too lazy for blogging

I just spent quite some time on a “bug” in one of my migrations. Run after run, it failed to populate the database properly. Even after adding the obligatory

  MyModel.reset_column_information

But after checking the database carefully, I realized that some rows had the intended data, while others didn’t. Long story short: Don’t forget to reset the column information on all models which inherit from the base model. In my case it was something like:

  Account.reset_column_information
  Guest.reset_column_information
  User.reset_column_information

I would say that with Arel, rails is on the right track to get rid of the SQL statements. But there is still some work which needs to be done. Stuff like Model.where(:name => ‘My stuff’) is already working really smoothly. What I would love to see is an easier access to Arel’s operators such as eq and not_eq. It would be great if the where method would accept a block which provides access to the arel table. where{|t| t[:name].not_equal(‘my stuff’)}.

I guess I will look into this soon. But right now I have to finish the rails3 upgrade first :(

I just stumbled upon a post by JamisBuck about unobtrusive JavaScript. And while reading the post itself and the comments afterwards, it seems as if there are people out there who do not really like the idea of unobtrusive JavaScript.

After a short time of being shocked and thinking about the argument, I think I understand - although I do not agree. Saying that the JS code should go where it is actually needed or executed seems just plain wrong. It might seem ok in the beginning, but it never is. It is the same argument which might be used when talking about the styling of arguments. But if you came from a php background, then you might know why this can be really bad. If you encourage the people to put styling, logic, or code inline, they will do it. And they will do it a lot. I have seen projects where this gets very very messy.

Back in 2005, when I came across ruby and especially rubyonrails, it was the clear structure of code which make me abandon php almost instantly. And I guess it was the same when I really understood the concept of stylesheets. This clear separation of concerns:

• Data and structure belong into the html code
• Everything related to styling is to be found in the stylesheets
• And nowadays, client side logic belongs into javascript files

I could continue the list… the beauty of the separation regarding different clients and so on, but I guess this has been discussed often enough.

Regarding the changes which all rails developers are facing with the release of rails3.pre, I would say they are more than welcome. It is another dark corner which is finally getting some well deserved love. Especially as JS-frameworks are getting easier and more powerful every day. I would encourage everyone to checkout jQuery as it improved a lot with its last iteration to version 1.4. Especially with regard to events. Much easier, much more reliable and even more powerful. I still have to check the implementation of rails.js for jQuery, but i have not had a single problem so far.

I am wondering when and, more important, how the first larger applications will be ported to rails3. When I check my largest and most important project, I see a lot of gems and plugins which are not yet supported. For some of them there is not even the slightest note on any progress towards rails3 compatibility. I know, as a good citizen of the open source community, I should help and update them myself. But there are far too many. So I will be stuck with rails 2.3.5.

I guess I will fork and upgrade a few smaller projects as soon as there will be time again. But I wonder why the adoption path seems so slow. Or am I missing something?

I completly missed the introduction of as_json in rails 2.3.3. And I think I am not the only one, as the there are not many posts about that topic out there. Anyway, using as_json feels so much cleaner than overwriting to_json. And apart from that there is not much more which changes. In your controller you still specify something like

wants.js { render :json => @my_object.to_json }

but it will try to load the data from your models as_json method, in which you can just provide a hash. I really like it this way, as you can create really complex json responses with all the ruby features you love. And the best, it seems as the options which are passed to the to_json method are handed over to your as_json method as well. So custom configuration is not a problem.

The first day I managed to install the app and do some quick testing on the recently released beta. Everything seemed ok and kept working on my projects.

Three days later I started a project from scratch and directly jumped on the rails3 wagon. And I think I was instantly hooked. Man, this baby is sooooo much fun. Not only gem dependencies are finally working, but ActiveRecord with Arel is just amazing. It reminds me a lot of my .NET days ;)

And the best feature I have not yet mentioned! The speed. Everything is really fast and smooth. Running it locally in development mode is a real pleasure. Even on a dated white macbook, pages load even as if you are in production mode. Amazing.

So, why is it a pain in the ass?
Quite easy, I have to update all my projects to use rails3 in order to be able to deploy it to our production server. Passenger can handle only one rack version and while rails requires rack version 1.0.1, rails3beta requires 1.1.0 . What a pitty!

If your 2.3.5 start behaving strangely after installing rails3beta, it might be due to the I18n gem. Previous versions of rails came with an older packed version which was automatically loaded. Now with rails3 and 2.3.5 already, you can actually install the newer I18n gem yourself (and it actually gets loaded). So here is what you might wanna do:

• Update your application to work with the new I18n API (what I did)
• Require a specific older version of the gem (probably 0.2)
• Uninstall the gem (which will break your rails3beta)

I would recommend updating your applications. It was a bit of a hassle for me, but this way I can be sure to be on the right path for the future. Or who does not want to use this really beautiful new query API?

Update: Please take care the the I18n.l(input, :format => ‘identifier_string’) is not working anymore. Instead of passing a string to format you should use a symbol instead.