Announcement: radiantpostfixextension release 1.0

I have just released a new extension for Radiant. From the description:

With this Radiant extension you can manage a small Postfix virtual domain. A Postfix virtual domain allows you to forward e-mail to another e-mail address. The extensions adds a tab to the admin screens of Radiant in which you to enter the redirects. It also supports crude but effective aliases and mail-lists. In addition the Postfix configuration is verified and instructions will be displayed if something is not right.

Here is an screendump to see the effect.

The first release, boldly named 1.0, should work under Radiant 0.6.3 and up.

Please visit the Radiant Postfix Extension project home.

Update 2008-04-21: just released version 1.1 as a file had the wrong name.

Installing Maven under Mac OSX

Update 2008-03-28: Instead of following this article, you are probably better of with MacPorts. Thanks for the suggestion Nino!

I did not know it could be this hard to install Maven. I've installed Maven a bunch of times already but never before on a Mac. It took me about 1 hour!

Here is what you need to do:

• Download the apache-maven.tar.gz.
  If you follow the link on the maven download page both Firefox and Safari will get an html page but save it as a tar file. Look in the downloaded file (search for the string "apache-maven") and extract a real download link. When in doubt run md5 apache-maven-version.tar.gz on the result and compare it to the MD5 that is posted on the download page.
• Extract the tar somewhere. For example with tar xzf apache-maven-version.tar.gz. Here it gives an error (tar: A lone zero block at 3083) but so far it does not seem to affect the result.
  
• Ignore all the babbling about environment.plist files, and just create a ~/.bash_profile and put something like the following in it:
  export M2_HOME=/Users/erik/apps/apache-maven-2.0.8
export M2=$M2_HOME/bin
export JAVA_HOME=/Library/Java/Home/
export PATH=$PATH:$M2

That's it. Good luck!

Repeated lesson: always distrust 3th party code generators

Warning: rant follows!

I am usually try to avoid generation tools. But I fell for it again. I thought that using Wicket Web Beans would speed up development of the administration screens in my current project. Indeed, the first screens were shown very quickly. But a few weeks later, it did not turn out to be so smooth as expected.

Here are some of my pain points:

• You must explicitly exclude properties you do not want to see. So when you add the method boolean isPersisted() in the base class of all your entities, you must visit the meta data for each entity and add "-persisted".
• Writing new types of input fields for specific properties works, but is a little clumsy.
• I have no clue how to add validation. Especially when you consider the excellent vlidation support in Wicket has for this, it is kind weird that it is not clear how to do this with Wicket Web Beans.
• When you have a recursive data structure, Wicket Web Beans crashes during the render phase with a StackOverflowException!
• Somehow I failed to get custom input fields for collection properties.
  

Some positive points:

• Support is good though the wwb user e-mail list. Unfortunately, I failed to provide the correct input (which is source code) as we changed the code constantly in an attempt to work around to shortcomings mentioned above. Secondly I did not want to sent our domain objects to a public list.
• For simple domain models you are probably quickly set up and done.
  

Okay, we could have worked on Wicket Web Beans itself. After all it is open source. The code quality seems quite alright though I expect you need some time to get into it. Due to project dynamics and considering the excellent Wicket form support, I decided to pull out.

Unfortunately its now 2 days before the end of the sprint. So in 2 days we will shame ourselves in the demo before the customer with almost nothing working. Hopefully we can do better next week with regular Wicket forms.

Note: 'me too' comments are likely to be removed. I am also very interested in success stories!

Update, a couple of hours later: I reworded the article a bit as I found the first version too harsh.

I finally made up my mind

Those who read this blog more often may have noticed the minor change in the sub-title. It now reads:

Experiences from a hard core Java programmer that finally decided Ruby is a very very nice language, but rather stays on the JVM.

Compare it to the previous text:

Experiences from a hard core Java programmer that struggles with the question of switching to the world of Ruby and Ruby on Rails.

So how did I come to this conclusion? Here are some random considerations:

• I have only once in the last 2 years used Ruby professionally (to do some counting in a site dump).
• I do have 3 Ruby sites running (one Camping and two using Radiant). So I am not going to stop using Ruby anytime soon.
  
• ActiveRecord totally kicks ass and is hugely impressive. Rails for the rest not so much (totally old school request response based, with like JSP code in the templates). It may be just my lack of experience, so don't base your opinion on this.
  
• I am very addicted to correct refactoring and code completion.
  
• As I wrote before, we now have Scala.
• Update 2008-01-23: This one needs to be added. Since I recently became a father, it is simply too much to keep track of 2 worlds at the same time.
  

So if you expected me to be on amsterdam.rb right now, here is why.

GWT in action - Book review

I recently joined JTeam, a self declared GWT specialist. Of course I do not want to stay behind so I started reading GWT in Action.

That was a mistake. There is nothing wrong with GWT, I think it is a very nice component oriented technology in the spirit of Swing and Wicket, which makes it a lot easier to build very complex applications.

But back to the book. Reading the book is a lot like looking at an extremely knowledgeable professor. The kind of professors that know so much that they don't know where to begin. And like with the professor you will eventually get it if you hang on and are able to sort it all out in your head.
Well, I was fed up with it in chapter 5, half way through the 17 chapter book. Here are my mischiefs: 1) the text was constantly referring to chapters further away in the book, 2) it was continuously repeating itself (I had to read at least 4 times that it is okay to use something else then Eclipse), but worse, 3) the text was almost continuously on a different conceptual level then the reader could be. For example implementation details are mentioned (for example the event_bits attribute in the generated HTML) while they have nothing to do with making you understand the API (writing an event callback class). Or the other way around, at places where a simple examples would do wonders there is only some broad goal description.

Since there are many other books on GWT, you are probably better of with another one.

JRuby on Rails - Book review

So what do you put in a book on JRuby? After all, for the programmer JRuby is 'just' another Ruby implementation. The question must have come up when Ola Bini decided to write this book. The result is materialized in Practical JRuby on Rails Web 2.0 Projects - Bringing Ruby on Rails to the Java Platform. The title is well chosen and also answers the question: JRuby on Rails is a practical book; it guides you through the implementation of several Rails sites and along the way it shows you neat tricks that are only possible in JRuby.

Contents
The first half of the book is all about JRuby on Rails. If you already know Rails it is funny to consistently see jruby instead of ruby, but otherwise this is part is boring for the initiated. If you do not know Rails and like to learn from examples, this chapter is well worth your read.

Right after that is an interesting part for all us that want to mix Java and Ruby.

Later in the book, Ola goes through the trouble of explaining how to use JRuby with all the non interesting things in Java: session beans, message beans, JMX, XML processing and SOAP. I have been in Java business for 7 years and have been luckily able to avoid these for most of the time. The integration provided by Spring could have been a very nice replacement for these subjects.

A bit hidden between this stuff, the book again shows it practicality and goes through all the options of deploying JRuby on Rails applications.

The book ends with some convenient JRuby specific references.

Conclusion
I strongly recommend this book when you are a Java programmer (of any skill) that knows some Ruby and want to start working with (J)Ruby on Rails. If you know Rails well, but little Java and you want to start with JRuby on Rails, the book is probably too heavy and will teach you only a few useful things. Do not start on this book with zero Ruby knowledge. Though appendix A helps, for seriously learning Ruby, the old Pickaxe (dead tree version) is an excellent first read.

WebBeans, the JSF cover up

At JavaPolis I saw very good presentation on WebBeans by Bob Lee. Bob did a very good job in explaining the concepts while thankfully still giving lots of code examples. WebBeans provides a way to use ordinary Java beans in the JSF environment. You do this with annotations.

Praise for WebBeans, and its main predecessor Seam; they really make developing JSF applications simpler. In particular, the conversation scope is a brilliant invention. But how simple does it get? Well lets see. For every aspect that can be managed there is an annotation. In one of the presentation examples I counted about 5 lines of ordinary Java code plus at least 12 annotations! Now there are ways to group annotations, but you do this by introducing more annotations! So instead of having to deal with JSF stuff, you now how to cook annotation soup.

I have always hated JSP programming, and now that I see that even talented people like Bob Lee and Gavin King are wrestling to fix JSF, I finally know why. The problem is that the whole idea of having contexts to store page data is flawed. It breaks all kinds of encapsulation rules and breaks the beloved type safety.

So what are the alternatives? Actually there are a few very nice web frameworks that do not use contexts. The one I am most familiar with is Wicket. Another often named contender is Tapestry, but of course there are many more. Wicket, like Swing, uses a component tree to build pages. Each component is completely responsible for its own markup (html) and data (the model). No encapsulation rules are broken. Another addition is GWT, not exactly a web framework, but nevertheless useful for making componentized web applications.