Moved to Wordpress

The last post was about the last thing left over from my job at Pramari.
With my switch to Senacor I also decided to change my blog.
The new one is here:
http://codepitbull.wordpress.com/

WCI 2009 talk about CEP

I am giving a talk at the WCI 2009 titled "Taming the Tsunami - Tackling the exponential growth of sensor data using ESP/CEP". As one might have guessed it's about my (current) favorite topic: CEP and its applications. It's going to happen on Friday October 16th, 2009 and I am pretty excited as this is my first conference submission.
For those who can't attend or want to get a little information on CEP I put the paper up on my dropbox.

Faster developing in OSGi with '-console' and 'update'

Just a little hint for those who work with OSGi on a daily basis.
Starting and stopping an OSGi-framework takes time, even for small projects. Working on a bundle that requires a lot of playing around can become quite painful when you have to wait those precious 5 seconds or more until the system is restarted.
Thankfully the OSGi-spec already provides an update facility.
Each bundle can be told to update itself from the location it was loaded from.
That last part is the important part and made my life a lot easier.
Most, if not all, OSGi developers already use the console to get handy commands like 'ss' or 'services'. Another nice command is 'update <bundleid>'.
The cool thing about 'update' is that even bundles you included from your workspace can be used.
Just fire up the framework with the '-console' parameter and whenever you changed something in your workspace use update to get those changes into your running framework.

Embracing Groovy

Actually it's not that much about Groovy than it is about scripting.
After a yearlong battle I finally got my way and we added scripting capabilities to the Rifidi Emulator.
Scripting became an important issue as the scenarios we wanted to create grew more and more complicated.
Now that we also have to support RSSI (Received Signal Strength Indication) we need to be able to simulate tons of different reads with varying tag properties. Something that simply wasn't possible in TagStreamer.
So finally the management agreed that we had to include scripting support.
I already had quite clear picture of what I wanted to achieve and how the thing should look in the end.
So here is a quick outline how Groovy got hooked up to the emulator.

1. At first we had to get rid of the PlugIn-Registry from Eclipse. We were using extension points to register the different reader implementations but decided to be OSGi compliant a while back. We ripped out the registry and replaced it with OSGi-Services and Spring.
2. The nice guys at Groovy were kind enough to already ship an OSGi-enabled jar. So I just downloaded the current binary distribution and put groovy-all.jar into our target platform.
3. We took our RMI interface that we had added to allow TagStreamer to use Emulator instances remotely and refactored it a little.
   We basically made it more scriptable by exposing a couple of helper functions for creating tags and managing readers.
4. Integrating groovy with the new interface was the easiest part:
   Using the executor pattern we start a new Groovy Shell for each script. Each script gets a reference to the reader management service injected and can now create/destroy/start/stop... readers and tags.
5. Now to the part that I like the most:
   We have been using the Equinox-OSGi-console for quite some time now and we love how extensible this little bugger is. We added a couple of new shell commands to manage the scripts.

That's it. 5 days of work and we got full scripting into the emulator. It's not perfect but it will be improved while we use it.
Things we need to work on:

• Integrate with Eclipse (We want to make use of the great tooling Groovy has there)
• Integrate with Edge Server UI.
  
• Start distributing scenarios.

But for now I am quite happy with what we got :)

Exporting an OSGi application from Eclipse

Sometimes working with Eclipse feels like arcane science.
Creating a pure OSGi (Equinox) application is as easy as it can get.
Running and tuning are dead simple. Manipulating the runlevels works like a charm (needed to get load time weaving integrated).
But then try exporting it.
After a little painful research and some nice hints from the newgroup I got the following process:

1. Create a product from your launch config.
2. Open the product and go the configuration-tab. You will only see the bundles that were designated to be auto-started at a certain level. Add all other bundles and set them to auto-start at level 4. The funny thing here is that these are the default settings for every OSGi-Framework application, but in a product the default is to not auto start anything.
3. Now make sure that all fields on the overview-tab are blank (Application has always a preselection, at least on my install)
4.  If you haven't done so before add org.eclipse.simpleconfigurator to be started in level 1.
5. Start the Export Wizard.
   
6. Make sure that "Synchronize before exporting" is UNSELECTED, otherwise the export will fail.
7. Export.
8. If you don't have the delta in your target platform you will now have to copy the native fragments into the export.

There you go.

Living without friends sucks

And again I stumble over a scenario where it would be so absolutely helpful to have C++-like friends in Java.
Again I need to jump through hoops to get the desired behavior.
I am working on an integration of our SAL (Sensor Abstraction Layer) with Esper.
But the messages from SAL can go to other receivers like JMS, too.
The problem comes form the fact that the messages coming from the SAL have to be readonly to not mess Esper up.
As I like my code easy readable I prefer setters over big constructors. But in this scenario setters would be very problematic as they would allow the manipulation of data at any point in the future. Something that must not happen from the moment on the message went into Esper.
So public setters are a no go. Protected setters don't work as they are only accessible from the same package. So I end up having to write a big constructor, collect all the data from the different sources and then create the object.
Exceptions might be another way of solving the problem. But all the boilerplate code ...
Wouldn't it be nice to declare it protected and define a list of friends who can access it?
Then I would be able to create the object, pass it to the friends who are allowed to access the setters and then put the object into Esper without having to worry that somebody messes up my messages.
So sad.
Note:
I put together a little idea using CGLib and a set of different interfaces to built a proxy based solution. As soon as I get some time I will post it here.

K.I.S.S. and the 5 rules of laziness

This article took me a lot longer than I had expected.

I could try to bring up the usual excuses like "my apartment exploded", "my dog (that I don't have) ate my laptop" or "my boss locked me up in my office until my Trac issues were all closed".

Nope, the problem is that simplicity is the frickin' most complicated thing to explain.

I tried to keep it simple and summarize things that I feel are important aspects of simplicity. The resulting article is not even close to what I had intended and I think I have to live with not being satisfied with the result. But at least i lived up to my promise to deliver this.

How often did somebody use K.I.S.S. ("Keep It Simple, Stupid") to tell you how to improve your code?

After using K.I.S.S. on a lot of fellow coders over the years I thought it should be a quite simple task to explain.
Let's cut this short: I was wrong.
There is so much more to this issue than you think in the first moment. Explaining K.I.S.S. would easily fill a ton of books without really getting to the point.
After a lot of discarded posts I remembered a quote from a friend:
"The most important attribute of a good developer is laziness."
Good coding skills in combination with laziness leads to effective simplicity.

So here they are:

My 5 Rules Of Laziness.

1. Be lazy: Look, the world is full of developers, you are most certainly not the first one to run into that particular problem. Search for an open source project or some sample code that fixes your problem at hand (Never ever forget to give credit to the source of your solution!).
2. If 1. failed remember being lazy: Ok, so your google-fu is weak. Most likely you will have several possible ways to get the job done. Always pick the easier route.
3. If you are working on 2., be more lazy: This is a lesson learned from doing projects in an agile way:
   Solve your problems at hand (the ones defined for the current iteration), not the ones that MIGHT occur. Don't forget about the MIGHTs, put them as issues in your tracking system. Discuss them BRIEFLY with your project lead to see if you can replace the MIGHT with a WILL see if it is urgent enough to put in the current iteration. If not, leave it.
4. If you are impressed by the beauty and complexity of your code:
   - Print out a copy of it.
   - Put it on the wall next to the picture of Picard.
   - Start refactoring until you feel like your cat could understand the code.
5. Document it!

1 is quite self explanatory. If you can have somebody else do your work: Have him do it.

2 is a little more interesting. It deals with the arch enemy of of software developers:

Complexity

It's a mythical beast more vicious than Grendel and sneakier than Loki. It is secretly plotting to turn your beautiful source code into a pile of gibberish.

Every software development project has the tendency to grow bigger and more complex. The accomplices of complexity (customers, management, team colleagues) are lurking everywhere. Through feature requests and performance improvements they will make your code more complex. But you don't have to make it worse.

If you can pick and choose always go for the solution that is easier to implement.

If  you need to do sorting and you can choose between different algorithms: pick the simplest one. If that proves to be a problem swap it out later on (you should be using something like the the strategy pattern anyway).

Note (let's not talk about why I have to point this out):

Don't take shortcuts (singletons, declaring things static, breaking the separation of concerns principle....).

My 3rd rule is actually an extension of 2. A lot of times you will discover new problems while you are working on your items. If you find something that breaks the software RIGHT NOW:

• open an issue
• tell the project lead
• fix it.

If it MIGHT be a problem there is a 80% chance that it will never actually happen:

• report it
• discuss it
• If you can still put a MIGHT in the sentence describing the problem, leave it.

An example from my personal experience:

A developer was working on a fairly simple piece of model code. After seeing that the issue wasn't resolved after 4 days of work I asked the developer what was going on. He pointed out that the code for adding and removing items to the model wasn't threadsafe, so he started making it threadsafe. He had turned the whole thing into an intricated (an adjective that should make all your warning lights light up at the same time) piece of threadsafe beauty. At least that was what he thought.

The model class was used exclusively inside an Eclipse RCP application. Eclipse uses the reactor pattern, therefore everything is executed in the same thread.

He not only added tons of code that were simply not needed he also broke some things in the process.

My 4th rule is quite simple:

Nobody will be impressed by a complicated piece of code with the exception of the author. And he will lose the love for that code when he has to go back and understand it a few weeks after he wrote it.

Just remember that somebody will have to maintain it. And it will most likely be yourself.

Number 5 I just threw in because without documenting your code (and I mean in your code and not some fancy user docs) rules 1 - 4 are worthless.