I love my job. One of my ideas got the green light a month or so back and I’ve been building it (while juggling other projects) ever since.

It wasn’t a unique idea, but it was one that would compliment our other image-related ad services: Web Thumbnails. Essentially, create a small thumbnail of a rendered website and use that as a visual representation of a link before someone clicks on it.

Something like this:

Ars Technica: The PC enthusiast’s resource Ars Technica. Power users and the tools they love, without computing religion. Oh yeah … Ars Technica review: The Sims 2. Posted September … arstechnica.com/ – 63k – Cached – Similar pages

(Web result borrowed from Google)

Creating the actual thumbnail is not that impressive of a feat. There are dozens of ways of doing that. The real trick, in my book, is creating an automated method of doing so. No technology is worthwhile, in my opinion, of it doesn’t make some task easier.

With the help of Mozilla and Gtk2::MozEmbed, I build Thumbzilla (okay, the name is cliche and taken, but for an internal project, it works). I almost immediately ran into a pickle of a problem: Javascript. Some of the sites I was attempting to thumbnail did not want to play very well with an automated process. When I logged in to check Thumbzilla’s progress I was greeted with a slew popups, alerts, and confirmation dialogs. Nasty stuff.

Obviously, anything requiring manual intervention is a wrench in the cogworks of my project so I did a little digging. I ultimately found this:

Suppose you’re annoyed by pop-up advertisements and want to prevent all
web pages from opening new browser windows. You can do this by adding the
following line to your Mozilla user preferences file (user.js):

user_pref("capability.policy.default.Window.open", "noAccess");

Throw in a little:

user_pref("capability.policy.default.Window.prompt", "noAccess");
user_pref("capability.policy.default.Window.alert", "noAccess");
user_pref("capability.policy.default.Window.confirm", "noAccess");

and my system is now chugging along quite nicely, with some of the annoyances of Javascript disabled. It will be several weeks minimum before Thumbzilla is publicly unveiled, during which time it will get tested, poked and prodded by various people. Still, I have to say I’m quite proud of how it turned out. I think this kind of visualization could be a useful part of searching the web. Let’s just hope I’m not the only one who thinks so.

D-BUS is a message bus system, a simple way for applications to talk to one another.

I was looking for a better way of doing inter-process communication (IPC) and I stopped to take a look at D-BUS. After playing with it for a few days and seeing it in action via beagle, I decided it was worth using.

I’ve started work on xchat-dbus, and X-Chat plugin to expose plugin functionality via D-BUS. The advantage to this is that other applications could interface with X-Chat without having to use a plugin and then find a way to communicate with that.

This started out as an idea to create a simple applet that would provide alerts via the notification area. I found one such applet, but it was overly complicated and didn’t work well. I started to write an X-Chat plugin to do it, but then I realized how much easier (and ultimately more useful) a D-BUS plugin would be. Plus, this will let me dig deeper into D-BUS and hopefully I’ll get a better grasp on it’s internals.

I just spent the better part of a week tracking down bugs in Mono and a custom application of mine (which I’m porting to Mono). I was having a rough time with some code working against a secure server. After reading this, this, and this, it finally works.

Bottom line: If you’re working with HttpWebRequest and trying to connect via SSL, you need to make sure that you tell System.Net to trust all certificates, especially if you’re developing a non-interactive daemon. There’s nothing more frustrating then spending hour upon hour tracking down why your code won’t work like it did under .NET, only to find out a few lines of code fixes it straightaway.

I started playing with ipod support in Rhythmbox a while back. I mocked up a little bit of the GUI, but then I made the mistake of looking at the libraries that interfaced with the ipod. There have been some efforts at getting ipod support under Linux, most notably gtkpod. There are a handful of various efforts at making GUI to interface with the ipod, but I found very little effort going into making a stand-alone library to access it.

Following the Open Source tradition, I decided to write my own library to interface with the ipod. I did this with sound reasoning. First, the existing projects that I did find all seemed to be trying to do their own thing (nothing wrong with that), each implementing their own version to accomplish a similar task. While there’s nothing necessarily wrong with that, it feels more `right` to me to create a more generic, independant shared library to interface with the ipod (and specifically, iTunesDB, which is the heart and soul of the ipod). With a shared library, I can integrate ipod support into any number of applications (xmms, Rhythmbox, gnome-vfs, etc) without having to worry about rewriting the same code over and over again, which gtkpod and others seem to be doing.

I talked to a few developers involved in other ipod-related efforts and met some resistance to my idea. Again, the efforts I witnessed seemed to focus on building application-specific support. On that vein, I took a look at my own motivations compared with that of other developers that I know and I came across some interesting bits of information.

Reading through a presentation [3.4M] given by Nat Friedman at GUADEC recently, I found and have shamelessly ripped out the pyramid of usability.

I place myself somewhere between core hacker and geek. I’m more than happy to hack away at code but I don’t find as much satisfaction in something that only I can use. I guess I prefer to look at things from an end-user perspective. They don’t care how complicated it is to write code or what effort went into it. They just want it to work. At least I’m not alone in this.

I know where I stand, but what about the community at large? Jorge pointed me to this study on the motivation and effort in Open Source software projects, conducted with a pool of 684 developers across 287 sourceforge.net-hosted projects. They concluded with some interesting results.

44.9% write code because it’s intellectually stimulating.
41.8% write code to improve their skills
33.8% write code because it is needed for work-related projects
29.7% write code for non-work-related projects
11.3% write code to spite closed-source projects
11.0% write code to enhance their reputation in the Open Source community

I can relate to these motivations but I can’t help feeling that something is missing. I don’t expect the code I write to save the world but I would like it to contribute to making Linux more usable to the end user. If I sync my ipod with Linux, it should work the same no matter what frontend I use. I should even be able to sync between whatever application I use in Linux and iTunes on Windows or OSX. It shouldn’t matter what application I use on which platform. It should just work.

So that’s my goal with libipod in a nutshell, as lofty as it may be. It should provide a seamless interface between any application using it and iTunesDB and allow the ipod to work with iTunes or any other compatible software.