Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS

Jared Richardson Most Popular
Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers

Blog Archive

Tue, 20 Dec 2005

"JBoss At Work" Was Named Poorly

I recently met Scott Davis at a software conference. Since we both had new books in our hands, we traded books. I gave Scott a copy of Ship It (which he was kind enough to review) and he gave me a copy of JBoss at Work. Every time I pick this book up I find myself still reading it half an hour later. It's a very easy book to read and a hard book to put down. :)

Let me start by addressing my comment about the naming of the book. The name doesn't begin to do justice to the breadth of the topics in this book. From the title, I expected this to be a book on how to use JBoss. While the book does cover JBoss very well, it does much more as well.

Many people have complained about the size of the Java stack. This book gives you the introduction you need to the entire stack. Starting with Java and Ant, it takes you through cascading style sheets, JSPs, servlets, EJBs and finally into web services. It even gives you some JDBC and Hibernate.

They also provide you with practical tips and examples as they go. For example...

In the first chapter they said they kept hearing "I don't wan to be an expert in it. I just want to make it work." That's what they've delivered. They don't take you into the plumbing of Hibernate or JBoss. They give you what you need to use Hibernate and JBoss and be productive. And many times that's all we need.

This is the best book I've read for providing an end-to-end introduction to the web services space, including the technologies that web services utilize. Also, they make a point of using freely available tools for every example. This is a book you can buy and then follow the examples at home without buying any extra software.

Are you planning on moving into the Java web services space? Then I suggest you get a copy of this book and read it first.


posted at: 14:53 | path: | permanent link to this entry

Leornard Nimoy Sings "Bilbo Baggins"

I'm not sure what to say... it's humor. Laugh? A great post the week before Christmas... as a break? :)

I found this on Digg.com a few weeks ago but it's not there anymore (that happens a lot!), so here's the direct link to Google Video.


Enjoy... or at least laugh at what people archive for posterity.


posted at: 11:32 | path: | permanent link to this entry

Unit Tests as a Gateway Drug

As I rule I encourage people to avoid unit testing and write higher level tests. There's nothing wrong with unit tests and I'm not opposed to them, but it seems like we are, as an industry, overly focused on unit tests to the exclusion of other types of tests. I try to encourage people to write tests that exercise more of their application. Mock client tests are my favorite type. They exercise more code than a unit test. When used in a Continuous Integration environment, you still get really good feedback on where problems are. Mock clients are coarse-grained tests in a fine-grained build.

Recently I'm encountering more teams whose code is "untestable". They're convinced that their product isn't testable because it has a browser GUI.

First, that's just flat out wrong.

Do you have a browser front-end? Then look at Watir, Selenium , htmlunit, and others.

But I've also found that unless the entire team gets involved, creating an automated testing suite is more difficult than it needs to be. It's so much easier when there's a team involved. But the idea that "our product isn't testable"... that's a difficult mindset to overcome.

So, in the cases when I don't have the bandwidth to create a suite of tests myself, I'm starting to sidestep the opposition.

Assuming that your product isn't testable from the GUI, your units are testable. So we'll start at a level you can't argue with... unit testing.

So far it seems to be working... my goal is to introduce automated testing via unit tests. Then we'll broaden their horizons a bit. :)

I'll let you know how it works out.


posted at: 11:16 | path: | permanent link to this entry