cwash into software » CapTech

Transactions, Part 1

Chris Wash — Thu, 08 Jul 2010 14:46:54 +0000

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:

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.
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

Eliminate Branching (IF Statements) to Produce Better Code

Chris Wash — Thu, 07 Jan 2010 21:05:46 +0000

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

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 oddIntegerPredicate = new Predicate() {
    public boolean apply(Integer input) {
        return input % 2 != 0;
    }
};

Iterable 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!

What I’d Tell Myself About Design If I Were Just Beginning

Chris Wash — Thu, 30 Jul 2009 02:25:26 +0000

From all the time I’ve spent learning design, there are a handful of things I’d hope to remember or re-read if I were to ever get amnesia and have to start all over again. For new comers and experts alike, I’d like to share a few ideas about design worth thinking about through musings and links to other material that has helped form my opinions (some more relevant than others).

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

The Elements of Reusable Code

Chris Wash — Fri, 24 Jul 2009 19:35:49 +0000

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.

Mocking with JMockit

Chris Wash — Tue, 09 Jun 2009 05:09:58 +0000

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.

@RunWith(JMockit.class)
public class ControllerTest {

@Mocked
HttpServletRequest mockHttpServletRequest;
@Mocked
ServiceRemote mockServiceRemote;

@Test
public void test_execute_expectations() {

new Expectations() {
{ /* define in static block */
final Model m = new Model();
m.setId(12345l);

mockHttpServletRequest.getParameter("modelId"); returns("12345");
mockServiceRemote.getModel(12345l); returns(m);
mockHttpServletRequest.setAttribute("model", m);
}
};

/* simulate setter injection */
Controller c = new Controller();
c.setHttpServletRequest(mockHttpServletRequest);
c.setServiceRemote(mockServiceRemote);

/* call code under test */
c.execute();

/* strict mode will throw exceptions! */
}
}

You can get the whole project from my GitHub account.

What is Hamcrest?

Chris Wash — Wed, 03 Jun 2009 10:37:54 +0000

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:

assertTrue(blackbeard.getOccupations().contains("pirate") ||
blackbeard.getOccupations().contains("captain"),
"Expected Blackbeard to be a pirate or a captain");

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:

java.lang.AssertionError: Expected Blackbeard to be a pirate or a captain

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:

assertThat(blackbeard.getOccupations(),
anyOf(hasItem("pirate"),hasItem("captain")));

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:

java.lang.AssertionError:
Expected: (a collection containing "pirate" or a collection containing "captain")
got: < []>

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

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.matchers.JUnitMatchers.*;

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

assertThat(blackbeard.getOccupations(),
either(hasItem("pirate")).or(hasItem("captain")));

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:

PatternMatcher emailAddressMatcher = new PatternMatcher(sequence(
capture("user", oneOrMore(anyCharacter())),
"@",
capture("host", oneOrMore(anyCharacter()))
));
PatternMatcher mailToURLMatcher = new PatternMatcher(sequence(
capture("scheme", text("mailto")),
":",
capture("email", emailAddressMatcher)
));

assertThat("mailto:npryce@users.sf.net", matchesPattern(mailToURLMatcher));

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.

OSGi-ggity-Giggity

Chris Wash — Wed, 15 Apr 2009 21:40:01 +0000

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…

Java 6 and Maven 2.0.9 on Leopard

Chris Wash — Wed, 19 Nov 2008 07:21:42 +0000

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:

source ~/.profile

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:

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
export M2_HOME=/Java/apache-maven-2.0.9
export M2=$M2_HOME/bin
export PATH=$M2:$PATH

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:

cwash:~ chris$ which mvn
/Java/apache-maven-2.0.9/bin/mvn

You can also check this by doing:

cwash:~ chris$ mvn -v
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "mac os x" version: "10.5.5" arch: "x86_64" Family: "mac"

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!

cwash into software » CapTech

Transactions, Part 1

Preface

What is a transaction?

Etymology

Transactions defined

Examples of Transactional Systems

Specifying Transactions

ACID properties

Why Should I Bother Using Transactions?

Up Next: Writing Data Reliably

Further Reading

More Related Content

Eliminate Branching (IF Statements) to Produce Better Code

Branching Considered Harmful?

Hevery’s Suggestions

Remove Copy-Pasted Loops And Conditionals: Introduce Enumerable Operations

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

The Bigger Picture: Well Designed, Testable Code

More Related Content

What I’d Tell Myself About Design If I Were Just Beginning

More Related Content

The Elements of Reusable Code

Decomposing the Problem

Communication Concerns

Communication Saturation

Value cross training

Design Concerns

Cross cutting concerns

Refactor mercilessly to remove duplication

Names Matter

Technical Concerns

Know the language and learn standard APIs

Modularize your code

Documentation Matters?

Going Forward

More Related Content

Mocking with JMockit

More Related Content

What is Hamcrest?

Introduction

A Brief History

Fail message… win?

Other Cool Stuff

Getting Reused

Chaining

Matchers For Regular Expressions

Conclusion

Further Reading

More Related Content

OSGi-ggity-Giggity

More Related Content

Java 6 and Maven 2.0.9 on Leopard

More Related Content