Medium

 I do occasionally drop stuff at https://weakreference.medium.com. See you there!

Reflection in Clojure

I recently got a question about dynamically loading and instantiating Java classes in Clojure. The goal was to check if a certain library was available on the classpath. If it was available it should be loaded and used, if not, a simpler default version would be used instead.

Given Clojure's dynamic nature, it would be reasonable to believe that this is a simple thing. Perhaps it is but, I didn't find an obvious solution to this problem in pure Clojure. Luckily, since Clojure runs on the JVM and interops nicely with Java, there is a pretty straight-forward way of solving this; finding and instantiating the classes needed aren't too hard to accomplish using Java and some good old reflection.

In the code example below the class we are looking for has a useful default constructor. If that's not the case, instantiating the class requires a little bit more work. But once you have a reference to that instance, using it from Clojure is just like using any other Java class from Clojure!

In the example below we prefer to call on Joda Time to provide us with the current date and time, but if the library is not in our classpath, we fall back to using java.util.Date.

(defn exists? [c]
  (let [loader (.getContextClassLoader (Thread/currentThread))]
    (try
      (Class/forName c false loader)
      true
      (catch ClassNotFoundException cnfe false))))

(defn print-java-date-now []
  (println (java.util.Date.)))

(defn print-joda-date-now []
  (let [clazz (Class/forName "org.joda.time.DateTime")]
    (println (.newInstance clazz))))

(if (exists? "org.joda.time.DateTime")
  (print-joda-date-now)
  (print-java-date-now))

Update 2012-10-22:

My colleague Mattias came up with this much nicer version of the exists? function using clojure.reflect/resolve-class:

(defn exists? [c] 
  (resolve-class (.getContextClassLoader (Thread/currentThread)) c))

Spring Break!

Last week the Citerus team spent a few fantastic days in Morocco. We try to take these trips somewhat regularly and over the years we have been to Italy, Czech Republic, and France among other places, but this trip was the first time we left Europe.

Citerus has been bringing quite a few new people on board over the last months, so this was a great opportunity to hang out with all our people for an extended time. Some for the first time as members of the Citerus team.

I must say I am amazed with the talents that have joined us for quite some time now. In fact, it blows me away. Spending time with my colleagues makes me feel old, slow and a bit stupid, and when building a great business, this is not a bad thing. I am very proud of being a part of this awesome group of people, you constantly learn new things, you are constantly challenged, and you always have fun.

Even though we bring our entire team together one day per month to share ideas and spend time together, doing this in new environments for an extended period really opens up a lot of great opportunities. The amazing views of the Atlas mountains as well as pool side work in Marrakech turned out to be perfect for creativity and focus. Look out for the new products we will be launching and exciting articles we will be publishing during the spring as a direct result of these last few days.

Feel like joining us? We’re hiring!

How Sad

How sad, no posts in over a year. Should we do something about that perhaps?

Jfokus 2011

Jfokus 2011 is getting closer and this year looks fantastic! New venue, an additional day, and, as always, many interesting speakers. Tuesday February 15 has a DDD track with lots of great speakers, including Eric Evans.

Citerus is of course represented as a Jfokus partner also this year. We will be in the exhibition both conference days, come and see us!

DDD classes survey

Eric Evans is doing a survey to guide future developments of the DDD classes that Citerus and other partners around the world offer together with Domain Language. If you are interested in DDD training, please take a moment to complete the survey. Thanks!

http://domainlanguage.com/survey/2010-08/

Meltingspot #4

Meltingspot #4 is now available. This time we start off with Daft Punk and end with Coldplay, while visiting both The Knife and Kraftwerk on our way.

Meltingspot #4 - This was meant to be, enjoy!

Follow us on Twitter @meltingspot, and stay tuned for our upcoming lists with music for the summer!

Your Build, Lava Lamps and Clojure

Long time without a post, here's one that's long overdue!

After a Javaform JUG meet-up this fall I happened to talk with @matkar (of Javaforum and Jfokus fame) at the pub following the meeting. He very convincingly described how great it is to use lava lamps as a visual tool for showing current build status. Actually, he pretty much insisted that I'd set it up immediately in my current project.

Well, it did sound like fun, so I got started. This blog post will layout what you need and how to create your own lava lamp powered visual workspace!

The build
First, you need a continuous integration (CI) server, also known as a build server. Your project needs one of these anyway, so if you don't have one in place, this is definitely the first thing to take care of!

In my current project we use Jetbrains TeamCity, but there are a number of free open-source products available as well.

You also need a way to extract the relevant build status data from the CI server. Depending on product there are typically a number of different ways of doing this. I used the RSS feed facility of TeamCity and polled the project's Atom feed for build status with certain intervals. For more immediate notifications one could probably fairly easy use TeamCity's Jabber support instead. But this was the easiest thing to setup and use, so I went with that, configuring a RSS feed with status information for the relevant code branch.

The Hardware
Secondly, you will need some hardware. By tradition, lava lamps is the number one choice for signaling here, but one can easily think of other options as well. If you decide to go down the lava lamp light road, try to get something that has a short start-up time. The ones I used take about 1.5 h to warm up (i.e. until they start "bubbling"), which is kind of long. If you have a disciplined team, the broken build will be fixed long before that. I got my lights from the gadget shop Teknikmagasinet here in Sweden, perhaps more expensive gear from a vendor like Mathmos would work better, but I don't know.

Then, you need some way of controlling the lamps. I did this by using an USB controllable power strip. In particular I used the SIS-PM Silver Shield Programmable Power Outlet Strip which comes with a simple but surprisingly nice GUI for use with Windows computers to control which sockets are on and which are off. It also comes with a Windows command line utility, which was the integration point I decided to use. I do my development on a Mac but the lava lamp solution was deployed on a Windows machine, so this worked out nicely.

For non-Windows deployment there are Linux drivers available for download from the page above, though I have not tried them out. There is also a SourceForge project with software for the power strip.

The Software
The final piece of the puzzle is the software that regularly polls the CI server's RSS feed and controls the power sockets according to current build status – successful or failed, in order to turn on and turn off the lights.

The code is written in Clojure. It uses functionality from clojure.contrib to parse the RSS XML and call the command line utility to control the power strip. The lightweight scheduling component cron4j is also used, which integrates very nicely with Clojure.

The code and Leiningen project definition file can be found a this GitHub Gist. I use the Leiningen command uberjar to create a runnable JAR, making deployment extremely simple. The code assumes that the two sockets used are named green and red, the strip itself must be named lava. These names can be assigned using the GUI tool shipped with the power strip.

As far as examples of functional programming goes this code is a particularly bad example. Functional programming is much about side-effect free pure functions and this use case is pretty much all about side-effects. But I think it shows rather nicely that Clojure can be used for all sorts of things, including problems like this, perhaps more suitable for script-type languages. Also, an obvious simplification that could be made is to avoid storing internal build state, and instead always update the lights according to the latest polled build-result, even in the case when nothing has changed.

The program is configured through a settings file. This is a standard Java properties file specifying the path to the command tool and two cron expressions. The first cron expression describes when and how often to poll the build server, and the second specifies a time to shut it all down for the day so the lamps get the chance to recover a bit during night when the office is empty.

Bill Of Materials

• CI server, JetBrains TeamCity
  
• One red and one green lava lamp (available in Sweden from Teknikmagasinet)
  SIS-PM Silver Shield Programmable Power Outlet Strip (available in Sweden from Kjell & Co)
  

Meltingspot

Meltingspot is a side project I run together with Tobias Hill. We're both big music lovers and we thought it could be an interesting idea to share some of our current listening with other people. With the advent of Spotify these kind of collaborations has now become quite a lot easier.

We will try to publish a new playlist regularly, perhaps once per month or so. Hopefully you will find something you like and we will get some great new listening tips in return.

The playlists are published at http://www.meltingspot.se, you can also follow us on Twitter @meltingspot.

Meltingspot #2 - Box in shape of things to come, is now live. Enjoy!

Speaking at Jfokus 2010

I will be giving a short introduction to Clojure for Java developers at Jfokus 2010 conference day, January 27.

The presentation will be in Swedish, more info on the Jfokus program page (in Swedish).

Jfokus 2010 is now fully booked, but there is a waiting list if more seats become available.

Hope to see you there!

DDD classes winter/spring 2010

These are the winter and spring dates for our Domain-Driven Design classes, offered in partnership with Domain Language, Inc.

• Februrary 18, One-day DDD overview.
  
• March 9, Four-day Hands-on Immersion.
  

The introduction class is a great way to get a good overview of Domain-Driven Design. Morning is spent on tactical design and how to interact with Domain Experts, and the afternoon is all about strategic design, context mapping and distillation.

In the four-day immersion class we really learn how to put the domain model to work. It is highly interactive with programming labs, design discussions, modelling sessions, and much more!

All classes are offered in Swedish in Stockholm. The classes are official DDD classes designed by Eric Evans, Domain Language Inc.

New Citerus blogger

Say hi to Mikael Boman's new blog The wheel of destiny!

First entry is about The top six technical practices every Product Owner must know about. Enjoy!

From Java to Clojure, followup followup

Martin Lübcke came up with this solution to the frequency sorting problem presented in the PNEHM article From Java to Clojure:

(defn order-by-freq [coll] 
  (keys (sort-by #(vector (- (frest %)) (first %)) (frequencies coll))))

Replace frest with fnext for Clojure 1.0.

When it comes to performance, this version is about as fast as the original version in the article, but it sure is compact, and surprisingly readable. Many thanks to Martin!

Music for the Fall

Autumn 2009 spotify:user:patrikfr:playlist:2Oa9PllvhY5KcLLLJDNMku

New Citerus Blogger

Follow Mattias Holmqvist's new blog "Learning more about software development".

The first two posts focus on, yes, you guessed it, Clojure, as Mattias works through some examples from Structure and Interpretation of Computer Programs.

From Java to Clojure Followup

Interest in the From Java to Clojure article has been pretty big, rarely before have we seen a PNEHM!-article getting so much attention!

I have also gotten some great feedback, in particular Stuart Halloway suggests that we use Clojure-contrib's seq-utils/frequencies to improve the code. Since we use Apache Commons Collections in the Java version of the code, its only fair for us to dive into the goodness of Clojure-contrib to see what can be of use there.

Let us start by a quick review of what our final version of the Clojure code looked like:

(ns step4.pnehm.clojure-orderer)

(defn count-words [coll]
   (reduce #(merge-with + %1 {%2 1}) {} coll))

(defn cmpr [[val1 freq1] [val2 freq2]]
   (let [freq (compare freq2 freq1)]
     (if-not (zero? freq) freq (compare val1 val2))))

(defn order-by-freq [coll]
   (keys (sort cmpr (count-words coll))))

As it turns out, clojure.contrib.seq-utils/frequencies does exactly what our function count-words does, as such we can use it as a drop-in replacement. A version which uses contrib now looks like this:

(ns withcontrib.pnehm.clojure-orderer
   (:use clojure.contrib.seq-utils))

(defn cmpr [[val1 freq1] [val2 freq2]]
   (let [freq (compare freq2 freq1)]
   (if-not (zero? freq) freq (compare val1 val2))))

(defn order-by-freq [coll]
  (keys (sort cmpr (frequencies coll))))

We have to make sure we :use clojure.contrib.seq-utils, and then we can replace our call to count-words, with a call to frequencies.

Now, for extra credits, let's look inside the frequencies function in Clojure-contrib, to see what i looks like:

(defn frequencies
  "Returns a map from distinct items in coll to the number of times
  they appear."
  [coll]
  (reduce (fn [counts x]
              (assoc counts x (inc (get counts x 0))))
          {} coll))

The implementation is quite different from our own, it feels a bit more straight-forward and intuitive. Initially, an empty map is created. As the collection is reduced a copy of the map is created for each processed item and the item is added with an incremented count (if the item already is in the map) or added to the new map with a count of one (if it is the first time the item is processed). get, gets a value from the map given a key, if there is no match the default, '0', is returned. inc increments the value, and assoc associates the value to a key in the map.

Not only is this version simpler than our own (which is good), it's also much faster (also good). Using seq-utils/frequencies a sample run with our micro-benchmark now looks like this (sorting 100 characters with 10000 samples):

Java: 120 ms
Groovy: 538 ms
Time Clojure: 563 ms

Excellent!

So, Joshua Bloch's item 47 in Effective Java (2 ed) applies as always: Know and use the libraries. If you get the feeling that someone must have done what you are about to do before you, someone most probably have.

Many thanks to Stuart Halloway (who will be at Øredev next week, don't miss it!).

The sources at http://code.google.com/p/pnehm-java-to-cool-language-x/ have been updated with the alternative version.

From Java to Clojure

In this article, published in Citerus’ newsletter PNEHM!, I introduce Clojure to Java developers by converting a piece of Java code to Clojure. The article examines how to call Java code from Clojure and Clojure code from Java, complete with source code.

Citerus’ consultant Peter Backlund took the same journey some months ago with his article Från Java till Groovy (in Swedish).

Read From Java to Clojure.

DDDSample Presentation (free event)

On Thursday evening, October 22, Sweden Spring User Group is hosting an even in Stockholm where Peter Backlund (mostly) and I (less) will present the current state of the DDDSample application.

Agenda

DDDSample är en Spring-applikation som utvecklats för att påvisa hur idéer och koncept från Domain-Driven Design kan implementeras i en modern utvecklingsstack. Applikationen utvecklas i samarbete med Eric Evans, författare till boken Domain-Driven Design, och syftar till att visa hur mönster från DDD konkret kan användas för att skapa en systemarkitektur för att lösa problem i en komplex domän, utan att skapa onödig teknisk komplexitet.

Sedan applikationen först introducerades för drygt ett år sedan har den kontinuerligt utvecklats, mycket tack vara den feedback som kommit från olika communities. Det är snart dags för en ny release och under denna träff kommer vi kika närmare på applikationens olika delar och se hur dessa mappar mot koncept inom Domain-Driven Design.

Vi kommer att visa hur Spring (och i viss mån andra ramverk) hjälper oss att programmera domändrivet genom att dels låta oss bygga en ren och rik modell i Java, och dels genom att ta hand om infrastrukturell kod och låta oss fokusera på affärsnytta (focus on the core domain).

The presentation will be in Swedish and the event is free to attend.

Sign up at http://www.eventbrite.com/event/445416252

Welcome!

Mocking to the Rescue!

I am not really a big fan of mocking. My experience is that if you design your code to be testable, you only rarely have to rely on mocks, instead you'll be fine just by stubbing an interface or two. But even as a proponent of what Martin Fowler calls classic TDD, I find it there are times when a mocking tool can come in handy. One situation is when you have to work with API:s that lack good interfaces, in these cases a good mocking tool with support for mocking concrete classes can be of great help.

Mockito is what I would like to consider a next-generation mocking tool, with support for both mocking and stubbing. Mockito fully and naturally uses recent language enhancements in Java, such as generics, static imports and annotations, to make the tool easy to use. Writing clean and elegant test code that is easy to understand can actually be pretty simple. TheMockito API is straightforward and well designed, the need for infrastructure code is kept to a minimum. If you are an EasyMock user, this comparison may be helpful when following along in the code below: http://code.google.com/p/mockito/wiki/MockitoVSEasyMock

Let's look at a few examples!

Stub an interface

A nice property of systems built using dependency injection is that you get loosely coupled systems with well-defined interfaces that are easy to stub for testing. It is easy enough to provide stub implementations of these interface directly in the test classes, e.g. as anonymous implementations or inner classes. But despite this, I have found myself more and more starting to rely on Mockito for these situations, it's fewer lines of code, and very convenient!

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.verify;
import static org.junit.Assert.assertEquals;

[...]

ClientRepository repository = mock(ClientRepository.class);
ClientId clientId = new ClientId(123);
Client client = new Client(clientId, new Name("Test", "User"));
when(repository.findById(clientId)).thenReturn(client);

Now, as an example, we can use our ClientRepository instance to test a service class:

FancyService service = new FancyServiceImpl();
service.setRepository(repository);
assertEquals(client, service.findClientAndDoSomethingTrulyAwesome(123));

When stubbing like this we are usually not that interested in verifying behaviour of the stub. But if we, for some reason, would like to explicitly make sure that the method findById(...) was called, we can do this with the following line of code:

verify(repository).findById(clientId);

Stubbing concrete classes

Now and then you encounter API:s that were not as designed for testing that you could wish for. In these cases, the possibilities of stubbing concrete classes can be very helpful.

Restlet

Restlet is a Java framework for creating RESTful web service. Reslet consists of quite a big API, and the authors have, among other things, decide to create their own implementation of things like Request, Response, Status.SUCCESS_OK (HTTP response 200) etc. Unfortunately, many parts of the API consists of concrete classes, instead of interfaces. One downside of this is that it is sometimes hard to write tests for code that uses the Restlet APIs.

Stubbing the concrete class org.restlet.data.Response is easily done in the same way we stubbed the ClientRepository interface above:

import static org.mockito.Mockito.*;
import org.restlet.data.Response;
import org.restlet.data.Status;
import org.restlet.resource.Representation;

[...]

Response response = mock(Response.class);
Representation entity = mock(Representation.class);
when(response.getStatus()).thenReturn(Status.SUCCESS_OK);
when(response.getEntity()).thenReturn(entity);

Quartz

Quartz is a scheduling component that is supported and also used by many popular application development frameworks and application servers, including Spring and Seam. When using Quartz you define jobs that execute according to a schedule. Every time a job is triggered a new instance of the job class is created, and executed. If state is to be saved between job executions it has to be stored in some kind data structure outside of the job. Quartz makes a context available, org.quartz.JobExecutionContext, for this and other purposes. The context is handed to every newly created job instance. The context can, a bit simplified, be viewed as Map where the job can store and retrieve data.

If we would like to make data available to a job or read the result from a job execution we have to create an instance of JobExecutionContext and hand to our job. Creating this instance is however quite complicated, and since Quartz also tends to favor concrete classes over interfaces, it makes it hard for us to provide our own implementation. Fortunately, Mockito (or another mocking tool that can mock concrete classes) can help us out here as well!

Use Mockito to setup the context and set a fictional indexCount parameter as input value to the job:

import static org.mockito.Mockito.*;
import org.quartz.JobDataMap;
import org.quartz.JobDetail;
import org.quartz.JobExecutionContext;

[...]

JobExecutionContext ctx = mock(JobExecutionContext.class);
JobDetail detail = mock(JobDetail.class);
JobDataMap map = new JobDataMap();
map.put("indexCount", 145);
when(detail.getJobDataMap()).thenReturn(map);
when(ctx.getJobDetail()).thenReturn(detail);

Now we can use the context in our test:

IndexUpdaterJob job = new IndexUpdater();
job.execute(ctx);

And verify that the index was updated:

map = ctx.getJobDetail().getJobDataMap();
assertEquals(146, map.get("indexCount"));

Mocking

As the name suggests, Mockito can of course be used for different kinds of mocking as well. For more examples, have a look at the Mockito documentation.

Follow Citerus on Twitter

What the title says: @citerus_se.