So, not a home user then. If you make your living with computers in that manner you are by definition a professional, and just happen to have your work hardware at home.
In the context of background jobs idempotent means that if your job gets run for a second time (and it will get run for a second time at some point, they all do at-least-once delivery) there aren't any unfortunate side effects to that. Often that's just a case of checking if the relevant database updates have already been done, maybe not firing a push notification in cases of a repeated job.
If you need idempotent db writes, then use something like Temporal. You can't really blame Celery for not having that because that is not what Celery aims to be.
With Temporal, your activity logic still needs to ensure idempotency e.g. by checking if an event id / idempotency key exists in a table. It's still at-least-once delivery. Temporal does make it easy to mint an idempotency key by concatenating workflow run id and activity id, if you don't have a one provided client-side.
Temporal requires a lot more setup than setting up a Redis instance though. That's the only problem with it. And I find the Python API a bit more difficult to grasp. But otherwise a solid piece of technology.
I thought that the point was to post valuable thoughts - because it is interesting to read them. But now you suggest that it depends on how they were generated.
Yeah, but if you're having to turn to a machine to compose your thoughts on a subject they're probably not that valuable. In an online community like this the interesting (not necessarily valuable) thoughts are the ones that come from personal experience, and raise the non-obvious points that an LLM is never going to come up with.
Strongly agree with that. Its slower, but I will always prefer building actual database records as either part of the test or in the test context rather than relying on some predefined fixtures. That makes the test behaviour clearer, and it means you don't have a bunch of unrelated tests failing because someone changed a fixture to accommodate a new test.
I think there's a space for something in between Ocado and Uber Eats, in the 2010s I worked for a startup where you could book an Ocado style delivery slot for the next day from a bunch of different butchers, bakers, etc and then we'd send a van round to collect from all of them and deliver it to you. Annoyingly they ran out of money just a little bit too soon, I'm pretty sure if they'd managed to hold out until 2020 they'd have seen a huge increase in sales as everyone fully got on board with online delivery and been laughing.
I think the big win with that model vs Ocado is that scaling down is fine, you work with whatever shops are in the area and don't need to deal with building fulfilment centres. Maybe you need a car park somewhere to put the vans overnight. Scaling up is a case of moving into different areas, or onboarding new shops. Absolutely agreed that last mile is a nightmare but we mostly had it down I think, the biggest pain there was that we were relying on a bunch of third parties to pack an order, and if any of them got something wrong we ended up with an unhappy customer on the phone and needing to deal with it.
I worked in this business for over 15 years on the tech and business sides and I can say that the traditional VC-funded startup regime is fundamentally incompatible with the basic realities of the food industry. What is sort of funny about it is that in many areas there are local companies that have been around for many years doing this fantastically. As other commenters pointed out, this is essentially the milkman model.
There are a number of extremely difficult problems that are definitionally insurmountable on the timescales that VC operates -- paramount among them being the establishment of trust and mutualistic relationships with your vendors/stores, customers, and employees.
You are right that there is such a space, it just won't happen in the context of a startup taking VC cash.
You're absolutely right on that - what eventually killed the business was an influx of VC cash and demands for massive expansion during a period when we almost had delivering in a single city nailed.
>the biggest pain there was that we were relying on a bunch of third parties to pack an order, and if any of them got something wrong we ended up with an unhappy customer on the phone and needing to deal with it.
Why not have drivers verify the order with the store? Like have the store folks walk through the pick ups. It might be slower up front, but it would save lots of time and money for everyone in the long run. One of those slow is smooth and smooth is fast situations. Alternatively, the drivers should have a book they could match pics to items perhaps
The other thing I wonder if it would be possible, would be to reduce revenue share for stores that routinely had issues with accuracy, but that means you'd need leverage, and you simply may not have it.
I stopped using Doordash because they had absolutely no process to ensure drivers picked up the correct person's order, let alone actually making sure orders are correct. You give me another person's order with completely different things - I don't trust you again.
This is one of the most basic functions that a delivery service should have: making sure that you get the items you ordered, in good shape.
FC's can have very efficient fundamentals if done right. Sharing shops with direct customers is very problematic - while appealing, the scaling just doen't work for them very well. They're also subject to a lot of variability due to contention with said customers.
This is why next day delivery slots worked - shops were able to pack orders during quiet periods rather than suddenly getting slammed with delivery orders that will be picked up in 20 minutes just as the lunch rush arrives. Some of the shops we were delivering for had people they employed specifically to do this, and generally they loved it because it meant their staff were doing something during otherwise quiet periods.
Next day slots generally work for few customers. We offer delivery in the next 3-4 hours (unless demand is crazy) and the difference in demand when you offer 3-4 hours and when you offer next day is HUGE.
100% this. Go and spend time with the people using your software. Even better, use it yourself.
One of the companies I’ve worked for did food delivery, and in food delivery during Christmas week everybody works operations - either you’re out in a van with one of the regular drivers helping them carry orders that are three times larger than any other week, or you’re handling phone calls and emails to fix whatever problems arise. Either way without fail January every year would see a flurry of low effort/high value updates to the software those parts of the business used. Anything from changing the order of some interactions to fit the flow of dropping a delivery to putting our phone number in the header of every admin page.
Absolutely nothing beats going out there and doing the job to discover where the tools you’re responsible for fall over. Bonus points if you can do it at the most stressful time of year when if anything is going to fail it probably will.
Not using it themselves is why my managment at various companies wouldn't let anyone do sensible things.
Companies that sell to other companies .... don't care about the users. It's one bunch of managers sleezing up to another to make a sale. Whether the product is good to use doesn't matter to them because none of them use it.
A "good" company wouldn't allow this to happen but it happens often enough.
Another bad smell is when developers themselves never use the whole product and simply work on their little bit.
Eat ones own dog-food, or in other words, get the company cooking something great together and sharing the results.
A great company basically opens on its first day and 48 hours later there are a ton of well fed customers who come back, not incidentally, again and again for what they perceive, is great.
But apropos feeding customers, if you can't 'eat your own food' dog or otherwise, why expect the user to want to do it ..
And it's such a blind spot in the industry that the people most able to build and estimate features and software are left to be the least equipped to see through the end user's eyes.
As such, when you encourage user oriented engineers, these common and often low effort issues can be avoided at the outset which improves velocity organizationally and results in better software and user experiences for projects now and in the future.
I once worked at a company where I couldn't a single person who would have used our product even if they could. "Well, I guess I am not in the target group for our product..." was the most often used excuse. It was very frustrating.
I’ve had multiple managers over many jobs who’ve said they were on board with this. I’ve had CEOs saying from the top down “decline meetings without an agenda”, and yet somehow it never changes.
This isn’t backed by the constant conspiracy theories about voice assistants listening to everything you say and then farming that off to third party ad providers so that you see ads for things you’ve been discussing.
I’m not certain about that, but it’s all very abstract to people. It is also tied to their phones for most people which they’d never give up anyway.
The more direct connection on something they don’t (yet) value as much as they value their phones might be a bridge too far.
An LLM feels like a person to a lot of people. It might be surprisingly difficult to avoid people feeling betrayed or creeped out by this “person”. No one has ever done this before and it doesn’t seem easy or like a straightforward win.
It is odd how often I hear even technically people defend the idea that Instagram is listening to everything they say even while the phone is locked, sending it to Meta, and then influencing their ad delivery. You have to either have very little understanding of mobile apps and reverse engineering to believe that this is happening but nobody has been able to find proof yet.
It’s right up there with people who believe conspiracies about everyday things like chemtrails. If you really though chemtrails were disbursing toxic mind control chemicals (or whatever they’re supposed to be this week) then you’d be going to great lengths to breathe only purified air and relocate to another location with fewer flight paths. Yet the chemtrail conspiracy theorists don’t change their behavior. They just like complaining and being angry, and it’s something they can bond with other angry complainers about.
Or if the moderation was good someone would go “nope, take that bullshit elsewhere” and kick them out, followed by everyone getting on with their lives. It wasn’t obligatory for communities to be cesspits.
reply