As of JUnit 4.4, if you happen to peek into the distributed JAR you’ll notice something a little off: in addition to the org.junit.* packages there is this a funny-looking org.hamcrest.* package sticking out like a sore thumb. You may have seen other projects pick up a dependency on Hamcrest lately as well, and I bet you’re wondering what it is. Let’s get to the bottom of it.

Introduction

The “I’m Feeling Lucky” Google search for the term hamcrest currently takes you to the project’s Google Code page that states Hamcrest:

Provides a library of matcher objects (also known as constraints or predicates) allowing ‘match’ rules to be defined declaratively, to be used in other frameworks.

That’s a pretty good description if you already know what a Matcher is… but it doesn’t explain much for a beginner. So what does Hamcrest really do for you? 

It's just like... It's just like... A mini... REGEX!

A good way to think of it is that Hamcrest is to objects what regular expressions are to text.
Hamcrest provides you with a set of methods that effectively define a DSL to do pattern-matching on objects.

What can you use it for? Well, like regular expressions, the possibilities are endless. Some really novel uses have come about recently, but the most prominent use has been in the area of testing – hence the JUnit dependency.

A Brief History

Hamcrest evolved out of the library JMock, being used to write specialized constraints on what you expected to happen to a Mock object when standing in for a real implementation. A more fluent assertion syntax arose from these constraints which allowed you to chain together main constraint calls under a single assertThat method. Later JMock’s author, Joe Walnes, refactored the constraint API out into its own library called Hamcrest as people became interested in using it outside of a testing framework for all kinds of different things. He also started calling the constraints “matchers” though they can go by both names or, in some circles, “predicates.” Other testing frameworks and even JUnit, notorious for not requiring any dependencies and staying conceptually small, have picked it up.

All those old friendly org.junit.Assert.* static methods are still around in JUnit 4.4+. They’re useful for certain things, but by and large they’ve fallen out of style. The new kid on the block, JUnit’s assertThat method allows you to pass a Matcher in to create an assertion that you would otherwise use a specialized-assert method. Why is assertThat so useful? A few different reasons. Not only does it provide a more generic way to specify assertions, it also alows the framework to know specifically what you’re trying to assert. That allows the framework to generate failure messages for you.

Fail message… win?

It’s always been a good idea to use the overridden version of assertX method that also takes a String for a failure message, for example:

If we passed in an object representing a childhood version of Blackbeard, say, (before he took to the high-seas) then we’d expect to see our failure message:

It’s always been a good idea to provide these messages. But there’s no getting around the fact that they’re repetitive, tedious, and redundant.

Using Hamcrest matchers alongside assertThat makes JUnit smart enough to generate meaningful failure messages for you: writing your assertion with Hamcrest matchers provides the framework with enough contextual information to generate meaningful failure messages on your behalf. No need to maintain an extra arbitrary String to make sense of your failed assertions:

This may not look like much of an improvement, but it also doesn’t read any worse. We can ditch the extra String parameter as well. When this fails we’ll get a pretty cool failure message for free:

Note: I’m using JUnit 4.6 – in order to get this syntax to work you need to do some static imports:

It looks like there’s still work being done to make this DSL read more fluently in JUnit; something like:

Other Cool Stuff

Getting Reused

TestNG, JMock and many other testing frameworks will certainly benefit from what Hamcrest offers, but we’re starting to see this being used in many other places as well. I’ll be interested to see how well matchers work together or are maintained seeing that they’re relatively easy to create. Hopefully frameworks will contribute useful matchers back to the project.

Chaining

Because the matchers are implemented as a DSL using the method chaining idiom, they’re extremely easy to combine and extend.

Matchers For Regular Expressions

To bring the blog post full circle, I found this earlier tonight: the Hamcrest Text Patterns project. Its goal is to have you write Hamcrest-style regular expressions using matchers which will produce much more readable regular expression code. For example, have a look at this test that I found in the project:

By providing a friendly name for each capture (user, host, scheme, email) you can provide meaningful messages programmatically about what doesn’t match up when something doesn’t match.

Conclusion

I hope you choose to take a closer look at Hamcrest because it brings a big bang-for-the-buck and has the potential to guide us to more human-friendly, readable code.

Further Reading

• Have a look at Joe Walnes’ blog for a great introduction to using assertThat as well as other creative uses of Hamcrest matchers.
• Also take a look at Nat Pryce’s blog for more info on Hamcrest and Testing in general.

More Related Content

• June 9, 2009 -- Mocking with JMockit (5)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• September 10, 2008 -- Axis2 client using ADB – runtime dependencies (6)

Update: A great article on OSGi popped up on Javalobby today. Check it out.

I haven’t yet written any thoughts about OSGi but it’s something that’s increasingly found its way on to my radar over the past year and a half or so. I’ve been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer’s talks on InfoQ about it). Needless to say it’s got me excited. Really excited – to the point where I’m catching myself geeking out uncontrollably like Quagmire from Family Guy. What’s got me all giggity? Let’s take a step back first.

With Java there has always been a focus on modularity, but it’s come up in different intermediate forms. Any typical Java developer can go on for hours about the importance for layering and properly isolating, decoupling and packaging components and subsystems. Java has the idea of a package, and the idea of JARs came about fairly early on in the process. But what became difficult was that often each layer had to have its own supporting infrastructure in place to be built independently, and someone needed to know how all of those JAR dependencies mapped out at build time and runtime. This was a necessary evil so that we could have individually deployable modules or subsystems. Once you got there, it was all worth it.

The problem was that while you may have been diligent and rigorous in your approach to applying how your projects were laid out and built, quite often the framework space solved this problem over and over again in many different ways. Going to upgrade a library was not an easy task, because you had to typically upgrade it across each of your layers, and what’s more, there was no consistent approach to manage transitive dependencies amongst the modules each library used. Library selection and dependency management was the work of a greybeard within your project and it took a while to change a library or upgrade. Not to mention a near certainty that you’d need to execute your entire suite of regression tests to make sure nothing broke.

After seeing many Java frameworks being cajoled into a Maven build in order to manage builds and transitive dependencies, there has been increased awareness on the part of the vendor (be it commercial or open source) space on modularity. But we’ve only focused on the problem of solving modularity from a build-centric view. In other words, “How can I package and manage these build artifacts in such a way that consumers can easily integrate them into their project in a consistent and automated way?” This was the pie-in-the-sky idea behind Maven as I see it, and they pretty much made it happen. You’d be hard pressed to find a framework today that doesn’t support it in some fashion.

But there’s a whole separate piece of modularity that takes place at runtime. In the context of my historical explanation of modularity within Java, you can look at OSGi’s ability to manage dependencies dynamically at runtime (via a header in your JAR MANIFEST file) as a “modularity win” and icing on the cake. But OSGi indeed goes farther than that. OSGi gives you the ability to install/uninstall, start and stop bundles dynamically (think Eclipse plugins) via its lifecycle, and that just plain gives me the “giggities.” To account for truly dynamic modularity OSGi also gives you requires and provides semantics (also declared via headers) akin to the requires and provides semantics you see in dynamic languages like Ruby and some Javascript packaging/dependency management frameworks. While this may seem like its strength is only in making a clear separation between APIs you use and export, its real strength is that this allows you to truly isolate your modules at runtime from trickery that can (and has) happened on a classloader level. “That couldn’t possibly work on an App server,” you say? I was skeptical, too, but not so fast…

If you’re the type that keeps up with the JCP space, you probably know there is a JSR “trinity” (equally as mysterious as its holy counterpart to the outside viewer) to provide a more robust modularization mechanism in varying degrees. That “quagmire” withstanding, OSGi has been mounting a considerable lead as the modularization system of choice in the JavaSE and EE/App server space. (It was already a formidable player in the embedded/mobile space, where it evolved from.) Nearly all major App server vendors have integrated the OSGi model into their core, which means they’ve probably cleaned up any classloader nastiness they’ve resorted to in the past. And now you’re seeing some of the leading frameworks like Spring and Web Beans/Seam 3 (and subsequently have signed up to publish themselves as OSGi bundles.) Not to mention the success that Eclipse has seen since refactoring itself to work off its OSGi implementation, Equinox.

If OSGi can continue to make inroads in the framework space, I think its prospects to the “in the trenches” Java developer are very exciting indeed. Expect me to babble on more about this in the future…

More Related Content

• July 24, 2009 -- The Elements of Reusable Code (0)
• June 3, 2009 -- What is Hamcrest? (0)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• March 19, 2008 -- New Wave Logging (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• June 9, 2009 -- Mocking with JMockit (5)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)

I’ve been doing a lot of reading lately and have been meaning to plug some of my favorite reads, and one of the things that I’ve been trying to read with an eye toward is for converting those that have been stuck on “behind-the-curve” projects to the new way of thinking and doing things. As such, and just in time for the weekend, I’ve compiled a list of my favorites with an eye to the “movers and shakers” that have driven innovation in the Enterprise Java world recently. Note that even though some of these links are specific to certain frameworks/technologies, there is a common thread throughout most of these that have a bigger focus on the best way to solve problems using Java 5/EE 5 constructs and concepts.

A book that should be on any Java developer’s shelf is Effective Java (2nd Edition). Make sure you get the second edition, for all of the Java 5 changes. This talk by Joshua should whet your appetite. (His talk on good API design is also very good.) You should also take a look at Bob Lee’s talk on Guice. Guice’s philosophy and focus on typesafety has spilled over into Web Beans (and newer versions of Seam) and its annotation based approach has heavily influenced newer Spring features. I especially like his points on type safety around the 11-minute mark. The walkthrough at the end of the talk from “old way” to “new way” is great for people who haven’t really gotten away from Factories, Delegates, and Service Locators yet.

The Guice video mentions that a common thread in modern Java frameworks is a focus on testability. Testing is a very important concept that nearly all new frameworks have embraced, but you still need know-how to be successful with testing. I’ve come across some great books recently in the automated (developer) testing arena. I’ve found the most thorough book on the topic out there is Lasse Koskela’s Test Driven. The ideas and topics discussed in the book are really language independent, and work equally well with other languages. To cut your teeth on TestNG, which the Seam documentation turned me onto, I recommend the TestNG developers’ book Next Generation Java Testing: TestNG and Advanced Concepts. Cedric Beust, also the author of EJBGen, and Hani Suleiman, author of the Bile Blog, produced a book that was a suprisingly good read. It’s packed with a lot of knowledge and some interesting takes on EE concepts. Newer versions of JUnit also include many of these features and concepts, so you’ll get the underpinnings of these concepts in this book. This video gives you a basis to TestNG’s approach.

As one of the growing number of developers who have an application in the Seam In Production page, there are a few Seam resources I have to share. Even if you don’t get into Seam, it should be on your radar because a lot of the core concepts around conversations have evolved into Web Beans, and are found other frameworks like Apache Orchestra and Spring WebFlow. Pete Muir did a Webcast that’s a great introduction to Seam 2.

Author of one of my favorite Seam blogs, Jacob Orshalick, has created a DZone RefCard for Seam 2.1 Core. It’s right off the presses, being published this week, but is a great quick-capsule review of what Seam can do for you, and nice to have on your desk if you’re writing Seam. If you need more in-depth descriptions of what’s on the RefCard, Jacob also coauthored the latest edition of the great Seam reference Seam Framework: Experience the Evolution of Java EE.
Dan Allen’s Seam in Action is another excellent resource. Of course, the awesome Seam Docs and Forums always come in handy. You should also RSS in.relation.to – the Hibernate/Seam developers’ group blog.

I know I’m leaving some great things out. What resources do you think someone who is used to J2EE should take a look at to get them “up to speed” with the state of the art?

More Related Content

• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• March 19, 2008 -- New Wave Logging (0)
• June 9, 2009 -- Mocking with JMockit (5)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• January 13, 2009 -- On Software Quality (8)
• August 21, 2008 -- Weblogic 9.2 + Seam : Victory is Mine! (1)
• August 2, 2008 -- How I Escape the “Reuse Trap” (0)
• July 21, 2008 -- Pimp My Build (0)
• March 13, 2008 -- Continuous Integration Dissected (0)

Trying to run through a screencast I’m putting together after upgrading to Leopard, I noticed Maven giving me a strange error when trying to run archetype:generate and realized that Leopard includes its own version of Maven (and Ant) out of the box.  The problem is that it’s version 2.0.6, which doesn’t have support for this feature.  I then set about trying to upgrade Maven (and in the process, Java) and here is what I uncovered.

First of all, I screwed myself over a bit by customizing my /etc/profile under Tiger; there were changes to this file that came in with Leopard but I can’t see where the updater tried to merge them in at all.  There are changes in Leopard to how paths are configured using a script called /etc/path_helper, but I don’t have any of that getting executed.  It took me a while to figure out this was the reason my .profile, .bash_profile, etc weren’t getting source’d properly.  What I did was pull out all of my updates to /etc/profile and just add in the following:

So at least now I have my .profile getting loaded properly.  I’d still be interested to see someone’s /etc/profile that works out of the box with the call to /etc/path_helper, but this is all beside the point.

Applying the Java update was painless – it worked fine through the Apple Software Update utility.  You can download it here manually if you need to.

Next, you’ll probably notice that Java 6 isn’t enabled by default.  This blog will show you how to switch over to 6 using the Java Preferences utility.  There is a flaw in the ointment, though – for some reason it appears that it doesn’t switch over all of the symlinks properly.  Maven’s startup script gets confused by this in a few steps.  You can read more about it in this message (some JIRA comments) from their mailing list.  The workaround is to just point your JAVA_HOME directly to the 1.6/Home directory.

You can install the newer version of Maven at this point.  I saw this post detailing the instructions, but it was what I expected.  Just download the latest version and extract it to where you keep these kinds of things.  Then you just have to update your .profile (or .bash_profile) to set up some environmental variables for you.  Here’s what I included in my ~/.profile:

You’ll need to do source ~/.profile or exit out of your terminal and open it up again for the changes to take effect.  Once you do you can test to make sure you’re seeing the right version of Maven:

You can also check this by doing:

I guess we can chalk this one up to kicking the tires on Leopard. Hope this makes the process a little less painless for someone else!

More Related Content

• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• August 1, 2008 -- New Apple Wireless Keyboard (1)
• July 21, 2008 -- Pimp My Build (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• June 9, 2009 -- Mocking with JMockit (5)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)

I couldn’t find any definitive answer to this question, so here’s what I found, just incase anyone else needs this little nugget of information: the runtime dependencies for an Axis2 client that uses Axis Data Binding (ADB):
activation.jar
axiom-api.jar
axiom-dom.jar
axiom-impl.jar
axis2-java2wsdl.jar
axis2-jaxws.jar
axis2-jaxws-api.jar
axis2-metadata.jar
axis2-saaj.jar
axis2-saaj-api.jar
backport-util-concurrent.jar
commons-codec.jar
commons-fileupload.jar
commons-httpclient.jar
neethi.jar
wsdl4j.jar
wstx-asl.jar
xml-resolver.jar
xmlbeans.jar

It’s long, I know – but not as long as what you find in $AXIS2_HOME/lib!

More Related Content

• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• July 21, 2008 -- Pimp My Build (0)
• March 19, 2008 -- New Wave Logging (0)

In terms of the sheer number of moving parts, extravagance, and complexity, the build-tool landscape is one of bells and whistles that can be a little tough to stay on top of. There are a few important pieces of a robust and valuable build, no matter what tools you use to achieve it, and by breaking the build into modules or categories, we can make a little bit of sense out of the chaos.

In our vast build-tool landscape, there tend to be some zealous cults out there, entrenched deeply in their own camps and unwilling to venture out to explore what the rest of the landscape has to offer.   Thus, there have been some religious-like differences of opinion about which build tools are better and why.  Sadly you run across these types of biases all too often, which only pollutes the landscape and makes it more difficult to wrap your head the most basic questions underlying all tools:

• What does it accomplish?
• When is it (or isn’t it) right for the job?
• How do I use it effectively and efficiently?

With a pragmatic view, we can try to cut through a lot of the BS and figure out if a tool is worth its weight in:

1. dependencies/design complexity.
2. ease of use/interface complexity.
3. architectural decisions/compromises that it brings to the table.

Does the tool get us to the goal of a single button build/deploy?  If the answer is yes, I’ll welcome it with open arms.  Does it add me a form of feedback or some kind of statistic that could be a kind of gauge on a dashboard?  Then I may be interested in it, but it’s not nearly as vital.

Here’s an outline of what I typically look to include in a project’s build before I am satisfied:

• Compile – Obviously your build script would be for naught if you didn’t include this piece.  There’s also something to be said about some dynamic/interpreted languages (that run on the JVM) taking the hit on this step and producing compiled versions.  The argument is akin to compiling your JSPs back in the day.
• Unit test suite – Another one of those no-brainers!  You’ll obviously want to integrate your ability to run a single test or test suite from a build tool quickly and easily.
• Test reports – Test reports are an important way of visualizing the health of your project and are usually the first place you’ll go when you see something wrong.  A must have.
• Transitive dependency management – This is one of those sticky subjects that people like to argue about religiously.  Really the important thing to note here is that a crucial part of keeping your build clean and manageable is figuring out how to represent and resolve transitive dependencies, or second-level dependencies.  If your code directly depends on a library, odds are that library has its own run-time dependencies that need to be satisified in order for it to work properly.  Since managing the different versions of many different libraries can become tough when you start to look at different “stacks” of software, many people advocate having a tool help you resolve these dependencies so it’s not as daunting a task to get the entire stack to work again when you need to upgrade a single library.  Maven and Ivy solve this problem by introducing repositories that will house and dynamically resolve these versioning issues, in much the same manner as yum or apt-get does in the Linux world.  A lot of newbs will make the mistake of thinking this type of functionality will let them turn off their brain when it comes to think about their project’s dependencies.  They will be sorely mistaken!  The point of these to make resolving conflicts in transitive dependencies easier, they do not replace your brain, nor your obligation to know the dependencies in your project and how they fit together!
• Utility ant tasks – the daunting part of learning how to write good builds has a bit to do with how much you know about the ant task landscape.  Nearly all libraries have tools that plug into ant, but which ones do you really need to know about?  I’ve found a few are quite powerful, particularly replace, uptodate, cvstagdiff (and corresponding svn’s), xmltask and dbdeploy.  I think these tools should be looked at when you are trying to figure out how to accomplish something specific, and for that reason, they’re a bit more like “bells and whistles” than anything else.  The same goes for the next category, which arguably doesn’t even need to live in your build (but if you’re a team player, it’s a definite nice to have):
• Static analysis – There have been a barage of slick static-analysis tools that have entered the Java landscape recently.  A few are FindBugs, PMD, CheckStyle.  While most of these tools have plugins that integrate nicely into an IDE, it’s also helpful to have them plugged into your build, too.  Just to make sure everyone is following the rules.  A few others I’ve seen that focus on cyclomatic complexity, cohesion/coupling are Metrics and JDepend.

What build tools fit into your pimped out script?

More Related Content

• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• September 10, 2008 -- Axis2 client using ADB – runtime dependencies (6)
• March 19, 2008 -- New Wave Logging (0)
• March 13, 2008 -- Continuous Integration Dissected (0)

Tired of messy logging logic cluttering your code with a bunch of if/else statements? Don’t let logging cramp your style! The approach Seam takes to logging makes your code pretty again (and other things). What does this mean for you? No more “code guards“!

A nice byproduct of the genius of Seam’s design is that many common problems can be solved by using EL as veritable swiss-army knife. We’ll look at this through a logging example specifically, though it’s just one of many different innovative ways of solving problems using Java5 features and EL as a general approach.

WTF is a code guard?

What goes without saying in most of the discussions regarding logging is that excessive logging can be the largest and most common performance bottleneck in code that meets its functional requirements. Thus, logging APIs introduce the idea of log levels, to ease the burden of excessive logging. Generally, log levels are a configuration setting on a per-environment basis. Development environments will typically log most dependent code at the info level, and cut that up to the debug level for custom code or when things go awry with a piece of dependent code. Testing environments typically log at info while production will often just log at the warn level.

While this is all well and good, we find that for a lot of the logging we do, we typically run across an ugly little flaw in this approach that’s produced an equally ugly hack as a work-around. Enter the code guard. From the log4j docs:

Code guards are typically used to guard code that only needs to execute in support of logging, that otherwise introduces undesirable runtime overhead in the general case (logging disabled). Examples are multiple parameters, or expressions (e.g. string + ” more”) for parameters. Use the guard methods of the form log.is<Priority>() to verify that logging should be performed, before incurring the overhead of the logging method call. Yes, the logging methods will perform the same check, but only after resolving parameters.

What’s all this business about resolving parameters? Let’s look at an example:

So, we need this cluttered if/else around only to ensure that our expressions (concats, usually) won’t get resolved unless we actually want them to. Why is there no other recourse? The answer isn’t surprising – it comes down to the way the API was designed. All log4j logging methods take a single argument — which made a lot of sense, I suppose when the powers that be first designed logging APIs. They soon realized that in order to use their API, one has to use an expression to resolve all parameters into a single argument prior to calling the method! This is why a code guard is needed.

Java5 introduces a feature that allows for varargs, and taking advantage of this can help us with our ugly little logging problem, e.g.

With this approach, our expressions won’t get resolved until after we’re in debug(), and we can let it do the dirty work inside the method. The first thing that our logging method does is check to see if its level is valid, otherwise it’ll fall out immediately. Because the concatenation happens inside the log method, we don’t need a code guard to protect us.

This is the approach that Seam takes to logging. Seam’s Log interface provides not only a solution that removes the need for code guards, it also allows you to use EL in your log messages (if you’re trying to dive into a Seam component…) – e.g.

Much better. By and large, this is the way you do logging in Seam. Because binding occurs late, you never really run into the problem where you need to even think about using something like a “code guard.” Code what you’re supposed to; not noise! This is just one of many novel ways to use EL in Seam, and why it really deserves a look as a way to write better code, faster and as a far more productive platform for Java programmers (fed up with JavaSE/EE 1.4) than Rails/Grails.

See the Web Beans Manifesto for much more on this approach.

More Related Content

• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• June 3, 2009 -- What is Hamcrest? (0)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• January 21, 2009 -- 16 Apps That Lessen TEH SUCK of Web Development in XP (8)
• January 13, 2009 -- On Software Quality (8)
• December 1, 2008 -- 24ways (1)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• September 10, 2008 -- Axis2 client using ADB – runtime dependencies (6)
• August 21, 2008 -- Weblogic 9.2 + Seam : Victory is Mine! (1)