That is the direct effect of reduced cost. Jevon's paradox type effect: cost goes down demand goes up. You can AI-check so many more things that would be very time consuming earlier.
Yeah I didn't implement that as in the show they don't let you look anything up but quite a few people have mentioned it would be useful. I think I will add
- A minimap to all the timetables that show visibly where the transport goes
- A tourist information center in town and city centers you can use to find out other information
Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common
Yeah, I used to hate it, but as I was building a new project I was like, oh man, I can't believe I'm even thinking of doing this, but it makes more sense LOL Instead of prompting twice, I can prompt once in one shot and it has the context of both pieces too. I guess if I ever need them to be separate I can always do that too.
Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat
Even if the rollout was atomic to the servers, you will still have old clients with cached old front ends talking to updated front ends. Depending on the importance of the changes in question, you can sometimes accept breakage or force a full UI refresh. But that should be a conscious decision. It’s better to support old clients as the same time as new clients and deprecate the old behavior and remove it over time. Likewise, if there’s a critical change where you can’t risk new front ends breaking when talking to old front ends (what if you had to rollback), you can often deploy support for new changes, and activate the UI changes in a subsequent release or with a feature flag.
I think it’s better to always ask your devs to be concerned about backwards compatibility, and sometimes forwards compatibility, and to add test suites if possible to monitor for unexpected incompatible changes.
Rollout should be within a minute. Let's say you ship one thing a day and 1/3 things involve a backwards-incompatible api change. That's 1 minute of breakage per 3 days. Aka it's broken 0.02% of the time. Life is too short to worry about such things
You might have old clients for several hours, days or forever(mobile). This has to be taken into account, for example by aggressively forcing updates which can be annoying for users, especially if their hardware doesn't support updating.
I love how Django just keeps slowly improving at every release. 6.0 is especially cool, including lots of really useful new features. Who said dependable tech was dull - this is the way is should be done. Well done all who contribute.
Same! I've been using it since pre-1.0 and love it. I am currently a few blocks away from it's birthplace.
Probably the wrong time or place but I am also on the market literally as of yesterday so if anyone is looking for an experienced Django guy, I'm your man! oldspiceap@gmail.com
reply