Hello there Rubyists.
Today I’ll be talking about introducing Ruby on Rails 3.0 thinking into your Ruby on Rails 2.x applications. In my humble opinion, with Ruby on Rails 3.0 on the horizon, every web developer programming web applications using our favorite framework should take into consideration learning new practices.
Frankly, between two version of Rails, 2.x and 3.0 you won’t find any fundamental philosophy differences. It’s still DRY, still REST. But there are some little changes as we may call it that are not compatible with old rails, and will give you deprecation warning for now and after some time they won’t work at all, if you try to use them in Ruby on Rails 3.0 web applications.
As I mentioned earlier in one of my posts, I am working at Selleo, and Selleo is in the process of moving from Ruby on Rails 2.3x to Ruby on Rails 3.0. There may be valid reason for a developer to still use Rails 2.x but there are no excuses if one is not making his Rails 2.x project Ruby on Rails 3.0 oriented. It costs you basically nothing as a developer and possible gains are priceless. Let’s discuss some of them:
First thing first: tests. Your Ruby on Rails application should be featured with both unit and integration tests. I know that some Rails developers have blood on their hands in this matter, I must admit, I belong to that group as well, since at the beginning of my Ruby on Rails developing career I didn’t write tests either. But trust me – it’s wrong, some extra time needed to cover your code in your Ruby on Rails project is worth the result of being able to add new features firmly in the stage of application life when the complexity factor is becoming significant one and in case of spoken framework upgrade – without test it is basically impossible to upgrade from Ruby on Rails 2.x to Ruby on Rails 3.0. So don’t even try it.
Second prerequisite for upgrading you Ruby on rails application is to make sure you’re using Ruby 1.8.7 or 1.9.2. RoR 3.0 is not working with either 1.9.1 or 1.8.6 versions. In Selleo we have chosen to develop with Ree (which stands for Ruby Enterprise Edition), since 1.9.2 is not production ready. If you’re being afraid that messing with your rubies will halt your development or raise various unpredictable issues then you should check out rvm which allows you to create multiple Ruby environments. If you’re fancy, you can have different environment for each of your Ruby on Rails projects.
Ok, after we have satisified our prerequisites we can focus on actual changes that will help making our Ruby on Rails project ready for 3.0.
So, let’s start with Bundler. Bundler is quite famous for itself, because it has been mentioned each time along with Ruby on Rails 3.0 beta releases, as a milestone change. Though, as a Ruby on rails developer you may leverage this new approach of managing gems and it’s dependencies in Rails 2.3x projects. You just need to override gem handling in your Ruby on Rails application. You can find more information on the official bundler site (which is http://gembundler.com/ ).
Second step is RJS -> UJS. You can find a nifty article about new unobtrusive approach with Javascript, here, at rubyonrailsdevelopment.pl, but to keep this article short, some helpers have been deprecated, and a whole idea of using Javascript is different, but there is a chance that this step does not applies to you – if you were not obtrusive with your Javascript in your Ruby on Rails applications.
Third, check your locale files for html code. Rails 3 escapes html by default, so use “_html”.
Fourth, small directory structure change of Rails applications – move your fixtures from test/fixtures to test/files if they are non-model fixtures.
Fifth, Metal abstraction has been removed from Ruby on Rails. Though if you were using Metal, then you’re prolly know how to help yourself.
Sixth, Ryan Bates in one of his railscasts (episode 211) demonstrates how to writecustom error_messages partial. You may use his technique, since error_message_for and error_message_on along with other helpers have been removed from Rails
The above is a “must do”, for a Ruby on rails developer if he want to be prepared for Ruby on Rails 3.0 Though there are some ‘should do’ that I am going to describe in another article. These ‘should do’ won’t crash your application, but for now will complain with deprecation warning.
August 26th, 2010 on 12:59
A+ would read again