I spent last week at RailsConf 2009 in Las Vegas representing the IronRuby team. I gave a talk there titled IronRuby on Rails, and spent the 45 minutes talking about the benefits of IronRuby running Rails, or any other Ruby web framework, can provide. This write-up will walk through the four sections of the talk:
- IronRuby on Rails
- Deploying on IIS
- IronRuby ASP.NET MVC
- Project status and roadmap
Last year, IronRuby was much like this sprout; much of the plumbing was there (xylem and phloem, if you will =P), but it has only just begun to be useful, like running Rails.
Quickly we learned that growing up is hard to do. As IronRuby was dispatching it’s first Rails request for RailsConf 2008, it began to experience all the stresses of the outside world, like loading activesupport on startup, which loads almost everything in the Ruby standard library.
The good news is that IronRuby is maturing; meaningfully interacting with the world around it, and begin to get good at things. Startup has much improved, and can run real Ruby programs like Rails, RubyGems, Rake, and Sinatra (to name only a few relevant apps).
IronRuby’s real world, the .NET framework, is different environment than the usual Ruby developer is used to, but IronRuby bridges the gap to bring the .NET framework to Ruby developers. An example of this is deploying Ruby web applications just like other .NET framework web applications using IIS.
Due to running real Ruby applications, and playing nice with .NET, people are starting to notice us. Community involvement is starting to pick up, and we’re getting closer to being a “real Ruby implementation”.
IronRuby running Rails is not new, but doing it well or completely – is. IronRuby can now run real Rails applications, rather than just toy-hello-world examples. This does not mean IronRuby on Rails is ready for production, but it’s a great measure of forward progress.
We’ve been tracking our Rails progress by running though all the different Rails development scenarios, like migrating a database, generating a model, etc. The Rails documentation page on the IronRuby website walks through setting up IronRuby to run Rails, and shows the various scenarios in action, as well as how to run the Rails test suite.
Rails is not the only thing IronRuby is tracking; we’re running RubyGems, Rake, Sinatra, Rack, and a bunch more ever-increasing Ruby libraries to catch bugs, find performance issues, and use their test-suites to gather more metrics on IronRuby’s completeness. For example, the Sinatra-basesd ironruby.info website runs perfectly well on IronRuby:
ActiveRecord is useful outside Rails, and especially to a .NET developer for interacting with SQLServer. Using Ruby to manage the evolution of a schema through migrations is extremely simple and takes the pain out of doing database development. This is an example of a migration which adds a “people” table (and knows how to undo itself).
Once your database is created by the above migration, you can fetch and manipulate the data inside of a Ruby REPL:
Also, using ActiveRecord in a desktop application is pretty straight-forward. The following is an WinForms application which databinds an DataGrid to the ActiveRecord “Person” class.
Being able to run real Ruby applications is great, but what about deploying them? Most Ruby apps are web-based, so in this case deployment means getting the application on a production web-server and database server. The database server is already covered by SQLServer, so wouldn’t it be great to use IIS as the web-server?
Of course ...
Rack is a Ruby web-server interface which almost all Ruby web frameworks build on-top of, like Rails, Sinatra, and Camping. This package enables and Rack-based Ruby application to run on IIS. Today this is only possible for Ruby applications through FCGI, where this implementation integrates directly with ASP.NET (through a HttpHandler), so your application will be “running” whenever IIS is.
If your organization already has an IIS knowledgebase, you probably want to utilize it. Deploying this way requires no retraining, as this solution is purely ASP.NET based; no throwing away of experience. It’s also a great way to sneak Ruby into your organization.
This project is fairly new, so if you want to use it please let me know and I help with any issues.
Another way to get a Ruby web application running on .NET is to use ASP.NET directly. While there is no IronRuby support for ASP.NET WebForms (IronRuby in .aspx pages), IronRuby does have support for building ASP.NET MVC applications.
As IronRuby is maturing, more and more people are noticing it and (more importantly) using it. Special thanks to the more consistent contributors:
They either contribute C# code to the IronRuby codebase, documentation on http://ironruby.net and http://wiki.github.com/ironruby/ironruby, or the general ecosystem with active blogs, speaking at user groups, or new projects based on IronRuby. More information about contributing to IronRuby can be found at http://wiki.github.com/ironruby/ironruby/contributing.
To get all contributor projects, check out the ironruby-contrib project
IronRuby will be tracking performance and compatibility as it gets closer to 1.0. With 84% total compatibility on RubySpec, focus is being put on running real apps’ test-suites. Startup performance has also been a focus of improvement as of late, and by building an adaptive interpreter/compiler (like IronPython now has) Rails startup time decreased from about 85 to 30 seconds, without sacrificing startup time! Keep an eye on http://ironruby.info for updates to these types of stats.
Lastly, a little bit after this post is published ironruby-0.5 will be released. Please give it a try and submit any bugs you find to Codeplex.