Coffee & Gems

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.

See here: http://www.dilbert.com/comics/dilbert/archive/dilbert-20071126.html

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.

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 dev.day.com . If you are interested leave your email address there. I'll drop you a note when it goes live.

Two little anecdotes that happened within the last two weeks to me: 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. 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 buzzwo

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: 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. 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

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

On Monday I was adding some new functionality to viibee.com 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: There is a lot of repetitive wiring to be done 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 &qu

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.

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)

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 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 don