I really enjoyed this book. It gave me the feeling that the advice given came from real-world experience rather than some theoretical model that same "wizard" says we should all do. I've seen a lot of the anti-patterns on the projects I've worked on and it was nice to see that they happen to other projects as well -- misery loves company. Most of the solutions, however, I haven't seen, at least in the form that is presented in the book. The Circuit Breaker, for example, is a great idea that I have never thought of. In the past, I've muscled my way through stack traces, log files and application server consoles trying to figure out "the bottleneck" or "the memory leak". Now, I have a better insight as to what can be done to prevent late night conference calls and getting on planes. I think Micheal has done a good job of explaining his ideas and I'm glad to see that he is refining his ideas through the NFJS circuit. Overall, I give this book two thumbs and say it is worth the time and money. Go grab yourself a copy.
One of the things I'm going to put onto my TODO list is to see how these ideas are expressed in Java, my current language of choice. The notion of a Test Harness that can be used to kick your application in the head and see how it reacts seems like a great idea but I wonder how much code you have to write to create one? Does one already exist? Should I write a basic framework and release into the wild? Is a Test Harness so tightly coupled to an application that you can really share it between projects? Can I create a Circuit Breaker abstraction that can take advantage of Spring and expose itself as a JMX MBean? If I do start releasing code, I'll be sure to mention it in this blog.
No comments:
Post a Comment