Monday, December 17, 2007

Job hunting is like dating

Paul Buchheit posted an interesting analysis of social networking products, their similarities and differences. In there he has hidden a rare gem:

10. Jobs. Job hunting and hiring are essentially the "professional" analog of dating and seem to work in somewhat similar ways.
Shaking Hands, by Aidan Jones

If you ponder it a bit, it sounds about right, doesn't it? People look for jobs they like and hiring managers look for candidates they like. When there is a match, there is a hire. The parallels are many:
  • Dumping/seduction: an employee will dump his current job for a better one, often due to seducing promises from their hiring manager.
  • Bachelorhood/marriage: some people change jobs like crazy (especially in the States), while others stick to one for life (quite common in Japan).
  • Stagnation: employment relationships, like sexual ones, tend to stagnate after a long period of time, when people lose interest in it.
  • We might as well admit it, women and work are the two dominant discussion subjects with one's friends, after midnight.
  • When one gets caught cheating on his wife/company, they go to court.
  • Girls have breasts, jobs have salaries. The bigger, the better.
  • People get jealous of their friends who make more money than they do.
Now, what does that mean for us? Are you happy with your current girlfr..., er, job? If not, could you perhaps find some new project / technology / tool / sexual position to stimulate your interest? Or is it perhaps time to be on the market again?

Sunday, December 9, 2007

How programming languages grow

Q: How do programming languages grow?
A: With pain.

Unless you were lost on a deserted island far away from civilization, you must have heard something about the ECMAScript v4 shenanigans. ECMAScript 4 is the future standard specification for what most people will undoubtedly refer to as JavaScript 2. This forthcoming specification brings a whole slew of features into the JavaScript language, about a decade after the current ECMAScript 3 standard came out. Many of the new features are about facilitating the creation of large programs in the language and improving their safety and robustness. As an intentional side-effect, they maintain and improve the syntactic similarity between JavaScript and Java, so that most young programmers will find it easy to learn and use (in case you didn't know, Java is one of the languages students learn in almost every CS curriculum nowadays).

The breadth of the changes as well as the increased similarity to Java has led some people to protest against them, while they portray the future of their beloved language with gloom and doom. Some members of the ECMAScript standardization committee decided to get off the standardization effort and pursue an ECMAScript v3.1, that is much less ambitious in scope, though still quite vague. These members are Microsoft and Douglas Crockford and while Redmond's move has set off the (usually correct) conspiracy reflexes of the community, Crockford's objections carry more weight to those who pay attention.

Doug Crockford has been known for many things in the JavaScript community, but what I respect most is his simplified JavaScript parser, which is itself written in the same simplified JavaScript. This is the second JavaScript parser in JavaScript that I'm aware of, the first being Brendan Eich's Narcissus. This subset of JavaScript that Crockford advocates for (and is still available in the ECMAScript 4 specification) prefers a more functional style of programming with heavy use of prototypal inheritance, compared to the traditional object-oriented style used in Java and proposed for ECMAScript 4. To cut a long story short, the creator of JavaScript convincingly makes the point that JavaScript must evolve if it is to keep up with the needs of its users, otherwise they will pick something else, like Silverlight or Flex.

In that presentation, Brendan Eich makes a reference to a talk given by Guy Steele in 1998, titled "Growing a Language". It was about the time that the Java community was having a debate about adding generics, operator overloading, complex numbers and other features. In the end some of the proposed changes made it to the standard, like generics, while others like operator overloading, did not. Today another debate is raging in the Java community, about adding closures to the language. Though perhaps less emotional than the JavaScript debate, it is still highly divisive and the reactions are occasionally overboard. It seems changing a language always involves fear, anxiety and pain. Guy Steele's talk provides some insights.

Its been about a decade since that talk, and it shows. No Powerpoint/Keynote slides, just hand-written ones manually placed on the projector. Even the haircut is out of fashion. However the actual presentation is sheer genius. Steele uses the form of his talk to illustrate the point of his argument. In order to demonstrate the difference between small languages and big languages in terms of the programs they can create and the difficulty of their use, he picks a subset of English as a given, all words with one syllable, and every time he needs to use another word he provides a definition. In the same way you provide a class definition of a Person in Java and then go on talking about that person in your business code as if it was a language primitive, Steele makes a talk sound like a computer program and as he confesses in the end, creating that talk was a lot like writing a program.

It may seem weird at first, but as you get the hang of it, it's an eye-opener. Not suitable for computer-language illiterate people of course. Your girlfriend definitely ain't gonna like it. Even the jokes are kinda geeky. Just watch it when you have an hour to spare and nobody is watching you. Then perhaps you might be able to understand Brendan Eich's passion. And do the right thing: use Firefox.

Monday, November 19, 2007

About Macs

If I hear one more time how Macs are expensive and just for fashion victims, I'll throw up. This urban myth keeps coming up for so long, that it's not really funny any more. These two statements that Macs are a) expensive and b) merely a fashion statement, are so easily debunked if one cares to look objectively for the truth that it's mind-boggling to see them come around so often. From personal experience, the (a) above is a farce. It is most ironic, that I mainly hear this from people who spend quite a lot on computers and tech gadgets in general. Like they are quite happy to shell out hundreds of euros for doubtful upgrades on PC hardware and assorted gizmos, but when contemplating a different platform altogether they become Ebenezer Scrooge.

When I picked a locally-assembled PC with Ubuntu for my desktop at work, I did it for two reasons. First, to save a little extra cash, since the budget was low and second, to keep up with developments on FLOSS desktops in general, since I already had a Mac at home. Both systems would work equally well for what I do at work. Now, the purchase savings from getting the PC, amounted to what I cost the company per day. Having spent about a day fiddling with driver's and software that was not readily available through synaptic (that was in Edgy if memory serves), that advantage was gone. I pretty much knew this was going to happen from the start. However, the second reason still holds. I believe that the inevitable progress in FLOSS desktop systems is eventually going to make proprietary products pointlessly expensive. Ubuntu's polish in each new version attests to this. However we are not there yet.

The "fashion" argument (b) is even worse. It might have had some merit in the nineties, when Apple was floundering and targeted mainly the publishing and multimedia markets, but as anyone can see today things have changed. Are all the Mac-carrying uber-hackers in large conferences fashion victims? Really? Those guys with the pony-tails, beards, glasses, t-shirts, shorts and slippers? Funny how they don't seem to spend much on clothes.

Actually, what people like Yakov Fain are really afraid of, is change. And that's perfectly OK. I'm afraid of change, too. Otherwise I might have moved already. Or changed jobs. Or get divorced. Um, nope, scratch that one. It's just that, occasionally, I do manage to build up the courage to face something foreign and exotic and learn to live with it. And sometimes even learn to like it. For someone like Fain who has spent most of his time in the Windows world, every other world will appear difficult to learn. I have a friend (hi George!) whose first computer was a SPARCstation. When he started using Windows, years later, the experience seemed weird and clunky. It's the same thing, only on the flip side of the coin.

Also, Mark Pilgrim's latest mocking of MySQL installation on Mac OS X while hilarious (which is why I like his blog), is unfair. Sam Ruby's too. Installing or upgrading MySQL on OS X is just a matter of getting the package from the vendor's site and launching it, not compiling from sources. The fact that there might be no package yet for Leopard or that the current package does not function well on it is utterly irrelevant. It will be fixed. Ubuntu is no different. I updated Firefox on my Mac at home the day was shipped, yet one week later my Ubuntu box at work is still at Of course, it will be fixed.

This is what you lose with centralized package repositories, in order to gain consistency and ease of upgrading. I'm no stranger to this kind of thing, having used FreeBSD and Linux as my main desktop for many years now. If you think installing things in Ubuntu is always as easy as launching Synaptic, try to use Skype on amd64. Or Flash and Adobe Reader pre-Gutsy. I'm quite used to watching compiler output scroll for hours so all of it was a walk in the park for me, but I can imagine how it might have been frustrating for someone less experienced. Ubuntu's (and FreeBSD's, Fedora's, etc.) advantage over the Mac is when installing something not packaged specifically for OS X by the vendor, like mutt or nmap. That is where the value of a community-maintained repository shines. Of course you can use MacPorts / Fink / pkgsrc / whatever, but they are not integrated into the system, so you merely moved the goal post a little further.

As a parting thought, I have a confession to make: I'd love to work with this guy. Interacting with human beings requires a set of skills that not many people in the technology world can brag about. Understanding how humans work and what makes them tickle is fundamentally different than being an expert with machines and software. Michael Lopp is an engineering manager at Apple. It figures, I guess.

Friday, November 2, 2007

GWT and animation effects

I've already praised GWT and its highly productive environment for generating AJAX applications. I've been using it in my Very Cool Project with great pleasure, I must confess. Creating a highly interactive web application, brings back some of the entertaining aspects of programming again. Although, to be honest, it would have been nice to get rid of all those anonymous inner functions I find myself dealing with. Life (and code) would be a lot simpler with closures and higher order functions. Sometimes I find it ironic that GWT translates my anonymous-inner-classes-using code to JavaScript code with closures, higher order functions and all the other goodies. Apparently, a change of perspective is always an eye-opener.

My nagging aside, GWT is an enormous leap over other solutions for interactive web applications in Java. However, one area that has received little attention so far, is support for animation effects. The stuff that puts the candy in eye-candy. Certainly, there is always the option to use other JavaScript libraries that provide such effects through JSNI, like Scriptaculous, YUI, Ext JS and others. But that is not an efficient nor elegant way to do it. Memory leaks may creep up (particularly on Internet Explorer), separate download requests for the other scripts must be made and JSNI references are, er, how should I put it, um, chatty?

A better way involves using a GWT wrapper around the external effects JavaScript library. This way you get to reap the usual benefits of GWT, namely the minimum number of roundtrips to the server, compilation of just the code you need (the effects you actually use) and no detour to JavaScript-land (though lately I'm having second-thoughts about the goodness of this). The main solutions that have emerged so far are various Scriptaculous wrappers, an ext wrapper and gwt-fx.

I've tried both one Scriptaculous wrapper and the gwt-fx codebase and I would wholeheartedly recommend the latter. For starters, it feels like things are done "the GWT way": a single EffectPanel to decorate the widget that will be animated, separate effect classes for the most popular effects, sequential and parallel combinations of effects, deferred binding for browser-specific functionality, Listeners and Adapters and much more. Implementing a fade effect took me about 10 lines of Java code. And we all know Java is not the most succinct girl in town, right? Furthermore, while the Scriptaculous solution worked on IE, Firefox and Opera, it would barf on Safari (version 2 if you must know). gwt-fx worked on all of them without any special-casing in my code.

Also, when things don't work as expected, the author, Adam Tacy, is very cooperative and helpful. He has endured a flood of patches from me to solve some problems that I encountered, and when not satisfied with them, he implemented even better solutions after careful consideration and thoughtful reasoning. Just make sure to get the latest version (1.0.0) that has every bug I encountered so far, fixed.

Adding a supported effects library in the main GWT distribution has been discussed a few times on the contributors list, but apparently it is not a high priority task at the moment. For a good reason I might add, since the release of GWT 1.5 is just around the corner, with support for Java 5 and a whole slew of compiler optimizations. However, with the recent introduction of the GWT incubator project it might be appropriate to start trying out some design ideas on such a library and see how it goes. If you care for such an outcome, don't hesitate to let the GWT developers know about it, by joining the discussion in the recent thread on the subject.

Tuesday, September 4, 2007

An exceptional interview

My friend Alfred was in a job interview the other day, with a guy named Quincy. It was for a Java programming gig and they were apparently getting too many resumes, so they sat him down with a paper and a pen and asked various questions in order to determine his skills. I hear it is very trendy nowadays, all the cool kids are doing it. After a lot of rather boring, Java-for-dummies kind of stuff, he was given a paper with something more-or-like the following code printed on it:

public String getSomething(String one, Object two, Integer three) {
if (one != null) {
if (two != null) {
if (three != null) {
String result = reallyGetSomething(one, two, three);
doSomethingMore(one, two);
return result;
} else throw new ObjectNotDefinedException("three is undefined");
} else throw new IllegalArgumentException("two is not legal");
} else throw new NullPointerException("one is null");

After taking a few moments to read the code, Quincy started firing away:

Q: What is wrong with this method?
A: Lot's of things.

Q: You mean more than one?
A: Of course. The most obvious mistake is that the method does not declare that it can throw ObjectNotDefinedException.

Q: Yep, that's right. Is there anything else?
A: Sure. That's the easy part that the compiler can tell you right away. Furthermore, the method is needlessly complex and has a questionable API.

Q: Really?
A: Sure, the order the null checks are in, force the indentation to increase, making the code difficult to follow. Moreover, if doSomethingMore() and reallyGetSomething() do not modify their parameters and have no side-effects that require this particular ordering, they could be swapped, saving one line:

public String getSomething(String one, Object two, Integer three)
throws ObjectNotDefinedException {
// Validate.
if (one == null)
throw new NullPointerException("one is null");
if (two == null)
throw new IllegalArgumentException("two is not legal");
if (three == null)
throw new ObjectNotDefinedException("three is undefined");

// Do the actual work.
doSomethingMore(one, two);
return reallyGetSomething(one, two, three);

Q: OK, now what's wrong with the API?
A: Check out the exceptions the method throws back to the caller.

Q: What about them?
A: Only one of them, ObjectNotDefinedException, is a checked exception that would give the caller a chance to react to such an anomaly. The others are unchecked exceptions that will bubble up the call stack and probably blow up in the users face.

Q: Well, perhaps the API designer wanted to differentiate the handling of the three error cases.
A: Perhaps, that's why I said "questionable". But looking at the similarities in the way the method handles its parameters, that would be hard to believe, don't you think?

Q: I'll ask the questions.

Then, after a bit of fiddling with the internals of his briefcase, Quincy presented another sheet of paper with the following printed code listing:

public class ThrowNull {

public static void main(String[] args) {

public static String getFluff(String name) {
if (name == null)
throw new NullPointerException("BOOM!");
return "Fluff: "+name;

public static String getStuff(String name) {
if (name == null)
throw null;
return "Stuff: "+name;

Alfred was given a few moments to digest it and then Quincy went on:

Q: What does the program print?
A: That's easy. It prints nothing. At least, nothing useful. It throws a NullPointerException since the caller of getFluff() is null.

Q: Why does getFluff() throw an NPE if the name parameter is null?
A: I suppose the getFluff() API designer considered that it's the caller's job to make sure it is not called with a null argument. He should have put that in the javadoc, though. You do write javadoc comments don't you?

Q: I'll ask the questions. What will the program output if we change the first println() in main to

A: It's not much of a change. The line "Fluff: bad" will be printed, followed by a new NullPointerException.

Q: So the "throw null" syntax is legal?
A: Hell yeah! Even Neal Gafter is using it.

Q: Which way of throwing an NPE is better?
A: Better in what way?

Q: I'll ask the questions.
A: Well, each one has its merits. The first form is more explicit and traditional, but longer. The second is more succinct and closer to the natural language, but cryptic to newcomers.

Q: So what would you recommend that we use?
A: Does that mean I got the job?

Q: I'll ask the questions.
A: Well, I kinda like the short, concise form, but I don't feel particularly strong about it.

Q: Good answer, because we picked the other one after a three-hour long debate last week.
A: You mean you were debating about ways to throw a NullPointerException for three hours?

Q: Yeah, why?
A: Don't you have real work to do?

Q: I'll ask the questions.

I don't believe Alfred has heard back from them ever since.

I'm actually glad about it.

Thursday, August 30, 2007

The case of the disappeared Exception message in GWT RPC

Regular readers of this blog (both of you) will remember my recent love confession for GWT. While I am glad to say that my feelings have not changed one bit, like all maturing relationships, we are getting more intimately familiar with one another. To the point where you know things about your significant other that you'd rather never found out. And since I know there are many others with feelings for GWT, I thought I'd give you a tip or two, in case you want to make a pass.

In my previous post I didn't elaborate on the marvelous feature of GWT RPC. The RPC feature gives your GWT client the ability to communicate with your Java-based backend in a very powerful, yet painless, way. I still plan to discuss it more thoroughly in a future post, but for now I'd like to mention a particular bug (or feature) of the current implementation.

The RPC mechanism allows a client to make a Remote Procedure Call to the server supplying the necessary call parameters and getting back the results. Quite often (as it turns out) the server will encounter an exceptional condition during the execution of this call and will throw an exception to the caller. Luckily an Exception in Java contains a detailed message about the problem encountered (or more accurately its ancestor, Throwable) that the client can rely upon to present the situation to the user. To give an example, you could have an Exception class EarthShatteringException like the following:

public EarthShatteringException extends Exception implements Serializable {

private static final long serialVersionUID = 1L;

EarthShatteringException() {

EarthShatteringException(String message) {

EarthShatteringException(Throwable cause) {

EarthShatteringException(String message, Throwable cause) {
super(message, cause);


This is pretty much elementary stuff, you extend the base Exception class and also implement the Serializable interface, in order to give GWT a chance to convert your exception object to tiny little bits, transmit them over the wire and recreate the object on the client. So the way you actually throw such an exception on your server might be something like the following:

public void doGreatStuff() throws EarthShatteringException {
if (something.isWrong())
throw new EarthShatteringException("God help us!");

On the client you deal with the exception in a callback function you provide, called onFailure:

public void onFailure(Throwable caught) {

In this example we just display the message contained in the exception to the user.

At least that's what you would expect. In fact, what this code will do in GWT 1.4.60 (the latest release as of this writing) is display the string null.

How could that be you say? I'm glad you asked.

Serialization in GWT is a little different than in the rest of Javaland. This is because the client in runtime is actually JavaScript code, compiled from our original Java code by the miraculous GWT compiler. The compiler uses its own private implementation of the standard Java class libraries, that implements a quite large, but still limited subset of it. In our particular case the implementation of the Throwable class does not implement the Serializable interface and the side effects that entails.

So when our exception gets transmitted over to the client, what gets instantiated is an EarthShatteringException type, but its supertypes are not serialized (hence transmitted) themselves. Therefore our stored error message gets lost somewhere in Cyberspace, never to be seen again. If your server-side code attempted to throw a standard exception subclass from the standard class library, like IllegalArgumentException, things could be even worse, like getting a ClassCastException.

The good news is that this is a known issue among the GWT developers. The bad news is that it is not fixed yet. However, a simple workaround exists. If you store a detailed error message in your own exception object and override the getMessage method (or its cousins) to return that copy, instead of the supertype's, it will produce the excpected outcome. For the previous example we could do it like this (changes in bold):

public EarthShatteringException extends Exception implements Serializable {

private static final long serialVersionUID = 1L;

private String message;

EarthShatteringException() {

EarthShatteringException(String message) {
this.message = message;

EarthShatteringException(Throwable cause) {

EarthShatteringException(String message, Throwable cause) {
super(message, cause);
this.message = message;

public String getMessage() {
return message;

If you are a grumpy kind of person and hasten to whine about the apparent intricacies of GWT, rest assured that most of the time GWT RPC is painless as advertised. In fact it seems so easy that people are already hooking it to other server-side frameworks, like Seam and Spring. It provides an elegant way to hook a modern server architecture with the most innovative web client technology on the planet.

I promise you, you'll love it.

Sunday, July 15, 2007

From CVS to Subversion

My friend George, whose day job requires the artistic and scientific skills of a system administrator (which pretty much boils down to: keep the users happy and yourself invisible), was envious of a guy who quit his job to write a web application framework in Lisp.

Common Lisp.

Of all languages.

Anyway, George is a great guy, at least when he is not having these wacky ideas, and an excellent system administrator. So the fact that he expressed envy for a programming gig, struck a chord in me. George loves challenges, too.

As a teenager I was a huge fan of MacGyver, a TV series where the main character is constantly facing intractable problems and always finds a solution through improvisation. In the same spirit, I have always liked doing challenging things, even when they appeared useless to some, rather than take the easy tasks with the most fanfare. As a software developer I seek challenges mainly through diversity, constantly seeking to conquer another problem space, another language, another framework in the vast field of computer science. But I've learned by now that nothing can be more challenging and satisfying at the same time for me, than a system administration task.

So I got myself one. I've signed up for the conversion of our source code repository from CVS to Subversion, as a break from my coding assignments. After eight productive years of using CVS as our main version control system, we became Subversion converts a couple of weeks ago. It hasn't been a wholesale migration yet, mainly for risk management reasons, but I've been committing exclusively to the new repository all last week. We began hosting new codebases (like my VCP project) in our shiny new repository, but for the time being we are still keeping the old ones in CVS. The process was rather painless. Not that it was a surprise for me. I have been making migration simulations and testing for about a year now and they always worked fine.

We had three main reasons for migrating to Subversion:

  1. Versioning renaming and copying files and directories. Since we are working mostly in Java where code refactoring often leads to renaming (for a class name change) and moving files around (for a package name change), it is imperative that we keep the change history of a file after renaming it. Till now the history was just lost after a rename, something that tended to make refactoring happen only when absolutely necessary.
  2. Atomic commit sets. Having the ability to commit every changed file in a single batch with the same revision number, made rolling back changes easier. It also removed the need to keep a separate log of our CVS commits in order to find out what files were modified along with a specific one in the same commit.
  3. Cheap branching and tagging. Experimental branches for fleshing out risky ideas should become more common now, since Subversion has better support for them. Also, no more tag-sliding to cope with unexpected last-minute fixes before a release, although, to be fair, Eclipse already helped with that.
However we are grateful for other benefits as well, perhaps less critical, but ones that provide an air of modernity to our deployment:
  1. The repository is now served via HTTP, allowing far more versatile deployments, than cvs over ssh. SSL tunnels allow for remote access to the repository without a VPN connection, something that was out of the question in the past, since it would mean that shell access to our development server would be open to the world. Also, the ability to use LDAP for authentication and authorization, removed the need for shell accounts for every committer. That had been partly achieved in the past through PAM and the pam_ldap module, but setting it up involved screaming, crying, weeping, swearing and hair pulling. Not looking forward to it, ever again.
  2. Binary diffs make storing binary files in the repository cheaper. If you store large binary files in the repo, like third-party libraries, CVS adds the whole new version, not just the changes. Not that we worry too much about the repository space, but it definitely feels like we are in the 21st century.
  3. Versioning symbolic links. Not that I expect to use them a lot, but still a nice touch.
  4. We got hook scripts from the vendor, for tasks like e-mail messages on commit, log message cleanup, etc. We had all that with CVS, but I had blatantly copied most of them from the FreeBSD project's excellent repository and while they were of the highest quality, they came without much documentation. Since I already had a working setup it did not seem like a big deal, but if I had to do it all over again copying scripts from, say Apache repositories, I think I would have posted this blog on September.
  5. We also got repository mirroring and backup without file system specific tricks. Backing up the repository was a straight file copy for CVS, but since Subversion is more sophisticated (even for the fsfs backend that we use), having to resort to file system snapshots for a proper backup would have been a pain. Our development server is a FreeBSD system and UFS2 snapshots are relatively cheap, but not as simple as Also, repository mirroring only came up once and it would have required a nullfs mount from another jail in the server, but having the option of svnsync makes things simpler.
  6. Fine-grained authorization for repository access with CVS over SSH, required enabling ACL support in UFS2 and manually handling the permissions in each folder or file. Subversion over HTTP however moves the authorization configuration on a separate place, as it should be.

Subversion definitely seems like CVS done right. There is a clear scent of modernity in every corner I look, compared to CVS. I was surprised to find various hook scripts and assorted infrastructure programs written in Python, Perl and Ruby. These are pretty much all the mainstream languages in a UNIX system these days, which says something about something.

The only thing I'm not terribly excited about, is the Subversion support in Eclipse. I've been using Subclipse so far and although I haven't had any real problems, the integration is not as good as with CVS. Which brings me to the main reason I picked Subversion for our next-gen version control system: Eclipse support. Had it not been for mature plugins like Subclipse and Subversive, all the advantages over CVS would have meant squat. Having to resort to command-line tools in order to perform diff, update and commit would have sent our team's productivity to the drain, before you can say Alt-Tab.

If I valued technical excellence over productivity, I would have moved us to Bazaar, Mercurial or git instead of Subversion. Every cool project these days seems to pick one of those for a VCS. They even have alpha-quality Eclipse plugins. Then I would need to schedule a weekend for the whole team in a Mediterranean resort and clue them in the joys of distributed version control systems.

Hmm, not a bad idea now that I think of it.

Then again, had I chosen technical excellence over getting work done, I would probably quit my job and build a web application framework in Lisp. Common Lisp.

Damn. George was right, again.

I hate it when he is right.

Saturday, June 30, 2007

How I fell in love with GWT

The first Graphical User Interface I ever wrote was in BASIC. I was about 13 when I wrote it, so it was a GUI for a game. You only build important applications when you are young. As you grow older, you compromise on the 'important' part, but that's life I guess.

The GUI didn't do much and it was a very laborious experience by today's standards, but I remember enjoying every bit of it. I am a geek, you know. A few years later I was building a GUI in C. It was more sophisticated, but the effort had gone through the roof. I started using polygons and clipping algorithms and z-buffers and whatnot. I even had a few books to keep me company that still hold a prominent place in my bookshelf.

They got to lie on the floor for this photo, but we've come a long way together and they didn't mind.


Using geometry and trigonometry to create a GUI, made the stuff that I was learning at the time in school actually interesting. Or perhaps it was the other way around. Who knows. It got frustrating after a while though, so when I discovered Windows and the Microsoft Foundation Classes, it felt like a godsend. I even got new books to celebrate the occasion.

But programming for the PC can only get you so far. Now that you can program for your phone, how could you let the opportunity pass? I couldn't. I started reading up everything I could find about Java Midlets and the Symbian OS. No books this time, everything was online. The development experience was great. You could do very little stuff in such a small machine and the process seemed like constantly solving puzzles. The GUI was the easiest part. You got a menu, two soft-buttons and some form fields. That's your interface. You could use any color you wanted, as long as it was black. I had great fun doing it, but my company was making more money in enterprise software, so eventually I found myself working in the Enterprise Java Software world. A place even the brave ones fear to go. Probably because it involves putting an HTML GUI on top of a Java server application, which is as scary as it sounds. If you are not a hopeless geek, that is.

The worst problem with such an arrangement is that you constantly have to context-switch your mind from one language to another: from HTML to Java, then to JavaScript, then back to Java, and so on and so forth. It's the same burden as using straight SQL to access your database (but let's not get into that again). And the tools aren't very helpful, either. The gap between these technologies makes you debug the same use case separately. Nowadays you have to add AJAX capabilities in your web-based apps, which only makes things worse. When I first used AJAX in the development of an HRM system a few years ago, it felt hard. When trying to find out why a certain widget was not getting updated, we had to use a Java debugger to see whether the server was sending anything and then a JavaScript debugger to check whether it was coming to the browser at all. It was madness, I'm telling you.

[By the way, if you have no idea what an HRM is, ask your hiring manager, he uses one. If he doesn't, tell him to give us a call. We can help.]

So when I heard about GWT, I instantly got excited. It promises to free us from the torture of creating the GUI in HTML/JavaScript and the backend in Java and it delivers on its promise. You do everything in Java! You create the interface pretty much the same way you did it with MFC back in the day and it gets transformed into JavaScript code of the highest quality to execute on your browser. All of that in the comfort of your Eclipse IDE. Apparently we have the same taste in IDEs with Google.

I've been reading about it for a year now, but I wanted to get some first-hand experience, before bragging about it. The opportunity came with my new Very Cool Project, which I can't talk about yet, so I'll just call it VCP. It's like VIP, only cooler. The Coolness of the project exists independently from GWT, but this is the icing on the cake. What would have been a technical wonder with a boring GUI, will now become a highly interactive experience that will validate the underlying technology. Just like what happened with GMail. Nobody cared much about Google's low-level technical marvels, until it hit them in the face through the excellent interactivity of the GMail GUI. Hopefully that's what is going to happen with VCP as well, if everything goes as planned. Yeah, I know. Like it ever does.

But with GWT, I feel quite confident. Creating a GUI is so easy that I made the VCP mock-ups in it. We used to do it in plain HTML with web designer tools and when we started developing we would copy the HTML files to JSP ones and change stuff all over the place. It took me only slightly longer to finish the task with GWT, but I already have working code to use. I can use the time I would spend coming up with a first-pass working prototype, to make a trip to Tahiti.

Just kidding. Like they would ever let me do it.

The other thing I like a lot about GWT is that it's open-source. And with the best license, Apache 2.0. This has already been quite handy in VCP, when I stumbled upon a bug during my upgrade from version 1.3 to 1.4RC. A simple request for help in the forum and a bit of source code reading, and I came up with a workaround in no time. And identifying the bug was the easiest part of all. I got a stack trace of my Java code and using Eclipse I could immediately pinpoint the culprit.

There is much more in GWT than that, though. You get easy browser 'back' functionality. No more 'history stack' for us, thank you very much. You can unit test your interface with JUnit. Do that with a HTML/JavaScript GUI if you dare. And perhaps most important of all: cross-browser compatibility. The Googlers have gone into the trouble of coming up with implementations for numerous browser inconsistencies and they have hid them inside the GWT classes. You only program against one GWT API, not against half a dozen JavaScript & DOM implementations.

I still haven't got a proper book about it, though. You know, for company and all. I did however, make the first step: I put it in my wishlist.

Friday, May 25, 2007

Why You Should Ditch C++ For Java

In the 8 years I've been developing in Java, I've heard of numerous arguments about why it is better than C/C++. Some rave about the garbage collection that frees you from (most) memory management tasks. Others are swearing by the thread awareness of the language and the libraries. Or the design patterns that are elegantly embedded in its library implementation. Or the VM abstraction that makes it possible to run the same code in multiple operating systems. And of course you can always find the weirdos that mumble things like type safety and automatic bounds checking. These are all nice indeed, but it is something else that fills my heart with joy each and every time I stumble upon it.

Pretend for a minute that you make a living programming computers. I know, why would someone in his right mind do something like that, but bear with me. Let's also assume that for reasons unknown even to the Creator himself, you are using a development environment (IDE in geek-speak) written in C++. Suppose that while banging merrily at the keyboard you hit an IDE bug. Kaboom!

Segmentation fault. Core dumped.

Or perhaps you got a pretty little window on the screen that informs you that something terrible happened to your IDE and suggests to notify the proper authorities (that is, the IDE maker). After recovering from such a traumatic experience, you will eventually have to relaunch your IDE, curse for the Loss of Unsaved Changes and do them all over again.

Now let's assume you were using an IDE written in Java. Click, click, click: bug. But this time no kaboom. You clicked on some button-shaped thingy but nothing happenned. You click again, nada. The IDE is still there but something went obviously wrong. You call for help and your friendly sysadmin shows up. He digs up the IDE's log file and he shows you what happenned:

at org.eclipse.update.internal.ui.wizards.ReviewPage$TreeContentProvider.getParent(
at org.eclipse.update.internal.ui.wizards.ReviewPage.getSite(
at org.eclipse.update.internal.ui.wizards.ReviewPage.access$29(
at org.eclipse.update.internal.ui.wizards.ReviewPage$
at org.eclipse.jface.operation.ModalContext$

What do you do? You just forget about clicking that button-shaped thingy ever again (or maybe for a day) and get back to coding frenzy.

The important thing to realize is that in both cases the same problem emerged. A reference or pointer to something was accidentally pointing to something else instead, and it was being forced to behave, perhaps a bit abruptly. After all, we should all be careful where we point to. It's the noble thing to do. But the impact of such an accident was fundamentally different. In the first case the operating system killed the process, while in the second case an exception was propagated up the stack. Both programs are multi-threaded and therefore capable of doing many things in parallel, yet the first one could not avoid having all its threads killed because one of them messed up. Oh, the cruelty! How would that make the other threads feel, I wonder. The Java program on the other hand, rightfully punished the offending thread (to make an example perhaps), while the others were left alone to go about their businesses. My guess is they all chatted quietly afterwards about it and everyone agreed that the grounded thread was a troublemaker, who got what she deserved.

The same thing happens all the time on server programs, too: big, heavy applications that serve legions of users. When the administrators are least expecting it, a stray pointer causes havoc. The service goes down, the call center is flooded with support calls and the administrator's pager goes nuts. That is for C++ server programs, of course. Java-based server applications go on serving people, even while a few threads get kicked in the bottom every now and then. (And in case some smartass mentions using watchdog daemons to restart servers: would you rather have a staff that worked via self-motivation or a staff that needed angry, big dogs to watch them while they do their job?)

So, in a nutshell, that's why you should not be using C++. Not if you pity the poor program's users, that is. Or its undeservedly punished threads. C++ is a hard, cruel language. Come and join me in the heavenly world of Java.

Wednesday, May 16, 2007

The Big Blue Blues

Bob Cringely has a two-part story on IBM's LEAN project. LEAN is a plan conceived by the executive team around CEO Sam Palmisano, to improve profitability by reducing costs. The idea is to offshore and outsource most of IBM's US-based operations to countries like India and China where it has been building up its presence during the last few years. The way this works goes like this: first of all, you pick the most expensive employees on your staff and you fire them. Then you make the remaining staff work overtime unpaid, to take on their responsibilities, so that customers don't start suing. Finally, you bring in new cheap labor to replace the ones who got the boot and hope they'll get the job done.

This is apparently the way you do business in publicly-traded companies these days. Product quality and brand value may go down the drain, but if such things please the stock market, then the executives can eventually cash-in their options and retire to Hawaii. The poor sobs that got the sack will be in a less advantageous position, unfortunately. Trying to find a job at their age is not something one likes to dream about. You see, the ones who get fired are not necessarily the ones with the larger paycheck. If that was the plan, the CEO would probably have to go first. No siree. Executive-types worry the most about having to pay pensions for their retired employees. So, instead of identifying the real blocks for increasing productivity, they just reduce costs and pretend that it's all well and dandy.

Apart from Cringely's excellent analysis, what is even more interesting is the comment section in his first post. Many anonymous IBMers have shed more light into the matter and also into the company's business practices of late. Underbidding contracts, mismanaging projects, lying to customers and 9 layers of management are the ones that stand out for me. The situation appears to be helpless. People come out frustrated, disappointed and in despair. Someone who used to work for DEC in the 80's said it was all too familiar for him. I have also been getting similar signals myself.

I have worked in an IBM project as a subcontractor for the better part of a year. My experience was rather good, all things considered, and I made quite a few friends there. This was a few years ago and the project was apparently a huge success for Big Blue. The team was hard-working, well-organized and included some very talented engineers. We were lucky enough to have probably the best project manager in IBM Greece's payroll, as I was told. And it certainly matched my experience. However, we were the exception. The word on the street was that IBM execution sucked big time. Virtually everyone admitted it. And not just project management, but other layers, too. I heard stories about constant quarrels in the team and lousy interactions with the customers. I know people who were fed up with the company and left. And based on multiple reports as well as personal experience, I wouldn't rate their engineering as first class.

The problem with 800-pound gorillas is their weight. Their greatest strength is eventually their doom.

You don't underbid if you are an 800-pound gorilla. That's common sense. Brand value is expected to be paid for. Startups know all too well how a slim profit feels like. If you miscalculate your expenses, you suffer. It's the risk you have to take to fight against the big boys. But startups have less fat than big firms. They haven't lived long enough to accumulate dysfunctional support layers that help run things but do not contribute to the bottom line. Big corporations can't afford not to make money to support their less profitable units. At least they can't be doing it for a long time.

Then there is the issue of mentality. On every successful project you have one or more champions. The people who are the stakeholders and carry the rest along the path to success. Big organizations have a tendency to dilute responsibilities among many people, without necessarily empowering them or giving them enough room to function. Eventually employees develop a public servant attitude and invest just the necessary effort for a minimally accepted outcome. If project managers were also architects perhaps it could work, but that is very rarely the case in my experience. Startups on the other hand are constantly running like there is now tomorrow. Continuously trying to outperform, outsmart, out-engineer their competitors in order to get a larger piece of the pie. Until they grow, of course, and become gorillas of their own, and age, stagnate and eventually die. Or maybe split up into many smaller groups that can be restructured as a startup again. Like what should have happened with IBM in the 90's, as one poster commented.

It's the same thing as what has already happened to Microsoft. And what will probably happen to Google in, say, 20 years. It's quite normal actually. But sad. And if you are trapped in there you might want to start searching for the emergency exit.

When I was graduating from college, I considered the worst aspect of working for IBM to be the dress code. I didn't wear suits at the time. As I found out, things have improved in that area. Unfortunately, virtually everything else has gone south.

Saturday, April 21, 2007

Heresy! Web apps without SQL databases

Apple's Jens Alfke posted a thought-provoking piece the other day about data storage in the web world. In it he questions the conventional wisdom that SQL databases are the one and only solution for that problem space. While discussing the scalability problems faced by (built on Ruby on Rails), he ponders over using plain files as a storage format and playing some clever tricks to get more performance in a simple way. The comments on his post are also interesting and the debate is still going.

Although I've been working for seven years in web applications with SQL databases, that's not the first time I've heard of this heretic opinion. As one of his readers accurately points out, Paul Graham's Viaweb (now Yahoo! Store) was (still is?) also using flat files to store its data in a FreeBSD UFS file system. Many large-scale server applications (say, Directory Servers) use storage managers like Berkeley DB to keep their data, without having the SQL query engine or the relational model to depend upon. Also, very highly transactional applications in the financial banking sector frequently use distributed in-memory object caches like Tangosol's (now Oracle's) Coherence as an ultra fast data store, with an RDBMS as a backup.

There is a lesson to be learned here, and it is finely articulated by Poul-Henning Kamp's presentation on Varnish, a web accelerator. Poul-Henning, a veteran FreeBSD kernel developer, created a Squid-killer by, to use his own words, not fighting with the operating system. The architecture of his web proxy is closely aligned with the way a contemporary UNIX-like operating system works, thus avoiding pointless layers of abstraction and architectural mismatch. The same logic accounts for Coherence's performance gains, a good mapping of the data storage architecture (in-memory object maps) to the web application architecture (Java EE or a lightweight alternative). The same way Varnish avoids traditional file I/O by using the OS's virtual memory (directly mapping files into pages via mmap), Coherence avoids the database overhead (SQL query optimizers, table indexes, disk access, etc.) by always dealing with objects stored in memory.

If for a particular web-based application problem we can devise a non-SQL storage solution that maps well to its use case requirements, then why suffer the (financial, support, technical) overhead of a SQL database? If there are no requirements of OLAP functionality or data warehousing, why bother? Remember the KISS principle: Keep It Simple Stupid! Who would knowingly subject himself to the evils of the object-relational mismatch (the Vietnam of Computer Science), if there was another way to do it?

Admittedly, the great thing about SQL databases is that they let you query your data in ways that you may have not contemplated as necessary. In a system with constantly changing requirements for data view (or with requirements for ad-hoc, dynamic viewing) you may well not have any other choice, but to use a SQL DBMS. Perhaps Object-oriented DBMSs can be a solution too, but I believe they are just starting to obtain OLAP and data warehousing capabilities and the performance may not be quite there yet.

Can it be an accident that Google uses Bigtable, a distributed storage system of their own devising for internal use? When distributed/federated databases have major drawbacks (namely cost and vendor lock-in), where do you go when you have to scale? Horizontal partitioning is a solution, but you'd better plan ahead.

In such circumstances, it may be appropriate to consider even heretic solutions.

Update: For those who won't take the time to watch the whole Varnish presentation (hey, it's fun, really!) Kostas Kalevras reminds me that you can find the meat of the presentation in the architect's notes. Apart from Poul-Henning's witty comments, they contain pretty much all the important points made there.

Wednesday, April 11, 2007

On FreeBSD and Debian package management

About a year ago I was contemplating writing a graphical package management tool for FreeBSD. I had been using bpm on and off for a while and while it was close enough to what I needed, the effort to extend it wore me off pretty soon. After all, how much GUI programming in plain C can a decent man endure?

Anyway, after picking a more workable solution on the programming language front, I had sketched up a GUI prototype and was considering the available options for the actual package updating code. My main interest was in binary packages and there were a few available command-line tools and libraries. None of the options seemed to work well enough though. Besides various communication issues among the two tiers of my application, what really drove me off this pet project was the source-based nature of the ports framework. That and the tiny issue of fatherhood, to be precise. I've tried to explain it once, but what I really wanted was something like the Debian system, which I'd argue is a better fit for regular users.

Michel Talon, long time FreeBSD user and developer, appears to have researched the issue more thoroughly while developing pkgupgrade, a tool that would have been another great option for my own project, had it been available last year. Pkgupgrade is written in Python, which would make it even yummier in my opinion. It's not Java, but it's close enough for my taste. Michel's comparison of the FreeBSD package system and the Debian one, comes to the conclusion that binary package management systems are inherently better for casual users than source-based ones:

"But the main factor ensuring reproducibility and reliability of the apt system is working with binary packages. You can be sure at least of the existence of a binary package, and probably that it works, due to the severe testing in the Debian system. There is no guarantee in a source based system. Hence no package management system can be reliable, however sophisticated it is."
The above excerpt may sound a bit harsh, but if you read the whole paper you'll see that the author's arguments are pretty balanced. Now that I've had the chance to use Debian's apt system for a few months, I can say that I wholeheartedly agree with Michel. This is pretty much what I had in mind for FreeBSD last year and I still think this is the direction the project should follow.

The upside for FreeBSD is that I no longer have the time to work on my old Java-based graphical package management tool. Because, let's be honest here, a system tool in Java? How many rotten tomatoes would be coming my way?

Monday, April 9, 2007

Paul Graham on Startups

When I began this blog I made a deal with myself that I would not post more than once or twice a week, but lately I just can't help it. I could use the excuse that I'm on holidays, I suppose. It's the Orthodox Easter over here, and Greece is covered with a smell of roast lamb. It's a sunny weekend, people walk around at a snail's pace, birds singing, flowers blossoming, you know how it is. I just got inside for a minute to check on my e-mail (I know, I know) and I discovered pure gold: Paul Graham's essays have an RSS feed! I don't know how long it has been out there, but I just stumbled upon it, and man, did that made my day! That and the roast lamb, of course.

After subscribing, I found out there were a few recent essays that I had missed. The one I want to particularly mention is Why to Not Not Start a Startup. Since this is a topic I am very interested in, I read it without even blinking. That alone could explain the tears in my eyes, but there is more to it. I've been a Paul Graham fan for quite some time, even though I'm not into Lisp. His writing style is marvelous and his wealth of experience, invaluable. I would like to take this essay and stick it in the faces of various investors we've met over the years. Not that it would change anything, but it would make me feel better, at least. I had been planning to write about a few of his points myself, but since I could never hope to be so eloquent, go read them straight from The Man.

There were moments of discomfort, I must confess. Like when I read the following:

"If you don't think you're smart enough to start a startup doing something technically difficult, just write enterprise software. Enterprise software companies aren't technology companies, they're sales companies, and sales depends mostly on effort."
Ouch. I know it's true, but it always hurts to admit it.

There are other well-established observations in there, like the consulting-to-product business transformation:
"What you can do, if you have a family and want to start a startup, is start a consulting business you can then gradually turn into a product business. Empirically the chances of pulling that off seem very small. You're never going to produce Google this way. But at least you'll never be without an income."
The chances may be small indeed, but, hey, it worked for Joel.

Also on the well-known territory:
"In a good startup, you don't get told what to do very much. There may be one person whose job title is CEO, but till the company has about twelve people no one should be telling anyone what to do. That's too inefficient. Each person should just do what they need to without anyone telling them."
Yep, I can fondly remember why we started it all.

The Love of Programming

Jeremy Allison, of the Samba fame, has posted a piece on the advice he would give a young engineer about to embark on a software development career. Really good stuff. If I were to summarize his post in three words, it would be "love, low-level, open-source". Hmm, that's more like five words, but who counts anyway? I must confess that I am in total agreement with Jeremy, about the necessary qualities he mentions. Particularly the first one, Love.

Occasionally I run across old friends from the university whom I haven't seen for a long time, and they will get to ask me what is it that I do these days. And every time I mumble something that contains the words 'software' or 'programming', they will go 'right, I liked doing that stuff as a student, but after graduating I swore I would never go through that again'. And I will give them a sympathizing smile. I really understand their frustration. Programming is hard. And not very rewarding.

Sure, you can make a decent living and in some rare cases you may even get rich. But how many people will understand your work? Say you design a great presentation framework for web applications, like Stripes. Will your mom ever comprehend its greatness? How would you describe the wonderful effects of annotations and convention-over-configuration? You can't. You might even say that it supports the extranodal lymphoplasmacytoid lymphoma and it wouldn't have made a difference. She would still refer to you at her friends as 'plays with computers'. Lousy job description. Personally, I would prefer being referred to as 'orders other people'. That is an Executive Manager, in mom talk. Or 'gives interviews on TV'. That would be VP of Software Strategy And Stuff. But when developing software, you have no other way to endure the obscurity and the difficulty of the craft, than to grow to love it.

There is a Zen-like sense in Programming, it seems. Knowledge shall set you free. And when searching for knowledge you have to go deep. You have to go low-level. Jeremy suggests that you should get acquainted with the way the system works deep inside. Amen to that. Processors, operating systems, protocols, that sort of thing. Joel Spolsky would agree, apparently. His advice to young students is to learn C, not just high-level computer languages. Steve Yegge has a similar suggestion, to learn Math. Algorithms, probability theory, statistics, etc. My take is you need a solid background in a wide spectrum of disciplines. Don't overspecialize.

The other thing Jeremy suggests is involvement in open-source projects. I guess it should be a no-brainer today, but it was true even ten years ago. Free access on the work of esteemed peers is something rather scarce in other disciplines. But the experience you can get working with the masters is simply invaluable. Not to mention the social skills you develop, while interacting with others. After a while you can learn how to judge the probable outcome of a discussion, simply by the way the issue has been put on the table. And that way you can try to contain a fire before it burns down everything. Good social skills are a requirement for a good future manager. Communities can also help make new friends and build a reputation. Things that can pave your way to a successful career. And maybe, just maybe, you'll avoid being referred to as 'plays with computers'. Sigh.

Saturday, April 7, 2007

The bcm copyright violation

I've read the whole thread on the bcm driver in OpenBSD violating GPL code. It was educational. And sad. For those who haven't heard about the issue, here is the executive summary:

A team of Linux developers began a clean-room implementation of a wireless network device driver for a Broadcom chipset. Their effort produced a chipset specification and a GPL-licensed Linux driver. An OpenBSD developer started implementing a BSD-licensed driver for OpenBSD based on their work. He apparently started with some code of his own and some from the GPL code base and kept rewriting function after function in his own way. Unfortunately, he started committing his work on the OpenBSD CVS tree before replacing every piece of the original code. This constitutes a copyright violation as the Linux developers recently pointed out. The driver was removed from the OpenBSD tree in the midst of accusations among the two camps about proper community behavior.

This is not an unusual thing to happen. What was unusual indeed, is the lack of cooperation between the two parties. Even though the core matter was quickly resolved (in an abrupt way, nevertheless), the accusations regarding the motives and the behavior of the other side went on for quite some time. This is the sort of thing we get to enjoy in the open-source ecosystem. If you are the kind of pervert that I am, of course. It's like a TV show where everyone keeps shouting, without actually hearing what the others are saying. Ah, the joy of mobs! And once again it comes down to the personalities of the people involved. Intolerance, stubbornness, old wounds, all contribute to a fire that keeps growing, burning down the bridges that people had built between their communities.

I can remember other cases where things were handled more professionally. A high-profile one was the JBoss and Geronimo clash. Fortunately, there were people with diplomacy skills on that one. Lawyers even. Hey, don't get me wrong, I know all the jokes about lawyers, but when you are talking about lawyeresque things, like copyright violations, it helps to actually know what you are talking about. Apparently, not many software developers do. Me neither. So, I'd suggest that in such circumstances the best strategy would be to listen first. Be condescending. Assure the other party that you are taking the issue seriously. Avoid any inflammatory vocabulary. Don't bend over, but don't counter-strike either. Remember, you are trying to uphold peace here, not win a war.

That is actually one of the things I like the most about the Apache and FreeBSD communities. The gentleness and the professionalism. There are always the bad apples, no doubt, but the overall impression is wildly positive. No drama queens. Not in the high ranks at least. The sad thing is that you don't get on the front page without some drama. You are instead painted as a 'nice guy'. Dependable but boring. The one that everyone wants to marry, but nobody wants to date. That's pretty much why I replaced my FreeBSD desktop with a Linux box at work. And why I develop on JBoss instead of Geronimo. It's a fame thing. Go with the flow.

However, at home, when no one is watching, I use a Mac. In case you didn't know, Macs are FreeBSD inside with the sexiest graphical interface on top. Which means, dependable and slutty. My kind of girl. I mean system. What's not to like?

Tuesday, April 3, 2007

Open source software in Greece

In a recent blog post, fellow open-source developer Dimitris Andreadis wondered about the sorry state of open-source software development in Greece. Dimitris has been working for JBoss, er Red Hat, for quite some time now and these days he is the Big Cheese of the JBoss Application Server. Therefore, his question is not of the naive kind. As a matter of fact I've been asking myself that same question these last few years and I'm about to tell you what I've come up with. But first some brief history.

My own open-source adventures as a developer began in the Christmas holidays of 2000, if my memory serves me correctly. With the University closed for the holidays, I spent some time during my vacation fiddling with FreeBSD on my laptop. As a Unix enthusiast I had switched a while back from Linux to FreeBSD, but I had been having a problem with the system's support for the Greek locale. The problem was that there was no support, whatsoever. Being young and foolish, I sacrificed a few nights of partying with friends to tame the beast. And tamed it was. I've been submitting various patches ever since, to the FreeBSD project, the Eclipse project, the Apache Lucene project, the Gnokii project and a few others. Aside from one (recent) particular occasion, I've been doing it on my own spare time, without any sort of compensation for my work. Not to mention missing a few parties.

What was the motivation then, you say? Well, obviously, at that time and age I wasn't a world-acknowledged computer programming Giant, yet. Yeah, I still ain't. But the goal had been set. And a few pints of beer could not have stood in my way. I sought recognition from my peers and recognition I received. Not right away of course. It took a few years more than I had imagined, but eventually I ceased to be the frightened newbie and turned into a seasoned veteran, who would help others find their way around the system. Besides the numerous "thank you" notes, I was rewarded with experience. And as you've probably heard, experience does not grow on trees. You have to invest time and effort, in order to get it. You have to sacrifice stuff. You have to say no to party invitations. From pretty girls. More than once. It's cruel, I'm tellin' ya!

So, we have determined that seeking experience, peer recognition, career advancement and having an itch to scratch, can lead an otherwise sane person to open-source software development. Pretend for a moment that you agree with me that there must be plenty of people seeking peer recognition, yada, yada. There is still the issue of effort and sacrifice. I would be tempted to concur with various other commenters in the aforementioned blog that in Greece we like to have it easy. But, let's put that aside for a moment and consider the "scratch an itch" issue. What if there is no itch? My friends who had Windows on their PCs, did not have any locale issues. They regularly cursed at the blue screens of death of course, but that's not exactly an itch, it's more of a gangrene. You just can't scratch it. So you spend your time downloading pirated versions of insanely expensive software instead, fooling yourself into thinking that you are obtaining experience. The error being of course in the direction. Experience mainly comes from diving deep inside a problem space, not sailing along in the surface. If we eliminated software piracy in Greece, most people would not be able to afford many commercial applications on their PCs. They would have to settle for free and open-source equivalents, warts and all. And then they would make the greatest discovery of all: they would be able to try and fix them.

If I'm coming across as a bit disappointed, it's probably because it's getting really late and I'm feeling sleepy. Don't pay much attention to me, instead see how good things appear to be in an excellent study by professor and open-source developer Diomidis Spinellis. In his paper "Global Software Development in the FreeBSD Project" he presents a world map with markers on the cities where the project's international team of developers live. You can see there that Greece is represented with a couple of markers, whereas Spain is not. Neither is Portugal. Nor Ireland. Even Russia is not so hot either, considering its size. And don't get me started on South America or Asia.

So, I'd say things aren't very rosy, but they are not that bad after all. It's just a matter of perspective. Glass half full or half empty? Dusk or dawn?

Now speaking of dawn, if you'll excuse me...

Thursday, March 29, 2007


"I'm just a jealous guy". Reading the news about Oracle acquiring Tangosol instantly brought John Lennon's voice in my head. It's Tangosol of course that I'm jealous of. As a matter of fact, I don't know of anyone who would be jealous of Oracle. Larry himself is a different story. He's got that ultra-luxurious feng shui mansion of his that I would die for, but I guess that's what you would expect from a gazillionaire. Tangosol, on the other hand are (or at least were) some regular guys just like me, working their asses off developing software. Except that I'm a software developer of the garden-variety, whereas they're of the genius one.

Still, I don't believe that's the only thing that made them filthy rich. At least I hope they are filthy rich. I don't have any inside information, but from what I've seen on the Net, Cameron Purdy & friends are really nice guys and absolutely deserved to be rewarded like Sultans. Something that cannot be said about other Java celebrities, that are now dancing with their red hats in their own dollar ponds. Anyway. Acquisitions are very hot lately with RedHat acquiring JBoss and Exadel, IONA acquiring C24, BEA acquiring SolarMetric, etc. It appears that the dot-com bust days are behind us for good.

What I particularly like about Tangosol is that they appear to have made it without any VC funding. Hats off to them if that is the case. We've been trying to pull the same lonely stunt where I work and it has been really hard so far. Most people we talk to, consider it a raving success that we're still hanging on our own after seven years, in such a small and distorted market. I mean, yeah, in theory we're doing the right thing, but if you consider the way the IT services sector functions in Greece, it's pretty much a leap of faith. The reasons are manifold:

Small market: many small fish can survive in a big pond, but as the pond gets smaller, the big fish have to eat more than their fair share to survive. And if they ever sense the inner fear of survival, then you can forget about level playing fields and gentle sports. Getting a contract gets ugly.
Cost sensitive market: being the best girl in town isn't as important as being the cheapest. You may be providing cutting-edge technology, state-of-the-art solutions, or the cure to world hunger, but unless you can beat their price, you are irrelevant. This should come as no surprise if one considers the characteristics of Greek economy. Large state sector, small private sector. State is a big spender, but non-deterministic in meeting obligations, payments, even deadlines. On the other hand private companies are obsessed with shrinking costs and conservative spending. It is sad how few companies actually consider Information Technology as something that would significally affect their competitiveness, ergo their bottom line.
Risk-averse VCs: VCs, like everybody else around here, would like to make big bucks without doing anything hard or, heaven forbid, risky. Recently I've heard of a successful Greek startup in microelectronics that failed to attract Greek VC funding, despite the exceptional prospects of their business plan. What the VCs told them, was that they couldn't back them, but if they could find foreign VCs willing to invest, then they would ride along. That's like saying, hey, I'm rather incompetent at evaluating business plans, but if you can find someone who knows this stuff and says it's OK, then I'll join you guys! Yeah, like we'll need your sorry arse then. What a bunch of wimps. From personal experience, when we were presenting our business plan to a local VC once, the guy that would evaluate it was at the same time preparing his proposal on a different business plan, from a local tavern. Judging by his eventual comments on our business plan, he must have had a hard time figuring out which is which.

It's funny, but I can't think of a single acquisition in the IT sector in Greece that was made in order to obtain the valuable IP of the acquired company or to enhance the product or solution portfolio of the acquirer. Here, big companies usually buy smaller ones in order to get a grip on their distribution channels, or to expand their customer base and get some more leads.

Maybe they are right. After all, who ever prospered around here by simply being better? Perhaps only in the souvlaki business.

Lucky bastards those Tangosol guys. The Oracle thing was easy. Pfff. Come and pull this stunt in Greece if you dare!

Monday, March 26, 2007


I've been meaning to start blogging for quite some time now, but I never seemed to make it. Too much real life I guess. It wasn't just thinking about doing it, I even made a list of issues I'd like to talk about and then did some brief outlines, too. I could never find a good first post though that I actually liked. By that I don't mean the very contents of the post. Nah, I don't remember ever liking one single thing I wrote after finishing it. No, I just wanted to write about something that would seem appropriate, you know? Something that would define the posts that would follow, give meaning to the blog, a definitive statement, a raison d' ĂȘtre.

Most people start their blogs by talking about who they are and what they are going to talk about and how they are going to be different from everyone else, like its some kind of audition for a play or something. Or maybe a commercial ("My blog, my world: the hidden treasures. Coming soon in a theater near you"). Well, I suck at advertising, particularly at advertising myself. I suppose it stems from my father, who sucks at it too, although his day job would have you think he didn't. I honestly can't think of a single reason you should read my blog. I probably wouldn't. Chances are I don't read yours, so you don't owe me any favors, either.

Yet, I still feel like blogging, you know? Occasionally. Not always. Sometimes I have some thoughts I'd like to save for posterity. For my daughter, maybe, or her future kids. I know I'd be thrilled if I came across a private journal of my grandfather and actually came to know him in a way I never did before.

So I was planning to start a private blog and keep it hush hush, but this plan went south. My long time friend and avid blogger adamo, tagged me. No, not that old joke we did at school, where we wrote "moron" on a sticker, put it on our palm and pat the victim on the back, I've learned that well by now. Instead, it's a rather girly thing that goes on in the blogosphere, in the spirit of "I'll show you mine, if you show me yours". Anyway, I was never an alpha-male kind of guy anyway, so that girliness didn't bother me at all.

What he did show me and the rest of the Internet, is a list of his favorite movies and asked me to return the favor. Apparently some other bloke tagged him by showing him his list, and passing the torch. Now, of course, I didn't consider to fall for this chain-letter blogging thing, especially in light of the fact I wasn't a blogger. Little did that deter him, though. He suggested that I post a comment on his blog with my list. That's like being the kid outside the tennis court that picks up the balls and throws the champs a towel when they are resting. I ain't no darn kid! Hell, I'm older than he is. I still had no blog though. So, I decided to pretend I didn't hear about it and let it go. Unfortunately, he didn't. I should have known better, the man doesn't let go so easily. He mailed. He phoned. I ran out of excuses. Then it dawned on me: that list would make an excellent first blog post! It is sort of defining, without being very literal, it is something I wanted to save for future reference and it definitely is something I like talking about. Not to mention I would get him off my back.

Not that I will read any of it after I write it. I'll probably puke. But what else is knew, right? At least that's what I figured. I'm probably terribly mistaken here and the white wine in my glass doesn't help either, but anyway here it goes. My very own Favorite Movies List. Not the best movies I've seen, not the most acclaimed ones, definitely not the most entertaining I've ever watched. Just the ones that changed my life. The ones that shaped it, in content and in form. The ones I'd like to take with me in the flaming boat on my way to Valhalla.

I wasn't sure about how many entries I was supposed to put on the list. Adamo had eleven. Go figure. The guy that tagged him had seven. I traced the origin of this meme and the originator had seven as well. So I decided to stick by the rules of Number One. Seven it is. Seven Is The Number And The Number Must Be Seven. Six Will Not Do. Eight Is Out Of The Question. You get the picture. Now, speaking of pictures:

The Age of Innocence

Scorsese's masterpiece. A film about freedom, love and loss, filmed with exceptional craftsmanship. It taught me that one can live a life without the thing he wanted the most and yet have the courage to make his life more than just bearable. Living a pretentious life in a conservative world, but still keeping the fire that burns within. Favorite scene, the mesmerizing beauty of Michelle Pfeiffer fading to red or yellow as a hint of Daniel-Day Lewis's emotions towards her. I've experienced this one myself once. A pair of eyes, a pair of lips, fade to red. Second best, the scene of a dinner, where there is a civil conversation taking place, where few things are being said and much more are being implied. In the course of the dinner, Daniel-Day Lewis's character discovers that he has been isolated from his friends and surrounded by enemies, after a series of vicious insinuations. This is wonderfully underlined by the camera movement, that starts at the table level, presenting regular close ups of the dinner participants, then gradually moves upwards and away from the table to reveal a jail-like room with closed doors and servant-guards all around. I've almost melted a cassette with the film's soundtrack from excessive usage.

Picnic at Hanging Rock

A strong contender for the first spot in my list. This early work by Peter Weir, my favorite film director, appears to be a detective story. But appearances can be deceiving. It is actually a mystery film, full of questions but with only a few (if any) answers. It pictures the everlasting conflict between Nature and Civilization, Freedom and Strictness in a beautifully haunting atmosphere. Perhaps not merely the conflict, but more likely the duality of these concepts, in a sort of Yin-Yang way. Mountains that appear to be alive, girls pictured as paintings. Adolescence, maturation and the long journey in the unknown to adultness.

Anatomy of a Murder

The film that made me love Jazz. James Stewart as s small town lawyer that lives happily, fishing with his pal (Walter Brennan's voice is a classic by itself) and listening to Duke Ellington. The guy is living a quiet but happy life, yet when challenged with a tough murder case, he shows the effectiveness of a big-city lawyer. A hint that living a challenging, high-paced, career-dominated life is not the only way to go. The image that still haunts me goes something like this: an armchair; a fireplace; a bourbon; Duke Ellington in the air; happiness.

The Verdict

Made by a dream team of film makers (Sidney Lumet, David Mamet, Paul Newman, Jack Warden, James Mason), a film without any pretentious artistic value, but soaked in pure soul power. A soul's journey from death to rebirth and an eternal lesson that when you hit rock bottom, things can only get better afterwards. The main theme is a fight of David against Goliath, but with a feverishly cunning Goliath and David having to confront himself first and foremost. Also, a story where love and betrayal serve as a reminder that one can only count on oneself.

Rio Bravo

You'd think that this would be another run-of-the-mill cowboys-on-horses-and-sheriffs-with-badges kind of movie. Well, that would definitely be a way to experience it. In a deeper level though, this film is actually an ode to friendship and a reminder that bravery is pretty much another word for integrity. There are no heroes, just people who stood by their beliefs when the shit hit the fan. Four men stuck inside a jail house, surrounded by hired gunfighters, struggling to hold on until the marshal arrives. The sheriff, a drunk, a cripple and a young gun. The everlasting question: which side are you on? The Easy side or the Right side?

War Games

The film that made me a computer engineer. Artificial Intelligence, computer networking, war dialing, hacking, and the revelation that you can't win at tic-tac-toe. For a young teenager it was definitely the best career advice I could get at the time. Eventually, it even affected my PhD dissertation, but you can't quote me on that. It's funny (or sad) how different things turned out to be when I actually encountered military computer geeks.


A wonderful spy movie and a hint that old-timers like John Frankenheimer can have a refreshing view on a traditional theme. My main interest in the film is the character of Robert De Niro. A former spy, wise but sad at the same time, without the usual glitter and glory, but full of loneliness and repressed desires. I always thought that if I ever made a spy movie, it would feel something like Ronin. Darn. No point in doing it now, I guess.

Creative Commons License Unless otherwise expressly stated, all original material in this weblog is licensed under a Creative Commons Attribution 3.0 License.