Fluxx

On the quadrupling of the estimate from $250 million to $1 billion between 1995 and 1996, the article states:

"The cost increase was the result of detailed engineering studies conducted during the year or so after the initial estimate was released. Among other things, soil testing in the Bay had revealed that bridge pilings would need to be anchored “deeper into bedrock than expected,” she writes."

Now hindsight is 20/20 and I am not an engineer in this field, but it seems that if you're floating an estimate that isn't informed by the engineering studies necessary to give an accurate estimate then you probably shouldn't have given that initial estimate in the first place? Or at least should have given the initial estimate as a range and/or with a huge disclaimer that you might get into researching the bridge and the estimate could cost multiples more?

Yeah that's totally fair. I live at Geary and Stanyan, and made liberal use of the 38L and 38[A,B]X busses, which cut that time down a lot. I used to go to the gym every morning before work and could be door to door on the 38BX in about 25 minutes most days. If you can get a seat on the busses, I kinda enjoyed the time on my phone or with a book, but that's not always possible too.

I commute by bike now, which is certainly the fastest way to get around the city - perhaps just not the safest or least-sweaty way.

There does seem to be a "center of gravity" in SF that is incredibly bizarre to me. For a lot of people, if you live west of Divis or south of 24th st, you might as well be, for all intents and purposes, in Oakland. Seems like a lot of the complacent crowd of SF lives in the Mission/SOMA/Pacific Height/Marina/Russian Hill bubble and never gets out of it.

Yet there is a whole 3/4 of the city that isn't encompassed by that part that is really, really awesome. It may not be "trendy" or anything, but they're full of great neighborhood places and "real" people. I think it's easy for everyone analyzing this situation to forget those places exist.

It's not revolutionary, but it does a lot of things right and has more features that what you mentioned above:

* maintains a semaphore of currently processing requests, and will immediately fail a request if the semaphore is full.

* tracks service latency and other statistics for you

* maintains a circuit breaker to immediately fail requests if the breaker is open (based on statistics)

* watches for health to be restored of the 3rd party service and allows requests to it again.

* built in request isolation via threadpools

* built in request collapsing and caching

Overall I like this cause it's a great demonstration of how to think about, and engineer for, failure in a distributed system.

> you're just given some basic data structures that handle pretty much everything under the sun, and you go from there

This only works because the size of your n is small, possibly a few hundred, so it doesn't matter. When you start dealing with millions or billions of records this stuff matters. Quite a lot.

So really, it's not the language, it's the size of your data - or the size of n that matters.

Django still powers a lot of the DISQUS infrastructure. That said, we're in the process of breaking certain parts of it off into independent services and out of Django. But Django will be the main component for the foreseeable future.

While I don't disagree that Apple's technical skill isn't best of breed, where Apple has shined - both now and in the past - is their ruthless determination and focus on UX and HCI. Apple goes further than any company on the planet to make technology devices (computers, laptops, music players, tablets, etc) that delight their users and just work and make them happier and more productive.

Apple doesn't have "cheesy blah inside" stickers because that doesn't delight users and make the product better to use. They're stupid. Apple also doesn't chase fads because fads are just that, "a fad" and rarely do fads have long lasting staying power like a good product should.

I'm a huge fan of office "suites" - smallish offices which comfortably hold 3-6 people. It's a good sweet spot between open spaces full of dozens of people and individual offices. Usually suite-mates are people on the same team/projet as you, so you still get that open collaboration, but aren't distracted (or distract) the other people in the office whose daily work is unrelated to yours.

> NodeJS is suitable for apps that do plenty of short lived requests.

I'm confused. Isn't Node's event-loop style programming ideal for long-lived requests? I.e. ones that, under a synchronous i/o, block other requests?

Hulu, Living Social, All of 37 Signals, Groupon, AirBnb, Scribd, Zendesk, Soundcloud, etc.

Twitter's scale is unlike nearly every single web app online, so I think the real story with Rails and Twitter isn't that "they had to move away from it for scalability reasons," but rather it's amazing that they were table to leverage Rails for as long as they did."

Also, Twitter is more dropping Ruby all together rather than just Rails specifically. Again, this isn't to say that Ruby isn't a great language that works for most people (it let Twitter grow quickly to where they are today), but at their scale with their demands it doesn't work well.