New distinct operator in Esper 3.1.0

REJOICE: Esper 3.1.0 got released yesterday and I am currently moving our code to use it.
A couple of leaks got fixed and some behavior have changed. But that's not what made do this post.
After reading through the changelog I discovered this little gem:
 - A new "every-distinct" operator has been introduced to the pattern language. Very similar to the "every" operator, this operator suppresses duplicate results received from sub-expressions based on a set of expressions returning distinct-values.

Before the this new keyword got introduced I had to create a separate data window and use the following query to fill it with unique events:
insert into collectwin select * from reader as tagevent where not exists (select * from collectwin as collected where collected.key=tagevent.key)
Thanks to the new keyword I can now define a pattern for that job:
pattern[every-distinct(res.value) res = ParsedEvents]
As I am doing ALE I need the parsed events to be unique within a certain time frame. To reset the set of unique events do the following:
pattern[every-distinct(res.value) (res = ParsedEvents where timer:within(5 sec))]

This makes the whole thing a lot easier and better looking :)

Recent Activities

The last few months were quite busy and once again it was my blog that had to suffer. We rewrote our whole middleware, I got into Esper, we had a big show in Orlando and I had to travel back and forth between Germany and the US.
But I didn't stop writing.
I finally pulled myself together to try write articles for software magazins. To my personal amazement it looks like as if people actually like the things I write ;)
The German Java Magazin published a 2 part series of articles on RFID and Open Source RFID tools in issues 4.09 and 5.09.
I mentioned before that I am writing on an article for the German Eclipse Magazin. The article was published in December 2008.
Yes, I know you won't be able to buy them as there are already new issues of both magazins out. I hope to be able to post links to the articles as both magazins tend to republish them online.

Software development basics

Software development is my passion. I love creating code, brooding over algorithms, learning new languages or frameworks and just about everything that is related to it.

Having started to code on the C64 more than 20 years ago I can savely assume that I know a lot about the process and the required mindset for coding.

And it's exactly that mindset that I miss in a lot of coders that come out of university.

It's not there fault. Universities tend to just teach the tools, like a programming language or UML, skipping the essential basics.

I don't want to get started on how much I think it is wrong to start coding with a language like java.

What I want to get started on is the basic set of principles and rules that should be the mantras of every developer and most engineers.

So this article marks the beginning of a small series about what I think are essential rules to follow to become a good coder.

In the series I will cover the following things:

K.I.S.S.

Divide and Conquer

Premature optimization is the death of software

Separation of concerns

Buildr + Scala on Ubuntu

So I got started on my Scala adventure.
Scala is a functional language and I wanted to get started with it since forever.
After playing around with it for some time I had to accept the sad truth:
The Eclipse plugin is a piece of crap.
Tons of crashes, inconsistent behavior, faulty auto-completion ....
So I had to go back to my old friend vim. The only problem was that without eclipse I needed something to do the building. I could have written some shell scripts but as we are looking for a better build system for our projects at Pramari I thought this might be the right time to do so.
Ant was no option, I already knew it and I wanted something new :)
Maven was also not an option. This tool is an abomination and if there is any tool that is able to singlehandedly make agile software development impossible then it is this monster (more rants to come, for now: If you need to dedicate a person to learn the build system you know that there is trouble coming).
After reading a ton of blog-posts I decided to give buildr a shot.
The tool looked very promising, getting scripting and building together looked very intriguing to me.
But before building the wise creators of Ubuntu and Buildr teamed up to give you a thrilling installation experience.
I have been working with Ruby on Rails for some time (Buildr is built on top of Ruby and Rake) so I expected a smooth installation using gem.
Boy, I was wrong.
It took me two days to figure out how to get it up and running.
First of all: I thought gem was a system comparable to apt-get. it's not. I tried doing gem install buildr which failed with a ton of error reports. After manually installing the required versions of rake and several other tools I ended up with a version of buildr.
To my surprise it wasn't added to a directory that in the shell path. After finding the file and calling it manually it failed with a couple of error reports.
To cut this short:
I just figured out how to get it running.
First of all: Don't try to do it from the debian gem repositories, you need to specify the version from rubyforge.
So here is what you need to do:

gem install net-ssh -version 2.0.4
gem install net-ssh -v 2.0.4
gem install net-sftp -v 2.0.1
gem install highline -v 1.4.0
gem install rubyforge -v 1.0.0
gem install hoe -v 1.7.0
gem install rjb -v 1.1.6
gem install rspec -v 1.1.5
gem install xml-simple -v 1.0.11

gem install --source http://gems.tron.name/gems.rubyforge.org/  buildr

This will give you a working version of Buildr 1.3.3.
To get builder to run with scala and java you need to specify SCALA_HOME and JAVA_HOME.
Uh, before I forget it:
Your buildfile needs to contain require 'buildr/scala' to be able to build a scala project. For some reason this line is not added if automatically creating a buildfile inside a directory hierarschy containing scala files.

Apache Commons Logging. IT'S A TRAP!

Apache Commons Logging (ACL) is a nice idea when you first stumble upon it:
Develop your app using commons logging, use whatever logging backend you want to use and let the guy deploying decide what he wants to use for logging.
So far so good. I liked the idea. We are using commons logging all over the place.
Now reality hits.
Two weeks ago we started a new project. This time we wanted to do everything right and wanted to get all logging centralized. Piece of cake when everybody is using it ... which is simply not the case.
Having tons of open source libraries in there we finally had to realize that not all coders bought into the idea of ACL. Which is perfectly understandable as it adds another layer to your logging, another jar to the classpath and it takes away the logging interface you came to love over the years.
People use ACL, log4J and *shudders* Java-Logging. How do you handle that?
A while ago I read a post about a new logging wrapper. The post was incredibly misleading and bad researched so I almost dismissed slf4j. Thankfully I looked again.
slf4j was actually what we needed.
So what does it do?
It's quite simple:
It's a log syndication tool. It just collects logging output from all kinds of different sources and redirects it to your logge rof choice.
Awesome, finally someone got it right.
Using it in OSGi makes my life a lot easier. Using OSGi I could sneak in the replacements for org.apache.commons into all libraries and could also catch logging output from all other sources.
Give it a shot and please, remove ACL from your project, it's a waste of time and space.

Double Check in Java is broken .. not

Coders from the C world are most likely to use the so called double check idiom at some point of their coding career. If those same coders (like me) do their first multithreaded app in java will probably run into some problems.After my first trials with java several years ago I ran into some pretty weird problems. Sometimes my nice apps would expose the weirdest behaviour. After searching around I got educated in a newsgroup.
Before I start to explain what the problem is I should probably explain what double-check is.
Let's say there is a certain object that needs to be initialized. An initialization should only take place once. Sometimes it might be required to postpone the initialization until the first use of the object (lazy init) or until certain conditions in the systems are met (service orientated architectures).
The following piece of code illustrates the naive approach:>

Test initValue=null;

if(initValue==null){
  synchronized(this){
      if(initValue==null){
          initValue=new Test();
      }
  }
}

So we first check if the variable has been initialized, if not we synchronize and check again and if this second check is succeeds we do the init work. The second check is done because another thread might have initilaized in the meantime.
The problem is that this won't work in Java. The JDK does a lot of work under the hood. On of these things is that threads can keep a local copy of variables. This behavior completely breaks double check.
That's where my story ended some years ago. I never touched it or bothered researching into it again.
Until I recently discovered atomic variables in Java and stumbled over the new memory model introduced with JDK 5.
After reading up on it I finally found the solution to fix double-check:
The volatile keyword.
Volatile indicates that the variable will be modified by several threads. This tells the JVM that threads are simply not allowed to keep local copies of variables.
Fixed double check locking looks like this:

volatile Test initValue=null;<br />if(initValue==null){<br />    synchronized(this){<br />        if(initValue==null){<br />            initValue=new Test();<br />        }<br />    }<br />}

Yep, I got my double-check locking back but there are still some things to consider:

• Performance: If using volatile on a variable better do some benchmarking.
  
• JDK 5: Yep, volatile only works like this with JDK 5 and later.

Spring, @Comparable, OSGi, Eclipse RCP in Eclipse Magazin

I wanted to post how I got Spring to use AspectJ for DI in Eclipse RCP applications. The post won't happen as I wrote an article about it for the German Eclipse Magazin. As soon as the article is out you will find a link to it in here.