The Weak Reference

Jfokus 2011

2011-01-16T14:42:00.002+01:00

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

2010-08-15T10:53:00.004+02:00

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

2010-05-28T10:59:00.004+02:00

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

2010-05-04T23:35:00.008+02:00

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

2010-01-30T15:52:00.003+01:00

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

2010-01-09T14:35:00.003+01:00

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

2010-01-09T14:30:00.003+01:00

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

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

2009-11-17T19:49:00.004+01:00

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

2009-11-03T21:51:00.006+01:00

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

2009-11-01T22:19:00.000+01:00

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

New Citerus Blogger

2009-10-27T22:00:00.003+01:00

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

2009-10-27T20:19:00.001+01:00

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

2009-10-19T21:55:00.002+02:00

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)

2009-10-08T22:17:00.006+02:00

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!

2009-10-06T17:42:00.014+02:00

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

2009-09-30T18:34:00.001+02:00

What the title says: @citerus_se.

Geeky Fact of the Day

2009-09-21T19:27:00.008+02:00

I read this tweet by Joshua Bloch:

"Geeky fact of the day: the sum of the first n cubes equals the square
of the sum of the first n integers"

And decide to throw some Clojure at it:

(use 'clojure.contrib.math)

(defn geeky-fact [n]
  (=
    (reduce + (map #(expt % 3) (take n (iterate inc 1))))
    (expt (reduce + (take n (iterate inc 1))) 2)))

Clojure Crash Course For Java Developers

2009-09-01T20:15:00.012+02:00

Updated, fixed bug in test-vec def

Looking at Clojure code coming from a Java background may be quite a daunting experience at first. So I have put together a short introduction that I hope can facilitate going from Java to Clojure.

Clojure is a functional programming language. As such we use functions to manipulate data, we avoid mutable state and side-effects. In a way it can be viewed as programming Java with only static methods and immutable objects. At first this may sound like a huge limitation, but in contrast to Java, functions in Clojure are are first-class citizens and Clojure fully support higher-order functions. That is, we can treat functions like any other piece of data, functions can be assigned to variables, functions can be passed as arguments to other functions and we can write functions that return functions. This can be very powerful and by keeping data immutable and strive for side-effect free behavior the idea is that we can write more robust programs that more easily can scale to multiple cores.

Clojure is a homoiconic language, that is, data and program instructions are represented the same way. This may look weird at first, and could need some time getting used to. Clojure programs typically starts out as text (in a text file) and is converted by a reader into data structures used by the compiler. The reader reads the text form by form. A form is a chunk of data that can be translated into a Clojure data structure. Numbers, like 123, are forms, so are lists, (+ 1 2) and vectors, [1 2 3].

Program and data are expressed as s-expressions, symbolic expressions, in a parenthesized prefix-notation. I.e. the function comes first and the data follows. The Clojure expression for adding the numbers 1, 2, and 3 is: (+ 1 2 3) This is a list and as such it will be evaluated as a function call. The function is + and the data to apply the function on comes after that.

Expressions can be, and typically are nested: (+ 1 2 3 (- 2 3)) => 5

REPL
The Read Evaluate Print Loop is an excellent tool to use when experimenting with Clojure. It is part of the Clojure distribution, so download and set it up before we proceed, and you will be able to try out things live as we look closer at the language:

1) Download Clojure (examples below are for Clojure 1.0.0).
2) Extract the zip and run java -cp clojure-1.0.0.jar clojure.lang.Repl

You should see something like:

Clojure 1.0.0-
user=>

Where user indicates the current namespace.

For a somewhat more comfortable REPL experience, add the JLine ConsoleRunner:

java -cp jline-0.9.94.jar:clojure-1.0.0.jar jline.ConsoleRunner clojure.lang.Repl

Forms
We have already met the numeric form, which is a literal, the vector, and the list but there are other forms as well:

Symbols:
Symbols are used to name things such as functions, namespaces (a Clojure equivalent of Java packages) and Java classes. We have already seen one: the + operator, which is a function.

Literals:
Strings, numbers, characters, nil (Java null), booleans (true, false) and keywords. Keywords are like symbols but begins with a colon e.g. :color.

Map:
Much like Java Maps, Clojure maps are zero or more key/value pairs enclosed in braces: {:language "Clojure", :kind "Functional"}
(commas are treated like witespace, leave them out if you like)

Set:
Much like Java Set, Clojure sets are zero or more forms enclosed in braces with a leading #: #{:red :green :orange}

These forms are translated in to data structures by the reader and compiler. More on Clojure data structures, their characteristics, related functions and relation to Java can be found on the Clojure Data Structures page.

Special Forms
In addition to the forms we have mentioned so far we have what are called "special forms", these are forms evaluated in a special way to do things normal forms can not do. There are a few particularily important ones:

(def symbol init?)
Binds a symbol to a global var in the current namespace, this is used to define things we need access to, e.g. a function or a value. Try it out using the REPL:

user=> (def a 42)
> #'user/a

user=> a
> 42

(if test then else?)
Evaluate test, if not nil or false, evaluate then.

user=> (if (> 3 2) "TRUE" "FALSE")
> "TRUE"

(let [bindings* ] exprs*)
Create local bindings used when evaluating exprs*

user=> (let [a 2] (> a 3))
> false

(fn name? [params* ] exprs*)
Defines a function. If we don't need to refer to the function, we can make it anonymous by not supplying a name:

Create a function that adds two values, and immediately call it on 1 and 2:

user=> ((fn [a b] (+ a b)) 1 2)
> 3

More special forms: http://clojure.org/special_forms

Macros
Clojure macros make it possible to add new functionality to the language, for instance by combining primitive forms. As a Clojure beginner you can safely ignore Clojure's macro functionality until you feel more confident in the language. But it can be good to know that many constructs in Clojure are macros, but they look just like ordinary functions. One of the most commonly used ones are probably (defn name doc-string? attr-map? [params*] body), used to create and name functions globally:

user=> (defn add [a b] (+ a b))
> #'user/add

user=> (add 2 3)
> 5

Using the function macroexpand we can see that defn is infact a combination of def and fn:

user=> (macroexpand '(defn add [a b] (+ a b)))
> (def add (clojure.core/fn ([a b] (+ a b))))

Immutable data.
The set of data structures in Clojure is extensive. We met a few of the structures when we talked about forms above. An important of property of Clojure data structures is that they are immutable. For example, operations on a list returns a new list with the result of the operation. The original list is untouched. We'll see examples of this below.

Functions
There is quite an extensive set of functions in the core Clojure libraries. Mathematical functions are named after their common symbols, as you would expect:

user=> (+ 1 2)
> 3

user=> (* 2 5)
> 10

user=> (> 1 4)
> false

There are also many functions to work on collections:

user=> (def test-vec [1 2 3 4 5 6 7 8 9 10])
#'user/test-vec

conj adds an element to the collection:

user=> (conj test-vec 11)
> [1 2 3 4 5 6 7 8 9 10 11]

map applies a given function to all elements of a collection, returning a new collection with the result:

(user=> (map #(* % 10) test-vec)
> (10 20 30 40 50 60 70 80 90 100)

The construct #(* % 10) is a reader macro for anonymous functions, the % is short for %1 and is bound to the first (and here, only) argument. We could also have written this using the fn form:

user=> (map (fn [a] (* a 10)) test-vec)
> (10 20 30 40 50 60 70 80 90 100)

filter will keep all elements for which the given function evaluates to true:
user=> (filter even? test-vec)
(2 4 6 8 10)

Again, all these functions return a new collection, our initial test-vec is untouched.

See the complete Clojure APIs for all core functions. In addition to Clojure core there is also the core clojure-contrib, a user maintained library that also acts as an incubator for Clojure core.

Java integration
Clojure runs on the JVM and is designed to make it easy to call Java code from Clojure, and Clojure code from Java. This is a big benefit as we can always drop down to Java if there is something we need that is missing from the Clojure libraries.

Calling Java is done using the . (dot) special form:

Accessing a static field:

user=> (. Math PI)
> 3.141592653589793

Calling a static method:

user=> (. Math min 3 4)
> 3

Creating a new instance is done using new:

user=> (def l (new java.util.ArrayList))
> #'user/l

Accessing an instance method, again using the . form:

user=> (. l size)
> 0

user=> (. l add "Cheese")
> true

user=> (. l get 0)
> "Cheese"

Note here that as we access the ArrayList instance it behaves as expected in Java. Clojure's immutability is not extended to Java objects, they keep their original behavior.

This is the basics of Java interoperability, but there is a lot of syntactic sugar available to make Java easier to work with from Clojure:

Direct static member access can be written with /:

user=> Math/PI
> 3.141592653589793

If it's a static method, make it a call:

user=> (Math/min 3 4)
> 3

Object creation can be done with Classname.:

user=> (def l (java.util.ArrayList.))
> #'user/l

If it feels annoying having to fully qualify ArrayList, we can import it (Math, as used above, is in java.lang and is imported by default):

user=> (import '(java.util ArrayList))
> java.util.ArrayList

user=> (def l (ArrayList.))
> #'user/l

The ' (quote) used above is another reader macro preventing the list to be evaluated as a function call.

Instance calls can be shoretened by placing the thing we want to call, the method, first, prefix Clojure style:

user=> (.add l "Cheese")
> true

Chaining Java calls in Clojure looks a bit messy by default:

user=> (. (. (. l get 0) (subSequence 1 3)) length)
> 2

Using the .. notation we can do this:

user=> (.. l (get 0) (subSequence 1 3) length)
> 2

The .. is, again, a Clojure macro, that expands to our first version above.

More on Java interoperability.

Tooling
REPL is all good for trying out things at the promt, but for writing larger Clojure programs you'd typicall want to use something else. Comming from a Java background all three major IDE:s have some kind of Clojure support at this point:

IntelliJ/IDEA: La Clojure plug-in
NetBeans: enclojure plug-in
Eclipse: clojure-dev

Hopefully this will get you started exploring Clojure. Have fun!

One Man's Entity Is Another Man's Value Object

2009-08-28T07:50:00.002+02:00

One activity that we tend to spend some time on when doing Domain-Driven Design is the characterization of our classes into Entities of Value Objects. Entities and Value Objects are two fundamental building blocks that we use to handle complexity and help us further deepen our understanding of the problem domain. Careful characterization can make our design simpler, yet more powerful.

Here are two things that I like to stress during this work:
1) It's not always obvious what type of building block a model item is.

Let the characterization process take time, do not be afraid to experiment. Try out a few different key scenarios, both by "modeling out loud" by expressing scenarios in the words of the Ubiquitous Language as conversations with other people on the team, and in code. Work hard to challenge your initial assumptions, refactor as needed. That said, if you have a choice, bias your design towards Value Objects. We favor Value Objects for their uninteresting life-cycle and immutability, we use them to push down complexity. Imagine if java.util.GregorianCalendar was immutable...

2) The characterization is context-dependent, i.e. one man's Entity is another man's Value Object.

Let's consider money, a popular choice when discussing Value Objects. Imagine I have a SEK 100 note and walk over to a person and ask her if she'd be willing to exchange my note for one of her SEK 100 notes. The person would most likely accept this proposal (after some initial suspiciousness, one can imagine). I get her note and she get's mine. From both our points of view, nothing really happened. I can still go down to the store and buy something priced at SEK 100. She can do the same. The value property of the note is what is important to us, not the particular note instance; as long as they have the same value, they are interchangeable. They are also immutable. When I get a note in my possession, it's value is already set. There is no way I can (legally) change the value written on the note. I pass it along as means of payment and I forget about it. As far as I am concerned it can be garbage collected when I no longer hold on to it.

However, if I walk over to a person and ask her if we can exchange VISA cards, odds are she won't agree. And we all know why. Our cards may be issued by the same bank, have the same shape and color, and both be VISA cards. But they also have a card number, they have an identity. The actual card instance does matter. Credit cards have a complex life-cycle tracked by this identity; they are issued, lost and cancelled, or stolen, or just expired. They are connected to an account, which may have a huge credit just waiting to be spent, or it may be overdrawn. We think twice before handing over the card to someone, because that someone can do things to our card that we don't want. Evil things. Things like (VisaCard) card.clone(), or card.charge(2 * amountAgreedUpon). In short, credit and debit cards are Entities and we need to handle them with care. Entities are high-maintenance. But can be oh so useful.

Now, if we scrutinize that SEK 100 note carefully, we will find a number, a serial numbers. So what is this? Notes do have an identity after all? Perhaps they are not Value Objects at all?! What is going on here? Well, I do not know this domain very well, but it is not that hard to imagine that there is someone somewhere that do care about tracking individual notes. Perhaps Sveriges Riksbank, Sweden's central bank, uses this information to track individual notes, as they enter them into circulation or destroy them when no longer in use. I bet there is a computer software system somewhere, in a different Bounded Context, where banknotes are Entities.

Read more about the Building Blocks of a Model-Driven Design in the DDD Pattern Summaries (.doc file).
Watch Dan Bergh Johnssons presentation The Power of Value from Øredev 2008.

Heldagsseminarium: Domain-Driven Design, 23 september 2009 i Stockholm

Jfokus 2010 Call for Paper Now Open

2009-08-19T22:43:00.004+02:00

The Jfokus conference is Sweden's premier conference on Java development, organized by the Swedish Java user group Javaforum. As a speaker at both Jfokus 2008 and 2009 I can tell you that Mattias and his team do an excellent work running the conference and it is a really great experience to both attend and speak at the event.

Submit you proposal now and hopefully we will see each other at Jfokus 2010, January 26 and 27 in Stockholm!

Follow The Weak Reference on Twitter

2009-08-10T14:45:00.002+02:00

Follow The Weak Reference on Twitter: http://www.twitter.com/weakreference

Laziness IS a Virtue of a Programmer

2009-08-10T14:14:00.007+02:00

As it turns out, laziness is a virtue of a programmer...

It is with particular joy I am rediscovering the programming paradigm that once introduced me to the art of software development: Functional programming. I begun my university studies almost 15 years ago. I initially planned to study biotechnology, but for different reasons I ended up with a M Sc degree in Information Technology Engineering instead. I had not really been doing any serious computer programming prior to my university studies, and the first course they threw at us was this monstrous thing called "Program Construction". It sure was a lot of work, but it built a great foundation for our further studies. And it was all tought in ML. 10+ years of Java followed. March this year I attended QCon London to give a tutorial on the DDDSample app, and also had the opportunity to listen to Rich Hickey give a presentation on Clojure. Since then I have slowly been rediscovering the beauty of functional programming; map, reduce/fold, higher-order functions, recursion, and more.

As an example, let's look at Clojure's lazy sequences:

This gives us a lazy sequence of all whole numbers:

(def numbers (iterate inc 1))

If executed it will define a lazy sequence, i.e. its elements will not be evaluated until needed. This is a good thing in this case since this sequence is infinite.

We can now use this infinite sequence, for example by calling:

(take 10 (drop 1000 numbers))

which will return the following (lazy) sequence:

(1001 1002 1003 1004 1005 1006 1007 1008 1009 1010)

Or why not take all the even numbers by filtering the sequence:

(take 10 (filter even? numbers))

returns:

(2 4 6 8 10 12 14 16 18 20)

I think this is pretty sweet!

For an upcoming PNEHM! article I needed to generate data sets of arbitrary sizes consisting of random letters a-z, so I did this:

(def s "abcdefghijklmnopqrstuvwxyz")

(def data-set
  (repeatedly
    #(nth s (rand-int (dec (count s))))))

From which I can take whatever number of random characters I like and do something with, for instance write 100 chars to file as a string:

(use 'clojure.contrib.duck-streams)
(spit  "data-set.txt"  (apply str (take 100 data-set)))

Note that the sequence is cached, so I will get the same characters each time (take 100 ...) is called. This may not be what you want. Converting the def to a no-args function, we can call it repeatedly and get different lazy sequences:

(defn data-set []
  (repeatedly
    #(nth s (rand-int (dec (count s))))))

And do:

(take 100 (data-set))

One final example, a function to calculate the Fibonacci sequence, from http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Lazy_Fibonacci:

(defn fib-seq []
  ((fn rfib [a b] 
       (cons a (lazy-seq (rfib b (+ a b)))))
    0 1))

(take 10 (fib-seq))

Gives:

(0 1 1 2 3 5 8 13 21 34)

DDDSample Interview Published

2009-06-30T08:49:00.003+02:00

At Jfokus 2009, Sweden's largest annual Java conference, Peter Backlund and I gave a three-hour tutorial on DDDSample. DDDSample is a sample application for exploring the building blocks of Domain-Driven Design built in cooperation with Citerus and Eric Evans.

We were also interviewed by Dan Berg Johnson on the topic; that interview is now published.

For more info on Jfokus, including a number of recorded presentations, visit http://www.jfokus.se/.

And don't forget to check out the DDDSample!

Giving Up on Safari 4

2009-06-22T18:12:00.003+02:00

It lasted 8 days this time around. After using Safari 4 as my main browser for about a week I decided to let it go. Despite applying the tweaks from this post there are still a few things that just isn't working out for me:

1) The setting to force opening of new windows in tabs is a little too "always" for my taste. I want (allowed) pop-ups to pop-up, but links that request a new window to be opened in new tabs. I believe this is the Firefox default and it works great.

2) Blocking pop-up windows is nice, but I'd like the browser to tell me when this happens, so I can elect to view this particular pop-up if I wish,

3) Once you get used to the Awesomebar, all other URL bars are, well, not so awesome.

So, for now I am running Firefox 3.5 rc2! If you have any ideas on how to fix the things above, please let me know and perhaps I'll try out Safari 5.

Them Netbooks

2009-06-17T08:55:00.006+02:00

After almost ten years of daily commuting between Uppsala and Stockholm I finally decided that enough was enough, and moved closer to where I work. For my current engagement this cut traveling down from about 80 to 30 minutest. One way. Per day. Much better from a getting-up-early-and-getting-home-late perspective.

However, spending all this time on trains had the side-effect of making time available for writing blog entries and PNEHM! articles (and the occasional nap). So with effective train-time cut down from 40 to 18 minutes there simply hasn't been that many blog entries written, except for the occasional #spam.

Time is one thing, but the smaller, more crowded city commuter trains, also makes it harder to open a full-size notebook to do writing and reading. So after much angst I decide to get me one of them netbooks. I bought an Asus Eee PC 901 with built in 3G modem, it came originally with Windows XP, but now runs eeebuntu 2.0. And it is actually rather nice. Sure, its been hit with the ugly stick, but the total lack of aesthetics is actually somewhat refreshing, the build quality is decent, and you almost get used to the tiny keyboard after a while. It could be a bit more snappy though, so I am looking forward to trying out eeebutu 3.0 with LXDE, hoping that it will speed things up a bit.

The 3G mobile connectivity, Google Docs, Spotify and the excellent Dropbox file sharing service gives you pretty much everything you need to write blog entries, catch up on your RSS feeds, browse the web, listen to your favourite music, process e-mails, read e-books, etc. You do your writing on the train, and as you approach the train station you just save and close the lid. As soon as you're back at the office, or home, or wherever, you can easily pick up where you left off, on the same computer or a different one.

Man, this cloud thing is really great!.