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.

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.

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.

© Juri Pakaste 2023