• 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.

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 'listener.java.erb'
content = File.read('listener.java.erb')
template = ERB.new(content)
File.open("#{classname}Listener.java", 'w') { |f| f.puts(template.result) }

If I run this using listener.java.erb:

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?

def read_file_content(filename)
  File.read(filename)
end

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) {
      buffer.append(line);
    }
    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.

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?

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.

I didn’t know at the time but Google also allows you do something similar. You just need to go to http://www.google.ca/experimental/ (also works for google.com and I guess most other domains). There you can opt-in to be part of the Keyboard shortcuts experiment. That’s it! J/K are used to navigate through search results, O (or enter) to open them.

Hopefully this is going to be useful for the other keyboard junkies out there.

Monday : I decided to use Typeracer as my baseline. It’s an online game that allows you to race others. The fastest typist wins. I had not played in 6 months or so – and it showed. My score for the last ten races dropped a bit. This was not a good start. Result after the day : 74 wpm

Tuestday : I did some drills on goodtyping.com to get back to speed. It must have helped because I raised my speed to 78 wpm.

Wednesday : mostly played Typeracer. I managed to cut down on typing errors and I’m up to 81 wpm.

Thursday : I tried to practice at night instead of during lunch time. Without much success – 80 wpm. My fingers were not obeying me. I did a few drills on goodtyping.com to increase accuracy.

Friday : Success! I managed to consistently type over 80 wpm today by concentrating on typing slower but with less mistakes. I managed an average of 87 wpm on my last 10 races.

The week is over and I achieved my objective of 85 wpm. I did this mostly by reducing mistakes – they can get really slow you down.

Thanks to my colleagues who followed in my track and helped me focus on this challenge.

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.

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.

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 http://codekata.pragprog.com/2007/01/kata_five_bloom.html – 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.