I just got home from a long trip to Tahoe to discover my book had been biled. Ouch. Disclaimer: I’m more than a bit pissed off and have decided to respond before cooling down. Also, keep in mind that Hani and I both spend a lot of time working together to try to hold OpenSymphony together. In fact, I consider him a friend. So seeing this ‘review’ was quite a shock if you can imagine.
OK, first, some point-by-point comments:
Hani’s jab at the title…. I admit I’m not a big fan of the title, especially given that much of the focus is on aspects not related to open source programming, but rather Test Driven Development. But ‘Developing web apps by avoiding all J2EE’? The technology discussed focuses on the Servlet and JSP parts of J2EE, but does not delve in to EJB, JMS, JNDI, or any other part of J2EE. Is that a problem? The book doesn’t claim to cover the entire J2EE stack, so why bitching about this is just whining and nothing more.
As for the JUnit chapter, I don’t see any real complaints here save the concern between not mentioning the difference between and error and a failure. I thought that this was covered, but I will take Hani’s word that it isn’t. This is an oversight.
The complaint about the mock objects chapter is a bit perplexing. While I admit it is a bit light (we point to several online webpages for further information — why repeat content already there?), the complaint that the examples are not ‘real world’ is off the wall. The example calls out to writing some Checkout code that requires a Customer, a ShoppingCart, an Invoicer, and an OrderDispatcher. It notes that the real OrderDispatcher might need access to JMS, JDBC, I/O, JNDI, etc. It then goes on to show how we can mock it in order to test only the Checkout code. I don’t see how this is a bad thing at all.
Moving on the Hani’s complaints about the XWork chapter. In fact, OSWorkflow does support XWork (as of today). The fact that the print went out claiming this while in reality this only became true until today is due to an oversight on my part. JPublish does support XWork and I in fact had Anthony Eden, the owner of JPublish, verify the sentance for me (“Version 3.0 and beyond include support for XWork actions in addition to the JPublish API from previous versions”). If Hani is trying to imply that I am deceiving the reader, he should do his homework and speak with Mr. Eden (they both lurk in #java all day long). If there is any deception going on here it would be Hani’s claims that the book says that “JPublish uses XWork”, when in fact the book clearly states that in merely “includes support”. To say that WebWork 1 and XWork are not very similarly designed would be a lie. Hani says this claim is misleading, but as I am the author of both the WebWork 1.x GenericDispatcher (the core in which all actions are executed) and XWork, I can say with absolute certainty that they are indeed extremely similar in concept.
The next comment Hani makes is totally off the wall. He indicates that we (the four authors) did no collaboration. While it is arguable that the final product may or may not indicate quality collaboration, I can say with absolute fact that the four of us worked very hard for 12 months meeting on a weekly or twice-weekly basis. Hani does not and could not know that, so for him to make this claim indicates his bias very clearly. We actually reworked the table of contents several times in order to make the chapter transition as smooth as possible, and I truly feel we did a good job there. However, I must admit it is hard to make perfect transitions when the book is one part reference guide, one part ‘case study’, and one part TDD process guide.
Hani then goes on to show his bias and anger toward Mike by complaining about the mention of JIRA in the book. I’ll admit I was a bit worried that the reference might be perceived as a biased reference, and as such we made sure that alternatives were mentioned. Now if Hani believes that the alternatives mentioned in the book are complete crap, that is his opinion. But it is far from a systematic method of deception. His claim that the IoC alternatives shown (Avalon) were done to make XWork appear in the ‘best possible light’ is just laughable. Keep in mind that Pico was created by Joe Walnes (one of the authors of this book) and didn’t exist until after the manuscript was frozen. None of us were aware of Spring until well after the book went off to printing, and even if we had it would have been increadibly hard for us to change the final drafts so late in the publishing process. Hani hasn’t written a book and as such doesn’t understand the complexities involved with trying to avoid dated material. In fact, the reference that OSWorkflow “supports XWork” is a case of me trying to get ahead of myself — and as we can see this isn’t a good idea as sometimes the material can be false (or false for a short period of time).
In his ‘review’ of the XDoclet chapter, it appears that Hani is complaining about the fact that we chose Hibernate over EJB (recall that Hani is one of the few people that refuses to give due credit to Hibernate or other EJB alternatives). Also, for those that are keeping score, a few years back I wrote a presentation at the San Diego Java Users Group called “is EJB always neccessary?”, in which I explained that proper use of alternative technologies such as Hibernate or Ofbiz when combined with usage of the containers transaction service (where the real magic is, in my opinion), you can usually avoid many of the pitfalls found with EJB. Feel free to google the presentation and decide for yourself if you think I am biased or not.
To me it seems that this isn’t as much as a complaint about the XDoclet chapter but rather his annoyance that both EJB and Hibernate were covered in a book that he tries to play off as otherwise ‘condescending’. Not only do I not believe the book is condescending, but I believe we have made a very fair effort to not knock on any technology that is considered a valid alternative. (one other reviewer has also said this, Grape Ape, aka Robert Nicholson, though his negative review is filled with as much bias as some of the positive reviews I’ve read, so it doesn’t really count for much). For example, here’s a quote from a sidebar in the WebWork chapter titled “What about Struts?”: “Both frameworks are powerful and can simplify your development greatly”. The sidebar also lists pros and cons to using WebWork and Struts. The list seems very fair to me (mature product, huge community, documentation, tool support vs. simpler to learn, easy to extend, clean API, easy to test, decoupled from the web tier). If you believe these pros/cons are inaccurate, biased, or decietful, please let me know.
Apparently Hani doesn’t appreciate the section on communication and tools. I can agree that it isn’t the most solid chapter, but there are some useful tips and advice in there. Not much else to say about that.
Hani is correct that the security chapter and the lack of wrap-up are problematic. There isn’t much I can say about this other than he is right and if we had more time we would have certainly focused more time on those parts. Fortunately those two items are not central to the book and not much is lost.
I don’t know what “style and ideas (mostly the lack thereof)” Hani is referring to, but I tend to thing that I’m very open to outside ideas and anyone who knows me or is on any of the mailing lists I’m involved in knows that I’m very open to alternative ideas. In the end, I feel that we did an excellent job of pointing out alternatives, listing pros and cons, and overall being responsible writers. I can’t say the same for Hani. Then again, his site is called The BileBlog and focuses only on the negatives, so I hope readers keep that in mind when reading his so-called review.
I must say that I pride myself in my honesty and ability to stand strong with my principals. So when I see someone making claims that I deceived my readers I get very angry. If it were true I would quickly apologize and try to rectify the error. However, in this case it simply is not true and it is clear to me that Hani’s anger towards one of the authors of this book clouded his judgment and caused him to state outright lies (coupled with some truths).
Do I think this book is perfect? God no. Do I think it is worth the $30? Definitely. To anyone interested in this book I recommend you not take heed to any of the reviews (positive or negative) as all of the ones I’ve seen thus far have been incredibly biased. Instead, I recommend you go to your local book store, flip through the pages a bit, and decide for yourself.
