Recommended Book: Real World Java EE Night Hacks by Adam Bien

Real World Java EE Night Hacks – Dissecting the Business Tier, Adam Bien, 2011, ISBN 9780557078325.

I highly recommend this very thin and down-to-the-earth-practical book to everybody interested in back-end Java (a basic knowledge of servlets, Java ORM, and REST might be useful). The book evolves around a small but realistic project (X-Ray), which we follow from the inception through couple of iterations til the end. Bien shows us how lean Java EE can be, how to profit from the functionality that it offers, and how these pieces of functionality fit together to deliver something useful. He actually introduces a complete Java EE development environment including continuous integration (CI), code quality analysis, functional and stress testing.

Some of the things that I appreciate most in the book is that we can follow author’s decision process with respect to implementation options (such as SOAP vs. REST vs. Hessian etc., a REST library vs. sockets, or when (not) to use asynchronous processing) and that we can see the evolution of the design from an initial  version that failed through cycles of growing and refactoring and eventually introducing new technologies and patterns (events, configuration over convention) to support new and increased requirements.

Book Review: Implementation Patterns

Implementation Patterns, Kent Beck, 2007, ISBN 0321413091.

Summary: Should you read the book? Yes, the chapter on principles and values is trully enlightening. The book in general contains pearls of wisdom hidden in the mud of “I know that already, man.” I would thus recommend skimming through the book and reading only the pieces matching your level and needs.

The book seems to be targeted a lot at Java beginners (especially the chapter on collections), going into otherwise unnecessary details, yet there are many valuable advises of which some can only be appreciated by somebody with multiple years of professional programming experience. It thus seems to me that the book isn’t a perfect match for anybody but everybody will find there many useful ideas. It would best be split in two.

An experienced developer will already know many of the patterns though it’s perhaps useful to see them named and described explicitly and listed next to each – it helps to be aware and clearer of what you do and why you do it.

I’d absolutely recommend everybody to read the chapter A Theory of Programming, explaining Kent’s style of programming and the underlying key values of communication, simplicity and flexibility as well as the more concrete principles (local consequence, minimize repetition, logic and data together, symmetry, declarative expression, co-locating data and logic having the same rate of change). Also in the rest of the book there are valuable ideas that it would be a pity to miss. I list below some of those that I found particularly interesting.

Book Review: Agile Project Management With Scrum

A review of and extract from Agile Project Management With Scrum by Ken Schwaber, Microsoft Press 2003, ISBN 0-7356-1993-X.

The book is basically a set of case studies about Scrum that show how to implement the individual aspects of Scrum, what are the common pitfalls and how to avoid them, and help to understand its mantra of “the art of the possible” and how to adapt Scrum to various situations. It’s very easy to read thanks to the case studies being brief and organized by topics (team, product owner, …). I’d absolutely recommend it as a third book in this domain, after a general introduction into the lean thinking (Implementing Lean Software Development – From Concept to Cash by M. & T. Poppendieck is great for that) and an introduction into Scrum itself. Scrum is not just a set of practices, it requires an essential shift in thinking. Thus it is not enough to learn about the practices – you have to learn, understand, and accept the principles behind. This book will hopefully help you to refine your understanding of these principles.

Extract

This extract contains the quotes and observations that I find the most interesting. It tries by no means to be objective or representative, a different person with a different experience and background would certainly pick different ones. Thus its value for others than myself is rather limited but it may perhaps serve as an inspiration to read the book. My all favourite quotes are in italics.

Clean Code: Four Simple Design Rules – Obligatory Read

I consider the Clean Code book to be obligatory for every programmer. And if you currently haven’t the time to read it all at once then you should read – and take deep into your heart – at least the 12th chapter Emergence by Jeff Langr, which introduces Kent Beck’s Four Simple Design Rules and explains thoroughly what they mean and why they’re so important. The rules, in the order of importance, are:

1. Runs all the tests
2. Contains no duplications
3. Expresses the intent of the programmers
4. Minimizes the number of classes and methods (this isn’t as controversial as it may sound, see below)

Stated like this in simple sentences it’s difficult to see the depth hidden behind them and thus their essential importance for clean, high-quality code with high-quality design and I’ll therefore try to explain what they really mean in the full extent based on Clean Codes. I’ll cite some parts of the book – for I can’t find better words than the author – hoping for the author(s) and publisher graciously permitting it.

Book review: Refactoring by Martin Fowler

I had high expectations for Martin Fowler’s Refactoring (1999/2002) but it turned out that both me and the book are too old. It had some interesting parts, but the main one – the refactoring catalog itself – had little new for me because I already know most of the refactorings and the description of steps how to perform them safely is nowadays essentially useless as they’re already automatically and safely performed by our IDEs.

I’ve enjoyed chapter 1 with a nice example of how bad code is turned into a nice one via a series of refactorings and I’d recommend it to any beginning developer. For others than me also chapter 2 may be useful, it explains why and when to refactor, how it impacts your development speed and how to justify it to the manager. I’d skip chapter 3 – bad smells in the code – and read instead of it the Uncle Bob’s lovely Clean Code , which is a great justification and basis for refactoring anyway.

In the catalog I’ve appreciated the description of some refactorings for various reasons, such as 6.4 Replace Temp with Query, 8.14 Replace Type Code with Subclasses, 9.7 Introduce Null Object, 9.8 Introduce Assertion. Of course also the other ones are good but they are just too familiar to me and my IDE to draw my attention anymore.

Chapter 12, Big Refactorings, is quite interesting, especially Tease Apart Inheritance.

Finally there are some good advices in Putting It All Together by Kent Beck, such as that it’s good to know when to stop and to be able to resist the temptation to refactor too much at once.

I’ve also appreciated the “war stories”, especially regarding performance tuning, where once again it’s demonstrated that a guess (however founded) is incomparable to hard evidence.

Conclusion

If you do refactorings daily, perhaps skip the book. If not, read chapter 1, perhaps browse through 2 and 12, check whether anything catches your eye in the refactoring catalog table of content, read Kent’s closing chapter and return the book to the local museum.

Book: Real World Java EE Patterns – Rethinking Best Practices (review & digest)

I’d like to make you aware of the excellent book Real World Java EE Patterns – Rethinking Best Practices by Adam Bien (blog), a Java Champion and renowned consultant, software architect and Java EE standardization comitee member. I’d absolutely recommend it to any architect or developer serious with Java EE 5 or 6 development, even to those not planning to use EJB 3.x (at least prior to reading the book ). It’s a must-read complement to the now a little outdated Core J2EE patterns as it updates the patterns for the new bright world of EJB 3/3.1 while discarding some of them and introducing some new, extremely useful patterns and techniques.

The book starts with an overview of the evolution of Java Enterprise Edition and the hard issues it solves for us, continues with the new and updated patterns and strategies and concludes with an introduction of two opposite architectures you can build with Java EE 5/6, namely lean SOA and domain-driven (which itself makes it worth reading).

What I really appreciate in addition to that valuable content is that for each pattern there is a section on testing and documentation and a really good evaluation of consequences in terms of maintainability, performance and other such qualities. You will find there also many code samples and beautiful applications of the Builder and Fluent API patterns.

The main message is that EJB 3.x is so lean and powerful that we must justify why NOT using it – and when using it, you should be very pragmatic and only introduce patterns, layers and principles if they bring real value.