Monday, November 26, 2007

SOA in a great video

OK, it's Monday but I worked all weekend so it sure feels like Friday. That's why I could not resist posting this video (made by the Singapore Media Development Authority). Note that SOA has finally arrived where it seems to belong (or come from?): right in the middle of a big marketing blurb.

Agile methods as explained by Dilbert (in case you missed it)

See here:

Monday, November 19, 2007

Cairngorm should take a lesson from Rails, revisited

Regarding the post Cairngorm should take a lesson from Rails from a while ago:

I just stumbled across Cairngen. It is a code generator that produces skeleton classes (events, commands, etc) through an Ant script. Much like Rails' scaffolding feature this might help a lot to get you started with a project, but I still believe that it i just a patch to work around the real issue. We simply should not have to write this boiler plate code at all.

Friday, November 16, 2007

New job

I've taken up a new opportunity that I pursue part-time: Technical Evangelist for Day. This is all about Java Content Repositories. It's great because it is a natural succession of my background in CMSs and Java EE. Moreover, getting to work with guys like David Nuescheler and Roy Fielding is not so bad either :)

My first task is to build up Day's new developer portal If you are interested leave your email address there. I'll drop you a note when it goes live.

Monday, November 12, 2007

REST is the new SOAP (in a bad sense)

Two little anecdotes that happened within the last two weeks to me:
  1. A buddy and I discuss how ...(something)... could be implemented, we find a solution, but we cannot do it that way, because he's afraid that the developers supposed to implement it will not find it RESTful enough.
  2. Another buddy is told by his CTO to implement a REST interface in his Rails app because that would render the controller's code cleaner (or some similarly daft idea). By the way, there was no business need to do an external XML-based interface other than "REST is cool".
If the idea that something should be RESTful gets into the way of getting things done and if things thought to be RESTful are done for the sake of it, well, then REST has become the new dogma. In this sense it is the rightful heir of SOAP and SOA (and it is the the flavour of the year for 2008).
You might also want to look at Roy Fielding's presentation at Railsconf (p.28):
and REST(ful) became the next industry buzzword

Friday, November 09, 2007

The social enterprise

Alex Iskold has written a post on the "social enterprise" where he evangelizes the use of wikis, blogs, etc in enterprises. I am (of course?) all in favor for that. But the way Alex describes "enterprises" and the way they work seems at least partially wrong to me: what Alex describes does not apply to the large corporation I have insight in. Two things:
  1. Large corporations are not organized in a top-down, hierarchical fashion, where communication is required to bubble up the chain of command and down in another department. Rather, they are organized in a matrix fashion, where the project hierarchy and the line hierarchy are intermingled and therefore communication is intermingled as well.
  2. There is not a lack of communication. If anything, there is an overflow. Workers in large corporations are scared to come back from holiday, because they know their email inbox will contain several hundred emails. So the issue is the necessary amount of communication.
Again, wikis and blogs are fine. I use them all the time and could not work without them anymore. But, wikis and blogs are not able to address another problem of knowledge management in corporations: lack of time to write things down that are not absolutely necessary to be written down. I doubt that tools can solve this problem.

EJB 2.1

Today, I threw my EJB (2.1) book Professional EJB onto the dump. I do not think I will miss it.

Thursday, November 08, 2007

Cairngorm should take a lesson from Rails

On Monday I was adding some new functionality to and it occurred to me how tedious it is to do that kind of stuff within Cairngorm. Just like DHH calls it: "XML sit-ups" (though it's not XML, but the sit-ups are the same).
The problem is:

  1. There is a lot of repetitive wiring to be done
  2. In our situation, where all client-server interactions follow the same pattern, one interaction could safely be deduced from a minimum of information.
For example: let's say I want to create the new "list users" functionality. I need to create a "list users" event, wire this event into the controller so that it fires up the "list users" command, create a method "list users" in the delegate, define "list users" in services.xml and, finally, code the "list users" command. And the same for "add user", "delete user" etc. You get the picture.

I think that Cairngorm should have a drink from RoR's "convention over configuration" cool-aid. How could this work?

Suppose you fire the event

new CairngormEvent("list_users", [rest params])

You do not have to define this event type. By convention, the controller will execute the ListUsersCommand. This ListUsersCommand is the piece you actually have to implement. Within ListUserCommand's execute method you call the delegate as usual. But, you should not have to define, what the delegate is supposed to do. Something like


should suffice. The delegate knows that the method "listUsers" translates into "/list/users" and dispatches the request onto its default server. The parameters are mapped onto CGI-style parameters, potentially converting camel-case into underscore_case. The response will automatically be sent to the command.

Of course, one should be able to overwrite, i.e. explicitly define the default behavior. But that can be done already.

Maybe, I am biased because in our project all client-server interaction is rather uniform, but I can well imagine that others go through the same kind of repetitive exercise. IMO this would be a worthwhile update to Cairngorm.

Tuesday, November 06, 2007

I like statically typed languages

I had to refactor viibee's internal structure of how we handle locations and was so glad that ActionScript is statically typed. Otherwise, I would have freaked. So, to my surprise, I must confess that I like statically typed languages.

Duck typing may be the latest craze, but right now I do wonder why it sometimes works so well.

Maybe it works OK in Rails because the amount of code one writes is typically less (so refactoring by hand is usually doable) and the structure is given (so you know where to look), plus you can use tests, of course. I guess in Rails the feedback one can get from tests and quickly running the app is almost as quick as what my Flex compiler tells me.

Monday, November 05, 2007


Hey, Apple, it's time to get your act together and release Java 6 on OSX.

(Dear Reader, if you are confused about the title, see here)

Android announced

Marc Hedlund makes a nice point on Google's Android and the iPhone:

It's remarkable to see Apple once again in the position of selling a whole-stack platform (software and hardware, at least -- network sold separately), competing with a broad coalition of commodity hardware companies using a common software platform. I think they'll repeat history -- they are already repeating history -- by not doing whatever they can to bring developers to their platform.

Sounds intriguing, but I see one possible difference: in the PC world there is pressure to do what your peers do in order to swap software. In the mobile world this has not happened, yet, and maybe never will. The peer pressure in the mobile world, if any, is to keep up with the user experience of your peer's mobile. So maybe the comparison above does not apply.

Flex client-server data exchange

Flex programming is much like classic client-server stuff (at least, compared to a web app). So, here's a challenge we faced when designing viibee:

The user modifies data on the client and these mutations shall, of course, propagate to the server. The question is: shall the data be modified locally (on the client) before the server received the changes or shall the client modify the data only after the server has persisted the changes? Let's call these two scenarios "optimistic" and "pessimistic", respectively.

In the pessimistic model there is less chance of an inconsistency of the data between server and client. Also, the user can always be sure that his changes have really been persisted. But you loose a lot of responsiveness of the UI (and this is why you chose to do a RIA, isn't it?).

In the optimistic model you have a much more responsive UI. But you might need to implement certain logic twice, especially some data validation will have to be done on the client and maybe on the server again. Plus, you will have to handle the case that errors occur on the server.

We thought of the pessimistic model as a "banking app" and the optimistic model as "GMail". Interestingly enough, Adobe has described the optimistic model here and describe it in terms of a banking application.

In the end, we have chosen the optimistic model and have not looked back so far.