> Quick quiz, hot shot: what did you think of the surgery team metaphor?
Interesting side discussion -- I have just started reading the book, but I did think that the idea of the surgical team was an interesting and radical departure from the standard "two-pizza team" pattern of a few developers that are considered roughly equivalent aside from minor leveling changes. My personal thoughts were that it would be hard to see success with the model unless you made sure all the roles were recognized as being equally important towards the success of the team.
Having learned multiple Devanagari languages at school (including both Sanskrit and Hindi), I don't recall being explicitly taught stroke order as such. There's an intuitive way to write most Devanagari characters that usually corresponds to the "preferred" order you mention, which is only apparent in serif Devanagari fonts anyway. But for example, I have no idea what the preferred order is for U+0918 घ, and never learned one as such.
Side note: since you mentioned ballpoint pens, (at least 10+ years ago, things might be different now) we weren't allowed to use a standard ballpoint pen/biro; fountain pens were preferred and micro-point ink or gel pens were allowed.
Here is an index of different theories that astrophysics departments have developed to explain these FRBs (Fast Radio Bursts): https://frbtheorycat.org/index.php/Main_Page. There are links to all of the corresponding papers as well.
> I can't imagine providing a feature-rich web application in Lambda without this kind of abstraction.
This reminded me of a caveat about using some of these abstractions – which is that they are still subject to the limits and restrictions of the underlying platform.
We discovered this the hard way once when an automatically generated function name or something was over the limit in prod (this issue [1] describes a similar problem). We did not catch this in dev because "dev" is one character under "prod" and our autogenerated name in dev hadn't put us over the limit. That was an interesting exercise in leaky abstractions.
forge and github-review (https://github.com/charignon/github-review) have given me a near-immersion experience for bitesized code reviews in Emacs. They even work together, via github-review-forge-pr-at-point!
The only thing stopping me from using this with larger diffs is the lack of a good way to show more of the surrounding context in github-review. Wonder if there is any interest in making github-review a first-class part of forge.
For what one person's opinion is worth, I quite like the look of old-style text-and-hyperlink websites, so long as there's something interesting to read on them.
I switched from Linux to OSX/MacOS around eight years ago, and the better and (to me) more intuitive modifier keys have been one of the features that have kept me there; along with the convenience of Emacs/Readline keybindings for text editing everywhere.
Getting keybindings to work the same way in Linux currently involves a Rube Goldberg setup of GTK3 key themes [1] and AutoKey [2] for me, and some things still don't work right (Super-W closing a single tab in Firefox/Chrome, etc.) Also, it looks like key themes are going away in GTK4 [3].
The Hawck daemon cited elsewhere in the conversation looks promising, maybe that'll work better.
Nearly 10 years ago (wow, time flies), as a weedy undergraduate, I was fortunate enough to do a research project [1] under one of the scientists [2] who worked on this survey. It was pretty cool to just be able to submit arbitrary SQL queries and get nice CSV files back.
With my imperfect knowledge of astrophysics and hacked-up scripts, it was pretty intimidating to stand up and present my "interesting-but-will-probably-need-more-detailed-research" to a bunch of people with literally decades of experience in the field and have them take me seriously and ask questions.
I do other things now, but it's a pleasant surprise from the past to see this on here :)
What are some alternative sites that send you guests? I have used hotels.com sometimes (has dark patterns too, but fewer of them). I would definitely prefer using something that was more...sensible.
I would naïvely think that booking directly with hotels would be cheapest, but I have definitely seen deals on these aggregators that were unavailable on the same hotel's own site – which is the only reason I even think about using them.
It's interesting to know that a traditional ISP like AT&T is heading the same way.
I think Google gets more freedom to try out some of these techniques because people still fundamentally think of them as a website (apart from Google Fiber, they don't serve end-users directly); whereas AT&T, being an ISP, is treated more like a water / power service, in that people expect them to be working by default, and going down is absolutely unacceptable.
Here's my attempt at an explanation, after reading the article.
Most companies' networks have edge routers (which sit at the points where they connect to other networks) and core routers (which manage the flow of traffic inside the network. All these routers basically use a standard protocol called BGP (Border Gateway Protocol) which is defined by RFC 4271.
However, BGP was still designed from the view of individual machines making routing decisions and announcing routes to each other that collectively make up the whole Internet. This helps the Internet as a whole be quite resilient – if one network goes down, there are still ways to route traffic through to other networks. Also, since the protocol is standard, you can swap out one vendor's gear for another at will (in theory anyway) as long as you know how to configure it correctly.
But this leads to some inefficiency – for instance, it is very hard to say that a path with fewer hops will lead to lower latency. What Google seems to have done is to make their edge routers into one single "intelligent" network, where the edge routers don't make routing decisions on their own, but feed their data into a central server. This central server can then say stuff like "My peering router in NYC seems to be under heavy load, let me redirect some of my traffic to NYC destinations through the NJ datacenter instead", or something to that effect; while still doing the correct BGP announcements from the point of view of Level3 or whoever is peering.
In short, they built their internal network from the ground up since they are so big they can afford to build custom routing gear instead of using the standard off-the-shelf, standardized setup that a small or medium-sized company uses. The network consisting of their custom edge routers (all the green blobs) together is called Espresso and represented by a light grey circle.
Just an anecdote, but I tried to use lob.com to send out Save the Dates for my wedding. The couple of test postcards we used did not arrive on time, and the tracking didn't work at all. Their support wasn't good at addressing my specific case – they mostly told me “This is how the website works”.
It could have been that I wasn't using it right, but I didn't have the time to troubleshoot. We ended up printing a bunch of cards at FedEx and addressing and sending them by hand. Everything worked smoothly.
I still use a keyboard with a PS/2 connector (Hangs head in shame). It's an old (at least 10 years) Kensiko ergonomic one I rescued from a giveaway pile and have never been able to find a good enough replacement for.
Pretty sure they don't make USB Type C adapters for PS/2.
Interesting side discussion -- I have just started reading the book, but I did think that the idea of the surgical team was an interesting and radical departure from the standard "two-pizza team" pattern of a few developers that are considered roughly equivalent aside from minor leveling changes. My personal thoughts were that it would be hard to see success with the model unless you made sure all the roles were recognized as being equally important towards the success of the team.
I had wondered about (and rour comment inspired me to look up) whether people have had any experience trying it out, https://softwareengineering.stackexchange.com/questions/3552... has some interesting references and pitfalls of the approach.