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.
One of the most interesting parts for me was the chapter about stress testing (using jMeter) and mainly the fact that it is introduced as a common part of a development process right from the start, which is how it should be bad sadly usually isn't. There are some good tips about what to measure and how to do it regularly.
I'd be also glad to see more often the full CI pipeline, where build and unit tests are followed by integration tests, deployment to a freshly created server, functional tests, and the computation of Sonar metrics.
Other highlights: Leveraging Scala's productivity for writing unit tests with ScalaTest (while the application itself is in pure Java), using async/threads for reliability, occasionally writing low-level but simple stuff oneself rather than adding a heavy-weight dependency (f.ex. a simple socket-based REST client), a pragmatic discussion of availability, robustness, and consistency w.r.t. caching, a discussion of the importance of timeouts for robustness (to avoid dead/live-locks).
The only thing I'd change is the Fitnesse functional test which is too low-level, too script-ish for my taste (though it works perfectly for the Bien's needs). I'd prefer something like
A. Bien is clearly a very experienced and pragmatic developer, knowledgeable of Java [EE] - somebody worth following.
You may also want to watch Bien's free screencast about lightweight and modern Java EE (6) architectures full of live coding.
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.
One of the most interesting parts for me was the chapter about stress testing (using jMeter) and mainly the fact that it is introduced as a common part of a development process right from the start, which is how it should be bad sadly usually isn't. There are some good tips about what to measure and how to do it regularly.
I'd be also glad to see more often the full CI pipeline, where build and unit tests are followed by integration tests, deployment to a freshly created server, functional tests, and the computation of Sonar metrics.
Other highlights: Leveraging Scala's productivity for writing unit tests with ScalaTest (while the application itself is in pure Java), using async/threads for reliability, occasionally writing low-level but simple stuff oneself rather than adding a heavy-weight dependency (f.ex. a simple socket-based REST client), a pragmatic discussion of availability, robustness, and consistency w.r.t. caching, a discussion of the importance of timeouts for robustness (to avoid dead/live-locks).
The only thing I'd change is the Fitnesse functional test which is too low-level, too script-ish for my taste (though it works perfectly for the Bien's needs). I'd prefer something like
| URLs accessed | Total hits | Today hits |
|---|---|---|
| 0 | 0 | |
| /entry/post_one /entry/post_two | 1 | 1 |
| /entry/post_one /entry/post_two /entry/post_three | 3 | 3 |
"High availability and extreme consistency are overrated in the real world. Clients prescribe 24/7 availability for noncritical software without even thinking about the consequences." p.66Check out the book's home page where you can find more details of the content and links for obtaining both the printed and electronic version (kindle / epub).
"It is very typical to find aplication, JVM, and even operating system bugs during stress testing. The earlier in the software lifecycle such bugs appear, the easier is it to fix them." p.152
You may also want to watch Bien's free screencast about lightweight and modern Java EE (6) architectures full of live coding.