Monday, July 1, 2013

How I fell in love with Ruby, or the magic of Rspec

After a long hiatus (I have been battling cancer, and am now a proud leukemia survivor), I started coding seriously again recently. Well I never really stopped, but I started a bigger project than usual, on which I am learning enough that I want to blog about it here.

 I am actually writing a book on my fight against leukemia, and to do this, I am using asciidoc. I documented a lot of my life during that period of time on a dedicated blog, and of course, I wanted to use that as a base to work on the book, so I decided to write a tool to slurp the blog's RSS, and save each post in a separate text file. The posts' content then have to be converted from HTML to asciidoc , the images have to be downloaded and so on.

The first thing, obviously, is parsing the RSS feed. While it is fairly simple to write a parser using my favorite language, perl, and XML::Simple for example, I researched if, by coincidence, the work was not already done. And actually it is: there is a ruby gem, aptly called "simple-rss" that makes parsing RSS a breeze. The code was so simple, concise and elegant (more on that in another post) that I decided to write the whole thing in Ruby: as an added benefit, I would learn a new language. And the more I worked on the project, the more I liked it. But the thing that made me fall in love with it happened when I started writing my first test suite.

At first, I did not write tests. I did not really know where I was going, and I just hacked a quick prototype of what I wanted. However, the more the project was advancing, the more I realized that this was going to be more than just a 100 lines script, and that I would go way faster, not to mention being safer, if I actually applied TDD on the whole project. More on that later. So I researched a good ruby test framework. I am growing tired of the whole Test::Unit, JUnit norm, and so, just to learn something new, I chose rspec. Now to explain what my first test was, I have to explain a few things about my project.

To convert the HTML to asciidoc, I chose to use a simple approach that I am familiar with: simple regexes, that translate common HTML constructs into their asciidoc equivalent. The reason I chose to do this is the following: the HTML that makes the content of a post on Blogger is most of the time super simple, so I don't need a complex parser, and coming from a perl background, I am very familiar with regexes. So I have quite a lot of regexes, that execute after one another, and basically, my test suite is very simple: I need, for each regex, to test it's validity with a few different strings, and then test a few more detailed strings in order to test the whole chain.

So the idea is very simple: having a file which contains the HTML strings and how they should be transformed to asciidoc, read it, and execute the test for each line, and that's it. That way, I never need to touch the code of my test again, I just have to add more strings to my file as the need arise. Actually, this is TDD at it's finest: as I encounter a particular HTTP construct I want to transform to asciidoc, I add it to my suite, and then when the test ends up passing, I know I'm done. I did not know how to (de)serialize data to a file in Ruby, yaml seemed to be a popular approach, so I just chose that and started writing my first rspec test ever.

15 minutes later, I had the following.

# encoding: utf-8
require_relative "../lib/lib_helper.rb"

describe "html-to-asciidoc" do

    before :all do
        # load all the patterns and the expected transformations
        @test_map = YAML::load("data/tests-html-to-asciidoc.yaml"))

    describe "convert!" do
        it "transforms html correctly to asciidoc" do
            @test_map.each_pair do |html_source,asciidoc|
                html =
                html.should eql asciidoc

 And the following yaml file:
# Normal text
dog: dog

# br tags
'<br />': "\n"
'<br /><br />': "\n\n"

# bold, italics, underlines
'<b>dog</b>': '*dog*'
And it works, out of the box. It fits my need perfectly,  it is dead simple and easy to maintain, again it took me, without any previous experience in yaml or rspec, 15 minutes total to put together. It is so simple that it actually encourages good coding practices and using TDD, and even if I compare it to perl, which I am more familiar with, I don't think it would be as concise just as quick to write and put together. Actually, increasingly, for most things, I tend to favor ruby even if I have to take some time learning things in the process, just because the code is so much leaner in the end, and because of the simplicity of putting together a test suite, which is paramount for me. I'm just totally in love with Ruby.

Sunday, March 21, 2010

Emergent Design

I have just finished reading the book “Emergent Design” by Scott Bain and thought I would do a little review here.

If you read my previous reviews, you might know that I don’t like standard chapters by chapters review, so this one is not going to be exception.

Instead I’m going to start by telling you about the week of training I had with Scott. It assumes a background in software development since I can’t summarize a whole week in two pages without making a lot of shortcuts.

I followed two consecutive trainings, one on Design Patterns and the other on Test-Driven Development (TDD). As you might imagine, these can be pretty dry subjects, especially if you take the simple approach of going through patterns one by one. Fortunately, this is not the way Scott teaches.

Instead, Scott tells a lot of little stories, some about his life as a Software Developer, some about famous authors, even some seemingly irrelevant like the Battle of Azincourt. As you can guess he doesn’t tell these stories for the sake of it: they all are relevant in (sometimes) unexpected ways.

I know that some students wish that it was more technical, but I don’t agree. Us software developers are used to learning things by reading documentation and so on, and quite frankly if I want to learn about Design Pattern, I can do that on my own.

Learning how to make proper use of them however, is an entirely different story and this is where Scott’s way of imparting his experience was hugely beneficial.

As you may well know, design patterns are not a miracle solution. They merely provide a common language for developers, and provide solutions for already encountered problems. But they are not a silver bullet, and will not make you magically write great code.

That’s why Scott also focused on three other things: code qualities (or flaws), principles, and practices. Let me detail.

Code qualities are for example code cohesion, code redundancy (or more precisely the absence thereof), the absence of non-intentional coupling, to name a few.

Principles are for example “Encapsulate by policy, reveal by need” or the open-closed principle.

Finally, Test Driven Development is a practice. “Programming by intention” another one. “Encapsulating constructors” yet another one.

Let’s use the word “practices” as a shortcut for these three categories.

A point that Scott made during the course is that as a profession, we Software Developer don’t have a common set of practices. Other professions do: for example surgeons wash their hands before cutting somebody open.

As a profession, we badly need to establish a set of practices, otherwise we set ourselves for failure. Our lack of practices that can guarantee success is probably the reason why nowadays, marketing drives our planning. Could you imagine going to a surgeon and tell him “Cut me open, do what you have to do, and I need to be out by 5pm”? No. Sadly, this is what happens in software, a situation that in Scott’s opinion (and mine) will only evolve if we start establishing a set of practices.

What is the purpose of these practices? “Guarantee some level of success, or at least prevent failure”, as Scott says. A surgeon that doesn’t wash his hands is going to kill the patient, every time. If he does (wash his hands), he might (hopefully) succeed. So he doesn’t think about it, and washes his hands.

The nice thing is, practices don’t cost anything to apply. Most of us developers know them all already, but maybe we lack of a common framework to apply them consistently and easily.

Scott’s course has provided this framework, and interestingly, faithfully following it has enabled me to produce better designs without even trying. It just seems to “emerge” from the way I code, and more often than not, I end up with a well known pattern without having thought about it.

Giving us a list of practices is not sufficient however, and Scott has also done a great job teaching us how to apply them.

Take TDD for example.

As every developer, I’ve always been convinced of the necessity of proper automated testing. As every developer, I seldom did because I found it very hard to do in practice, for two main reasons: my code was not designed well enough to be easily testable, and I lacked a simple method to write tests.

As I said, “practices” solved the first problem, and Scott provided a simple method that makes writing tests a no brainer.

Recently I had to work on a bug in an old legacy code. After a week of battle with it, I had three different solutions and absolutely no idea which one to use.

So I wrote my tests, nearly without thinking, following Scott’s method. And I wrote, one solution pretty much singled itself out, and “emerged” from my tests. Within a few hours, a problem that had kept me in check for a week pretty much solved itself.

Scott’s practices had a huge impact on my coding. After nearly a decade of software development, I felt that I wasn’t evolving much. Learning new techs and so on, yes, but writing better code, no.

Looking back, I can see a quantum leap in my ability to write good code, and the greatest thing is that it is actually easier now. Before I had to think about how I was doing thing. Now I apply trusted principles, and can pay attention on why I’m doing things instead. The energy gain is incredible.

Oh, and the book “Emergent Design” you may ask?

Well it is pretty much a blueprint of the Design Patterns and TDD courses I took. Do I really need to say that I think it is a great book?

From a technical standpoint, it is a must-read, with a lot of references code examples and thanks to Scott’s style (he also tells a lot of little anecdotes and stories in the book) it is also a very very pleasant read (as opposed to, for example, the GoF Design Patterns which is dryer than the Sahara).

- Update:
Here is a remark Scott made after he read this review:
I consider Test-Driven Development and Pattern-Oriented Development to be "disciplines", not practices. Words are arbitrary of course, but the distinction I make is this: a practice is quick and easy to learn and put into place while providing a lot of value, whereas disciplines require much more investment from the learner and the team, and are expected therefore to give an even larger payoff in the end.

So, practices (in my use of the word) are things like encapsulating constructors, programming by intention, following a coding standard, making all class state members private, things like that. Washing one's hands was a good analogy on your part.

Disciplines include the ones I mentioned, and also Refactoring as Fowler defines it. Basically, the stuff I create classes around. This distinction may or may not be important for your purposes, but the teacher in me came out when I read it. :)

Thanks again Scott.

Wednesday, October 14, 2009

Getting back in shape 2

I told you a few weeks ago that I decided to get my feets wet using Ruby on Rails to work on a little project.

However, I soon realized that it was going to take more time than expected.

Even if I understand how Rails works, having a backgroung using other MVC frameworks, there is a wealth of things to know before starting.

Since I'm alone, I can't peek on an existing project, starting slowly by correcting bugs and so on, as I would do if I worked for a company: I have to learn enough about Rails before starting. Fortunately there are some very good books, so it's only a matter of time.

In the meanwhile, I still need to practice my Ruby. A programming language is like a foreign language: even if you know the grammar, if you want to be fluent, you have to use it.

I was thinking about what I could do: I needed a little project, self-contained so that it has a begining and a end, if possible with a deadline in order to prevent it from going out of hand. After all, I'm still looking for a job, and that has to be my main occupation.

I don't even know how I stumbled upon it: but I discovered the Ruby Programming Challenge for Newbie: every 2 weeks, you have a problem to solve, in Ruby.

It's a very cool idea: you work on a problem that you wouldn't necessarily have thought of (so it pushes you a bit out of your usual zone), you have a deadline, the solution can be pretty short which means that in my case I don't sacrifice too much time from my job searching, and you get reviewed by your peers (well in that case, your elders, since you are supposed to be new to Ruby), which is at the same time very scary and the best way to learn.

So I gave it a go, and finished yesterday. I'm submitting my solution today for review.

As expected, I learned a lot in the process and had a lot of fun. Being an hardcore perlist, I kind of got frustrated at Ruby sometimes but that's okay, the more I get the hang of it, the more I like it.

Now I have to wait till next week for the review! It's going to be a long few days :).

Thursday, October 1, 2009

Good tools to work well

You know, it is something that my grandfather repeated over and over: "A good worker needs good tools in order to work well".

In the particular field of development, we have two kind of tools: hardware and software. I'd like to focus a bit more on hardware tools.

Looking for a job in Seattle is a very interesting "job". I basically spend my time finding companies, trying to learn everything I can about them and figuring out if I'd like to work for them or not.

More often than not, I am able to find pictures of the offices, where the developers work. And there is one constant: they have the most amazing workstations ever.

Here, you wouldn't think of letting a developer code on a four years old 17" monitor. The absolute minimum I've seen is 22" single monitors, the average workstation is dual 24", and Google has the most humongous screens I've ever seen (bellow, Seattle office of google).

In France, I remember struggling for a few month to upgrade the ram for my team, and changing the monitors was just out of question. The only guy who had a wide-screen was the front-end designer. Don't even ask me about the CPU power of the workstations.

How crazy is that?

Here, when you pay somebody $75k+ you provide him the best tools money can afford. It is just common sense, really. If he spends 10 minutes a day more than necessary compiling an application, by the end of a month he lost 3 hours, more than the value of a CPU upgrade.

At one of the companies I worked for, I had such a slow PC that launching Eclipse took 15 minutes. No kidding. I launched it, and went for coffee.

I don't know where this 'cheapness' comes from in the french culture. I think that it is partly because the guys who decide how to spend the money don't have a clue of what is a developers job.

And the developers don't even complain. I don't think they even realize it! It's a cultural thing.

Well, guys, if you read me: this is not normal. Your work is the blood of your company. You deserve the best tools money can buy.

I already talked a bit of the psychological impact of having cool gear on a developer. But the truth is, you don't even need this reason. You need cool gear, because it makes you more efficient by an order of magnitude. And in the U.S where efficiency is the most important criterion, this was understood long ago.

Tuesday, September 22, 2009

Getting back in shape

Ok, let’s start with a little piece of advertisement: I am now allowed to work in the U.S and am therefore looking for a job in the Seattle area. My perfect kind of company would be a small start-up working on an interesting project, but I am open to pretty much anything. Please do not hesitate to contact me if you have any opportunity for a young manager that loves coding, making opinionated software, playing with nerf guns and that has a funny French accent ;).

Looking for a job is an excellent way to get to know what kind of technology is used on the market, and to my surprise, in Seattle, one technology is very popular: Ruby on Rails. It’s funny because I don’t think it is widely used in France, so I was never very interested in it. I thought “Pretty much another scripting language and another MVC framework” and archived the data in a corner of my head.

When I saw the sheer number of positions where you have to be competent in RoR, I had to revise my judgement, and decided to test the framework. At the same time an idea for a little website popped in my head, so that was the perfect project to get back in shape.

One objective: finalizing my little project (codename “Powerade”, don’t sue, I have no money), using as much unknown technologies as I can: Ruby instead of Perl, Subversion instead of CVS... Ok I’m keeping MySQL and Apache.

So a few days ago I installed an Ubuntu VM, set it up with all the necessary software, and got to work. By the way, if you know a good lightweight Ruby IDE with a vi plugin, I’m interested, as Eclipse seems a bit too much for my VM.

And getting back in shape it is!

After 3 months of forced inactivity, where I didn't code because I was to busy discovering Seattle, it is kind of funny to see how quickly things that where a reflex fade from memory, and at the same time how some things are imprinted in my fingers. For example using svn instead of cvs is a pain since when I do any revision control operation I just type cvs something without even thinking about it, but at the same time, I completely forgot the most common cvs options and had to browse quickly through the manual to do the most basic operations. Using the CVS plugin for Eclipse the last year probably didn’t help by the way...

I kind of like Ruby on Rails.

I am not necessarily a Ruby fan yet, but I can see myself becoming one. I had a good laugh when I discovered that you can write things like “dog.isHungry?”, but I somehow miss Perl. Maybe it’s just a matter of fluency.

On the other hand, I am amazed by Rails.

In 5 minutes of toying with it, I had a web page enabling me to create a user and edit it, and this is incredible.

I still have to use it more to do a comparison with another framework such as Cocoon, but I am already seeing why Rails is so popular.

It enforces a proven project structure that is very clean. A framework like Cocoon doesn't and it's very easy to do messy thing. It automates tedious tasks like creating databases schema, updating them, creating test cases and test data, and test database. It has it's own server embedded which is nice because you can work on your project pretty much anywhere without having to go through tons of configuration beforehand. The list goes on and on.

We’ll see if this good impression persists after a prolonged use, but I already convinced ,).

Friday, September 18, 2009

Book Review: "Leadership Jazz"

I wanted to write a review of Leadership Jazz by Max de Pree for a long time but somehow never managed to do so. It is one of these posts where you exactly know what you want to say, but somehow it doesn't come out, because it is more a gut feeling than a very intellectual opinion that you want to convey.

"Leadership Jazz" is not a technical book, that is to say there are no articles on how to organize yourself, to lead more efficient meetings or to hire a team. Instead, Max de Pree explains his vision of what it is to be a leader little by little, drawing on the considerable experience he had while being the CEO of Herman Miller.

This is what makes it hard to review. It is not a manual. It is more like the advice of a wise grand father, who tries to convey a part of the experience of a lifetime to the younger generation. It is not a book about being a manager, it's not a book about being a leader... It is more a book on how to be a decent human being.

It is filled of little gems of wisdom, and reading it was a strong experience for me, filled of little epiphanies where I just had to stop reading and go for a walk to digest what I just read.

I love so many quotes that I can't even begin to choose one, so I'm just going to pick a few at random.
  • Leaders ought never to embarrass followers
  • Equity is the special province of a leader
  • We have much to learn from jazz-band leaders, for jazz, like leadership combines the unpredictability of the future with the gifts of individuals
  • The servant-hood of leadership needs to be felt, understood, believed, and practiced [...]
  • You never want to go to sea with a captain that would rather be in port.
I basically found those quotes by picking a different page each time at random and scanning it quickly.

This book truly is the best I ever read on leadership. It applies to everybody. Managers of small teams, CEO's of multinational companies, parents, political figures, teachers... To me it is no wonder that Bill Clinton calls it "Astonishing".

When I read this book, I get the same feeling that I get when I read old chinese taoist classics like "The book of Leadership and Strategy". It seems profound, timeless, which is rare enough to be mentioned.

Read this book. Even if you are not a manager of any kind, it will make you a better human being.

You can find it on Amazon.

Friday, July 24, 2009

Google Wave, continued

Some links that have a little info on them about what Google Wave is about

About Page from Google
A guide to Google Wave
The Google Wave API
There are already Wave widgets
Wikipedia's page on Google Wave which as interesting info on why Google wants to open source it.
Some news about the public Beta

That's pretty much it for now, every article that I can find is pretty much a copy paste of those pages.

Search Results