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.
> 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.
I'm not sure if you can count this as a startup, but I bought my King-sized Sleep Innovations (memory foam) mattress with Amazon Prime for $530. And if I wanted the less-think 10" one, it would be $400.
The damn thing was ~100lbs in a giant box, and I got it shipped to me free. It's super comfortable and well worth the money - remember you sleep for like 25% of your life.
Mattresses seem like less of a specialty-item than eye glasses, so I wonder if big online retailers like Amazon can just cut out the middle man and service 80-90% of customers?
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.
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.
There was a Soundcloud account with a like every essential mix ever on it the other week, but shortly after it disappeared - I think due to licensing issues with BBC content outside of the UK. Did you look into that for your player?
> Isn't this just a method of implementation for your option 3? I don't really see a substantial difference between mocking the server and mocking the API.
The short answer is that there is no difference. Just as you could mock out a call to S3API.get(object_id) and have it returns my_object, you could write a server that responds to the S3 API call for getting object_id.
The long answer is that using mocks is a lot quicker to develop, easier, more straight forward and has faster run time than maintaining a real runnable copy of S3 that behaves the exact same as the real S3. With the fake S3 you're still spending CPU cycles inside your S3 client while it talks HTTP with your fake S3, which slows unit tests down a lot. Plus fake S3 may have slightly different behavior when your S3API library interacts with it, which could lead to really hard to track down bugs later on. Trusting your APIs is what unit testing is all about.
In my opinion, having to replicate S3 in development and test isn't the best idea. There are a few problems I see: You have tied yourself to S3's API, you must maintain this "other" S3 by making sure it behaves like the real S3 and your test and development code never actually hits the real API you're using...until staging or production.
There are a few better strategies I can see here:
1. For test, use something like VCR[1] to record real HTTP interactions with the real S3 API during first test runs, serialize them to disk, and then replay them later.
2. Go the more OO route and create an internal business object with a defined interface that handles persistance of your objects. You could have a S3Persister for production and staging, but then you can create a LocalDiskPersister or even MemoryPersister for tests. Hell, you can even keep your own S3 and create OurS3Persister as well. The main point here is that your application code is coded to one API/interface - the "persister" - and you can easily swap in different persisters for different reasons. All the individual persisters can then have their own tests that guarantee they adhere to to Persister interface and do their own individual things correctly.
3. Mock out the calls to your S3 library. It's the job of the library to provide an API interface for you as the application developer to S3, so you can mock out those API calls and trust the library works and is doing the right thing. Since you're mocking things out, you should still have integration tests with the real S3 to verify everything is working, but for quick unit tests mocking works great.
The blog post mentioned they had GB of data, so YMMV on these ideas, but these are strategies I and others have used in the past when dealing with APIs like S3 and they work great.
I think this article title is misleading. It's not 10 million hits a day on Wordpress, it's 10 million hits a day using Varnish to a single URL. Might as well say you can serve 10 million hits a day to a static file served out of memory.
If you know what these commands are doing under the covers, these commands are a true time saver. If you don't know what these commands are doing, they're basically "magic" and in the hands of inexperienced developers could be harmful to their education on Git.
> Too bad every generation has to rediscover all this stuff.
Even though this technique existed 30 years ago, doesn't mean that it's been recently "rediscovered" by the Ruby folks and excitedly implemented to the musings of, "how did we miss this technique?!?" There are likely lots of reasons why this wasn't used before. The abstract of their paper seems to shed some light on this:
[...]But Ruby interpreter runs on various platforms, and we do not have portable
memory allocation API to obtain aligned memory region without wasting region. In this paper, we propose portable scheme to map from object pointers to corresponding bitmap table
in constant time.[...]
I may be totally wrong, and the paper is entirely in Japanese, but I think there is more to it.
"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?