JUGC 0.2 with Python support

I just released version 0.2 (and 0.2.1, now with a NEWS file!) of JUGC, the unit conversion library generator. It allows you to specify a set of measuring units and translations in XML files and generate a conversion library from them, thus avoiding parsing a definition file at startup. The generator portion is still written in Java, but now in addition to Java, it can also generate Python code. There are small examples on the Examples wiki page. There isn't much documentation, but the example data files and tests should be clear enough.

Article page

pgrok

I put up pgrok ("Project Grokking for Emacs"), a simple Elisp package for project settings and tools, on Launchpad. It's a tidied up version of a couple of things I've been using for ages, basically for loading project (a source tree) settings, functions or whatever you need from files that are looked up in your directory hierarchy. There are also two (at the moment) functions for locating stuff in your project with find and grep.

There are no releases yet, but it's just one file in the bzr branch hosted on Launchpad. I use GNU Emacs 23.0.60, no guarantees about any other Emacsen.

Article page

Software Engineering Radio

They keep on asking their listeners to plug them, so here goes. I've been listening to podcasts quite a bit lately, as I got a phone that can do them and my commute is too short to really concentrate on reading articles, and the best of the ones I regularly follow is Software Engineering Radio. There's a lot of backlog to go through and at least the interviews they've done with Joe Armstrong, Galen Hunt and Dave "not PragDave" Thomas have been really nice.

Article page

AudioFormat 0.6

Waking the project up, at least momentarily, from a nine-month slumber, I released version 0.6 of AudioFormat, the friendly audio file format converter for the GNOME desktop.

I've again found more use for the software and discovered that it was in several ways still embarassingly broken, from refusing to install on Python versions with micro version numbers (like 2.5.1) to still continuing conversions after clicking cancel, even without the window, when using as a Nautilus extension.

It should be at least a bit better now.

Article page

Dependency injection: I'm not going back

InfoQ carried an article about dependency injection, with the title "Does Dependency Injection pay off?".

Answer: it does.

You learn something useful from most languages, frameworks and libraries you get to know. One of the more surprising revelations the Java world had for me, after working in it for the best part of a decade, came in the form of Spring. It's a huge pile of stuff, but in the center sits a pretty good idea. It's not an original idea, but Spring is where I got to know it. It's dependency injection. It's about classes not instantiating their dependencies or looking them up from some sort of global scope, but exposing them as constructor arguments or properties.

In Spring, you define the dependencies in an XML file and let the framework set things up. It works well enough, but I've been merrily using the same design in non-Java environments ever since getting to know it without any of that angle bracket noise and haven't really missed it; you get by just as well with a piece of code that creates all the objects, hooks them up and presses play.

Everything is so much cleaner and simpler than it used to be and as an extra bonus, it's suddenly a lot easier to test, too. The cleanliness DI brings to your design has the quality of being self-supporting: once you start building the system with it, the path of least resistance is to keep on using it instead of letting the dependencies spread. It also makes using singleton a lot less tempting (it's easier to just instantiate an ordinary class and give that instance everywhere it's needed), which is another big plus.

Someone in the InfoQ article invokes YAGNI. It's a false argument. You have to set up the dependencies anyway somewhere. You are going to need that. So the question is, should you do it in one place or scattered throughout the system? Which is cleaner? Another question you can ask is the old OO design principle, whose responsibility is it anyway? With the benefits DI brings, it's an easy decision to make.

Article page

Using SSH from the Gnome menus

Some time ago I wrote in a SSHMenu related blog posting's comment thread that I found the Gnome panel's menu combined with gnome-terminal's profiles feature sufficient for my SSH needs. As a followup, I got a email a couple of days ago by someone asking if I knew how to do the same thing except opening Nautilus windows for the remote hosts. I replied, but apparently the email could never be delivered, so here's a quick recap.

Below, I'll use foo as the remote host name. Replace it with the name of whatever host you want to use.

Steps:

  • Open the menu editor, either by right-clicking on the menu or from System > Preferences > Main Menu.
  • Click on New menu to create a new submenu, call it "Remote hosts" or something.
  • Select the new menu, click on New Item to create a new menu item.

For terminals:

  • In the Launcher Properties window that opened after clicking New Item, set the launcher type to Application, give it a descriptive name like "ssh foo" and the following command: gnome-terminal --window-with-profile="Remote foo". You can also give the launcher an icon. I usually like to give an icon that I use also for the gnome-terminal profile. See below.
  • The launcher won't do much useful yet, beyond opening up a new terminal, so now you have to create the gnome-terminal profile "Remote foo".
  • Open up a gnome-terminal window.
  • If you value your screen real estate, you probably have hidden the terminal menu bar. You have to make it visible to access the new profile creation functionality, so bring up the context menu with the right mouse button and select Show Menubar.
  • In the gnome-terminal menu, select Edit > Profiles. Click on New to create a new profile and give it the name "Remote foo". Click Create.
  • In the General tab, you can give the profile an icon. As I said, I like to use an icon here and in the menu, but that's up to you. You can also specify host specific colors in the Colors tab.
  • In the Title and Command tab, check "Run a custom command instead of my shell", and specify ssh foo as the custom command.

Now you are set, and selecting ssh foo in your new Remote hosts should open up a new terminal window that prompts you for authentication information for foo.

Turns out using this for Nautilus is even less work. Assuming things work out.

  • In the Launcher Properties window, instead of specifying gnome-terminal as the command, type in nautilus ssh://login@foo .

Replace login with your login on foo.

That's it. No extra steps needed.

Now, if gnome-vfs does its magic, you'll get a new Nautilus window when you select your new menu entry, showing the contents of your home folder on foo. The other option is that you get a Nautilus window showing nothing, which seems to happen to me for some hosts. No idea what that's all about.

Article page