mherdeg
(I have the same feelings as mhh__ in https://news.ycombinator.com/item?id=38967529. Just a remarkable and extremely slow miscarriage of justice.)
I love peoplemovers (like the Hong Kong Central-Mid Level escalators and the delightfully bouncy SFO walkways) and always wondered what would have to be different for us to get super-fast ones for transit.
In Boston, IMO they would be at least as good as the Green Line :)
The past year or so of published literature on LLMs has been kind of hilarious because there is a substantial chunk of stuff whose contribution is "putting this extra English sentence into the input produces measurably better output".
It's like watching alchemists puzzle out chemistry, or like watching wizards fill their spellbooks. What a cool time.
In this vein I think about nelhage's "Computers Can Be Understood" from time to time - https://blog.nelhage.com/post/computers-can-be-understood/ .
Some of the best ambassadors for Brutalist architecture I've experienced are the Barbican in London and the Bonaventure in Los Angeles. They make good spaces for people.
Did the company just write off that shipment and keep selling them?
I went looking for articles about this recently and couldn't find them any more. Did I imagine this happening?
* the 2019 update that someone re-evaluated the risks and thinks the retrofit might not have been necessary after all ( https://www.nist.gov/publications/wind-effects-tall-building... )
* the identification of the person who called LeMessurier in 1978 and whose questions made him redo the math (whose name is not listed in the New Yorker article) as Lee DeCarolis ( https://onlineethics.org/node/41606 )
In the version of the story I read, Diane Hartley flagged the risk to the engineer by writing a whole thesis about the building (see e.g. writeup at https://www.lemessurier.com/sites/default/files/publications... and https://onlineethics.org/cases/engineers-and-scientists-beha... ).
It's interesting how, the closer you look, reality grows more complex than the stories we tell about it.
* each person in the room pulls up the stem when their individual second hand is pointing at 0, and also sets the time to the prearranged hour/minute,
* then everyone waits a bit longer until this is done;
* after another minute, everyone pushes down the stem simultaneously
Is there an alternative where you could have some way to force your second hand to the 0 position rather than waiting up to a minute for it to get there on its own then freeze it?
I do see why hacking is nice for time zone changes.
I like the suggestion to rethink whether you actually need to be doing asynchronous computing with a message broker/queue/stream or whether you can represent your work another way.
I loved seeing the genuine joy our PMs had whenever they found an honest to goodness calc bug and could get it reproduced and fixed in The State Machine. It was also a delight to see the web app approach parity with the desktop client experience -- we got to listen to a wide swath of users and build out the stuff we thought would be most useful to the most folks. And I loved our group PM's insight about what the heck Excel could be good for versus purpose built BI tools, other web sheet apps, pure SQL, etc.
This is a very fun kind of product to create and it's awesome that you were able to ship it in a way people could use!
I originally picked up the book because I was trying to understand Euler's polyhedral formula better -- which in retrospect is kind of like reading Zen and the Art of Motorcycle Maintenance because you wanted to fix a motorcycle.
I'm not wired for pure math -- I loved real analysis then quit while I was ahead. Still it's fun to pretend sometimes, and Lakatos does a great job of making you feel like you're learning inside knowledge about what mathematicians do. He introduces fun concepts like "monster-barring" (the way people sometimes carve out special cases in a proof when they encounter counterexamples).
I've never made it the whole way through, but I like to go back every few months and absorb a little more.
edit to add: I just now skimmed the author's Wikipedia entry and the Stanford Encyclopedia of Philosophy's story about the author's interaction with someone named Éva Izsák and I have a ton of questions.
> Impact Theory agreed to destroy all Founder’s Keys in its possession or control
What does this mean practically -- like they delete the files that would allow them to transfer control of the NFT? What even are these things, are they just text files in a distributed file system that list the owner's name or what?
Bonsai Kitten is lost to the ravages of time.
(1) You learn a ton about which production clients actually respect your instructions, and which ones creatively misinterpret them. You learn a lot faster than you would by stepping through the code.
(2) You learn how other systems behave with flow control in place. If you can, you make it so the default behavior is safe for users. This makes it safe for people to practice pushing the button, even when things aren't overloaded, so they remember how to do it and don't feel uncomfortable doing it during a high-load event.
(3) You get to see some really cool shapes -- sinusoids, cliffs, plateaus -- that show you how traffic goes away and how much of it comes back. (You probably learn, early on, to tell different clients to retry after different time windows, and how this shapes the curve.)
Also really satisfying has been observing how a system behaves under load and making a tens-of-lines-of-code change that hugely affects the safety of request handling. We stabilized a large system that was showing bad behavior under load just by teaching it a few things like
(1) Put health checks in a different thread pool than other request handling, so you can always satisfy them quickly
(2) If you're going to return fast failures to certain categories of request when overloaded, insert some debouncing. Evaluate "I am overloaded" over a time window -- like "I have been continuously overloaded for the past 300ms" -- and a lot of signals smooth out in a way that ends up feeling better to users.
This has always been a fun space to work in.
As far as I can tell from TikTok people want to be part of a brand experience, they want to show their friends they live a luxury lifestyle, and they want to earn promotional goods by being influencers.
There may be some sinister manipulation by marketing experts, but maybe also people just love Texas Roadhouse rolls and love being a part of a bigger movement when they get their pint of butter.
Is there anything wrong with that? It's fun to do your version of the thing that everyone's doing!
I think the separate trend towards hiding your authentic self in a small group direct message or a Discord or Slack instance isn't so bad ... It's not too far off from where we were on IRC in the before times.
Did the domain lapse and was it re-registered and rehosted for promotional purposes?
(1) How many distinct total binary versions of your monolith will you permit to run in production? Some options might include
At most two globally ("current" and "new" canary/blue-green deployment, no special code on particular tiers)
At most two globally, but sometimes you're willing to deploy a special build to a single tier to mitigate an emergency, with eventual convergence
At most two per tier, but with no attempt to keep each tier running the same binary code (maybe you don't want to redeploy your async consumers as frequently as you redeploy your http handlers)
An unlimited number (maybe you deploy customer-specific binary code to specific instances within a tier)
Would you like an alert when there are too many distinct versions running in production? Who should get that alert and what should they do when it fires?
(2) Does this thing deploy simultaneously everywhere?
If so, is any specific person or team responsible for making sure the deployment worked ok on every tier, declaring an incident if not, and rolling back and finding an owner to resolve the issue? Will every team who owns a part of the monolith contribute someone to a shared rotation for release monitoring?
(3) Suppose there is a blocking problem in one part of the monolith, for example async message processing stops working reliably. Should this block deployment or development for other teams whose changes are outside this blast radius?
(4) Suppose some low-level intermittent compilation error prevents the binary from starting up 10% of the time after a certain build revision for every tier. What team will work to resolve this kind of problem? Is there a team writing telemetry and common logging for your monolith everywhere? Is there a team who will implement common operational concerns like feature flags to gate binary changes?
(5) Does your monolith run in any non-production environments? Is every tier running in each environment? Does somebody publish an SLO for those environment? Is one team allowed to break everyone else in pre-prod by deploying experimental code to the monolith in some environment? Who deploys to the pre-production environment and how?
(6) Suppose you discover you need to split up your workload (one kind of http request is much slower than all others and you want to separate failure domains). How much work does it take to create an additional tier -- updating deployment jobs, quality gates, and CI/CD pipelines throughout various environments, provisioning resources, setting up graphs and alerts, creating new tests? Who does this work?
(7) How will you manage configuration for your monolith? Will configuration directives be delivered to every tier simultaneously? Can someone accidentally break the behavior of another team's tier with a typo or logic error in a configuration change?
(8) When it comes time to split this thing into microservices or macroservices for a few years before a successor team looks at the mess and decides to reimplement a monolith, how do you set up your architecture to successfully allow a split?
(9) Are you absolutely sure your tiers do what you think they do? Can API customers bypass rate limiting by pointing to the hostname of your async-worker tier? If a security vulnerability in a particular http route affects your monolith, will you remember to block the route on every tier (even the ones you think don't normally serve web traffic)?