JavaBeans? Senseo pads!

Recently I have been getting my hands dirty with Adobe Flex. Now, let me just state for the record that I have never been fond of creating frontends. I find the bulk of traditional web programming mind numbingly boring. It never posed me with enough interesting challenges and the code-deploy-test cycle is very counterproductive. Come to think of it, that may very well be the reason why I never liked to create frontends: the feedback cycle was too long. I am the kind of guy who wants to see how my site looks like again once I add a mere button to it.

This does not mean that frontend design does not hold my interest, though. I always try my best to create an attractive, user-friendly site for my customers. However, in most cases we have to hire a web designer for a graphical design. I guess that’s okay, but I always felt I lacked an important skill.

Ever since AJAX introduced itself I found myself increasingly more interested into frontends. For the first time you were able to create user interactivity in web applications rivaling that of desktop applications. Even though AJAX was (and still is) a very exciting technology I still did not like the programming model much. Applications often evolve into a big unmaintainable mess of Javascript code. Rightfully so, a lot of AJAX guru’s and books emphasize on the fact that Javascript requires just as much structure and discipline as an object oriented language, like Java. I can’t disagree with them, but you have to admit that it’s a lot easier to make a mess of Javascript code. Due to the amount of freedom Javascript gives you it inherently requires more discipline to handle. The other thing I found lacking was a good set of UI widgets. DOJO has perhaps the best set.

During the course of this year two AJAX-like technologies gained momentum: Google Web Toolkit and Adobe Flex (strictly speaking I would not categorize Flex as an AJAX-based technology, but for the sake of argument I will). I have been experimenting with both technologies; recently I’m using GWT in a project, but mostly I have been playing around with Flex in a pet project. I don’t feel comfortable comparing the two just yet, but I do know that I am very excited about Flex and it’s not in my personality to get excited quickly. I have read a lot on Flex and seen some presentations on it. One thing I quickly noticed is that Adobe really thought this technology through. They didn’t just jump on the bandwagon; no, they took their time, thought things through and created their own programming model focused on user interactivity.

Flex applications run on the Flash player, which ~98% of the internet users have installed. Its programming model is based on MXML and Actionscript 3.0. You can think of MXML as a declarative domain specific language focused on constructing UI’s. It is based on XML that eventually translates down to Actionscript 3.0. I find MXML to be an elegant way of creating UI’s. The code is compact, easy to read and expressive. Actionscript completes it nicely with a way to program any logic that needs to happen. Flex is actually a pretty substantial framework. Not only does it provide you with a lot of cool and useful widgets, it also provides you with the means to connect to a backend written in an entirely different language (e.g. Java) through Flex Data Services. Be it an HTTP service, a Web service or RPC calls. I probably should also mention Flex Builder. It is an IDE specifically targeted to writing Flex applications. Flex Builder is a great asset for building Flex applications as it is quite sophisticated. It provides auto-completion, code assistance and an extremely helpful visual editor. You can actually drag&drop your application together without making a mess of your code. I can go on and on about what Flex has to offer, but I think you get the picture.

I just started programming a real-world application with it and so far the experience has been a blast. I look forward to sharing more of my experiences on Flex in the future.

In one of my latest posts I talked about my enthusiasm on the new Eclipse release. I was especially enthusiastic about the new plugins, such as Mylyn and Spring IDE 2.0. I really believe that good plugins help an IDE become even greater than it already is. Especially with the diversity of technologies that we have available these days I thought the fight between IDE’s would be won over plugins. So, I proceeded to give Eclipse the benefit of the doubt (again).

Well, after trying to use Eclipse in my daily development work, I quickly reached a point where I could not take it anymore. I admit that I am very quick to discard a tool if it does not provide me with a good level of usability. However, because I had tried Eclipse a couple of times in the past I kind of knew what to expect. Therefore, I decided to keep an open mind and follow Eclipse’s concepts and usage this time.

What caused me to revert back to IntelliJ IDEA is the sheer complexity of Eclipse’s interface. Somehow, by leaning on the plugin model as much as Eclipse does, there seems to be a lack of consistency in layout, configuration and usage. One of the plugins is used by opening a perspective, the second one by switching to a different view and the third one through the context menu. I found myself searching for plugins and switching between views/perspectives so much that I was distracted from my work.

The final straw was trying to a) define a web application project and b) trying to deploy it to Tomcat. I just could not do it within a respectable 10 minutes. If I try to do this in IntelliJ, everything just fits. It asks me for all relevant information in a structured manner and produces the exact same behaviour as I expected.

I don’t know, maybe I am complaining too much or not spending enough time to get to know Eclipse. But when you think about it: an IDE is such an important tool in a developer’s toolset that the experience should be as smooth as possible. IntelliJ did, and still does, give me that experience. Don’t get me wrong, I admire the Eclipse Foundation for the amazing work it has done. Even though Eclipse does not satisfy my needs, it sure does for a lot of other people.

Too bad, because I really like some of Eclipse’s plugins. I wish JetBrains would catch up…

Last Thursday (July 5th), I was one of the lucky ones to attend a Domain-Driven Design session by Eric Evans. This session was hosted by Interface21 and took place in the Lloyd Hotel in Amsterdam.

Some of the topics of discussion were:

• What does it actually mean to have a model?
• What makes a good model?
• How do you arrive at a good model?
• How do you identify the relationships between different teams/systems?

Because the session was on an invitation-basis only, the group consisted entirely of experienced architects and developers. The result was a highly interactive session where everyone shared their experiences in applying DDD in the real world. I have read Eric’s book on DDD about 1,5 years ago and liked it a lot. It’s an interesting read and I recommend it to anyone who is interested in DDD. However, it’s one thing to read from a book, but actually hearing the author and fellow developers talk about it is an entirely different experience. It provided me with a lot more insight.

Some of the statements that stuck with me where:

• A model is an approximation, not an exact representation of the real world
• A model is never static; it keeps evolving over time.
• Trying to model the customer’s domain “right” the first time points to ignorance. At the kickoff of a project neither you or the customer has a clear idea yet on what the model should be. Next to that, requirements change over time and along with it the model should too. Even if the requirements do not change, a better understanding of the business during development may result in re-expressing some concepts in the model.
• Do not try to use DDD if it does not fit or lacks the appropriate resources. For example, if a domain expert is not available, don’t try to force DDD anyway.
• Leave the model open for implementation choices. Do not over-constrain your model. However, do not under-constrain it either.

Bram Smeets, a colleague of mine, has met Eric a couple of times and told me that one of the things he noticed about Eric is that he is a genuine nice guy. After having attended this session I have to agree with him. Even though he is recognized as the expert on DDD, he remains a down-to-earth guy with a very friendly attitude.

In conclusion, the session was excellent and I’d like to thank both Eric Evans and Interface21 for it.

I’ve never been a big fan of Eclipse. There was always something about it that made my skin crawl. It never reached the same level of usability of IntelliJ IDEA.

But now I have to admit that for the first time in my career I actually anticipated the release of a piece of software. I am even “ashamed” to say that I actually count down the hours and minutes of the official Eclipse Europa release. The main reason why I chose to give Eclipse a try for the fifth time is because of the great plugins that were released with it, one of them being Mylyn. I tried Mylyn out today and I have to say…I’m impressed. Of course, there are some minor bugs in it, but overall it works like a charm. It will take me some time to get used to the Task-Focused UI, but I can already see its benefits.

The main features I like about it are the integration with our issue tracker JIRA, task contexts and scheduling. When you think about it, it makes sense to view and manage your project’s issues inside your IDE. I mean, your code is right in front of you, why would you want to switch out of that mindset and use a web browser to visit your (sometimes slow and unhandy) issue tracker site and see what you’re supposed to do today?

But that’s not the great thing about Mylyn; it’s the task contexts that make a huge change in the way you work. When you start working on a task your package explorer immediately filters out everything that you don’t need. If you need to fix a bug in the Foo class, you only see the Foo class. Need to refactor a piece of Foo’s functionality to the Bar class? No problem, it will automatically be added to your task context. To top it all off, you can actually share your task context with your team. That means if I don’t have the time to finish a task, my colleague can take it over and immediately see what he’s supposed to focus on. Want to commit your changes to your version control system? No problem, Mylyn will group the changes you made to your classes per task. In effect, this makes it very clear to see what changes were made for each task.

I still have to work with Mylyn in a real-world project, but I think the chances are big that I will keep using it.

Database clusters are not that uncommon these days. Often, the reasons for using one have to do with fail-over and load balancing. Many database vendors have this in mind and provide some sort of support for it in their product. This support varies from a full-blown database cluster like Oracle RAC to data replication used by, for example, MySQL.

Business clients of a small to medium scale simply can not afford a solution like Oracle RAC and therefore often resort to data replication. And there’s nothing wrong with that choice. In many cases it suits the business’ needs. However, things get a little bit more complicated when the client wants an application that writes at roughly the same frequency as it reads from the database. Add the requirement of being able to instantly see the result of a write operation, but all the while being highly performant, you’ll quickly realize that data replication isn’t an option. So, if you can’t rely on the support your database gives you, you need to find a different solution.

Surprisingly, there are not a lot of options available in the Java Open Source enterprise market. Basically, your choice boils down to either Sequoia or HA-JDBC. Sequoia has been around a while and appears to have matured a bit. HA-JDBC is relatively new, but has an impressive list of features. Recently (well actually, almost a year back now), I had the opportunity of using HA-JDBC in a project for one of my clients. That experience was definitely not a picnic…

The problem with HA-JDBC isn’t the product itself, but rather the lack of good documentation and examples and especially the sheer complexity of JGroups. Let me tell you…JGroups is a great library…when you finally get it to work. The configuration of a JGroups stack it is just ridiculous. It is so low-level that I doubt a network engineer can fully understand it. It has you dealing with so many foreign protocols and settings that I seriously doubt it is meant for a developer to configure. Recently HA-JDBC released its second release candidate and along with it an upgrade of its dependency on JGroups. Still, there remains to be a serious lack of good examples on how to use HA-JDBC in combination with JGroups.

Therefore I decided to create some sample configuration for anyone else who is having trouble with this. The .zip file contains 2 files:

• HA-JDBC configuration file
• JGroups protocol stack configuration

The HA-JDBC configuration file defines the database cluster, synchronisation strategies and a reference to a JGroups configuration file. This file is pretty straightforward and self-explanatory. The JGroups protocol stack configuration defines an example TCP stack. This is the only stack type I got working so far, but I might add more stacks later if I get more insight into JGroups. The files themselves contain more information.

Download the example configuration of a HA-JDBC database cluster in combination with JGroups

Leave a comment if you have any questions on either HA-JDBC or JGroups. I would not call myself an expert just yet, but I’ve played around with both products long enough to know their quirks