Monday, December 31, 2007

2007 predictions review and predictions for 2008

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 competitors stayed like it was before.

  • Location-based services have a chance to grow a lot. I expect a technology mish-mash of GPS, RFID, bar code readers on camera phones, etc. Nothing will be ready for the very big stage but we will see some trials.

    Yes, we've seen Google Maps on the iPhone and related stuff. LBS is gaining steam.

Right. Encouraged by this tremendous success of 3.5/4 I'll dare to do another round for 2008:

  • Android will turn out to be a nice platform for phone applications (nicer than Symbian and J2ME that is). However, it will not be able to change the rules of the mobile industry. But changing the rules is what the mobile industry needs in order to get some real innovation (see, partially, the iPhone). Therefore, I think that Apple will be the company pushing the envelope of the mobile industry in 2008 again. Not as much as 2007, though.

  • Adobe Air will create some initial interest and will serve as a starting point for other desktop/web integration technologies (like Mozilla's). However, Air's lasting impact will lie in increasing interest in Flex (which will see more developers in 2008).

  • In 2008 the social networking craze will continue. OpenSocial and the Facebook API will go head-to-head for the developer's minds and we will see more interesting applications emerge. At the same time we will find ways to monetize social network applications.

  • And here's a negative one: all efforts to bridge the PC and the TV to watch movies over the Internet will fail (once more). And that is despite of all the effort that is poured into this idea.


I'll be back in a year to check on these.

Friday, December 21, 2007

Saved by the bell (thank god it's christmas)

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.








Monday, December 10, 2007

Line feed in Flex ResourceBundle

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.

Friday, December 07, 2007

JRuby performance

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)

viibee.com in public beta!!!

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.

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: http://www.dilbert.com/comics/dilbert/archive/dilbert-20071126.html

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 dev.day.com. 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
Yikes!

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

  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

delegate.listUsers(params)

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

13949712720901ForOSX

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.

Wednesday, October 24, 2007

viibee.com is in friendly user tests

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.

Monday, September 24, 2007

Does the language really matter?

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 company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.


I agree with his conclusion that more clever guys will be more flexible in choosing their tools. But is it really true that this translates into business success? If so, how can it be that MySpace succeeded although it was (originally) built on ColdFusion (in 2003 I believe). How can it be that Facebook is rumored to be sold at 10 billion dollars while being built on PHP (I do not mean to diss PHP, but it is hardly a technology known for its extravagant cleverness)? Regarding the ColdFusion example above I read that MySpace chose this technology because they simply had a development team that happened to know it well (and thus was efficient enough at cranking out the code).

My take on this question is that the chosen technology just has to fit sufficiently well to the problem. If that is given the team that is more proficient in their technology will have the advantage.

Thursday, September 20, 2007

Slightly slimmed down Cairngorm

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 need for VOs in our case.
  • We use only one business delegate. This delegate encapsulates all available services. To be honest, I am not sure if Cairngorm is even meant to be implemented like this, but anyway, it saves us from creating a new delegate whenever we add a service. All we need to do is add a new method to our delegate.
So adding a new service boils down to
  • adding a method in the delegate and the controller respectively
  • creating a new event class
  • creating a new responder/command class
Even coming from a RoR background where DRY is the dogma we can live with that.

Thursday, May 31, 2007

WPF and Flash

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.

Thursday, January 04, 2007

Agile and testing

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. That's painful. I wonder how Kent intends us to do this. Any experience/opinions?