Road Map: The rails leading to 1.0

Rails is already an incredibly capable environment, but we’re still not quite ready to slap on the 1.0 sticker according to my own standards for that label. So what’s missing? Here’s a list of the major achievements that I want to see happen before we go to the big one-o:

  • Directions: While its fully possible to do intricate custom URL layouts, its not as easy as it could be. The combination of mod_rewrite going in and the hoops you need to jump going out ensures that most people just stick with the defaults. Directions is the path that’ll rectify that by pulling URL rewriting into Rails, so WEBrick and Apache will share the same format and it’ll be possible to handle both in and out in a coherent fashion. Nicholas Seckar is leading a development effort guided by a design from Dave Thomas.
  • Packaging: Instiki has had great success with the OS X native .app format. We want to enable all Rails applications to have push-button package outputs to .app, .exe, and one-file scripts for the rest of ‘nix. The rise of SQLite3 will make this even easier (thanks to Jeremy Kemper for the adapter and Jamis Buck for the bindings) to have self-contained applications. Marcel Molina is leading the development on the one-file scripts that’ll serve as the foundation for the native compilations.
  • Web Service Dispatcher: XML-RPC and SOAP could easily be supported by the same controllers and models as the rest of the application if the calls were translated into controller calls. That’s what the new WebServiceDispatchers will do.
  • Caching & Performance: One of the easiest ways to deal with performance is to start caching, so that’s what we’ll do. There’s a lot of different schemes to pursue and that’s exactly what we’ll do. From full-page caching that sidesteps Rails to per-request model caching to integration with MemCached. Lots of opportunities to take what’s already there and make it much faster with a bit of sprinkled caching. Getting a good benchmarking suite together is part of that. Florian Weber has promised us the later since 0.7, so he expect a delivery any day now :)
  • Documentation: I really do need to fulfill my obligation to renew the introduction video and accompany it with more. On top of that, we’ll need to start the long rumored Rails User Manual. We’re already off to a fantastic start, though, with great API documentation and quite a few guides and tutorials. The last push will round off the polished feel a lot, though.

Five major areas of improvement. I hope we’re able to reach all of these goals by mid February or early March. But there’s no inherent pressure. We’ll continue to release updates at the current staggering rate and when its ready to ring the bell of 1.0, we’ll ring the bell.

SoapBX: Presentations powered by S5, Textile, Rails

Pelle Braendgaard just launched and announced a new free Rails service entitled SoapBX that let’s you use a combination of Textile and S5 to forget about Powerpoint and Keynote:

About the development of SoapBX using Rails, Pelle writes:

I got an idea less than two weeks ago and now as a testament to the
power of Rails I have released the first initial beta version of
SoapBx, with less than 20 hours of programming involved so far.

Congratulations on the launch, Pelle!

Brian discovers the default logging goodness

Brian McCallister started working on a new Rails application and discovered the goodness that is the default logging setup:

This is sort of what using Rails is mostly like. You stumble on a really nice gem — the default logging giving you a breakdown of execution times, translating it to requests per second, giving you any sql, execution times on the sql, etc. Oh yeah, nicely color coding and bolding as well. Then you stumble on another gem. It feels like programming in ruby, where things surprise you by being just really well done, and easier than expected.

It is indeed a powerful tool to have a tail running on while developing as you get an early warning system for performance problems and a minds eye into the internals of the system.

Using the Rails to impress potential employers

Drew McLellan is looking for a job and what better way to demonstrate to potential employers than to show you’re keeping up with the field of web development:

I like to work on the edge and am frequently updating my skills. Right now I’m learning Ruby with the aim of doing some work using the Rails framework in the near future. Learning new things opens your mind to possibilities, and more possibilities lead to better solutions.

With jobs being outsourced left and right, perhaps its also time for you to demonstrate why you’re not just yet another mainstream developer chasing the same Java, .NET, or PHP jobs as everyone else. Stand out from the crowd.

Ruby on the German Rails

I love picking up Rails praise in a foreign language through the wonder that is Google Translate:

…within fewer days it was my small Webapp finished and I a realization enrich: I like Python still rather than Ruby, but Rails rockt without end!

And even if David evangelisiert sometimes somewhat too much , then he is right nevertheless nearly always :)

Because with Ruby on Rails I had to have developed first time fun a Web application and to have written also the feeling somewhat elegant and none dirty PHP chopping.

Thanks for the kind words, Florian Munz. I apologies for publishing your words in a much “gebrochen” English. If you’re fluent in the language of commands, you’d probably prefer the un-mangled German original.

UPDATE: More German praise from Mornography: “Ich hab’ Spaß”.

Rails 0.9.3: Optimistic locking, dynamic finders, 1.8.2

Rails is now fully compatible with Ruby 1.8.2, which we advice all to upgrade to as soon as possible. It contains a year’s worth of bug fixes for Ruby, so it’s great finally to be able to use the new version with Rails. But that is not all we got in store for 0.9.3. A few of the highlights are:

  • Automated optimistic locking: Just add the field lock_version to your table and the associated class will be governed by optimistic locking that’ll raise an exception if a stale object attempts to save.
  • Dynamic finders: Finders like Person.find_by_user_name, Payment.find_by_amount, and even Person.find_by_user_name_and_password are now available with no code at all. Any column can be used and combined with other columns in the new dynamic finders.
  • MS SQL Server and DB2: Active Record now supports both Microsoft SQL Server (through ADO) and IBM’s DB2 databases.
  • MemCacheStore for sessions: You can now store sessions in Action Pack using Danga’s memcache technology.
  • Generators guard against reserved words: Not only will ./script/generate model Thread be denied, you’ll also get a list of synonyms pulled live from WordNet!

That’s just a small taste of the 35 changes, fixes, and features introduced with Rails 0.9.3. You can read the full story in the changelogs for Active Record, Action Pack, and Rails.

Upgrading from Rails 0.9.2 to 0.9.3

There’s only one change you need to make in order to have your application updated from 0.9.2 to 0.9.3. In the config/environments/production.rb and config/environments/test.rb, you need to change:

  ActionController::Base.reload_dependencies = false
  ActiveRecord::Base.reload_associations     = false


Dependencies.mechanism = :require

And in config/environments/development.rb, you need to change:

  ActionController::Base.reload_dependencies = true
  ActiveRecord::Base.reload_associations     = true


Dependencies.mechanism = :load

If you’re coming on from 0.8.x, you’ll need to go through the Upgrading to 0.9 manual.

43things in 5,204 lines of Ruby on Rails

Eric Hodel was so kind as to show me the output of rake stats on 43things and it revealed that it took 5,204 lines of Ruby to create the current version. That’s pretty darn amazing considering they’re not even taking full advantage of the huge array of improvements in Rails 0.9.x and that the team consists of three out of four programmers new to Ruby.

Another round of applauds to the team at The Robot Co-op for creating such an interesting application in so few lines. Kudos!

Are you watching the health of your software?

Kent Beck has probably been more responsible for the uptake of automated testing amongst the general developer population than any other figure over the last five years. One of the reasons is that he’s such a great speaker and writer that you can’t help but paying attention. Another, of course, is that automated testing is naturally a Good Thing to do, so it shouldn’t be such a hard sell.

Anyway, as the second edition of his Extreme Programming Explained is hitting the street, Kent has broadened his focus from just testing to the concept of software health. It’s not just about passing the tests today, it’s about being in a position that allows you to pass the test tomorrow too.

He talks at length about this and other great metaphors in an IT Conversations recording called Developer Testing. It’s about one hour of Kent’s thoughts. For free. So what are you waiting for?

When you come back, all energized with a strong desire to improve the health of your software, do check out Steve Kellock’s A Guide to Testing the Rails. Rails is uniquely supportive of getting your test game on with the least amount of configuration or even learning. For all the controllers and models generated, you already have test suites waiting for test cases to enter. And running rake will execute the whole lot of them.

If you do need a bit more assistance in exactly how you should do testing, and especially unit testing, I can heartily recommend the Pragmatic Unit Testing book by Andy Hunt and Dave Thomas. It’s available in both a Java and C# flavor, but don’t let that scare you off, pretty much all of the meaningful lessons apply directly to any environment. Combined with Steve’s guide, you should be all set.

As a rule of thumb, you want your rake stats to report that you have a 1:1 ration between code and tests.

Watch for huge requests on default FCGI

As you might have noticed, 43things have been down for the count a few times since launch with nasty 500’s. The cause was the combination of default FCGI settings and a bad-ass RSS query that pulled out everything from the system at once and took up a couple of pages in the log.

That action couldn’t be rendered within the 30 second limit that FCGI imposes by default, so Apache suspended the connection to FCGI and caused hits to that particular FCGI process to go out of commission.

Lessons learned…

  1. Make sure you don’t have any actions that take longer than the timeout limit in FCGI
  2. Increase the default timeout limit if you have actions that you expect to take close to 30 seconds or more