Posts Tagged ‘interesting’

Apache Maven, 2eme édition

décembre 12, 2011 2 commentaires

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!

Étiquettes : , , ,

Book: Patterns of Enterprise Application Architecture

I have a hate/love relationship with IT books. Really. On one hand, I love to read them. On the other, when they’re good enough, I feel compelled to blog about them. And it bugs me so much I’ve to do it before being totally free for some other books. As such, let’s speak of Patterns of Enterprise Application Architecture, by Martin Fowler.

As said in the title, the book is all about enterprise patterns and actually does it very well. Indeed, crazily enough, there’s more in IT than just the Gang of Four patterns… Stuff like optimistic (offline) locking, the Active Record pattern, Gateway and way more.

The book is divided in 2 parts: first Martin walks over what he calls « The Narratives ». There the stage is set, and the general issues are introduced for the reader to get a proper overview and understanding. Layering, mapping aspects, transactions isolation levels, ACID implications, session, remoting… All these concepts are nicely put together.

Then each pattern is seen in details: how it works, when to use it and some examples (mostly in Java, but C# and maybe some others are also covered). The presentations are well done, presenting pros and cons as well as the various way to implement each of the patterns.

The book shows hardly its age, having been written in 2002. For example, Dependency Injection isn’t spoken of. Similarly, at the time, XML was fancy, so Martin Fowler speaks of it several times, which is funny in retrospective. Still, most of the patterns are still relevant and are important to know, so it doesn’t matter.

In the end, I wish I had read this book (or learned its content) when doing my Computer Science Degree. Indeed, since, I’ve come to know them, but it’s really because I’m interested in the topic. Yet they are of the uttermost importance for anyone in the field. They should be basic knowledge, in order to have a better understanding of the problems at hand, communicate properly between practitioners of the art and not reinventing the wheel .

Furthermore, the extensive coverage of the book should still teach some stuff to most of us.

For example, Kent Beck at some point speaks of remote computing, saying that remote interfaces tend to be coarse grained, whereas local ones are fine grained. Indeed, when going over the network one wants to have as few calls as possible, whereas locally one wants clear intentions and fine control. While obvious, I wasn’t so aware that one interface would be at pain to serve both purposes.

I also loved Martin Fowler First Law of Distributed Object Design: Don’t distribute your objects!

Still, I’m only scratching the surface of this 500+ pages. Martin Fowler was nice enough to provide an online Catalog of Patterns of Enterprise Application Architecture, which should help to get a better view of the book’s content. Since the book publication, a new pattern was also made available online, the Domain Event concept, which is worth looking at.

One more thing: the book is part of the « Martin Fowler Signature Book » series, and thus has a proper hard cover and a nice red bookmark fabric. Cosy and very useful 🙂

To sum up, very nice book to get quite some overview of the general concepts at play in enterprise architecture. Almost a must read actually.

I stop here otherwise I fear I’ll write more than there’s in the book 😉


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.

Étiquettes : , , ,

Livre : The Pragmatic Programmer: From Journeyman to Master

juin 30, 2010 1 commentaire

[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


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 !

Étiquettes : , , , ,

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!).


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 !

Étiquettes : , , , ,

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

février 11, 2010 1 commentaire

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

Étiquettes : , , ,

Agile Tour in Strasbourg – (partial) feedback

octobre 31, 2009 Laisser un commentaire


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 😉


Étiquettes : ,
%d blogueurs aiment cette page :