Get off my lawn.

Thursday, September 18, 2008

Mistaken Identity

I got a "thanks for your order"-type message from the publisher of some kind of engineering magazine the other day, thanking me for signing up for a subscription. It came to an e-mail account that I don't use very often.

Apparently, someone mis-typed their e-mail address when signing up for a subscription to this magazine, specifying my address instead of their own. The message didn't appear to be spam, and I took no action in response to it.

It's been kind of interesting to see the kinds of e-mails I'm getting on that account since then. Apparently, the person who signed up for the engineering magazine subscription is also a trucker, and is being asked to participate in a lot of surveys for the "American Trucker's perspective" on various issues. This person also does some woodworking, and apparently lives in the SF Bay area. And, his subscription to "Out Magazine" is about to run out.

So if you are reading this and you know any "alternate lifestyle" truck-driving engineers who do woodworking for a hobby and are complaining that their issues of engineering and lifestyle magazines haven't been showing up at their home in the SF Bay area, I may have an idea about that.

Thursday, September 11, 2008

Dirty little secret

I've been a fan of Steve Yegge's blog for awhile now.

A new post from Steve Yegge is like getting a huge erector set for Christmas. It's going to be useful and pleasant, and it's going to take time. The guy's blog posts are long.

Whenever one arrives, I think "okay, I'll set aside some time to read this", because although they're long, they're usually pretty funny, and they make a good point.

So this latest post arrived, with a provocative title: "Programming's Dirtiest Little Secret". Given what I've read from him in the past, I thought it was going to be something nice and deep, like the fact that most bad programmers are socially liberal yet fiscally conservative, or some kind of tie-in between good programming skills and an awareness of a higher power.

But, no. It was about the fact that some people can't type. You know, press keys on a keyboard and make letters and such appear on the screen. I didn't see that coming.

Typing is such a fundamental skill for someone in the tech industry that I haven't even thought about the necessity of having that ability for someone in my line of work. But it's true, now that I think of it. There are plenty of people who can't do it very well. What a joke that is. I don't care how good a programmer/designer/architect you are, showing up to the computer party without typing skills is like a race-car driver waxing all poetic about the "racing line", the "limit of adhesion", "taking them on the outside", etc., and then mentioning "oh, by the way, I don't know how to drive a stick."

As a developer/designer/architect, you're in the business of making a computer do your bidding. I don't know how you could expect to do that effectively at all if you haven't yet discovered an efficient means of talking to the computer to start with. I'm going to make a point of asking about typing skills the next time I interview someone for a programming job.

I see that you have Spring WebFlow, Axis, XFire, Ajax, Flex, and SWT experience. You've impressed me with your opinions about what makes a good architecture. Your thoughts on thread safety, resource contention, and race conditions appear to be well thought-out. So... Can you type?

The reaction should be interesting.

Also, the aforementioned blog post gave me some insight into why Steve Yegge's posts are so long and verbose. The guy can type 120wpm.

Tuesday, September 09, 2008

A post from e-mail: Test

Hello, this is a test of posting to a blog from e-mail.

Thursday, September 04, 2008

OSGi Bundle Deployer

I wrote a little tool for development with OSGi (specifically Equinox), which I've been playing a lot with lately. I thought I would post it here in case anyone found it useful. It's similar to the File Install bundle available for Apache Felix (as a commenter on this post pointed out).

The tool in question here is an OSGi bundle that manages the installation, update and un-installation of other OSGi bundles. It bears the unimaginative name of "bundle deployer".

Essentially, its job is to monitor one or more directories on the file system and install, update, or uninstall bundles being manipulated there.

Once you've configured and started it, you can install a bundle in the OSGi environment just by copying it to a monitored directory. To update an installed bundle, update the corresponding file. To uninstall it, delete the corresponding file.

I find this useful, since I've been spending a considerable amount of time updating bundles on a remote machine I'm testing on. I can just scp all of the bundle files I'm dealing with onto a specific directory on the remote machine, and they get loaded and updated automatically.

Here is the "user manual":

First: download the bundle from here:

You can get the source from here:

Second: In your OSGi console, set a property:

osgi>setprop bundle.deployer.dir.names=/home/fred/my_bundles:/home/fred/my_other_bundles

The format of the property value is just like your OS's PATH statement. The example shown here is for Linux, with a ":" between directory names. On Windows, the path-separator character is ";", e.g:


You can also specify this property in your OSGi environment's config.ini file. If you use this bundle on Linux, you can create a config file at /etc/bundle-deployer.conf with the property in it. In this case, the bundle deployer will use property values specified there, but actual system properties you specify will take precedence.

Note: The "\" character is an escape in a properties file. So if you specify a Windows path with backslashes in a properties file or in config.ini (which is also a properties file), be sure to use two backslashes (\\) for the path separators. Better yet, just use forward slashes (e.g. c:/my_bundles). This works fine on the Windows platform too. Cmd.exe is the only component of Windows that doesn't know what to do with "/" path separators.

Once you've set this property, install and start the bundle deployer:

osgi>install file:/home/path/to/download/bundle_deployer_1.0.0.jar
Bundle id is (something)
osgi>start (something)

When the bundle deployer starts, it will scan the directories you specified, and install all of the bundles found there. After installing all of them, it starts them all. If a bundle is already installed, installing it again has no effect.

That's basically all there is to using it.

I typically configure Equinox to use this bundle in the conventional way (specifying it in the config.ini file), so that when I stop/restart Equinox, it loads this bundle (along with others that are already in use). When the bundle deployer starts, it loads the bundles I'm working on. This approach would most likely work in a production environment, but that's not the point. I think you'd want to use the recommended approach for your OSGi environment for loading a production set of bundles.

One last thing: This has only been tested with the Equinox environment, and not on Knopflerfish or Apache Felix.


Update Exceptions: It's possible for an update operation to result in an exception in the OSGi environment where it complains about "X.jar is not a valid zip file". What's happening here is that my directory scanner notices that the file's modification time has updated and signals an "update" event to its listener, without bothering to make sure the file isn't still being updated before it fires the event. This wouldn't be hard to fix, and I'll post an update once I fix it. In the meantime, just update the file again if you get this error message.

If you see this happening frequently, you can reduce the likelihood of it happening by adjusting the bundle.deployer.sleep.interval property to a higher value. This property controls how long the bundle deployer waits between checks for updates in the monitored directories. It's specified in milliseconds. So:

osgi>setprop bundle.deployer.sleep.interval=10000

...results in a directory scan every 10 seconds (instead of the default of 2 seconds).

You can set the bundle.deployer.sleep.interval property in any of the places mentioned above (console, /etc/bundle-deployer.conf, config.ini).

The tree-chopping-itself-down bug: The bundle deployer does not exclude its own jar file from installation or update (or delete) operations. If you do something weird like putting the bundle deployer's jar file in a directory that it's monitoring, it will have no effect. If the bundle deployer isn't started already, simply copying the file into a directory won't do anything. If it is already running, it will attempt to install itself, but since it's already installed, the install operation will have no effect.

However, if you delete the bundle deployer's jar file from a directory it's monitoring, it will uninstall itself. OSGi's APIs are smart enough to prevent this from being the black-hole-inducing disaster it sounds like it would be, so I don't think there would be any serious effect. I frankly haven't tested that. This isn't really how the bundle deployer is meant to be used.

System Properties: While it's running, the bundle deployer doesn't notice changes you might make to system properties and update its configuration. You have to restart it via an update operation at the console. Not really a "bug", but something to bear in mind.

So there it is. I hope you find it useful.

The more I work with OSGi, the more I appreciate it as a server environment. It incorporates internal pub/sub messaging, dynamic load/unload of modules, the ability to monitor changes within the environment itself, and a host of other things, not to mention a legitimate component model for Java.

The next thing I plan to do is get a SQLite embedded database running on it. That should be handy.

Tuesday, September 02, 2008


(No, not the shiny metal that comes on aftermarket Harley parts, or the idiotic Trace Adkins song that makes me want to stab myself in the ears with an icepick.)

I'm also not referring to the "chrome" that lurks in the belly of the Firefox web browser. 

"Chrome" is Google's new browser that they apparently developed either in total secret, or cranked out overnight between Labor Day and today. 

I'm using it right now, on Windows. I haven't formed an educated opinion about it yet, but I'm not letting that stop me from posting something about it for the whole world to read. 

Here's what I know in the 2 minutes I've used it:

First of all, it's fast. Firefox 3 was a noticeable improvement in browser speed over Firefox 2, which itself is many times faster (and better) than Internet Explorer. This is a big improvement over Firefox 3, even on this Windows box I'm using, which typically feels a little bit sluggish.

Chrome runs each tab in a separate process. Right now, I have one Chrome browser running with 4 tabs open, and there's a separate chrome.exe process running for each tab. There's a couple of other ones too, and I figure they're probably just there because it's a Windows tradition to run extra stuff for the purpose of junking things up a bit. (Nice job, Google.) Google chose to run each tab in its own process to help prevent memory fragmentation, which results in eventual memory bloat when the browser has been running a long time. 

Most of the shortcut keys I'm familiar with in Firefox seem to work here. Except F11 for full-screen. In any case, the familiarity is a good thing, because there's no menu at the top of the Chrome window. I have no idea how I'm going to get into the preferences window and screw around with Chrome's settings.

No, wait... scratch that. There's no menu, but there is a little picture of a wrench, which gets you to a bunch of settings. There's also a picture of a document, which for some reason is the entry point for a plethora of other things. These include a JavaScript console, a debugger, and a task manager so you can kill tabs that are running wild on your system.

Google has published a whole document about the design of Chrome, with hand-drawn appearances by some of the industry's leading minds in browser design. Pretty informative, and it also reminds me of those Gospel tracts that Chick Publications has been putting out for 40 years.

Chrome features the ability to open an "incognito window" for anonymous web surfing. It deletes all cookies after an incognito session, and doesn't remember anything about what you've been doing (unless you download a file or something). This is analogous to a feature Microsoft is calling "Porn Mode" in its upcoming browser, IE8. Firefox doesn't have that feature, that I know of.

So far, I'm impressed. It seems to be a pretty cool browser, for people who get excited about that kind of thing.