Codigo Ergo Sum

I've just released a new version of the i15r gem which alleviates the tedious task of internationalizing a Rails site by finding the "static" texts and replacing them with I18n message strings.

The good news -and probably the reason I am writing a blog post about it- is that it can now process haml files, too. This must cheer up those who -like me- have come to like haml so much they now use it for their projects. So go get it and let me know how it works for you.

(See the introduction to the series.)

When you want to pull in a Ruby library, you require it. The library you require has to be on Ruby's load path ($LOAD_PATH) in order to succeed. So let's see how Rubygems hooks into this process.

The secret lies in custom_require.rb. You'll see a nice comment near the top.

When you call "require 'x'", this is what happens: * If the file can be loaded from the existing Ruby loadpath, it is. * Otherwise, installed gems are searched for a file that matches. If it's found in gem 'y', that gem is activated (added to the loadpath).

In fact, that explanation looks so straightforward to me that I doubt if I can add more words to precise it, so let's look at the code together:

module Kernel
  alias gem_original_require require
  (...)
  def require(path) # :doc:
    gem_original_require path
  rescue LoadError => load_error
    if load_error.message =~ /#{Regexp.escape path}\z/ and
       spec = Gem.searcher.find(path) then
      Gem.activate(spec.name, "= #{spec.version}")
      gem_original_require path
    else
      raise load_error
    end
  end
(...)
end

Aliasing a method, redefining it and calling the original version from the redefined method is a very familiar pattern if you have read Rails source code (called method chaining).

So, just as the above description says, if the file can be loaded "without Rubygems" it is and Rubygems never comes into the picture. If not, we make sure that the load error comes from the file not found on the load path and then find the gemspec for that file and activate it.

Activating it adds it to the load path, so we can call the original require safe in the knowledge that it will now succeed and we won't get another load error this time around (and go into an infinite loop). Clever, heh?

This is one of the cases when the code is so simple for a moment I think I could have written it myself. With its <10 lines of code Rubygems is empowered to load a myriad of useful Ruby libraries. Isn't this wonderful?

I am not sure about you, but one thing I keep bumping into while developing ruby applications is rubygem version conflicts. If you have ever come across "can't activate activesupport (= 2.3.4, runtime) for [], already activated activesupport-2.3.3 for []" type of errors, you might be sympathetic to the cause.

Since rubygems was and is being written by some excellent Ruby minds I knew the fault probably lies with me and not with the tool. Being a motivated and proud craftsman I felt like I needed to know my tools and rubygems is probably the number one tool most of us Ruby developers use on a daily basis.

I intend to write a mini-series of Rubygems posts. A post will be added to the series when I explore some murky corner of rubygems inner mechanics. Some of the time this will come from a particular problem I come across while coding while on other occasions I might just look into the source code and try to understand what a particular piece of code does.

Now, I realized that when I read on a blog: "I will go into more detail about X in a forthcoming post", it is the surest sign that you will never read about X again. At least not on that very blog. And I am not saying this in a mean way, I think it is very natural for our plans to change ("evolve" may sound better) even on the short term. So I am aiming low and hoping to give you more than you expected. (Notice I wrote "mini-series" which may just mean a couple of posts.)

Do not set your expectations high

I am absolutely not a Rubygems expert so please do not be fooled by the "under the hood" title. This will not be commensurate to Jamis Buck's series on Rails routing. I do not -yet?- have a deep insight and I am not even a contributor to Rubygems.

The forthcoming :) series is just a humble attempt to gain an understanding of a very important part of the Ruby arsenal. I hope to understand it better by explaining to you how it works and I hope you will understand it better by reading my explanation. And last, but not least, I hope we'll both spend less time debugging those tricky issues.

Having said that, I encourage you to participate in the series. Tell me about a particular problem you had with Rubygems. Correct me if I am wrong. Point me to an article where all this is already explained, and much better. Give feedback so this might evolve to be a discussion rather than an academic lecture. Thank you.

Continuous Integration (CI) is a basic building block of any project done in TDD style. In brief, having a CI server properly set up guarantees that developers can rest assured that the application passes all its tests and can thus be deployed at any moment. It does this by sending some kind of a warning if something is broken so it can be fixed immediately.

Now I noticed that if a CI server is not in the mix right from the beginning of project, chances are it will never be, that was one of the first things I installed on a new Rails project. My server of choice is Integrity mostly because it is so easy to set up and quite straightforward to use.

Ok, so next we need some tests that Integrity will run at each commit and make sure the app can still be built. As a high-level acceptance test framework, I use Cucumber, which plays very nicely with Selenium for automated in-browser testing. Since nowadays even the most basic web application will have some amount of client-side scripting code (that is, javascript) if you really want to test the features of your application you'll need Selenium tests.

That's when matters get a bit more complicated when it comes to integrating these with the Integrity server. Why? Because on the server you usually don't have the "desktop environment" which is available on the machine you do the development on. By default, you don't run a desktop manager and have a graphic display on a server. A tool called xvfb comes into a picture that emulate a dumb framebuffer so you can still programs that need a graphic display.

To have some practical guidance, here's what I did on an Ubuntu server to enable all of the above:

Install java since Selenium runs in the JVM:

apt-get install java-common sun-java6-jre

Install firefox since that's what Selenium runs by default and that's a very good choice.

apt-get install apt-get install firefox

Install X since that's what the xvfb launches and Xvfb itself.

apt-get install xorg xserver-xorg
apt-get install xvfb

Next I found a wiki that describes how to launch the Xvfb correctly. Log into the server and do:

startx -- `which Xvfb` :1 -screen 0 1024x768x24 2>&1 >/dev/null &

So Xvfb will run on the DISPLAY :1. So far so good. But something was still not quite right. When integrity launched the test suite that included some Cucumber-Selenium tests I received an error message basically saying that no browser sessions could be started. And the solution to that, in fact, is where this post wants to get at.

After a decent amount of head-scratching and code mining I realized that the Selenium server starts the browser on the same display where the server itself (the jar file) runs. I have found the relevant code that assembles the command that starts the Selenium server in the selenium-client gem and figured it was not meant to be run in graphic hardware-less environment since I saw no options to define which display it should run on. So as an easy hack I added the hardcoded "DISPLAY=:1" before it and crossed my fingers.

Bingo, it worked and I had a green build again! What's more surprising is that it still runs perfectly on my Macbook so it seems to run in (some) graphical environments, too. It seems a bit strange to me to have found so little information on this subject since Rails, Cucumber, Selenium and CI are all en vogue so it is possible that I missed something obvious and there is an easier way to do all this. I am very eager to hear how others set up their CI to run automated-browser features. Do you use another tool, not Selenium? Do you use a CI server with a monitor?

Anyway, I certainly hope my hackish solution will prove to be useful for some of you TDD-minded developers out there who run their CI on a simple <name of your favorite provider here> slice.

UPDATE: As a fellow developer and the author of the selenium-client gem himself pointed out library code is not the place for enviroment specific settings. Rather, it should go into the application's code. I guess that leaves the choice of putting it into the code of the application you are building or the configuration of the CI server. This latter seemed more clean to me so I put the following line into config.ru in Integrity's directory:

env["DISPLAY"] = ":1"

There is still something left, though. When integrity -or, to be precise, the selenium process that was launched from integrity- wants to access display :1, it will be denied. You need to explicitly enable local connections by putting "localhost" in a file:

echo 'localhost' >/etc/X99.cfg

, and then using that file as the access records list when you launch the server:

xinit -- `which Xvfb` :1 -screen 0 1024x768x24 -auth /etc/X99.cfg 2>&1 >/dev/null &

(Note that I launch xinit and not startx as before. startx somehow adds another -auth option which messes things up)

There, that should do it. It works and there is no code where it does not belong.

I realized how 20th century (plus boring and error-prone) it is to write one's invoices by hand. So I went looking for an invoicing application. My expectations were quite low: I wanted one which can be used from my MacBook, has some basic functions that cut down on typing (e.g a client "database"), has a decent design and UI, can make out invoices in different currencies and did not cost more than ~$100.

It seemed like I have found one, which, though it had several minor bugs, seemed acceptable, so I purchased the Basic version. Everything went reasonably well until I had to make out my first invoice in euros. It turned out that the Basic version can only make invoices in Hungarian forints in spite of having a couple of other functionalities (e.g set the VAT rate to 0% automatically on invoices made out to EU companies) which made me think it could make it in euros, too.

Ok, so accounting hell got me again. I sighed and asked the company how much it would cost to have this funcionality. I was informed I had to buy the upgrade to the Business version which costs ~$120 more, roughly the double of the original price I paid! That was too much to take, so I went looking for another invoicing application. After all, it should not be an insurmountable task to write such an app, I murmured to myself.

I did find a couple of very good applications which even overdo what I want them to accomplish. However, the Hungarian homologue of the IRS basically shuts out any foreign competitors by regulating very heavily which conditions must be fulfilled by an invoicing application for a Hungarian company to be able to use it. Bummer.

"There is still a glimmer of hope." - I thought. I checked the Hungarian scene still thinking it could not be that difficult to meet my expectations. Well, apparently I was wrong. The ones I found are either overcomplicated to use, look like home pages in the 80s or are way too expensive. Sometimes all of these. So I put off the challenge of finding an acceptable piece of software and got back of writing invoices manually.

Now you might wonder where the dog food is in the story. Well, today I received the invoice from the company of my purchase of the Basic version of the application. It was written manually on an invoice sheet :) That's tantamount of Steve Jobs using a PC with Windows Vista.

We, developers, have to come up with user names all the time. In this glorious, pioneer era of TDD, more than ever we have to not only enter them into text fields but write them in test files that are part of the code and thus are clearly visible and permanent.

So it is important to give good names, but what is a good name like? I am not thinking about the semantics of the name (whether it has accented letters, or if it has two or three parts, etc.) but look at them from a very personal point of view: whether it makes you, the programmer, satisfied with your choice of names or bored with repeating the same old names you used in other projects and even in those projects, you had copied them from somewhere.

So when writing your first test where a user is needed, stop for a moment and imagine a world which you like and which is amusing in the context of your application's domain (like philosophers playing soccer, Luddites attending a technology conference, etc.). Pick some names and let the feeling that you have created something instead of just using old, boring names fill you with contentment. Whenever you need an other name, take one from your world. If you need further data (e.g date of birth) about your test users you can even do a little bit of research.

Though investing energy in this may reduce the time you spend writing code, compared to all the hours you put into a project, it is negligible. Nurturing this "subculture" in your tests can be very entertaining so you have a good time developing and are less prone to boredom. I think it pays off. We, Ruby programmers all know how important it is to be happy while programming and the effect it has on our productivity.

And besides, do you know of anyone who is called John Doe?

A very simple twitter bot that retweeted everything that was tagged by a certain tag was put together for Scotland on Rails '09. Then, Jaime Iniesta adapted it for Euruko '09. I then forked from his repository, made a few simplifications and minor improvements and DRY-d its configuration.

Maybe most importantly I then turned it into [a gem][hashtag_retweet_home] so that configuration files (including the bot's which has the credentials for the twitter account) do not have to be included in the repository.

I also set up a twitter account for the budapest.rb group where an instance of the HRT bot will post any tweets that have been tagged with #budapestrb. So, my fellow budapest.rb programmers, if you have anything to say about the budapest.rb, just make sure you include the #budapestrb tag in your tweet and watch the HRT bot repeat it.

To launch your own hashtag retweet bot, just follow the instructions in the README.