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
I was able to find his reply. The stuff after the `>` is him quoting me. There's another part to this somewhere, but I'll have to keep looking.
> Hello!
> I am learning Erlang and really liking it.
Great
> I am finding myself really liking the immutability in regards to being able to reason about my code, but that leaves me with a probably easy question: why does immutability make concurrency easier?
Tricky I guess it makes parallel execution easier (no locks) - it certainly makes programming easier
closures really are closures :-)
> Is it because it's difficult to have something in a thread reach-across and modify the state of another thread?
That's not really immutability - actually I hate threads - the difference between a thread and a process is
crucial - threads can modify shared state (horrible) -
In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden)
where is the shared state? In the middle of the Atlantic? - shared state breaks laws of physics.
State changes are propagated at the speed of light - we always know how things were at a remote site
not how they are now. What we know is what they last told us. If you make a software abstraction that
ignores this fact you'll be in trouble.
> Does that mean concurrency wouldn't be so bad if you kept state mutations contained within one thread?
Yes - if you use the word process, not thread. Processes were invented to provide protection
from other computations and to share resources in a clean way - threads share resources in a messy way.
> If you don't have time to answer right now, a link or some guidance into the right resource would be appreciated!
I think what you're interested in is the distinction between message-passing-concurrency and shared-memory-concurrency.
Ah, found the email he responded to a year later. As before, the stuff after the > is him quoting me.
----------------------------------------
> Hello!
>
> Just under a year ago I send you a message asking you about multi-process computing and the like. You gave me a long, detailed email that not only answered my questions, but also explained in pretty-decent detail.
>
> I was so impressed by that email that I actually purchased your "Programming Erlang" book, and enjoyed that just as much, and today I started my first job doing Erlang full-time (well, mostly; there's some JS involved).
Great - thanks a lot for buying the book - these kind of stories
make it feel all worth while
> I just wanted to thank you for the help. I know a compsci-celebrity probably gets bombarded with emails,
Actually not - I guess it's a 'being polite' thing - I rather like twitter it
lowers the entry barrier for communication between people.
I have in the past mailed several of my CS "heros" - and was always
rather reluctant to do so. Then to my great surprise I often got long
and helpful replies (from Niklaus Wirth, Alan Kay, Jim Gray)
This kind of fits in with my view of life - 95% of people are basically helpful.
I've always thought that converts were gained "one at a time" - imagine
a drip drip drip of water falling into a pan - one day it overflows.
We always think it's fantastic to hear the stories of what you guys do with
Erlang. (I say we because the Erlang you're using is the product of
many people fantastic work) - I'm just the fall guy who writes the books
and happened to start it all :-)
I was sat listening to Brian Acton who founded WhatsApp and made 3.5B$
and thought "I invented this crap" - which is a great feeling - and they gave me a tee-shirt.
So the side effect of what I do is I get to meet loads of interesting people
and do what I want.
Anyway thank again, and I hope things go well for you.
> and I think it's really cool that you took a good amount of time responding to some random guy on the internet asking for help.
Well every body is a random guy until you share stories.
My wife was a random woman before we met.
Anyway life would be very boring if it were not for random events.
I never run for busses or trains - it was after I read about a guy who missed
a train and had a random conversation with a guy on the platform
who had also missed the train - this gave them an idea that they
turned in a multi-million dollar business.
I guess the other reason that you get long replies is that I'm an author
and I don't do short mails.
> As usual, keep up the great work.
I'm trying - though I've recently retired - gives me more time for hobby programming - though I have to tend my garden and so on
Please consider sharing this email exchange with lettersofnote.com. I am not affiliated in any way with that site, but I have found it to be a great source of inspiration and a reminder that very successful people are still people, and often very approachable and kind people. Reading this sort of thing can restore one's faith in humanity, and provide impetus to change one's own behavior towards kindness and generosity.
Yeah, I'm glad I was able to dig it up. It has an almost-inspirational sentiment to it.
Also, rereading this line genuinely made me laugh:
> I was sat listening to Brian Acton who founded WhatsApp and made 3.5B$ and thought "I invented this crap" - which is a great feeling - and they gave me a tee-shirt.
Me too; it's an cleverly simple way to say something that seems obvious, but bizarrely isn't. I guess like Erlang itself, Joe was good at expressing the complex tersely.
