fvrier 2010Monthly :

Scala might be useable very soon

The Scala 2.8 beta 1 announcement gives hope regarding the availability of a decent IDE for editing Scala code. We will see what Scala 2.8 final looks like, but if the eclipse IDE support features basic Class and Method renaming, I will most likely make Scala my main programming language for writing open source code that targets the JVM. Two projects that I would most likely convert to Scala would be :

  • Gisgraphy Java client : a Java library that gives access to gisgraphy City and GIS features search engine.
  • Pymager Java client : a simple Java wrapper on top of the RESTful interface provided by pymager, an image service that provides simple conversion and thumbnailing / resizing features.

Surviving with many patches

In many situations, open Source software developers need to deal with the maintenance of patches. Examples include :

  • Unofficial versions of the linux kernel, where specific patches are applied (e.g. Xen kernel, openvz kernel, ..) and need to be constantly forward-ported to the latest kernel when it is released
  • Distribution-specific changes (e.g. Ubuntu-specific changes to debian packages).

Maintaining one big diff file for all changes would clearly quickly become unmaintanable, so it looks like different approaches are now widely used instead :

  • Maintaining stacks of patches, using specialized tools such as quilt.
  • Using distributed VCS tools such as git.

How to survive with many patches describes the use of quilt. Here is some background :

“Andrew Morton originally developed a set of scripts for

maintaining kernel patches outside of any SCM tool. Others extended these into a suite called quilt.

It looks like distributed VCS tools have now superceded quilt, as far as pure software development is concerned (linux kernel, etc.). But quilt remains very popular for maintaining distribution-specific changes to packages. Indeed, as distribution packages live outside a SCM tree, it is important to have mechanisms to apply distribution-specific changes to the upstream source packages. And this is where quilt comes to the rescue.

Ubuntu packaging guide describes the use of quilt in debian’s packaging system. Such a simple system is clearly awesome, and the more I understand how the Open Source communities organize themselves, the more it makes me realize how technically advanced the Open Source world  is compared to the corporate world !

No matter how much you might have heard that tooling is unimportant, the reality is that tools are important. Tools enable complex collaboration, and this is clearly an area where Open Source excels.

http://www.suse.de/~agruen/quilt.pdf

Cumulative Flow Chart in Kanban, and distributed SCM tools

Cumulative Flow Chart in Kanban attracted my attention as I consider it a nice example of using branching efficiently.

IMHO, it is simply wrong to assume that every single task can be split into small fragments that are then iteratively incorporated into the mainline. The author calls this kind of task a “technically complex story”, and I have yet to see a successful example of migrating frameworks or doing technical migrations like that without resorting to branching. This is what the whole open source community does, and it is high time the “enterprise” world catches with these practices.

Branching then comes to the rescue ! Let the “technically complex story” evolve in its own branch, and make sure to conduct in-depth QA BEFORE the merge. Same thing for code reviews and going through the DONE checklist : make sure to do it BEFORE the merge so that you do not end up with non production-quality code in the mainline, which is then pretty hard to get rid of.

BTW, Version Control Tools gives an overview of the differences between git and mercurial, which are two wonderful SCM tools that are very branch-friendly.

Cannot stop laughing while reading this..

The worst question interview ever describes… well, just read the post and you will quickly figure out what it is about. I simply LOVE Gavin King’s comment :

Heh, and I’ll continue to be an ass in all future responses to “John Smith”s who tell talented guys who worked on my projects for years that they aren’t “team player”s, “have an attitude” and are “prima donna”s. I’ll be the judge of that, not some asshole anonymous blog comment poster who has never met or worked with Norm. I’m protective of my team. That’s not going to change. Sorry if you don’t like it.

YES, Gavin King is an ass, but most of the time, this category of ass is right, and people should just listen to them instead of complaining.. ah ah ah :) love it ! :)

PS: for those who don’t already know it, Gavin King is the founder of Hibernate…

EJB 3.1 : still not there yet…

EJB 3.1, a compelling evolution describes the new features available in EJB 3.1. It looks like EJBs are finally getting the features they miss..

However, there are still a few things bugging me :

  • Why insist on keeping the neat features (IoC, ..) server-side only ? Why can’t I just use the same mechanisms for in-container server-side code  and other kind of code ? Do I still need to revert to using Spring for everything that is not running inside the JEE6 container ? What about integrated tests ?
  • How come we still don’t have any equivalent to Spring templates, that take care of creating standardized, runtime exceptions and handling opening/closing resources automatically ?

So for now, when working in non-spring environments, I need to create my own Templates to avoid creating clumsy code…

I agree that Spring Framework is a patch, and should eventually disappear. But for it to disappear, the underlying technologies need to start being half-decent…

NoSQL

These days, it looks like there is a lot of hype around the NoSQL movement.

These data storage systems have a number of features in common:

•   a call level interface (in contrast to a SQL binding)

•   fast indexes on large amounts of data,

•   ability to horizontally scale throughput over many servers, and

•   ability to dynamically define attributes or data schema.

NoSQL explained correctly gives an idea of what these datastores are useful for, and how they complement the current RDBMS offering.

High performance scalable datastores compares the technical  characteristics, maturity and licenses of the  NoSQL offering.

Other links on the subject that might be of interest :

Pyxis à Vision PDG à Mont-Tremblant

François Beauregard, le Président de Pyxis, a répondu présent à la 10ème édition de Vision PDG qui se déroule actuellement à Mont-Tremblant. Plus de 100 chefs d’entreprises de l’industrie des technologies du Québec se retrouvent pour échanger et partager afin de poursuivre la croissance de leur entreprise. Écoutez Maurice Bergeron, Directeur Général, interviewé pour l’occasion

Making my 360 evaluations worthwhile.

Recent blog posts made on the Pyxis blog clearly show that there is a lack of trust towards the true usefulness of 360 degree evaluations. A couple of months ago, I was about to prepare my first 360  evaluation that was geared towards evaluating my own work at Pyxis over the last 6 months. As I prepared to do so, I asked my caddy to guide me through this process. To make things easier to grasp, we simply wrote down the goals I was trying to accomplish with the evaluation and grouped the by theme to see how we should deal with them.

Once simplified, the goal of my evaluations came down to two main themes :

1- Get an evaluation of my performance in order for me to be able to deal my salary for the next year.
2- Get proper feedback in order to get better within the next year.

So far so so good right? A regular 360 should help me meet those goals right ? Right ? Wrong. Totally wrong. The two goals are exactly that, two different goals and should be tackled differently. The first goal is there to evaluate whether or not I have performed to the levels that were expected by my employer and whether or not I should be rewarded accordingly. How is a subjective evaluation based on generic questions gonna help me do so ? Let’s say my job for the past year had been to be a product owner of a software developed at Pyxis. Let’s say my goals were to bring it to market within the first 6 months, to break even with the development costs within the next 3 months and to make a profit for the last 3 months of the year.

What does me having 3/5 or 5/5 on being a team player, having verbal skills, technical skills or management in a questionnaire have to do with me meeting my objectives? How about nil, zero, nada, zilch ? What might actually matters for this point is whether or not I have met those goals. Unfortunately, for most employees,those goals are seldom set in advance and/or are very seldom very clear. Too often, we learn the expectations once we get to our evaluation. Much like we set the condition of success for the user stories we develop during the XP/Scrum planning game, we most definitely should set the expectations far in advance. Then and only then can somebody be evaluated fairly.

As far as number 2 goes, in order for me to get better I need proper feedback. That’s when a properly used 360 can be useful. But feedback on what actually? In my limited experience with 360 evaluations, more often than not, when someone is asked to rate a colleague on a question along the lines of  “Shows commitment to the project” they will come up with an example on when the person showed or lacked commitment to the project. Actually, they might of forgotten all about the project and might rate you on whether or not they like you as a person or not. Why not reverse the situation and come up with the examples and then ask the questions based on a particular event ?

Let’s say I worked with Marc on a project for 3 months. Within that time a lot has come and gone. Asking him a random question will render a random answer. But if I want specific feedback in order to get better on a particular subject, I can plan accordingly. If instead I’d ask him : “On that project, we didn’t meet our deadline for 3 consecutive sprints. Do you think I showed the proper commitment ? If not, how did you feel about it what what would you suggest I should change ?” This should trigger memories based on those event and more specific feedback on a more precise theme.

Like some suggested, the 360 feedback should be done face to face. You might not want to go all the way and do it in groups, but for the audacious it’s an interesting avenue.

Also, not having the two conflicting goals might help both goals being reached. Let’s say my annual raise is based on my 360. Why should I be inclined to ask the “questions that hurt” to somebody ? If I get negative feedback I might get scared of not getting my pay raise. Who would want that? On the other hand, if I use it only for a genuine goal of getting better, I have at least one reason less not to ask the real questions.

Also, by setting your goals far in advance, you will have less excuse not the meet them. Actually, you might ask for more frequent feedback from your peers, since you have a clear goal and getting better will help you meet your goal. You will get better, and both you as an individual and the enterprise you work for will flourish from that. How about that. A frequent inspect and adapt cycle. Wonder where I heard that one before.

I hope this small recollection of a conversation I had with my caddy can help you guys or keep this interesting conversation alive.

-Nicholas Lemay

Truc podcast 2 – Une serviette, ça ne sert pas juste à essuyer!

Lors du deuxième podcast de Vox Agile : ‘Élargir les horizons’, nous avions enlevé toutes les bébelles pour empêcher les sons nuisibles, mais ce n’était pas suffisant.

Comme les micros étaient sur une table en bois, le son se propageait plus facilement. Le simple fait de frotter la table avec la main créait un bruit de fond. Nous avons donc utilisé une serviette pour couper le son.

Donc, le truc podcast, c’est:

Une serviette ou un tissu épais sur la table empêche la propagation du son.