mandarg
Joined 13 years ago
Joined 13 years ago
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.
It looks like the Firefox extension isn't around, and the corresponding Chrome one [1] doesn't actually work any more and was last updated in 2014.
I suppose things were simpler back then when services had slightly more open APIs.
[1] https://chrome.google.com/webstore/detail/scribefire/elkkomi...
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.
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.
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.
A canonical example: http://bactra.org/
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.
[1] http://shallowsky.com/blog/linux/gtk3-emacs-key-theme.html
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 :)
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.
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.
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.
https://twitter.com/mangokhale
[email protected]