Archive for the ‘fads’ Category

Twitter flies off the rails

Thursday, May 1st, 2008

According to noted internet pundit Arrington twitter has made the call to rewrite and move off ruby on rails. Not really a shock, rails is fundamentally not going to scale up past a certain point.

The uncharitable part of me (and the part that is confident nobody reads this blog) thinks that the vast majority of rails developers have never been around the kind of scale we’re talking about when we say rails doesn’t scale. Especially when I see something like this:
Image from a slide show: Scaling rails is easy

I love that items 2, 4 and 5 are REALLY REALLY hard.

More likely though those developers haven’t faced an app that is particularly hard to scale. I think the issue is less “does my framework scale” and more “is my application going to be hard to scale”.

Twitter is a great example of the kind of app that is very hard to scale, regardless of the platform. Rails is probably not the culprit here, but I doubt it is helping at all. In fact, at this point I would suspect twitter will do what everyone ends up doing when this happens: php frontend talking to a web service driven by java (or c). Because it turns out when the problems get real hard you don’t want a scripting language to handle them.

Rails isn’t bad, but it is isn’t “easy” to scale, except in cases where the application is easy to scale (content). Rails is designed by small, custom app developers for small developers. It provides one major benefit: it makes it faster to develop a certain class of applications. Thats it. So if time is money (you are a small dev shop) rails will make you money. Otherwise rails give you very little. I don’t think it would be a bad choice for most apps, but I don’t think its the panacea many rails advocates would claim.

Your Favorite Language Sucks

Saturday, April 19th, 2008

I’ve noticed at the few events I go to that have a lot of consultants running around that the de-facto standard for freelance developers has become Ruby on Rails. I think this is very sensible actually, because Rails was written by and for these kinds of people, where getting something that works well enough running in the shortest amount of time possible is the name of the game. Rails (and the subset of ruby rails uses) has also exposed a lot of people to objected oriented concepts that have been around for a while. And the rails implementation is a really good one to wrap your brain around how and why object oriented design is useful.

That said, the one thing that annoys me about this whole thing (and a lot of the webdev blogosphere) is that a vocal subset of rails people are religious about it. They like to come into any situation and immediately begin advocating for why rails is magic and should be adopted for everything. This of course has nothing to do with rails itself, which as far as I can tell never claims to be anything other than what it is: a rapid application development framework. By rights it should be putting the competition (mostly .net) out of business: its probably the best RAD framework out there. But it isn’t good for everything.

Backend work at yahoo tends to be written in c++ or java. Much more time consuming for development, but necessary to support the kind of scale our applications need. Frontend work is done in php, but not because php is super-awesome. Rather, php is easily extended with compiled extensions, is quite fast and flexible for the front end and is easy enough for experienced developers to get up to speed with.

There have been some attempts to get rails going at yahoo, with mixed results. The fact is that for a company with thousands of developers, a robust platform and massive scale rails doesn’t have much to offer. That’s because its the wrong tool for the job. Not because it is the sux0rz, or because php/java is the roxorz. Its because any competent developer should be able to get the job done in any language, provided its the right tool for the situation.

If you need to write a run of the mill database-driven application and get it done yesterday, rails is the tool for you. If you have microsoft servers and need to do the same, asp.net is probably the tool for you. If you have microsoft servers, lot of time and expertise you should probably through out the asp.net framework and write your own thing in c# for the .net run time. If you are yahoo, google, amazon or aspire to be you should decouple your frontend from your backend, write your front end in a nice template-focused language like PHP or python and design a nice REST interface for the backend, implented however (even rails if you like) with the understanding that as you grow you might need to replace the backend.

At least, thats my opinion. Others have succeeded with any old stack. Wikipedia is pure LAMP, amazon is JSP on the frontend and twitter runs on rails. That’s probably strong evidence that it doesn’t even matter that much what you use, as long as you design the thing to solve your problem. The rest is just details.

What were they thinking?

Wednesday, September 19th, 2007

Google Maps traffic is really nice. I love the time estimates that take traffic into account. BUT why, why did they decide to use green/yellow/red/black? To those of us (a sizable percentage of men) with red/green color blindness it is very difficult to tell (especially on a mobile device in sunlight) the difference between green red and black. (yahoo maps does the same thing, except with those little circles, for me the red and green look the same). There must be a better way.

Here here

Thursday, August 23rd, 2007

The iphone is not breaking the web. As Joe Hewitt notes, the “iphone only” sites are raising the bar for mobile web apps. As other devices catch up with apple everyone will benefit.

Twitter

Tuesday, August 21st, 2007

I just got an account…and the service is down. Its a strange thing about downtime. Around here downtime is the sort of thing that sends people in to a blind panic an for that reason it almost never happens. Complete downtime with cute messages is unheard of (except for flickr occasionally). I suppose that is a function of having lots of infrastructure and ops people to handle graceful failover.