> 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.
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