Monthly Archives: February 2011

Ice is one of the most important ingredients in a cocktail. Even when it's not in the glass it's used during mixing. This makes the quality of ice very important.

First of all the water used has to be of good quality. If you don't have good quality tap water I would strongly recommend that you filter the it. This greatly improves it. This is important since badly tasting water will affect the taste of the drink.

Secondly the temperature of the ice is important. I always take my ice directly from the freezer when putting it into the shaker or the glass. I never use ice that has been out on the bar for a while since it gets wet. Wet ice dilutes the drink to much.

Third is the size. If I don't use crushed ice, which I don't very often, I used large chunks. I freeze ice in freezing boxes of various sizes. Most are five by ten by two centimetres. But some are about ten by ten by ten centimetres. I then use a cast iron pester to crack the ice into suitable chunks. A small block is usually made into two pieces. One piece like this is enough when shaking a cocktail.

The reason the size is so important is that it makes it possible to control dilution more precisely. Since the ice is so large it will cool the drink faster whilst melting slower. This makes it possible to mix the cocktail until it's perfectly diluted without worrying about its temperature. The same is true when serving on the rocks. The larger the chunks of ice the slower they melt and the better they keep the cold.

But when serving on ice it also provides for a nice visual effect. Imagine your sour or old-fashioned poured into a glass with one single block of ice that is so large it just fits in the glass. Or being served a long drink on hand cracked pieces of ice, not one looking like the other. It always impresses my guests šŸ™‚

Last night we had our neighbour over for a couple of cocktails. The spirit for the evening was Tequila. A bottle of Jose Cuervo Especial Reposado to be more specific.

My favourite for the evening was Amante Picante. It's a wonderfully refreshing drink made with cucumber, coriander, hot sauce and agave syrup. Most recipes uses green Tabasco but I much prefer using Cholula Original hot sauce, if you can get your hands on it. The recipe is:

2 slices of cucumber
2 sprigs of coriander or cilantro
1Ā½ shots of Jose Cuervo Especial Reposado Tequila
1 shot of freshly squeezed lime juice
Ā½ shot of agave nectar
2 dashes of Cholula Original hot sauce

Peel and chop the the cucumber. Muddle it with the coriander in the base of the shaker. Add all other ingredients and shake with a block of ice. Serve in a martini style glass decorated with a wheel of cucumber.

Both my wife and my neighbour became very found of a cocktail called Freddy Fudpucker. This is a lovely blend of tequila, orange and vanilla in the form of Galliano. It is served in a collins glass. To add to both the flavour and colour I added two raspberries. The recipe is:

2 shots of Jose Cuervo Especial Reposado Tequila
Ā½ shot of Galliano Lā€™Autentico liqueur
3Ā½ shots of freshly squeezed orange juice
2 fresh raspberries

Shake all ingredients with a block of ice and fine strain into a ice filled collins glass. Decorate with a slice of orange and a fresh raspberry or two. Serve with straw.


When writing my article AMQP Hello World as an Exploratory test I realised that the test is written in a different way then many tests I read. I felt that I should explain why I choose a different design when writing tests since I think this would benefit many projects.

The code below is taken from the example provided in the AMQP article and can be found at my github repository.

My main driver when writing tests is readability. A test should read pretty much like a well written requirement specification. It will detail the requirements for set up before testing can start. It will then details the given state of the application, moving on to the state when something happens and then verify that expectations were met. Before finishing the application needs to exit gracefully.

When I work with tests in Java I tend to use JUnit 4. JUnit 4 does not need naming conventions, such as setUp, testXyz and tearDown. This is all driven with annotations, which frees up the name space and allows the developer to instead name the methods according to what they do.

Below is the set up method for my test:

The method name clearly states what the method does. The annotation clearly states which role the method plays in the test life cycle. This makes the test code easier to read and debug.

When working with the actual test methods I use names that clearly identifies what the test verifies. Below is a test methods from the example. The method name points out what the method tests. The content is then written in a given-when-then pattern to detail the steps that are required.

This way of working has a couple of side effects that are quite useful. When adding more tests, either as new test methods or as new test classes, it is easy to spot similarities which can be shared in between tests. This in turn helps to enable the creation of a domain language for the tests of the application. It is important though not to forget that tests should first and foremost be readable. Creating to much abstraction makes it harder to follow the test code.

The given-when-then methods clearly defines the steps taken to perform the tests but does not slow the reader down with large amounts of implementation details. This makes the tests a good source of documentation. It further more makes it very easy to see if a test failed due the state being changed before or during the operation that is under test.

The tear down method is, just as the set up method named according to what it does rather then its function in the test life cycle. Its function in the test cycle is defined by its annotation.

I find that this style of test design makes the tests much easier to read, maintain and understand. They also work much better as documentation when trying to understand generalised well written code.

We have taken the decision to use Rabbit MQ as our internal message queue. To understand the way that Rabbit MQ talks with Java applications I decided to create a little Hello World application. Using Rabbit MQ's Java API guide I created the exploratory test below.

The complete code, in a Maven project, can be found on my github repository here.

The test starts with setting up the connection to the Rabbit MQ broker which is running on localhost. Since the client comes with sensible defaults the connection does not need to be configured with anything but the name, type and durability of the exchange. A queue is then bound to the channel to enable us to send messages.

The actual test only details the steps needed to verify that the message sent matches the messages received. The implementation will be discussed in each of the supporting methods:

To send a message to the MQ we simple publish it to the given exchange using the channel:

We then pick up the message using a consumer. When implementing this in production code the producer and the consumer should not be running in the same thread since both are blocking. But since we are only testing the availability of the MQ the blocking is actually working or out advantage.

The last step of the test is to assert that we received the same message as we sent:

When the test is done we need to close the channel and the connection:

The benefits of using this approach to understand new technology is that the tests can be put to use to verify the integrity of the libraries and the MQ used when running automated integration tests rather then just writing throw away code.

If you find the structure of the test code different you can find an explanation in this article which discusses the drivers behind the design as well as the given-when-then pattern used in the test method.

The faƧade pattern is one of my most used patterns. It works as the glue both within an application and as a boundary to dependencies.

It mainly comes in handy when solving the following problems:

  • Testability
  • Fluid design and readable APIs
  • Protection against external forces and changes

Ever so often test driving development becomes extremely expensive because the interfaces the code depends on is impossible to test against. This may just as well be internal legacy libraries as external libraries. To remedy the problem I use a faƧade interface that provides the operations I need. I then mock the expected behaviour of the operations when writing code required. With some careful planing the binding of the library implementation to my faƧade can then be done without to much hassle.

Fluid design and readable APIs
Each component within an application strives to resolve it's own domain. This often results in the boundaries becoming a bit awkward. To help creating fluidity in design and APIs it is therefore often useful to create faƧades matching each domains language and a thin layer of bindings that glues the libraries together.

Protection against external forces and changes
When using external libraries, apart from the above issues with testability and fluidity, faƧades also help reduce the cost of upgrading the dependencies. Whenever an external library changes the only code in the application that will need to change is the binding to the faƧade.

The overhead for getting the above benefits is actually remarkably low. It is usually enough to create an interface that delegates it's operations to the library it is a faƧade for. The binding can the be done using dependency injection or factories.

Even when it's more difficult it's usually only a matter of composition. I have some times had to compose the the logic of the integration on a couple of abstraction levels but then it has still been well worth it since it has simplified the usage of the API considerably.

It is a shame that I don't get to see this pattern used more often. It would have reduced cost and complexity on many occasions.