Accelerated GWT Report Card

Student Name: Accelerated GWT School: Apress School Year: 2008 Teacher: Hamlet D'Arcy Overall Grade: A-Strong on client side, i18n, and advanced topics.
Grading Scale: A=Outstanding, B=Good, C=Average, D=Poor, F=Fail
Teacher Comments
This was a good book and a worthwhile read. It was very strong on the client side and documented many edge cases of the GWT framework without reducing itself to an overly specific "recipe" book.
Client Side Programming	A-
Knowledge of Standard GWT Widget Set	A-
Great coverage of basic widget set. Contains examples and advice about how to layout widgets in various containers, including composing widgets in the Composite class. Sometimes the widget API was explained too completely and it felt like reading Javadoc, but these sections can easily be skimmed. Also, this book was written for GWT 1.4, so UiBuilder is not covered at all.
Knowledge of CSS Styling	A
Great coverage of how to work with the CSS of widgets including several good examples. Best coverage of the topic I could find.
General Client Concerns	A
Overall, the client sections are excellent. Serializing your own classes is covered, the output of the GWT compiler is given fair due, and generators for creating custom JavaScript code at compile time are covered. So far, this is the best book on client side GWT that I've found, even though it doesn't cover the 2.0 features.
Knowledge of JSNI (JavaScript Native Interface)	D
JavaScript Native Interface is barely covered. In comparison, GWT in Practice covers it maybe too much. Embedding JavaScript in multiline Java comments is the most controversial part of GWT, but it's not the most important. Still, a little more info would be helpful.
Server Side Programming	B
Knowledge of GWT RPC (Remote Procedure Calls)	B
GWT RPC is covered in 14 pages. Do you need more than that? Maybe not, it's pretty straight forward. The appendix does cover some of the newer 2.0/1.5 features, like generics.
Knowledge of Internationalization	A+
Over 30 pages on i18n, including an example using localization at either compile time or run time. Very good chapter.
Knowledge of Security Concerns	B+
Same origin policy and cross site scripting: check. Not as lengthy coverage as in other books, but adequate.
Knowledge of GWT Testing	B
GWT Testing is surely the easiest chapter of the book to write. GWT ships with GWTTestCase for testing asynchronous calls and a benchmarking tool for measuring performance, and they are clearly explained all over the Internet. Speed Tracer, the 2.0 profiler that runs in Chrome, is of course not covered.
Creative Code Samples	B
Decent enough code samples (with an occasional error) covering browser history and server sessions, as well as the other topics mentioned. Some of the code samples were a little long and ImageBundle was given too much space given that it is deprecated in 2.0.
Knowledge of Alternative Server Stacks	D
Nothing on the server side beyond GWT RPC is covered.
GWT Best Practices	B+
Tools to Write GWT Clients	A
The Enterprise means constraints: existing domain objects, maybe a crummy DAO, etc. Enterprise GWT apps will need things like custom serializers and custom generators to work around their legacy constraints, and Accelerated GWT covers these topics well.
How to Design GWT Services	B
General advice about domain objects and writing RPC services is given and a DTO approach is avoided, which pleases me. Overall, however, not a lot of information is given on building "Enterprise" backends, which is part of the book's title.

"GWT In Practice" Report Card

Student Name:	GWT In Practice
School:	Manning
School Year:	2008
Teacher:	Hamlet D'Arcy
Overall Grade:	B (solid effort; time well spent; not enough on client side)

Grading Scale: A=Outstanding, B=Good, C=Average, D=Poor, F=Fail

Server Side Programming	A
Knowledge of GWT RPC (Remote Procedure Calls)	A+
How Ajax calls are made from the client to the server using GWT RPC is clearly explained in a variety of use cases (almost too many!). The difficult to understand relationship between service interfaces, server/servlet implementations, and the client asynchronous interface is explained in words, with diagrams, and within the IDE. Explaining GWT RPC is where GWT in Practice really shines... and this topic is still relevant today in GWT 2.0.
Knowledge of Alternative Server Stacks	A
GWT in Practice demonstrates how to consume REST and POX services with GWT, how to integrate Flash for SOAP services (not a good idea IMO), how to use Java Applets(!) for a SOAP client, and how to use Comet for streaming data to clients. The book focuses so much on server side technologies that perhaps it should have been called "GWT Server Stack Recipes".
Knowledge of Security Concerns	A
The Manning "In Practice" imprint means the author is targeting real world developer concerns rather than giving a generic overview, and security is one of these real world concerns. GWT in Practice does a great job explaining all the cross site scripting concerns (and how to work around them), security certificate issues (and how to work with them), and how to configure Tomcat security (which isn't even unique to GWT). It's clear the authors have real experience with securing a GWT app in a variety of contexts.
Knowledge of GWT Testing	B
GWT ships with both GWTTestCase (for easing the testing of asynchronous and multithreaded components) and a performance benchmarking tool. The tools are straightforward and covered in every other GWT text as well. While a testing section is essential to any GWT book, this one didn't stand out against the other material. I'd have liked to see more testing best practices. Plus, GWT ships with a new performance testing tool, so this section is starting to age.
Creative Code Samples	B
The book deomonstrates how to turn on history to support the browser back button and how to record and playback certain Comet messages. The former is useful (and part of the GWT project) while the latter seems unlikely to be needed by almost any other GWT developer (and is custom implemented for the book).

Client Side Programming	C+
Knowledge of Standard GWT Widget Set	C
Granted, the "in Practice" title is not meant to be a basic introduction, but there is almost no material on the standard GWT widget set. If you want to know all the user interface widgets supported by GWT then look elsewhere. However, some widget layout and CompositeWidget material was covered, the GWT in Practice salvages a C grade.
Knowledge of JSNI (JavaScript Native Interface)	B
Surely the most controversial part of GWT is the ability to embed JavaScript within multiline comments of Java files. Sounds nasty even if IDEA does support refactoring and highlighting, right? (And as of 2.0, Eclipse does as well). This books contains a ton of JSNI. Pages of it, actually; which isn't always a good thing for the book or for GWT. GWT in Practice will definitely show you how to wrap JavaScript libraries, even if it makes for poor reading. The best part of the JSNI examples was the recipe for adding drag and drop, which appeared twice in the book for some reason. If you need drag and drop or to wrap a JavaScript library then this is the book for you!
Knowledge of CSS Styling	B
CSS styling gets a whole 2 pages. Which means there isn't much to say beyond what the browser offers already.
General Client Concerns	C
There simply wasn't enough information about client side programming in GWT in Practice. The example that were shown left me wondering, "Is that something I'll really need to do?"

GWT Best Practices	B+
How to Design GWT Services	A
This is the only book I found that included best practices about how to design services, which the author recommended using DTOs and keeping interfaces seperate from implementations to decouple physical services. However, some of the diagrams seemed forced and pointless (and they were, did you know Manning requires a visual aid on every spread?)
How to Design GWT Clients	F
What should client side design be in an Ajax application that consists of pretty much just one web page? This wasn't covered at all. Note to authors: please include this in your GWT 2.0 update! Also, there was no coverage of how to deal with degenerate browsers like IE6. This is the bane of my current project and any hints would be appreciated.
Knowledge of the Best Tools for the Job	B+
GWT in Practice shows NetBeans, Eclipse, and IDEA in action. The most helpful diagram of how a GWT project is structured was actually an IDE screenshot. For builds, the Maven plugin is covered ad naseum, which is understandable considering the authors wrote it. But still, Maven is dead to me so it was time wasted (now where is that Gradle GWT plugin)?

Teacher Comments

Even in light of the GWT 2.0 release, GWT in Practice holds up as a solid GWT book for newcomers. It definitely favors the server side and gives the client side short shrift. My biggest complaint was that it seemed to be a lot of recipes bundled into an "in Practice" format, and many of the recipes I didn't need (Flex? Applets?). Given the book is from 2008 when GWT had just been released, I wanted to dislike it. But it's held up quite well. It should not be the only GWT book you read, but probably it should be one of them.

How to run a Developer Book Study

Have you seen "Everything I Know" from Buckminster Fuller? He recorded 42 hours of lectures detailing his entire life's work. I tried to read the transcript but it was unbearable. More limited in scope is my "Everything I Know about Developer Book Studies". It may not be better than Bucky's, but it's certainly easier to get through. So here are my experiences from doing a few book clubs a year over the last 3 years.

Picking a Book
This is way harder than you'd think. Creating a web survey for your team or devising elaborate instant run off voting schemes aren't worth the effort. Better to gather several ideas and then let one person decide... naturally that person is the one organizing the book study in first place.

But picking a good book is still hard. Don't trust Amazon ratings. Many of the ratings are given by people compensated to give a review. There's a lot of publishers handing out free books in exchange for public reviews, so 4 stars doesn't mean a whole lot. Jolt Awards on the other hand have proven to be a very reliable source of good books. Even then, it can be a crap shoot. "The Pragmatic Programmer", for instance, is a great book but we had a terrible time finding meaningful conversation around it. Perhaps some books are just meant to be read alone.

Finally, don't pick anything too long. A lot of people (me included) have a hard time not reading every page of a book. In a larger group you'll surely have a few. Dragging a book club out over several months saps your energy. Low 300 pages is my limit. The bigger font the more better, too!

Creating an Invite List
Do you invite everyone on the team? Everyone in the company? The remote office? Contractors? It depends on what you're trying to accomplish with the book study. A team only book club is good if you're reading a book that specifically applies to your project, while an entire company book club is good to promote practices across teams. Want to jumpstart agile adoption with a book study? Invite the team only so you can discuss specific practices to start using that make sense for you. Want to upgrade your standard coding practices by reading Clean Code or Effective Java? Invite the entire company, because quality discussions don't depend on a specific team context.

Remote employees are hard. Conference call etiquette always seems to break down. It's most painful for the remote person, so he or she needs to be especially motivated to benefit.

Having several people remote can work. We did a Design Patterns study and included a team from a different company. We agreed not to discuss work specifics and it turned out pretty well. We read Head First Design Patterns and GoF at the same time, and one person from each site presented on the same pattern from the different texts. The room with more people did dominate the conversation though.

As for contractors, I like to invite them and explain the time is non billable. Few accept but I feel it's a nice gesture. Does that sound condescending? It's not meant to be.

Choosing a Format
The format is one of the most important decisions, and different books require different formats. Soft skill books, especially agile, don't need much structure. Everyone has an opinion and everyone can generally contribute to the discussion (not always a good thing). Technical books need more structure. We did Java Concurrency in Practice and settled on a format where each person is assigned a week, and that person presents back to the group as if they hadn't read the chapter (which they had in fact read). No one was an expert on concurrency, so without the format we had nothing to say. With the format, even people who hadn't had the time to read that week benefited.

Try to have a format that produces decisions. "We will start test driven development" or "We will document monitoring concerns in designs". Without action after the book study you're just sitting around talking. Try to use what you learn at work with specific actions and decisions. Writing all your decisions and recommendations down can help you plan your course of action after the study is over. Don't bother taking minutes though; it's unlikely that anybody wants to read them.

Also, it's nice to give everyone something to take away. If it's your turn to lead then have a 2 page handout ready with your material or your code samples. Handouts are much better than slides because they can eventually be transformed into blog posts or internal trainings.

A final bit of logistics: schedule the meeting for 1 hour, the room for 1.5 hours, and try to finish in 45 minutes. If no one has anything to say then cut losses and run. If the discussion is productive then stay a little late.

Reading the Book Correctly
I like to set an aggressive schedule to keep the study under a two month span. Any more and you get burned out and bored. Once a week for two months is a lot. Our Release It! study did four every-other-week meetings and worked great. Keep it short.

Read with a highlighter. Highlighting text forces you to read the important passages twice, making them more memorable. You'll remember a book better if you've highlighted it, it's easier to come back and find passages later if they are marked, and it's easier to gather up your notes if the book is marked up. And bringing a written set of notes to a free-form session is very helpful, it helps keep the conversation on the most important topics.

As for the pace, I have two bits of advice:
1. Don't read ahead; you'll forget the material by the time the sessions come around.
2. Read the entire book ahead of time; you'll have better discussions because you understand the book's entire context and the pressure will be off to complete some sort of weekly reading schedule.
"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes." -Walt Whitman. See? My copy of Song of Myself was highlighted, so I could easily find that passage! (OK, I admit I googled it).

Promoting the Event
Showing the value of the book club to the other developers and managers can build interest and get more participants in the next club. Let others know what they missed by posting your notes on your blog or wiki, or holda training session on the book content at the end of the study.

I like to let managers know who is and isn't participating. If some teams aren't present in the studies then the managers can apply pressure to get more people involved. Being known as the guy who organized the book club doesn't hurt your reputation either.

Lastly, ask to be reimbursed for the books. It can't hurt. My employers have always been happy to buy books, I'm surprised when people are afraid to ask.

Take a break
So your bookclub was awesome... now don't do it again! Give yourself some time to recharge your batteries and implement all the great ideas. It'll also give you time to email me with your lessons learned. I'd love to hear them.

Release It! Review in "Quotes"

On Stability...

"Every integration point will eventually fail in some way" - Michael T. Nygard
They sure do... and the book contains patterns to follow, like the Circuit Breaker, to ensure your system stays alive when the other system dies.

"Generating a slow response is worse than refusing a connection or returning an error" - Michael T. Nygard
The book explains how slow responses tend to propagate upward from layer to layer in a pattern he calls "cascading failure". There are several patterns to address this issue, especially Timeouts.

"Hope is not a design method." - Michael T. Nygard
Quotable nuggets like this make the book an entertaining read from start to finish.

"Ohnosecond: that very short moment in time during which you realize that you have pressed the wrong key and brought down a server, deleted vital data, or otherwise damaged the peace and harmony of stable operations." - Michael T. Nygard
It'd be alright with me if I never had credentials to log onto another production server in my life.

"Data purging always gets the short end of the stick. It certainly doesn't demo as well as... well, anything else in the world demos better than data purging." - Michael T. Nygard
There's not a lot to say about purging except, "Why aren't you doing it?" Still, the book contains a good call-to-arms about the topic.

On Capacity...

"Nothing is as permanent as a temporary fix" - Michael T. Nygard
The last chapter contains a wonderful description of Enterprise Architecture in which a crystal palace has been built and calcified, and now developers tiptoe through the code speaking in hushed tones, trying not to touch anything. Reading this passage was worth the cost of the book alone.

"Storage is a service, not a device" - Michael T. Nygard
The real cost of hardware is thoroughly explained, and Michael shows how the real cost of ownership on local storage is sometimes seven times higher than the actual hardware cost. As for processing power, he introduces the concept of a "Forklift Upgrade"... adding CPUs to a box is pretty cheap, unless it requires a new box and your box weighs two tons. Makes you think differently.

"Some technologies just beg to be misused. Take bottle rockets. No matter how many warning labels manufacturers put on bottle rockets it's still a firecracker with a handle." - Michael T. Nygard
Or the combination of StringBuffer, SQL, and a JDBC connection. Oh God, please don't build up a SQL command by combining all these. The book's coverage of this one is a little more nuanced than mine.

"Nobody deliberately selects a design with the purpose of harming the system's capacity; instead, they select a functional design without regard to its effect on capacity." - Michael T. Nygard
Design for Capacity... can you honestly claim this as one of your design principles? This is different than designing so you don't ruin your capacity. Mr. Nygard explains how this isn't premature optimization and provides concrete patterns to follow to get capacity.

"Factor the cost of generating content out of individual requests and into the deployment process" - Michael T. Nygard
If web content is static between releases, then precompute that content as part of the build. This is a good example of how the book contains specific, concrete advice, and isn't just a collection of high-level maxims.

On Availability...

"The proper way to frame the availability decision is in straightforward financial terms: actual cost vs. avoided losses." - Michael T. Nygard
Service Level Agreements (SLAs) are given a fair and developer focused treatment, complete with some light math. See his blog posts on Reliability Math Getting Real About Reliability for a flavor of how some math can actually help explain some of these concepts (although those posts get into a lot more math than the book did).

"Most of the time, the real culprit [for deployment and production defects] is a mismatch in topology between QA and production" - Michael T. Nygard
I spend a staggering amount of time trying to replicate defects in development. Part of this are the hidden dependencies that come with housing several components on the same machine in QA but not production or differing network configurations like having firewalls set up between servers in production but nowhere else.

"A running application can be interrogated for its internal state, but a halted one cannot." - Michael T. Nygard
For me, this was non obvious. This quote comes in the context of building a clean start-up sequence for all of your system components, and not accepting work until the entire system is running successfully. Compare this to a system that aborts and exits if something fails during start-up. Which system would you rather troubleshooot? Which system has a better chance of being able to tell you what is wrong with it?

"Java GUIs make terrible administrative interfaces for long-term production operation." - Michael T. Nygard
GUIs make terrible administrative interfaces, whether they be desktop or web. Scriptability is advocated here, and exposing your application as JMX MBeans is held up as an excellent example of how to do it right without much effort.

On Transparency...

"Without transparency, the system will drift into decay, functioning a bit worse with each release." - Michael T. Nygard
Many of the book's concepts are explained with analogies from outside computer science. For instance, eutrophication from Biology, bulkheads from the shipbuilding craft, and circuit breakers from electronics are all used to explain some of the patterns and anti-patterns laid out. Part of the joy of reading this book is finding those quotes and concepts from other scientific fields that somehow apply to our craft. The writing goes beyond the obvious tie-ins to entropy and constraint systems. Readers love a diverse bibliography.

"Can we make it through the holiday season? (Notice that this requires a projection about a projection, which doesn't just double the possibility of error but squares it.)" - Michael T. Nygard
It's OK to think in mathematical terms. Really, it is. This book makes you think differently about capacity, availability, and reliability by bringing it back to some simple numbers.

"A startling number of business-level issues can be traced back to batch jobs failing invisibly for 33 days straight." - Michael T. Nygard
With better monitoring you'd have had 32 days to fix the issue. Now it's the 33rd and you're working the weekend. Enjoy it. By the way, this is a design issue, not a reporting issue.

"Logging should be aimed at production operations rather than development or testing. One consequence is that anything logged at level "ERROR" or "SEVERE" should be something that requires action on the part of operations." - Michael T. Nygard
You can show up at work Monday and start applying this advice in your code, and you can show up and start applying the principles in your designs. That's a unique combination for a book. Release It! blends enjoyable writing, high level conceptual thinking, and lower level implementation steps. My work did a book club on Release It! and within a few weeks it has changed the flavor of our design sessions. I really enjoyed this book and highly recommend it to others.

Expert F# by Don Syme Review

(Sorry if this sounds like a commercial, but I liked the book)...

Can a 650+ page book from 2007 on an evolving language be any good? There are only two or three other F# books available, so saying it's the best reference isn't a big commitment. But two years after its release, Expert F# continues to be a great reference and overview of the language. It has a number of good things going for it.

1. The book's not a 650 page reference manual. Expert F# is really two books in one. The first 250 pages deals solely with the language, functional and OO programming techniques, and available libraries. Seemingly in its entirety. I find F# an incredibly clean, simple, and easy language to program in (at least from my reference points). The fact that it can be fully described in 250 pages speaks to its straight-forward nature and lack of weird edge cases. Compare that to your JVM/CLR language du jour.
   
   
2. The Appendix is a 7 page language guide to the F# syntax and language features. I printed this out from the eBook copy early on and it never left my side. This was a great aide in learning the language and all programming books should steal the idea.
   
   
3. The functional programming chapter clearly explains the idioms of FP and does not use OO as a point of reference. I don't want an OO/FP hybrid and this is a good introduction to recursion, immutable data types, pattern matching, et al, yet it strictly avoids the common "here is how to use a functional syntax with the standard Java/C# mutable HashMap". In fact, I suggest you skip the OO chapter. Let's learn FP first, and then decide when it's required to resort to OO.
   
   
4. The eBook has a searchable index. The book is 2 years old and it's still easiest for me to find answers in the pdf rather than searching Google and HubFS.
   
   
5. The downloadable code samples are a valuable resource for exploring the concepts beyond code snippets. I have fond memories of using the PalmOS code samples to learn the platform, and these are of the same caliber. But seriously, isn't there a better build system for .NET than build.bat files? Ugh.
   
   
6. An entire chapter on fslex and fsyacc? Actually, there are two chapters. Awesome, especially when coupled with the code samples. Langauge oriented programming gets a very good treatment here.
   
   
7. The asynchronous workflow and concurrency chapter is worth reading just to see how elegant they made thread manipulation and wait/join actions. Yes there is a difference between let and let!, and it's cool. And who doesn't want yet another monad tutorial? Not me.
   

And the bad...

This is really two books in one: a language guide and a set of case studies on advanced topics. I'd have bought this book long ago if it were just the first 250 pages. Can anyone read a book that's too heavy to carry out of the house? My advice: buy the eBook and print out the chapters you want. Save a tree. Appreciate F# even if you don't plan on shipping code with it.

Java 5 Function Object Awesomeness

You don't see a lot of blog posts about how great function objects are in Java. It's pretty popular to hate on Java in this area. You're not really a Java programmer unless you write a blog post about how crummy they are, right? Whatever. I like Java. I also like function objects. And enum types too. Martin Fowler's Type Safe Enum in Refactoring was one of my favorite chapters. It seemed so clever, and I got a warm feeling every time I wrote one. And now the language supports it with the enum type. Welcome to 2004!

The first attempt at a function object is usually a Strategy Pattern. And you litter your code with a bunch of anonymous inner classes (ugh, the syntax is kinda cumbersome) and you declare an interface somewhere (ugh, again). This is the high ceremony of Java the critics talk about. So it might make sense to need a function object attached to an enum. Let's say you have an enum type representing a "healthy snack"; each snack can be eaten (a public method), and each snack needs it's own preparation code (hidden implementation).

My default implementation used to be to create an enum with a private inner interface, attach an instance of that interface to each enum element, and create the function object as an anonymous class instantiated in the definition:

public enum HealthySnack {
    APPLE(new PrepareStrategy() {
        public void perform() {
            System.out.println("slice...");
        }
    }),
    ORANGE(new PrepareStrategy() {
        public void perform() {
            System.out.println("peel...");
        }
    }),
    CARROT(new PrepareStrategy() {
        public void perform() {
            System.out.println("skin..."); 
        }
    });

    private final PrepareStrategy preparation;

    private HealthySnack(PrepareStrategy preparation) {
        this.preparation = preparation;
    }

    public void eat() {
        preparation.perform();
        System.out.println("eating..."); 
    }
    private interface PrepareStrategy {
        void perform();
    }
}

So a HealthySnack has an eat( ) method, which calls the prepare( ) step unique to each element. An apple must be sliced, an orange must be peeled, etc. Easy. A little verbose. High ceremony? Yes... but how can it be avoided? I wouldn't think this code is too abstruse.

Here's the trick I learned from Effective Java 2nd edition. What's to stop you from declaring an abstract method in the enum? And then have each element implement the method in the declaration. Nothing is stopping you, it turns out. I had no idea this was even legal, but check out the new code:

public enum HealthySnack {
    APPLE { protected void prepare() {
        System.out.println("slice...");
    }},

    ORANGE { protected void prepare() {
        System.out.println("peel...");
    }},

    CARROT { protected void prepare() {
        System.out.println("skin...");
    }};

    protected abstract void prepare();

    public void eat() {
        prepare();
        System.out.println("eating...");
    }
}

Much better. You get to throw out the private interface declaration. You can throw out the strategy instance field, too. And the element definition contains the overridden method but not the anonymous class declaration. The essence of varying preparation per element is revealed much better by declaring an abstract method instead of a private interface.

<caveman_voice>Book good! Book useful!</caveman_voice>

Now to go rip out all the needless cruft I've been producing the last few years.

Google Guice by Robbie Vanbrabant

The stars aligned this week: I was called into jury duty the same day Google Guice by Robbie Vanbrabant arrived in my mailbox. Awesome timing. This is my review in which I purposely avoid any juice puns (you know, like saying "the guicy details" and such).

The Content
I'm gearing up to deliver a dependency injection brown bag at work, with the intent of helping teams roll out Spring and DI on more of our projects. I wanted to read this book mostly as a comparison to Spring, but to also see how well DI was explained. I've had the Guice user manual and videos bookmarked for months, yet haven't worked up the motivation to look at either. At 180 pages, it was easy to breeze through this book; the writing was conversational (good!) and the font was big and the pages were small so you really feel like you're making progress when reading. Afterwards, I've been able to have several informed conversations about both frameworks, and I feel like I have a good grasp on the differences despite never having used Guice on a project. So if your situation is anything like mine, then I definitely think reading the book will be time well spent.

Dependency injection, and the motivations for it, are covered quickly, so don't expect too much in that department. Martin Fowler's article is still the best reference I can find, despite it starting to age. This book is really about how to use Guice effectively.

It does a good job of attacking the comparison to Spring head on. People are typically worried about the heavy use of annotations in Guice, despite usually complaining about all the Spring XML in the same sentence. Robbie does a good job pointing out that annotations are just metadata and not really a form of tight coupling. Your code will function just fine without Guice (i.e. in the unit test). There's a good comparison to annotations as offering the same coupling as Javadoc. If you mention Guice everywhere in your Javadoc nobody would complain that your code is tightly coupled. And how much different is the metadata of an annotation from the metadata of Javadoc? (This also supports my biggest gripe about writing Javadoc... if you really follow the DRY principle and strive for cohesive, small classes, then there isn't a whole lot you can say in the docs that doesn't drag a bunch of dependencies into the class. My Javadoc tends to be retardedly simple and I haven't found a good way to fix this). Anyway...

The other concern is that Guice doesn't really do anything that Spring doesn't. I thought Robbie made a good case on why Guice is an improvement on several fronts. The type safety of Guice was well explained. Programmatic bean configuration in Spring is pretty type unsafe. Neither constructor arguments nor their types are checked at compile time, while Guice provides this. And the examples clearly show that bringing up a Guice Injector is a lot easier than bringing up a BeanFactory. The term "lightweight" for Guice seems appropriate. As for the lack of XML... this is probably a good thing. I hear horror stories of Spring configuration explosion, but honestly I've never seen it. If your class explodes to several thousand lines you know to refactor, but when your XML explodes to the same length people tend not to do anything about it. Programmers seem to understand refactoring and modularization when it comes to classes but that doesn't carry over to XML. If your configuration is in Java it's probably a lot easier for a team to recognize and reorganize away from bad patterns. This is kinda compelling for me. As for the IDE support of Java configuration over XML configuration... this argument gets trotted out a lot but the Spring support within IDEA is amazing. I've never had an issue finding my bean definition or with refactorings breaking the XML. Maybe Eclipse is different? Maybe it's time to switch? The biggest issue I have with Spring configuration is finding out what the runtime errors really mean and which of my beans has a bad definition (nested exceptions to 10+ levels anyone?). Guice's type safety and claimed improved error messages should both help here.

The nuts and bolts of creating Injector objects are well explained and easy to follow. Robbie makes a good point that Guice is not a container, it is simply a framework. In my uses of Spring, I've always brought Spring up at startup, and if any object needs DI, then every dependency between that object and the Spring root needed to be Spring managed. Guice's simplicity tempts me to just create new Injectors at the point in the object graph where they are needed, eventually having several injectors throughout the object hierarchy. I deal a lot with legacy code, and I've so far been stymied with how to use Spring without the dreaded Big Refactoring. I guess there's nothing stopping me from creating a whole bunch of Spring BeanFactories everywhere, but the prospect sounds a lot more appealing in Guice because it's a little lighter weight. If anyone has a DI in Legacy Code case study then send it my way.

As a sidenote, part of the Guice type safety relies on Neal Gafter's Super Type Tokens, and I finally feel like I understand that idea. The book explains it very well.

The Aspect Oriented features of Guice look cool too. Striving for the 80/20 rule in AOP has lead Guice to a point where there isn't a RegEx like declaration of point cuts, but rather a nice, fluent, type safe way to declare them. The compiler checked Guice code:

bindInterceptor(
 subclassesOf(Phone.class),
 returns(only(Receiver.class)),
 new PhoneLoggerInterceptor()
);

Looks a lot more manageable (yet less powerful) than the Spring pointcut:

@Pointcut("execution(* com.xyz.someapp.dao.*.*(..))")

especially after having recently suffered through a demonstration of Spring AOP that involved 15 minutes of fiddling with the pointcut while wondering why it wasn't working.

An entire chapter of the book was spent on using Guice in Struts2 and Wicket. I don't often write web apps and I've used neither of these technologies; however, I have to say, Struts2 looked very easy to get running with a minimum of boilerplate. Either all the Struts2 horror stories I heard were false or Guice really does bring a lot to the table for web frameworks. I also really admire that the book tells readers wanting more information to buy Struts2 in Action (from Manning) whileApress seems to have their own series of Struts2 titles. Not sure how that slipped past the editors...

The book ended with a discussion of DAO and persistence, some Guice recipes (covering many common errors and edge-cases), and some thoughts on the future of Guice. I love that the book references a future Guice enhancement as Google Code issue #39. I think my pet project that nobody uses has more than 39 issues.

So what's the conclusion? 5 hours of reading left me with a good working knowledge of Guice. Definitely worthwhile. That's my glowing endorsement.

The Book Itself
The point of Apress' firstPress imprint is to provide short, lower cost, print-on-demand or eBooks on emerging technologies. This one weighs in at 180 pages (large print, small pages) and costs either US$10 or US$19.99. I really like the idea of this imprint. Longer than a white-paper, easier than the 600 page reference manual. Have you checked the page count on Pro Spring 2? 1,000 pages, you gotta be kidding. Only a student has that kind of time on their hands. Also, the writing was above average. Conversational, fast paced, and the code examples weren't filled with attempts to showcase the wit of the author. Note to world: there is only one person I know of that has the skill to make a good code example funny. You're probably not him. Lastly, a co-worker said they thought the book felt flimsy and cheap, but I never noticed. It had been rattling around my motorcycle top-case for 3 days, so I blame my transport not the book.

The Small Gripes
There is no index. There should be an index. And it should err on the side of too lengthy. Also, the diagrams mostly confused me. I actually understand what scope widening injection is, but I still can't figure out the diagram describing it. Whatever, it doesn't matter. I just felt like I had to say something negative to appear fair.

The Disclaimers
Apress sent me the book for free with the agreement that I'd review it. So I'm incented to write a positive review. On the other hand, I work full-time for a competing publisher. So I'm incented to bag on the book. We checked with the lawyers (seriously) and they were fine with it. That should be enough for anyone!

And to all you future jurors...
Jury duty rocks. It's as close to a vacation as I've had recently. But please, if you're summoned, know your rights. As a juror it is your constitutional right to ignore bad laws, power hungry judges, and overzealous prosecutors through the use of jury nullification. And I wonder why I was dismissed from all the juries I was pulled for.