For our application that meant bringing 1 of 3 application servers down and slowing things down in general. So we're stuck with 3.0.5.
From what I understand the Rails community has declared 1.8.x as a thing of the past (tbf it IS a thing of the past. But in a non-perfect world migrations our not always easy). This may be a good thing (it forced us to march towards 1.9.2) but I'm sure it has caused a lot of problems.
Our best hires are friends of our employees. In fact it works so well when we want to hire someone we think of job ads as a waste of time. And there is some explanation to that:
Good employees (and you'll surely have one) have friends on the same level. If your company / environment / team is good then employees are happy and try to convince their friends to join so that they can work together. We have 17 employees and only 3 of them have been hired through job ads.
A long, long time ago I coded an MP3 implementation for a TI Fixed Point 16bit DSP@100MHz (family 5XXX IIRC).
I initially wrote it in floating point C (compiler translated float to fixed point) and it was damn slow.
I then rewrote everything to use fixed point arithmetic only and dropped down to about half a second of decoding for a second of data.
That wasn't still good enough because the DSP had to take care some other stuff like ide drives, dma, fat, dac, usb , display drivers etc, so I rewrote all critical parts in assembly taking advantage of the chip's build in dsp functionality and dropped to 100ms of decoding for 1s of data.
So it might be helpful to start from a pure python implementation then move your way down, you'll still learn a lot.
I thing there's an explanation to the NoSQL movement and why non-rdbms are gaining popularity these days.
Not a long time ago, if you had to handle 1 billion records then you were already big with piles of $ sitting beside you. Then you would just call Oracle or Greenplum (or whatever) and say "Hey, I've got some million $ here, care for it? I just want to be fast(tm)"
Lately it is quite possible to be small and forced to handle millions of records daily or struggle with new technologies that require less man power for development but need scaling a lot earlier (e.g Rails). You have limited resources and if you can get away with Tokyo Cabinet on a single machine instead of a 100k mysql cluster then you get to live longer.
As any new cool technology it'll get some hype and then fall back to being the right tool for the job. It's good to have some alternatives to RDBMS, some problems are really not relational.
The funny thing is that I like the guy. I like both of them. I don't think that they are great hackers, but I enjoy reading their blogs and I respect their efforts.
I also believe that StackOverflow is great. I tried contributing but almost always someone hits submit before I do so I gave up until I have more free time.
Sorry for not being politically correct, I thought this was HN.
"Joel boasts that for 1/10 the hardware they have performance comparable to similarly size sites. He wonders if these other sites have good programmers. Let's see how they did it and you be the judge."
Let me be the judge then.
For a site serving 13 million pageviews per month (80% of them are uncachable searches) we use 2 servers with about the same configuration (same memory, cpus). The database server has an average load of 1 and the application server (that is serving a bunch of other sites as well) is under 2 most of the day.
We have 1/2 of their capacity running an equally heavy site (all sites running on those servers make up 16-18 million pageviews per month). So if they run on 1/10 of similar sites, we run on 1/2 of their 1/10. Even better we pay 100% percent less of what they are paying. I wonder how smart Atwood is.
I don't intend to be a smart ass here. I would never say "Hey we run with 1/10 of your capacity, you are stupid" because performance heavily depends on the application. StackOverflow probably has a 90% cache hit ratio (86% of visitors are from google that land on some question asked some days or months ago). So 3 servers for a cache and forget site (logins and bits for pages that change often can be cached too) serving 16M pageviews per month is below average. They maybe doing a whole lot of other things in the backend that we don't know of , but the same goes for the other sites that "their programmers are stupid and use 10x hardware."
I would expect them to say what problems they solved and how instead of bragging about how awesome programmers they (he?) are.
For our application that meant bringing 1 of 3 application servers down and slowing things down in general. So we're stuck with 3.0.5.
From what I understand the Rails community has declared 1.8.x as a thing of the past (tbf it IS a thing of the past. But in a non-perfect world migrations our not always easy). This may be a good thing (it forced us to march towards 1.9.2) but I'm sure it has caused a lot of problems.