wetwiper

Apple adopted the term to describe a new sensor that measures depth

Not to be _that_ person, but someone should maybe inform the author that use of LiDAR has been around for quite some time already... the "sensor that measures depth" is pretty much a description of what LiDAR is used for and this isnt a new application of the term. And sensors to do this already exist so no "newness" in this field. I mean sure, if they were talking about it being included for consumer usage in everyday mobile devices, then maybe thats a new thing? But the wording of that phrase seems to want to credit Apple for something newly coined or invented, which isnt the case

seconding the request for a self hosting option, as well as the payment of a licensing fee (which I'd be happy to pay, as this is also something I've been looking for)

This is all well and good when dealing with optional features/functionality. But 'required' fields present a challenge. Such as adding a required field to a form, or updating some process with an additional step. If the UI is added last, but the backend logic is ready and available before the time in production, this would suggest that your backend is either using dummy values temporarily or using additional logic to work around the release delay. In either case, this means: - cleaning up said extra processing/dummy value logic when deploying said feature for real (potentially introducing bugs during this step); - requires reverting data storage in the event of dummy input being used where such data needs to be persisted (I'm assuming the backend has been updated already to cater for the required fields since the changes are already in production); and - other (backend) systems that feed from the other end of the API that now depend on such a field being set, now either need to treat the field as optional and at some later stage add any validation, etc, -or- needs to be scrubbed of such dummy data as well (not always possible).

Seems that the answer in such cases is that enabling the option on the UI is not the keystone, but rather the usage of said fields in other APIs or functionality within the backend. But this complicates matters depending on the backend itself as well as the required usage of said required field(s).

So while I can see some value here, I dont think required inputs are as simple or easy to chalk up.

Despite having used the "we're solving problems" argument myself on occasion, I think what we're really doing is identifying problems and assisting with possible solutions using particular knowledge of our domain.

Somebody wants something done within particular constraints, so our job is to identify potential issues that may occur, such as scalability problems, costing issues, UX concerns, etc. And help explain to that client such concerns and possible solutions or compromises, and let the client decide on the solution.

Once actually implementing some plan, we have some creative freedom on the implementation details, but I'd hardly call that solving a problem (apart from it being your own problem on how to get the design coded up).

agreed. I'd even be inclined to take it further and suggest that once leaving high school, pressures and stresses related to self sustainability (being employable, financial concerns, housing, etc etc) would become more real than any previous family memory.

Also, wouldnt an understanding that materializes as one gets older of the back story into each memory story (with the frame that memory stories here as having a positive impact) have the potential to change the frame of the memory, which decreases the likelihood of it being remembered? As in, certain memories are pretty great until ypu understand how it came to be that way, in which case either the back story becomes more signigicant or it becomes more mediocore than remembered. And mediocrity is easily forgotten...

I'd also suppose that as people move on with their lives, people relate to each other via shared stories... family stories have little meaning to those not involved, and so have little impact in "fitting in" in the rest of society. As that dawns on individuals leaving home, so are such stories repressed until they more actively need to be remembered.

Since the mention of P2P traffic comes up, can you maybe mention the differences are between what you want to achieve and a P2P network with a payment system included into it? I'm honestly just curious...

My first and ongoing thought reading here was: "this sounds they want to build a P2P service like Bittorrent". Tje only difference is that you seem to want to include a payment mechanism into it.

Different note: how do you plan to verify original ownership of material? So of I upload copyrighted material of content, does that allow me to get paid for someome else's work? And if the original content creator uploads the same material, how do plan on validating originality of the content?

Are you not maybe specifying too much too early on?

Back when I did some freelancing gigs, the general advice I got was to spec a high level, general proposal which included all the client's requirements. Broadly. Then decide on iterables, with the spec (and timeline and effort and payment) for each iterable being done prior to commencing work on it. The key being to have a working system after each update. Sound familar ;D

The client's risk investment in you not completing the project (and them being left with some obscure code and no system) is minimised. Your risk is minimized as the client actually gets to update requirements at each iteration and you get to charge depending on implementation details for those changes. And if they feel you are taking them for a ride, they have a conpleted system up to that point in time, so have the option of looking at other developers. Which also allows you to bail as well without dropping the client with an incomplete project if its not worth it continuing.

My experiences like that went well - frequent communication kept the client informed of progress, they were able to manage adjustments (cost and time to implement), and at the end of each iterable they were left with a working system (even if rudimentary in the early versions) which they could build off of things went south.

I usually got paid more out of those, and ended up doing more work for them because of the relationship built.

This was exactly my thought! Despite all the hoohah around the decisions made and whether or not they did things correctly, this idea of "we'll create a bunch of separate services and then use a common shared library for all/most of them" was the start of the end from where I'm sitting... doing this is exactly where the trouble starts with future code changes as the shared library almost becomes a god-like object amongst the services using it: change something in the shared lib and all services using it need to be re-tested. Unless proper versioning takes place, but that, from my experience, seems to rarely be the case. Or need proper service ownership and chain or notification to inform service owners when particular versions are being deprecated or retired... which seems to rarely be the case as well.

Even so, imagine the chaos if frequently engineers/devs need to add code to one lib(the shared one), wait for PR approval, then use that new version in a different lib to implement the actual change that was needed? Thats seems to be introducing a direct delay into getting anything productively done...

Myself and a colleague are in this same position... we've just launched a store selling physical products, with a 2nd product store (with a completely different product set) launching in a few weeks. And then we're also working on an app that should be ready in about 3 or so months (at current projections).

Our approach has been approaching people or businesses in similar fields or related industries, and pitching the products to them and getting them them to sign up as affiliates. It reduces our income quite a bit and we make very little off it, but instead of us trying to reach the people they know and are in contact with all on our own, we effectively use them and benefit from them doing our marketing. They are keen to do it, since they have a good incentive to do so. Se make it worth their while. The long term goal is building up a brand, and then profiting off of that. In the meantime, everybody wins if they generate sales, but we dont have expensives if there isnt.

And yes, we met with potential affiliates during our lunch breaks, or after hours, etc. A couple were also generated through friends, family, and social group contacts.

Seconded. At least some screenshots, a video or two of game play, and a general story and game play idea, would help a lot for potential players to determine whether they would be interested or not. I don't want to have to create an account just to figure out if I would be interested in playing the game.

I'm not in Israel, so my answer doesn't contain specific values. I also don't do freelance work online. So...

My "offline" freelancing work quotations are structured like this: Firstly, I have a target of how much I want to make in a month, secondly an idea of how many hours I'm willing to work in a month to reach that target, and finally an indication of the delivery requirements of the project, if any (some quotations ask me to specify by when they could reasonably expect delivery, while others give an idea of when they require delivery). Then, I balance hours vs money vs delivery. So a project that has a delivery of a month (or multiple thereof) and means spending mostly all the monthly hours on that project will attract a rate that means I get out what I intend to for a month. Something that has a shorter delivery requirement with a higher number of hours to be spent (those projects where something needs to be done urgently, for example) the rate is a lot higher since more hours are spent on the project. I also work in a setup cost for each project, which is not billed directly but rather included in a higher hourly rate. I'll typically make more from 4x 1-week projects than 1x 4-week project, but the latter at least getting me to my target. While the former means a nicer "paycheck" at the end of the month, it requires more effort to get right, and it means requiring 4 different projects.

Obviously in practice there's other issues to consider, but such things are picked up over time. For example, projects don't occur one at a time sequentially. Which means sometimes working on 2 or more projects concurrently (your choice completely though whether you accept the extra work and whether you've planned for it). This means when sending the first (and subsequent) quote out, that the 'weights on the scales' have been adjusted accordingly. Then there's the consideration that there might not be work for some period, in which case either the end monetary target needs to be adjusted down for the period without work, or otherwise have an inflated monetary target to begin with, the excess of which caters for those periods (you'll need to determine what is a fair increase and how long it will take to build up a sufficient amount before you can afford to be without work - that length of time is a good indicator of savings needed before starting freelancing). Something else to consider is that a sufficient amount of time will need to be spent on admin work: generating quotes, responding to emails, invoicing, following up with payments, meeting (potential) clients , etc. You'll need to decide how to bill for this time as well.

Aaand I'm almost done with this novel... since you're wanting to do freelancing work online, you'll need to consider most of the above, but importantly, that a) your success rate of landing work is likely going to be a lot lower than what you think, b) the amount of "admin" required increases (responding to and browsing alerts, etc). All factor in on the total you'll make in a month.

Hehe... nick chosen for a variety of reasons :) I'm going to point out that storing user IDs and such in the payload is perfectly acceptable, and one possible means of transporting a user id around rather than as part of a url path, query string, etc. Because the payload is typically meant to be readable, there should never be any sensitive data like password info added to it. Note that while JWTs are used for authentication typically, thru are also used as a means of secure message passing. Anyway, proper use of a technology comes down to developer awareness, but I would hope that the developer implementing any means of security would do some research into doing it properly. We can't blame the tool for being used incorrectly :) Perhaps the problem in this case is a lack of sufficient proper documentation? Can't say I've found lack of docs to be a problem, but I guess people's mileage differs.

As for my points 3 and 4, I did mention that they included a DB lookup. I don't believe I've ever read anything that claims that it prevents a DB hit. In fact, this[1] page states that they help to prevent more than 1 DB hit for user info. However, what I was trying to allude to in my previous comment was that you can store the bare minimum info of your users in a cache. This cache can be used during the validation of the token (and even with token generation) , which prevents a db lookup. Since the data in the cache should contain data that rarely changes (should only typically be updated on password change, or when any of the details used in the payload of the token changes) , management and maintenance of your user cache is simpler. Specifically on point 4, what I was suggesting is that if you are planning on using something like HMAC as the algorithm for signing, then the signing and validation steps of the token can include the password hash or similar unique value for the user in addition to whatever key is provided. In addition, if your tech team has access to your production DB, you have a concern when anyone leaves anyway, regardless of what authentication method you are using. So not really something specific to JWT. In the case of JWT and using HMAC for example, I would have my production key stored in the prod environment only.

I will say that changing a key is a real concern, if your key does become compromised... but it is possible with a bit of thinking upfront about it. I've successfully implemented something like this previously.

Again, it's not the right tool for every circumstance, but when used in the right circumstance and in the correct way, I don't find most of your post to be relevant (meant with good intentions and I'm not trying to be provocative).

Perhaps a quick read through the Wikipedia page [0] on the topic, but more importantly, the JWT IO page [1] on the matter provides usage and implementation guidelines, as well as confirms some of what I've mentioned previously.

[0] https://en.m.wikipedia.org/wiki/JSON_Web_Token [1]: https://jwt.io/introduction/

Wow, I found this to be a naive view of JWT usage. I'm not advocating it's usage for every circumstance, and, the author does add the disclaimer that he knows little about it, but I feel the author misses a number of basic concepts of JWT's. Here are some observations:

1. you are able to decode the headers and payload of the token regardless of what algorithm was used. This is because both are base64 values of the content they represent. The purpose of the JWT is to securely identify a user in a stateless environment. The token's use is therefore to pass basic user information (as well as token information for purposes of identifying how to decrypt the token, it's validity time, etc) along, while identifying the user at the same time. The former requires that data be easily readable, hence the base64 hashing of that content. The latter part is achieved by using an algorithm that generates the signature of the token using the first 2 parts and by providing a secret key. If the data in the token is modified in any way, the signature won't match. Hence the validation of the token fails.

2. You should never be including any sensitive data in the payload of the token. Such as password hashes. The example given in the post is akin to a developer storing a users sensitive details in a cookie. You could probably get away with "higher sensitivity" data stored in cookies in certain cases, but overall it's just wrong and as a developer one should know better.

3. Persistence of tokens is typically an issue admittedly. How I've typically countered such things is using shorter token lifespans, as well as such things as the inclusion of a "session" key on my users table. This doesn't prevent a db lookup, but the value of which can also be saved to a redis instance for example. The value of this field remains mostly static and can initially be the same across all users for example, and the value of which is included in the token payload itself. For example, all users can have the same value of 1 (very simple case, but bear with me). Now, if you need to invalidate a user session for some reason, or log them out of all their devices, or some similar action, simply change the value of this field. Your token validation would need to include a check against this value as well which makes this not very different to session storage (or rather a user cache) , but it's not a worse performance than server session storage and because the value remains mostly the same, is actually easier to implement in my opinion.

4. A single key used to sign all user tokens is generally a bad idea to begin with regardless... but that's like not salting passwords or taking any proper measures when securing users. The case mentioned in the post could be likened to someone accidently typing out an admin password for a web login in a public forum... in which case, shit happens. Sure, in such case it's easy to update the password without affecting user logins, but to be fair, the use of insecure methods for security in general rarely if ever leads to secure implementations. Can't expect a sturdy wall if you don't plaster the bricks together. So related to my point 3 above, use of the user's password hash, for example, or some other, non public, identifier in addition to the signing key helps tons. Or use an RSA implementation signing algorithm. If however, you want HMAC, or such, your performance using a user cache is not unlike server side session storage, and is easier to implement and maintain. All the while keeping the benefits of JWT.

Again, not for every use case, but it's not as broken or insecure as the post makes it out to be.

I think the idea is rather: get up off your chair, move away from your screen, and interact with other people. Or dont interact (your choice), but do something that takes your mind off a problem and simultaneously off the "work" aspect.

More to the point (at least in my case) is to ensure that your priorities remain ordered correctly. Basically, ensure that you spend sufficient time with family, friends or others, and make time for hobbies that don't involve code. Time management is important in this regard... committed to providing 8 hours a day? Stick strictly to that. Your own personal project? Define a time restriction on the hours spent on that project, and keep strictly to it. You soon realize how much time those distractions during the day take up. By reducing those, your productivity increases. But importantly, relationships become stronger and those hobbies help expand your mind. Both are extremely beneficial to you and your growth as a developer...