Since we’ve come up with I18n, that single “Ruby gem to rule them all”, we’ve always said we wanted new functionality to be tried out in plugin-land, giving it a good round of battle-testing and discussion. We also said we’d plan for another “round” of evaluating these things and considering to include them to I18n itself.

The I18n gem has probably been in production for long enough that we can be sure the API works well enough. Also, in release 0.2.0 internals were cleaned up quite a bit and the API has further consolidated.

So, my feeling is that we can start moving things to I18n that have proven useful in plugin-land – reviewing and reassessing their implementation and sticking to a modular design.

Here’s an overview of a few recent changes to the I18n gem library following these considerations.

Ripper is a Ruby parser that ships with Ruby 1.9. Ripper2Ruby is a library that generates a representation of Ruby code which you can modify and/or compile back to Ruby.

When it comes to selecting a fullfledged Internationalization solutions for a Ruby on Rails application Globalize has always been amongst the first choices. Shipping with “batteries included”, solid support for Model translations and everything stored to the database it was an obvious pick in many project environments.

On the other hand Globalize had some problems like the fact that it actually limited the set of ActiveRecord features one could use for translated models, its original choice to use default strings as keys and the mere size of its shipped data – something that sparked the development of several other Rails I18n solutions announcing themselves as way more lightweight and down to the basics.

Now with the introduction of the new I18n API to Ruby on Rails (which will be released with Rails 2.2 pretty soon) this landscape has changed. Future solutions will comply with and build on this API and therefor can be made much more modular, exchangeable and lightweight.

We’re happy to announce Globalize2 as the first fullfledged I18n solution for Ruby on Rails compatible with the new I18n API.

Future versions of Rails will ship with a minimalistic, yet powerful I18n/L10n api baked in.

The following post is about technical api and implementation details. You can read more about the motivation and reasoning behind this work here.

So, it’s getting real. Our changes to Rails have been merged back into master and will be released with Rails 2.2.

We’ve started this project in September 07. A couple of I18n plugin developers gathered to implement a Rails core patch which should make our lifes easier. We agreed on the following goal:

“Our goal with this work is to eliminate the need for monkey patching Rails in order to internationalize an application. We want to achieve this by implementing a minimal, common I18n API that can be leveraged by all I18n/L10n solutions.”

For a spam protection feature in a project I’m currently working on I started out specifying the behaviour of a filter chain that I was planning to implement. Specifically, I wanted to specify that the filter chain would call the filters in the expected order.

Looking at the RSpec documentation for expecting method calls on mock objects I didn’t found this usecase mentioned at first. It turns out to be pretty easy with RSpec mocks though.

#should_receive takes a block that (according to the documentation) is meant to be used to compute return values. This block is called within the specification’s scope so it can be used to track the method call order.

My initial spec looks like this (simplified for clarity):

it "runs the filters in the correct order" do
  log = []
  @default.should_receive(:run){ log << :default }
  @akismet.should_receive(:run){ log << :akismet }
  @defensio.should_receive(:run){ log << :defensio }
  @chain.run
  log.should == [:default, :akismet, :defensio]
end

Update

After some discussion on the RSpec users mailinglist Ashley Moran pointed out a more elegant solution to this which also uses the should_receive block:

it "runs the filters in the correct order" do
@default.should_receive(:run) do
  @akismet.should_receive(:run) do
    @defensio.should_receive(:run)
  end
end
@chain.run
end

Thanks :)

Just some quick notes about the safemode library I’ve been working on with the help of Peter Cooper recently. Rather than starting out with a Haml specific library Peter suggested turning this into a more widely usable tool and hacked his way to make it eat plain Ruby code as well as ERB.

Since I’ve cleaned up things a bit and started working on a Rails ActionView ERB handler so one could transparently use this library when rendering ERB templates with ActionView. Yesterday I’ve managed to render a blog index page (which I used as a sample app) through this handler for the first time.

For my intial speculations about the feasibility of a Haml safemode as an alternative for Liquid I got a bold 'No!'.sub(/o/){|c| c * 46} by Ryan Davis. Ouch! Also, Peter Cooper initially commented rather sceptically …

You guys were right that my first thoughts didn’t go far enough with just looking for certain syntax node types. But hey! There’s still hope. :)

In the meantime I’ve implemented an experimental attemp on a safemode plugin for Haml which takes a bit different approach and certainly does more to get its job done better.

Ok, this is really a looong lasting itch of mine I wanted to scratch ever since I’ve learned Liquid templates for Mephisto.

Liquid still is (as far as I know) the only usable “safe” Ruby templating engine that one could use for themes/templates in an application like Mephisto. In this context “safe” means that you can allow your users to download and install themes from arbitrary sources.

Liquid is safe …

So, with Liquid you can still sleep at night without any worries that some bastard might have included a bit of code into a theme that sends your password files to the russian mafia, runs rm -rf / or whatever nightmare you like worse.

Liquid does a very solid job here and as such it earns respect. But … let’s face it: Liquid sucks, syntaxwise.

As a Ruby programmer you want a templating system that makes your templates easier to type and more intuitive to grasp than ERB, not worse! Maybe it’s really just me, but for me Liquid fails miserably in this regard.

Haml is sexy …

On the other side of the Ruby template engines universe lives Haml. A templating system that is that awesome that you can’t possibly toy around with it for more than 3 minutes without getting totally addicted to it. But Haml is an evaluating templating system like ERB and as such you can’t use it for themes from arbitrary sources.

So how cool would it be to combine the best of both? Obviously it’d totally rock. It would be as cool as Yahoo sunglasses in 1994 and as sexy as the Audi R8 in 2008 combined.

Just a short heads up that I’ve updated the will_paginate_liquidized plugin to work with the latest (Chrismas 07) edition of will_paginate.

Like its name says will_paginate_liquidized enables will_paginate to be used within Liquid templates. You can find more about it here: will_paginate_liquidized plugin project page.

Wow, I still can’t believe how fast Taskmate has been moving forward in the past few weeks.

The main goal was to improve the initial version by adding some (minor) new features, track down any bugs … and most importantly adhere to the TextMate bundle style guidelines so it can make its way into the official TextMate review directory.

And this goal has been reached. The bundle has been commited to the review directory:

http://macromates.com/svn/Bundles/trunk/Review/Bundles/Taskmate.tmbundle.

I’ve just released a first version of the Google Analytics plugin for Ruby on Rails that I’ve done in the course of the offer to build custom plugins for Mephisto users.

You can grab the plugin and read more about it here: Ruby on Rails Plugin: Google Analytics (blue egg edition)

Eran Ben Sabat was the first to contact me about this offer and suggested that I could write a Google Analytics plugin which he was interested in.

By now there’s another interesting request by Thilo Thamm who asked for a plugin for allowing users to add blog posts. This sounds like another great idea for a useful plugin and I plan to tackle this one next.

I was totally thrilled how much fun it was to work with both Liz and Eran Ben Sabat on their plugins. So my offer still stands. If you have an idea for a nice plugin, don’t hesitate to drop me a note.

image credits

When I recently started to help porting Rails Engines to Rails 2.0 I haven’t found a complete big-picture walkthrough for the Rails startup process.

There are some really useful resources about this (see the end of this article) but they are for Rails 1.2 (some things have changed quite a bit in Rails 2.0) and each of them only covers certain parts of the process.

Thus, I’ve taken some notes while reading to the Rails code and compiled the following guide from them.

This article intends to walk you through the startup process in a whirlwind-speedy way, yet sticking closely to the actual code. I’ve added links to the code browser on dev.rubyonrails.org so you can look at the code lines while reading this article.

Of course, any feedback, corrections or additions are highly appreciated.

“Because home is where my editor is.” — ember

Taskmate is a small tool written in Ruby that enhances your text editor with some really simple yet powerful todolist’ish features.

You can read about my motivation to implement Taskmate here. And you can you can download and learn how it works here.

File this as either a bumbling, fingers-all-thumbs attempt at viral self marketing or the het up utterings of a developer playing with his latest mini pet project toy. ;-)

Ok, I love GTD. I’ve been addicted to it for about one and a half year now. I’ve read Dave Allens book more than just once and tweaked my implementation again and again, discussing with friends and collegues … and still I find myself helplessly stuck at times.

At the very least, over the time I’ve been able to identify quite accurately what requirements my perfect “trusted system” would meet and probably more importantly: what it easily could omit.