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.

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