Extreme Feedback Device (XFD): The ONOZ! Lamp

When two good ideas meet, there’s a chance for an even better idea to be born. This happened to us some time ago, when the ONOZ! Lamp came up.

(This is a free translation and revision of an earlier article written in german)

The first good idea

On April 1st 2004, Alberto Savioa published a blog entry about an idea of two lava lamps (green and red) displaying the current build state of a project. I was somewhat distracted that day, marrying my wife, so the idea came to us two years later. Mike Clark wrote his wonderful book “Pragmatic Project Automation” and included not only the idea of the lava lamps, but also detailed construction guidance.

The second good idea

One day, an email contained a little animated gif with two panic guys running around.

Investigation suggests Jonn Wood as the author. We thought the guys act exactly like us after a broken build (one of the worst things that may happen here), so the gif and the word “ONOZ” were integrated into our company culture.

The birth of another idea

After we read about the lava lamps, we wanted to own them, too. But only after inspiration from the animated gif, we were sure about our specific realisation. We merged the two states into one lamp (on/off instead of green/red) and did without the lava. A normal desk light would do the job now.
We even have a good justification for the omission of the green (lava) lamp:

• it saves energy
• no timer switch is needed for the nights/weekends
• our team includes colorblinds

The last reason is a good one when you look at this simulation of colorblindness:
These are pictures of the original green and red lava lamps:

This is how it looks to a colorblind employee. These images were generated by Vischeck, a website trying to inform about colorblindness practically.

Not much of a difference. If you swap them around secretly, ten percent (the percentage of colorblinds in the male population) of your team will panic without reason.

The ONOZ! Lamp

With little investment, we build a system supervising the build state of all our projects. Every build process sends its result to a server that checks for failures. If a build failed, the lamp gets switched on over traditional X10 signals. We can’t overlook the sudden burst of luminance, we panic a bit and try to fix the build. The lamp turns off when all projects are back to normal.

The ONOZ! Lamp is just a lamp standing around, until something ugly happens. Then it turns into a glowing infernal of failure. We nearly failed to give it a correctly spelled name, too. We named it “ONOEZ! Lamp” first, which seems to be the only invalid spelling of this exclamation.

The effects

The ONOZ! Lamp works great. Its mere presence has a comforting effect, as long as it is off. Which is the case most of the time. When it fires, the effect is like an alarm stopping all work. And the operator giving the alarm is always alert and incorruptible: our continuous integration server.

---

Read more about our Extreme Feedback Devices:

• The Code Flow-O-Meter: http://schneide.wordpress.com/2008/10/06/extreme-feedback-device-xfd-the-code-flow-o-meter/
• The LED Bar: http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio Feedback: http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/

Java solves all memory problems, or maybe not?

Many people think that Java’s Garbage Collector (GC) solves all of their memory management problems. It is true that the GC does a great job in many many real world situations. It really eases your life as software developer especially compared to programming in languages like C /C++ where memory management is a major PITA. Even there you can help yourself by using object systems with reference counting, smart pointers etc. but you have to be aware of this issue all the time.

So everything regarding memory is fine in Java?

Actually not really. Many Java developers do not think about code potentially leading to memory leaks. I would like to point out some problems we encountered. The problems can be divided into two categories:

1. Native resources which have to be managed manually
2. Listeners attached to central objects which are never removed again

Examples of native resources

Database connections, result sets and so on are a very common native resource that need manual management. JDBC is a real pain regarding resource management and especially Oracle is very susceptical to leaking those. Either you are very careful here or you use some framework to help you. If you do not want to go the whole way to a persistence framework like hibernate, iBatis or toplink a solution like Spring JDBCTemplate may help you a lot.

Another example is the JOGL TextRenderer which has to be manually disposed or you will leak texture memory  and soon run into resource problems.

Files/Streams and Sockets should be handled carefully too. In most cases you are more or less in the same boat with the C/C++ people but using finally can help you there.

Examples of listener leaks

Sometimes something innocent looking like a Swing Component can turn into a memory leak. We used JDateChooser one of our projects and found some of our data displaying dialogs to exist several times in memory and thus taking huge amounts of RAM eventually leading to OutOfMemoryExceptions. In case of dialogs and windows a WindowListener might help.

Sometimes you might write similar objects yourself that register to some central instance (maybe even a singleton *yuck*). Deregistering them always is easily forgotten or overlooked. A common code pattern to look out for listener leaks where you cannot deregister easily at the right moment is the following:

public class MyCoolClass implements IDataListener {

    public MyCoolClass(IDataProvider dataProvider) {
        super();
        dataProvider.addDataListener(this);
    }

    ...
}

Avoid such constructs as they can prove really dangerous. There is more that can be done to lower the risk of hard-hitting memory/listener leaks: Use WeakReferences for listener management at the crucial central objects. The referenced objects are taken care of by the GC and the listener manager has to take care of the WeakReferences. They can be cleaned up periodically or when a notification takes place.

Conclusion

The Java GC helps a lot in everyday programming but there are still things to look out for. Just be aware of the resources you are using and think about their need of management. I will write some follow up articles about getting heap dumps in different situations and searching them for memory leaks using some nice free tools.

Update:

Kris Kemper wrote a nice article about Swing Memory Leaks with JCalendar and a solution to the problem.

Deploying a Grails app on an Oracle DB

Running our new grails app on HSQL and a Postgresql everything went fine. But the production DB was decided to be an Oracle. And suddenly the app crashed several times. Here’s a list of what problems we encountered:

• ORA-00972: identifier is too long
• want to store a null value in a non null column

Oracle identifiers are limited to 30 characters. So we thought using a mapping for the table should do the trick. But grails uses the table names to construct the n:m relations and their id column names between the domain classes. Looking at the grails docs we found a joinTable mapping:

static mapping = {
    table 'PROP'
    tablePerHierarchy false
    instrumentInfos joinTable: [name:'PROP_INS', key:'id', column:'instrumentInfos_id']
}

This worked most of the time but in some cases grails just didn’t want to take our definitions. The problem was a bug in grails. The workaround we took was to shorten the domain classes names.
The second problem arose as we tried to store empty strings into the database. Oracle stores empty strings as null values which causes a constraint violation exception. The solution was to declare the string columns nullable or not nullable and not blank but you cannot use a not nullable and blank string with an Oracle DB.

Extreme Feedback Device (XFD): The Code Flow-O-Meter

This is a free translation and revision of an earlier article written in german.

Since March 2007, the Schneide uses another Extreme Feedback Device (XFD): the Code Flow-O-Meter.

So what is this thing?

We bought a portable fountain made of slate, filled in water (no additives) and connected the power supply cord with a X10 application module. Then we programmed a litte IRC Bot (using the ten-minutes-to-success java IRC library pircbot) that triggers the module. We were then able to control the fountain by speaking to it over IRC.

Afterwards, we piped the commit messages of our source repositories to a little script that determines the “impact” of the commit by measuring the amount of changes to the code. This sounds more sophisticated as it really is, the number of changed files was a good enough guess for it. This impact is related to a duration, the more impact, the longer the timespan. Now the script tells the IRC bot to activate the fountain for that amount of time.

This way, we have a direct but unobtrusive notification about what is going on in the repositories, as this is the most important location of our company (talking about the numerous safety nets we applied to it would require another blog post). Initially, we thought about playing an audio sample singing “alleluia”, too, but this became ridiculous soon.

But why do you want this notification?

One of the rules of agile (or good) programming says “commit early, commit often”. But as soon as every little commit gets examined by a continuous integration server, all automated tests and a large number of software quality metric tools, the liability to keep the changes local a little bit longer grows. “After all, it’s ready when it’s done, and this is soon enough to check in” was a common justification especially among the less experienced programmers. But that’s the best way to miss the early feedback. And early feedback is effective feedback.

So we installed our portable fountain as a counter-incentive against late commits and started a little game. The rule of the game is simple:
Keep the Flow-O-Meter running!
When you commit, the fountain flows. The size of your commit is not as important as the commit itself, so its better to commit often. If everyone does it, the fountain may flow the whole day.

The Code Flow-O-Meter may be regarded as a measurement device of “progress”. Things are in a state of flux as long as it is running.

And did it work?

Yes, definitly. The Code Flow-O-Meter has become our little pet. Everyone loves it because it’s friendly and comforting. Think of a tamagochi, but without the annoyances. You only need to change and commit something to feed it and get the reward, nothing more.

As an additional gain, everybody else loves it, too. When we show it to a customer, they first see an ordinary portable fountain. When we explain and demonstrate our working cycle (code, commit, review) to them, something magical happens. I tend to think they involuntary get the notion of something happening after the commit when the fountain comes to life. This may be the concept of a build server, otherwise being invisible and intangible, materializing in the fountain. When we continue to explain what happens after the build, like the ONOZ! lamp lighting up to indicate a failed build, it’s already clear to them that the process does not end with the waterflow. The Code Flow-O-Meter serves as a link between the developer’s local work and the build feedback arriving out of nowhere some minutes later.

---

Read more about our Extreme Feedback Devices:

• The ONOZ! Lamp: http://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/
• The LED Bar: http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio Feedback: http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/