Some ActiveRecord fun

Many of you have already used has_many and belongs_to Active Record relationships. This is really easy to do when you have a single attribute to map; like, in example, an Article with many Comments. You’d write something like

class Article < ActiveRecord::Base
  has_many :comments
  ...
end

---

class Comment < ActiveRecord::Base
  belongs_to :article
  ...
end

Combining these declarations with a article_id column in your comments table would allow you to:

• access all the comments of an article with article.comments


• access the article a comment belongs to with comment.article

There are situations, however, when things get a little more tricky. Think about this example: you have a Movement object, which identifies a cash flow between two Accounts. You also have an accounts table; so, in your movements table, you would add columns like from_account_id and to_account_id.

How can this be mapped with ActiveRecord? We need to write two belongs_to declaration, this way:

class Movement < ActiveRecord::Base
  belongs_to :from_account, :class_name => "Account", :foreign_key => "from_account_id"
  belongs_to :to_account,   :class_name => "Account", :foreign_key => "to_account_id"
  ...
end

This tells ActiveRecord that the movement class must reference two Account objects. One is accessed with movement.from_account and the other with movement.to_account.

You can do the same thing for your Account class:

class Account < ActiveRecord::Base
  has_many :movements_out, :class_name => "Movement", :foreign_key => "from_account_id"
  has_many :movements_in, :class_name  => "Movement", :foreign_key => "to_account_id"
  ...
end

This way, with account.movements_in, you can get all the cash flows to the account, and with account.movements_out all the cash flows going out of the account.

Plain and simple! :)

Autospec for Rails + libnotify on ubuntu howto

Hallo! After a couple of hours of work I finally managed to get autospec popup notifications on my ubuntu machine. Now I can start autotest in the background, and whenever I save a file into my project folder, after a few seconds I receive a notification message on my desktop about the tests.
Here are the steps to get the same result:

1. install the required gems (ZenTest, and obviously rspec and rspec-rails);
2. sudo aptitude install libnotify-bin;
3. edit the file .autotest in your home folder (I said home, not the root of your project!) with the content from this link: https://gist.github.com/840314
4. save the two pictures rails_ok.png and rail_fail.png from http://blog.internautdesign.com/2006/11/12/autotest-growl-goodness and put them into your ~/Pictures/rails folder.

At this point you are supposed to only run autospec in your project root folder, save a file and see a notification like the one at the top of this article! Happy BDD!

Building a pronounceable password generator in Ruby

Heya guys! Today I tried to build a pronounceable password generator. To keep it simple, I started from a simple concatenation of words - in my case, italian words. This is really easy, but you'll see that results will be very good.

I took a list of italian words from this site: Italian dictionary and affix file for ispell. It's a good choice because ispell dictionaries are prepared to be declined; concatenating two words without suffixes will give good results for pronounceability.

Before proceeding, however, I needed to narrow the words list:

I removed the ispell affix definitions, to get words like "abaco" instead of "abaco/G":

cat italian.words | sed 's/\/[A-Z]*//g' > parole.txt

I removed all words containing capital letters, like "Yamaha", "Windows", and "Acicastello":

cat parole.txt | sed '/[a-z]*[A-Z][a-z]*/d' > paroleNoCapital.txt

Finally, I sedded out some cuss words - not writing them here, for the sake of decency! :)

I was then ready to write the following ruby script:

def genera_pass_da(parole, n = 2)
how_many_words = parole.size
word = ''
1.upto(n) do
word += parole[rand(how_many_words)].chomp
end
word
end

file = File.open("parole.txt")
parole = file.lines.to_a.select { |word| word.size < 7 }
1.upto(10) do
puts genera_pass_da parole
end

Even if it's far from being polished and optimized, launching this gives a good set of pronounceable passwords. They're all lowercase and without numbers - so probably not the best choice for your remote banking account - but still ok for other uses. Here's a shot:

metalelf0@eagleone$ ruby rapg.rb
uditovoi
vammimidi
gechitua
dareisisma
ecoivi
ancabatto
unotacca
fangopupe
apesella
bemasire

Someday I'll improve it by adding numbers, some capital letters, customizing choices and so on - but many friends are yelling me that it's sunday and I need to go out, so... see ya soon!

Shared pomodoro part II

Last month I posted an article about the Shared Pomodoro, a shared timer for all the members of an Agile team. By sharing a common timer, all the team members can have pauses at the same time; so, there's nobody hanging around speaking or joking when someone else is working.

We are trying to apply this in our Agile team, without much success. The main area of debate is focused on pauses: a lot of times the developers keep working for 1-2 minutes after the ring of the timer, and then they want to take a 5 minutes break like their team partners. But in a shared timer environment, this is not possible. Shared pomodoro should also mean shared pauses.

Also, when somebody is on a difficult task at the end of a pomodoro, and wants to finish it before having a pause, it's common that he needs more focus and concentration. This is really difficult if the other developers are pausing, and talking loudly in the same room.

Another problem we had with pauses was that they sometimes extended after 5 minutes.
In our latest retrospective, a week ago, we decided to ban the usage of personal laptops during the 5-minutes break, to remove on of the most common sources of oversized pauses. However, some of the pauses lasted more anyway, because somebody was going out of the room to get a snack, smoke a cigarette, go to the toilet and so on.

Personally, I don't think that forcing all the team members to finish exactly at the same time and start over exactly at the same time could be more productive than leaving each couple free to take its own rhythm. If a couple works 28 minutes and then takes a 5 minutes pause, they're not working less than a couple doing 25-5. But I think that the couple working 28 minutes still needs a 5 minutes pause, and it wouldn't be correct to force them to a 2 minutes pause just to keep the shared pomodoro rhythm alive. I know that the strict application of the Pomodoro Technique would prohibit any work after 25 minutes, but in my experience I think this doesn't compromise the technique effectiveness too much. After all, the technique leaves space for flexibility in the pauses duration (both short and long pauses), so even applying it strictly could lead to not synchronized couples.

I've read on the Pomodoro Technique official mailing list (http://tinyurl.com/l55un2) that some other teams tried using a shared pomodoro without much success. At this point, I think the best solution is having a pomodoro for each couple. It has its downsides too, but IMHO they can be overcome much more easily.

Don't leave juniors on the bench

Recently I've read many articles about how to choose the best junior developers, and how to train them. This is an hot topic for project managers, as they need to have good and cheap developers: usually, this also means "young" developers.

I still haven't found any article, though, approaching this subject from a psychological point of view. Typically, these writings are about technical training, or maybe about how to productively insert a junior resource into a team: but not about how to make the junior motivated to give everything for the project.

I think it's a really different situation from inserting an already expert developer into a team. A young developer still needs to understand almost everything about team work, daily planning, and so on. Sometimes universities don't give them any hint about the situation they'll find in a real work place, so it's time for them to find out. I suggest, let them find out the hard way.

A young developer needs to be involved in all the team activities. He really should be able to write a lot of code, discuss planning, design and so on, since the start of his work in the project. In an agile team, this means that he should write code at least as often as he drives his pair; he should be able to speak while the team writes down user stories, and participate actively to retrospectives.

Don't care too much about the impact this could have on both the developer and your team: in the worst case, you'll have a small loss of productivity, but we'll discuss this in detail later in this article.

I think a good analogy can be done with football. Yeah, I wrote football - after all, it's a team game, where the cohesion between all the team members is important to achieve success.

In a football team, as players get old, young players come in, and they need to be inserted into the first team. This process can be really difficult, no matter how good the young players are: for a coach, leaving the 33 years old world-class striker on the bench and throwing the 17 years old promise on the field, could result in both a success or a failure covered with critics.



However, if you ask any football coach what's the best way for young players to improve, they will answer the same: experience. They need to *play*. A young player, if left on the bench, can not grow, even if he has the chance to train with the best footballers in the world. He needs to feel the adrenaline of important matches, receive the ball and face the toughest opponents.

Going back to our junior developer, it's exactly the same situation. If you want him to improve, you must not leave him on the bench, thinking that time will help him.

Such a cautious and mild approach could result in a demotivated young resource, compromising both his morale and his productivity. Also, you'll need a lot of time to evaluate his real skills.

You should let him code, even if he's half as fast as your other developers, and hear his opinion about the practices of your team. Involve him in all the team activities, and try to teach him what he needs to start working with your team.
Obviously, this can be done only if he has at least some basic skills, but choosing the best young resources is another topic - I won't dwelve into this right now.

Maybe you'll realize he's such a good developer that after some weeks he'll be perfectly inserted in the team, contributing interesting ideas and giving a productivity boost, but even if this takes more time, it's the right thing to do.

Such a steep approach is obviously not productive in the first weeks, but as time goes on, you'll be able to evaluate better not only the technical skills of your junior, but also his resistance to pressure and work load. These characteristics are as important as the technical skills, maybe even more, so finding them out is definitely useful.

Shared pomodoro - to share or not to share?

Last week a very interesting discussion emerged in our Agile Team. We are 10 developers, and we all work in the same room. We use the popular "Pomodoro Technique", conceived by Francesco Cirillo, to organize our daily work. If you have never heard about it, visit www.pomodorotechnique.com; shortly, its main characteristic is that it divides the daily work into very small iterations called pomodori, all of 25 minutes, separated by regular pauses of 5 minutes.

The technique works really well; we had some discussions about the nature of timers - somebody loved the kitchen mechanical ones, somebody else was irritated by their ringing sound and preferred software timers. But apart from this, there were no problems.

A month ago, we added two couples of developers to our team. The new guys came from another popular Agile team, and they proposed the idea of a "shared pomodoro": an unique timer being shared by the whole team. The Pomodoro Technique defines clearly how to setup work iterations and pauses, and it's also really strict about the need of stopping work exactly after 25 minutes; so, there's no reason for not synchronizing all the developers.

Before this fact, we didn't follow the technique too strictly; somebody prefered to work for 50 minutes and take a longer pause thereafter; others used pomodori just to track their work, without caring too much about pauses duration.

As you can imagine, the shared pomodoro is quite difficult to apply in such an environment.

Let's try to summarize briefly the advantages of a shared pomodoro:

- pauses are shared too, so the whole team can have a pause together;
- when you're working, everybody else is working too; so, you don't have distractions from other people having a pause;
- there's more discipline: all the developers have to keep the same rhythm, even if they're tired;
- the team actually behaves like a team, and this common practices may increase the cohesion between the team members.

The disadvantages of the shared pomodoro are almost symmetric:

- if you *really* need to take a pause, for any reason, you break the team rhythm;
- if you want to work for more than 25 minutes without a pause, you can't;
- every time there's a pause, the whole team has to wait for all the team members coming back to the open space (but hey, this is called discipline!);
- the team behavior looks more chaotic, and it's more difficult to organize common activities.

So it's mostly a choice between discipline and relaxed rules. It's not easy to choose which solution is the best for you, or which one will give you more productivity. The author of the pomodoro technique, Francesco Cirillo, reports that studies have been made to find the maximum time a human brain can keep concentrated on a single subject, and the average value found out is 25 minutes. So, if his theory is right, following the technique strictly is the best way to keep concentrated, work better and consequentially improve productivity.

Enough said? Not exactly. In the previous statement, there's an important word: "average". This means that the "25 minutes" value is not the same for everyone, or for any situation. Sometimes it may happen that you work on a really hard subject, and after a pomodoro of work you need a slightly longer pause, because you're tired; some other times, you're feeling a good rhythm, with many tests passing, and you want to take a shorter pause. This kind of behaviour is definitely not compatible with a shared pomodoro.

If you want to decide whether a shared pomodoro is right for your team, try to ask your team members how confident they are with the rhythm described by Francesco Cirillo. If they're already using the technique strictly and they feel confident with it, you can try out the shared pomodoro for a month or so, and then decide whether yo keep it or not. Otherwise, you can try to tend to it, if you feel that your team is too chaotic.

The only approach I find not correct is imposing a shared pomodoro from above, without asking any opinion to the team members. This may lead to unhappy team members, cause they could feel their freedom and creativity is constrained by a timer. If all of your team members feel like this, maybe you should put the shared pomodoro apart - or find other team members! :)