Kai Kreuzer

This Is Not Your Father's House!

2011-10-31T13:39:00.000+01:00

To continue the "Not your father's" series (see Sven's blog and Marcel's blog) you can imagine that if even Java and IDEs have evolved over the years, the way that people want to use and operate their houses has tremendously changed as well!

As many EclipseCon attendees are likely to spend more time with their IDE and Java than with their families at home, they might find the idea appealing to also use Eclipse technologies for remotely adjusting the heating, turning off the lights, checking if the latest internet shopping has arrived or telling their spouses "I love you" through XMPP and text-to-speech, while staying late in the office another time ;-)

So if you are a geek and are interested in hardware, do not miss my talk at EclipseCon Europe this Thursday, 11.30am. I am going to demonstrate you how easy it is to add new hardware devices to your home automation infrastructure as well - luckily a few sensors are spread out over the conference venue.

You have not heard about the M2M contest at EclipseCon Europe yet? Go and prepare yourself for your participation then! And no worries - I won't compete with you in the programming contest as I will be a member of the jury :-) Looking forward to your submissions!

Using Xbase for Home Automation Rules

2011-09-29T22:50:00.000+02:00

Up to now openHAB has embedded JBoss Drools as a rule engine for automation rules. Although Drools is very powerful, this solution also has a few problems: The Drools IDE is not completely working in the openHAB Designer, so that no code completion and syntax checks are available for the rules. This makes the creation and debugging unnecessarily difficult, especially as the Java syntax of the rules is not very intuitive.

Although Drools offers an option to define tailored DSLs for rules, which could lower the syntax complexity, I personally feel that Xbase might be a better match for openHAB on the long run. This is why I have started with the development of an alternative rule engine for openHAB, which is fully based on Xbase. I would like to give you a brief summary of what exactly I have in mind:

Being a part of Xtext, Xbase perfectly integrates with the item and sitemap definitions of openHAB (which are already based on Xtext). It will therefore be easy to reference items from within rules and to have full IDE support on them. The "execution" part of a rule would be basically an list of Xbase expressions, which leaves a lot of power to the user as he can do all actions he was able to do in a Java-syntax Drools rule.

The main challenge is the "when" part of a rule, i.e. the triggering condition. Here lies the full power of Drools: Using a sophisticated RETE-algorithm it is possible to have relations between rules, where the triggering of one rule means the deactivation of others etc. This is indeed very powerful and necessary for expert systems and alike. For home automation use, my impression is that this rather confuses the normal user who still wants to be clear on what is executed when (and hence the defined rules usually use quite simple trigger statements).

The idea is to provide different kind of triggers (of different categories) for the new engine:

Event-related triggers: "Item X was updated", "Item X changed to OFF" or "Item X received command UP"
State-related triggers: "State X == ON", "State X != 0" or "State X > 20"
System-related triggers: "System has started" or "System is shutting down"
Timer-related triggers: "Time is midnight" or "Timer cron(0 * * * *)"

Obviously, one can think of many other trigger possibilities, but the list above should imho do for a start. Keep in mind that you can still do additional if-statements inside the "execution" part of your rule if these triggers do not suffice.

An example rule could hence look like this:

rule "Announce caller"

when

Item IncomingCall was updated,

State Presence == ON

then
send MusicPlayer OFF

say IncomingCall.newState + " is calling";
end

If you compare this example to the current Drools syntax you will see that it is much more natural to read. Having full IDE support with code completion etc. also makes writing such rules much simpler than it is today.

I am planning to show this new rule engine in action in my talk at EclipseCon Europe on November 3 in Ludwigsburg, so make sure you are there if you are interested in it!

Building p2-enabled products with Tycho

2010-12-01T19:21:00.000+01:00

Working on the build and the packaging of openHAB, I had to undergo quite some efforts to get it done with Maven3/Tycho.

My special challenge was to package a product which is p2-enabled and includes root files. If you just want to do the one or the other, it works quite straight forward: You can use the "eclipse-application" Tycho packaging type to build Eclipse RCP products, which will also nicely include any root files that you have defined on your features.

Since version 0.10.0, Tycho also supports building p2-enabled products (TYCHO-188), but you will have to use the "eclipse-repository" packaging type to do so. Unfortunately, root file inclusion does not work with this packaging type (due to very complex reasons, see TYCHO-513 and TYCHO-465).

So what is the workaround to have both at the same time? I have chosen a combination of the "eclipse-repository" packaging and the "classic" Maven assembly plugin to do this job.

The "eclipse-repository" packaging is used in a Maven project that contains the RCP product definition. Using the "materialize-products" and "archive-products execution, makes sure that the p2 director is used to install and package a product from the repository (for all platforms that are listed in the configuration of the target-platform-configuration Maven plugin). Note that choosing Mac as a platform does not seem to be an option right now, at least I could not get it working...

If you now run a "mvn clean install" on this project, you will find the resulting zip files in the target folder. But how to add additional files (such as readmes, licenses, start scripts, additional libraries and folders, etc.) to it to make it your final distribution? That's where the Maven assembly plugin comes into play:

You need to create a Maven project that contains the files you want to add. The assembly plugin allows the inclusion of project dependencies in the assembly, so we need to define a dependency on our product project in our pom.xml. The problem here is that if you do this as usual, you will end up with the packaged p2 repository to be included in your assembly as this is the primary artifact built by the "eclipse-repository" packaging. Luckily, the product zips are attached as additional artifacts to the build result, so we can define a dependency like:

<dependency>
  <groupId>com.acme</groupId>
  <artifactId>com.acme.rcp.product</artifactId>
  <version>${project.version}</version>
  <type>zip</type>
  <classifier>win32.win32.x86</classifier>
</dependency>

In the assembly descriptor, you then need to say that you want to unpack this dependency into your assembly. As Tycho often packages a bit to much into the zips, you can also take this opportunity to remove a few contents that you do not want in your final distribution:


<dependencySets>
  <dependencySet>
    <useStrictFiltering>true</useStrictFiltering>
    <useProjectArtifact>false</useProjectArtifact>
    <useTransitiveDependencies>false</useTransitiveDependencies>
    <outputDirectory>/</outputDirectory>
    <unpack>true</unpack>
    <unpackOptions>
      <excludes>
        <exclude>**/org.eclipse.platform.doc*.jar</exclude>
        <exclude>**/org.eclipse.jdt.doc*.jar</exclude>
      </excludes>
    </unpackOptions>      
    <includes>
      <include>*:org.openhab.designer.product:*:win32.win32.x86</include>
    </includes>
  </dependencySet>
</dependencySets>

Note the reference to include (only) the dependency to the zip for the Windows platform; this is necessary as you might have many dependencies for different platforms defined in your assembly pom.xml. This include tag makes sure that this assembly descriptor picks up the right dependency (you can have other assembly descriptors for other platforms in the same assembly project).

This solution might not be the most elegant, especially if you are building packages for many different platforms (you need a separate assembly descriptor for each). But it works for me and I thought it could be helpful to others as well. If anybody knows a smarter solution or has a suggestion how to improve mine, I'll be more than happy to listen :-)

Binary builds for openHAB available!

2010-11-29T18:22:00.000+01:00

As promised during my talks at the Eclipse Summit Europe and the OSGi Users' Forum Germany, I have finally fully automated the build of openHAB with Maven3/Tycho and uploaded the result to the openHAB homepage.
You will find there a platform-independent runtime zip that should work out of the box on Windows, Linux and Mac. This is all you need to get started. If you prefer IDE support for the configuration and rule files, get the openHAB designer zip file as well.
Besides these components, there are also optional bundles available in the download section, which you can add to your runtime if required for your setup. For all of this, simply follow these simple installation instructions.
Please excuse that the documentation about the configuration files, formats and options is still very limited - please visit the discussion group if you are in any doubt of what you need to do. I'll take care to update the documentation on the website subsequently.

openHAB @ Eclipse DemoCamp in Darmstadt

2010-07-27T18:56:00.002+02:00

I had the pleasure to present my openHAB project at the Eclipse Helios DemoCamp in Darmstadt on July 14, 2010. First of all, a big "thank you!" to Jochen Hiller and Marcel Bruch who have organized this great event and gave me the opportunity to do a short demo.

Altough most of my presentation was a live demo, I also had some slides that I have now made available on SlideShare for anyone who is interested.

Tycho Entering the Eclipse Space

2010-04-09T12:24:00.002+02:00

Almost two years have passed since my blog post about the the discrepancy of OSGi/p2 on the one side and Maven on the other. At that time I was pessimistic that the two worlds would ever come together and the creation of the B3 project even reinforced that impression.

Nonetheless I followed Sonatypes efforts on the Tycho front during the last year, which looked very promising. It actually already works so well that I recently changed the build of openHAB from Maven2/PaxConstruct to Maven3/Tycho - it's really cool (a blog post with details will follow soon).

Seeing that Chris Aniszczyk has now also embraced Tycho for the JGit/EGit builds is a clear sign that Tycho (and thus Maven) is slowly being picked up in the Eclipse space.

And the best news: Tycho has just been proposed as an Eclipse project! As the proposal states, it "competes with these [Buckminster, B3, PDE Build and Athena] projects". But seeing its current stability, its ease-of-use and all its possible synergies with the existing Maven tooling, I am pretty sure that it will win the race for being the preferred future build infrastructure for Eclipse/OSGi projects.

Kudos to Sonatype, who really put a lot of effort into this and who has torn down the barriers between the two worlds!

Choosing a Versioning Control System

2010-03-09T19:32:00.002+01:00

When initiating an Open Source project like openHAB, one of the many questions you have to answer before you start is: What VCS should I use?

In the beginning I did not really realize that this is an important question. Being a professional Java developer building commercial products with Eclipse, the use of Subversion with Subversive as an IDE integration just seemed natural to me and not worth any further considerations.

It was more by chance that I noticed questions about using git on other OS projects that were using SVN as well as the activities in the Eclipse community around (E)git. When Ekkehard Gentz started a blog series about DVCS and Eclipse, I eventually decided that I needed to have a closer look.

After having grasped the great advantages of a DVCS, especially for Open Source projects, I then had to decide for one - to keep things simply, I only looked at the most popular ones, Git and Mercurial.

As I am using OSGi and Eclipse, there were quite some strong arguments for Git:

With JGit there is a pure Java implementation available
EGit is now under the Eclipse umbrella and actively developed by many gifted Eclipse committers.
It seems that Git is more hyped than Mercurial (at least that's my personal impression).
Git seems to be more powerful and flexible

Hence I installed Git and EGit and gave it a try. After working with it a bit, I noticed that I didn't really feel comfortable with it. It is difficult to say why, but I made out the following reasons:

I am a Mac and Windows user and Git somehow made me feel that its home is Linux. Although there is now a Windows version with msysgit, cygwin used to be the official way of using Git on Windows.
Coming from SVN, the Git vocabulary can be confusing - e.g. something like a svn revert is not done with git-revert, but with git-reset. Together with the abundance of commands and functionality of Git, this can easily make people feel lost if it's their first time with a distributed VCS.
The standard way for pushing and polling with Git is ssh - but this makes things much more difficult to use, if you are behind a firewall.
EGit is still an incubation project and there's still some way to go until it reaches a level like Subversive: There is no support for the "Team Synchronization" view, which I use a lot. It also had some trouble with deletion and renaming of files. Last but not least - it is lacking icons on the context menus. Ha, I know, this is only cosmetics and should not be relevant at all; but still it leaves the impression of being a version to early to be used.

Almost all of the above items felt better on Mercurial (and HgEclipse), so I finally decided to go for it. I guess on the long run, I might reconsider this, once EGit has matured, but for the time being I am happy with this situation. And it is very reassuring that there are plenty of tools around to convert a Mercurial repo into a Git repo and vice versa - so no decision needs to be taken for eternity!

Now I am only waiting for Ekke to finish his series to eventually see to what conclusion he came and which DVCS is the one of his choice :-)

Positioning openHAB

2010-02-23T18:44:00.001+01:00

As already mentioned before, I have started the openHAB project not because nothing on the market could have provided me the desired functionality, but because I want to build something robust, stable and open with a modern technology stack.

If I were a pure user, I would still stick with Misterhouse as this has matured over the years so much that they are discussing on their mailing list already whether it's better to have a deer head or a magic mirror talking to you.

Well, I am not, and so I take the challenge to build something equally useful on top of a JVM. After Claude's comment I very much considered contributing to the openRemote project, tried to dive into the details of their code base and involved myself in technical discussion on their forum. But at the end, I decided against it, because all the main things that I would like to see covered are still on their todo list. That wouldn't be bad at all as it could have given me a good opportunity to contribute the missing things, but unfortunately - at least that is my impression - it would mean more or less a complete rewrite of openRemote...
Just to give you a few examples of what openRemote IMHO lacks:

No rule engine support yet
it has a "one-way" protocol, i.e. the client (e.g. iPhone App) is stateless -> it cannot show if lights are on or off, it cannot display values (e.g. temperatures), etc. Version 2.0 will bring a server push, but I am not sure when the client will support this?
No states are cached on the server which is definitely a problem for rules and stateful clients
No modularization / extension concept yet, it's one brick (the BOSS)
No easy protocol to implement for new extensions, see discussion about arduino support
No simple way to build from latest sources, so people are desperately waiting for an official build

I don't say that any of this is bad, I just want to highlight that their architectural approach obviously followed other priorities. I can imagine that openRemote and openHAB can cross-fertilize each other and maybe there is someday a possibility to integrate or even merge these projects - time will tell :-)

openHAB is out!

2010-02-21T22:11:00.001+01:00

It took quite some preparation, but finally I can anounce that I have created the envisioned Open Source project for my (and others!) home automation needs!

In order to avoid any brandmark violations, I have reconsidered the name of the project, so that it is now called the open Home Automation Bus (openHAB).

You will find the project hosted at Google Code at http://openhab.org, even an initial codebase is already available. Although it's not doing much at all yet, it should give interested persons an idea of its architecture and show that things are moving and the project is on its way.

I will soon post further background information about the decisions taken, so stay tuned :-)

Reinventing the Wheel

2009-11-22T00:38:00.001+01:00

As announced, I would like to tell you some details about my latest private project: SmartKNX!
I have spent quite some time in the past months with the Open Source project MisterHouse - a software for home automation. Initially, I have started using it, then I also engaged myself in the community and contributed some new features and bug fixes. Misterhouse really offers a lot functionality and it has quite a low learning curve for newbies. Especially, the iPhone interface is attractive, which has been mainly done by members of the german KNX community. See these screenshots to give you a rough idea, how it looks like:

So although this all looks quite fancy and modern, being a professional software developer, I still do not feel completely satisfied with it. There are multiple reasons for it:

MisterHouse more or less only consists out of a bunch of Perl scripts; the core dates from more than 10 years ago. Many parts are hard to read as the software is not modular and even things like the HTTP server are coded in Perl with a scary if-then-elsif-elsif-elsif... block for doing all request processing.
The standard web interface also dates from the 90s and thus is not really usable anymore. The iPhone interface has been plugged on-top, but is not really well integrated. Future additions like ajax-enabled features might become very awkward due to the reason above, the simple embedded HTTP server.
I do not want to think of what security wholes might be in these scripts, there has definitely never been any focus on securing the interfaces.
There is not really good IDE support for the whole thing; my tool of choice for the moment is 'vi', but as I am not 100% fluent in Perl, the regular expressions and the MisterHouse API, it is often a long trial&error session before things work the way I want. Eclipse Perl integration has helped me a bit now, but still it is far from being as nice as all the goodies of JDT.
Debugging is a nightmare for me as well; I can put some log messages here and there, but often it only helps to do educated guesses what might be wrong. This is tedious and not the way one expects software development today.

Taking all the issues above, I asked myself if this is really the framework that I want to work with for the next decades (well, a home automation project is really for a life-time, isn't it?). And I wondered what my sons will tell me if they grow up and see what I did there (and I have to ask them to learn Perl in order to maintain our house)...? So do not get me wrong - I really appreciate what has been done with MisterHouse and it is truely amazing. I just feel that time has moved on and that after more than 10 years it could be time for a "next generation" implementation.

And this is what I would like to do: A complete rewrite of MisterHouse on basis of the very latest technologies - the temporary project name is SmartKNX, which also shows the focus on KNX rather than X10 (what MisterHouse is mainly focusing at). But of course, SmartKNX should be so modular and extensible that any other domostics standard can be supported as well. As technologies, I have things like Java, OSGi, XText, Maven, Scala etc. in mind... More details will follow - stay tuned!

Accumulated Distraction...

2009-11-20T20:30:00.007+01:00

It's a long long time since my last post, but I swear that I haven't been lazy or without impulses. Usually, I like to blog while being at conferences and it is not long ago that I attended the last one: The Eclipse Summit Europe 2009. As usual, it was a great event with many interesting people and lively discussions.

But a few things detered me from directly blogging about my impressions this time. For example, the ESE2009 organizers did not provide any public Wifi access to the attendees this time. I am not sure whether this was because the Wifi used to be heavily overloaded in the past years or if they just wanted to draw attention to the talks; if latter, this might indeed have worked out as I have seen much fewer people typing on their Macs throughout all sessions... Another reason for not blogging at this occasion was that I was invited to an X-Box soccer competition by the Itemis guys until late at night; these chaps seem to always be prepared for everything ;-) Last but not least, I didn't find much time to blog on the last conference day as I was called to hospital for the birth of my second son - well, I hope that at least this can be accepted as an excuse.

Despite all these distractions, I have been working quite eagerly on a new private project that I will very soon blog about; it is quite fascinating and if all goes well, I might present it on a future ESE - let's touch wood!

One last remark: As I missed a few sessions at ESE due to my early departure, I am taking the opportunity to join the Eclipse Demo Camp in Frankfurt next Thursday. There are already more than 60 people registered for it, which is quite astonishing. So if you are around and don't have any other plans - join me there!

It's All About Dependencies

2008-04-27T15:57:00.004+02:00

Trying not to reinvent the wheel over and over again in software development, reusability has quickly become a strongly desired virtue. Object-orientation was once meant to deal with this, but it soon became obvious that objects are a much too small unit to be really reusable across projects or companies. So in today's world we ended up with modules all over the place - some call them libraries, plugins or bundles, but most often these are simple jar files; in general a module is just a bunch of classes and resources, sometimes enriched with some meta-data.

As it is with objects, modules make only sense if there are dependencies between them. For objects, these dependencies were often hard-coded, but in the age of dependency injection they form rather meta-data that comes aside the classes (e.g. in a Spring application context xml).

For modules, two main solutions have evolved over the past years to describe dependencies: Maven pom-files and OSGi manifest-files. Both have quite a lot things in common: They specify names and versions of modules and list their mandatory or optional dependencies. Of course there are many details where the one offers more and other things than the other, but in general, it is a very similar concept.

The difference between Maven and OSGi is their use case: Maven targets the provisioning, build and distribution of modules, while OSGi is targeted at the development and - more importantly -
the (dynamic) runtime of applications. Both are well established in their domain and have a big community of users - but slowly people realize that they actually want to have them both at the same time. On the one hand, OSGi is introduced into "classical" applications by Spring Dynamic Modules where the build process is best left to Maven. The OSGi crowd on the other hand has noticed that it is a pain to collect all required dependencies and that there actually should be something like a repository infrastructure to easily retrieve and distribute modules.

The OSGi Alliance has therefore set up the OSGi Bundle Repository (OBR) - which looks very similar to Maven repositories, I just doubt that it will be equally successful. The Eclipse Foundation, one of the foremost adopters of OSGi, went one step further and introduced p2, the new provisioning system that will come with Eclipse 3.4 aka Ganymede. p2 replaces the Eclipse Update Manager, brings a new infrastructure for bundle repositories and supports to dynamically install and manage bundles in a running application. In the next phase (after the release of Ganymede), it is planned to extend p2 towards the build process as well.

Although competition is usually very welcome, it means some dilemma for the average configuration manager: Building dynamic applications does not mean that one can decide for the one option or another, but both approaches (Maven and OSGi) need to be combined. There are multiple tools and plugins available, which help converting Maven pom-files into OSGi manifests or vice versa or which allow calling the plugin build from Maven or to call Maven out of Eclipse.

The problem is that with generation one descriptor file out of the other, some information is usually lost or at least the comfortable tools cannot be used that exist to maintain the files. So the right decision very much depends on your application: If you already use Maven for continuous integration, the pom-files will be the source of everything for you and you can introduce OSGi by generating manifest files from these. If you instead work on an Eclipse RCP application and are used to all the comfort that Eclipse offers you for editing the manifest or the plugin.xml, nobody will be able to convince you that you should instead manually put your changes in a pom-file and generate the rest again.

Although p2 is a cool feature, it might make things worse, at least in the beginning: For OSGi-centric applications, its use will be very desirable, while not offering all flexibility of Maven. So if Maven is already in place, it is unlikely that it gets replaced by p2 soon. Instead there will be adapters, mapping Maven repositories or OBRs to p2 and having Maven builds pushing build artifacts back to them.

I would not object to using different tools, if the integration would be smooth - but experience shows that both worlds do not really pay much attention to each other and leave the integration part out of their scope - so usually the integration is done by some annoyed people who actually want to use things productively and have to help themselves to sort out things. Unfortunately these kind of integrations are often only pursued until there is a version that is doing somewhat the expected thing - and then it is left to the depths of Sourceforge. Maybe I am too pessimistic, but the Equinox team already stated that they are not interested in any direct support of Maven, so the way ahead might be bumpy...

Still, at some point in the far future when Spring Dynamic Modules have become a de-facto standard and p2 is stable and fully supports the build process, I am confident that building, integrating and deploying applications can be real fun :-)

Some Goodies...

2008-04-26T13:17:00.003+02:00

During the JAX'08, I learned about some helpful tools - some being older, some newer, but for Eclipse RCP programmers or Java programmers in general maybe helpful. So here's a short bullet list of what I came across:

The Nebula Project: Pretty cool widgets to include into your Eclipse RCP applications. If you want to have something that does not look all normal, but with some wow-effect, that's the place for you to go.
Many people complain that RCP applications look to similar to the Eclipse IDE (and therefore too technical and not fancy enough), so here's another possibility to make something special out of your RCP app: Use Eclipse presentations! Kai Tödter provides an easy example how to do this with his MP3 Manager. If you want to see how far you can go with these presentations, have a look at Lotus Notes Hannover - but make sure to employ some full-time resources just for developing your RCP skin...
The Plugin Spy will come as a feature of Ganymede (Eclipse 3.4) and really makes life much easier to find out what you are looking at (which class, extension, id etc.).
The Eclipse Core Tools can be very useful for debugging - they give you some insight into places that are otherwise hidden from your view.
Everybody who has problems with memory leaks in Java applications will very much enjoy the new contribution from SAP, the Memory Analyzer.
Something already quite old, but definitely useful, is Pack200, a packager that is specialized on shrinking Jar files - which works very efficiently. Although jars are usually already zipped, their size can be reduced immensely by Pack200. This is useful for distribution, but you should be aware that you need to un-pack200 your jars before they can be read by the JVM. The new Eclipse provisioning system p2 will make use of Pack200, that's how I came across it. Apologies if you might now this tool since years already...
If you want to "patronize" your developers a bit more, you can use AspectJ to enforce your architectural rules that you define. A nice starting point to do so is the PatternTesting project, which might give you an idea of how powerful AspectJ is for this purpose.

Concurrency in the Java World

2008-04-24T17:35:00.002+02:00

No this post is not about multi-core cpus or about making your code more thread-safe. It is instead about the latest trends in the Java universe. As Ted Neward says, Java was seen for a long time as the universal (God given) programming language that can and should be used for each and every (software) problem in the world. This ended up in a blown up JDK, an abundance of core APIs and an always busy JCP. Furthermore, Java has become an established programming language. As Rod Johnson notes "Nobody wants to date a Java developer." Java is now mainstream and not sexy anymore.

Out of these two reasons, one could see a clear trend away from the "classical" Java.

The very first step in this direction was IMHO already the rising of Eclipse - the chosen name already shows that it was intended to break the Sun monopoly in the Java world. All of a sudden, there was a "parallel" UI-widget-framework available than AWT/Swing that is an integral part of every JRE.

The second step was an alternative to J2EE: Spring, as I have already mentioned in my last post.

Then there followed the hype of dynamic languages, first of all Ruby with the web app development extension Rails, which many Java (web) developers turned to. The ones who didn't want to miss everything about the Java platform, chose the "light" version of turning Java the back and got on with JRuby or Groovy.

It wasn't only dynamic languages that prospered on the JVM, but there were also new statically typed languages, such as Scala showing up and getting lots of attention and interest.

The world was just seeking for something new and sexy again - the only common denominator was the JVM as everyone agreed on its great benefits of its write-once-run-anywhere concept.

But then came Google around and used Java just the other way round: GWT and Android both let the developer use Java syntax, but their source code is compiled into something very different than Java bytecode: In the former case its Javascript, in the latter its classfiles for the Dalvik VM - an alternative VM with its own compiler.

So has Suns battle to keep the Java community together failed? Despite of all of the above, I tend to say no. Obviously, the idea of an omnipotent programming language must be given up, but not because Java is bad, but because there simply is no one-size-fits-all in programming. In contrast to .NET, the Java community promotes its own freedom and all the movement in the market is a clear sign that this freedom is used to drive innovation and that things will evolve.

The bad news is that you cannot rest on your knowledge of the Java language - the language itself will change in the upcoming years and there might be different favourable options, depending on the environment that you are working on. So stay informed and don't forget to learn at least one new language per year, before it's too late :-)

The Emperor's New Clothes

2008-04-23T11:13:00.002+02:00

I have been puzzled already many times about how complicated and difficult to understand some things are done in the software development world. For example, I never really fully understood the need for fully-flegded J2EE application servers for any kind of web applications. I have seen so many cases where EJBs were hardly used at all (because of their inherent complexity and their backdraws) and there existed only a set of stateless session EJBs, of course without any distribution or clustering needs.

So from this background, I very much enjoyed a session with Brian Chan, the CEO of the OS Enterprise Portal Liferay, who explained why and how the migrated their application from a pure J2EE application to a Spring-based web application running on Tomcat.

Brian came up with a very striking analogy: He stated that the J2EE/EJB history very much resembles the tale of the Emperor's New Clothes: For years, whoever wanted to build "enterprise" applications automatically set on EJBs. There was no questioning about this - instead, it used to be a perfect selling point as nobody challanged the product's architecture; what was based on EJBs was automatically considered as good and professional. Nobody dared to admit that EJBs were bloody complex at that time and did not solve the real problems - as nobody didn't want to appear as a fool. Until Rod Johnson came around and told the world in 2004 that there are indeed ways to do enterprise applications without EJBs - he introduced Spring. So Brian rightly praised Rod for having the guts to play the child, stand up and point out that the emperor was indeed naked. This was really the advent of a big change in the people's mindset about enterprise applications. It does not mean that there is no right for J2EE applications servers to exist, but that there are many cases where there are actually better (i.e. simpler, cheaper and faster) solutions.

Now I am just waiting for somebody pointing out that HTML is not at all the right technology for building enterprise user interfaces...

Keeping Process Alive

2008-04-21T18:07:00.004+02:00

New year, new conference, new blog entries - this time I am attending the JAX'08 and I have just an interesting opening "Agile Day" behind me. This was all about agile development and management practices and how these can be introduced into an enterprise, which has no experience with them yet.

There are many agility-oriented consultants that know how to enable the transformation of a team or company towards an agile player. This is not an easy path to follow, but with enough social skills, it should be possible to get things going. It is key to success to have full support from management as well as from the team members. If any side has doubts or does not welcome any change, the transformation project might be doomed before being started.

Now imagine that despite all possible obstacles the transformation was a success and your department is now following appying agile practices. The external consultant leaves and you are left on your own. What happens? For a while, it is taken as normal that after such a big organisational change there is still some inclarity about one thing or another and one tries to figure out how to fill the gaps. Usually one fills the gaps with something that one is familiar with and so this will bend the agile process a bit towards the "old" style to do things in the department. As things are not smooth yet (to really "live" agile practices, people might need several months or years) and so no real improvement can be seen and only few people will be enthusiastically support it (now that the expert as a backing is missing). New people will arrive, others will leave the company. Spin this further for a couple of months to a few years and most of your agile process will have eroded. It is likely that all you will see that is left is continuous integration - that's the one practice that is so immensely successful, that nobody wants to miss it and so its wide acceptance is almost guaranteed.

But what to do to avoid the erosion of the rest of your practices?
From what I learned there are a few key things that you need to make sure on the long run:

In each agile team, you must have at least one change agent that actively persues the agile way and continuously drives the team to follow the practices and to improve its adoption. "Supporters" of the agile way are not sufficient - if things start to slip, the change agent must take immediate action, so he plays a very active role.
New team members must be fully introduced into the practices - not by provided some Wiki pages with coding conventions to follow, but with an active mentor or foster parent during the initial weeks or months.
You need to pay special attention to your retrospectives - these really forces the whole team to think about the process, where it is not appropriate and what can be improved. Only by these retrospectives it can be achieved that team members identify themselves with the practices and see it as something that they really own (and therefore need to care about it).
Progress should be made visible (e.g. in burn-down-charts) and achievements should be celebrated - each successful iteration motivates the team members and it gives confidence in the ability of the team to the team itself as well as to the management. A positive effect is also that with each iteration, future estimations will become more precisely.

If you respect all of the above points my guess is that you have a good chance that your people really pick up the agile way, live it and improve it. That's what you should be striving for.

The Eclipse Plugin Build Nightmare

2007-10-12T09:10:00.001+02:00

A couple of weeks ago, I was still naive. Having build an Eclipse RCP application it was easy to use the PDE tools "product export" or the "Build all" of an update site project to build and distribute our application. Ok, I had to fiddle around a bit with the right dependency settings for my product definition, but it was all no rocket science.

Now all that was left was to include this build in our continuous integration server. My primitive belief was that there should be a simple API access to immitate the "button click" that I usually did manually. I could not have been more wrong.

I had my first doubts after it took one of our most gifted developers a couple of weeks to perform this job for our proprietary environment. Clearly I blamed our environment and could have bet that it is all so much simpler with any common CI system.

It was just until this week at the Eclipse Summit Europe that again had to revise my opinion on things: No matter who I talked to, nobody ever found a quick and easy solution for building their plugins. There is no stable solution for Maven, the PluginBuilder does not relief from intensive maintenance and even the official Eclipse projects do not have any common ground to "build" on. What explains why you can hardly find any snapshots published to an update site...

The Eclipse Foundation has already identified this as a "pain point" and apparently at least the documentation has already improved with the Europa release. Let's hope that there will be also more improvements on the tools side to make this task something that does not hinder us from being productive for weeks.

RAP as the next GWT?

2007-10-11T16:57:00.000+02:00

One of the projects I recently got to know about is the Rich Ajax Platform (RAP). So far I was never very interested in frameworks around Ajax, but being an Eclipse RCP developer, RAP really caught my eye. It has a similar approach like the Google Web Toolkit (GWT): The application is developped purely in Java and it is automatically "converted" into a web application by the toolkit.

One big difference is that RAP actually mimes the SWT API - so in principal, all you have to do to make your Eclipse RCP application a RAP application is to replace your dependency declaration from the standard Eclipse SWT bundles to the RAP bundles. Hence there is no new API to learn and code can be easily exchanged between SWT and RAP applications.

While GWT produces lots of Javascript code to actually run most of the logic in the web browser, RAP keeps the logic inside Equinox on the server. The web browser mainly serves as a "terminal" to display the UI and to receive and send events. Although the project is still in an early stage, it is already working quite nicely as one can see at http://eclipsediscovery.yoxos.com/discovery/rap.

I am sure that this project can be of great help to quickly build complex and interactive user interfaces on the web. This can be so much more productive than working with classic web frameworks with Ajax packages on top...

Doing IT the Eclipse Way

2007-10-10T22:40:00.001+02:00

Having joint a BoF session with Naci Dai (member of the WTP project mangement committee) tonight, I now have a clearer view on what is special about the Eclipe community. Being initiated by a big company like IBM obviously helped to provide a sustainable and solid foundation for the whole community. There are for example strictly enforced processes - like how to become a committer to an Eclipse project. Only developers who have proven to deliver quality code by regularly contributing to newsgroups or BugZilla are elligible to be suggested as a new contributer. Not even a company that sponsers a project has the right to bypass this process.

Also, there is a long process for new project approvals - it usually takes several month before a project even gets into the incubator. All of this ensures that the community is composed of motivated AND talented people - which results in a pretty good quality of the Eclipse ecospace.

Although there are strict processes to comply with, the internal project organisation is left to the projects and leaves a lot of flexibility. This is important for the agile self-organisation of the teams and clearly works out quite well - as long as the projects are kept small.

The clear message is that Eclipse does not want to be SourceForge - nobody should simply come along and "dump" some code, but the contributors are expected to be sustainable - which might explain the fact that merely about 1% of the committers are students. An astonishingly low figure! So Eclipse is really backed by companies sponsoring the developments by dedicating staff members to the projects.

Every employer of a committer must sign an IP agreement that the code that is contributed is automatically under the Eclipse license. Interestingly, Google is one of the few companies who does not sign these agreements, such that there are no Eclipse committers from Google. It seems that "don't be evil" does not automatically translate into "be good". At least it shows that Google sees the Eclipse community as some kind of competition to their own initiatives. Interestingly, at the Eclipse Summit you can find many flyers from google about the summer of code etc. How did they get there? Seems that Eclipse is not totally unimportant for Google...

Some Thoughts on the Open Financial Market Platform

2007-10-10T21:15:00.001+02:00

Yesterday I attended a Symposium about the Open Financial Market Platform (OFMP) at the Eclipse Summit Europe in Ludwigsburg. This platform is an Eclipse project proposal which is based on an inhouse solution that has been developped by a project team in a bank.

The Symposium had an interesting setup - besides the project team that contributed about 25% of the participants, another 60% were committers of other projects or commercial products that partly offered to bring in their know-how and make sure that OFMP one day nicely integrates with their project. The rest of the crowd were about three people - including me.

The objective of the Symposium was to define what services could be defined and in which direction the project should move, so that it is interesting for the community. But wait - which community? The participants of the Symposium were not the target audience - these should be people from the financial industry that want to solve similar problems and therefore could benefit from the work done by the initiators. So clearly, at least I should be part of the targeted community, right? Unfortunately, the built solution is a mid-office deal processing platform, which does not really have much in common with the Asset Management solutions that we at Odyssey are dealing with. Besides, the OFMP is supposed to be a modular set of OSGi bundles that offer reusable services. The current implementation is a monolithic EAR, though. Even worse, it has not been build for easy customization, the services have not yet a clearly defined contract and they depend on a specific data model with a DAO persistence layer. I bet my feedback didn't help motivating the OFMP team too much.

Do not get me wrong, I very much honor the commitment that the team shows. Maybe it is merely my nature to be doubtful or maybe I have already seen too many initiatives failing...
To sum up the critical factors that I see in the way for a success of OFMP:

The effort of migrating a JEE EAR application to modular OSGi services is easily underestimated.
The proprietary data format should be replaced by a standardized solution like FpML. That is planned, but again, this is a lot of effort that does not bring any benefit to the initiator.
The solution has not yet proven to be reusable. There should be at least a handful banks that have already adopted the solution, before other banks will have trust that they could also benefit from it. Sadly however, the initiators do not even know a potential next victim.
To give a direction to the project, business analysts are needed as otherwise there will be a superb technical infrastructure , but no services that use the real-world problems of the banks. But how to get business people abord an Eclipse project? Any chance that they spend their precious time being surrounded only by geeks? I am sure that that will be a challenge...
The initiator, being asked what they would like to see being contributed to the project by others, so that they themselves can benefit (isn't that their motivation after all?), couldn't tell a single feature (besides improving and bug fixing some of the existing code). Does that mean that the solution is already full-fledged? Rather not - instead I see the risk that they quickly loose the (financial) interest in the project and stop supporting it.

Anyhow, I am looking forward to see OFMP evolve and I wish the team that none of my fears come true!

Has OOD failed?

2007-07-03T12:07:00.000+02:00

Inspired by some sessions at the TSSJS, I spent some thought on the "old school" object oriented design programming model. It appears to me that, although we are all using object oriented languages like Java, the core idea of object orientation has somewhat failed without anybody actually admitting it. Here are the arguments that should make you think about it:

The original idea (at least how it is introduced to beginners) of OO is to create real-life "stuff" in software, like a library, books, etc. - nowadays referred to as the domain model. In reality, the domain model is often less than 10-20% of your codebase - the major part are "abstract" infrastructure elements like facades, notifiers, providers, factories, services, etc. Although people will argue that these also have an equivalent in the real-world, one cannot really disguise the very technical concepts that lie within them, which seem to be rather forced into an OO shape.
For many people it has become a best practice to design an anemic domain model. This really makes objects lifeless as all logic is taken away from them and they degrade to pure data containers.
From other classes that still contain logic, AOP tries to squeeze out the cross-cutting pieces, like logging, transaction handling, etc. This functionality is then instead kept in aspects (does anybody really dare to call them objects?) that are attached to the outside of the objects like contagious pimples. (Don't get me wrong - I like the idea of AOP very much!)
Having internal states of objects results in a bad memory footprint, so to be scalable we prefer having stateless services without any internal state.
Passing objects via method invocation might work for some internal classes, but on the SOA-enabled systems, we are passing XML data structures to remote stateless services.
Public constructors are outdated, better use factories instead, or - even better for decoupling - a Spring container that handles this for you.
The object-relational mapping stays a nightmare, despite Hibernate and JPA. JDBC result sets still appear to be an adequate solution, especially if one only needs a few fields from a long list of records.
Business logic as the core part of the software needs to be quickly adaptable to new business requirements. Therefore it is taken out from the objects and moved somewhere else, e.g. in a rule repository (e.g. VisualRules, jRules or any kind of script) where it can be replaced or updated without recompilation and redeployment. Another option is to call it service orchestration and call global functions (web services) in a procedural manner driven by a BPEL file.

Object orientation doesn't seem to match the needs of todays challenges anymore - and it feels as if we stick to it because nothing better has yet been found. It will be interesting to see how dynamic languages might help moving software development into a new dawn.

Code and Data in the Light of DSLs

2007-07-03T09:07:00.000+02:00

In the keynote at TSSJS, Martin Fowler talked about one of his favorite topics: Domain Specific Languages (DSLs). In his point of view this is all about writing readable code that speaks for itself and doesn't need any further inline documentation to be understood. That general purpose languages such as Java do not fulfill this requirement can be at the vast number of proprietary XML configuration files, each of which is based on his own little DSL, according to Fowler. I agree with him that extensive XML configurations do not help the readability at all and rather result in the infamous XML configuration hell. With the advent of Spring, more and more information is moved from the code to XML files and although the Spring team doesn't see any problem with this, projects like the SpringIDE hint that there is some lack of readability in these files and that a tool-supported representation of the information might be of help.

But didn't we just mix up two different things: Java and XML? Java is used to write code, while XML merely holds some configuration data. Is that really the case? And what is actually the difference between code and data?

Code vs. Data
On machine level, its all just bytes. A memory range can store machine code and/or data, and there is no sign on what the information is supposed to be. It is easy to execute data - buffer overflow exploits demonstrate this daily. Higher level programming languages such as Java introduce a strong separation of code and data in order to prevent such security holes. XML is widely used for configuration data and for the exchange of runtime data (think of web services or message queues). But then there are things like HTML, BPEL, etc. Do these merely hold configuration data or are they actually code? What about a script that is stored inside a database and executed via the Java Scripting API? And what is a rule in jRules? The boundaries between pure code that defines the sequence of the operations and data that influences the decisions in this sequence has become completely blurred. It is a matter of personal taste where configuration ends and code starts - only the power of the syntax might be used here as a guide and as a starting point for discussions.

Use Cases of DSLs
Let's come back to DSLs. Do they now address code or configuration? After aboves elaboration, the answer is both. Although the general discussion of DSLs often refers to DSL-enabling languages like Lisp and Ruby, and by this at the description of code, there are also frameworks like openArchitectureWares xText that help to describe models, i.e. data structures with a DSL. Fowler distinguishes between external and internal DSLs. Not wanting to draw a line here, I am still tempted to say that internal DSLs are usually a better match for code, while external DSLs are a good candidate for data.

DSLs and XML
So will DSLs be a solution to the XML configuration hell? I do not believe so. As I said, on the one hand the public discussion is much more about dynamic languages that are seen as the saviour for many problems - for code. On the other hand, XML languages still spread unmolestedly and there is no end in sight - but that's what XML was about right? Having an XML Schema as your DSL simply gives you a platform independent format with tool support (XML editors and parsers) for all you ever wanted to express. What is just lacking is the readibility that Fowler asks for. But instead of replacing XML and XML Schema with some well-readable DSL, the market seems to strive for a different solution: It regards XML merely as the serialisation format and provides graphical editors on top of these. Now that is readable as a diagram looks so much better than XML code. We just might now end up in an editor hell - you will need a vast set of editors (all with a different user experience of course) just to configure your application. So how will we change this if we just have "vi" available on a remote console? Well, let's hope that the XML format is still human-readable and that the XSD is somewhere near!

Summary
The dilemma is that XML Schemas are the most widespread DSLs, while not offering a good readability. The current discussions on DSLs won't have any impact on this fact - in contrast, in our heterogeneous world XML will continue to spread not only as a configuration or data format, but also to express programmatic logic (e.g. BPEL). Instead of having an easily readable format, more and more graphical editors will become available to ease the work with these XML formats and to make them available to (business-oriented) people that are not at ease with XML.

OSGi - the new Java enterprise container?

2007-07-02T14:55:00.002+02:00

Counting the number of sessions on OSGi, one could get the impression that this is just in its trigger phase of the Gartner hype cycle. But looking a bit closer, this technology does not seem to follow the usual pattern: OSGi is around already since 2000, at that time targeted mainly at the embedded systems world. Slowly but steadily, it has crept into more and more markets. It has by now already proved to be a stable and well-functioning platform for Eclipse and it is used in many software products like IBM Websphere Application Server (WAS) or Adobe Version Cue without anyone taking great notice. How mature OSGi already is, is demonstrated best by the fact that the OSGi Alliance has admitted that the abbreviation OSGi doesn't actually mean anything in special (formerly it should stand for "Open Service Gateway initiative").

So what is OSGi then all about? The OSGi Alliance defines it as a "dynamic module system for Java" and as a "Universal Middleware". It indeed is a component container, specialized on the clear separation of the components and their flexible lifecycle management.

OSGi and Java EE
Originating from the embedded world it is per se lightweight, in absolute contrast to an Java EE compliant application server stack. That should not say that OSGi tries to compete with Java EE, though there are many scenarios where OSGi might be the better (because lighter and leaner) choice altogether. Instead, it can also improve current Java EE architectures by modularising existing EARs and by introducing strict dependency management rules. Using an OSGi container on top of an application server brings benefits like the possibility to transparently replace a module during runtime or to run multiple different versions of a module at the same time.

OSGi and Spring
Talking of lightweight containers, Spring quickly comes into ones mind. Although Spring proponents will argue that one cannot compare Spring with OSGi as both try to achieve different things, they yet do not intervene when somebody says that Spring will be the next Java EE. So as we have already compared OSGi to Java EE, it must be allowed to compare it with Spring likewise. They both are lightweight containers, trying to decouple the parts of a modern software architecture. While Spring tries to reach this goal on a very fine-grained (object) level with dependency injection and aspects, OSGi introduces a rigorous dependency management and a runtime seperation of modules using different classloaders.. Where Spring declares its beans in the application context xml, OSGi declares its exports and services in its manifest. Both containers therefore do similar things - but with quite different means. Both approaches are beneficial for the software architecture and therefore it is legal to say that Spring and OSGi are a perfect match - with the reservation that the configuration has to be merged (and redundancies removed) and that Spring lets itself deploy inside an OSGi container. This is what the Spring-OSGi project is all about, which is scheduled to be released in August.

OSGi and Maven2
Alright, Maven2 is definitely no container by any means, but still it has one striking similarity to OSGi: The profound dependency management with automatic resolution of sub-dependencies and different versions. Maven users are blessed by not having to care about where to retrieve their dependencies from and how to put them all correctly in the build path. The dependency declarations in Mavens pom.xml is very similar to the information in OSGis manifest file. Wouldn't it be great to automatically map this information? Luckily, somebody is already working on this: There is a Maven2 OSGi plugin hosted by Apache Felix, an open source OSGi implementation project. Unfortunately this currently seems to work only one way - to generate manifest information from the pom.xml. Developers who are used to implement Eclipse plugins and therefore like the tool support to maintain the dependency information in the manifest file will still have to find some solution how to sync this information.

OSGi and the JCP
OSGi and its concepts have already a long history in the Java Community Process: Already in 1999 the JSR-8 has been submitted in order to specify OSGi within the JCP. Out of some reason that was withdrawn and the OSGi Alliance did the specification on their own. Currently, there are the JSR-277 and the JSR-291 which address modularity and dependency management (JSR-277) resp. dynamic lifecycle management (JSR-291) for Java. While JSR-277 is trying to do something very similar as OSGi already offers, the Expert Group of JSR-291 has decided to fully adopt the OSGi specification a few weeks ago. It is therefore very likely that OSGi is going to be part of Java 7.

Summary
Whereever there is the need to modularize a complex system or to dynamically start/stop/replace single modules, OSGi is definitely worth a try. There are stable and mature implementations available like Equinox which builds the core of Eclipse, with which it is easy to start and to have some first results in a matter of a couple of hours. Having the JCP now embracing the OSGi specification, it is obvious that OSGi is a key concept for the future of Java in general.

TLAs around SOA - is it all just hype? (Part 3)

2007-07-01T17:23:00.001+02:00

Besides the rather negative impressions of JBI and BPEL (see parts 1 and 2), I also enjoyed a refreshingly positive session of Gregor Hohpe from Google about Event Driven Architectures (EDA). Having heard of them so far only in the context of SOA, I didn't expect much at all. Instead, Gregor presented a pragmatic example of how EDA can work - without any complicated containers, service infrastructure or anything like that - simply with pure Java. The core consisted out of one single class called "Channel" which allowed sending and subscribing events. On this he has built an application that is very loosely coupled as there are hardly any method invocations. Instead, all application flow is caused by the exchange of events. He pointed out some big benefits like the possibility to easily switch between two modules with the same functionality or even run them at the same time for test purposes. Furthermore it is possible to replay the event chain and therefore reproduce states from the past. And of course, this programming model makes logging as easy as with AOP (or even easier?) as all one needs is a class that subscribes and logs simply all events.
Certainly this approach is not applicable to any kind of problem, but it is definitely worth to be considered in many cases.

TLAs around SOA - is it all just hype? (Part 2)

2007-06-30T17:03:00.002+02:00

The next TLA - well here we have a rather a rare occation of a FLA - is BPEL. Reading sales brochures, BPEL is already used everywhere and the swiss army knife for your service orchestration. Talking to Tom Baeyens at breakfast, he pointed out that he is happy that nobody really yet succeeds with SOA, so his jPDL solution has had a good chance to spread without much competition. We seem to be on the right track with our proprietary tooling at Odyssey as nobody else really has anything much more sophisticated to offer, while suffering the same problems like not being able to factor out the technical details from the model used for the graphical designer. There is no good solution yet to easily exchange the technical part of the model by another one, e.g. for a different platform. This becomes very obvious when looking at the jBoss jBPM solution: Although using a common runtime platform, there are two designers for BPEL and jPDL that are completely independent from each other. Tom agreed that it is not feasible trying to have one graphical designer that can be used to create files for different execution languages. Therefore I don't feel so bad anymore about the fact that we didn't really manage to define a platform independent model (PIM) for the graphical designers of our in-house pageflow and workflow solutions. The current BPEL tools are meant to improve the communication between IT and business by allowing business people to sketch their ideas and have the developers fill out the details. From this moment on, the BPEL artifacts are read-only for the business to have a ground for discussion, but changes should only be done by developers. In our case, where we ship a default version of a diagram, the business consultants are supposed to specify the necessary customisations for a specific customer. Our goal is therefore even higher than the usual BPEL use case. Time will tell whether this is at all a feasible approach!

TLAs around SOA - is it all just hype? (Part 1)

2007-06-29T21:32:00.002+02:00

One expects of conferences that one is thrown at with all the latest TLAs. SOA being one of these for a while already and in the SOA context one also hears about things like ESB, EDA, JBI, SCA, BPEL and so on. Having tried to make any sense of these by reading magazines or listening to podcasts, I truely must admit that attending the TSSJS really helped me to get a clearer picture. E.g. it seems to me that one can forget about JBI - it is one of the technologies being speced and tried out in the real world only afterwards. Sadly however, the spec mainly aims at vendors, while they show no interest (only Sun backs it, while IBM and BEA stop their participation in the JSR). Trying to be yet-another-service-container, this mission is likely to fail and so I come to my personal conclusion that it's not worth the effort to dive into. Another clear sign for me was that none of the attendees of a JBI session was actually using JBI nor considering the use for the future...
Instead, SCA seems to have much stronger industry support, also being some kind of service container, but targeted rather towards the application developer than at the platform vendors. Nonetheless it is in its early stages and one will have to see how the adoption rate is going to look like.

Welcome to my blog

2007-06-28T23:41:00.000+02:00

To be a real geek, I would have had to have a blog already since quite some while - well, come to any conclusion that you prefer, but I am simply happy to now eventually share my thoughts with you online :-)
The trigger for me was being currently at The Server Side Java Symposium 2007 in Barcelona. It's a really great event and it's a great pleasure to meet all these great people here that one otherwise only know from their blogs, from an article in some magazines or from one of my favourite podcasts. It's really fun being a part of the community and therefore it becomes a real necessity to have a blog myself as well.
So please enjoy it, visit it regularly and leave your comments!