Gemsets and .rvmrc – Ruby Gem Management Made Easy

RVM is a tool that automatically manage your ruby versions. You can make 1.8.7 and 1.9.2 live together without issues. The installation process is a bit lacking – bash < <( curl ) is not really a command that looks safe at first sight. Blindly executing code from the Internet is not for the faint of heart but yep, rvm is really that useful.

I especially love gemsets. They allow you to completely separate your various development environments for each of your projects. Gem conflicts are a lot less common.

You can even automatically change to a gemset for each of your project by using the an .rvmrc file. I use ruby 1.9.2 by default but I have one project that uses ruby 1.8.7. I use a separate gemset called ‘mygemset’.

# create the gemset if it does not exist
# switch to default ruby version when exiting directory
# use ruby 1.8.7 with a specific gemset
rvm ruby-1.8.7-p302@mygemset

Pretty neat. Since this file is committed, it also means everyone on the team has the same setup.

A Preference for Flexibility

I came upon this example in an otherwise very good book. One example tried to test a main method by passing arguments:

String[] args = new String[2];
args[0] = "param1";
args[1] = "param2";

Whenever I write in this kind of code, I always prefer to create an array instead:

List<String> list = new ArrayList<String>();
MainApplication.main(list.toArray(new String[list.size()]);

It’s a bit more verbose, but I find it offers a lot more flexibility as adding new parameters is simply a matter of adding a new element to the list. In the first example, adding a new parameter requires two steps : 1) modify the size of the array and 2) initialize an element of the array to the desired value.

I do whatever I can to remove a step, as small as it seems.

Modifying all the indexes is also a lot less fun when you need to add an element at index 0. And of course you’ll eventually copy/paste one line of the array and forget to modify either the size of the array or the index.

Using a list is a small improvement but in the long run, small things make the code a lot more maintainable.

PS : a friend noted that if you already use Google Collections (now Guava), you can get even more elegant code with

list = Lists.newArrayList("param1", "param2")

Programming is Hard, Shipping is Harder

For the past year I’ve done lots of experimentation with various libraries and I had a lot of fun using ruby. Tinkering is fun, but it doesn’t get anything finished. I have a tendency to hop from pet project to pet project, never finishing anything (or worse yet in my deranged mind, releasing something half finished).

That’s basically what my friend forced me to understand by harassing me to ship an application online (or so my deranged mind remembers from our last conversation :)). Now I can thank him because it’s done.

I give you the The Pomodoro Assistant.

Since I use the Pomodoro Technique at work, I went with a simple app that allows me to manage my pomodoros. The design is ugly and it’s still lacking many features. However it’s online and available for you to use if you desire. And I’m already using it at work so it must be kind of useful.

I’m eagerly waiting for comments and feedbacks.

Python One Liner

I keep forgetting this simple way to start a HTTP server to serve files from the current directory… Now it’s going to be here for eternity

python -m SimpleHTTPServer

Then point browser to http://localhost:8000
This blog shall become an extension of my brain…

Thin Line

“Daddy, what are you doing on the computer?”

How can I say that I’m installing rvm for ruby 1.8.7 + 1.9.2, rails 3 and postgres on a brand new Ubuntu installation?

“Daddy is playing on the computer.”

Don’t you just love it when the line between work and play is so thin?

Keep Your Code Where It Belongs

The Story

I just bought a new computer. For the first time in ages I didn’t feel like spending hours deciding which parts I wanted, so I went for a big brand PC. Of course it came with Windows 7 installed.

Like any self-respecting geek, the first thing I did was… to install Starcraft. No problem there.

The second thing was to install Ubuntu. Then things started to get hairy. I could reboot to Windows once. Then the Master Boot Record. In case you don’t know, the MBR is a very important part of your disk that tells it what to boot. I was stuck.

Time for google. Fortunately I came across this page. It basically says “Some programs write to the MBR, overriding Grub 2’s boot code”. It then goes on to explain how booting from another drive (not an option for me), using LILO or reverting to Legacy Grub. The last one worked for me.

The Point of the Story

Anyway that got me thinking about a golden rule of software development : keep your code where it belongs! (Most likely, it does not belong to the boot sector.)

I can’t remember how many times I saw software fail because someone decided it seems to be a good idea to modify the internals of a framework/platform and commit it. Then the day comes when you want to use a new feature – and all hell breaks loose.

There is always a better option. If you think your project is different, think again. 99.9% of the time you’re wrong. If you think you’re in the .1% – so does everybody else. Otherwise you end up with an unbootable PC, a Tomcat that cannot render .jsp (yeah I saw that) or an application that is stuck with an obsolete, unmaintained version of a library that you can’t get rid of.

Keep your code out of the framework. You’ll stay sane a lot longer.


In September 2009, I decided that for the next year, I would concentrate on three goals:

  • Reading (12 books)
  • Blogging (40 posts)
  • Coding (4 projects)

What did I learn about setting objectives? What do I need to improve? These questions will be answered in a few moments… and if you care you might even hear how I fared.

The results (drum roll)

Overall I’m happy with what I accomplished. I read more books than what I planned (16 books that I remember plus tons of blogs), and I blogged as planned (*exactly* as planned if I include this post and another I posted only on the Pyxis blog). However I wanted to code a lot more than I did. I’m still pleased with the small projects that I worked on but I envisioned something bigger. I mostly did prototypes, katas and experimentation with Rails. No big projects, nothing on github (yet).

I did learn a lot about setting objectives for the future:

Lesson #1 : Never write about goals other people set for you

My wife convinced me to put something about losing a bit of weight. Fail. It wasn’t my goal, it should never have made the list

Lesson # 2 : Keep your objectives focused

For me, three goals was one too much. Very early on I could see that it was easier for me to write blogs or read books than it was to code – books were feeding me for blogs, blogs were giving me questions to read about. Coding felt lonely. Next time I’m going to go with two goals max to start with – and coding is going to be one of them.

Lesson # 3 : Do it gradually

Setting goals is definitely something that allowed me to improve. When I did it in the past, I usually started with a big goal in mind. I suggest you try it with small objectives at first and grow more ambitious as you go. Get started, have habits in place. Then think big.

Lesson #4 : Think about your next goals in advance

Especially if you plan on blogging about it on time. Shame on me.

I have a few ideas but I’m not fixed yet, so I’ll set a few very short term goals for now.

Rediscovering ERB (without Rails)

Since I discovered Haml for my HTML templates in Rails, I stopped using ERB. Haml is more intuitive and readable to me.

I am rediscovering ERB though for something else completely – Java code generation.

There is a lot of boilerplate code in most Java projects. A good IDE can help you alleviate some of it but most (if not all) applications will have additional boilerplate very specific to your application. Using ERB, you can easily create cut down on mindless typing.

For example, let’s suppose you are writing many Java listeners. Just create a script that will do it for you. I’ll make an exemple with a ContactListener class that is notified when a user is added, removed or blacklisted from your contact list.

require 'rubygems'
require 'erb'
# setup - could be initialized from script arguments
classname = "Contact"
listener_methods = ["added", "removed", "blackListed"]
# create file based on ''
content ='')
template ="#{classname}", 'w') { |f| f.puts(template.result) }

If I run this using

public interface <%= classname %>Listener {
  <% listener_methods.each do |method|  %>
  void <%= method %>(<%= classname %>Event event);
  <% end %>

Then I generate this file:

public interface ContactListener {
  void added(ContactEvent event);
  void removed(ContactEvent event);
  void blackListed(ContactEvent event);

That was easy – and it’s not that useful I admit. I’m sure you can create your own listeners just as fast in your own IDE. Probably even faster.

However here comes the fun part – the same script can be used to create lots of other classes:

  • The ContactAdapter class
  • The ContactEvent class
  • The ContactController
  • The Contact model
  • The ContactRepository (maybe even with a few methods to add/remove/retrieve a contact by id)
  • The ContactView through which users will be able to trigger ContactEvents (maybe with a simple UI – even buttons to trigger each events on the ContactHandler)
  • Registration of the ContactHandler and the ContactView by your favorite IOC framework
  • Registration of the ContactView so it is accessible from your application’s menu
  • Test classes for all of the above (including failing test cases that you’re going to have to write)

And probably other bits here and there to glue everything together.

Your mileage may vary, but code generation might be a great way to make your path shorter.

Can your IDE do that?

Dear Java, Please Let Me Work

I had to read the content of a file for a ruby project. This is how I did it:

def read_file_content(filename)

Simple enough, right?

Then for some reason I thought about how I would have to the same in Java:

public String readFileContent(String filename) {
  try {
    BufferedReader reader = new BufferedReader(new FileReader(filename));
    StringBuilder buffer = new StringBuilder();
    String line = null;
    while ((line = reader.readLine()) != null) {
    return buffer.toString();
  } catch (IOException e) {
    return "";

Need I really explain why I prefer Ruby these days? Even if you remove the try/catch clause and rethrow the exception, that’s still a lot of code compared to a single line of ruby. I am also aware that it is possible to write the same Java code in a single line using Apache’s commons-io (IOUtils.toString(InputStream) – but still, why are the base Java libraries so verbose for file manipulation?

I still like Java, but I’m impress by the compactness of Ruby. It just works as it should. Sometimes working in Java it seems I’m just smashing the keyboard instead of getting actual work done.