Apache Maven, 2eme édition

Cet été (si loin déjà!), Pearson m’a envoyé un exemplaire gratuit du livre Apache Maven 2 et 3, 2eme édition, grâce à la sympathique entremise d’Arnaud Héritier et Nicolas de loof.

Bien que j’ai dévoré le livre dès réception, la présente critique a été retardée par un déménagement/changement de taff. Ceci dit, mieux vaut tard que jamais, et maintenant que le contexte a été posé voyons pour une critique sans faux semblant…

Alors, que dire d’Apache Maven 2 et 3? Pour les pressés, en quelques mots: si vous sentez débutant/intermédiaire en Maven, foncez. Si vous êtes expert et cherchez à tuner votre Maven, passez votre chemin.

Pourquoi foncez? Tout simplement parce que le livre réussi à bien mettre en avant tout l’intérêt et la force de Maven, abordant les multiples domaines d’usage, sans sombrer dans le guide de référence infâme et soporifique (et supplanté par internet depuis que l’ADSL existe), le tout avec un mode narratif franchement agréable passé la surprise initiale (il s’agit en effet de Nicolas et Arnaud narrant comme telle ou telle personne ont eu tels soucis et comment cela a été résolu). Et comble du raffinement, nos deux comparses fournissent en chemin des trucs et astuces pour des problèmes "courants" qui, perso, m’ont bien servi depuis.

Certes, tout un chacun trouvera des aspects qu’il aurait souhaité voir plus approfondi, mais c’est également une des forces du livre: il pousse à aller de l’avant, tout en donnant les bases pour qu’on se sente capable de le faire. A l’inverse, il ne cache pas certains aspects encore perfectibles de Maven, tout en fournissant assez d’info pour que le lecteur ne soit pas démuni.

Je ne ferai qu’une critique négative de taille: les auteurs tentent de rassurer sur le futur de Maven, entre Sonatype et la fondation Apache. Et perso ils ont produit tout l’effet contraire. En effet, si on lit bien que les deux organisations sont faites de personnes pleines de bonne volonté, on devine également aisément que des tensions sont présentes, sans en avoir le détail, tout en voyant de façon évidente les contradictions des deux approches, entre le rythme mesuré de la fondation Apache et de ses règles et le dynamisme zélé (et intéressé) du papa de Maven et son équipe.
J’ai également ressenti un certain flou sur les produits Sonatype. Comment s’intègrent ils avec le reste? Où commence le domaine payant? Quelle stratégie est suivie par Sonatype dans tout cela?
Bref, ça manque de vision d’ensemble, à mon sens, ainsi que d’une présentation claire et sans ambages des tensions présentes (ou passées, j’en sais rien moi) histoire de poser le cadre.

Avec le recul, toutefois, cette critique s’atténue pour laisser place à la gratitude de se servir au quotidien des conseils et de l’inspiration générées par ce bouquin. Aussi, vue la période, je concluerai simplement: un parfait cadeau de Noël pour geek ou geekette!

Allez, bonne lecture à tous et encore merci à nos deux auteurs!
++
joseph

Book: Implementations Patterns

In Implementations Patterns, Kent Beck focuses on "low level" advices. It’s all about how to write nice, readable and maintainable code.

Such a narrow focus is good and provides a nice occasion to think on one own’s habits.The extensive thinking put down in the book quite often put words on feelings/intuitions one can have while coding. It makes them explicit/obvious and helps to think more rationally about them. It also put new light on different aspects, widening the comprehension.

The chapter "Theory of Programming" is also pretty nice, esp. when addressing flexibility. Indeed, flexibility is about being able to change easily the code, not providing the user with hooks all over the place to change everything in the software. Insisting on code readability is also always welcomed and well put in perspective. It somehow managed to feel more convincing than previous readings I had on the topic.

Yet it isn’t all nice in Implementations Patterns. The term pattern feels often overstretched. Kent Beck is mainly just browsing through the available options in Java and discussing their pro and cons. Sometimes it feels obvious and a bit overdone.

The chapter on collection performance feels also a bit like "space filling" rather than helping achieving the book goal. A nasty voice inside of me can’t help noticing that for a 129pages yet 45$ book, it’s comprehensible…

A point has also really surprised me: Kent Beck speaks of final fields and says he usually doesn’t bother writing the final keyword. He would only if his code would be changed by many people. Not only it’s contradict his main motto of communication to the readers, but it’s actually a big hole in the class, both in terms of performance and maintenance… Crazy it managed to go through the editing process IMHO.

To conclude, the book is helpful and hopefully my coworkers will appreciate its effects on my code. I’ve more tools/knowledge/options to write readable code, I just have to make good use of them by now… Is it a must read ? Dunno. Maybe I start to have read quite a bunch of such books to have a feeling of "deja vu". Surely as well I’m getting older. Anyway, it was a good read, I recommend it. Whether it’s a must read is left to the reader as an exercise

Side note: for a deeper look at the book content, there’s this infoq review Book Review: Implementation Patterns which shows it well.

Livre : The Pragmatic Programmer: From Journeyman to Master

[This article is also available in English.]

Par le passé, j’ai lu des livres tels que My Job Went to India: 52 Ways to Save Your Job ou Practices of an Agile Developer et, hum, j’ai préféré ne pas en parler…

Avec The Pragmatic Programmer: From Journeyman to Master, c’est différent. L’essentiel est dédié à comment augmenter ses compétences en programmation, au sens large (comment débugger, orthogonalité, utilisation des exceptions). Chemin faisant, il fournit des conseils de bonne qualité. Si vous sentez que vous pourriez faire mieux sans savoir vraiment où demander/chercher des conseils, alors ce livre est susceptible d’aider. Dans l’absolu, de bons livres techniques, tel Effective Java, ont ma préférence, mais de façon plus générale, presque en termes de méthodologie et d’approche, The Pragmatic Programmer: From Journeyman to Master peut aider.

Certes, je ne suis pas 100% d’accord avec ce qui est écrit. Je ne suis toujours pas un expert emacs et je n’envisage pas de l’être. La génération de code n’est pas que du bonheur, surtout si fait de façon statique (c’est à dire à un autre moment qu’à l’exécution). Mais cela n’enlève rien de la facilité et du plaisir de lecture global. Les chapitres vont droit au but sans pontifier. L’aspect pragmatique est, j’ai trouvé, ressenti.

Il est à noter que depuis la parution de ce livre, en 1999, et des suivants (susnommés), le web présente bien des ressources intéressantes sur le sujet. Par exemple le wiki 97 Things Every Programmer Should Know (qu’un google translate devrait pouvoir rendre accessible à des francophones purs, à défaut une traduction doit pouvoir se trouver voir même s’envisager). De telles ressources ont un intérêt similaire.

Au final, je ne pense pas que des livres, à eux seuls, puissent permettre de progresser réellement et efficacement en solitaire. Dieu merci, il existe désormais internet où il possible de trouver de bons programmeurs (cf Igor Vaynberg par exemple), voir même parfois de pousser la chose jusqu’à bosser avec eux… D’ailleurs, ne dit on pas "Qui ose gagne" ? lol

++
joseph

ps : lorsque je cherchais à remettre la main sur cette page avec ces 97 astuces, je suis tombé sur ça en chemin : 97 Things Every Software Architect Should Know. Et j’ai vraiment apprécié celle là : "Simplicité avant généralité, utilisation avant réutilisation". A méditer !

Book: The Pragmatic Programmer: From Journeyman to Master

[Cet article est également disponible en Français.]

In the past, I’ve read books like My Job Went to India: 52 Ways to Save Your Job or Practices of an Agile Developer and, well, I prefered not to speak about them.

With The Pragmatic Programmer: From Journeyman to Master, it’s different. It focuses itself on how to improve programming skills and, for that, provides mostly good advices. If you feel you aren’t doing good enough and don’t really know where to go/ask for advices, this book could help. Still, good technical books like Effective Java would have my preference, but on a more general level The Pragmatic Programmer would still help.

Yet, I don’t agree with all which is said in the book. I’m no emacs expert and I don’t intend to be. Code generation has drawbacks as well.

Still, it’s an overall easy to read and interesting book.

However, since, stuff like the "97 Things Every Programmer Should Know" wiki page have popped up and may provide just as much.

And in the end, the more I think of it the more a proper tutor looks like the way to go. You can’t become a master just by reading books, and most probably neither by trying it all alone. Thanks god we have the web and good programmers around (if one is daring enough to go and work with them!).

++
joseph

side note: on my way to find again this "97 tips" page, I got into this one as well: 97 Things Every Software Architect Should Know. And I really liked this one: Simplicity before generality, use before reuse. Something to work on I fear !

Book review : SCJP Sun Certified Programmer for Java 6 Study Guide

In order to get ready for the SCJP 6 exam, I’ve read SCJP Sun Certified Programmer for Java 6 Study Guide, from Katherine Sierra and Bert Bates, aka some of the certification’s exam creators.

The authors make clear at the beginning that the book is about, and only about, being ready for the SCJP exam. No more, no less. And they keep to their words : the book is strictly focused on the exam.

The bad consequence is that sometime (often) I was eager to know more, to go further the "there’s plenty more to tell, but that’s enough for the exam, so we stop here". Furthermore, as you can imagine, this isn’t the most fancy book I’ve ever read. Katherine and Bert do attempt a few times to instil some fun, but it didn’t fall quite right.

The very good side is that the book teaches all you need to know, no more, no less. I would even go a bit further : if the authors say "methods X and Y are also part of the exam", then you should really know exactly what’s in these methods. I’m pretty sure I lost some points due to some API I didn’t know enough. Even better, they say clearly what’s in the exam and not. No need to worry because some dumb mock exams found on the web put stuff you hadn’t any clue off. If it wasn’t in the book, it’s not on the exam.
Even more important, the writers are very good at explanations. Really, they know out to make things clear. Awesome. I now have a grip on regexp. Really !

To conclude, this book is really one (if not the one – I haven’t read the others so it’s hard to tell) to go for when preparing SCJP 6, no more, no less. At least it was for me!

++

EDIT : did a bit of clean-up

Agile Tour in Strasbourg – (partial) feedback

hi

I went yesterday to the Agile Tour 2009 event in Strasbourg. Overall, I was fearing it to be a bit dull, the program looking not so attractive. Yet I found it quite interesting and worth the time spent. Maybe low expectations helped, I don’t know, still I’m happy of this outcome.

Let’s dig through it in more details

First, I went to Stéphane Becker talk. In fact, it was a feedback from his XP implementation. Indeed, working in the video game industry (in Strasbourg, crazy!, in a company named Creative Patterns), the first project he did was quite a hell (80h and plus per week of work for the last 8 months) and as such they decided to act upon it. It was in the very beginning of the 21st century (2000 or 2001 I don’t remember), so they went for XP.

Among the interesting bits is the fact that they went for not having titles in the dev. teams.

Indeed, they had the feeling that it was stopping members of the team to feel/be responsible of their act, under the assumption that the guy with the higher title would do it (or at least would have to do it). Furthermore, the idea was that one should be proud of his achievements and actual work rather than some "dumb" title saying nothing in the end. The outcome is, apparently, what they were aiming for : each one is the team feels now "responsible", and they see quite often each team member taking naturally the lead "from time to time", depending on the topic, all without external action or internal discussion. Thus, it looks like quite effective on team empowerment.

Still, it raised the question of how to evaluate/pay each guy in the team. First, the answer was that it was all team based : all the guys have roughly the same salary and share the team’s fate… Yet, after closer interrogations, it came up that the salaries were linked with each one experience and skills, thus breaking this "one pay for all" rule. In the end, I’ve no clear picture of how they do to evaluate/pay each guy, even if this choice of "no title" rings some bells.

In less details, these parts were also of interest :
- at first, they went for paper based issues lists and the like. However, for follow up, they ended using some software (from what I got it’s this Agiletrack software I never heard of before). However, now, they put the issues on paper (on "post-it") for the planning meetings, because it helps quite a bunch to deal with it efficiently…
In the end, I’ve more and more the feeling that that having both papers and software looks like the (unfortunate and required) way to go. If anyone tried Henrik Knibberg "paper/dashboard only" approach, I’m eager to hear/read feedbacks !
- Stéphane had this nice sentence : "Agile is just about giving the proper occasions to communicate for the team". I deeply agree with this : all these fancy words and tools should not forget about the final aim of better communication.
- when planning for more than the next sprint, like planning for the next batch to be delivered to the customer, they involve the team members which will do the development, apparently on a "per feature" basis. The idea is to get them on board as soon as possible (better for their involvement and for the overall precision of the estimation). I was quite interested in this because Agile Estimating and Planning always speaks of the whole team, which sounded a bit too much to me.

Hum, I’ve been writing more than expected and it’s getting late… Well, I guess I’ll dig into the others sessions another time ! So stay tuned for more on "exploratory test" and Pomodoro

++

Book review : Maven: The Definitive Guide

I’ve recently finished Maven: The Definitive Guide. It was the paper edition, since I muss confess I didn’t manage to go through the pdf edition.

Still, I found the book rather interesting and quite well put. It’s not as enlightening and breath cutting as some others, but at least I was able to read it without effort. Some bits, for example where each setup options are presented, are a bit boring, but otherwise it provides good insight on most of Maven, including m2eclipse and plugin creation. Furthermore, there are pages I already know I’ll read again later, like the example projects they provide and the different strategies used there, to make more sense out of them (now that I’ve a better overall understanding).

I would do only one reproach : the explanation about how maven resolves dependencies lacks depth, notably regarding snapshots.

Overall, I would advise it for an average user of Maven willing to get a better understanding of it (I now know where this "mojo" word comes from !).

Book review : Clean code

hi

I recently finished Clean code, from Robert C. Martin (well, in fact it’s mainly from him and some guests, but then..).

Anyway, the focus of this book is how to write clean code, meaning readable and maintainable code. For this, the authors go at length on the different aspects, dedicating whole chapters to aspects like "Meaningful Names","Functions" or "Comments".

At first glance, these chapters can seem a bit boring, containing mostly "common sense" point. However, all put together, I really have the feeling to understand way better how to write clean code. We all know that methods should be short. But who does so actually ? Now, I try to : the book really convinced me of applying these "rules". And I really feel that my code is getting more and more readable… Nice feeling, enough, I would say, to recommend reading this book !

However, don’t expect a "perfect book" similar to Effective Java. Indeed, some chapters are either way too superficial, like the one on concurrency (and even the appendix on it), or simply boring : the refactoring examples aren’t compelling at all. They even seem a bit odd, since this book isn’t explicitly about refactoring (more on these kind of books another time lol).

Finally, the last chapter of this book should please every reader of this blog :chapter 17, "Smells and heuristics", provides a summary of many codesmells (summing up most of the book), which are at least nice to have in mind.

Overall, I think this book helped me a lot to improve my "clean" code ability. It’s nice as shiny as patterns or the like, but that’s the code we write and read everyday !

I think as well it’s the kind of book worth being read again after some time… In fact, I was already reading it again recently. I found some interesting points on the "introduce null object pattern". Even better, some topics covered matched exactly some issues I had encountered just before, providing very good food for the mind !

++
joseph

Book: Enjoying Web Development with Tapestry

Kent Tong has a very didactic way of explaining the Tapestry framework. He explains the fundamental aspects behind the framework from a general point of view, and then provides very consistent and precise examples.

In his book, Kent Tong shows first the Tapestry framework and its way of doing things. Then he explains how to integrate the framework with others, like Hibernate or HtmlUnit. Thus, with this book, one can approach web design in all its aspects, which is fairly important. The interest of Kent Tong examples are such that I’ve used them in different contexts than Tapestry. Indeed, he explains both the details of the implementation as well as the impacts, all being done with clarity and precision.

Important to notice as well, Kent Tong has regularly provided updates or corrections of his book. For example, when I bought the book, only Tapestry 4.0 was covered. Then Tapestry 4.1 appeared. Short after, Kent Tong provided an updated version of his book covering Tapestry 4.1 (which introduces some fairly important changes).

Finally, personally, it’s the best framework introduction book I’ve read until now.

NB : Just a last notice : eventually, I didn’t retain Tapestry.
More details on Agile Skills.
Review written first on developpez.com.

Livre: Enjoying Web Development with Tapestry

Kent Tong a une façon très didactique de présenter le framework Tapestry. Il explique les grands principes, montre leurs applications de façon générale puis donne des exemples précis et pertinents.

Dans son livre, il présente d’abord le fonctionnement intrinsèque de ce framework, puis montre des explications pertinentes d’intégration avec des framework tiers, tels Hibernate ou HtmlUnit. Cela permet donc vraiment d’aborder la conception de site web de façon globale. La pertinence est telle que j’ai réutilisé ces exemples d’intégration dans d’autres contextes. En effet, Kent Tong explique tant les détails de réalisation que la portée de ceux-ci avec clarté et précision.

A noter également que Kent Tong a régulièrement fait parvenir des corrections ou mises à jour de son pdf. Par exemple, la version que j’avais acquise l’année passée couvrait uniquement Tapestry 4.0. Puis Tapestry 4.1 est apparu, et peu de temps après Kent Tong a communiqué une version à jour de son livre couvrant Tapestry 4.1 (qui introduit des changements notables).

Au final, personnellement, c’est le meilleur livre d’introduction à un framework que j’ai vu jusqu’à présent.

NB : Je tiens toutefois à préciser que je n’ai pas retenu ce framework.
Plus de détails sur Agile Skills.
Première parution de cette critique sur developpez.com.