Five things I like about WebROaR
Posted by Sam
WebROaR was announced a couple of days ago but somehow I missed the announcement. The more I look it over the more I like it so I thought I'd put together a list of five things I really like about it.
- Deploying a new application or taking down an application doesn't require a server restart. This is important when you have many apps running because it takes a while to fire those applications up again.
- Integrated stats! This is similar to what you get with New Relic.
- Exception tracking built into the app server! No longer do you need to remember to use ExceptionNotifier or other such plugins.
- Minimum workers! No longer do you have to wait 15 seconds for your app to load because the app server unloaded your site due to inactivity. I hear this is coming Phusion 3 but this is important for sites that aren't terribly busy.
- The admin interface!
And now for three things I'd like them to add.
- Multiple users. It looks like you could manually add users to a file but it should be doable through the admin interface as well.
- Restful interface. Call me picky but I'd like to see a RESTful interface for sites, users, stats, etc...
- iPhone interface. I know we don't NEED an iPhone interface but it would be nice, especially for those of us still on the Edge network.
Overall I really like where they are going with it. If they continue down the road they are heading down I think they'll have one of the best app servers for any language. Peaking at their code though it looks like they've got a ways to go, but for an initial release I definitely like where their head's at.
Tags: rubyonrails webroar
New Augmented Reality site launched
Posted by Sam
I've been hard at work (in the off hours) on a side project with a few other folks. It's really starting to come together, but it's very early on yet. If you are interested in augmented reality then you should check out Shimmerbeam. Keep in mind it's a long ways from finished but it's already a fun way to inject yourself into augmented reality. And it's one of the more interesting things I've coded in a while. If you have any suggestions on how to make it better feel free to post them in the comments!
For the technical folks the entire site is built on Ruby on Rails, RMagick, Prawn and PostgreSQL and so far the whole thing is written in less than 1,100 lines of code! Once I get rid of the controller logic in Rails 3 it will be even less code. Check out the site... go... now!
Tags: augmentedreality rubyonrails
The Last Word on Rails Scaling
Posted by Sam
Ok, I have to admit that I'm getting a bit tired of all the Rails scaling questions. People seem to think that's Twitter's scaling problems are Rail's scaling problems. They aren't. Twitter's scaling problems do not equal Rails scaling problems or to put it more succinctly Twitter's scaling problems != Rails scaling problems. Rather than try and convince people that Rails can scale I'm just going to include a couple of stories about large companies that have scaled Rails to Billions of page views a month. Will this finally convince people that Rails scales?
Our first Rails app that scales is brought to us by AT&T. Yellowpages.com was rewritten from a Java app to a Rails app. It serves over 1.4 billion requests a month using 25 servers per data center. That's only 4 more servers than it was using while running under Java. The Java code base weighed in at 125k lines of code while the Rails code base came in at under 20k lines of code, including tests. The much larger Java code base didn't include any tests. The entire site was coded with at most five developers over a three month period. One thing that really stands out with Rails site is the maintainability. As a developer would you rather jump into and maintain a site with 125k lines of code or less than 20k lines of code? Over the life of the site AT&T might spend a couple extra grand on servers, but they will more than make it up by having less developers and getting new developers up to speed much quicker! And do you think there are more bugs and security issues hiding in 125k lines of code or in way less than 20k? If you want to look at more details you can check out this presentation from Rails Conf 2008.
Our next app is brought to us by LinkedIn. LinkedIn built a Facebook app called Bumpersticker that handles 1 billion page views monthly and around 100TB of data each month. This app is obviously also built on Ruby on Rails otherwise I wouldn't be including it here. ZDNet has a write up and there's also a video that looks to be from Joyent. This story isn't as interesting as the Yellowpages.com story because it wasn't a rewrite and it's harder to see the benefits of using Rails as compared to a traditional environment like ASP.Net or Java but I'm including it to point out that you can get the advantages of a great framework, cut development time and costs and still scale out to a billion page views a month.
So that's it. Can we please stop asking if Rails can scale and stop using these horribly outdated technologies like Java and .Net? Please? Pretty please?
Tags: rubyonrails
Images Belong in the Database
Posted by Sam
Logical Reasons
The more web programming and system administration I do the more I'm convinced that images and other forms of uploaded content belong in the database. I've pretty strongly suspected this for many a years but it's becoming more and more clear that this is just how things need to be. There are many reasons. Some are technical and some are logical, but all signs point to loading images in the database. Below are just a couple.
I'll start with the logical reason first and then get to the technical reasons. Logically all other forms of dynamic content will reside in the database yet programmer after programmer insists on putting images and other uploaded content on the filesystem. Now you've got some content in the database and it's tied to content on the filesystem. Suddenly the nice clean line is broken. You've blurred the lines on who does what and where it goes. What usually happens is programmers forget to clean up after themselves so files references are deleted in the database but still exist on the file system. You know why this happens? Because you shouldn't have put it there in the first place. Repeat after me - dynamic content in the database and application files in the filesystem. Got it?
Technical Reasons
So know that we've got the logical reasons behind us what are some of the technical reasons? For starters your database(s) will always be in sync. That's what they are meant to do. That's what they have to do. Your database(s) have to be synchronized. Your site depends on it. It doesn't matter if it's a simple site with a single database server or a huge site with a dozen database servers. You have to keep your database servers in sync. And databases are good at it. It's much much easier to scale out database servers than file servers. Having all your dynamic content in the database keeps everything in sync.
Some people will wrongly argue that having files in the database will cause slowdowns. To that I say....um maybe, but only if you're doing it wrong. Databases are very fast and have excellent caching but it's highly likely that multiple web servers can server images straight from disk faster than a database. Well that's great, but images still belong in the database. And in this case you can have your cake and eat it too. Check out this article about caching images on the file system with Rails. Hrm, one extra line of code lets you cache your image on the file system. Doesn't seem to bad to me. Elegant, simple and lightning fast.
The Reason for the Rant
Time after time I'm responsible for deploying other people's crappy software. They invariably come up with some stupid solution that lets them click the checkbox that says their product will work on a load balancer, but they neglect to tell you upfront what ridiculous hoops you have to jump through to get it work. The most recent product is called Ektron. I can't say what it's like to work with from a programming stand point but from an admin stand point it's a nightmare. Instead of loading the images in the database like they should they instead force you to share out files and do this dumb little virtual directory linking to the other servers. It's just annoying and not even close to elegant, but then I have yet to see a CMS system that is so I wasn't surprised. Thankfully the Ruby on Rails team understands what it takes to scale apps and they provide you with a nice foundation. If only the rest of the world would catch up.
Tags: rubyonrails web rant
Engine Yard to Create mod_rubinius
Posted by Sam
In a previous blog I posted a rebuttal of sorts against the DreamHost whine fest. Well at least that's how I saw their blog. The arguments spilled over to a another blog posted on Ruby Inside. One of the points that I took issue with was DreamHost saying that the Ruby on Rails folks needed to step up and create something that DreamHost could resell. In their words:
4. Officially support shared hosting environments.Alastair and I are in agreement that there is already a great way to deploy Rails applications and it is not Mongrel and [insert favorite web server/proxy solution here]. LiteSpeed is light years of ahead of everybody else in Rails support and deployment and it's also much, much faster than Apache in general. But in all honesty the bigger issue here was that I feel like DreamHost needs to step up and put their money where their mouth is. They are making money on hosting not the Ruby on Rails developers. If they want to make money on Ruby on Rails hosting then they should step up and create a solution.
Well it appears I wasn't the only one who felt the same way. Yesterday, the folks at Engine Yard announced that they hired a developer to work on mod_rubinius. Rubinius is a very promising Ruby implementation that is gaining a lot of momentum and Engine Yard is backing it with the hiring of several developers. It's been written about plenty on the web but it's nice to see that a hosting company that is making money from Rails hosting is actually putting it's money where it's mouth is instead of just expecting everybody else to do their work for free and let them reap the benefits.
I couldn't be happier deploying Rails apps on LiteSpeed, but I always welcome alternatives. So well done Engine Yard!
Tags: rubyonrails