Coffee & Gems

OK, after I was daring enough to publish some predictions for 2007 , let's see how I did: The uptake of RoR will continue. JRuby will make a diffenrence and will allow RoR to make its way into the enterprises. Similar frameworks in other dynamic languages will rather help RoR than take away from it (Django, Grails, etc) because they will only increase the overall interest in dynamic languages. I'd say half-right. RoR's rise did continue, albeit with much lower pace. However, Django, Grails, etc did not make much of an impact. REST will become mainstream in the sense that it will not be considered the poor little relative of SOAP anymore, but a viable alternative even for the enterprisey guys. REST has become mega mainstream, up to the point that by now saying "SOAP" has become a bit of an embarrassment. Macs will continue to lead the pack in terms of innovation on the desktop. Uhm, yes. Neither Vista nor Leopard changed the world, so the distance between these com

I just realized that whenever I feel terribly tired there is an urge to post a video on this blog. Well, here we go. And merry christmas, everyone.

A small hint if you need a line feed in your Flex resource bundle property value: \n needs to be written as \\n Seems not very intuitive, but is logical when you think about how the strings get processed.

JRuby's Charles Nutter definitely has a great attitude. Check this out: For those of you playing with JRuby, if you run across benchmarks of any kind that show JRuby running slower than Ruby 1.8.x, we'd appreciate you filing them as bugs (from here )

I am very pleased to announce that viibee.com is online with a public beta version! viibee.com is a video-based dating platform that makes online dating fun again. Don't just take my word for it. Check it out and create a profile.

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

Yes! viibee.com the video-based dating site I am working on with a bunch of friends has entered friendly user tests. I am very happy to see this. If you want to get notified when we go live sign up here. Oh, we also wrote the Agile Dating Manifesto and some context to it in order to explain our ideas about online dating.

Just read this post from JRuby god Ola Bini which pointed to an older article by Paul Graham . Eloquently as ever, Paul explains his views that more clever guys use superior technology and therefore are likely to succeed in business (i.e. be more successful than the competition). During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a com

Currently, I am in the finishing stages of a Flex 2 project (actually a pet project of mine and 2 buddies). We have chosen to use Cairngorm for the client-side architecture. Generally, I am quite happy with this choice because it saved us from having to re-invent the wheel and it works quite well for us. But. At the beginning of the project we felt that Cairngorm introduces too much bureaucracy into our client-side architecture. It was simply too heavy for our needs (more like J2EE in 2001 than Ruby on Rails in 2007). So we stripped out two parts that we thought are adding unnecessary complications: The most annoying bit for us were the value objects (VOs). We already have a model and we have an event object. We simply had no reason to create another object for transporting data. If we want to pass a model object to the business delegate we simply pass this model. I we want to pass some very simple set of variables (say, a string and an integer) we simply add that into the event. No n

Recently, I have finished my first project using the Windows Presentation Foundation (which is, by the way, the best UI framework I ever worked with). One of the little things I had to accomplish was to integrate a Flash animation into a WPF UI . While there is some info on this on the Web I thought it might help if I post this C#-based example project for Visual Studio. For some background info I recommend Adam Nathan's " WPF Unleashed " which is an excellent book. btw: the backend was, of course, built on Rails. RESTFul and all that.

Over the Christmas holidays I finally had time to read the excellent report " Scrum and XP from the Trenches ". In it Henrik Kniberg describes in great detail how his company has implemented Scrum. Most notable is that he does not spare out the trails and errors they encountered along the way and also describes the problematic areas. One of them: testing. In Scrum you produce a release every, say, 3 weeks. The term "release" IMO implies that the software is tested (otherwise it might be just another build). In order to get that done you will need to code test-driven (well, duh, it's agile after all). That means: unit tests and back box tests. The latter are often much harder to implement and a pain to set up (so save some time at the beginning of your project to get the infrastructure right). But even then you might find that there is a remaining part of your system which you need to test manually. And that will be the same repetitive process every three weeks.