Preface

This work came out of an lack of consistent, cohesive documentation for beginners on transactions. Similar material does exist, but much of it suffers from either being hard to find, scattered and spotty, or not written at a basic enough level where requisite knowledge is not required in order to understand the material covered. Over the course of this series of articles, we’ll talk about what concepts you need to know in order to effectively and correctly make use of transactions in your applications. This series of articles is written as a set of core concepts to understanding the basics of transactions, and is intended for junior to intermediate level developers, but my hope is that others will benefit from this series as well. As always, feedback is greatly appreciated.

What is a transaction?

Etymology

The word transaction comes from the Latin word transactionem meaning “an agreement, accomplishment,” which itself comes from the past participle of the verb transigere, transactus, meaning “drove or carried through.”

Transactions defined

The word’s definition is typically related to business or economics, meaning a single business deal, or an exchange of goods between two parties. Most introductions to transactions use an example of debiting one bank account and crediting another. When we remove funds from one account, we need to make sure that they are deposited into the other. If something fails (sufficient funds do not exist in the account being debited, or the account being credited has been closed) then both accounts need to be returned to their original state before the exchange began. This is actually a very good example, but how does that apply to software?

Let’s back up for a second. If we focus on what’s going on, we begin to see there are two distinct activities in play:

1. Grouping a set of multiple changes together that all have been applied successfully, or, in the event of a single failure, that all need to be undone.
2. Managing (or coordinating) the execution of these changes, when their interactions might interfere with one another.

Examples of Transactional Systems

Like many other terms in the software lexicon such as “class”, “object”, “system” and “code”, the definition of the word “transaction” suffers a bit from the word’s inherent over-abstraction; it is widely applicable to a great many circumstances and situations. But once understood, is easy to spot scenarios where the pattern is used and applied. Transactions are important in software when updating shared resources, like a cache, database, or message queue, but also come into play when reading – especially when access must be coordinated across many separate but concurrent workers reading shared data. We’ll talk more about this in depth later. Some examples of systems that heavily utilize software transactions are:

• eCommerce (Shopping-Cart, Billing, Banking) Applications
• Relational Databases
• Caching Systems
• Messaging Systems (Message-Oriented Middleware)
• Source Code Management Systems

As you can see, not only are these fundamental building blocks of business software, but also modern distributed systems. Transactions are prevalent in the frameworks and tools we use to build, tune, and scale the software we write.

Specifying Transactions

ACID properties

A technological definition of the word transaction involves specification of qualities (or “properties”) that must be enforced in order for the transaction to be processed successfully. These properties, the ACID properties as they are known, grow out of our business concept of a transaction (an exchange between two parties). They exist as conventions that specify or constrain the software that’s responsible for processing transactions. Enforcing all four of these properties guarantees the transaction is reliable and therefore viable candidate for successful completion/processing.

• Atomic – When we say transactions need to be atomic, we don’t mean that they need to be small, though often they are. What we mean is that you can’t subdivide a transaction any further – the group of changes must be viewed as a single set. When applying that set of changes, it’s “all or nothing” – that is, each and every individual change processes successfully, or else the entire group is undone completely. There are no “partial” transactions; we can’t subdivide them further.
• Consistent – If a system successfully processes a transaction, then all resources involved in the transaction must be consistent afterwords – whether the transaction processed successfully or not. For example, if one account is debited and another is credited, the balance of the debited account must be equal to the difference of the original balance and the price of the transaction (and vice-versa for the credited account). Transactions that do not complete successfully should not have any side-effects to either party involved in the transaction.
• Independent – Transactions should not interfere with one another, even though they may involve shared resources. For example, one transaction should not be able to see the work another transaction is currently performing until that transaction has completed. They should be independent or isolated. Typically, transaction isolation becomes an issue as transactions being processed become larger: that is, the longer they live or the more resources that they enlist. Isolation also has performance implications as the amount of load or concurrency increases. Isolation mechanisms expose either locking or multi-version concurrency control (MVCC, “diff-ing” or delta-management). We will discuss these later when we talk about concurrency control and isolation.
• Durable – Systems processing transactions must record successful transactions so that a history of the transactions processed is not lost. Relevant actions taken are logged for auditing purposes. This audit trail allows the state of the transactional system to be recreated at any point in time if there is a system failure. If the information cannot be recorded in this way, we can not say we have a durable transaction, because we won’t be able to recreate the state of the system if a failure occurs.

In a real world business transaction, these conventions are likely enforced by human beings involved in the transaction. If one of these properties were violated during your checkout at a store in the mall, then either you or the clerk would be pretty upset and likely to call in relevant authorities to sort out the matter. For example, if you bought a shirt but were refused a receipt for the transaction, you would most likely be upset and demand a refund, as the receipt is confirmation of the transaction’s durability.

Why Should I Bother Using Transactions?

As you can see, transactions also provide us with some guarantees about what will happen in the event that something goes wrong during the interactions between shared resources. These guarantees are very useful to us as software designers and developers, but their benefits may not be intuitively obvious until we consider what our jobs would be like without them. Transactions give us with a safety net of assumptions; when something goes wrong, we can lean on the transaction’s guarantee to rollback, or automatically revert all changes from the start of the unit of work. Imagine if we didn’t have this guarantee: we would be forced to write code to cleanup the mess we’ve created, and not only is this code hard to maintain, it’s hard to write and get correct the first time. With transactions, we don’t have to worry about writing extra code to “cleanup” the mess we’ve created, and can instead focus on what the code we’re writing is actually supposed to do: the business logic. When something goes wrong, we can safely assume certain scenarios are out of the question by using transactions. In many circumstances, transactions are key to writing code that is functionally correct, and most of the time make the code cleaner, more robust and maintainable (especially when considering the alternative of coding cleanup logic by hand).

Transactions are fundamentally all about coordinating access to shared resources. A term that can be used interchangeably with the word “transaction” is unit of work. Transactions are important to software systems because they’re how we manage interactions with the different systems involved that have access or expose shared resources to clients.

Typically when we work with transactional systems, as application developers we:

• Write code that explicitly utilizes a transactional API, like JDBC, that will contain the semantics for how to handle the processing of the transaction, or…
• Configure a transaction management mechanism, like an EJB container, that can do the processing and coordination work on our behalf based on conventions.

The next article in the series will provide examples of both approaches. Either way, the end result provides a way to keep each unit of work’s interactions separate from each other, and guarantee that all changes in the set are applied together or undone completely.

Up Next: Writing Data Reliably

• Programming With Transactional Systems
• Declarative Transaction Management

Further Reading

• http://www.etymonline.com/index.php?term=transaction
• http://en.wikipedia.org/wiki/ACID

More Related Content

• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 24, 2009 -- The Elements of Reusable 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)
• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• January 13, 2009 -- On Software Quality (8)
• 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)

In a recent tech talk, I watched Miško Hevery propose an interesting challenge to his audience: start a toy project and try to write the code with no if-else or switch blocks at all. None at all?  Before thinking about how to do this, why would you want to do it in the first place?  On the surface, it may seem to the unassuming a bit counter-intuitive.  Comparison-based branching is at the heart of programming, and the concept of an if-else or switch block is almost universal, existing in most every programming language ever devised.  What’s Hevery’s agenda with this exercise – and what can possibly be gained from trying to write a program without branching entirely?

Branching Considered Harmful?

In 1968, E.W. Diskjstra, famed programmer and author of the shortest-path algorithm, wrote an article to be published in the Communications of the ACM entitled “A Case Against the GOTO Statement” that was later renamed “Goto Statement Considered Harmful” by the editor.  The phrase has grown into a meme of its own in the CS community, denoting a practice that has fallen from grace and become widely discouraged.

I bring this up not to point out its cultural signficance, but the core of his argument:

The go to statement as it stands is just too primitive[;] it is too much an invitation to make a mess of one’s program.

Essentially, Hevery is making this very point for the if-else statement, 40 years later, but for very similar reasons.  If-else and switch statements easily account for some of the ugliest code that I have seen (and written).  Overuse of if-else blocks can lead to the arrow antipattern, a scenario where conditional branches are so deeply nested they become unmaintainable.  Too often developers fall into this trap, described aptly by another Dijsktra quote:

The prisoner falls in love with his chains…

Hevery’s point is that code without if (or switch) statements is:

• Easier to read and understand
• Easier to test
• Easier to maintain, extend, etc.

But how do we write code without branching constructs?   If we are talking about fixing the arrow antipattern, you may know a time when you avoided this antipattern by using separation of concerns, for example, the MVC pattern instead of a monolithic servlet.

Hevery’s Suggestions

Hevery goes on to explain how good OO design can eliminate the need to explicitly code the most egregious uses of branching, by instead favoring dependency injection and polymorphism.  But this technique is only really useful where we can create methods and objects that are cohesive and loosely coupled.

With polymorphism, you dispatch into a method whose binding is not known at compile-time but determined at runtime.

This is the weapon of choice when we are working on code that is highly procedural and there is a bad OO-design smell.  But it is far from a one-size-fits-all solution.  If we were to transform every branch in our program by instead using polymorphism, it would be a tangle of incohesive objects that would likely be harder to maintain than the original procedural code.  Luckily, there are other techniques that are more appropriate in certain circumstances.

Hevery continues: certainly, primitive comparisons are going to be the most difficult to eliminate, but shouldn’t happen very often.  So we reluctantly allow these to stick around.  Another class of if statements exist to check against nulls.  Hevery explains how null pointer dereference checks quickly become pandemic, occurring every time a member of an object is referenced.  This should largely be a non-issue, and is only a problem because code is allowing nulls to be returned.  The semantics/method contract of most methods can easily be changed to prohibit the return of nulls.  (This is only really difficult when recursion is used.)  Developers, as it turns out, don’t have to return null values.  This is particularly true with collections, and warranted a section in Joshua Bloch’s Effective Java.  Instead return an empty collection can be returned, or you can implement the null object pattern (e.g., a no-op logger).  Hevery finally rallies for ditching using return codes in favor of throwing relevant exceptions.

Note: I encourage you to watch the talk, as he continues talking about how specifically you can use inheritance and polymorphism to remove branching. The rest of this article will talk about other strategies to remove unnecessary branches.

Remove Copy-Pasted Loops And Conditionals: Introduce Enumerable Operations

Many languages contain an enumerable construct that includes “higher order” looping operations that can eliminate the need for many specialized cases that are usually solved by a foreach loop with an embedded conditional check of some sort.  This type of construct can be traced back to Smalltalk, and exists in most modern dynamic languages such as Ruby, Groovy, Python, and provided by a number of Javascript libraries.  Getting this to work in Java is a bit of a challenge because there is no mechanism for closures (yet) but some partial solutions do exist (they lack the full power of true closures, but overusing true closures can break down OO-style constructs).  For further information, take a look at lambdaj, Adrian Kuhn’s Pimp My Foreach and Google Collections’ Iterators.

Here is an example of the types of things this style of programming can fix.

List<Integer> numbers = Arrays.asList(0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
List<Integer> oddNumbers = new ArrayList<Integer>();

for (Integer check : numbers) {
    if (check % 2 != 0) {
      oddNumbers.add(check);
    }
}

In the case of the Google Collection, they call their enumberable construct a “Iterable” and the closure construct a “Predicates,” we’ll be able to replace the above code with this:

Predicate<Integer> oddIntegerPredicate = new Predicate<Integer>() {
    public boolean apply(Integer input) {
        return input % 2 != 0;
    }
};

Iterable<Integer> oddNumbers = Iterables.filter(numbers, oddIntegerPredicate);

LambdaJ, and Kuhn’s solution work in a similar fashion.  While syntactically not as pretty as the dynamic languages, these constructs are functionally equivalent and arguably no more painful than the original code.  In many cases of deeply nested for-if-for-ifs, it significantly reduces the cyclomatic complexity).  This style of programming, once everyone on the team has become familiar with it, can reduce often copy-and-pasted looping code to one liners, removing some really ugly duplication and the potential for those hard-to-spot copy and paste errors.

Lookout for Train Wrecks: Obey the Law (of Demeter – and other SOLID Principles).

Steve Freeman and Nat Pryce describe “train wreck” code in their new book Growing Object Oriented Software Guided By Tests as chained “getter” method calls, linked together like train cars.  The authors call them “wrecks” because the code is essentially an egregious violation of the Law of Demeter.  One of Nat’s examples:

employee.getJobDescription().getResponsibilities().add(new ManagementResponsibility(employee.getDepartment()));

The problem is that this style of programming destroys all encapsulation and information hiding concepts in code.  Train wrecks can become pandemic as well because instead of using an object-oriented style of programming that passes messages between objects to perform work, we essentially allow objects to know too much about their collaborators and details.  Another way this has been said is “talk only to your friends” or “ask, don’t tell.”  A client object asks other objects what their state is, and uses an if statement to perform an action, instead of telling the collaborating object what it wants done, and letting that object figure it out.  Instead of the train wreck, we should extract the behavior to a method that allows us to tell our collaborator what we want done:

employee.promoteToManager();

Complex conditional “train wrecks” can often be extracted in the same way.  Quite often these types of objects are really just procedural code masquerading as a class, and will be in violation of other SOLID-principles such as the Single Responsibility principle.  Making this code more “SOLID” will make it easier to test and maintain.

The Bigger Picture: Well Designed, Testable Code

Remember, this exercise in design (by removing ugly branching) is not just for aesthetics.  There is a very legit reason to try these techniques: writing testable code.  Hevery’s talk (and his other talks) are essentially about how to write code that is testable.  Freeman and Pryce’s book is about the very close relationship between testability and OO-design.

If you like these ideas, you might be interested to try the TDD As If You Meant It exercise as well.  This is an exercise that will show you how to listen to test code to drive adding features that are driven out by tests into your production codebase by implementing them first in the test class.  This is the ultimate way to ensure that your production code contains only what it needs and nothing more, and that code is adequately covered by tests!  Remember, the more code you write into production code, the more you’re going to need to maintain it, and the more skeptical you should be about how readable and well designed it is.  These techniques and exercises may seem silly on the surface, but if you explore them I am confident they will help you write better code!

More Related Content

• July 8, 2010 -- Transactions, Part 1 (0)
• July 24, 2009 -- The Elements of Reusable 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)
• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• January 13, 2009 -- On Software Quality (8)
• 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)

The competent programmer is fully aware of the strictly limited size of his (or her) own skull; therefore he (or she) approaches the programming task in full humility, and among other things he (or she) avoids clever tricks like the plague.
–E.W. Dijkstra

Designers are something of an enigma to most people; however, the fruits of their labor are largely understood, well used and appreciated. Design is often considered to be a purely aesthetic matter: a matter of taste, of style, of opinion; we know a good design when it when we see it.  But many times we can’t quite put our thumb on why it’s good design, or what makes it well-thought out, or pleasing. Maybe some of us can articulate what it is we like about design, but few connect the dots enough to notice recurring qualities in our favorite designs or think about underlying truths beneath those qualities.  Even fewer still have the experience to know when to apply these qualities, within the proper context to produce a good design.

Programmers are equally if not more engimatic to general society.  Perhaps on the surface for many different reasons.  But, coincidentally developers are designing all the time; could this play a part, perhaps?  Is this why we refer to the most experienced of our profession as “architects?”  Aren’t we, by way of programming systems and wiring them together, inherently striving for greatness as designers?

Especially when you’re inexperienced, you’re very much focused on learning what it is about a design that you find compelling, agreeable, or pleasing.  We value a good design so much that we spend a lot of time studying, talking about and debating what makes a good design.  As the narrator (Jack?) in Fight Club admits he had become “a slave to the IKEA nesting instinct,” so too, I find myself in willing servitude of the design pattern instinct at times.  More often nowadays I stop and catch myself, and I’d like to think I’m not the only one with this premonition.  Too quick are we to whip out our design patterns books (especially right after we’ve finished them) and, as the first order of business, go to town solving problems we don’t have.

Few products today need to ship in shrink wrapped boxes as they once traditionally had to.  The connectedness of the Internet, coupled with all of the modern advances in hardware have fundamentally changed the way we look at developing software.  “Fast, cheap, good – pick any two” still applies, but fast is faster, cheap is a lot cheaper, and good encompasses much more today than ever before.  Software development still lags behind.

The unwise developer makes all design decisions up front, for fear of getting the solution wrong.  The enlightened developer creates the closest thing to a working solution now, for fear of getting the solution wrong.  The former produces a solution that fits his view of the problem.  The later continually adapts his solution to encompass others’ view of the problem.  Which is more valuable?  The unwise developer wants to be done, and will sacrifice alienating some users.  The enlightened developer wants to be correct, and will compromise stability of the design.  Why do this? Because inactivity leads to software rot, and we have techniques for dealing with changing designs.  What good are our big up-front design skills when the requirements change?

Like Darwin encouraged us to do with our views of biology, we’ve ditched an up-front design model for an evolutionary one.  There is increasingly a focus on software as an evolutionary process everywhere, and it’s phrased in many ways: continuous production (Cal Henderson’s explanation the best); the perpetual beta; “no such thing as done“, agility – openness and responsiveness to change.  The risk of bloated software has lead us down a path to focus on and seek to create small, modular applications that create “business” value immediately, can be chained together but never grow overly complex.  Our design decisions still exist, but they are on a much smaller scale, and with much more concrete drivers and concerns factored in.  And we understand that we’re fundamentally in error when we make them out-of-context.

Others have thoroughly dealt with this topic in much greater detail than I can or care to.  Neal Ford has written about what Evolutionary Architecture and Emergent Design look like.  Martin Fowler has asked, “Is Design Dead?” and answered his own question.  I would encourage you to read their thoughts on the matter, as my own conclusions are largely in line with theirs.

That being said, there are some tools that you should look to add to your collection as you go.  Any craftsman must learn to master his or her tools.  Just having the tool in your toolbox does not necessarily make you a good designer; because they must be used properly, in the proper context.  Like Clint Eastwood’s character explains of his toolkit in Gran Turino: each tool has a job, its own context and realm of applicability.  Also, resist the urge to apply them every chance you get.  Much of good design is about restraint.  Try to see them applied correctly, or incorrectly, and talk with others about it.  Keep a conversation going; don’t allow your codebase to become stagnant.  Continually question, strike the right balance and good designs will emerge and bad designs will improve. Your methodology may have you delivering in sprints, but good design is a marathon.

Here are the basic tools.  There is a lot of material out there on these – easy to Google or find on Wikipedia.  I am not going to offer any links or speculation, because I think these things should continually be discussed.  You should be constantly evolving your own opinions and knowledge of them.  They must be used, discussed and understood in order to be mastered.

Overarching Computing Principles – Reduce Complexity

• KISS – Keep it Simple, Stupid.
• DRY – Don’t Repeat Yourself.
• YAGNI – You Ain’t Gonna Need It.
• SOC – Separation of Concerns.

Basic OO Principles

• Inheritence
• Coupling/Cohesion (dependency)
• Encapsulation
• Modularity
• Abstraction
• Polymorphism

SOLID (Advanced) OO Principles

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Emergent Design Techniques

• Test Driven Development
• Continuous Integration
• Refactoring
• Project Automation
• Continuous Production

To borrow a great closing quote from Brian Liles,

Do not seek to follow in the footsteps of the wise. Seek what they sought.
–Matsuo Basho

More Related Content

• July 24, 2009 -- The Elements of Reusable Code (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• June 9, 2009 -- Mocking with JMockit (5)
• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• December 1, 2008 -- 24ways (1)
• 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)
• August 2, 2008 -- How I Escape the “Reuse Trap” (0)

Back in April, there was an interesting article quoting Ron Jeffries et al on InfoQ looking at code reuse from an agile perspective. The conversation steered toward explaining reuse as a concern that is very expensive, looking at it from a top-down, “enterprise”-wide lens.

But is code reuse a black and white issue? My contention is there are varying degrees of reuse that are often neglected on a microscale within an even moderately-sized project. If the code you produce isn’t going to be reused, is it even going to be looked at? These are similar problems with similar solutions.

As far as producing reusable code, I believe there is a medium of full-fledged, framework or API degree of reuse and also a “just enough” degree of reuse. The article touched on a similar concept:

Adam Sroka called this ‘emergent reuse’ and noted that this seemed more efficient than the ‘design for reuse’ approach. A poster named Tim explains it to his business people this way: “The first time you have to pay for it to be coded, the second time you have to pay for it to be reusable, the third time it’s free.”

A higher degree of reuse requires more of an investment in these principles and practices. What’s more, I think the article fails to draw a distinction between the roles (or competing concerns) involved in reuse: not only should we be worried about reusing code we produce, but often we are presented with a very real problem that wasn’t talked about in the article which is how we consume code that we choose to reuse.

A project is itself a consumer of its own code, and many times you’ll find a codebase is not even internally consistent in how it reuses code within itself. Quite often consumer-reuse happens in the form of depending on third party libraries, open source frameworks or APIs. In this sense, reuse becomes an issue of code quality, or more aptly, code cleanliness.  It’s hard to come up with solutions to big problems by just thinking about an ideal solution, and even if you are able to do it, odds are your solution will probably be rather academic.  It’s easier to make progress on large-scale problems by breaking them down, and making a habit of looking for patterns and ways to combine, compose and chain smaller solutions.  Like we do with Agile problem solving approaches.  Can’t we do that for the hairy reuse problem?

Decomposing the Problem

Code reuse is a tough problem to nail down, because it’s a high-level view composed of a whole host of smaller concerns. With a nod to separation of concerns, I’ve tried to decompose these competing factors into their own categories and make some suggestions of things to look at if you’d like to have a higher degree of reuse within your team or code base.

Communication Concerns

Communication Saturation

Last night I listened to an Agile Richmond talk by Jeff Sutherland espousing the ideal of communication saturation.  Jeff was talking about Scrum, and wanted to draw a strong correlation between this saturation and “hyper-productive” teams.  The key, Jeff said, was the ability of the group to recognize what is the next most important thing to work on and come to a collective decision about it.  This resonated with my experience with agile.  Our group was able to defer stories where we saw reuse was going to be apparent in the future, and this not only did this save us time in the long run, but it made the problem of “discovery” and consumption a no brainer.  Everyone on the team knew a component we delivered one release was to be reused in future releases, even if we weren’t involved in developing it.  This, coulped with the idea of collective code ownership, opens all the right communication channels for a software development project in my opinion.

Value cross training

Don’t be afraid to ask for help or give it if you can provide help. Educate yourself and teach others. You’ll find that successful teams do this naturally through many different ways. If it seems tough to approach individuals, a better course of action may be to schedule a weekly development meeting to discuss hard problems and solutions to those problems. Record topics that come up regularly. An informal retrospective after a release or milestone can go a long way to correcting the course of the ship.

Design Concerns

Cross cutting concerns

A whole class of reuse problems can be boiled down to reinventing the wheel instead of solving core business problems.  If you’re solving a technical problem, is it a cross-cutting concern?  If you can identify a problem that has been solved in more than one way, it’s a good idea to pull the team together and talk about a good way to solve it moving forward.

Refactor mercilessly to remove duplication

Refactoring to remove duplication is a skill that takes practice and diligence to do well. But it’s often a quick win to spot and remove duplication; Don’t Repeat Yourself will go a long way to improving the quality of the code your team produces by coercing the design of the code into something more fundamentally sound and amenable to larger scale refactoring later.

Reuse problems are often a manifestation of not having “everything in its right place.” If you always know where to go to get a hammer, then the problem is reduced to that hammer being there when you go to get it.  The bigger problem is (rightfully so, now) knowing when you need that a hammer.  This is not necessarily going to solve the problem of discoverability or consumption for you (communication is needed for that), but it will help with organization tremendously.  Whether or not you achieve an enterprise degree of reuse may be a horse of a different color and have a lot to do with communication, but in the microscale refactoring is the weapon of choice.

Names Matter

If you are able to refactor using composed methods, naming becomes a lot easier. Each method will aim to solve one single “atomic” concern, and larger methods will become more readable and logical as they get shorter and more maintainable.

Technical Concerns

Know the language and learn standard APIs

Unit testing can help you learn a new API fairly quickly and document some hard-earned pieces of knowledge going forward. A handy construct that is available in many languages is a shell interpreter like IRB or BeanShell, which can be invaluable in helping to pick up the syntax and semantics of a language. Wikipedia has a list of interactive programming language shells.

Modularize your code

Modularization is important. Few languages support full modularization OOTB. At the base level, you need to be able to encapsulate your code and also package or namespace it. This is all you really get OOTB in most languages. Ideally, full modularization would provide you with the ability to bundle together code and provide a mechanism to have the code installed or uninstalled dynamically at runtime – in order to achieve this you often have to specify dependencies between modules and declare a version for your bundle. (OSGi aims to do this in Java, and is definitely worth a look).

Modularization is important to code reuse because it presents a barrier to someone else using your code. If I want to use a particular component or method that exists in your library, that means I am fundamentally absorbing the lowest-level dependencies that you have. If your project is not properly modularized, I may have to eat all of your dependencies. The larger your component is, the more complexity any consumer must absorb to reuse your code. Modularization should help with this problem.

SOA was supposed to have solved this problem, right?  At least a subset of reuse problems – iteroperability.  We’ve found it’s a lot harder in practice than it is in theory.  You have to version services, and use some registry to look up and discover a version.  Not to mention the governance issues involved.  This is why I’m so excited about OSGi.  This might be the way to take your microscale reuse to the enterprise, and the model (in practice, and arguably theory) is a good deal simpler than SOA, too.

Documentation Matters?

If you are writing an API or framework, you can’t argue that documentation will be incredibly important to the success of your project. Note, I’m not talking necessarily here about Java-doc style-documentation; rather, I’m talking about providing a would be reuser of your code with enough support to make them successful. Sometimes that means concise, well written and up-to-date API documentation. Quite often this will come in the form of a user or developer’s guide with a more narrative style or structure. FAQs or troubleshooting guides are often very important tools.

Reuse is something that is far easier to say than to do. Doing it requires both good design and very good documentation. Even when we see good design, which is still infrequently, we don’t see the components reused without good documentation.

-D.L. Parnas, Software Aging. Proceedings of the 16th International Conference on Software Engineering, 1994

Going Forward

We all know waste is a thief.  Rework is wasteful.  Solving the problem of reuse on a grand scale may seem intractible, but I think it’s just another problem, and arguably not even the hardest one we have to contend with in software development.  If we can break the reuse problem down from its mighty enterprise-wide incarnation into smaller, more digestable reuse problems, it becomes a lot easier to make progress.  And maybe one day we’ll find a way to get to that enterprise-wide reuse that may seem too good to be true at the moment.

More Related Content

• August 2, 2008 -- How I Escape the “Reuse Trap” (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)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• June 9, 2009 -- Mocking with JMockit (5)
• 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 13, 2009 -- On Software Quality (8)
• December 1, 2008 -- 24ways (1)

Update: I cleaned up the example based on Rogerio’s comments.

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this.

There’s no getting around the fact that some frameworks, especially legacy or proprietary third party modules, are not coded in such a way that it’s easy to write testable code against them. Common pain points include:

• Pervasive use of statics
• Lack of dependency injection mechanisms
• Creating dependencies inline with the “new” keyword

All of these issues will pose problems when trying to double-out dependent code for testing purposes. One approach to solve these problems is to use a dynamic language and metaprogramming constructs to do this kind of doubling. Testing Java code with JRuby or Groovy has become more and more popular for this very reason.

But a lot of these will introduce a level of language abstraction between your test code and the code under test, and you’ll have to have developers maintaining a test suite sign on to learn the language being used.

In comes JMockit, which uses the instrumentation features provided with Java5 to perform a lot of the same magic tricks for you.

This also allows you to test things that weren’t otherwise possible (or are very difficult) and overall I think the programming model is much more in-tune with standard Java programming idioms. It doesn’t discriminate against you if you don’t use dependency injection, but will work with you if you do. Here’s a quick example that colleagues Andy Pemberton and Patrick Cox worked through with me trying out JMockit.

You can get the whole project from my GitHub account.

More Related Content

• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• 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)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• 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)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)

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 just read Your Unit Tests Lie to You by Janusz Gorycki and I was going to leave a comment there, but thought it was more appropriate to expand my comments off into their own thing.  For those that haven’t read the article, its basic premise is to grab hold of the nearest “test infected” reader and shake the warm and fuzzy out of them.  It paints the short sightedness of many recent “unit testing” converts as living in a dream world where unit tests should replace formal testing. It follows with many sentiments I’ve read (and written about here) for a while now.  It’s not that I disagree with what is being said in the article, or its tone for that matter; most of what is being said is spot on.  Unit testing is definitely not a silver bullet.  If you read my blog often, you no doubt get that. The article ends:

So please, don’t fire your QA department just yet. Their job is still important, even if you unit test.

So to Janusz, the fundamental problem here is a general ignorance of the purposes behind a unit test suite.  I agree 100% that’s the primary factor behind his problem.  What don’t we agree on?  Semantics.  But semantics are important!  How far do we have to go for a true zen-understanding of this issue?  Not far.  Indulge me —

When is A Unit Test is not a Unit Test?

Here’s my thesis: you may use a unit testing framework, but what you write are developer tests.  Even if they are technically unit tests, it is against everyone’s interest to call them this.  Picky, useless distinction, you say?  Hear me out.

There is a vast difference between the gamut of possible automated tests one could write and what is known colloquially as a unit test.  A number of different kinds of automated tests are written against frameworks that are built on top of unit testing frameworks.  That doesn’t make them unit tests.  It doesn’t make sense to call them unit tests.  A square is a rectangle, but does that make every rectangle a square?  An automated acceptance or integration test is subject to a completely different set of problems (in areas such as specification, maintenance, complexity) than a unit test.  In fact, about the only thing they share is their lifecycle and execution model, which many times has been retrofitted into the JUnit lifecycle and execution model.

“Unit Testing” and Linguistic Drift

I’ve recently seen a number of different incarnations (1, 2, 3) of the argument that we should eschew use of the term “best practice” because of the implications of its linguistic drift and general propensity of people to turn off their brains when just spoon-fed answers, not having to experience deriving the solution for themselves.  Similarly, the popularity of unit testing frameworks and the sheer frequency with which the term has been used have, in a sense, set the idea of developer testing back considerably.  Cedric Beust makes the point that in many cases we’ve confused [developer] testing terminology with JUnit terminology, and TestNG was in part a response to that.  Here we oversimplify the problems we choose to bite-off and the goals we strive toward.  They’re not realistic.  Is it no wonder so many people fall flat when trying to adopt “unit testing”?

While there may be some overlap with the goals of validation and verification, most in the know consider the true benefits of “unit testing” to be a totally different animal altogether.  We seem surprised to find the benefits of doing developer testing have little to do with what “testers” do.  This dischord causes a lot of confusion, and has sparked a lot of articles.  Some draw this conclusion, appropriately, that developer testing, while it fits a rigid definition of what testing is, shares little with what a typical “tester” is responsible for (true V&V).  Quite often developers are the only ones doing any automation work, including this automated “developer” testing.  Developers tend to do it for all kinds of different reasons, too.  We’ll use a suite of automated tests to proceed without fear of integration errors.  That adds value totally independent of validation and verification practices.  If our suite catches regressions before we hand a single version off to testers, that saves both developers and testers time.  I could go on and on, but the term “unit testing” conveys very little of these kinds of benefits to the development lifecycle, and as it turns out, causes a great deal of confusion.

The Right Usage

When we’re talking pure unit tests, that is, black-box testing components in pure isolation (which requires isolated dependencies), not in concert, as developers we can certainly find merit in this practice.  But what we’ve learned is that this idea of unit testing, while quite beneficial as a development practice, shares very few goals with “testing” as we know it from a classical definition of the word (end-to-end V&V).  Perhaps a few years ago this distinction was not that true, but we now know better.  We know the danger in trying to bend unit tests into something they’re not.

My point is essentially this: knowing how to use a unit testing framework, a very simplistic construct on the surface, to do all of these wonderful things is certainly not something that just “falls out” of developing a unit of code – it’s not something we should expect developers to just deliver each iteration as part of their deliverable like it’s “done.”  Effort invested to develop and maintain test code alongside the code under test is not free.

Only if you are persistent will you come to understand there sometimes is very little benefit in terms of “full blown”, classical validation and verification – the whole reason you set out on this crazy “unit testing” kick. You either stick with it, or write it off at this point.  If you stick with it,  well, I’ll save you the trouble of figuring this out for yourself; you learn it’s only another development practice, that needs to be balanced out with other sound practices. It’s hard work.  Really hard.

Then why go to all the trouble?  It’s my contention, and I assume most will agree, that developer testing is useful.  It drives out better designs, code, and has the potential to thwart a caste of would-be regressions.  It can stamp out integration errors.  It can help you learn about a new framework or prototype a new feature.  But that usefulness comes with a very real cost.

If we truly acknowledge that the type of practice we’ve talked about has merit as a development process, it makes very little sense to continue referring to the practice as “unit testing.”  If testing modules of code, driving development with these tests, maintaining them alongside the code, and other automation activities are worthy practice for developers, we should consider the semantics of our vocational vocabulary.  Let’s stop confusing each other.  We’re not talking about delivering 100% code coverage, we’re not talking about replacing testers (unless you’ve got the huevos to go without them, anyway), and we’re surely not talking about writing or releasing bug-free software.  It’s a lot easier to cut through a lot of the hype and confusion if we can all learn to say developer testing and understand it as such.  Let’s put the term “unit test” to rest.

R.I.P. unit tests.  Long live “developer tests!”

More Related Content

• 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)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• June 3, 2009 -- What is Hamcrest? (0)
• March 13, 2008 -- Continuous Integration Dissected (0)
• March 11, 2008 -- Bugs, Detectives, and Test Automation (2)

More Related Content

• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• January 13, 2009 -- On Software Quality (8)
• March 13, 2008 -- Continuous Integration Dissected (0)
• March 11, 2008 -- Bugs, Detectives, and Test Automation (2)
• June 9, 2009 -- Mocking with JMockit (5)
• August 2, 2008 -- How I Escape the “Reuse Trap” (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 24, 2009 -- The Elements of Reusable Code (0)

Update: Sysinternals puts out some great developer friendly tools. They come in handy!
Update #2: I’ve made the switch to using Launchy over DOMercury.

Working on Windows XP is unavoidable at my job. While it’s not my favorite environment, I’ve found a decent baseline of software tools to augment the barebones OS that can get me to a place where it isn’t that bad. Note, I’m not including any tools for doing off-development related things, anything development related that is on the web or any cool plugins for any of these programs.

Here is what I need, in roughly the order I download them:

1. Firefox – I open IE, download Firefox with the purest intentions never to open IE again. Of course, my job gets in the way. I’ll save all the addons for this I install for a rainy day.
2. cygwin – first thing I do after making necessary LAF adjustments and installing Firefox. I don’t know how some people can survive without a robust command line… at the very least find, grep, sed, xargs. Also, if you don’t know what Ctrl+R does in Bash, check it out immediately.
3. Google Desktop – in lieu of not having Spotlight or anything similar, I set this to work early indexing
4. Eclipse – there is so much I use Eclipse for. Always one of my first downloads/installs even if it’s not needed immediately. Contains TCPMon, a Diff/Merge tool, great refactoring support, and about a million plugins to do many development tasks you’ll inevitably need to do (or want).
5. TCPMon – Whether you use Eclipse’s or some other, track this down and figure out how to use it. (HttpFox is great, but it can’t capture requests you make outside of the browser. Sorry, we’re not supposed to be talking about Firefox extensions, I know.)
6. Pidgin – best F/OS IM client out there for Windows (and other platforms). You can do some crazy stuff with Jabber, ladies and gents. But that’s another blog.
7. WinSCP – I don’t need to FTP or SCP files everyday, but when I do it’s usually easier to do it using WinSCP, and I can save my connection information incase I need to do something similar later.
8. PSPad – currently my favorite Windows-based “barebones++” text editor. In addition to the “coder-style” basics, a neat trick is that you can launch hyperlinks or filepaths by selecting and right-clicking.
9. vim – …Because none of these editors are perfect, though, I always keep ole’ vim on hand incase I get annoyed with PSPad. Honestly, I find myself in it just as frequently.
10. WinMerge – best F/OS Windows diff tool I know of – can compare directories which you can’t get the Eclipse merge tool to do.
11. SoapUI – general swiss army knife for anything related to web services. (Contains TCPMon, too.)
12. Squirrel – Ditch the Toad, go F/OS. Well, there is a free version of Toad but it can’t compete. As Jack White says, “Be like the squirrel.” Does whatever you want to a Database. Any database (well, almost). Written in Java, communicates using JDBC. Driver manager is a good way to get correct JDBC connection strings if you ever forget or can’t seem to get one right.
13. CommandBar – Found this mentioned in the Productive Programmer as a way to marry an Explorer and Cmd window. Comes in handy.
14. clcl – Another Productive Programmer recommendation for a simple multiple clipboard manager.
15. git – while I don’t always need this, I have been using it more lately because the version control software I have to comply with (eventually) on my current client sucks so mightily. I’m using git for day to day development and then I create a repo to interoperate with Harvest when I need to. (Be thankful you don’t have to use Harvest.)
16. DOMercury – Recent find that provides a Quicksilver-like launcher for Windows. It also includes an Alias manager. A priceless easter egg: ‘wtf’ launches IE. This sold me immediately. I’m not sure how well it keeps itself indexed, but I usually install it after everything else to keep it simple.

What am I leaving out? What kinds of things do you need to make your time in XP bearable?

More Related Content

• April 15, 2009 -- OSGi-ggity-Giggity (4)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• January 13, 2009 -- On Software Quality (8)
• December 1, 2008 -- 24ways (1)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• August 2, 2008 -- How I Escape the “Reuse Trap” (0)
• March 19, 2008 -- New Wave Logging (0)