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.

Book: Domain Driven Design

When I first started to work, I knew I was doing crap. Yep, really. We were using old stuff, copy/pasting heavily, editing config files by hand before deploying in production and so on. However, knowing you do crap doesn’t help you doing right, even if you had the occasion.

As time went by, however, I was lucky enough to work with real Software Developers, craftsmen as we would say today, learning a lot on the way.

Yet, even these bright guys were sometimes uneasy. Not on technical stuff, not on infrastructure, but, well, you know, on the classes and the like you’ve to do for your customer. How shall we split the different parts of the requirements? What should be top level code or just "code that works", intended not to be touched more afterwards. To which extend shall we integrate what’s the business requires, or shall we adapt it a bit to our stuff ?

Yet, these foggy stuff are the value of an application. Customers don’t care too much about how nice your XML described UI is. Nor does he care too much about maven and the like. He cares about these (often messy) code doing what he asked for. The code which enables dealership to get their good in time. The code which triggers automatically some buy on some mutual funds. The code which allows to display the breaking news. The user’s code. And on top of that, whatever the nice technical layers around, if the users’ domain is badly understood and/or translated into code, then it’ll be a mess and massive pain to work with.

Domain Driven Design is all about this code which actually is, or at least should be, the heart of your application. This "domain" code is where the real value is. Ṫhe book makes the obvious visible again: the domain, the users’ stuff, is what matters. Even better, the books describes plenty of means to handle this part of your application, from quite low lever to high ones. How to handle large domain. How to refactor towards greater insight (a chapter title actually). It even has a chapter called Strategic Design, speaking about how to handle these different domains which always coexist, and how to make the best of them. Most important of all, the books is all about the UBIQUITOUS LANGUAGE.

The uppercase is not mistake: the UBIQUITOUS LANGUAGE is what allows users and developers to understand each other effectively and over time. It matters. The UBIQUITOUS LANGUAGE deserves its uppercase. And by doing so constantly in the book, with the core concepts, Eric Evans makes it obvious what matters or not. After reading the book all these big uppercase words will stick to your mind with ease. ANTI CORRUPTION LAYER. REPOSITORIES. BOUNDED CONTEXT. They’re all still there

To tell more about the UBIQUITOUS LANGUAGE, it’s the language used to describe the domain, both by the users and the developers. It is should be reflected in the code. And, of the highest importance, is should evolve with the comprehension of the needs. This is the domain. This is the added value of your work. Eric Evans takes care of showing ways to handle this UBIQUITOUS LANGUAGE and make it pervasive and effective. His examples are clearly first hand ones, which smell and look like what you could expect tomorrow (or on Monday rather lol). No big word on SOA or Agile Manifesto. No, just how to make your users needs properly fulfilled. On top of that, the author speaks of organization at the code level and higher ones (like what to do with big blobs of codes or legacy systems). This uncommon "elevation" is very nice and helpful. Speaking of more than the GOF patterns as a way to make your code base intelligible is very nice. In fact, the book’s title second part "Tackling Complexity in the Heart of Software", is true and right to the topic.

I guess you got it, I liked this book. It makes you think and ponder often, on your current practices and on "industry wide" ones. Like the habit of affecting the best developers to the infrastructure teams. Common isn’t it ? These top notch guys can then develop some stack able to solve both desktops and web needs, transparently and recursively. Sounds all good, but is this what your users want ? They want their needs fulfilled, they want their reality to be tackled. And whatever your bells and whistles, if you can’t move stuff Y to point 1243, it’s no help.

Well, I fear I’m too verbose. By the way, the book is quite verbose as well. More than 500 pages and extensive texts. Reading it took quite some time, even if I liked it. It was just big, both in volume of text and on impact of its content. But it didn’t go in the way, apart that at the end I was wondering about stuff explain at the beginning. But then, no big deal: for sure I’ll read it again.

To kind of conclude, this book is the last bit of theory I was missing towards making great software, in the long run, in a sustainable way, for the users. It has already changed the way I approach design and it looks like my users felt and liked it already.

I already said too much: I’m off !

++
joseph

Book:Foundations of Security

I have finally finished Foundations of Security: What Every Programmer Needs to Know. Yep, finally: it wasn’t done too easily.

Indeed, the book felt really dry. Nothing in it gives this willingness to read late into the night. Rather the other way around, it would make me fall asleep quicker.

However, it doesn’t say much about the content of the book. And there, this book clearly aims to be kind of exhaustive. Pushing it even a bit too far, like enumerating all the devices able to store a password, from PDA to file or code source. Still, this kind of completeness is a nice refresher.
It helped as well to have a deeper understanding of facts I knew about security, like precisely why/how Javascript is bound to the page domain.
Similarly, the book pointed out some potential issues I could have overlooked. Info leakage, esp credential, wasn’t present enough in my mind, notably through referer headers.

Regarding security practices themselves, I felt like this book was either too technical for a non IT guy or too simple for an IT guy. My case being more of the latter, I often felt frustrated by the lack of technical depth, the suggested solutions being quite often already known. Furthermore, this kind of enumerative text used made technical bits quite repetitive. I sometime asked myself is some stuff wasn’t already described earlier, or if I hadn’t already read it. It wasn’t the case, but the commonalities in presentation, description and structure really didn’t help.

At the end of the day, I don’t regret having read this book. My knowledge on security is now firmer. Yet I’m pretty sure some other security books exist which are more instructive and/or enjoyable to read.

++
joseph

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

Book: Don’t make me think

I had already read some books on usability. The last one had about 400 pages and lots of texts. It laid out 10 (or 12) rules regarding usability. I can’t even remember one !

On the other hand, Steve Krug’s Don’t make me think is still deeply in my mind. Not only the author applied usability to his book (about 200 pages, very easy to read with drawings right to the point), but, even better, what he wrote is enlightening.

First, Steve Krug introduces the "guiding principles", all evolving around his First Law of Usability : Don’t make me think. Simply put, the aim is to remove all questions, even unconscious ones, when browsing the web. All these littles inconveniences or inconsistencies which go in the way must disappear. And Steve Krug presents this with way more skills and drawings than I do, making it really impressive and long lasting.

He goes on speaking on the way we use the web (scanning, not reading), than that we should "Omit needless words".

These first chapters are still vivid in my mind. They come with very relevant examples that we’ve all seen before, and thus that we’ll see again in the future, bringing back the good stuff of this book.

Then, Steve Krug goes on a more general level : why/how to avoid these endless discussions about "mine design is better than yours", how to do "real size" usability tests (and not the ones requiring huge resources/teams/testers/rooms/… as was put in this previous book!) and how to deal with Pointy-Haired Bosses. Less crazy than the first chapters, but really helpful.

Overall, this book really helped me. I now have quite a tool set (and mindset) to deal with usability questions. To put it shortly, I feel now empowered on this topic, quite a change from my previous readings.

To conclude, if usability is remotely some of your concern (and you don’t know it all already), read this book !

++
joseph

More details on Advance Common Sense.
Review written first on codesmell.

Book review : Test-Driven Development By Example

hi

I’ve recently read Test-Driven Development By Example, a book from Kent Beck.

I’ve liked the following:

• description of the TDD cycle : Red – write a little failing test/Green – make the test pass quickly, even if it involves dirty tricks or duplication/Refactor – make the code clean, including hunting for duplicates for example.

  The emphasis on making the test working quickly first was a bit unexpected to me. Indeed, I tend to try to write "clean code" first. It’s not bad in itself, but it happens sometime that I’m not confident with the design. Thus, I feel uneasy. Smaller steps, maybe less clean, would probably help: seeing a green bar is always a good feeling. This leads me to the next point.

• Kent writes that one of the key point of TDD is about reducing stress : being able to do small steps reduces the stress/fear level, hence fewer errors and better feeling. If the target design is unknown or intimidating, use (very) small steps.

  As pointed before, I wasn’t really aware of this, even if I appreciated the final feeling one has after writing proper unit tests. I’ll try it

• The notion of "emerging/organic" design is as well spoken of. It’s the idea that with proper TDD the design will evolve to fit exactly the needs, no more, no less. A kind of perfect match in the end.

  I had already heard of it but it was a nice refresher. Still, it doesn’t fit with our actual practices : we tend to prototype first the design.

  But maybe once I should try starting with a very easy and naive implementation and see where it goes. After a few refactorings, it may end at the same design, or may be even better. Still, I fear it would take more time and I’m unsure about the results.

  On the other hand, as told by Kent, if ever the code has to evolve to become more general, this can be done easily, with the tests providing the required safety net. Then, how many code are designed with a way broader scope that they’ll actually use, leading to verbose and/or a bit inappropriate abstractions ?

  Once again, feedback is welcome, and anyway I’ll test it.

• TDD helps narrowing and keeping focus. That’s a big reason for the small steps, one thing at a time, so if something behaves in a unexpected way it’s easy to spot early.

  But Kent pushes it further : when doing TDD and using "dirty tricks" to get the green bar, he suggests writing done a list of the stuff left to do. He does so as well for other related ideas popping up. The aim is to keep focus on the current work, coming back later on the todo/improvements noted (which in turn, for sure, can/should be done test first ). He suggests using a good old paper list, and simply to strike the work done. As such, progress can be seen easily and is quite satisfactory. Furthermore, the overview is always present and one can easily pick the easiest/smallest stuff to do, for example just before leaving.

  Said this way, it may sound obvious, but the fact is that we tend to lost focus when doing pair programming. Maybe Pomodoro could help us, but this way of doing as well. Again, it’s worth a try !

Still, the book wasn’t only joy to read. The first 80 pages are a TDD example where Kent Beck uses very small steps. Personally, it really went on my nerves. Furthermore, he complains about some lack of features in Java which have been added since (the book is from 2003). It didn’t help neither.

He finishes the book with a small chapters on different patterns, like "red bar", "green bar" , testing, xUnit, design and refactoring. If you have a bit of practices regarding unit testing and if you have knowledge on patterns and refactoring (personally I’ve read books like Refactoring and Head First Design Patterns), there is few to learn there. Only the null pattern did interest me and will be the topic of another post. I wish he has spent more time on testing, like which code coverage to aim for (and why), gui unit testing and common pitfalls.

Maybe some answers lie in the "Testing Object Oriented Systems: Models, Patterns, and Tools" which he presents as "the comprehensive reference on testing". This time is a 1000 pages book, sounds intriguing lol

++

Side note : I often wonder if my reviews aren’t too verbose… I would welcome feedback on the matter !

Book: Scrum and Xp from the Trenches

At work, we’re currently reviewing our Agile process. So I thought it was a nice occasion to read again Scrum and Xp from the trenches, esp. since we have a paper edition of it.

Simply put, this book is why I started to be so much interested in Agile software development : the process it described is really compelling. The author hardly presents what is an Agile process (from a theoretical point of view), rather it dives immediately on how they did it. Still, he provides the different choices they faced and explains why they went for such or such solutions, all in order to accomplish the various “agile steps” which are to be done. It really enlightens the reader, helping to grasp properly what it’s all about. Furthermore, it gives ground to the author’s claim that it’s just how they did it : one gets easily that’s adaptation is the key, that Agility is not a stone graved process. This helps to consider it’s own environment with a fresh eye.

At the end of the book, I had the feeling I had a proper overview of the whole process, on how these teams worked. Added to the explanations on why they choose such solutions, it makes it all reasonable, sound and efficient. Attractive and, hosnestly, a real breakthrough compared to all these RUP, ITIL and others crappy acronyms. What else could we expect from a process ? It actually seemed like helping and being efficient ! Crazy ! The only question I had left was “when can I start ?” (which is part of the reason I moved to Thomas Daily by the way lol).

In retrospective, now that I’ve been working in a Agile shop for now 7 months, the book didn’t answer all the questions I had since. Furthermore, more theoretical books have helped me really grasp why such a process was working, that it was all about the empiric nature of each IT project. Still, when coming back to this book, it was once again compelling. Going through the experience and writing of Henrik Knibberg has helped me once again, spotting points where we didn’t get it all.

As such, I really advice this book (which comes as well as a free ebook, both having been updated since publication) for all people interested in getting Agile, how it works, what it provides or even to improve one’s own way of applying it. So don’t hesitate : read it !

++

Side note : Henrik speaks of other “from the trenches” stories in his book. I never found any, so if anyone knows some other, I’m interested !

More details on infoQ.
Review written first on codesmell.

Wanted : book/resources on Java certifications !

I’m currently looking seriously at some Java certifications. As such, Uwe kindly gave me lots of Java certification books, but they are about Java 1.2 (whaou, prehistory ) and 1.4.

Since Java 5 introduced quite some new stuff, extra resources/books would be welcome, as such feel free to comment. I’ll as well update this post with my own findings, even if I already have enough to learn with all these funky bit operators and the like… Funny how little I saw them used BTW… "Wondering about the use case am I !" (yes I played Stars War Lego recently )

++

EDIT : For some mock tests, Javaranch is the way to go, as they provide some lists of mock test sites.
For books, uwe sent me this very usefull link (thanks by the way !): Javabooks timeline. But in the end, I settled for SCJP Sun Certified Programmer for Java 6 Exam 310-065 which I didn’t find in the Javabooks site.

Anyway, I’m eager to get the book, since certification looks like more useful than I previously thought, in terms of Java mastering and understanding. It really helps to go deeper into it.

EDIT – follow up some interesting links for certifications wanna be :
- JavaRanch SCJP faq
- Java keywords… special mention for true, false and null !
- regex quantifiers…
- explanations on the String pool

Digging in !
++ (re)

EDIT : this quest is now over. Thanks all