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/
Sunday, August 15, 2010
Friday, May 28, 2010
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!
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!
Tuesday, May 04, 2010
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
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)
Saturday, January 30, 2010
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!
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!
Saturday, January 09, 2010
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!
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.
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.
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.
Subscribe to:
Posts (Atom)