Category Archives: programming

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.

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.

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.

Unreasonable Fear

Sometimes, developers are a bunch of wimps.

We get so comfortable with our programming language that many of us are afraid to try something else.

Many of us learn one programming language (Java, C# or something else) and we stick to it no matter what. We do use libraries and frameworks and we’re often eager to try a new one in our project. But talks about learning a new programming language are usually met with quick rejection. We want to stay in our comfort zone.

I think something is wrong with this picture. Is learning Ruby on Rails really more difficult than learning Spring? Is Hibernate really simpler than activerecord?

Why are developers afraid of trying something new? Some problems can be solved easily in Clojure or Erlang. Are you sure Java/C# is the solution to your problem? It might be part of the solution, but probably not the entire solution.

Discovering ruby (and rails), I see flaws in Java that I didn’t see before. I learn a different way of doing things that expands my knowledge. When I come back to Java, I see problems from another point of view and sometimes use a different solution than I would before learning ruby.

Why are you still afraid?

Training On Hold – For Now

I planned on continuing my training sessions while I was on vacation. However it seems that I am even more tired after a day in the sun than I am after a day at the office. Go figure.

Anyway I decided to put the training on hold until I come back. A guy has to take a break from time to time. And it gives me more time to read and think about my objectives for the next year. That’s what I’m going to do for the next two weeks.

I’ll continue to do katas and small projects when I come back.

How to warn users not to use an interface

Everybody knows no one reads documentation. Hamcrest found an original way to warn users to use the org.hamcrest.BaseMatcher class instead of the org.hamcrest.Matcher interface.

Look at the interface yourself.

They added a dummy deprecated method called _dont_implement_Matcher___instead_extend_BaseMatcher_ in the interface.

I am still unsure whether I will ever use this in my own projects. But when this method appeared in my code today I could not help but look at it. It was then totally clear that I was not doing what they wanted me to do. I’ve seldom seen documentation that obvious.

Training week #2 and a challenge

This week I consolidated the two katas I did last time (Prime Number and Bloom Filter). Nothing much to talk about.

The only thing of note is that I got late in my RSS feed (again) so I missed the announcement of Corey Haines’ Learn How to Type Week.

I repent and decided to try my own this week (along with a few colleagues).

I’ll keep you posted about the results. I’ll work in increasing my wpm.

Developer in Training

I believe in software craftsmanship and in training to become better.

That’s why when I was challenged at work to take a few hours each week to train, I thought “What a great opportunity!”.

Well that’s what I should have thought. Instead I said: “But what about the project? The deadline? The world is going to end!”

Then I realized how lucky I was to work at Pyxis. I asked the Product Owner and it wasn’t such a big issue.

Lesson #1: Ask and thou shall receive

For my first training session, I decided to do the some katas in ruby as it has become my language of choice for pet projects.

Part 1 – Primes

I started my first session with the Prime Number kata. I like this kata since it is really simple, can easily be done in less than 30 minutes (closer to 10 once you’ve done it a few times) and I learned a few useful tricks in ruby by watching this kata permormed by Uncle Bob on Katacast.

I plan on doing the Prime Number kata every week as a warm up.

Part 2 – Bloom filters

Afterwards I tried kata #5 from – implementing a Bloom Filter. It’s an algorithm that probabilistically determine if an element is part of a set. It works like this : if the element is in the set, it will always return true. However if the element is not in the set, the bloom filter might still return true depending on some probabilistic stuff.

Training ends

Here are my highlights of the session:

  • I learned a new algorithm, it’s purpose and a few use cases
  • I performed everything in pure TDD
  • Continued to learn new keyboard shortcuts in Rubymine (I try never to use the mouse in katas. If there is a keyboard shortcut I forgot, I look it up and make a point on using it)
  • I managed to take some time to train!

The only downside I can think about is that I spent a little while trying to configure ruby 1.9.2, rspec and the latest beta of Rubymine 2.5 before reverting to ruby 1.8.7.

As for improvements, I see lots of ways to improve the Bloom Filter katas, especially when it comes to my tests. I’ll give it another try next time.

Git is not (just) Source Control

After many discussions with a colleague about Git, I came to realize that Git is not merely a source control. With time it became a tool in my developer’s sandbox. To develop software effectively, I need (among other) an IDE or text editor, a prompt and countless libraries. I came to rely and trust these tools.

I used many other tools for version control but I saw them as infrastructure – mandatory in the grand scheme of things but not used to improve my productivity.

Git changed everything by allowing me to rethink the way commits and branches work.

  • By promoting small commits that do one thing but do it well, git forces me to split my task in even smaller chunks that can then be commited. This sometimes leads to architectural changes.
  • By making it possible to  reorder the commit history (git rebase -i origin), it pushes me to make each commit clean and atomic.
  • Git makes branching cheap and easy. Like you, I try to code each features in a separate branch. But unlike you, I am undisciplined and often forget. However if I start on a feature and realize it takes slightly longer than expected (and I’m talking about an hour max, not 3 days), I create a branch for that feature. It’s easy and it allows me to work in small, independent chunks. It also allows me to always be able to come back to a stable branch if I need to do a few quick fixes on another part of the project.

Git is not a mere tool – it changed the way I design and code.