BGE's Killer Blog... Of Justice

Eclipse Galileo Review

2009-06-25T09:04:00.003-04:00

It's that time of the year again... here's my short review of Eclipse Galileo, which I've been using since M6.

While reading this review, keep my usage pattern in mind: programming for a large portal written in Java using frameworks such as Spring and Hibernate. Domain objects are mostly annotated, with some Hibernate XML thrown in. Spring configuration is still using XML for now.

Here are the things I like about this release so far:

HTML tags now auto-close. Same for XML tags; if you type "/" at the end of an open tag, the close tag is removed. Not a huge feature, but it's the kind of polish you find in IntelliJ that's starting to make its way into Eclipse.
Fully qualified class names are hyperlinked in XML files! This is a HUGE help for our team, as navigating those Spring XML files is always tedious.
Go to implementation. When you hover on a method call, you get a small pop-up that lets you choose between going to the declaration or the implementation. I'm still catching myself going to the declaration and pressing CTRL-T, but I'll get myself re-trained eventually. It would be nice if this feature had a shortcut key.
Switching editors with CTRL-PageUp and CTRL-PageDown. This used to switch tabs within the editor if present, to my great annoyance when I had XML files opened. I never use the "design" view for XML, so having to go CTRL-F6 or mouse around just because of a design view I never use was pretty annoying to me.
Rectangular/Column/Block selection mode. This used to be an add-in, but it's nice to have it built-in. This was one of the few things that had me boot up vi for text editing once in a while...
The compare editor is now a much more complete Java language editor, with completions and so on. Since I often have to resolve annoying conflicts by hand when merging old branches, this is a welcome addition.
Hyperlinks in JavaDoc pop-ups. Man, this is great! How often I've wasted time closing the JavaDoc popup and navigating to the parent class or to "see also" links by hand... Or even given up and gone to the web browser to browse the online HTML doc. In my mind, anything that saves me from switching to a different app just to navigate documentation is a Good Thing; it's one less hurdle to staying in the Zone.
The previous version of WTP had an annoying bug in JSPs: malformed tags would eventually lead to a stack overflow on complex pages, on every keystroke, until you closed and reopened the file. I haven't encountered this problem with Galileo.

But the major plus in my mind is the new plugin installation UI, known as p2. It's still not up to par with the Debian package manager front-ends, especially when explaining conflicts or missing dependencies. But it's much less confusing than previous efforts. I may actually use it to upgrade Eclipse next time around, something I never dared to do before.

What's to dislike? Well, nothing much. I still wish they'd implement proper themes for syntax highlighting, since the Export Preferences system exports all preferences. It's possible to edit the resulting file to strip non-highlighting related data, but it's a pain. Don't underestimate the power of syntax highlighting themes! Programmers like to share those, especially when the default theme is dark on light instead of the much less eyestrain-inducing light on dark.

Also, I wish installing Subversion integration wouldn't involve adding third-party connectors that sit in a different update site. I know it's related to licensing, but this is somewhat annoying. SVN support should be built-in, given that CVS is largely deprecated now.

Oh, and this isn't part of the Eclipse Galileo release, but the Maven plugin for Eclipse is really shaping up nicely. We've converted all our active projects to Maven, and it's really convenient to be able to just grab a project out of the repository and start working immediately. Not to mention how nice the new archetype UI is.

Again with more gadgets

2008-12-26T11:02:00.007-05:00

Well, my daughter was born this september, and she's still being a bit grouchy, so you'll forgive the lack of posts.

First of all, while she was sleeping in the first months and I was exiled to the living room as the little one was co-sleeping (before we discovered that she really hates it and would rather be in her own bed... She's strange, that one), I found time to update cbrPager somewhat. The main gain was the addition of background threads to pre-load pages. Oddly enough, page switching, while twice as fast, is still slow; it looks like the N800's relatively puny processor is having trouble just scaling the bitmap. I can't very much scale it on load, because the user may require it to be resized. But since then, very few changes. One pending feature request which I'll get around to implementing someday.

Second, I decided to take the plunge after much consultation with online price comparison engines and reading reviews, and, basically, the result is that I'm writing this from an Acer Aspire One AOA110-1698 netbook. It's going to replace my desktop completely. In doing this, I get two advantages:

I hope to free the office to become the little one's room as she becomes older. I'll only require a desk that can hold the 22' LCD, the netbook in front, the external hard drive and DVD-ROM, and a keyboard drawer. This means not much depth is required, and this gives us a lot of flexibility on the size of the desk that I can live with.
I can actually write this while watching the Dear Daughter sleep.

The latter was not part of the original plan, but I've got to admit, the Atom is a pretty amazing chip. It's faster than my old Athlon XP 2000+, and the GMA945 graphics, while not really the speediest in the world, are still quite a bit faster than my old Radeon 9000. Now, I don't recommend using that machine as a primary machine unless you're upgrading from an old clunker like mine; if right now you have a quad-core bomb, this little netbook won't impress you too much. But it's plenty fast enough for my needs; I even got some programming done on it.

Acer Aspire One Mini Review

This is turning into a mini review, so let's just get it done so I can gush about my daughter at the end of the article :) First, let's cover the external appearance of the device.

When you get that machine out of the box, it can't help turn heads. Everybody at the office wanted to have a look at the thing.

The shiny body, as often mentioned, attracts fingerprints more than anything else, so it doesn't impress me that much. Build quality is good, feeling as solid as my Dell corporate lappy.

The touchpad is quite small, and this can be annoying; unless you give it very high acceleration, you'll have trouble traversing the screen in a single swipe. I highly recommend using an external mouse for any kind of serious work. Still, it's built-in, and I still use it quite a bit when no at the desk.

The keyboard is the main reason I chose the One over, say, the Asus EeePC 900A or the Dell Mini 9. It's simply amazing. It's as usable to me as a fully laptop keyboard, and the key stiffness is even better. Key travel is great. Acer can do really nice hardware when they care, so it's too bad their stuff is usually so crappy. But the one feels more solid than the cheaper 14" laptops you'll find in brick-and-mortar stores (such as the really crappy 14" eMachine laptop that sells for the same price--trust me, unless you have to have a 64bit machine, the One is a better box). I only have one complaint about the keyboard: the left control key doesn't work very well, sometimes not registering. I solved that by remapping my caps lock key to control, which I do on regular PCs anyway. If the unit had been bought in a store, I would have returned it, but it's not worth the hassle since I have an alternate solution. One day, I'll take the keyboard apart and try to figure out if it's just a particle stuck under the keycap or something.

The screen is fantastic. At lowest brightness, it's very clear and sharp. You can plug in an external monitor. The graphic card appeared to give a fuzzy image at first, but after messing around with modelines in X, I got it to be pretty sharp. Too bad there's no DVI connector, but there's no room for both VGA and DVI, and VGA is still more widespread, so I understand the decision.

After having to crawl under my desk to reach rear-facing USB ports on my desktop, the side USB ports (3 of 'em, just enough for two external drives + the keyboard/mouse connected to a USB/PS/2 adapter) are really a blessing, and an unanticipated benefit to switching to a netbook from a desktop.

The 1698 comes with a 6-cell battery. It adds a silly protusion at the back, and I'm sure they could have come up with a better design. But do get a 6-cell. This thing has better battery life than my N800, and it shows... I don't use the N800 for web surfing much anymore (it's still getting much use as an e-book/comic book reader/time waster game machine). With the 6-cell, it's still pretty light, slightly less heavy than a thick hardcover book.

Software

Unless you don't know Linux at all, ditch the Linpus that comes with it. It's not that bad, but it's not that interesting either. There isn't that much software available for it compared to, say, Debian, Ubuntu or the latest Fedora (Linpus is based on an old Fedora release).

I initially considered installing Ubuntu, but in the end, I opted for Debian. The SSD in the 1698 is only 16 GB (it's big for an SSD, but it's far from my roomy 80GB I got on my desktop--it's now in an enclosure serving as the drive for multimedia stuff). I'm very satisfied with the boot time (about 20 seconds, not visibly much more than Linpus) and hardware support (full, after some monkeying around).

To install Debian on the AAO, the best hints are on on the Debian Wiki, these guys' blog (it was actually very, very helpful), and the kernel built by this guy (follow the link in the message). I had to monkey around with the kernel sources because I wanted to use madwifi to get the LED workings, and the headers package wasn't working right, but besides that, everything was very smooth.

To get the external screen working at full resolution, I added the modeline as explained somewhere (I can't find the link). The modeline has to be added to the Monitor section. For 1680x1050@60Hz (Samsung SyncMaster 2253w--it was a steal at 200 CAD), it's

        Modeline "1680x1050" 149.00 1680 1760 1944 2280  1050 1050 1052 1089

And then xrandr will see the right resolutions. I think it reads the resolutions from the built-in panel and ignores the external monitor; looks like a bug in the Intel video driver.

To get the screen switching functionality, I used arandr to create the scripts, and tweaked them a bit. In xfce, it looks like xfwm4 is a bit dumb when the monitor is added after X is started. So, the script to switch to the dual-screen configuration looks like this:

#!/bin/sh
killall xfwm4
xrandr --output TV --off --output LVDS --mode 1024x600 --pos 0x1050 --rotate normal --output VGA --mode 1680x1050 --pos 0x0 --rotate normal
xfwm4&

And everything works find. It's best to boot X without the external monitor plugged in, or Thunar has very tiny fonts when you unplug the VGA and switch to internal panel only. Don't ask me why; there might still be some glitches in the RandR extension. Still, RandR is really, really cool, and it looks even more flexible than many Windows XP display drivers (dual screen support is sometimes spotty--the worst part is, it's really driver dependent...).

I also installed XP on a small 4GB partition, just for the odd game that doesn't run in WINE or Dosbox. Install was OK, but installing the updates was really, really slow. I thought it was the SSD that was slow, and maybe that's part of it... but maybe it's just Windows Update. Someone at the office had to install SP3 + updates, and it took him as much time on his relatively fast desktop with a good 5400 RPM hard disk as on my paltry Atom 1.6 GHz with a really slow SSD. So, YMMV. If you're a heavy XP user, the hard disk may be a better choice. The external drive is a good compromise; I'll use it for heavy data crunching. But still, Windows really likes writing all over the disk. Use FAT32 and no swap.

Caveats

I still haven't tested the camera or the card readers. I'll test the card readers soon, moving the /home to a Class 6 8GB card; this should be faster than the SSD. When SSDs become cheaper, I'll swap the built-in one. In general, it's not that slow, but once in a while the whole system locks up waiting for the disk, and that's really annoying. Still, I like the SSD--it stays cool and boot times are really, really good with it. Heck, it boots faster than the fancy Core 2 Duo laptop the office provided me, and that uses a 7200 RPM disk drive!

It's still somewhat fiddly to install other OSs on that thing. But it's workable. Linpus is OK, just not as nice as .deb based distros (why they chose Fedora as a base is beyond me).

I haven't installed Notebook remix, because it depends on GNOME. Why it's not a plain GTK+ program is beyond my understanding. Maybe I'll hack it up a bit, it looks like I've become quite good at porting GNOME programs to plain GTK+.

In Canada, you get the weirdo keyboard with an extra key. However, I don't find it that bad, it's actually quite workable. I just hit the backslash instead of the Enter key once in a while. Nothing too bad, really. The Page Up/Page Down keys around the up arrow are really placed in an ideal way.

There's this fan control thing that is suggested online, but it doesn't seem to work too well with the latest BIOS (fan keeps turning on and off). The fan isn't that loud anyhow; it's not really noticeable. Maybe I lucked out and got a version with a nice fan.

Summary

Overall, I'm very happy with this purchase (400$, taxes and shipping included, at Swift Gamers--the guy ships fast, he shipped same day at 19:00 and it got home the following morning!). Mobile computing is in, folks. We now have enough power at low enough prices that you'll see small, light lapops everywhere. And I cannot emphasize enough how small and light the device really is. The only thing that might stop it is the CPU makers' fear that it'll cannibalize the sales on their high-power processors. But I think that'll only delay the inevitable. Low power CPUs are now very powerful, and make no mistake, people want low power. Being free of the power cable was already very cool with the N800, but now, I have my full desktop's power in my hands, and it's just... really cool.

The future of computing may not be determined by trying to beat the physical limits so Moore's law can still be applied. I think it'll be about finding more power-efficient ways of eking out a lot of computing power in small packages, at least for the end users. The big CPUs will be relegated to server racks, where they'll serve the computing power remotely. Star Trek TNG's vision of a big mainframe with small tablets serving as terminals may be the true future, with ubiquitous WiFi or 3G/WiMAX giving fast access to centralized resources.

Or maybe not. I'm not tech pundit, I don't pretend to know the future. But it's a really nice way to organize one's work, in any case.

And now, for something completely different...

This is usually a technology oriented blog, but I'd be a very poor father if technology were my only concern.

Stéphanie Nguyen-Emond came into my wife's life and mine this september, and despite the sleep deprivation (that little rascal was sleeping only 10 hours a day at first, and crying all the remaining hours of the day--with very little reason, believe me!), the worries about the little one not drinking well, the diapers, daddy getting sprayed with the little one's waste products several times, the Dear Daughter twisting around whenever she's being picked up (she wants to see stuff, and hates it when she's not facing outwards), etc. etc. etc... she's given my life meaning and purpose.

She's a robust baby, with very, very good lungs (we can attest to that every time she wakes up), drinks too fast sometimes, and has a wonderful smile when I change her diaper.

As a parent, you have to learn to be patient. Sometimes, I get very frustrated, and then feel bad about it because I feel I should have more patience, more skill calming her down. But the minute after she gives a really wide smile and coos, and then I feel like everything is all right with the world. Despite the crazy economic times and the uncertainty about the whole financial system, I find that I'm still optimistic. I'll work hard to leave her a nice world, and the difficulties we live right now will no doubt yield some good in the end. Hopefully a world that is more just, less crassly materialistic, and focused on protecting the middle class rather than the rich and powerful. One can only hope. Society is a pendulum, and it has swung too far to the advantage of scoundrels and con artists. It's only a matter of time before it swings back, and I hope I'll live to see it so that's the world my daughter will inherit.

Regardless, I'll be there for her, always. And that has to be worth something. Stéphanie, ton père t'aime et sera toujours là pour toi.

Again with the N800 :-)

2008-09-23T22:25:00.005-04:00

Well, I'm at it again. I wanted to read mangas on the N800, but the only working application, Comix (a Python application) was somewhat slow. Not the Python code itself, which was actually quite fast, but rather the overall approach. You see, to speed up processing, Comix would always unzip the whole comic archive file (cbz or cbr) in a temporary directory and read from there. It does make page flipping faster.

It also fills the N800's main drive as fast as you can say, "out of disk space" :-)

The approach is acceptable on the desktop, where at worse, we're talking about 50 MB of temp disk space for really large archives. Not an issue, even on my relatively small (by today's standards) 80 GB drive.

On the tablet, though, not only is it problematic (you get 256 MB of drive space and that's it!), but even writing to external memory cards is really, really slow. Expect 2-5 minutes before you see the first page, and meanwhile Comix is hung. And woe to you if it crashes–you'll have to recover all this space at the command line.

The crash thing didn't bother me too much, but the slow boot time did. I read fast, especially manga which tend to have relatively little dialog per image. So I started looking for an alternate solution that ran on GTK+ and that I could potentially port.

After swimming through numerous Java applications (useless on the tablet), there were two candidates: cbrPager and Comical.

Choosing the One

Comical initially looked more interesting. It embeds libunzip, unrar (through a special exception to the GPL in the license) and did all image decoding in memory, which I thought could be faster. cbrPager, in contrast, had a similar approach to Comix (unzip to a temporary directory), except that it unzipped only one image at a time. I worried that this would be slow. Also, cbrPager used the Gnome libraries, some of which are not available on Maemo, and I didn't really expect to have to rewrite parts of the UI layer. But unfortunately, Comical is written on top of wxGTK, which is a bit problematic on Maemo (there's a port, but it's hard to get from a repository). So I decided to take a look at cbrPager and do an initial "straight port" using the Gnome canvas and disabling parts of the interface, just to see whether it was fast enough to be a workable base and not force me to deal with wxGTK.

It was quite fast, thank you very much.

I immediately knew I had a winner.

Modifications: Front end

I Hildonized the toolbar and main window, which was relatively quick. Unfortunately, one of the features that's really useful for tablet-based comic book readers is rotation. Comix had it, together with very high quality antialiasing. A small modification to the cbrPager source gave me antialiasing and rotation, but not both at the same time; rotated images looked really, really bad.

Since I wasn't too happy with using the Gnome canvas anyways, and that it was the last Gnome dependency left (I had had to remove all others), I decided to try to find a nice way to replace it. Initially, I was quite ambitious, thinking I'd do raw updates to the main widget. Looking over in the gdk-pixbuf library, it looked possible, as that library had all the bells and whistles I needed: antialiasing with selectable algorithm, automatic rotation, image scaling, etc.

But then I started to think about how to embed the image render in the main view, and my head started hurting, thinking that I'd have to write a GTK+ widget from scratch (it's not hard, exactly, as I've learned later, but I had never done something like that before...). In the end, I decided to look for a plain image viewer (initially I though gqview, since it has the features I'm looking for) and see if I could scavenge their widget.

In the end, I found GtkImageView, which had a ready-made widget and was only lacking rotation. I added rotation and was a happy camper.

Well, almost :-) I had introduced a memory leak that ate all the RAM of the tablet really, really quickly. Fixing it was really simple, but that didn't happen before I crashed my tablet several times in an effort to figure out what exactly was going on...

From the front-end point of view, I then added a few tidbits: scrolling through direct pen usage, auto-rotate, bookmarks (my wife asked for that one really fast...), persistent zoom settings, fullscreen... All of those were pretty easy to add, which speaks volumes about the initial cbrPager code's organisation (hint: it's pretty nice).

Modifications: back end

I then got annoyed that users were forced to install unzip. One nice feature of Comical is that it embeds the unzip code. So I wanted to do the same. For RAR files, I chose not to do it right away because of licensing problems.

To do that, I needed to extract the archive reading logic. It was embedded in command line use. So I chose to encapsulate it in a gobject. This was probably a bit overkill, but it made sense with respect to the use of the GtkImageView gobject.

I first moved the code of the fork/exec logic into a gobject and got it to work that way. Once that was done, it was really easy to get it to work with direct calls to the unzip library.

I had wanted to extract the image bits in memory and decode completely in memory, thus removing the need for a temporary file. I didn't do it that way right then because there were reports of really slow decoding when doing that through pixbuf loaders. Since image decoding was actually slower than archive reading, I decided to pass for now.

Writing a gobject was kinda cool, but those things are really quite heavy... there's a lot of macros and presumably some overhead. Since the same 3 objects are reused throughout the application (one object per supported archive type), the overhead is negligible, but if I had to do it again I'd just go with a struct and function pointers, although it feels kind of silly to do that given that there's already gobjects in the application.

The result

Well, just go download it at https://garage.maemo.org/frs/?group_id=777&release_id=2075.

You can see the announcement on the Internet Tablet Talk forum. There's screenshots.

Just beware, you need a memory card in the internal slot for this to work... I'll work on a fix tomorrow.

Credits, thanks, etc.

Many thanks to the original author of cbrPager for writing the initial code, and for putting up with me :-)

And thanks to the ITT community, who will be my beta testers, as usual ;-)

N800 Update

2008-06-25T22:10:00.003-04:00

Well, after a couple of months with the N800, I must say this was one of the better purchases I've done in electronics since getting my first computer. It's an extremely useful device.

I got a second one for my wife, and it came with an iGo foldable Bluetooth keyboard, which was a pretty good deal. The keyboard is a nice addition, and next time I go to a convention, I'm not bringing the laptop, or at least, not for anything except the tutorials. The tablet is much nicer to carry, its battery can last much longer, and I look like a total geek when I unfold the keyboard and start typing away. Given that I'm now comfortable with my geekiness, this is actually an advantage :-)

Looking at the price I paid for both tablets, it was actually cheaper than many MP3 players, even when factoring in the price of the additional SDHC cards.

So, here's my appreciation of the device after two months of use:

For e-books, total success. I'm nearly done with the Honorverse stuff, and I'll move on to other books soon.
For tech books, I haven't used it much so far because I've been commuting by car lately. But my wife is using it to study for the SCWCD, and although in her opinion it's better to look at her desktop LCD, the tablet is good enough for reading in public transit. And much less heavy than the SCWCD book...
For the Internet, it's really incomparable. No device that size can do it all like this one. I wish they'd upgrade to Firefox 3's final engine instead of an alpha 1 derived version, though. No doubt that's coming soon.
For videos, it works very well, although sometimes hitting the optimum encoding can be tricky.
For games, it's better than I thought in the end. iNES has excellent performance, so old NES games play extremely well. At least iNES has a saner on-screen button system than FCEUltra. Star Control II (The Ur-Quan Masters) is also extremely playable, but you need a keyboard. I use a small PlayStation 2 USB keyboard with an adapter for this, and it works kind of like a mini console controller.

Also good news, the latest release of Maemo, Diablo, has been officially released to the public. I can report that it was a pretty painless upgrade. The browser and flash support seems somewhat snappier, and I'd say the overall OS feels more solid overall. Except for the weather desktop applet, everything from Chinook (previous release) worked very well.

So Nokia can count me amongst their satisfied customers.

Behold my new toy!

2008-05-19T21:12:00.004-04:00

Much to my wife's chagrin, I've acquired a Nokia N800 Internet Tablet. It's been a long, long time since a piece of hardware interested me, so let me tell you about this one.

First, though, some background on why I got one. I got fed up of the huge boxes of books (mostly mine, and mostly old sci-fi or computer books) that take a lot of space in our closets. Also, I'm getting worried that my main bookshelf will buckle and fall under the load; the tablets have nearly 3/4 of an inch deflection at the center. Doubling up the number of books on them was probably not very smart...

So, I decided I'd get an e-book reader.

After a lot of research on the Kindle, the Sony PRS-500 and 505, the eBookwise 1100 and a few rare and too expensive other options (Cybook, etc), I settled on a previous-generation Sony. Unfortunately, it's not really a common device in Canada, so I went to eBay.

The price was rather high in my view, for a previous generation device, and all sellers were shipping by UPS (I really don't like getting packages by UPS, the distribution office is at the other end of the city and they never deliver the package at a decent hour). So, I started looking for other options, such as PDAs, with the philosophy that if I paid more than 200$ for something, it better do more than one thing.

Research on this took a lot of time. Did you guys know that PDAs are a disappearing species? Which is bizarre, in my view, because they are useful beasts, especially with WiFi. But smart phones are killing them. Unfortunately, for e-book reading, a smart phone is not an option... especially since I already have a cell phone (the cheapest I could find) and have no desire to change providers/pay a lot just for getting extra PDA functions.

But after a while, I found a site that mentioned the Nokia 770 Internet Tablet. Being curious (what's an Internet Tablet? Since when did Nokia do something other than a phone?), I researched a bit, and here's a capsule version of what I found:

The Internet Tablet series of devices are 4-inch, 800x480 screen devices with WiFi and Bluetooth included;
The screen size/resolution yields a totally crazy 220 DPI screen;
The screen size means that you can browse web sites from the tablet with a minimum of scrolling;
The screen size also means you can read PDFs in landscape mode without too much trouble, which is a HUGE advantage compared to the Sony PRS 505, which doesn't render PDF too well. As much of what I intended to read on it were technical books that tend to be distributed in PDF, this was an excellent advantage;
And, the clincher: this thing runs a variant of GNU/Linux known as maemo, and hundreds of programs have been ported to it!

I originally thought of getting a 770, but in the end, I settled for an N800, which looked better, had a faster CPU, more RAM, and as an added bonus, is somewhat lighter.

So, what am I doing with this thing?

Reading e-books, of course, mainly David Weber stuff I got on the CD that came with the War of Honor hardcover I bought some time back;
Reading tech books, especially since I hacked evince to be a bit closer to my preferences (I wanted the paging buttons to scroll by screen size rather than go directly to the next page);
Browsing the internet. Instead of staying in our home office to browse 'til the wee hours of the morning, I can finish reading my favorite blogs elsewhere, the idea being that I don't need to stay in front of the PC 'til the wee hours. It's kinda hard putting this in practice, though;
Watching video. This was a surprise, since the tablet is not meant for that and apparently, Nokia sort of goofed the video hardware on that count. But when properly re-encoded, the screen is gorgeous enough and the speaker good enough quality that it's quite a pleasant experience, and doesn't tie up the TV screen. Great for watching smaller clips. My wife and I have been listening to a couple of episodes of La Linea every day when we feel like it;
Games. This was somewhat disappointing so far, because the d-pad isn't the best thing in the world, emulators run slow, and button placement is awkward. ScummVM was the best success so far, probably because it's already mouse-based.

But the most unexpected development of all: lately, I've stopped having much fun with my Xubuntu box, because, besides small, occasional sound card glitches I had when following Hardy, I've been having no problems at all... and no incentive to do a re-install. In fewer words, I was getting bored. But the N800 is a new environment. Even though it's GTK+ based, there's lots to do--it's still somewhat rough, and there's a lot of stuff to port to it.

I got the urge to hack on it just for fun.

The first thing I did was recompile evince (a PDF viewer, slightly more flexible than the one that's included by Nokia) to give it key assignments I like better. If anybody wants the patch, I'll be glad to provide it (it's quite trivial). Setting up the cross-compiling environment (known as scratchbox) wasn't the simplest environment setup I've ever done, but after a couple of tries, I got it to work right. I had to try a second time because somehow, I hosed the first version when switching targets.

The second is far more interesting. As I was complaining about the hand writing recognition on the tablet, somebody at the office pointed me to the QuikWriting system by Ken Perlin. That system lets you write without lifting your pen, and the overall mechanism is much less error-prone than hand-writing recognition. I looked and looked for an implementation and could only find an old one for Qtopia. I really wanted to try it out on the tablet to see if it was a viable option.

Finding no port, I ported it myself. The result is available in the maemo Garage. It's not quite finished--namely, I'm a bit annoyed at the current letter display, and international support would be nice. I'd also like to refactor the code and render the input areas using vector graphics instead of a stupid bitmap.

Still, it works right now, and I'm using it in production.

Doing this was the most fun I had in a long time.

As for my wife, she asked me to buy her her own N800.

A nice new toy, indeed! I'd recommend it to any GNU/Linux-head out there. It's pretty capable, the build quality feels solid, the battery life is good, and the screen is fantastic. I give this device 9/10, and I'll be sure to look out for the next version.

(Addendum: yes, I know of the N810, but the hardware is very similar, so I'll probably skip it. My dad got one, though, and he's also having fun with it.)

Musings from EclipseCon 2008, part 1

2008-03-18T16:21:00.005-04:00

I totally forgot to mention it for the longest time, but having a fruit hat picture on my blog landed me a free entry to EclipseCon in Santa Clara, CA, USA. Alogient was kind enough to pay for my transportation and hotel room.

I'm writing this from there; the connectivity is really good overall, I wish I'd been wired like this last time I went to a conference...

I'll have more things to say about the overall experience later, but right now, there's an interesting thought I want to write down.

Today's keynote was given by the guy behind Fake Steve Jobs, who, at one point, made an interesting (if not very original) parallel between Apple and a cult. It's mostly interesting because during lunch, I sat at the "Maven" table (and unfortunately, none of the m2eclipse or q4e guys were there--guys, you suck! :-) and one of my lunch colleagues made the reflection that people get on the Maven train because they've invested so much time learning it that they want it to be worth something.

Note that the guy saying that being wry, and we all had a good laugh. But it got me to think that Maven could be seen as a cult as much as Apple, but for totally opposite reasons:

Apple is a cult because they do products that are designed and work really really well the first time you pick them up;
Maven is a cult because it does not work at all the first time you pick it up, and probably the converted really just want other people to suffer as much as them :-)

So, now you can decide whether that's the reason I'm a Maven fan...

Maven (non)-bashing

2007-08-26T21:31:00.000-04:00

Looks like the popular sport of bashing Maven continues. Just thought I'd add my own opinion to the mix.

Background

At work, I've instated Maven use for new projects as well as some active projects (those I could get people to migrate, anyhow) about nine months ago. My reasons were the following:

We had a crufty Ant-based build system (which I built myself, I'm ashamed to say--I think my only excuse is that it replaced another, cruftier Ant-based build system with really wonked dependency management), and some of its persistent bugs (wonked version number handling and unversioned third party libraries) were really starting to get on my nerve and other developers';
I'd tried out Ivy, and I had problems getting it to just work (this was way before the current version, at a time the documentation was rather sparse);
A co-worker started bugging me about "why not Maven," so I got curious;
I finally found out how to adapt the pom.xml file to a non-standard directory structure, from the Wicket project's pom files. This was the clincher, because I really hated the standard Maven layout (especially separated code and resources directories--ugh) and I wanted to be able to retrofit our old projects that had a more widespread layout (source in src/, tests in test/ and webapp in www/).

Initially, I was the only Maven user in the whole place. I introduced my team mate who worked on the same project I was doing, and more recently, I ported a whole bunch of legacy stuff to use Maven instead of the old script, declaring that if that stuff could be ported, anything could. Two other co-workers started using the Maven build at that time, and so far, they feel it's been positive.

Maven bashing

OK, fasten your seat belts, folks, because that's going to hurt.

I had two huge problems with Maven:

Bugs
Very, very generic documentation for many non-generic tasks, like sofware release (mvn release:prepare and mvn release:perform)

The main bugs I hit were huge bugs with the CVS SCM provider that made the release plugin basically unusable. I tried fixing it myself, but I nearly burned my eyes out navigating the SCM module source code. This is another sub-complaint: the code quality is, frankly, not that amazing. It's a bunch of too-small modules strewn together, and sometimes the modularization is pushed a bit too far for my tastes: you get a package with interfaces only, a package with the implementation, a package with just the model created automatically from modello files, and then a package for each different plug-in. That's two extra packages, in my view, and it means a very high cognitive load.

The main problem with the documentation was that it was highly variable. Sometimes, you get amazing details, lots of examples. Sometimes, you get a glib description and the goal documentation (note to plug-in developers: the goal documentation would be much better if the configuration parameters were actually explained; sometimes, it's not clear exactly what a term means in a given context, and being told "localRepository: local repository path" does not help much). Sometimes, you only get autogenerated stuff with no description whatsoever.

Also, I wish more attention were paid to error messages. This is a common problem in software, however; Maven is not the only (nor necessarily the worse) culprit. Exception: the archetype plugin is one of the stupidest thing I've seen from an error-reporting point of view. When it's missing files, it just throws "unable to copy file" without having the decency to tell you which one... even the stack trace is mum about this.

Maven praises

However, I'm not convinced that this is an excuse to ditch the whole system. The main concepts, if not necessarily the code, are quite solid. I wish there was a way to specify ordering when binding many plug-ins to a single phase, but that's the kind of stuff that's not needed that often.

Maven works mostly as documented, and when it works, it works really, really well. In my experience, it's relatively speedy (at least, compared to my hokey ant script). The release plugin, now that they fixed many, many bugs with CVS interaction (actually, the CVS plugin may have been the culprit, I was never able to ascertain this because the code was really "indirect" about it), works beautifully.

Writing a plug-in is really easy. Even compared with Ant tasks. Yes, it's that easy. It's a shame some Plexus or Maven core stuff is so poorly documented, but you can usually figure it out by looking at a similar plug-in.

Despite what a lot of people say, it is very much possible to have Maven work outside its standards. You'll have to be more verbose in your pom.xml, or use a parent pom. Wicket, as well as our own projects, are testaments to this flexibility. You have to hunt around for information on how to do this, but it is available on the Maven site.

Conclusion

Despite some shortcomings, I truly believe Maven is a very good build system. It was maybe a bit too ambitious at first, but since 2.0.5, it started being able to deliver on those ambitions. It is also much more flexible than people give it credit for.

For those banging their heads with it, I advise that you look at the Wicket and AppFuse pom.xml files. Likely they've solved your problems already, so you can just ~~steal~~borrow their solution. :-)

Assertions in Eclipse

2007-08-10T08:55:00.000-04:00

A small trick I found. While running unit tests, I realized that the Maven Surefire plug-in enables assertions during the test run, while Eclipse does not do so (at least, not by default). Looking for a way to enable assertions at unit test time, I found that you can go to Windows | Preferences... > Java | JUnit and select the "Enable assertions for new JUnit launch configurations" checkbox. Hope this helps somebody somehow.

3 things I learned about software in and out of school

2007-06-30T22:00:00.000-04:00

Following the lead of Carnage4Life and Scott Hanselman, here are my own items:

Three things I learned while in school

Some people can program, others can't. Those who can't will never be good at programming, even if they work really, really hard. I learned this when I saw somebody stare at a compiler error message for 30 minutes (until I helped them with it) for a simple missing parenthesis! Staring at the error message for more than a minute is not going to help you figure it out when all it says is "Parse error..."
It's hard to know when to stop generalizing. I learned that in Software Engineering when we had heated discussions about whether we should bring generalizations to the next level, something I was very much against.
Working in a group is more fun, but can be disturbing to by-standers.

Three things I learned while not in school

Business people tend to ignore technology under the pretense that business concerns are more important, but it's not a good idea. Technology problems don't really go away by themselves, even if CPUs become vastly faster every year.
Software is a highly volatile industry. When I left school, it was the .com boom, 99.99% employment, etc. etc. Since then, I've seen ups and downs, but always in a very protracted time period.
As you grow older, your experience will tend to grow stale. The reason for this is that as you gain experience, you are more and more likely to become the team lead or senior programmer of your team. As such, you won't have anybody to "pull" you forward as you did when you team lead or senior guy was there and you tried to show off that you were a better coder/designer. The only fix is to always remain open to ideas, regardless of how junior the person who expresses the idea may be most of the time.

Lesser known IoC containers

2007-06-27T23:30:00.000-04:00

The point of this article is to talk about my experience with IoC containers other than the 1000-pound gorilla in the IoC container space.

Through some interesting circumstances (mostly, my hard-headedness about not including 15 megabytes of stuff just to get an IoC container; note that I do know Spring is modular, but it wasn't at the time), I'm one of the few people who hasn't been using Spring. At work, we've mostly used PicoContainer as our middleware "glue" layer. I've also dabbled with Guice, and Plexus (a bit) when messing around with Maven Mojos. This is a summary of my experience with each.

PicoContainer

Let's cover the IoC container I feel I know best first--PicoContainer. PicoContainer is a small (the JAR is 100 KB or so), type 3 (constructor injection) IoC library.

And that's pretty much the only thing it will ever be, if you don't customize the library. It does constructor injection. It supports hierarchical containers to resolve dependency conflicts. And that's it.

However, the real power of PicoContainer is its open architecture. You can implement your own component management strategy by implementing ComponentAdapter and ComponentAdapterFactory. There are a few example adapters. But overall, this lets you futz around with the component instantiation without having to resort to aspect-oriented programming or exotic annotations. Also, since you are in full control of which ComponentAdapter is used for which component, you can completely customize the instantiation on a per-component basis.

As an example of how useful this can be, it was very simple to implement a specialized adapter that can inject some dependencies through construction injection, and then looks for more dependencies to inject using setter injection. When my experiences with Guice left me somewhat lukewarm, I was able to quickly whip up an @Inject annotation for PicoContainer.

Finally, the hierarchical container facility is extremely useful for one-off dependency injections, such as injecting dependencies in objects retrieved from the persistent store by Hibernate.

So, in conclusion:

Pros

Very small
Reasonably fast, to the point that it can be used with throwaway containers
Works even with old JDKs such as 1.4
Component adapters are extremely flexible
Containers are very lightweight, can create and throw away child containers at will

Cons

The authors believe constructor injection is the only viable option. However, although constructor injection enforces integrity, it's also very awkward, especially when you get more than 5 dependencies. OK, you probably shouldn't have that many, but sometimes, especially in Struts actions or some other equally centralized point of logic, you will get that many, and it's still less awkward than having a façade just to cut down the dependencies.
Although the adapters are very flexible, there are very few useful implementations that come with PicoContainer. One that supports Guice-like semantics would be welcome.
The hierarchical system for resolving dependencies works well in some situations, but is extremely awkward in others. Granted, it's possible to write a component adapter that uses an alternative resolution mechanism, but in the IoC realm, PicoContainer is a bit like assembly language, or Forth; even relatively common cases have to be implemented by hand.
There is relatively little integration from 3rd-party frameworks (such as Struts, Wicket, and so on). On the other hand, such integration is always very simple to write with PicoContainer, which is not necessarily the case with every IoC container.
Error stack traces are OK, but sometimes very confusing; specifically, it's not always clear which dependency was missing when trying to instantiate a component.

Summary

If you want a small container and don't need many fancy features, or if you prefer to write such features yourself to gain maximum flexibility, PicoContainer fits the deal. In my mind, it's more of an IoC library than an IoC framework.

Guice

Guice is a relative newcomer in the IoC container arena. Its main claim of fame, despite what its adopters will tell you, is that it comes from Google. Also, unlike PicoContainer, it came out at a time where people started being annoyed at massive XML files, such as those that show up in many industrial Spring-based code bases.

It immediately grabbed the interest of many a-bloggers, showed up on dzone, yadda yadda. The question is, can you believe the hype?

Well, underneath the hype is actually a very nice IoC container that goes the extra mile to provide you with near-perfect error reporting, and that is not afraid to sacrifice purity to the altar of practicality. Guice supports, out of the box, all sorts of dependency injection scenarios, provided that you mark your dependencies with the @Inject annotation. From the theoretical point of view, this is more invasive than a run-of-the-mill IoC container, since classic IoC containers should, in theory, let you use plain objects without any special annotations. This, many argue, makes Guice much less flexible than Spring or PicoContainer.

In practice, I found that adding annotations makes sense in most cases. Externalizing all dependency-related informations sounds great in theory, but in practice, you'll end up with 80% of your services having only one sensible implementation. The services with more implementations have different-enough implementations in many cases that the POJO that receives it works well only with one of them (I estimate that about 10% of application services are like this). Guice's use of annotations to mark injectable resources and to let the target object control what resource gets injected to some degree is very practical.

The IoC container is pretty fast, and does some wicked ASM and cglib-fu to provide precise error reporting and the best possible speed regardless of the situation. Overall, it has an "advanced technology" feel to it. It shows a lot of polish in its package structure and in name selection.

However, Guice is a very "closed" system. Being advanced technology is nice, but it does make certain kinds of things a bit more difficult. Here is an example of such difficult things, and incidentally the reason we went with PicoContainer at work. Guice comes in a "uber jar" format; it bundles two versions of ASM (one for cglib, and a more recent version for itself; ASM is noted for major incompatibilities between minor versions, much to the annoyance of projects using it, and cglib appears to be evolving very slowly these days). Hibernate also uses a version of ASM, albeit an older one, as well as the same version of cglib as Guice. So, in an effort to trim the 550 KB or so JAR file to its bare minimum (remember, PicoContainer takes 110 KB...), I tried to get it to work with the older ASM version. The only part that didn't compile was some code used for error reporting, so I figured I could live without it. Well, I was wrong; the previous version of ASM crashes and burns during unit tests. I'm wary of dismissing obscure crashes to situations that will not happen in production code (even though the failing unit test looked like it was doing something exotic), so I left it at that, figuring I was better sticking with PicoContainer and bloating our applications as little as possible.

Some may dismiss this as a trivial reason to not use Guice, and in some ways it is. But it is something to be aware of. I know Hibernate, for one, has had all kinds of problems with use inside environments that come with a different version of ASM. So I'm a bit wary of such annoying dependencies, especially on ASM and cglib which are known troublemakers. Granted, the problem is a bug in ASM, but it does mean that Guice's use of ASM is exotic enough to trigger that bug.

Another problem with such a closed code base is that it's hard to extend it without releasing your own build of it. I'm not that keen with depending on an annotation that's inside the IoC container's package; I'd prefer depending on, say, the @Resource annotation that's standardized in a JSR (granted, it's not supposed to have exactly the same semantics, but my point is that I dislike putting hard dependencies at the POJO level). I understand the necessity of the annotation, and it's no worse, in my mind, than the transient or volatile keyword. Except in one way: it binds the code specifically to Guice, not just any IoC container. It would be nice if you could ask Guice to use another annotation type (this is noted as issue 70 in their issue database), but right now, you can't.

Pros

Still reasonably small
Very advanced, gives a peek of what libraries can look like if people would start to target Java 5 (see also Stripes)
High-tech, uses all kinds of tricks to maximize performance and give the best error reporting possible
More popular than PicoContainer at this point, is getting all sorts of frameworks integrated with it
The only IoC container I know of that allows post-instantiation injection of dependencies for non-constructor injected services. This is actually a great idea in some cases (such as deserialization)
Used in Struts 2. So it's going to end up being used by somebody visible, unlike PicoContainer :-)

Cons

Sometimes too advanced; that kind of trickery can hurt if you get bit by a bug (admittedly, there doesn't appear to be many of them)
Binding on a specific in-package annotation is annoying, I'm curious as to why there isn't a way to configure it?
Not an open architecture the way PicoContainer is. It's very easy to futz around with PicoContainer internals. Guice is much more selective with respect to what it lets you do or not do.
Java 5 only. Not that I care, but somebody might. Though, they did manage to make it work with Retrotranslator.

Summary

If you want a rich IoC container without the huge XML file tradition (yes, Spring folks, I know about JavaConfig, but it's still not what most people use), with sensible defaults and excellent error reporting, Guice fits the bill. However, if you want something with a hood that you can pop open at will, you may prefer another IoC container.

Plexus

I haven't played with Plexus a lot, so I can't really give too many details. My only experience was inside the Maven 2 codebase.

As far as IoC containers go, it looks OK (although it does suffer from the XML configuration file syndrome, the XML files are lighter than Spring 1.2 configurations [though not Spring 2.0 configurations], and you can use JavaDoc tags to autogenerate the XML file). However, I felt a bit annoyed at it overall. Error reporting, at least within the Maven environment, is not that great, even for simple mistakes like forgetting the appropriate JavaDoc tag or misspelling something. Plus, I can't really figure out where this project fits. It doesn't look like a project that's used by anybody except the Maven guys; why didn't they use PicoContainer to start with instead?

There are a lot of plexus components, but they don't tend to be that reliable, or their use within the Plexus infrastructure is not consistent. A good example is the password input component. Some Maven components use it, some use a plain text input component instead. It's not quite clear, when developing Plexus aware components or Mojos, which you're supposed to use for what.

A pet annoyance of mine: the Plexus guys want you to obtain the logging service through dependency injection. Although that sounds great in theory, I think it's nuts. Logging (at least, programmer logging) is purely a developer service. I'd even prefer not having to create a special object to start logging--if it could figure it out from the current stack with reasonable performance, it would be much better. So, if, to get logging, I need to create a field, a setter, and configure something in an XML file... I'm not going to use logging, or at least, I'll use Jakarta Commons Logging or SLF4J and just forget about Plexus logging.

So, all in all, it looks like an interesting project, but I don't really know why anybody would use it over Spring, or Guice, or even PicoContainer. I guess every developer likes to write an IoC container, because although it's not too hard, there are enough challenges and futzing around with reflection or byte code engineering to make it an interesting task.

Closing thoughts

So, there you have it, a quick round trip of some lesser-known containers. I also know of a few others:

HiveMind/Tapestry-ioc, the container behind Tapestry. Well, this one looks powerful, but like Tapestry, it changes wildly between releases, and releases happen relatively frequently. From a pure technology point of view, it looks very powerful, as HLS does not mind looking for good ideas in other projects.
Yan, a relatively unknown container that appears to allow injecting almost everything in almost anything. The author is one of the few who documented how to use his container in rich domain model. The Spring guys have allowed this only very recently, and it requires the use of the AOP sledgehammer to get it to work.
And, of course, Spring, whose basic container is becoming more powerful with every release thanks to ideas from all those lesser-known projects, but which remains a huge project. Granted, you can use only parts of it, but it's not the standard usage.

I hope this (longish) post will be of some use to somebody.

Eclipse Europa Review

2007-06-18T10:53:00.000-04:00

About this review

OK, so it looks like I can win a t-shirt doing an Eclipse Europa review, and it happens that I've been using it since M7 (the last release before RC0). So, even if I don't get a t-shirt, I'll post this, because I'm a nice guy and I want people to benefit from my living on the bleeding edge.

Before going on with the review, it would probably help readers to know what my Eclipse usage profile is. I use Eclipse mostly at work (http://www.alogient.com), where we build web applications and web sites. I'm currently doing a lot of work on a transactional Java application, using Maven 2 as the build system, Struts 1.2.9 (yes, I know, it's old... it's also stable and well-known), Hibernate 3.3.2 + patches, PicoContainer 1.2, Jakarta Commons Lang and Collections, and other miscellaneous libraries.

Given that, I won't use a lot of the new features touted by Europa (and specifically WTP 2.0), such as JPA and JSF support. JPA may get some use someday. JSF... nah. My only experience with JSF was extremely painful, so I don't really want to use it.

So, let's see the new features I'm likely to use in WTP:

Support for JSP tag files. We've started to use JSP tag files quite a bit, and I'm looking forward to better support for them.
Better HTML and JSP formatting when requesting a "format everything" (CTRL-SHIFT-F)
Better publishing performance.
Improved "maximize editor" behaviour.
Improved generics warnings.
Rename refactoring changes.
Ability to refactor without saving.
Class editor showing disassembled code.
Improved presentation of libraries in project explorer.

(In case you're wondering, I've had to recall this from the new and noteworth pages, because I've been working with Europa for long enough that I don't recall many specific enhancements)

First impressions

My first impressions once I boot the new Eclipse is that they've made it a bit faster, again. I can't really quantify this, but overall, the IDE feels snappier, especially when dealing with the WTP features. This is a great time saver in the regular look at web page/fix bug/publish/restart server cycle. More speed is always a good thing, especially since I run Eclipse on Linux/GTK+, which is usually slower than under Windows.

The workspace switching improvements are welcome, letting you switch between recently used workspaces without having to open the "Switch Workspace" dialog.

I initially imported my settings from a settings export of 3.2.2. This worked mostly OK, except for the XML syntax highlighting which, somehow, always loses my colors. This is very annoying, given that I like to use a dark background for code (OK, XML isn't really code, but it still gets a dark background). Even after importing my settings, the XML editor ends up having all content and CDATA sections in black-on-black. This kind of thing is commonplace in Eclipse and is generally annoying.

I took our main project (with its project files generated by Maven) and published it to Tomcat 5.5. It worked like a charm, and publish was significantly faster, especially the initial publishing operation.

From a stability point of view, M7 was so-so, but RC0 was pretty solid. I've yet to see it behave badly. It looks more stable than 3.2, especially the WTP features.

Refactor changes

One of the "big deals" with this release is the "inline" rename refactor. Essentially, you select the "rename" refactor (CTRL-ALT-R) and instead of getting the old rename dialog, you get to retype the new name and press enter; the rename is then applied. I've seen this feature in IntelliJ IDEA as well.

My experience with this feature is summarized as follows: I turned it off. There were two annoying things with it:

I often fire the refactor with the cursor in the middle of the identifier to rename. Eclipse doesn't pre-select the identifier, so typing the new name immediately doesn't overwrite the old name; instead, it inserts the new character at the position you were in. I assume some people like it that way, but I'm used to the old way of working, and to me, positioning the cursor prior to invoking the refactor interrupts my flow more than typing the new name. Note that I'm a fast typist, so this may make a difference.
After running the refactor, all editors "flicker" briefly, and I'm always worried that the refactor wasn't applied properly or something. I agree that this is largely psychological. But it's another reason for which I turned off the new feature.

So, your mileage may vary, but I think it this feature could get a little bit of polish. Maybe having an option to auto-select the renamed symbol so retyping would overwrite the old name. At least, from a "key feel" point of view, it would be more similar to the dialog, without having to lose the advantages of the in-editor rename (you see more context, it's less obstrusive, etc. etc. etc.)

The other big change I noticed in the refactoring support was the ability to refactor without saving files. This appeared to work well, and it's seamless enough that I'm not nervous about enabling it. The only thing that's slightly annoying is that when you build automatically and you do certain refactors with global impacts, Eclipse may flag a bunch of errors until you save your refactored file(s). This is probably due to the way the compiler works. But it's really not a big deal at all.

HTML and JSP improvements

The new HTML and JSP formatters are very much welcome. They do a much, much better job than the old ones, and I can actually (gasp!) use them to format blocks of JSP or HTML without fear. The old ones really mucked up our JSPs. The ones I've tried the formatter with use JSTL; I haven't tried it with scriptlet-heavy files, but hopefully, I don't have to work with those for some time. :-)

The JSP tag file support appears to work well. However, thanks to the use of an Appfuse-like taglib include at the beginning of every JSP file, it doesn't work in my everyday job, because the taglib declarations are stowed away in another JSP fragment. It looks like Eclipse doesn't see them in this case. I've resorted to copy-pasting the declarations temporarily while I work with the file so I can benefit from autocompletion. In that case, it works well.

Unfortunately, it doesn't work that well with custom tags sitting in custom JAR files that come from internal projects. I have that small library with JSP tags, which is included through a project dependency. I could never get autocomplete to work with those tags their TLD file is in the META-INF directory of the source tree). Oh, well.

The tag file support also works for editing the tag files themselves. This is not a big deal, but it does avoid a bunch of spurious warnings about unknown tags when working with those. If you use a lot of tag files, you'll be much happier with WTP 2.0 than with 1.5.

Additional polish

The new look when maximizing editors (with the package explorer, etc. minimized to the side) and the fact that minimizing the docked windows actually minimizes them (instead of turning them into a space-wasting horizontal bar) is a much overdue enhancement, and I'm very happy it's done. Also, the fact that maximizing the editor window does not close the secondary tab group is very welcome, since I tend to work with two tab groups, a habit I've kept from my old Emacs days.

The additonal diagnostics for generics are somewhat useful. They do catch a lot of strange corner cases in the generics specifications. Since we use generics rather heavily (and sometimes in exotic ways), I'm happy with this addition, but I think most developers won't notice.

The improved library presentation also fixes a small annoyance. I used to have to filter out all libraries from the project view to avoid having a huge set of crap in there. Especially for Maven-driven projects, which include every JAR in the world, this is an important feature.

Finally, the class disassembly is very nice, but unfortunately, with Maven's automatic source download feature, I don't use it anymore. Wish I'd had that a year ago...

The less good

This is supposed to be a balanced review, so I have to say something bad... bear with me.

The main annoyance with this release is that a lot of those new features have additional preferences, but those only overload the already busy preference panes. One more checkbox here, one more checkbox there, and you end up with a huge amount of checkboxes. The Eclipse preferences are comparatively messy compared to, say, Netbeans'. In all fairness, Netbeans' doesn't let you configure all that much unless you go to advanced mode, but maybe an advanced mode is what Eclipse needs. All I know is that it's starting to get really, really busy in there, despite the fact that some preference pages have very little on them (see General | Search, for instance). To me, it looks like the nature of the project (it's a plugin-driven platform) has unfortunate side effects when it comes to preference management.

The only other annoyance for me is that I was becoming spoiled rotten with the new features every minor release of Eclipse was bringing. This release does not bring much new stuff, especially from the basic IDE front. This is somewhat less true of WTP, but I'd still like to see more advanced IntelliJ features in WTP, like advanced refactoring support for CSS files. As such, Europa is a bit underwhelming. It seems like many of the features are "gadgets", and there isn't much new stuff. I'd like to see implementation of more refactorings, for instance.

Final throughts

Still, despite all this, it looks like a worthy release. The additional features in WTP are nice, and it's probable that the JSF developers out there will be even happier. And, despite my whining about the lack of "big" changes, the small things count quite a bit as well, such as the new maximized look and the increased performance.

Is it worth upgrading from Eclipse 3.2/WTP 1.5? Well, maybe. I guess it depends what features you're using. For me, it was worth it, if only for the increased performance. It will be worth it eventually anyhow. But for the average Java/JSP developer, I'm not sure there's a compelling reason to upgrade as soon as it's hot the press. For EJB or JSF developers, the picture is likely to be very different, but I admit that I don't use those technologies much anymore.

Still, Eclipse will remain my main IDE. As an aside, yes, I've tried Netbeans 6, but there's always something in the way it wants to work (usually with web projects) that don't match my way of working. Eclipse is very complex, but it's also very flexible, and I always manage to make it do what I want. That is why it remains my main IDE, and why I'll upgrade to Europa. Hey, what am I talking about! I'm already running it! :-)

Technical difficulties

2007-06-18T10:50:00.000-04:00

It seems the old domain (bge.kernel-panic.net) does not work anymore, for reasons unknown (I don't host stuff there myself). I need to blog somewhere, so I moved the stuff to a generic blogspot address. Annoying, but sometimes, stuff like this happens. The new address (at least, temporarily) is http://bge-kernel-panic.blogspot.com. Sorry for the inconveniences. Have a nice day anyhow...

Odds and ends

2005-09-05T22:10:00.000-04:00

I saw a couple of interesting things on TV today. First, there was this report of protest over the Gentilly 2 nuclear reactor renovations¹. As you may already have guessed from my not-entirely-green opinions, I think those protests make no sense. Building a new nuclear reactor may be questionable (and then again, maybe not--nuclear waste is a huge problem, but so is the greenhouse effect, and at least the former can be found and contained with relatively primitive facilities). But Gentilly 2 has been built, and we can either get rid of it now (and thus make this costly endeavour more costly), or fix it, run it for 20 more years, and amortize the cost of getting rid of it over a longer period. Yes, Hydro Quebec is building a wind power park; that's not nearly done, and in the meantime, we're stuck importing electricity from coal-fired US electric plants. Turning off Gentilly 2 would make it worse.

On a related note, if the protesters are also those against new hydro dams, I have to wonder how they thing we'll build the windmills they are so in love with. Answer: lots of petroleum, and a bit of hydro to power the facilities while they're assembling the stuff. We'll be lucky if we can maximize the use of hydro power. The fact is, as things stand right now, it's extremely inconvenient to carry electrical power, so we're very much slave to oil when it comes to building stuff using heavy equipment. The energy density of windmills is much lower than a dam's, so I wouldn't be surprised at all if the amount of oil used to up the wind power capacity is larger than that used to build one of the humongous hydro dams that make our pride in this province. The main reason for building windmills is when hydro dams have all been built and the demand still rises.

Yeah, demand could go down too, but it's a bit late to think about this--too many buildings built with poor insulation, too many joules wasted for no good reason except to save a few pennies in construction cost, etc. We'll just have to regulate for better energy efficiency and hope we'll stamp out those obsolete energy wasters sooner rather than later. By the way, I agree with ecologists that both the provincial and federal government are really being idiots about this. I'll excuse the provincial government somewhat because it has no money, but for the federal government, this is unacceptable. They're sitting on a multi-billion dollar surplus, and instead of lowering taxes or attempting to conform to the Kyoto protocol they're so proud of having ratified, they're just pissing off the provinces trying for a political land grab. The tragedy is really the lack of alternatives; the Liberal Party really needs a kick in the <somewhere> to wake them out of their arrogance. If they don't want to lower taxes, the least they could do is gain political favor by showing leadership on the energy front, instead of duplicating provincial programs.

But I guess that while Canada still makes a lot of money off tar sands, there's little incentive to do anything like that. Why not do both, export all the tar sands, let other countries foot the Kyoto fine, and laugh all the way to the bank? Oh, wait, the US is our main buyer and haven't ratified the protocol. Damn it.

And before your friendly neighborhood defender of the A-25 bridge (which, by the way, does not look like it's going to happen--we'll get a "urban boulevard" on Notre-Dame street instead, and I'd rant about this, too, except I'm so disgusted I can't find the energy) is written off as a quack because he's inconsistent, I'll let you all know that I've been biking up a storm lately. I've also been buying local fruit and vegetable as much as I could, which is less than I'd like because growing season is too short here. I'll also let you know that my CO₂ emmissions are 1.64 tonnes per year, according to the Climate Change site (which, I guess, is the only tangible thing the federal government has done about Kyoto...). Provincial average is 3.7. I can't go much lower than that if I want to survive winter, either; taking all their suggestions would lower only to 1.4 tonnes per year, mostly by recycling. There is no recycling in this building, because of some lame-ass municipal bylaw, and that's the part that hurts the most.

I find it ironic that the calculator admonishes me for not lowering my emissions by a whole ton, when one ton is 66% of my CO₂ emissions. There's not an awful lot more I can do, either; I barely use the car anymore, not using the A/C and dishwasher would save something like 75 kg of CO₂ per year, and I can't compost because I have no yard (condo life, you know--I'm sure I'm saving more emissions by having to heat less).

On the biking subject, I'm starting to get serious about it. I bought some new bags for the rear rack (the old one was cheap crap and its zippers broke; the new one uses a pull rope, which is a much smarter system, and it's made in Quebec to boot), a small rear-view mirror for my helmet (looks silly, but still a good idea), and biking shorts. The latter were expensive, but well worth it. I feel like maybe I'll have children someday after a long ride, which is something I wasn't too sure about when I rode with regular shorts. My perineum would feel numb after 25 K or so, 30 K if I was riding on nice, well-maintained pavement (which doesn't really exist in Montreal, I'm sad to say).

Let me tell you about my latest bouts of crazyness.

Two weeks ago, a very good friend (who is now my official biking partner) and I took the south trail. I joined her around St-Michel and Jarry East, we went to Christophe Colomb, all the way down to the Old Port, right to Pont de la Concorde, down to Jean Drapeau park, got lost (laughing most of the time) in Jean Drapeau park, decided not to go to the south shore given we had done the Ile Notre-Dame trail twice, went back up the Champlain Bridge Estacade, through the Lachine Canal trail, then back home after nearly dying on the Berri climb. The Berri climb, by the way, is much worse than I had expected. Halfway up, you feel great. Then the wind blows you nearly back down the hill, and the second part, while shorter, is steeper. You do the whole think in first gear, believe me, especially if you've just done 35 K. Total, about 45-50 K.

Last week, we took the north trail, joined by her brother and sister-in-law. Christophe Colomb to Gouin, west all the way to the Bois-de-Liesse park, then on Pierrefond Boulevard all the way past St-Charles to the next park. Then back the way we came. Much less strenuous, but much longer. The trails that way are extremely nice (though with a not-too-nice view on the Hydro Québec high-voltage power lines), and except for a rather disagreeable stint on Boulevard Pierrefond where there's a one-block stretch without a trail (I swear! This is the silliest thing I've seen in bicycle trails, but it's true!), very enjoyable. Total, 80 K for me. Odd thing was, I felt tired, but I didn't feel cramped up the following day. Admittedly, we took it easy. It's still 80 K, and still impressive. I dislike doing that much distance in a car!

Today, went solo to the east, my friend being out of province on vacation. They have this new trail next to the De Montigny stream, going through the Marie-Victorin college grounds and the Rivière des Prairies hospital. Going to the trail is a pain, though. Up an industrial street, hoping to see it connect. Didn't. Had to cross Henri-Bourassa, a rather busy and wide boulevard. Luckily, this was labour day, so it was rather calm. But you can picture me running like an idiot next to my bike because there was no ramp to go on the sidewalk on the other side of the street. Next time I'll cross elsewhere (Renaude-Lapointe, maybe), but it's still likely to be not much fun. Anyhow, I then lost the trail on Maurice Duplessis, I think I turned left instead of right because I found its end on Boulevard Léger. Traffic is light despite the very wide roads there, though, so not a problem. Then on the East Gouin trail, which was overall nice. Then the Pointe-de-l'Île park, which was a bit swampish, but overall OK and mostly free of pesky insects anyhow. Then down to Pointe-aux-Trembles, which alternated between nice trails and so-so trails next to the railroad (lots of brush in the way there; it seems like they're not really maintained). Then a disgusting segment on the sidewalk in Montréal Est. This part alone makes me wary of doing that trail again; the air was full of petrochemical and solvent smells, and I wonder whether it cancelled any health benefit I got from the ride. Then a surprisingly nice part in Promenade Bellerive, which made me forget about the ugly part from before. Then another disgusiting part in Hochelaga, where I stopped at the local Tim Horton's to get a sandwich. Then a part not worthy of being called a trail on Notre-Dame street; it's so incredibly bumpy and badly maintained that I would've been better off going up l'Assomption to Hochelaga and brave the annoying traffic. Then got lost and missed Viau, ended up on Pie-IX, turned on Ontario to join Pie-IX, up the hill (walking) of the Olympic park (it's short, but it felt like 30% grade), one lap of the Maisonneuve park, then back home through Boulevard Rosemont and Beaubien.

I have no idea of the total mileage; probably around 50 K. But I rode at maximum speed for much of it and stopped only three times (once at the park, once at the Tim Horton's at Notre-Dame/Dickson, once before entering the Maisonneuve park because the hills had taken a lot out of me). I expect to be somewhat stiff tomorrow. Overall, I liked the trip, but the part through Montréal-Est really sucked. I'm likely to go to the Promenade Bellerive in the future to kill a few hours, though; it was a really, really nice place, and not nearly as busy as Parc Maisonneuve; also, going over the A-40 east is less stressful than going over it at Viau, because there's less traffic and the lanes are wider. But I'm not sure I'll do the whole east-end-of-the-island trip again, mostly because of the poor state of the Notre-Dame trail. From a pollution point of view, though, the Champlain Bridge part is probably similar, because you're travelling under the busiest highways of the area. Though, I guess being under means a lot of lighter particulates don't enter your lungs. Still, the west Gouin trail was much nicer, though it is less interesting, in the sense that the east part fools you into thinking you're in the middle of the countryside, then throws you in dense residential areas intermixed with industrial complexes.

So, remember that heading "I must be crazy?" Well, my sanity isn't improving. I suppose my health must be, though. I hope I can do some cross-country skiing this winter, otherwise it's going to be really boring waiting for next spring.

If you want a decent bike shop in the East End, I'd recommend André Lalonde Sport, on Métropolitain East, a bit east of Langelier (though you have to do some creative acrobatics to get there if you're eastbound on A-40). It's pretty close to my home, and they were having a summer sale, with many things 50% off. That's where I got the shorts and stuff. The bikes there look like they're good quality; maybe I'll get one of the hybrids there at the end of next summer. The Schwinn is somewhat capricious (the rear brakes tend to become loose) and heavy; it's perfect to ride to the metro and for the trip to the grocery store because it's unlikely to be stolen, but for long distances, the gear ratios are far from ideal and the fat tires and weight are really dragging me down. But maybe I'll decide it's good enough by next year. Let's say the improved comfort of the biking short have really improved my appreciation of the Schwinn, now that I don't feel like my bee-hind will fall off every time I'm unable to avoid a pothole.

In any case, it's good to have a decent bike shop close by, given that Canadian Tire is a really poor bike shop, Sport Expert is expensive, and smaller bike shops are somewhat far from my place.

Gentilly 2 is the only nuclear reactor in the province of Québec. It's largely criticized, but IIRC, it has had a trouble-free life.

Capitaine Flam and the death of scientific optimism

2005-07-24T01:24:00.000-04:00

This Friday, I was goofing off at work, mostly because I was just waiting for the rain to stop. I had used my bike in the morning and didn't fancy pedaling in the rather strong summer storm that was in progress. I eventually came across this site and begun quizzing a co-worker on which songs he remembered. Now I feel quite old, because he didn't remember any of them.

I surprised myself enjoying the Capitaine Flam (Captain Future in English and Japanese) theme song. It's disco! It's kitch! But it's also a blast from the past.

I had never followed that particular series that much (preferring Albator to a large extent--seeing reviews of the two series, I sort of understand why). However, there's a particular episode that's still in my mind.

The good Captain finds himself stranded on a planet, his ship stuck somewhere in orbit. Together with other strandees, he builds a small ship from raw metal (how in the world can he do that? No machine shop, nothing... Anyway...). Unfortunately, the thrust system in the ship requires calcium to work, and there's no source on the planet. The Captain tries to sacrifice himself, but another strandee is quicker and walks into the power plant, letting his dead bones fuel the ship. All others escape, but rather gloomily.

Now, my recall of this episode may not be complete. Also, as I found out by checking out a few sample clips to refresh my memory, the animation was awful, the Captain was a stereotypical macho scientist-soldier with a density level approaching that of a neutron star, and overall, it felt very different from regular anime, plot-wise. But this particular story remains; it was a rather heavy-handed way to teach a kid that bones contained calcium, but it stuck in my juvenile mind. So, this is why I wanted to find out a bit more.

It turns out the series is based off an old pulp serial written by Edmond Hamilton in the 50's. Apparently, it got imported in Japan in the late 70's, and the Japanese really ate it up, despite all sorts of stupid plot devices, really weird concepts (one of the crew members was the brain of a dead scientist enclosed in a levitating cube filled with nutritive fluid--in the anime, it's a saucer-like device instead, but they kept the overall concept), a solar system with life on every planet (the anime places the action in different solar systems to make it a bit more plausible), a satellite around the sun, and a lot of other silliness. Curtis Newton, aka Captain Future, is the least plausible thing in the series, gifted with nearly superhuman brain power and reflexes. There's also a lot of silly stuff, like time travel, interdimensional travel, various human subtypes on every planet of the solar system, etc. etc. etc. And the total unconcern for safety around nuclear devices that filled pulps from that period.

It doesn't mean the series had no redeeming points. Newton is strong, fast, a perfect shooter, but still wins most fights through cunning and his superior scientific knowledge. Maybe unrealistic, but it did value brains over brawn, and although it was definitely meant to be wish-fulfillment for the target audience, it still made the pulp more clever than, say, plain superheroes. The text had some scientific explanations in them; some were completely bunk, but they were existing theories at the time. Keep in mind that before we sent probes all over the solar system, the fact that it was devoid of life was unobvious; we had only one planet as an example, and it's literally teeming with life of all kinds. But I think the main redeeming point is the sense of adventure, the optimism towards science, the sense that justice would prevail. Modern fiction is definitely more complex and mature for not being so optimistic, but it's also somewhat depressing, especially in the light of the events of the last few days.

So, what have I learned from this trip down memory lane? First, I've found out why the anime felt different from other anime at the time; it was actually an American story, which explained why it felt somewhat "average" in some ways. Still, I think it's an important anime, because it's one of the few that did adapt Western concepts; even if they were somewhat juvenile concepts, they are still part of our culture.

Second, I learned that I'm still very nostalgic about such series. I wish they were more easily available. People in France have better access to those; we in Canada are too small a market to matter much, unless the US cares. And the US doesn't care about most old anime series, because they were horribly dubbed and sometimes hacked to pieces and turned into some sort of composite anime.

Third, I feel that although the way pulps looked at the world were very naive, they served a purpose. I doubt the grunge movement would have come to exist if kids had been reading that kind of stuff instead of hanging out in bleak suburban malls. But nowadays, there seems to be three kinds of media that younger people consume. Squeaky clean, mind-numbingly dull shows like Barney the dinosaur, which, frankly, insult kids' intelligence (compare those to intelligent shows like Passe Partout if you have the chance, and you'll understand). Violent or disgusting cartoons, who are all pretty much the same and are really cookie-cutter shows to sell toys and such. And the things they aren't supposed to watch, and are usually depressing, trash/destroy music videos or series. Hardly uplifting material. Combine with news media that scream "fear! fear! fear!" all the time, hardcore porn that treat women like things, and wonder why you shake your head at the decline of social mores. Even adults aren't immune to such treatment, and kids are like sponges.

I am not advocating censorship in any form. All kinds of material have their place. But can't we get a breath of fresh air once in a while? That may explain why super-hero movies and Lord of the Rings are such resounding successes--they are breathes of fresh air. Unfortunately, they're also old material, and require suspension of disbelief. They also tend to be past-oriented, and I feel that future-orientation is one of the strong points of western society.

I guess I'm itching to see something like this corny, stodgy Capitaine Flam, but updated to modern standards. No need to make it violent or dark or anything; just remove the blatant macho elements, the rather dangerous use of atomic devices, make the science a bit more plausible (even if that means you have to introduce hyperspace, even though that's as implausible as everything else), and maybe we'll have something. It may not be that marketable nowadays, but dammit, I'm sick of wallowing in guilt over all the defects of my society, and I'm also sick the only optimists appear to be idiots (i.e., right-wingers) who are in denial over today's problems. Those problems are solvable, and we should be working at solving them instead of denying they exist or accepting them as the inevitable byproduct of modern civilisation.

Take the widening gap between the rich and poor in industrialized nations (or better yet, the gap between industrialized nations and non-industrialized nations). This is indeed a problem; it's returning us to a feudal-like system, with corporate employment replacing serfdom. Sure, it's not as many hours, not as physically demanding... But those are superficial differences; the work owns you, just like it owned the serf. The left likes to say this is the byproduct of a capitalist system; the right likes to say that everybody gets richer this way, even if the rich are much, much richer than the poor. Both attitudes are problematic, because they both perpetuate the problem. If the left wins, you just get a different clique with all the riches (remember the USSR?) If the right wins, as they are right now, it only gets worse. If you read older sci-fi novels, there's a huge contrast. The world is owned by the average majority. The heroes are sometimes richer than the average, but they show very little greed. Of course, they're also paternalists, and tend to patronize "the little folk", but despite that, the whole feel of stories of this era is much more hopeful than what I see these days. It seems, in fact, that those heroes wish for a day where they won't be needed anymore, and where everyday people will be able to live in peace.

There are other aspects of modern life that aren't being seen in the same way as they were in those novels. But this is starting to be quite long, so I won't go there.

If there was one thing those old stories did that isn't really done anymore, it was to teach elementary science concepts in the guise of a space adventure. In a crowded world like ours, "hard" science is losing relevance because the hard problem is becoming how to interact with all those other 6 billion people sharing the space with you. But in space, nature reclaims its place and survival comes from scientific thinking once more, just like it did on Earth before we started to tame it. The paternalist, gun-toting Captain Futures weren't the essence of such storytelling; the ability of humans to figure out who nature works and how to make the best of it was. I'm sure it would be possible to have good, entertaining stories with interesting characters without turning it into a dark, depressive mess many modern sci-fi stories end up becoming. And it would also be possible to have such heroic stories without resorting to super powers, or without wallowing in distortions of medieval history. If anyone knows of an author who does this, let me know.

As for myself, I intend to give it a shot--to see if I can pull such a thing. My own fanfics, although edging towards medieval/modern hybrids (and left unfinished, shame on me!), do try to have such an atmosphere. When I wrote them, it felt "natural;" so I don't think I'd have to force myself. The main problem will be to figure out an interesting plot with solid scientific basis (but not necessarily too solid--after all, the pulps weren't that solid about many things!), and come up with interesting characters.

Wish me luck!

Difference between Windows and UNIX programming cultures

2005-07-18T22:28:00.000-04:00

This post on Slashdot links to an article on comparison between UNIX and Windows programming cultures. However, it mostly talks of how the problem of usability is approached. I'd like to take a different tack, in the difference between the API of the two systems.

Windows APIs are huge. In the Microsoft world, everything seems to end up being part of the core OS services somehow. This has the advantage that you don't need to expect people to have such-and-such library. Or does it? Changes to what is the "core" between OS versions make compatibility somewhat nightmarish; you're never quite sure what libraries are there or not. Writing installers is a mess. MSI helps, but not if there's no MSI package for the libraries. Another side-effect of this is that Windows programmers are always learning a zillion new things. Win32 services. COM. COM+. .NET. DNA. TAPI. The list goes on and on. Many of those APIs do the exact same thing, so learning the new one is only needed because the old one becomes obsolete. It's hard to stabilize such a huge API.
In contrast, the core UNIX APIs have been mostly unchanging for 30 years. You can write most application-level code without touching the newer calls; newer calls are mostly there because they provide better performance, and are needed in more specialized situations. There are a lot of third-party libraries; however, they're not part of core UNIX, and it's reasonable for UNIX programmers (though maybe not from the users' point of view) to expect the needed libraries to be installed. Like core UNIX APIs, those libraries tend to use rather stable technologies.
Core Win32 APIs have no consistent reporting. OK, this drove me up the wall when I was coding on that platform. Does the MoveWindow() return NULL or INVALID_HANDLE on error? How about CreateFile()? And what's up with the ridiculous conventions for WaitForMultipleObjects()? Sure, GetLastError() is there, but so many APIs set this (including, say, MessageBox()) that many programs end up reporting an error as "The operation completed succesfully". UNIX APIs tend to return ints, -1 on error with errno set, a positive integer otherwise. Period.
The C library in Windows is a mess. It's getting better recently, but people still use old Win98 boxen that don't have a decent libc installed. This, plus the annoying mishap with memory allocation (there are too many ways to allocate memory: GlobalAlloc() (deprecated), LocalAlloc() (deprecated), VirtualAlloc(), CoTaskMemAlloc(), malloc() and operation new in C++--and they all use a different heap!), makes writing interoperable DLLs a real mess. Contrast with UNIX, which tends to ensure that malloc works the same across all libc versions, and where upgrading your libc pretty much upgrades your whole system, and you'll see why I was pulling my hair trying to fix installation problems with the C library. Of course, .NET will solve all this... Just like Java is supposed to solve similar problems on UNIX. Well, not everyone wants to install 100+ MB of runtime code just to run your application...
Windows SendMessage() is stupid. Granted, with MFC and such, you don't need to look at it as much. But what's the big idea of passing two parameters of a known bit-width for every message? Why not pass a void* pointing to a different struct for each message? The result: huge pain when porting from Win16 to Win32, and another huge pain that will occur when porting from Win32 to Win64. No wonder they want to move to .NET. Compare to X-Window, which uses the void* approach, and you have to admit that SendMessage() and the WindowProc() conventions are mis-designed.
Some Windows services are strangely tied to physical windows. For instance, many COM calls don't work if there's no window and no message loop. This is documented, but it's a pain in the ass for multithreaded programming. Ditto for timers; IIRC there's no way portable to Win98 that lets you have a timer callback without a message loop. Compare to UNIX setitimer(2).
UNIX threading is a mess. This has improved somewhat in recent years, but I still run into problems. Linux and glibc are the big culprits there. They have changed their threading strategies several time, and each time a glitch appears, we get a finger-pointing match between the kernel and glibc team. This is annoying to say the least. At least one widely-distributed Linux distro (RedHat 9) exhibits severe problems under load, due to bugs in the glibc that are partly made worse by the JDK. In my view, threading should be a kernel service (and I'm not completely alone in this view--it seems the Linux kernel is moving more and more towards that model) and it should remain stable, dammit. Sure, you could do similar things with fork(), but that's not a reasonable approach with a GC runtime. In contrast, Win32 threading has been rock-solid for years. You can bitch a lot about their synchronization privitives (events are extremely easy to mis-use, and their overlapped IO is one of the most convoluted APIs I've had the displeasure of using, full of corner cases and with no easy way to cancel without introducing a lot of extra code), but at least, threads switch properly, semaphorses are locked properly, and that part of the API has been very stable.
UNIX C++ integration sucks. UNIX people seem to prefer C. So, there's no integration between signals and C++ structured exceptions. C++ runtimes are not versioned as carefully as the libc. And so on and so forth. Annoying, this. C++ remains a second-class citizen in UNIX for rather stupid reasons. At least, in Windows, exceptions work somewhat right (you need to mess with _set_se_handler() IIRC to get it standard compliant, though), and the C++ runtime is versioned together with the C runtime (then again, the C runtime's versioning's already messy...).

I'm sure I could go on, but these are the main thing that strike me. I don't know if this is useful to somebody.

Credentials: I've worked in a Windows shop for four years, writing Windows applications first in raw C, then in raw C++. I've seen Win16 (the horror! the horror!), the passage to Win32, COM using raw C++ as well as ATL, lots of newfangled APIs (pen API, new serial port interface in Win32, WinINet, etc) and had lots of headaches getting the stuff to work all the way down to Windows 95. Lately, I've been mostly writing Java applications for UNIX, but I've had the opportunity to write some C code on POSIX systems once in a while. I like to think I know what I'm talking about on those two APIs.

Back from vacation

2005-07-18T21:53:00.000-04:00

Came back from vacation 2 days ago. Spent time with my family in Hampton Beach, NH.

I've been to Hampton many times in the past. However, it was my first time doing it by bus (because I was joining the family in the middle of their vacation). There's a couple of weird things I noticed with my bus trip:

Those idiots at Station Centrale kept insisting the bus went to Manchester, NH first, then Concord, NH. I had picked Concord, NH as destination because I wasn't sure there would be a bus to Manchester (turns out there was, I'll know for next time). Manchester, NH is further south than Concord, NH, so starting from White River JCT, VT (where I had to transfer from the Montreal-Boston bus), it made more sense that it would stop at Concord first. Sure enough, it did. Went to Manchester anyhow because it saved some time otherwise. But if I had followed the tickets blindly, I would have been stuck waiting for the Concord bus at Manchester, which I would have just missed...
On the first leg, we had plenty of room; everything got packed at Burlington, VT. Namely, got a rather, ah, large person next to me with a bit of BO (don't blame him, though, it was really hot outside). Thankfully, unlike in a plane, I actually had room leftover.
All the cute women were in the trip from Montreal, when the bus was half-empty, so my plan of having a nice lady sitting next to me obviously didn't work. And I'd shownd up really early hoping that would happen. Bummer.

Besides that, not much to say about the vacation. It was mostly relaxing, no thanks to the idiots next door who partied until 5 AM every darn night. After four nights of this, several people complained (including us) and they got kicked out. The last two nights there were bliss compared to the previous nights. And before anybody says anything about me being an old fart and noise intolerant, I slept next to the A-15 in Montreal for four years, and I could sleep with the window open. A-15 is extremely noisy, so it's not about noise intolerance. Maybe I'm just incompatible with Rap music.

Then again, the owner told us those guys had made a foot-wide hole in the wall, and left shaving cream all over the place. I guess maybe they were just idiots.

Other things I noticed: property prices are insane down there. The only city with decent prices in NH was Manchester, which is odd, given that it's one of their largest cities. Coastal property is completely ridiculous, and rents are pretty bad as well. 4 1/2 start at 1000$ in most locations. Keep in mind those locations are suburbia at best; there is no bus service to speak of, commerces are only accessible by car, and so on. It gets worse in the Boston area (which, at least, does have some public transportation). I know taxes are low there, and mortgage interest is tax-deductible, but still.

Consumer good prices aren't that fantastic either. I bought two things: a nice pair of shoes (and I could've probably found those in Canada, now that I think back on it) and the Noir DVD set. I would have preferred getting the DVD set here, but it's out of stock everywhere. Even in NH, I only found it in Nashua. I saved a bit of money mostly because NH has no goods tax, but if it hadn't been for the out of stock thing, I would've gotten it here.

Who cares about consumer prices? Well, it used to be that going to the US, my family and I ended up close to the limit of goods we could bring back (there used to be a 300 CAD limit for a stay longer than 7 days). Now, although the limit is much higher, we weren't even close to the old limit. It's just not as attractive as it once was, even with the Canadian dollar so high and the lack of consumer tax in NH. I'm really wondering how USians make ends meet, despite lower income tax. I'm sure their salaries, just like ours, didn't move much since 2001; however, the prices are higher, real estate is insanely expensive, and even gas prices must be starting to hurt. You hear a lot of stuff on the radio about 0-down mortgages, getting a loan from the mortgage, etc. etc. etc.

This is happening in Canada as well, but I'm not that worried; prices are still somewhat reasonable, compared to theirs (it's still dang expensive, but looking at their real-estate classifieds sort of made me somewhat less sensitive to this). Taxes high, yes, but we don't have that medicare mess to contend with. The provinces are on the edge of deficit, but at least the federal government is not (and those who think state governments in US aren't in trouble; think again, they had to cut a lot of services from what I heard). And most people I talk to, even home owners, are extremely wary of taking loans from the mortgage. At least, in Quebec; don't know how it is in Ontario or BC. So, from what I can see, there's still room for price growth on real estate in Montreal (a good thing for me) without necessarily hurting everyone. I'd also expect that, if there is a speculative bubble in real-estate, it will hurt much less in Montreal than down south. There's definitely a huge bubble there; just look at Alan Greenspan's worries about the fact that raising interest rates does not raise mortgage rates. This is because banks expect to always be able to recoup their capital easily thanks to the speculative market which inflates prices way too fast. If prices crash, or even stabilize, some banks are likely to be in trouble.

Of course, I'm no economist. But seriously--300 000 USD for a 4 1/2 condo is insane, period, especially in suburbia. I'm getting annoyed at Laval prices which hover around 150 000 CAD for similar units--and you will get access to the metro in 2006-2007 at that price. But then again, maybe there's something I'm missing.

It's just that I didn't expect San Fransisco prices in the New England area. And I still think I had reasonable reasons not to expect that...

Cloud now running x.org

2005-07-17T22:09:00.000-04:00

I just upgraded my main workstation, Cloud (named after the famed FF VII character with the big-ass sword) to use X.org.

Was a mostly painless upgrade. Didn't even follow existing instructions on the upgrade; I just noticed that a dist-upgrade grabbed a lot of xorg packages, so decided to take a look at xserver-xorg.

Initial problems: couldn't get OpenGL to work right. That didn't take too long to fix, though I'm not sure whether it's the refresh of the configuration I did or today's dist-upgrade that fixed it.

Second problem: it didn't really want to upgrade my XF86Config-4 file. Solution: nuke it, reconfiguration the package, and let debconf do the work.

There were a few other annoyances (mostly related to the dga and xv extensions that are never installed by debconf, for odd reasons), but it's been extremely painless. The main remaining annoyance is packages that still insist on linking on the original version of the OpenGL libs (such as xscreensaver-gl or doomlegacy); those won't install. But such is life on the unstable tree.

A lot of people reported better performance, but I haven't noticed anything. However, the radeon driver has always been very good even in XFree86, so that may explain it.

The main positive is that I'll finally be able to counter taunts from the Arch Linux fan at work. :-)

Enabled comments

2005-07-17T19:06:00.000-04:00

OK, I decided to enable comments, mostly so I get an idea if anyone except Code Ronin reads this, or if I'm "pissing in a violin" as one of my French friends likes to put it.

Note, however, that you'll need to create a blogger user to be able to add a comment. This is in an effort to prevent too much spam. Maybe I'll move to a moderation-based system at some point in the future, but that would require migrating all of the blog. Right now, despite previous complaints, blogger is free, simple, and publishes to an FTP site, so I'll keep using this.

Darn blogger...

2005-06-30T00:27:00.000-04:00

Wish they'd tell me when they add options that break layout like "enable float alignement" that default to what it used NOT to be without telling me... Was wondering where the <div style="clear:both;"> was coming from...

Holy Wordpress, Batman!

2005-06-30T00:15:00.000-04:00

Glad to see The Code Ronin gave his site an uplift. Awesome work; congrats on your new baby! :-)

On the Canadian gay marriage legislation

2005-06-29T23:03:00.000-04:00

Far be it from me to unilaterally praise the current federal government's policies (a lot of them are just so much improvisation, and, much as I like many things in the NDP program, I'd rather see that money administered by the provincial government, thanks very much), but I'm rather happy they finally got around to voting for legislation of gay marriages. Even though it's very much an abstract concept as far as it comes to my own life, I think it makes sense, and for once, we can be proud to be at the forefront of social liberalism. We're usually proud to be at the forefront of liberalism in North America... which isn't saying much in general; USians are a bit stodgy when it comes to such things.

But this is not about the law itself. Rather, it's about the people they find in news roundtables such as Le Point to claim that it's a bad thing.

The argument goes something like this: marriage is meant to protect families. In Quebec (and in the rest of Canada as well), we would be in a huge demographic deficit if it weren't for immigration. By trivializing marriage, we are removing special protections to families and making them general. Therefore, we'll worsen the demographic deficit, making our situation worse.

This strikes me as an extremely convoluted argument. Furthermore, I think it's completely bogus.

One of the so-called "key" arguments given against gay marriages is that they can't have children by definition. Well, it's not that clear, nor is having children or not a criteria for marriage, even in ancient times. Consider:

Couples where one or both spouses are sterile are allowed to marry last time I checked, even in the Catholic church. Otherwise, you'd have to pass a fertility test before marriage, which I would find somewhat offensive. What business is it for any institution to only allow one to love those they can have children with?
Couples where there are no children, for a variety of reasons (some more frivolous than others), are allowed to remain married. Practically, those people cannot have children, although they theoretically could. Shall we force divorce on those people? Keep in mind they may have very unselfish reasons not to have children (say, fear that they won't be able to provide for them, or fear that they wouldn't be good parents--maybe there should attempts to diminish such fears, but I don't think we can condemn people who believe this).
Couples sometimes adopt unwanted children of other families. Why not gay couples? I concede that this is a whole 'nother can of worms; there are fears over the lack of a role model of each sex, for instance. However, studies have been made on this, and they have found no significant differences between children raised by gay couples and those raised by heterosexual couples¹. From that point of view, gay couples can, theoretically, raise children. The way they'd do it wouldn't help demography much, but it may make the life of those children much more bearable. Instead of being thrown between foster homes, they'd get a stable family, albeit a still unconventional one. But I suppose those against such practices are also against getting the government to intervene when children are mistreated, so there wouldn't be as many adopted children. I guess.
Some will say that although it's not allowed to force people to have or renounce children (and the latter is debatable, because it seems acceptable to many), it doesn't mean that we should allow people who can't have children to have them. In that view, fertility assitance should be disallowed as well. This would definitely have a worse impact on demography than any gay marriage; fertility rates are dropping alarmingly on the planet, to the point that fertility assistance may become necessary in many cases.
And as for gay couples adopting disallowing childless heterosexual couples from doing same, when we run out of children to adopt, we can deal with that. It doesn't seem to be a problem right now.
If someone's gay, you can write them off the demographic curve anyhow; even though they are physically able to reproduce, they will probably choose not to. Why force them to do so as a façade, then? Should we force nuns and priests to renounce their vows for demography's sake? Yeah, yeah, it's not the same. Whatever...
In any case, what difference does it make that gays can marry? Who does it hurt, except some sensibilities? Keep in mind that once upon a time, black people sitting in the front of a bus was hurting some sensibilities as well. Also, keep in mind that nor the law nor the Supreme Court mention an obligation for religious marriages to be celebrated. So, if you're a catholic, you can simply dismiss it as a civil marriage, having no value before God, and sleep extremely well at night knowing that all is right with the world. Maybe it's just a folly of our lay society. Just ignore it and let the non-believers live the way they want.

For the record, I'm officially a Catholic. However, I don't agree with the precepts much, knowing that they take such... ah... conservative (*cough*backwards*cough*) stances on abortion, gay rights, and especially contraception. And one better not go to much about how such practices are banned by the Bible, because I'll dig out that passage about Sarah practically throwing a handmaid (little more than a slave, really) in the hands of her husband Abraham because she was sterile (Genesis 16:1-6; also see "The Handmaid's Tale" by Margaret Atwood for an interesting twist with this whole mess). Do you think that's acceptable? Is that different from adultery? Because she was a slave? Is slavery acceptable? And if it was in those times and not anymore, why is it different with contraception?

And don't get me started on Harper's comment that the vote's legitimacy is tainted because Quebec separatist Bloc MPs made the difference. Well, if he's right, I'll consider any vote that passes because of Conservative MPs is null and void because it was done by a bunch of rednecks who are chronically stupid due to spending most of their times looking at their navels and congratulating themselves for being keepers of decency, while their standards on decency are at least 40 years out of date. But he's wrong, so I won't do that. Again for the record, I have no great love for the Bloc, but dammit, they were elected, and whether I agree with them or not, they are legitimate MPs and have the right to vote for a bill. If Conservatives are frustrated that they don't have the balance of power in the minority government because they can't get any votes in Quebec, they have only themselves to blame. I would've voted for Joe Clark at the previous election, but no way I'd vote for Stephen Harper and his gang of merry Alliancists. I feel they'd do as lousy a job representing me and my values as the Bloc would representing the values of a guy from Toronto.

Rant mode off.

OK, short summary: Gay marriage legislation passes. Me happy that I don't live in backwater country like another I won't name. Next step is to legalize marijuana, just to completely piss off our neighbors down south <g>

¹ I heard a testimony of a scientist about this at the Quebec National Assembly in 2002. I don't think anyone disputed the claims at the time; the methodology is likely valid. Ironically, when I was looking for information on this, I found this nugget, which mentions that Quebec adopted adoption gay right laws after Alberta. Amusing.

Sometimes, you just can't win

2005-06-20T23:39:00.001-04:00

Man, I've been really unlucky on the transportation front recently...

Saturday, it's Housewarming Party time at one of my friends' house. The directions on the invitation suggest that there's plenty of free parking in the area, even though it's in Old Montreal (and on weekends, it's true that free parking is usually available). So, I think, instead of taking one hour of public transportation and worry all night that I'll miss the last bus, I get my car and drive down there. After all, my car has to be good for something; I certainly don't use it much right now.

So, down the 25 I go; take the Souligny thing, drive down Notre Dame (avoiding potholes all the way and cursing the 60 kph speed limit, which I respect but apparently nobody around me was willing to take into account). It's going well, and I expect to be only 15 minutes late.

Then I see police lights in the middle of the road. Uh oh. Looks like Notre Dame is no go; detour through Ste-Catherine street. OK, up Pie-IX I go. Down Ste-Catherine. It's really slow going, and I wonder whether it wouldn't have been faster to bike all the way.

Traffic gets even worse. I can't figure out how the one-way streets are laid out in that area, ever, but I manage to go down St-Denis, hoping to reach De La Commune. Damn, Notre Dame is closed there as well. I drive west, until McGill, on René Lévesque (which is really crazy at the first interesection, because eastbound cars hit the barrier and turn left, right in our way, not letting anyone pass. Bastards). Go down McGill, which, thankfully, is open. Find De La Commune. No parking.

Huh? Well, half of De La Commune is closed. Figures. Mess around for 30 minutes trying to find a parking, until I find one somewhat far (Duke and Wellington--ten minutes walk, which feels really silly if you have a car...). Finally reach the party, one whole hour late, with a knee ache because I'm not used to driving for such extended periods anymore. Woe is me.

Sunday was OK, mostly because I brought my dad to a movie for father's day. The movie was La Marche de l'Empereur, which I highly recomment. Nature has some really screwed up setups for some species; we should be grateful we're mostly wired to kill other species rather than to keep eggs warm until we barely have enough strength to walk. I ended that day with a bike ride to the IGA on Langelier and Jean-Talon. A really easy ride, since Langelier is an underpass. Easy, that is, if I don't take the idiot who almost exited to the service road on me... I mean, I was pretty visible, and the guy only needed to slow down a tiny bit (I was pedaling like crazy), but instead, he speeds up, trying to beat me to the exit. Moron.

Today, everything started out smoothly. I had less trouble climbing the Galeries d'Anjou overpass than on previous days, so I know I'm starting to get in better shape.

Then, disaster; the whole metro is paralyzed by smoke, as some circuit breaker or another caught fire somewhere on the orange line. I'm stuck at Frontenac. Good thing it wasn't +30 Centigrade outside, but the sun was strong and the sky completely cloudless. I waited for the 125 Ontario for 20 minutes, until I figured out that it wasn't going to show up, and that even if it did, I wouldn't have any room in the bus. Why is it that the STM have no emergency buses ready within mere minutes in those situations?

So, I walk to Berri-UQAM, thinking of taking the orange line (I though it was only the green line that was affected in this case). Get there, hit a locked door. I asked some STM employee, who told me that the whole metro was shut down, and to take the 15 if it ever managed to show up. Waited for the 15 a little bit (maybe 10 minutes), then got fed up and walked to the office.

Total mileage: 4.7 kilometers.
Total UV exposure: probably 30 minutes in full sun.
Total minutes late to the office: 45 minutes.
Total cups of water consumed upon arrival: 10 in two hours. I had picked that day to forget my water bottle.

Needless to say, I'm quite tired now, I'll probably hurt like hell tomorrow, I'll be surprised if I didn't get sunburnt (hadn't expected such a long stay under the sun), and the ride back from the metro was much harder, tired as I was. Plus, I had to leave early to attend the condo association's meeting, so I'll have to stay late tomorrow.

Woe is me.

On the plus side, I'll have tighs of steel for my beach vacation in a few weeks. Maybe I'll get a few interested looks. I better, because it was a lot of work, dammit, and not even all of it voluntary!

In any case, it got me more quality time with Kajiura-san's Madlax soundtrack. I got a lot of respect for the "Saints" track (great marching song) and "Flame". Also, I'm getting a bit obsessed with the "Madlax" song itself. Such obsessions usually last a couple of months, so I'm not to worried yet, just thankful I have earphones so nobody else has to suffer from said obsession.

Weather complaints again

2005-06-11T23:18:00.000-04:00

Remember me complaining about how it was friggin' cold a while back? Well, now, it's friggin' hot (28 C, NO WIND and humidity at 61%, which, at 28 C, is really, really humid and sticky and disgusting). Only in Montreal, I tell you... No wonder people always mention the weather when explaining why they won't move to Canada. I used to think they were wusses, but now, as I melt in my chair, I'm thinking maybe I was a bit hasty in judging them...

I do have A/C, but I don't really feel like using it, it was cold for too long and I intend to suffer for complaining about it.

(The real reason is that I'm trying to save on my power bill and that I dislike "canned air". I'll probably turn it on if I'm unable to sleep at some point)

And I actually went to the grocery store on my bike this morning. A nice lady wished me "bon courage" as I pedaled out. I thanked her, though I didn't think I'd need any. I wouldn't have if my stupid chain hadn't unhooked itself from the gears while I was going back on Jean Talon. I guess I was a bit too hard with the dérailleur.

Took about 10 minutes, once back home, to get all the grease off my hands. My shorts, unfortunately, were a bit more attached to it; thankfully, it's just the front of the pocket that suffered when I got my keys out.

In other news: I finished Star Ocean 3, which was a pretty good game overall (although the plot twist towards the end sucked--enough so that I felt like never playing the game again in retaliation). It's a beautiful game, mostly because they bothered to animate eye movements and convey the characters' moods through them. I'll probably play it again eventually.

Also got the Mad Lax OST through not-quite-legal means (it seems like it'll be available on Amazon on July 5th, I'll order the legitimate copy then). My respect for Yuki Kajiura grows every time I get some new stuff from her. The OST left me with no particular impression when I first listened to it, but on second listening, I realized how strong some tracks were. It's probably not her best, but it's still extremely impressive. It's strange how her music either surprises me completely or grows on me after I initially disliked it. Definitely an amazing composer.

I must be crazy

2005-06-05T17:00:00.000-04:00

I must've clocked 24 klicks on my bike today. Not even close to the 40 klicks the "Tour de l'Île" people do, but that's the point--I'm not ready to do the tour-de-l'Île, and I want to be ready for next year. Whether I'll be able to maintain my shape during winter is another story, I guess...

I should've picked a less busy street than Viau to go down to the Maisonneuve park, though. I think I breathed in a lot of hydrocarbons. Down with cars! Hurray for bicycles! (except in winter, of course)

It was a good workout for myself, but also for the bike. I had ridden to the metro so far, but never farther than that. There are a few problems with the derailer that I'll need to look into, but besides that, it's a sturdy, reliable workhorse so far.

Anyhow, I'm sure I'll sleep extremely well tonight. And hurt all over tomorrow...

Why Free Software matters

2005-05-03T23:23:00.000-04:00

No, I haven't turned into Richard M. Stallman.

I'm not in the habit of linking to trade press articles; most are trite. This one, however, summarizes my whole take on proprietary vs. free. Proprietary licenses give rise to abuses of power more often than not. That is why, as a general principle and if possible, they should be avoided. I don't care how much of the economy rests on them; a lot of the economy used to rest on strip mines, and those are still seen as harmful and as needing very strong regulation.

Now, in the bitkeeper case, it's a bit more complex, because one could argue that there was no good substitute at the time. And I can understand Linus' position of wanting to use the best tool. However, what I find unfortunate is how Linus and Larry reassured everyone that exactly what happened would not happen. Whose fault it is, doesn't matter. The fact remains: a proprietary program gives all the power to the author, and none to the customer. If you're going to use a proprietary program, make damn sure you freeze the license at least for the version you're using, so that conditions don't get changed retroactively. Better yet, if you have a free software alternative that fits the bill with minimum customization, just bite the bullet or hire someone to do it for you. It may cost more up front, but in the long run, it may actually be a safer proposition.

I know it's cliché, but would you buy a car with the hood welded shut?

(Interestingly enough, while there is a move for software to become more transparent, cars are actually becoming more opaque, but that's a whole 'nother can of worms...)

This said, take the time to read RMS's writings, instead of just putting him in the "communist" box. What he says is very similar to this. Some claim his arguments are "moral" rather than "practical" (and some discuss the morality of what he says). I contend that there is no difference; what is morality for, if it's not meant to help figure out praticalities?

On the limitation of ORM systems

2005-05-01T23:21:00.000-04:00

Lately, I've been wondering why so many ORM systems tend me to throw up my hands in disgust and hope I'd just written straight SQL.

There's the Object-Relational impedance mismatch, of course. That alone is a big killer. The fact that relational systems support declarative rather than object-oriented data is a big problem. Another is that relational systems discourage encapsulation; you should know, when designing a database, exactly what you're going to store, because it dictates relationships. In OOP, refactoring objects to move state data around is no big deal. After all, what's one more pointer dereference? Especially when it's as likely that the refactor causes one less pointer dereference.

In relational systems, where the data is is one of the most important decisions. It dictates index structure, how many joins you need to make, how easily you can access the data from different parts of the system, etc.

Whatever ORM system you want to use, it must truly address this concern. Lazy-loading is not an answer. Neither is select n+1. You need something that can anticipate object queries (maybe from hints as to what objects are related when you pull an object graph) and collapse large joins into a normalized object graph.

But that's not the only problem. Another is the "garbage generation" problem.

This is a problem, mind you, that is mostly specific to garbage-collected languages where objects are very heavyweight (i.e., Java, C#; Python objects are heavyweight, but so are primitives, so I don't count Python in there). Even if you collapse large joins, each query will generate a lot of temporary objects. This is fine if you're actually going to do something with them. But what if you're only trying to display them to the user?

For such situations, a simple query with queries on column names may work better; especially since you can use limit/offset to tabulate the data. However, it's extremely annoying to lose the ability to query a typed object; working with string column names is annoying, it makes it hard to refactor, you don't get code completion, etc. Admittedly, all those things are crutches and aren't especially necessary to programming, but it'd be nice if you could have them.

But if you try to generate objects from a large query, you generate a lot of garbage. All that for a simple table display! A table display that is, in most business applications, very likely to be much more frequent than table updates...

The ideal interface, to me, would be to get an iterator that returns a single table row object graph at the time. Unfortunately, very few ORMs offer that.

The last problem is that many ORMs really, really want to provide your database schema. They'll work with custom schemas, but it's always a big problem. It's, to be fair, a really hard problem.

That said, I think Hibernate really handles many of those things well. So does iBATIS SQL Maps, although it does different things well. I'd like to have a combination of both, that is, the power of Hibernate with the ability to write custom queries. Or I'd settle for an iBATIS extension that makes it easier to handle multiple database dialects, and a way to have it iterate over result sets rather than populate lists. Or maybe iBATIS already does this; if anyone knows how, please drop me a line.

UPDATE: iBATIS has queryWithRowHandler(), which probably works the way I'd like it to. It's probably better than an iterator, because people forget to close result sets. Should have checked before starting to write this. All that's really missing is the custom database support. And, according to the todo file, they have no support for BLOBs yet (I know a few applications where this can be a problem). Still, overall, it looks like an interesting solution when you have to recycle an existing schema.

Bitmapped fonts in xft applications

2005-04-29T00:39:00.000-04:00

A couple of months back, I moved to using XFce 4.2 and the os-cillation Terminal application. I liked the Terminal application mostly because it had the features of gnome-terminal, but didn't require gnorba and other silly libraries. When all you want is a competent multi-tab terminal, it's annoying to require all sorts of extra stuff.

The only annoyance is that Terminal uses client-side font rendering. For some reason, client-side apps weren't able to see bitmapped fonts on my system. Which is not normally a problem; however, I really like the "terminus" font for terminals and editors and such, and it being a bitmapped font, I had to make do with Andale Mono, a font that I never found as clear.

I got fed up and did a quick google search. Turns out that on Debian systems with fontconfig installed, there is something that can be done. I went into the /etc/fonts directory. There was a conf.d subdirectory, in true Debian fashion. When in there, found a file named yes-bitmaps.conf, while the file no-bitmaps.conf was symlinked. The symlink contained the "debconf" word, which led me to think that it was a configuration option below my normal debconf level.

dpkg-reconfigure fontconfig, and voilà.

So, for those of you who want to use terminus in Terminal (or any GTK+ 2.0 application, as most use client-side font rendering thanks to pango) under a Debian system, hopefully this post was of some use.

Positively non-humbling

2005-04-15T01:58:00.000-04:00

Looking at my old entries, I found something about a so-called humbling experience. Well, turns out that isolating the lookup from the rest of the system was a really good idea, because somebody's trying to use it outside the application framework...

At this rate, my head won't pass well through door frames very soon.

Hey, I'm entitled to brag once in a while like everyone else, ain't I?

I really, really hate computers...

2005-04-13T20:31:00.000-04:00

Stupid computers.

This week-end, my computer's hard drive started showing up bad sectors. Well, that gave me an excuse to go buy a bike (I got a retro bike--it looked cool, and was cheaper than the cheapest hybrid; bit heavy, though) and enjoy it for some of the week-end.

But still, I had to get the darn computer to work.

Scrambled to get data out on CDRs. Degradation was really quick, which surprised me; usually, you get a few bad sectors, not a whole whack with a bunch more following in hours' time.

Bought a new disk, was pleasantly surprised that Maxtor 8 MB cache models come with a 3-year warranty, so if it goes bad like the last one, I'll have some way to recover my losses. If I don't lose the bill, of course.

Installed the OSes. For the record, I dislike installing Windows. On the plus side, the new installation seems much snappier logging in; I must've done something wrong the first time. I also installed Debian from the latest Sarge netinstall CD, and it went extremely well. Took a bit of time to get used to the GRUB, but besides that, I had almost nothing to do. Recalling my original Debian install, it was such a pain at the time--especially the ALSA drivers that would not enable any channel by default. The new ALSA init script does enable the PCM channel to a sane value, so it works really well.

Monday, came into work, and expunged my woes by expressing them to our sysadmin. His rather cryptic reply: "It's springtime." Say what?? Apparently, humidity changes due to Montrealers having to heat their houses in winter (otherwise we'd be frozen solid in a matter of minutes during winter) and abruptly stopping in spring wears out the rubber seal that keeps the vacuum in the drive. Once vacuum is lost, the drive surface oxydizes. It's worse if your heating is electric, as mine is (most modern constructions in Montreal are, since electricity isn't that expensive up here and it's much more convenient than putting water pipes or air ducts all over the building's walls). There's a small circle on the drive that pops up when vacuum is lost, and sure enough, when I checked, my former drive's is popped up.

Bummer. This means, next winter, I'll have to humidify the damn computer room. This means work--the humidifier I have needs cleaning every day. Maybe I'll just put a bowl filled with water next to the heater instead.

On the same day, one of my co-worker's new work computer showed signs of instability. It's one of those eMachines with integrated nforce chipsets. Another co-worker has the exact same model, which exhibits no stability. Granted, the stable machine runs Arch Linux and the other, Debian GNU/Linux, but I don't see how that could be the problem; we did compile X.org by hand on the Debian box. Stability is good for a while, then the co-worker will copy-paste something, and poof--back to the gdm screen. This is driving me nuts.

So, to close:

I hate computers!

(with apologies to Christian ;-)

Long time no post

2005-03-29T22:41:00.000-05:00

Time I waste sometime airing my thoughts to a non-existing audience.

First, promises I made. Fanfic not advancing at all, I'm afraid. Been busy with taxes and lots of other stuff. Xenosaga II is advancing. I'm in the sidequest part, and I dislike doing those on second playthrough (I'll just play a second time with a lot less annoying things to do), so it can be a bit tedious. Though a lot of them are no worse than those in FF X-II, and probably no worse than the stuff in FF VII (I suspect that although I did those ten times, I'd balk at doing it again at my age). Beard is still off, for practical reasons and because I got used to it. And there's no way I can screw up shaving activities in this state.

Reminds me of the best way to keep things clean: own as few things as you can manage. Works OK so far.

Other things... got federal tax return back, so working on taxes instead of fanfic paid off, I guess. In an élan of non-geekiness, I bought a 30$ D-Link router instead of hacking one from leftover computer parts. The amount of power eaten by all those moving parts in regular computers made me balk. D-Link's not really hackable, but they get major good points for giving it a plain HTML interface. I don't know how solid the device is, but it's not being used for anything critical (my laptop isn't connected to it all the time), so even if it dies, it's no big deal.

Been following the Hacker's Diet's exercise program once more, reached rung 20 without too much trouble yesterday. I feel overall more alert. I recommend this program; its main attraction, to me, is that I cannot make excuses to skip an 11-minute routine, and since it's supposed to be daily, I can't think stuff like "I'll do it tomorrow..."

In my current conceited state of mind, I decided to commit to the electronic medium my thoughts on the rules every programmer should know. OK, so they're the rules I know, and they may not apply to every programmer; but I've been toying with the idea of writing some stuff on this someday, and, well, now's as good a time as any.

So, here it is: BGE's Killer Programming Rules... Of Justice.

If it ain't tested, it probably doesn't work

This can be seen as a corollary of the second law of thermodynamics. Code, left alone, "rots". Of course, this sounds silly; the code doesn't change, so how can it rot? Well, everything around it is changing; new OS, new libraries, new runtimes, even the code around it may make that code malfunction. There are only two ways to ensure the code remains OK: active maintenance, which is not always practical (codebases tend to become really big!) or periodic testing. And "testing" does not mean send it to a client and hope it works. That's exactly when it won't (and that part's a corollary of Murphy's law)

Just say no to protected data members

Protected data is t3h 3v1l. There is no telling what derived classes will do to it. Unless you want to be condemned to leave your base classes with the same implementation until the end of time (and that's not really feasible, because of the first principle, above), you should never use protected data. That's right, never. I'm usually not that drastic, but I've never seen protected data being used in a sane manner. And this is coming from the guy who things Multiple Inheritance can be very useful at times. If you think of the implications, protected data makes your base class less reusable and unable to evolve, which kind of goes against the grain of object-oriented programming principles.

Overriding concerns should not be abstracted away

Overriding concerns are things like transactional semantics and resource clean-up. Somebody, somewhere, is going to have to make a decision on the transaction boundaries or on the clean-up time. It very likely should be code that has a wide enough view of the problem to make an intelligent decision, usually some top-level or near-top-level method. I've ranted about this before.

Keep resource ownership sane. Don't transfer it implicitely.

This means several things, namely:

DON'T allocate a resource in a method to clean it up in another function at the same level;
DON'T have objects allocate resources and expect the caller to clean it up if something bad happens (note that if your object has a "close" function of some sort, it's really the object cleaning up; what I mean here is don't expect the caller to call a method to get said resource and clean it up by hand);
DON'T program as if exceptions cannot occur in any block, and DON'T try to catch every exception to force cleanup in catch handlers. This is extremely brittle. See Herb Sutter's Exceptional C++ for more details;
DON'T transfer resource ownership if you can help it;
DO try to give any limited resource a finite scope in a single method, if possible;
DO wrap the resource in an object with a close() function (or a destructor in C++) if the lifetime of the resource cannot be determined by the code allocating it.

Respect the computer and the OS; it's more often right than wrong.

Surprising to many who know me, I do apply this piece of advice to Windows-family OSes as well. In my experience, 98% of the time when I thought the compiler/OS/computer was being stupid, I found out that it was a coding error (not always mine, but always within the programming group). There are some exceptions to this: kernel panics and such should not happen through a programming error, period. But I'm talking of more subtle cases, where you wonder why the heck the code stopped working, why the OS is returning an error there, etc. Don't just throw up your hands in the air at the stupidity of the OS, even if, yes, it is stupid sometimes. But you'll probably find with times that if it's not necessarily entirely your fault, it's at least partly your fault, because what you're doing is a bad idea and that's why the OS is being difficult. Of course, OS programmers are human, and so are computer designers; but they have several hundred thousand programmers who bang on their code everyday, and that doesn't count users doing all sorts of nasty things to their nice piece of software; they are therefore tested very widely. OSes are pretty mature these days, and except for, say, exploits and such, if your code acts weird, it's pretty much certain that it's your fault.

Try to listen to what the machine is trying to tell you.

This is related to the previous point. If you have to do something really cumbersome, or scary, or brittle to get things to work, it's likely that somebody is trying to tell you something. Namely, that your semantics are muddled, that you're using the wrong approach, or that you're trying to do something that's not really allowed. Virus writers want to do the latter, but industrial programmers don't; it always causes huge problems in the long run, when it stops working with compiler XYZ and OS Gamma. Another nice way to test whether it's a boneheaded idea is to try to explain it to somebody. If you feel silly explaining it, or you can't explain it clearly, it's probably because you're a bit confused about what you're supposed to do or how you can achieve it. Try to take a different tack.

Sometimes, it pays to trust your intuition.

I've been known to really dazzle co-workers by looking at some code, pointing at a line saying it's not a good idea to do that, and, of course, it ends up being that line that causes the problem they're trying to fix. Now, if you can't really prove that this is the problem, intuition is worthless. But it's easy enough to throw test data at said method/class and check.

The brilliant lone programmer is a myth.

Well, I can't claim that I'm a perfect authority on the subject. But I've known programmers who started out as loners. Sure, they are more brilliant than some more social programmers. But they always reached their full potential only after becoming more social. Programming is about ideas; if you don't exchange them, you can miss something really obvious, or paint yourself in a nice little corner, or constrain your mind to a nice little box of your own making. It is unfortunate that the myth of the lone, incredibly brilliant scientist is so pervasive in our culture; I guess it's because everyone likes heroes. But, as Isaac Newton allegedly said, "if I have seen so far, it is because I have been standing on the shoulder of giants." (Aside: it's interesting Newton, of all people, said that, as there are rumours that he was not really the most cooperative scientist, nor one who shared his results very often). Now, this doesn't mean that I think one should ignore more introverted programmers; rather, one should try to make them feel comfortable in the team, so they start sharing all those insights. Being an introvert myself, I know it's not easy to bring out one, but it's not completely impossible either.

Keep commented-out code out of your source files.

Yeah, yeah, I know, maybe you'll need it someday. Just like protected member variables right? :-) Seriously, you should use source control. If you use source control, there's no reason to keep this cruft around. If you're really worried that you may need it, apply a source control label to the tree before removing it. The reason? Dead code breaks the flow of the code around it, makes plain-text searches find false positives (I know good IDEs make plain-text searches less frequent, but they still happen sometimes), and by the time you'll need it again, it probably won't be any good anymore; it'll have suffered bit rot. If you really must keep some code commented out in the source file, at least be polite and move it to the end of the file with a comment giving a hint where it came from. This way, people looking at it will figure out immediately that it's not something that was left commented out by mistake. But I really think it should be ditched rather than commented out; the latter idea is a lousy compromise at best. Just use source control. Comments are for explanations, not for executable statements.

Avoid doing things that disgust you, especially if the rest of the code already does.

Your objective, when touching a piece of code, should be to improve it, not worsen it. Adding a feature can be seen as an improvement, but it's not necessarily an improvement for the code quality; it's just a feature. Going through the code and resisting the temptation to copy-paste a segment is an improvement. Nobody will pay for such things, and you're always short of time; I know, I've been there. But when I stopped making excuses for myself, I realized that in many cases, I could find a solution that, if it didn't improve the code much, at least didn't make it worse, implemented the feature properly, took less time to debug because it was easier to understand, and (that's the part that surprised me quite a bit) didn't take more time, overall, to do than the quick-and-dirty solution would have taken. In fact, every time I was forced to take the quick-and-dirty solution, when I redid it properly later, I was always really annoyed somebody had forced me, because the proper way hadn't been any longer and wasn't really riskier. Code will worsen on its own; you should always strive to lessen its entropy, not add to it.

Avoid doing things "just in case."

This is the infamous YAGNI (You Ain't Gonna Need It) principle from Extreme Programming. By all means, think of a design that will accomodate "just in case" (just don't take that too seriously nor waste too much time on it). But don't bother implementing it unless you have an immediate use for it. You'll just be adding to the complexity, with no benefit, and you'll have added code that will rot eventually from disuse and lack of testing.

It's not because there's a class that it's object oriented.

I've seen many cases where people would create bunch of classes, each implementing bunch of interfaces... And who, in the end, created a spaghetti-like mess. OOP does not mean you should forget structured programming; it's still there, within your classes. And it's not because you replaced your globals with singletons that you don't have globals in your project. And it's not because your class implements an interface that it's swappable, especially if all the code ends up using the exact class because of missing stuff in the interface. I could go on, but I think you get the point.

Be really, really careful when designing and changing persistent data formats.

Those are always a bitch to upgrade. Your internal code can change somewhat more easily, so internal code organisation is only important for your next maintenance release; if it's not ideal, there's the possibility to fix it later. But broken persistent formats can be a real pain to fix. Even more so if you're signing the data or encrypting it in some way; you may not be able to re-sign or re-encrypt it after you've converted it. Bummer. Changing formats should be done carefully as well, because there's always trouble with conversions or with people who want to use old versions with new data. And no, it's not because you're using XML that you're safe from any of those problems. You can have problems with XML-based formats, too; you only avoid (some) parsing problems, not semantic problems.

Don't go ape with design patterns.

I sometimes think that software design teachers are encouraging students to look for ways to apply patterns when they teach their course. This is exactly the wrong way to teach patterns. Patterns should be a solution to an existing problem: you have a piece of code that needs to do such-and-such thing, so such-and-such pattern will help. You should never, even be given a pattern and asked to apply it in your program. The reason I think this is what's happening is because I've seen a trend in code written more recently that it's filled with pattern mush, often in places where it doesn't make sense. Extra factories where a simple function would do; composites where the composite's properties are not being used; and so on. This is extremely annoying because it can make the code hard to follow, especially if the person applying the pattern didn't really understand it. Also, I find that a few patterns in the GoF book aren't all that useful; Flyweight is rarely applied correctly, and I always found Visitor to be a bit cumbersome (yes, I know what it's supposed to solve, but I've usually found different ways to solve this particular problem, and they tend to be easier to read for maintenance programmers).

Make objects minimal-state.

That is, objects should maintain the bare minimum of the state they need. Never add a member variable just to avoid passing a parameter between two member functions; it may look like a good idea at first, but it's really not--you're adding extra state to the object for no good reason. Would you add a global to your module just to avoid parameters in structured programming? Well, adding a member for that reason is like adding a semi-global, and it's not a good idea.

Avoid the construct-and-call-setters anti-pattern.

I've seen this very often, and it makes me feel a bit sick every time. You have an object with an empty constructor, which must have its setters called before you call any method. IoC is bringing back this way of doing things (so is struts, to some degree), and it really distresses me. What if you forget to call a setter? What if you call them in the wrong order somehow? What if somebody calls a setter after calling a method, thus violating some invariants? By turning an atomic operation (object construction) into a non-atomic one, you're asking for trouble. Strive to keep your objects in a sane state, always. It should not be possible to put it in an insane state from the public interface, especially not by forgetting to call a method... Note that you can always prevent such problems by adding manual checks, but that's brittle; it's better to make it impossible to put the object in an incorrect state in the first place.

Well, that ran a bit longer than I thought, and it contains some stuff that's a bit lower-level than what I initially wanted to write. But there it is; I hope it was somewhat useful to you, at least. It's by no means complete, but it's a start. I may complete this list from time to time when things come to my attention. I may also strike out some items or modify them, as I've been known to revise my ideas on some things.

It's gone, Gone, GONE!!!

2005-03-16T23:03:00.000-05:00

Had an argument with my beard trimmer yesterday around 00:30, which resulted in me shaving the whole thing off, including mustache. Morale: don't shave at 00:30.

Hadn't seen my face whiskers-free for ten years. It looks weird.

Not sure whether I'll let the beard grow back yet. I look less intimidating without, which may have some benefits overall. But my face looks wider and my chin sort of disappears in my neck visually, which I don't find that aesthetically pleasing. But maybe I'm just not used to it. I'll probably give myself a few weeks, and then decide. Probably depending on how many of my friends laugh at me.

I have to get a picture up of The Beardless One, just for everyone's amusement. Stay tuned...

A-25 Redux

2005-03-08T23:00:00.000-05:00

The mayor of the Anjou borough has a half-page on every "Ville d'Anjou" leaflet we get once every month.

On the whole A-25 issue, he has to say that it will improve the pollution situation by putting pressure off A-40, and that the complaint about lack of collective transports is silly since he asked Transport Québec to put reserved lanes for buses on the bridge, otherwise it was a no go.

He also mentions that the bridge won't really make urban sprawl worse, because people are already sprawled all the way to St-Jérome, and that's way farther than the sphere of influence of the new bridge. As he points out, people don't sprawl because a bridge becomes available--they sprawl because they can't find affordable and calm spaces in the city boudaries. Anjou could provide that, especially if it were less isolated from a transportation point of view. The A-25 bridge won't help that, particularly, but as I mentioned in a previous post, I'm worried that no bridge will also mean no metro, no commuter train and no A-720 extension.

Needless to say, I agree with much of what he says. I don't know about the pollution situation, though; A-13 was supposed to help, but didn't in the end, because it only allowed people to settle way further. A-25 won't be as bad since it won't reach all the way to the north shore, but it could still have unexpected effect. I think a longer A-720 would be a better choice if one wanted to make the "less pollution thanks to the highway" argument.

Still good points. Too bad he's preaching to the choir; he should write for the Plateau or Outremont regional newspaper. Still, I have some hope--the president of the chamber of commerce of eastern Montreal wrote an editorial in a major newspaper about the whole transportation infrastructure situation. Hopefully it's been heard.

Keeping my fingers crossed... At the very least, if that bridge has a cycling lane, I could cycle to Laval, and that would be, as they say, Way Cool.

Added to developers' whiteboard

2005-03-02T22:41:00.000-05:00

String b = "some string"; StringBuffer sb = new StringBuffer(); sb.append("a" + b + "c"); sb.append("a").append(b).append("c");

'Nuff said.

Note to future language designers: make sure "+" is an efficient operation, maybe by having it return some sort of temporary "not concatenated yet" list of strings and resolve the catenation at the very end. This would be possible to pull off in C++ given the powerful type system and pass-by-value semantics (and it would literally rock if move constructor made it into the language!). It's not possible in Java, so we have to tell people to be careful. And for some reason, there are a some people who aren't.

Reminds me of the equivalent problem in Python:

b = 'some string' sb = 'a' sb += b sb += 'c' sb = ['a'] sb.append(b) sb.append('c') sb = ''.join(sb)

But notice that it's more a problem of incremental appending than one of usual concatenation. At least, 'a' + b + 'c' will not produce a temporary "string buffer" object on top of the extra temporary strings. Besides, Python does not have pretensions as being the new systems programming language...

Some would argue that neither does Java, but I disagree; witness the number of client apps being written in that language because that's what graduates are taught, and because people can't handle language where the GC does not come by default (make no mistake, the Boehm GC is available for C++ and works very well).

Consumption frenzy

2005-02-26T13:00:00.000-05:00

Got the books! Yay!

Quickly read Money 201 and managed to be uplifted and depressed at the same time. Looks like I've been doing many things right, but a few wrong. Unfortunately, to do those things right, I'll require more money. Or slack off on pre-paying parts of the mortgage. But I hate paying interest, regardless of what finance books say. I should write my own book, maybe.

Read Exceptional C++ style rather quickly. I feel relatively good about it--it's a good book, and it looks like I'm not too rusty. But, to my dismay, I'm also not that interested in all those dark corners anymore (something I've alluded to in previous posts). Still, I wish the "smaller language screaming to get out" Bjarne Stroustrup mentioned when talking about C++ would come to light. The closest I've found so far is Python, and its library is growing a bit messy.

Speaking of libraries, I've had the opportunity to look in the Java libraries for a few things. I was trying to get some substring appends to be efficient. Unfortunately, StringBuffer does not have an append(String, int, int) operation--only an append(char[], int, int) operation. So I had to call substring() (which is bad, but better from a garbage generation point of view than toCharArray() or whatever it's called). Man, I wish for the nth time I could get access to the internal array. Actually, StringBuffer could, if the String's array were package-private, and in my view, this would be a very sensible design.

Anyhow, I look around for a solution, and it looks like Writer has a substring write operation. So, I think, maybe I can change my code to work through a writer instead. But, being curious, I wonder if they just go through the whole array char-by-char, or maybe chunk stuff in a pooled buffer.

The answer is: none of the above. They call substring().

Also annoying, they don't let you create a StringWriter on an existing StringBuffer, but you have access to the underlying StringBuffer anyhow. This is incredibly non-symmetrical and quite stupid.

Coming from the C++ world, I find myself constantly annoyed by the sheer lack of rigor in the design of the core parts of the Java libraries. Newer parts (such as the Collections system) show more care, but some very fundamental classes (such as java.lang and java.io classes) show sloppiness. So, you get new classes that have better concepts, such as java.nio and Collections. But what can they do about String? It's such a fundamental type, and yet they give no way to easily extend it. You can't even access the internal array. Of course, that's done for safety reasons (so nobody can modify the string in place, since the string is supposed to be immutable), but you can still access it anyhow with reflection and a custom class loader. Worse, as far as I can tell from the StringBuffer code, it's not as efficient as it could be, because it goes through the public interface of the string object.

This may sound like a nit, but efficient string manipulation is extremely important. You want to have a language that lets you do as much as you can with as few temporary buffers as possible. Especially when object allocation and garbage collection are as slow as in many JVMs. I've had many sites run out of memory because they did extra copies of incoming requests and outgoing responses. Granted, they shouldn't do that, but given the API provided, it's the most natural way. I mean, I keep seeing (and writing!) code that does such things as "string("+s+")" even though it's inefficient. If it's inefficient, why is it the most natural way of doing things? At least, in C++, the compiler has a chance to collapse the temporaries! The specifications of the Java language prevent any sort of optimization for this construct. Bad.

Rant aside, I got one other thing--Xenosaga II. So far, I like it, although I couldn't fully believe it when they asked me to switch disks (I was a mere 8 hours in the game...). I hope the second disk is a bit longer. A lot of online reviews have complained how it's tedious and so on, but if they had a bit of a longer memory, they'd recall that Xenogears was pretty much the same. This new game feels more like the original Xenogears, with its long dungeons and somewhat higher level of difficulty. There's very few boss fights I finished in a singly try; I usually get killed at least once. This is a refreshing change from most modern RPGs, like Final Fantasy X-2 (which never felt very difficult--you have so much flexibility with jobs, and changeover is so fast, that it's hard to get stuck in an attrition battle with your enemy).

A couple of things are somewhat suboptimal with the game, though. First, I don't know why they messed with KOS-MOS' voice acting. It was excellent in the first Xenosaga, perfectly neutral and emotionless, except for a few (intentional) occasions. The new acting varies, going between somewhat neutral and somewhat whining. It just doesn't work; KOS-MOS is supposed to kick ass, not whine.

I'm also annoyed by the poor treatement they gave Yuki Kajiura's soundtrack. It's an awesome soundtrack, but in the game, the tracks are often cut before they finish (unforgiveable in a game that uses voice acting! The player does not control the rate of delivery, so efforts should be made to time the script to the music; Xenosaga I pulled it off much better), cover them with too much sound effects (disminishing their impact), and sometimes use them in strange contexts. How dare they make Kajiura's work sound so bland!

Load time in combat isn't that wonderful either. However, it's possible to level up relatively quickly, which puts a lot of tedium out of it. I prefer to have less more-difficult fights than to have to fight weak enemies 100 times to level up (like I've done often in FF VII). I might as well put a rubber band on the "O" button if I'm going to do that. I prefer games to treat me like a thinking being than like an automaton who just presses "O".

On the plus side, the fact that there's almost no segments with no BGM helps me enjoy the game quite a bit. The non-movie soundtrack is nothing really earth-shattering, but some tracks are very, very solid. Unlike many reviewers, I don't think it was a mistake to move from a symphonic soundtrack to a synthetic one. Symphonic soundtracks are popular in SF themes, mostly due to Star Wars and Star Trek. But synthetic soundtracks can work well, too--witness early Babylon 5. It's a matter of balance. Strong melodies should accent strong points, and trance-like tracks should be used for BGM in more repetitive parts.

And you gotta love the new character models. Too bad the hands are done with a thumb, index and block containing the three remaining fingers, all the time. That trick is used in Final Fantasy X and X-2 when there's too many characters in the scene, but Xenosaga II uses it all the time. It's a bit sloppy. But the nice face models and expressions make up for it.

I'll post a full review when I've finished the game. Which, at the rate I'm playing, will probably be next week-end or so.

Not so humbling after all, to humanity's great sorrow

2005-02-17T23:37:00.000-05:00

OK, so I was really tired yesterday. Turns out I had good reasons to abstract file lookup: I needed to do easy unit tests. Granted, I could have mocked a ServletContext, but I think it's cleaner this way. So, much to everyone's chagrin, I'm not really humbled by my experience.

I have, however, discovered the benefit of a good night's sleep, yet again. Something I won't get next Tuesday because I have to go to the dentist. How this is interesting to you I have no idea, but you never know!

In other news, the guys at work are making fun of my work habits and love of mechanical keyboards¹. They are mean to me. But then again, I complain all the time, so I suppose I deserve it.

¹ The text in the picture is in french, and reads "Directly from the Espace Logient/Benoit Goudreault Emond/Concerto in Mechanical Keyboard/And Bouts of Anger". This is a loose translation, but it's probably accurate enough. "Espace Logient" is a pun on a show room in Montreal known as "l'Espace Go" (which is, by the way, quite a nice show room).

Humbling Experience

2005-02-16T23:34:00.000-05:00

You know how it becomes customary for all software developers to whine about everyone else's code. Too complex. Too convoluted. Ad nauseam.

Well, read your own code.

Today, I was trying to retrofit some local file-reading capabilities in a system that was mostly meant to read stuff off of a network request. Since the network request bits are semi-auto-configured, I wanted the same capabilities for the local file-reading stuff. So, made an interface. This removed some bindings between the system and the application framework. Made it cleaner, more standalone, etc etc.

Then, in the bus, it hit me: bad idea. The system is completely dependent on the application framework anyways, because database tables/file names/etc. are all done according to an implicit convention that cannot be found outside said framework. So, all this wonderful isolation just made things more complex for no reason whatsoever. At worse, I should ask callers to supply the appropriate framework object and use it directly; if I need abstraction later, I can always put it there--later. Given that it's code for more junior programmers, why make it more complex than it needs to be? It's already a bit complex with a singleton spawning a query engine, which spawns a stateful query and a result.

In my defence, I got very little sleep yesterday :-)

In other news, I just ordered bunch of books from Amazon.ca. If you want some software-engineering-related or C++-related books, they have killer rebates right now (50% off selected books). Some of the books on sale are not that great (if I see one more "Enterprise Java with xyz" book, I'm going to hurl), but some others are the Herb Sutter classics, and some rather new books on working with legacy code and configuration management. I got myself the Sutter classic I didn't have, and "Working with Legacy Code", which is something I really need to read RFN. Especially since today, I was writing, effectively, legacy code, and it was my fault.

Also ordered a personal finance book, because it's tax season right now, and my new financial adviser seems to be determined in making me feel inferior. But looking back with a cool head, my gut feeling is that, besides a little bit of neglect (mostly money stuck in an ING account instead of invested in, say, a dividends fund), I've done pretty well. Probably the advisor's tactic was merely to try to sell me a credit line, something which I'm not really open to.

Finally, I realized, to my disappointment, that cool template tricks don't really do it for me anymore. I had the chance to get the Template Metaprogramming book 50% off, and I passed. It looks cool, but I have very dim hopes that I'll get to use it, because:

It tortures compilers, including G++, and
I don't think I'll ever be allowed to use this stuff except in a few toy or hobby projects, because it'll be very hard for any company I ever work for to find people able to understand this stuff.

In many companies, there's a "language guru" and a number of journey(wo)men. I've seen few places where there are many gurus (though Silanis was one of them at a time), and even then, they're hampered by management's fears that nobody will be able to figure out the code. A very sane fear in some ways, but not as much as one would think when you realize that code written by non-gurus tends to be as obscure as guru-code, except it's not because of mere technical proficiency reasons!

I also realized today that what I'd really like would be to rewrite my current company's codebase all in Python. But then, I'm sure nobody would want it, even though Python is easy, because we hired Java programmers, of course. Everyone's so damn specialized.

Well, that was today's rant. I need sleep. Especially since re-reading my previous lines makes me realize that the experience is having less and less of a humbling effect as I get riled up...

Whither Moore's law's application to everyday computing?

2005-02-08T01:16:00.000-05:00

An interesting article: Where have my cycles gone?.

This article asks the question I've asked myself for the longest time.

Nowadays, it's not as bad, because I run Linux on my home computer. I have, therefore, a good idea where my cycles have gone. The computer is pretty snappy at this time (well, it is an AMD Athlon XP 2000+, but there's a mere 256 MB of RAM), despite how much resolution I drive it with, how much anti-aliasing I've added, and how many background services I run.

But whenever I use a Windows XP computer, a Java application, or even some Linux desktops (those with GNOME or KDE come to mind... I use XFce which avoids much of the madness), I really wonder: given Moore's law, how come many tasks appear to be slower than they ever have been?

The author cites some understandable reasons. Here's my take on reasons I do not understand.

Incorrect algorithms: somewhere, programmers have gotten really sloppy. Trying to sort linked lists with a classical quicksort (hint: don't!), running through data structures many times in an effort to work on the data where a single pass would work, doing all sort of really stupid things to help performance (such as adding cache to an O(n²) algorithm that could really be done in O(nlog₂n)), and so on and so forth. I'm always suprised (in a bad way) at how many things are done with such sloppy algorithms. If the programmer would just think for a few seconds, it would avoid such problems. Complexity problems like this are usually trivial on small data sets, but what if your small data set is the set of pixels in the GUI blit routines that get used all the time, hmmm?
Wrongheaded ideas: some OSs and applications have patently bad ideas at their core. Like searching stuff frequently that is not indexed. Like putting files all over the disk and expecting the filesystem to have an efficient lookup algorithm tailored to your application. Like opening multiple database transactions where everything should be done in one (this is bad for performance, but also for data integrity). The list goes on. I see this in commercial software all the time. I can think of no fundamental reason why system applications would be in a better state, given that they are marketed nearly the same way as user applications (which, IMHO, is really wrongheaded!). User applications, of course, have all those problems. Yuck.
Speed/memory tradeoffs: for some reason, everybody got drilled into them that you should always save cycles in priority to memory. So people read the whole file in memory and cursor through it with pointer operations. So they put stuff in sparse hash tables where a sorted array would do and give significantly similar performance characteristics. So they introduce lots of caches to gain a small 5% increase in performance. It doesn't work, and here's why. Today's systems are usually starved for IO time or for memory; CPU is rarely running at 100% while you work (take a look at a system monitor or at the Windows Task Manager during the day; you may be very surprised at what your computer is doing). As people try to run several programs at once and get them resident, the problem worsens. Once physical memory is exhausted, the system becomes starved for IO time as the OS needs to swap stuff. If you get in this situation, it will always be much slower than the "slower" algorithm that uses almost no memory. There's also an interesting effect I've seen in some cases: due to CPU cache effects and the importance of keeping a working set small so it's most effective, larger uses of memory may be detrimental for performance in many situations, even if the OS isn't starved for RAM.
Memory/resource leaks: they're everywhere. Garbage collected languages are great, but they shouldn't be taught as the first language. People who learned on garbage collected languages tend to think that the garbage collector takes care of all resource allocation. Hate to break it to you, kids: it only takes care of memory allocation, and on top of that, if you keep references to an object too long (like in caches...that thing again!), it never gets collected. Garbage collection is no excuse to be sloppy about object ownership. See previous point on why resource leaks eat up time.
Freakin' objects everywhere and the lack of stack allocation: this is mostly a problem for language like Java, which couples an asinine lack of stack allocation for simple objects with a really slow allocator and garbage collector. Mix in a really high per-object allocation overhead (all object get a condition variable and a vtable, whether they need it or not!) and you've got a recipe for high temporary memory usage. That would be OK if the Java VM contracted its memory use once in a while. But NOOO! I sometimes think those who wrote the JVM have disregarded 30 years of computing, both in VM design and in garbage collection algorithms. I can think of no other reason that would explain how they could deliver such a ridiculous JVM 1.0. And I still don't understand how many of my Python scripts have more predictable performance than many of my Java programs, despite the JIT and the fact that the Python programming model does not lend itself to much optimization.
Buzzword mania: why is it that we need EJB? Do you do transactions across multiple databases? Do you really need to distribute your objects (remember the first law of distributed computing: don't distribute your objects)? Replace EJB and related questions with buzzword of the month. Many products are built with technologies that don't really fit the problem, increase complexity, memory use, and decrease performance, for no visible gain in capabilities. This is really dumb. See my earlier article on why software projects fail.

Is that it? Probably not. But I think it covers a lot of things. If you're studying in CS or Comp. Eng., I really recommend that you do the following:

Study algorithms. Know the main ones. Know which data structures have what complexity guarantees. This will help you choose the right structure and algorithm for the right job.
Pay attention to the more low-level classes. Assembly looks like pre-history, but the principles of how machines work will always remain useful. C and C++ feel like nailing your toes to the desk in an awkward position, but you'll learn to be careful about resource ownership, and that's a valuable skill regardless of the language.
Remain skeptical of those who claim your designs aren't "elegant" enough. There's always a sweet spot; but in any case, a design with less code will almost always be more elegant from a maintainability, understandability, and from a performance point of view as well. In my experience, university "elegant" means "complicated". It's cool looking, full of design patterns and objects and inheritance. But when 60% of what you typed is syntactic and semantic sugar, you'll end up with a mess sooner or later. And that will make it harder to figure out whether you picked the right algorithm. Don't misunderstand: elegant design does exist. But you'll have to develop your own sense of it. The understanding of elegant design in academic circles varies widely. Be especially wary of teachers who don't code, or instructors who never had to maintain any of their projects. Design sense mostly comes from learning what not to do by having done it and being stuck maintaining it.
Remain humble when you're about to do some task. You may be smart enough to implement the equivalent of a database by hand; but why take the chance? And even if you're smart enough, keep in mind you don't really have the time anyhow. Solved problems may be fun to solve again, but good commercial-grade code is always developed with time pressure. Time you spend on your fun problem will be taken away from time you should spend making the overall system design maintainable.
Try to understand what you're doing. Try to understand the libraries you're using, at least in a general way. Otherwise, it's going to be very hard to pick a given routine (or even a given method overload!) over another.

Well, that's my advice, for what it's worth. I just realized that a lot of it applies to people who already program professionally, and I can think of a few people who don't follow this advice. I know I try to follow it carefully, and it served me well so far. I've been programming commercially for nearly 5 years, and as a hobbyist since I'm 14, so I like to think that I've learned a few things at this point. I'm sure there are other things programmers should be careful of, but those I've noted in this post are supposedly 'obvious' and people still don't do it.

Hence this rant.

Hopefully, if people apply those, Moore's law's application to everyday computing, in the form of faster, more capable computers with the ability to do more for their users, will become reality.

Bela Lugosi Night

2005-01-29T23:04:00.000-05:00

For christmas, I got a pair of DVDs from the "classic horror movies collection". Given by none other than my very cool parents, who know how to humour my strange tastes.

Today, I was feeling sort of lousy, so after the grocery run (well, I went to the mall, but nothing really inspired me, except a miniature plunger for my bathroom sink... how exciting), I curled on the sofa and listened to a couple of movies, both starring Bela Lugosi.

For those not knowing Bela Lugosi, he's an actor who played in many 40's horror movies. But his main claim to fame in modern cinematography is probably his partial participation in one of the worse movies ever made, Plan 9 From Outer Space by director Ed Wood. Lugosi was slated to play the head vampire, but he died early in the making of the movie. Ed Wood, ever the optimist, replaced him with a much taller man who had a different face and had the replacement cover his face with a cape for the whole movie. If you haven't seen Plan 9, you should; it's quite bad, but so bad it's sort of good. Ed Wood by Tim Burton is worth seeing as well; it's a not-quite-documentary on the making of Plan 9

Anyhow, for those reasons, Bela Lugosi is known to me. But the only movie I've seen him in was Plan 9, which doesn't count.

Hence: The Devil Bat. Nutty doctor bitter about some rich man making a fortune on his discoveries (the doctor cashed out instead of getting a stake in the company) invents a way to make bats gigantic using electric current (???). He conditions the bats to hate the smell of a particular aftershave he's developing. He then distributes the aftershave freely to members of the rich man's family and sics the bat on them.

It's a harmless movie. Special effects are especially laughable, but it was made in 1949. Though they could have been more careful about some things, like the bat-flying-out-the-window shot where the window is obviously NOT the window we saw open (the bricks don't have same texture, etc). There's some priceless Lugosi acting (meaning, quite exaggerated) like replying to "goodnights" from his intended victims with "goodbye Mr. insert name here". A rather silly subplot of the hero's assistant trying to woo the rich man's daughter's French maid. And the rather unnatural switch of the female lead's affections from her murdered intended to the hero (man--it's like it's the most natural thing in the world!)

That said, it's too bad such movies don't really have a soundtrack, because some parts run a bit long and dry.

Then, I listened to The Human Monster. Unfortunately, sound quality was somewhat poor, as it's a really old movie. Lugosi exaggerates his expressions even more than in the other movie, and his face just screams "villain!" all over the place. I found that movie a bit less enjoyable, although it's definitely more serious and more care was put into it. I guess it's just too serious--old horror movies should be cheesy. But as far as it goes, it's not that bad a movie, with a pretty predictable plot, but some relatively well-scripted moments. Keep in mind I'm no movie expert. Unfortunately for me, who wanted to look at a Lugosi flick, he gets less face time here. I must admit, though, that I found the scene where he puts the female lead in a straightjacket and drowns a man in front of her quite tense and effective.

Looking at old movies like this is an interesting experience. You realize that modern movies have more technical means, but their plots stink--they're as predictable as those old things, and often play on the same themes (there are exceptions, but there were exceptions then as well). You realize that while attitudes towards women have changed on the surface, they are basically the same in modern movies; they were simply quite a bit more open at the time, and they weren't as bad as many people make it in comparison to those of modern movies. The female lead in The Human Monster is a damsel in distress, but she's also incredibly stubborn about wanting to find out who killed her father. Surprising after seeing The Devil Bat, where the female lead is a human carpet in many ways. As now, scripts vary widely.

Well, I'll probably listen to other movies from those disks in the near future and let people know what I think about them.

Dumb questions for Java heads

2005-01-27T21:12:00.000-05:00

At work, we came across a really annoying problem upgrading some machines from Tomcat 4.1 to Tomcat 5.0

We have some servlet mapped on the servlet-mapping "/". It's supposed to handle an URL known as /en/blah. Now, due to some rather odd customer requirements, we're also required to have a physical file /en/blah/index.jsp, which, even more oddly, contains a redirect to /en/blah/natter (instead of /en/blah).

When the user browses to /en/blah/, Tomcat 4.1 calls the servlet. So does Resin 2.1.x. But Tomcat 5.0 opens up the welcome file /en/blah/index.jsp.

OK, I know it's not such a good idea to have two potential targets for a given URL that yield different results. But, I'm curious whether either behaviour is mandated by the Servlet specs? Or is it simply undefined?

My reading of the 2.4 specs says that the "/" servlet is the default servlet, and welcome files have higher priority. However, this may not have been the case in earlier specs. But looking at the changes in the back of the 2.4 specs, they don't seem to mention anything like that. Or maybe I'm missing something.

Just curious...

Star Wars Revisited

2005-01-23T23:59:00.000-05:00

Well, not really revisited, but I can't think of a more interesting title.

Three friends and I decided we needed to watch the original Star Wars again (not the one that was "remastered"--the real deal, with nothing more than slight picture clean-ups; unfortunately pan-and-scan). Of course, having seen it many times, it's a great occasion to poke fun at it.

OK, so there's the usual corny lines, botched special effects, and so on... but it's still quite good for the time.

However, something unusual happened this time. I noticed something new. In "A New Hope", in the scene where the imperials break in the room on the death star where the droids have been hiding, watch the rightmost stormtrooper carefully. He's taller than the others, and he appears to bang his head on the door frame!

Isn't that cool? It's not? Oh, just shut up.

Weather update

2005-01-23T11:18:00.000-05:00

In case anyone cares, or even if nobody does, it's frickin' cold today. It was also frickin' cold yesterday, the day before, and the day before the day before. I wouldn't mind so much, except that the days before that, it was a very warm -5 centigrade.

And there's no snow. Which is a moot point, I guess, because it's way too cold to cross-country ski; I'd probably be drained after a mere kilometer, all my calories going into my body's central heating system.

I take hope in the fact that January is the coldest month in Montreal, and that it can only get warmer from here. But maybe I shouldn't even think that, as nature always has some nasty surprise for us in February.

I normally wouldn't mind the cold, but I now pay the heating bills directly (they used to be part of my rent). My heaters are electric, which means it's less polluting (Montreal power mostly comes from insanely huge hydroelectric dams), but it's also more expensive per Joule presently. I think the last two months have been more expensive than the previous six months, even when taking the A/C into account. And I've been really cheap on heating, keeping ambient around 15 centigrade, five degrees below the "comfort temperature".

Bleah. And municipal taxes are going to hit me on the head soon, too. Joy.

Ah, well, that's what I get for not moving to California when I had the chance. Then again, I'm not sure I'd still be employed if I had moved down there, with the .com bubble and all. In any case, I'd have less liquid assets because property prices are insane down there. I suppose all those temperature shifts have their compensation--nobody wants to live there, so prices are still somewhat affordable.

About the A-25 bridge

2005-01-22T22:06:00.000-05:00

OK, this post is going to be of little use to those who don't live in eastern Montreal, unless you are somehow interested to get some idea how life there is.

It is, uninterestingly enough, about a highway.

Montreal is oriented in the southwest-to-northeast orientation. However, northeast is usually called the "east" of the island, because streets run parallel to the island's axis. Same goes for the "north" of the island--it's actually northwest, perpendicular to river St-Laurent's current.

In the middle of the island, there's St-Laurent street, which cuts the island in two parts: the west and the east. The west has traditionally been Anglophone, multicultural, rich, dense, commercial and well-served by major infrastructures (roads, commuter trains, and so on). The east has traditionally been Francophone, mostly white, poor, full of strange empty spaces in the middle of nowhere, industrial and somewhat isolated by poor transport infrastructure.

In recent years, the industries of the east, mostly related to manufacturing jobs, have closed down or moved back to the States. The east of the island turned somewhat commercial with a rather large complex centered on a huge shopping mall, Les Galeries d'Anjou. Around that area, high density building were built. The east became attractive to immigrants, provided they could figure out French reasonably well (Haitians and Vietnamese are a natural fit and a common sight), because property value was much lower and yet the new constructions were reasonably well-built. The trans-canadian highway, known as A-40 in those parts, was prolonged to the end of the island, and the A-25, a north-south highway, was built, linking east of Montreal with the south shore cities of Boucherville and Longueuil.

Actually, it's probably easier to see a map (apologies to the SIA for linking to theirs). Note that the map has an area known as "Centre-Est", which I'll refer to as Hochelaga because it's the "traditional" name.

Other parts of the east became attractive as well, still because of low property costs and reasonable building quality. The formerly half-destroyed Plateau Mont-Royal became so trendy that prices there have become unaffordable, and since west of it is downtown, people are moving east to Rosemont or Hochelaga. Hochelaga is still half-destroyed, but it's slowly becoming more interesting, as young couples move in and renovate the heck out of old duplexes.

Other parts of eastern Montreal are doing OK as well. Anjou is mostly doing well, thanks to north-east Anjou being an industrial park, and thanks to a reasonably efficient town administration. St-Leonard is doing well. Rosemont is doing reasonably well. Some parts of Mercier west are doing quite well, being brought into the orbit of Rosemont. East of A-25 is not doing that great, but services aren't all that bad and property price is ridiculously low.

Overall, eastern Montreal is more affluent than it used to be when compared to western Montreal. The price of properties is still somewhat on the low side. And yet, people fail to flock there. New home-owners consider Longueuil (south shore) or (shudder!) Laval (northwest of Montreal). Why, exactly, is that the case?

I think the equation is very simple. I live in Anjou. East of St-Leonard, it's the best-served burrough in terms of public transportation and road infrastructures (I consider the road infrastructure in the immediate neighborhood to be better designed than that in St-Laurent, which is in western Montreal). I work downtown. It takes me 50 minutes to work with public transportation, roughly 45 without. In St-Laurent, where I was geographically further from downtown, commuter train would take 30 minutes, and driving would take 25 provided there was no traffic (which never happened, but never mind). Times to go downtown from Laval are roughly the same (ok, maybe 40 minutes by bus/metro, but Laval people are way farther from downtown than I am!), and Longueuil residents can make it even faster.

Why?

Answer: north Anjou does not have a metro, which it was supposed to have 15 years ago. South Anjou sort of has a metro, provided you don't live too far from A-25. No commuter train at all. Roads? A-40 does not take you downtown; it takes you north of Mt-Royal, and then you have to go down some crowded, busy streets like Parc. Or you can drive all the way to A-15, find yourself in ridiculous traffic, and double back. Or you can take A-25 down to Souligny, cross the Armed Forces base, take Dickson to Notre-Dame, dodge potholes and huge 12-wheelers to A-720, and then finally reach downtown.

Oddly enough, despite sounding way more complicated, that's the fastest way to get downtown. Seriously. Even if there's no traffic on the A-15. This, as they say, sucks.

In the case of a western resident of the island, it's much less annoyance. Take the A-15 to downtown (and you can take it from A-40, A-20 or even A-520, depending which has no traffic that morning). Sure, you get a lot of traffic, but at least there are no traffic lights, so what you lose in traffic you gain in continuously moving. Not a option on Notre-Dame. Laval people just take the A-15 further away. Longueuil residents take the bridge (which does get jammed, to be fair) directly to A-720 and zip downtown.

If you factor in public transportation, the difference is even more marked. Western Montreal has plenty of commuter trains, even if you go geographically farther from downtown than Point-Aux-Trembles is. Laval has commuter trains and is getting a Metro before eastern Montreal, even though that damn Metro station is costing three times more than was expected (and costs are still rising). Longueuil has had the Metro for a long time, and has commuter trains as well. Granted, though, east Laval and east south-shore aren't well served by trains (see this map, and weep). But they have their own east-west highway (Laval has the A-440, south shore has A-20 and A-30) which east Montreal does not have south of A-40. In fact, if you look at the commuter train map, it's painfully obvious that there is no service for the east.

OK, so some of those parts don't have that much population density. But neither did Longueuil when it got the Metro, and Laval, while dense in some parts, has a very sparse population. In any case, they are off the island, and contribute largely to urban sprawl. They are also far.

It is becoming clear to everybody involved at various levels of the government that this is somewhat unfair for denizens of the east. The A-25 already exists in Laval and north of the A-40, but the two sections are not linked. The provincial government has finally decided to build the bridge to link those two sections. Hopefully, it will allow traffic to the Anjou industrial park to possibly take the A-440, thus freeing the A-25/A-40 junction during rush hours (it should be known at this point that the Galeries d'Anjou complex is smack in the middle of the A-25/A-40 junction; it's quite interesting during rush hours, especially since the closest bridge to Laval is all the way west in St-Leonard, clogging the A-40 with huge trucks). Of course, this does not solve the problem of going west from south of the A-40, so the project also implies some rather large changes to Notre-Dame. It was originally planned as a highway, but nobody can make up their minds what to do about it.

This bridge would be a toll bridge. It would probably relieve some pressure to the A-15 and the A-40 (which is already not managing traffic well at all). Less idle engines and all that.

And of course, the first reaction of every environmental group is to decry it as an enemy of substainable development.

OK. Fine. I understand people don't like having huge highways carved into what used to be idyllic fields of grass.¹

But, I mean, come on! The frickin' A-25 is already pushing north all the way to Henri Bourassa (north of A-40), there's a huge boulevard north of that where people have a really heavy foot on the acceleration pedal, and nothing was built around it for years because it was known that there would be a highway there someday! On the Laval side, the highway is already there and pathetically waits for a bridge to show up! There's huge concrete blocks in the water already, only awaiting for funding to build a full bridge!

Critics then point out that the new A-25 bridge will require changes to Notre-Dame, cutting the south of Notre-Dame off from the rest of the island. This is utterly ridiculous. South of Notre Dame, between Dickson (close to A-25) and the A-720, is the Montreal Harbor. It's a fenced area where only 12-wheelers can get in. Because Notre-Dame is a street instead of a real highway, it's full of potholes from those 12-wheelers and I'm sure a lot of pollution is generated just by the efforts to fix it year after year. You may hate A-720 for cutting off downtown from Old Montreal, but it's not going away, and we might as well do something with it. Turning Notre-Dame into a highway would probably not make noise or pollution much worse for residents immediately north of Notre-Dame, since traffic there is already very bad and full of huge trucks. It may actually improve things, since the highway would be either in a tunnel like A-720 or walled off like A-25 in the Anjou and Mercier areas.

Critics finally point out that we should build a commuter rail to the east instead. I agree that we should build a commuter rail; it's sorely needed. Actually, we should prolong the metro (preferably with at least one station north of A-40), but with the Laval metro costing so much, the AMT has no money for that. The rail is needed anyhow, because the metro won't help Pointe-aux-Trembles or Rivière des Prairies. But the rail also won't cost that much--maybe 20 million or so--because the track is already there, all that's needed is to build train stations. So it's not as if the A-25 bridge is competing, in terms of financing, with the commuter train.

Finally, I'd like to point out that all critics of the A-25 bridge live in Outremont, the Plateau or some other central area of the island. They have no idea how ridiculously isolated eastern Montreal is. From Pointe-aux-Trembles, it takes 1 hour 20 minutes to get downtown! From east Laval, don't even think about it--not only you'll waste time and gas driving to the A-15, but then you'll be stuck there for at least an hour in traffic, and you'll then have to double back on the A-720! At this point, any development is welcome. Eastern Montrealers hope that starting to build any of these projects will probably get the others built as well.

I'd also like to point out that although the bridge will be expensive, so was renovating the Acadie circle, and so are the repairs to the A-40 brought by ridiculous amounts of traffic. But nobody yelled when those were done. Of course not--those were needed. The fact that many of those people who don't want Notre-Dame to become a real highway nor the A-25 bridge to exist at all live in Outremont is surely a coincidence.²

What really pisses me off about all this, though, is that such concerns were never raised when Laval or Longueuil was to get its infrastructures. The metro eventually followed, because the roads were too congested. But now that eastern Montreal would finally get decent infrastructures, which would probably help develop it (there's a lot of mis-used space there--much more than in dense, crowded western Montreal), all of the sudden, those concerns show up. OK, fine, some of them have some validity to them--why don't you lobby for a damn commuter train and for a damn Metro line, instead of against a bridge?

Deep within myself, I believe that nobody really cares about eastern Montreal. Nobody has cared about it for the longest time.³ I hope that will change. It's easy to yell about new infrastructure being non eco-friendly when you have your infrastructure already built. Sort of like industrialized countries going all sanctimonious on developing countries about pollution, but not being willing to share more efficient technology with them, or to sell it at a lower price. It's also really idiotic to yell like this before the whole project is known; for all we know, the government may be planning a light rail line on that bridge! I don't always agree with the Charest government, but I hope that in this case, it will not back down. We've been waiting for that bridge for 30 years. It's high time eastern Montreal and eastern Laval got the chance to show off their potential.⁴

¹ I'm being sarcastic here. The only fields above A-40 in the A-25 axis is full of weeds, power lines, and is crossed by a railroad. It's not idyllic at all, and if it's not contaminated by idiots dumping stuff there, it certainly is by the PCBs that were used at a time to isolate power lines.

² I'm not trying to single out people living in Outremont here. But one of the people who utterly destroyed the Notre-Dame project is the current mayor of the city, Gerald Tremblay. He lives in Outremont. He feels Notre-Dame would cut off part of the island. He's obviously never been east of Papineau; there's nothing south of Notre-Dame there, except a harbour and lots of contaminated soil. I suspect those writing editorials against the bridge live west or close to St-Laurent. They obviously don't know that a) the highway is already there, we're only talking about a bridge; b) the Anjou industrial park is not developing as well as it could because of this silly highway configuration; c) east Montreal is not going to get a metro because Laval got theirs and it was too expensive.

³ I suppose a sensible question to ask me at this point would be, "why did you move to eastern Montreal if it's so isolated?" The answer is, I'm not really that annoyed by long transit. But those living in Rivière des Prairies or Pointe-aux-Trembles are not amused. Also, I wanted to find a place I could afford. Finally, I grew up in eastern Montreal, and it's an area I really like. I realize that I wouldn't have had such a good deal if the area had full infrastructure; but now that I'm there, I'd selfishly like it to show up.

⁴ Especially since east Montreal and east Laval are being neglected in favor of much farther places like Deux-Montagnes or northwest Laval, since those have good highway access. Having cars travel 45 KM instead of 20 is certainly not an improvement in terms of pollution. I'd much rather have east Montreal settled than those places, and it's not happening because of lack of access. Perversely, I think the lack of bridge, rail and decent Notre-Dame highway encourages urban sprawl; critics say the opposite, that keeping the east of the island isolated will counter urban sprawl. Well, people don't care about theories; they just go to St-Eustache or Deux-Montagne, or they go to Longueuil and emit thousands of tons of carbon waiting on Jacques-Cartier or Champlain bridge.

Fanfiction redux

2005-01-11T22:20:00.000-05:00

After a seemingly interminable funk, I finally feel the writer's itch again. I'm giving yet another shot at the conclusion of my FF7 trilogy.

This time, I'm not even planning out the whole plot until I've got some more material written. I'll try to write "as it goes". At worse, I'll revise later. I feel that many decisions I'd taken in the previous installment really painted me in a corner if I kept the old plot structure I had in mind, so I'm killing it.

This post is mostly to force me to actually finish the damn thing.

Actually, I may have a better chance than last times I tried. Those long public transit trips help a lot. The fact I ran out of stuff to read until I get my ass to the library helps as well. Finally, I really feel the itch. Before, I was trying to write as an obligation, that is, I hated the fact the trilogy was incomplete. This time, I was cooking last week-end and, as I was waiting for the pressure cooker to finish whatever it is pressure cookers do (ok, ok, I know they cook stuff; it's a pressure cooker, duh!), I just got the editor out and started writing on a whim.

I can't promise anything, but I feel good about this time.

It's just too bad that I have to scrap all the stuff I had already written for this. Maybe I'll recycle it some day. But I'll definitely not use it now; that stuff is poison and has "painted in corners" all over it.

Hmmm, maybe I should have a "failed fanfics corner" if I ever get over my embarassement...

Neat Eclipse SWT trick

2005-01-04T22:15:00.000-05:00

I've been rather underwhelmed by Eclipse's performance under Linux compared to Windows. Turns out the main problem is a huge mismatch between the widget model for SWT and that of GTK+.

Thankfully, somebody ported SWT to another free widget set, the FOX toolkit. It's available here. It works quite well as far as I can tell, although my tests were extremely basic.

I'll have to try it at work and see if Eclipse is usable on my workstation there.

Another nice tool I found (although it's probably well known, but I didn't know about it until a co-worker pointed it out) is xbindkeys. Unlike many other key binding programs, it works on key combinations for those of us who don't have an "internet" or "multimedia" keyboard (I have a much beloved but somewhat low-tech Fujitsu KB 4725, which is one of the few mechanical keyboards still manufactured, and I'm not giving up mechanical keyswitches for extra "internet" keys!)

I hope they'll be as useful to you as they were to me.

Why Software Projects Go Wrong

2005-01-04T20:21:00.000-05:00

A rather ambitious title for a humble post.

Reading (as I tend to spend much time doing) Slashdot, I found this post which leads to a formal survey. The survey in itself is interesting, but it suffers as much as any survey: it hinges on people's perceptions.

So, I thought that adding my own perception on why software projects don't work well would contribute to the body of knowledge somewhat. After all, the study does not reveal exactly why software projects go bad; it only reveals what we think goes bad.

So, here's my modest contribution:

Mismatched metaphors

This is, to me, the worse problem in software development today. It's a meta-problem, that encompasses using the wrong methodology, unrealistic time pressures, lack of customer involvement, and even design complexity. Those things can arise without the mismatched metaphor problem, but a mismatched metaphor can lead to all of them.

Good examples of this are: the idea of software as manufacturing, or of applying construction-related methods to software. Another is the insistence that you need artificial deadlines to stimulate people, that programmers are fungible resources, that resources can be exchanged freely, that software complexity scales linearly, components that are supposed to fit like lego blocks, and so on.

Software is not like manufacturing or construction. Software construction is what the compiler does: it turns a design spec (source code) for algorithms into a final product (an executable algorithm in machine code). In the days before advanced programming languages, "hand-assembling" the code, as well as the translation from pseudocode to assembly, could be seen as construction. Those are largely automated today. Time for software construction scales linearly with hardware power (well, not quite, because there's hard limits like hard disk access times and so on, and some code optimizations run only in quadratic time or worse, but much of code generation is made up of linear processes).

Writing software is mostly a design activity. Some parts are construction: writing the same string sifting algorithm for the 100th time, translating a high level algorithm into a language that's not quite abstract enough, and so on. Those tasks will eventually become easier and mostly automated with time, as better libraries and languages appear. Some may remain, for the same reason we don't write everything in pseudocode: we don't know algorithms to make every algorithm description into efficient code without human aid.

It is therefore closer to the design stage of construction or manufacturing.

An aside: construction projects are very often late, mostly due to mismatched designs or misbehaving contractors. So, it's not really as if they have a sterling record with their methodologies. Besides, from the construction point of view, software has relatively good track records, as long as you work in a shop that has decent configuration and build management. Manufacturing has a better construction record. However, the amount of investment it requires is tremendous. Try retooling your whole factory in a few weeks to produce a very different widget. This happens very often in software, though.

Mismatched metaphors are sometimes applied by project managers, but it's only deadly when it's applied from a higher level. When most of the upper management believes that software is "like" some other thing (other thing often being a process where fabrication is very expensive), be very afraid. Software is not like any of that. If it's close to something, you could pick, say, producing music on tape. Except that music is never tweaked once it's on tape! So there's really very few things that are similar.

To summarize: Software is unlike any other human creative activity. Treat it as such and respect its differences.

Unrealistic expectations

While people who don't know software shouldn't decide on methodology based on other things they know, people who know software just a little bit can be very dangerous, too. Often, they have certain expectations as to how easy or hard certain things are. They'll estimate times based on this instead of asking their staff.

To be fair, I've seen this mostly happen when past staff had the nasty habit of padding their schedules by way too much, either to goof off or to hide the fact that they have no clue what's going on. But it's not always the case, and if the staff changes, there's no reason to keep judging the new staff from the old standards.

But sometimes, they just have no idea how complex the software has become, or they were used to shipping very "quick and dirty code" (this is the case for many senior execs in startup companies who used to code) and that low level of quality is not acceptable anymore. Also, sometimes technology changes, and it's unfortunate that some new technologies in the realm of software have reduced programmer productivity rather than augment it.

Now, this is no excuse to let programmers goof off. Find one that has a history of delivering good results. Good estimating skills are nice too, but most valuable is the ability to smell "trouble areas" in requirements and designs. That person is probably a good sounding board on whether estimates are bunk. If such a person is giving you vague answers, it's likely that the problem is mis-scoped or that the code is of enough complexity that the person is unsure. In those cases, be willing to give them some slack.

Also, never underestimate the power of an existing codebase to ruin your day. Especially if those who wrote that codebase have left.

In summary: Don't expect anything. Ask your technical staff what to expect; it's more likely to be correct.

Fads

It's interesting how software is often managed with the expectation that it works like a manufacturing project, but management itself behave like youths, sniffing for the latest trends and acting like fad-crazy dolts.

For better or for worse, the IT industry is full of "fads" that keep ruining projects. They do provide a lot of fun for skilled programmers, as they provide new things to do and learn. But unless you're building a prototype or you have a lot of spare cycles to spend on exploratory products, it's not a good way to select technology.

There are, of course, new technologies, and those should be adopted. What make fads different, though, is that they always claim to be a silver bullet, but you must apply them to all your code and use them properly if you are to reap the benefits. So huge rewrites of a somewhat crufty but at least working codebase are ordered.

Note that there are reasons to rewrite large pieces of code, especially if the code is presenting serious structural problems or if it was left to the tender mercies of bit rot. But implementing a new technology by rewriting an existing application is very dangerous. First, because unless you're fanatical about documentation and process, the enumeration of everything that application does is not available. The application will have a bunch of features, behaviours and quirks that everyone is used to, but that nobody really knows completely. However, new technologies is nearly never one of them. What you need is either an adapter, or a fully new product, with a new name, so people don't expect the same thing. For more on this, see this Joel on Software article. Note that Joel was later proven wrong about Mozilla; in the long run, they did the right thing. But they aren't a commercial entity, and most software is done by commercial entities that cannot afford to wait that long because that'll only mean the code will be lost.

So, to summarize this somewhat rambling point: don't let fads rule your product roadmap. Don't accept projects that embrace a new, never used technology without prototyping first. New technologies must always be explored, and programmers should be given the chance to play with them from time to time (on company time, otherwise it won't get done; don't worry, once you've given them some company time to play with it, they'll probably put more of their own time, because it's fun). But don't let the latest trade press articles make you plunge headlong into using this new whizz-bang without due consideration and a technical exploration.

Piling up stuff

This one's simple: the temptation, when a product is already late or borderline, is always to add features "while we're at it." This makes no sense, but still happens. Don't do it. It makes things later. Ship the damn thing, whatever it takes, then schedule time to add those additional items.

Unless your customer is very tolerant of slippage, adding stuff since you're already late does not make sense. It's likely programmers will still kill themselves to get the stuff out. You end up with a pissed off customer (since the product was promised earlier) and a pissed off staff. The former can be damage-controlled; the latter cannot. A pissed off staff is a very, very bad thing, and you should take it seriously.

If you must add stuff, or fix bugs, move the deadling. If you do anything else, you're playing the ostrich. The deadline will slip. No, the slack time the PM put in cannot be used to fix extra stuff; it's already used because software is still an inexact science.

Multiple lines of power

This one is my favorite. It's also the most common.

When it comes to making decisions on a project, there should be one person with the power to move deadlines, cut features, leave bugs in, send programmers home to rest, and so on. That person is the one with the responsibility of the project succeeding or failing, usually called the project manager.

If you give responsibility to somebody without giving them those fundamental powers, you are setting that person up for failure. That person is likely to sense that and not work at the best of her abilities, to say the least!

I've been on countless projects where technical decisions were taken in advance, during the project, without advice from the developers, and over the head of the project manager. This is wrong, and a recipe for problems in the very near term.

That doesn't mean the project manager should ignore advice from others. But that person makes the final call. With responsibility, equivalent power should be available.

Well, that was my own somewhat conceited list. Most of those are management responsibility, though, and unlike some programmers, I do not believe software always dies because of management problems. Here's the list of "programmer sins" if you will:

Falling in love with your own cleverness

I think every programmer has seen either one of those:

A program with code so compact and so obscure it's impossible to figure out what it does, but the original author claims it's "really efficient;"
A program full of design patterns and deep inheritance hierarchies, but which doesn't use them (how to tell? Look for a lot of unused classes, or a lot of intermediate base classes that have only one derived class...)

I pity you, because you've found code written by a programmer in love with his own cleverness. The resulting software will usually work for the first version; the next version will probably slip badly, because it carries too much obscure code or too much extra baggage that makes it impossible for anyone to tell how to do the work.

Refusing to compromise

Clean design and clean code is incredibly important, but sometimes, you just have to grit your teeth and do something that you know is a bad compromise. This is never the case if the project hasn't slipped (and a project which was late before it even started does not qualify as a slipped project!) or for things that have an effect on persistent data (because you usually can't fix them later, at least not without import/export conversions and other nastiness). Also, it's not a good idea if the shop where you work never schedules time to clean up those things before even starting work on the next project. You'll know after a few releases. If that occurs in your shop, well, I pity you; I'd also tend to consciously let that particular release slip so you can do it properly, or later releases will slip much worse.

But face it, sometimes the company faces non-technical requirements that will force you to do something nasty. Don't refuse it. Make sure you document it well, though.

Overgeneralization

It takes a lot of practice to be able to write reusable toolkits and frameworks. And even then, they're likely not to be that general. Resist the temptation to do it until you've studied a lot and done a couple, complete with mistakes.

Beginners (myself included when I started out), especially bright ones, tend to write very general pieces of code. Coupled with a lack of experience at writing readable code, this can create a little piece of code that nobody can quite figure out. Plus, all that effort spent on generalizing the solution is likely to be wasted, since you'll find that:

People end up doing custom solutions instead because the general solution is too hard to use or too obscure;
The software ends up never needing so much generalization anyhow.

Reusable code is hard to do. It requires good taste, experience as to what level of abstraction is needed, and the ability to write extremely clear code. If you feel you lack any of this, don't write generalized code.

Copy-paste programming

This usually works well for the first release, but the second release will suffer. Bugs are duplicated by every cut-and-paste. Try to factor out common code in functions. That's what they are for.

One would think people would know that, but every piece of code I've ended up having to maintain used copy-paste in obvious ways in several places. Don't do that! Avoid it like plague! With modern refactoring tools that can extract functions from a piece of code and so on, time constraints aren't even a good excuse anymore.

Note that I've been known to do so for optimization reasons (because Java strings suck), it was always very, very well documented and I've always kept the copied code right above the pasted code. So if you really have to do it, at least make sure it's not all over the place.

Too many things at the same time

Note that this is sometimes a management pathology as well. But programmers shouldn't be too quick to point at management, as it sometimes happens because they did not communicate certain problems.

Programmers should always resist the temptation to do things in one big batch that cannot be tested in the interim. Do things in small steps. Test each of those steps to make sure every step does what you expected and has no embarrassing side effects. Fix any problems, then go to the next step.

The point of this is that by doing things one at a time, you can tell which thing you did broke what. So, try to do one thing at a time and test each one of them.

Projects sometimes fail because they run out of control. Programmers do a huge batch commit to the source tree which breaks everything at once. Huge commits are not a problem per se; however, if the whole thing was done in one shot, and if the huge commits repeat themselves, expect trouble. Things will start breaking left and right, and nobody will be able to figure out what caused it.

The last project I worked on that had that problem still exhibited severe instability until we got fed up and spent nearly a year rewriting huge parts of it. That was after nearly a year and a half of being completely b0rked, unpredictable and unable to change to accomodate features required by customers. Last I heard, there's still parts that are b0rked. As I remember, it started going unstable when people did those huge, deep-impact commits that always changed 2-3 different things at the same time.

Well, that's pretty much it. I'm not sure whether those are the "top" reasons for failure in software projects, but they're the ones I've seen the most often for projects that got in serious trouble.

A visit to IKEA

2004-12-30T22:04:00.000-05:00

This may be of no interest to anyone else, but I'm officially giving up shopping at IKEA.

Not that it's really bad, mind you. Going to the Boucherville store is much less hassle than going to the Cote de Liesse store ever was, even when I lived close to the Cote de Liesse store. Getting back on the A-20 is a bit more of a pain because of really weird traffic light timings, but I've survived to tell the tale.

And it's not because I'm annoyed by the prices, or the layout, or the crowds. Prices are reasonable; the layouts, although slightly strange at first, let you see all "sample rooms;" the crowds are very manageable at the Boucherville store. So, no problems there.

My main annoyance is how square everything looks. Square couches. Square footrests. Square chairs. Nearly cubic cushions. Square handwoven baskets, for crying out loud!¹ Sharp corners everywhere.

One of my friend's flat is mostly furnished in that style. It's a great, pure and all that kind of style. But it is not at all the kind of stuff I have. And I am not going to buy a whole new set of furniture just to fit with the rest.

I was toying with the idea of buying a set of shelves there, or maybe a new computer desk. But it's not going to happen. I'll probably grab a good desk from somewhere where the whole boxing day stock isn't gone yet instead.

So, you learned it here first: BGE has given up on IKEA as a source of furniture. There.

¹ Well, there are some round baskets, but they're huge. I'm looking for something to go on a shelf, not for an exotic clothe hamper!

Jukebox mania

2004-12-23T01:25:00.000-05:00

I am now the proud owner of a Creative Nomad Zen Xtra, thanks to being extremely lucky (perhaps undeservedly so!) So I've been messing with it a bit.

The device itself is extremely nice. The scroll wheel thingy is a bit awkward to use, especially with the case on, but I've few complaints so far. I don't know how it fares against an iPod; my last MP3 player was a CD-based koss thing that got zapped by a static charge when it was so cold outside the air in my flat was dry to the point of pain in my nose...

Storage capacity is very high; I don't think I have enough CDs to fill it! So far, Xenosaga II OST went on. USB transfer is extremely quick.

This device pretty much prompted me to finally set up USB under Linux, because I hate booting into Windows (with Windows 2000 not being supported so much, I'm always worried I'll get contaminated by some nasty worm or something; I do install system updates, but I don't run Windows all that often, so I tend to be quite a few updates behind).

Overall, it was a bit painful, but that's my fault for insisting on compiling my own kernel. Setup went like this:

apt-get install gnomad2 (lots of gnome libs get installed--maybe I should rewrite this thing in pure GTK or something...)
Run the program; complains it can't see the Nomad. Hmmm.
Install the libnjb utilities. They, too, complains.
apt-get install hotplug. Still doesn't work. Darn.
Read the USB howto. They mention the USB filesystem. Hmm, don't recall setting that option.
Download 2.6.9 kernel, since a recompile is a good excuse to update to latest kernel.
make menuconfig and realize that indeed, hadn't set the CONFIG_USB_DEVICEFS option. Set it. Also set up the hotplug support (CONFIG_HOTPLUG). Remind self that options that affect one another aren't always grouped...
Rebuild, install kernel package, reboot. Plug device in.
Start gnomad2; it finds device right away! Success!
Find out that gnomad2 has support for transferring data files as well as music. This means I won't need to boot under Windows except to update firmware. Hmm, maybe I can try to hack firmware; then again, maybe not, as a goof could really ruin the device.

That's pretty much it.

I'm a Magical Boy!

2004-12-21T02:00:00.000-05:00

It's true! Well, at least the quiz didn't put me in as a magical girl.

Still, it's rather disappointing that I get only 18 episodes. I guess they ran out of money like some other show, which may be a sign of future greatness...

You are in an anime! What happens? by meteoric
Name
Age
What the anime is about	Magical boys
Genre	Romance/Sci-Fi
Episode count	18
Your role	Major character

Quiz created with MemeGen!

About comments

2004-12-21T01:36:00.000-05:00

Note that I've disabled comments, because I'm not sure how they work on blogger.com yet.

So those wishing to comment (<sarcasm>I know I have numerous readers</sarcasm>) can do so by contacting me.

As soon as I figure where the comments go, I'll probably enable them for members of the blog. Those wishing to comment on the blog will merely need to beg.

How can I trust ActiveX?

2004-12-20T23:21:00.000-05:00

The "How can I trust Firefox" post on an MSDN blog by Peter Torr made it to Slashdot, and I expect us to know very quickly how robust the .net stuff is when subjected to the Slashdot effect. It seems to hold so far, which is pretty impressive when you think about it.

In any case, it led me to wonder why I trusted Firefox more than IE, even when browsing under Windows. Of course, under Linux, it's pretty much the browser (konqueror and mozilla nonwithstanding). But I still feel safer with it under Windows. Why is that?

Well, thinking about it a bit, I'm just really scared by ActiveX controls.

Now, binary extensions are never a good idea for something used to browse the internet. A few trusted, well-known extensions such as Flash Player may be the exception (and if it weren't for the zillion sites that use those, I wouldn't trust them either!). Also, small adapters for things such as media players that are otherwise trusted are ok to me, especially when the code for those adapters is available.

But why should I have to download a binary for a bloody Google toolbar?

Most Mozilla extensions are free of binaries and run in a scripted environment, with proper sandboxing. Some do ship binaries, and I tend to dislike those; in general, they rarely work with all varieties of libc/g++/etc. that live on my system. I compile those by hand.

Scripted environments are extremely important for such kinds of extensions. At worse, you can have semi-compiled stuff (like Java applets), but expect performance to be annoyingly bad. That's because the closer to the machine you are, the harder it is for a user application to "sandbox" your code.

Another thing that's a big no-no is the automatic download of plug-ins. By all means, put a "click here to download plug-in" window. But don't even start to download anything without the user's conscent. Not even to check the signature!

But overall, the main thing that bothers me with the ActiveX extension model is an overall feeling of treating security as an annoyance, and feature delivery as the main goal.

Examples of how this is the case (note that not all of these are IE specific, but they do illustrate an overall approach to the problem that has permeated the early history of Microsoft):

The big Word Macro fiasco. In the early days of Word Macros, I remember the company I worked for considering a way of delivering our software through Word Macros in a mostly automatic manner. The idea was to "spread the word" about the software, so to speak. The scariest part is that it worked at one point. But then, Melissa came up, and Word was hardened against macros. Well, kind of: you'd get a dialog asking you whether you really wanted to run the macros. That's a pretty useless dialog; you can't see the macros at the time you read the dialog, you don't even have their names, you don't know who wrote them, etc. As a user, how are you supposed to know what to do? So, user clicks yes, or otherwise the nice Word macros installed by the IT department won't work. Congrats, you're infected. They fixed this recently, but it took several iterations.
All the security problems related to vbs macros in Outlook. Now, if you're running a script in such a container, I'd really restrict its operations. I wouldn't allow it to create just any ActiveX control, at least not without some registry-fu done by an installation program. And I definitely wouldn't allow an incoming mail to generate outgoing mail! But those who wrote the HTML control and the Outlook stuff just gave all scripts access to all ActiveX marked "safe for scripting", which includes nearly all of them (see below). Probably so people could write automation more easily. Wouldn't it have been better to give no access and open up on an "as-needed" basis, perhaps requiring intervention of some installer to do so?
There is no GUI to unregister ActiveX controls if it misbehaves. It's possible to monkey with regsvr32 /u blah.dll, but users won't usually know where the ActiveX DLL ended up. Heck, they probably don't know what the name of the DLL is! At least Firefox extensions can be uninstalled...
The whole "safe for scripting" issue. OK, this is the silliest thing in my opinion. To make an ActiveX available to script languages, you mark it as "safe for execution" and "safe for scripting". This is done by marking it as part of two COM categories IIRC. You must, of course, sign the control. Two problems with this:

The control is made available if, in its author's opinion, it does no harmful operations regardless of the input from the script. This is a tall order. And, keep in mind, not everybody's Donald Knuth. There are probably a lot of controls in the wild that are actually not safe for scripting at all.
There is no support whatsoever given to programmers to even help them make the control safe for scripting. No way of specifying what types of operations the control should be restricted to; no way to restrict file operations to files selected by the user; no way to restrict access to internet connections. In general, no way to declare which Win32 APIs I want the control to restrict itself to run. What we get instead is a series of guidelines about how to write safe ActiveX. Thanks for nothing. If some script smashes my control's stack, that's it, it can inject any code it wants and all of it will work.

To be fair, I wouldn't be surprised if some XPCOM components in Firefox have similar issues. But in general, XPCOM components have to use XPCOM services if they are to be portable, and those are audited somewhat. I believe there's some security checks involved as well. In any case, there's a choke point for XUL/JavaScript extensions: they need to go through Mozilla to do anything at all. ActiveX go through Win32, with no restrictions, even if the developers of the ActiveX would prefer to have some. Instead of addressing this problem (say, by exposing OS services that are potentially dangerous through some COM interfaces, which could easily be overridden by the container), Microsoft has done the following:

Given us confusing dialog boxes;
Telling everybody that signed code is the key;
When scripts managed to do some nasty things (like spam the whole planet), patch stuff on a case-by-case basis.

Not a good past history, for sure. Windows XP SP2 supposedly fixes some of those problems, but a lot of sites still run Windows 2000 and others haven't managed to get existing software to work with SP2.

How can I trust ActiveX? Code signing, without a way for developers to somehow have a fighting chance at writing safe code, is not very useful. I can't write JavaScript extensions to extend IE easily, either. And the ActiveX gets downloaded automatically, if only to check its signature. The problem, kind people, is history. The Firefox people are new, and they have been pretty serious about fixing security problems. They provide a programming model that gives the extension developers a fighting chance at insuring safety of their code. ActiveX only supplies protection before execution; afterwards, all bets are off.

OK, so I haven't refuted Peter Torr's points about Firefox itself. But I wanted to point out that if you trust the Firefox binary you installed, the programming model offered to extension authors doesn't make me too nervous. There is no such guarantee with the IE extension system.

Until .NET and its Java-inspired sandbox is ubiquitous, I think the following would really help IE become a more trustworthy browser:

Disable automatic installation of ActiveX.
Allow extension of the browser through JavaScript and maybe XAML. Sounds like XUL/JavaScript? Well, that's no coincidence.
Instead of making extra services available through ActiveX controls, forcing an ActiveX lookup, only allow browsers to run well-known ActiveX (such as XMLHTTP) or controls that were installed explicitely for the browser.
Give up on the trust model to security as the sole needed answer. Sandboxing is necessary somewhere. Programmers aren't Gods; the programming model should not expect them to be.
Give people time. Microsoft history with respect to ActiveX security is so bad that some places will not buy anything with the word "ActiveX" in it (some departments of the Army, for instance; I experienced that first-hand at one point). Even if a new model becomes available, it will take time for people to realize it's more secure.
Forget about legacy support. Use the fact that you're still the dominant browser platform to force third parties to use the new programming interface. If you lose dominance, it will be the worse possible time to do this, as it will annoy ISVs and prod them to move to other browsing platforms.

Credentials: I've developed quite a few ActiveX controls in my career. One was embedded in Word (and all it did was automate Word itself and display a picture, but it was a huge pain to develop--Word is far from being an ideal container). Another was embedded in IE and allowed one to sign an HTML form. The Word control didn't scare me too much because it couldn't be installed automatically and it only reacted to user events; it had no programmatic interface. The IE control needed a programmatic interface because it needed to be called through JavaScript, because HTML forms aren't as rich as Word documents. I remember being scared a lot writing the IE control, knowing that my control was marked as safe, signed, everything cool, but that I had no way to verify that it was safe. I ended up making the interface the very minimum needed so the control would remain useable. But it would have been much better to write this in script, if possible.

Canadian Weather

2004-12-20T22:35:00.000-05:00

It was bloody cold today. To the point I thought my cheeks would freeze completely at one point. Not a nice feeling.

Which brings me to a rather funny observation about Montrealers. We'll brave deadly cold just to make sure we get a seat in the bus, for a 15-minute bus ride. Even funnier, I'm one of the ones who did it, and I didn't even realize it until I was in the line. By then, well, I was there, and I decided to tough it out.

One would think it's a macho thing, but the three people in front of me in the said line (and, needless to say, who had been there much longer than I) were women. Are stupid male habits rubbing off? I hope not...

In any case, that was not very smart, but my toes are still moving and my fingers haven't fallen off. Plus, I had that really warm polar cap. I sometimes think that winter is a humility test: you must be willing to wear a silly hat, or your ears freeze. So, you're either humble or you suffer.

Still, tomorrow, if it's that cold again, I'm staying in station and I'll stand in the darn bus.

Apparently, there's going to be rain (not ice rain, liquid rain) this Thursday. There go my plans for cross-country skiing coming Christmas weekend. I knew I should have gone last weekend, instead of messing around in the west of the island looking for decent Christmas gifts (in my defense, I found a really nice one, but had to drive way west to get it). Montreal weather is completely whacked. If you want to move here, be prepared.

Then again, we don't bitch about much more than climate, so I guess it's a pretty decent place to live. I'll take weird temperature swings over earthquakes, tornadoes or civil unrest any day.

Well, that was pointless, but, hey, it's my blog after all.

About the picture

2004-12-19T20:41:00.000-05:00

I know somebody's going to ask about this, so I'll just say it up front.

Everybody who saw the picture failed to notice my dashing figure. They just ask, "Who is the man on the picture on the wall? Actually, why is there a picture of a man on your wall?"

Fear not, I haven't been hiding in the closet or anything. Unfortunately, the actual answer is somewhat convoluted and, at the same time, boring. I know some people won't believe it, but it's the harsh truth.

When I started off at Logient, there was a lack of space, so I ended up in the corner cubicle¹. A rather lousy place for somebody whose main job was technical lead. One guy left, leaving me the adjacent cubicle. That was already better. However, when I moved, somebody pointed out that Guy, the guy who's picture was on my cubicle wall when we took the orange hat picture (still following all that?) had held a similar position to mine, and had his picture on my former cubicle's wall. So, lacking a picture of my own, some prankster pinned it to my wall.

OK. Fast forward a few months. Some events free up space in the office. So I get to move closer to the windows, and I jump at the chance, as my eyes get bad quickly when I can't look outside. This is the cubicle I have on the orange hat picture.

Nothing much is planned where I work when it comes to office set-up and such, so I just take all my stuff and put it on the new wall. This included a rather large database schema I needed at the time. This also included the picture, as someone reminded me to bring it while I was moving stuff. So, without further thought on the matter, I just pinned it there to shut people up and moved on to more important things, such as my wonderful Fujitsu 4726 keyboard.

Fast forward a few months again. The window seat is great, but there are no real blinds, only some sort of semi-transparent thingys. When the sun is setting, I get it smack in my face². So I put on my sunglasses, which help a bit. That made people laugh, so I put on the hat, and the earphones³ on top. The picture is so strange (I look like some weird American jet fighter pilot or something) that co-workers rush to get the digital camera.

So, to summarize:

The guy in the picture is Guy, a former Logient employee. I met him once, and that's it.
His picture is on my wall because it was on my cubicle wall before and somebody complained he'd feel "left alone", so I humoured that somebody.
I really look silly with an orange hat.

I'm not in the habit of discussing anything about work, but, well, this had to be explained.

I hope this clears up any misunderstanding. Thank you.

¹ We don't really have cubbies at Logient, it's a big open area, somewhat loft-like. But there are a few partitions. They don't cut out the noise, so everyone hears me swear all the time, but that's why we have earphones. The partitions are to hang things on, because many walls are naked red brick, which don't appreciate thumbtacks too much.

² I guess I shouldn't complain--it's one of the nicer spots. Or so I've been reminded many times by co-workers when I complain about the sun in my face.

³ The big earphones are supposed to get people to understand that I'm coding, dammit, and that I don't want to be annoyed. It worked for about two hours. Maybe I should start wearing torn jeans and spike bracelets.

First post!

2004-12-19T02:15:00.000-05:00

Well, I'm quickly messing with the blog (from Blogger.com for the moment, I'll probably whip up something myself someday).

For the moment, though, this works. Had a lot of fun making the template match my own site; pretty much had to destroy the existing stuff and rearrange the whole template. Had to figure out a lot of stuff in a hurry. Will have to read documentation on their HTML template format. But for now, it works well.

I've got to go to sleep now... (look at the publishing date below; should give you a pretty good idea why...)