> All of which I've directly contributed to and never (directly) recieved anything in return
To be fair, you received a service for free that you may have otherwise had to pay for. I'm not saying it's just, but to say you didn't get anything in return is disingenuous.
Agreed. I mostly meant that I'll never see the actual dataset that I contributed to. That's why I'd prefer to spend my time on things that I can see, like OpenStreetMap :)
While you weren't paying for it with currency, the service is most certainly not "free". There's still a transaction happening when you use the service, albeit a transaction the service provider refuses to acknowledge outside the terms of service.
> Exponential inner loops for big searches, huge recursive calls. Those things show up in code written by experienced coders IRL.
The thing is, those things are easily fixable after the fact. A bad architecture is not, and without practical experience designing systems in the real world, you don't have those instincts to guide you towards the correct choices because you haven't made any mistakes to learn from.
This was the main thing, as by that point, all native code was being compiled to Arm and not x86. Using x86 meant that some apps, libraries, etc just didn't work.
Of course they do. The cost of the ingredients is on the order of cents, the marginal cost of labor negligible, and the cost of the machines can be amortized over many thousands of servings.
But even if they didn't, it's a cheap way to get people to show up and potentially order other, higher margin items. If your machine is broken, you lose that funnel and your customers go elsewhere.
You don’t lose many customers - because they’re not required to light a huge “ice cream machine broke” before you get in the drive thru. And once you’re in line and ordering you’re unlikely to cancel just because the machine broke.
I’ve even had the app be wrong and let you order an ice cream when it doesn’t exist - then they lose money giving you a more expensive substitute.
We have 1 location in my area. I go maybe once a month hoping for a decent experience, but every single time they are out of key ingredients (no chicken, no beans, no chips, etc).
I really don’t understand how that can even happen at Chipotle where the entire menu consists of a grand total of (maybe) 10-15 core ingredients?
I would go way more often if they simply weren’t out or ingredients 90% of the time I go.
But he’s right about not canceling the order. I think last chipotle visit I subbed black beans for pinto, and tofu instead of chicken. The “sorry no chips today” was icing on the cake at checkout.
That’s interesting. I’ve gone to chipotle around once or twice a month for two decades now, and with the exception of their lemonades I’ve only had something unavailable maybe 3-4 times. Regional variation I guess.
Check out r/chipotle - maybe it’s an echo chamber there but it’s a major problem with mobile orders where you don't have an opportunity to sub an ingredient that’s out of stock. Depending on the store, chipotle mobile orders are a “fun” gamble - chipotle needs to fix quality standards across stores at least in my region!
Chipotle is one of the very few businesses I have ever left a google review for because the complaint seems extremely simple to fix. Just stock your store and hire enough people to prep the food!
True - it every time I’ve considered ice cream as an important part of the meal I’ve already disqualified McDonald’s (Dairy Queen or Culver’s is a step above).
With react-strict-dom, you'll be able to have far better code sharing between web and native. It will greatly assist the development of universal apps that target Web, iOS, and Android.
Right now react-native-web is not nearly as good as iOS and Android react-native. react-strict-dom is a massive leap forward for universal apps.
This is extremely elitist and reductionist. Plenty of the best comments/discussions on HN come from non-programmers. Personally, I like that people from various backgrounds come together like this as it tends to provoke more interesting discussion and makes HN less of an echo chamber than Reddit.
When you're using expo you cannot bundle your own native extensions. At my previous job we used pjsip. This extension uses JNI and native calls in iOS via objective-c. You can't bundle native extensions when using expo. You're locked to their prebuilt ones.
To use your own extensions you have to eject/or start a new application with their own native libraries. For most of what expo does you can use the unimodules libraries, they're quite good in my experience.
> When you're using expo you cannot bundle your own native extensions. [...] You're locked to their prebuilt ones.
Unless I'm misunderstanding what you're saying, this isn't true at all. At $day_job we have an Expo app with a custom native library and it works just fine; you just have to write an Expo-specific adapter for it and can't use Expo Go in that case.
Presumably because most people don't know about F-Droid, and there's a question of whether it's worth continuing to develop the app for a tiny subset of the original audience.
At what point do you hit that scale with project management software, though? Maybe you can't get to the point where you're managing all projects across all of Walmart from the same instance, but certainly you can run pretty much anything of reasonable size.
reply