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

Shuffling the stack: first faltering steps on Factor

In my neverending quest of avoiding actually getting any of my projects ready, I started playing with Factor. In four years, Slava Pestov and the other folks hacking on Factor have created an extremely impressive language, beating many other dynamic languages like Python and Ruby in speed and providing an environment that doesn't make the Factor 2.0 goal "Best interactive development environment of any programming language" sound like an impossible idea.

But it does have a steep learning curve. The concepts of the language aren't difficult — in many ways it resembles other dynamic languages — but it feels like I'm clumsily trying to perform mental gymnastics instead of actually being productive. See, it's a Forth-style stack shuffling concatenative programming language. There are named variables (dynamically scoped, which feels weird, but that does have its uses when used sparingly) and these days there are even lexically scoped named locals, but depending on those instead of getting used to stack manipulation would be cheating, no? So now I'm slowly dupping, overing, tucking and swapping my way through simple algorithms, trying to switch my head into the right gear.

Article page

This is how all software should be

 $sudo -u couchdb /opt/couchdb/bin/couchdb 
 couch 0.7.0a572 (LogLevel=info)
 CouchDB is starting.
 CouchDB has started. Time to relax.

It's a bit like having a dictionary with the words "Don't panic" printed on the cover in big, friendly letters.

Article page

Resin: Javascript in JSPs?

Am I missing something here? JSP Templates vs.

/test.jsp:1: 'javascript' is not supported as a JSP scripting language.

1:  <%@ page language="javascript" %>

That's what Resin 3.1.2 tells me.

Update: Right, now I noticed this in Resin 3.0.0 release notes:

Since the JavaScript for JSP was used by too few users, it no longer makes sense to continue support.

Arf.

Apparently Tomcat, Jetty and Glassfish all support only Java in JSPs, not any javax.script implementations. Now I'm trying to figure out how to use EJS from scripting.dev.java.net. Any other Javascript templating options for servlets? I know Helma, but I'm interested in the front-end code (templates, value objects, possibly controllers) only.

Article page

Cirque du Soleil's Delirium: meh

We went to see Cirque du Soleil's show Delirium, now in Helsinki on their tour of Europe, yesterday. It was the first time I've seen any of their shows live. It wasn't exactly bad, but not what I was hoping for. The most important part seemed to be the music and the video stuff, and the acrobatics were a bit of an extra. Trouble is, the acrobatics were what we went there to see.

The music was an A-Z of genres with no carrying theme, going from rock with guitar heroics to Africa flavoured world fusion to soul to pop to salsa to tango. And few of the songs were all that great, either, basically sounding like filler tracks on a pretty ok album. A different album in each case, of course.

The video show was amazing, mostly computer generated and in all cases heavily processed, with two big screens on each side of the stage, one behind it and a translucent one part of the time in front of it.

And occasionally somewhere there were a few acrobats. They were mostly extremely impressive, too. At least when you could see and concentrate on them. Too often, though, even if they were there, there was the huge A/V show going on all around them, drowning them with its volume, both in terms of sound and screen area. And as if that wasn't enough, sometimes they had the translucent screen in front of the stage showing water or something, forcing you to squint to see the people who you thought were supposed to be the most important part of the whole experience.

According to the official web site, "For the first time Cirque du Soleil created a show where melodies, musicians and singers are the driving force". I guess I'll just have to keep that it mind when deciding which show to go see next time.

Article page