I still don’t get the fascination with Ruby on Rails
Blogging live from BarcampSheffield where the technology of the minute still seems to be Ruby on Rails. I detest RoR.
RoR is offered as a platform that is quick to scale, because the framework that it sits upon can be scaled horizontally. This means that when you run out of capacity for your application, you can drop another identically configured box in to the cluster. This really isn’t the case, even for companies who have lots of VC cash to burn through. If you colo in a typical London Datacentre, you will typically only be allowed to draw 8A of current. A modern ‘enterprise’ server has a significant power draw, so you don’t get to keep adding boxes.
You also can’t just keep ordering power feeds, as even if the Datacentre owner will let you, you still need to deal with excess heat.
Scaling does not mean “Allows you to throw money at the problem”, it means “Can deal with workload”.
The RoR ‘Live’ demonstration was being developed on a 1.2GHz laptop, and had one user at the start (the demonstrator). The guy needed to apologise for the poor performance of the application! For anyone trying to solve the problem of scale, I repeat the advice I always offer in person - checkout mod_perl. When you can design your application to run as Apache modules, you will find you can deal with workload much more effectively (read: quickly!) than by buying lots of kit. When you want to scale horizontally (as, actually, you should for redundancy), you still can, it’s just a case of managing sessions.
Anyway, Barcamp has been very useful. Check out the Barcamp photos on flickr. No idea who set out to embarrass Plusnet (the hosts) following news last week.. :-)
Posted: May 26th, 2007 under Sys Admin, The 'net, networking.
Comments: 7
7 Responses to “I still don’t get the fascination with Ruby on Rails”
Write a comment
You must be logged in to post a comment.
Related articles
- Mac VNC Client for Linux KVM (March 30th, 2008)
- Internationalisation of DNS continues (February 8th, 2008)
- Text editors to be placed on endangered species list (January 21st, 2008)
- If VoIP kills phreaking, who are tomorrow’s engineers? (October 29th, 2007)
- Making the right ipv6 noises (October 25th, 2007)
May 27th, 2007 at 7:01 pm
To be fair Andy, the same comments could aimed at any system that you don’t design properly, it’s not just down to a flaw in Ruby or Rails.
May 28th, 2007 at 4:51 pm
This comment was passed to me by Adam Bardsley, the demonstrator
I was going to explain in a comment that the laptop is not only a 1.2Gz but it is also very old and and takes a good minute just to run the java eclipse editor. I wouldn’t use this as an argument that says java is good enough for serious use :)
May 28th, 2007 at 4:55 pm
Thanks for writing. The first thing I want to say is that I enjoyed your demonstration and was impressed with the web-app that you wrote in double quick time.
My opinion is that :
Good to meet you yesterday.
May 29th, 2007 at 8:35 am
Rails does indeed add an overhead but you eight that against the amount of flexibility, productivity and quailty of code you can create. I actually regret the demo only really showed how quickly you can do things rather than foxussing on the clever programming tactics you can use to make very easily understandable code.
On the performance side people are actually working on an event based proxy that should massively increase speed as well as adding flexibilty to your scallinbg solution : http://swiftiply.swiftcore.org/ for anyone whose interested
May 29th, 2007 at 9:43 am
Talk of performance weighted against flexibility, productivity or code quality is a specious argument. You can write good or bad code in any language, though I’ll concede that some (PHP) tend more one way than the other. Similarly, flexibility and productivity are features of the programmer, not the language.
It is interesting that you mention the “clever programming tactics” that ostensibly make Ruby more understandable. It is nice that some of what makes Perl great has made it in there, but therein lies the problem.
One of the primary criticisms levelled against Perl is that too many people use clever tricks that are infinitely more readable to them, but only serve to obfuscate for other programmers. Cleverness, when applied to programming, isn’t always all it’s cracked up to be. Elegance is a far greater substitute:
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan
As a final point, I would suggest that better (or at least less painful) integration of Ruby and Apache would be a better long term performance (and security, and configurability) gain than adding another layer to the stack.
May 29th, 2007 at 7:05 pm
Adam Bardsley wrote:
[…] but you eight that […] foxussing […] your scallinbg solution […] anyone whose interested
Are you drunk?
August 2nd, 2007 at 12:00 pm
Sorry to comment on an old post like this, but the RoR craze worries and annoys me too. It seems no real thought has been given to what happens when the application is built - sure it speeds up development but an application does not stop existing when development is finished
* There are maintenance issues caused by all the ‘magic’ - I am of the opinion that to be a good developer you need to understand what happens in an application at a low level so optimisations can be targeted where required. Ruby seems to encourage abstraction and this can lead to scant regard being paid to sensible database design and unnecessary bloat.
* Hosting / Server Admin is a hit and miss affair - early RoR evangelists sung the praises of fastcgi which I have found to be like plain old cgi but patched up with speed-laced chewing gum. Then there are things like lighttpd and WEbrick, the latter is too small and the former unreliable. I have been pointed in the direction of NGINX but am a bit wary of it. So I have settled for my current preferred solution of Apache 2.2 with mod_proxy_balancer as a front to a mongrel_cluster - I have yet to test this in anger but it at least uses a known application at the front end. It seems odd to me though that what is bandied about by the developer crowd as a fantastically elegant solution generates applications destined to live out their lives in what can best be described as a compromise.
I find it a bit like someone coming up with a fantastic new way to build a car really quickly and ignoring the fact they are completely un-drivable. Maybe I am missing a trick, but surely a decent mod_ruby can’t be too hard to come up with?