Say I have an object that likes to transition solely between happy states every time a certain event occurs. Here’s how I might handle it:

 theObject.happy = !theObject.happy;

There. Simple huh? Something you probably learn how to do in an introductory programming course. It might be surprising to you, but someone asked a question on how to do this on Stack Overflow. The other alternative provided in the answer is the somewhat more cerebral:

theObject.happy ^= true;

Thanks Spock. Of course if your language doesn’t have an assigning XOR operator this option is ruled out. If you value clarity of code, or you simply don’t want less brainy maintainers pestering you about what your code is doing, you rule this option out as well.

So I’ve been writing a lot of code recently of the first form, and it’s been making me sad. There’s a strong feeling of non object oriented-ness about it. I mean, to toggle the state of an object I have to:

1. ask it what its current state is;
2. flip that state locally;
3. and then tell the object to take on this new state.

Bleh! Why the hell should I care what state it currently is in? I just want to toggle it! Shouldn’t I just be able to ask the object to toggle it’s own state; perhaps of even multiple properties in a batch sequence?

Naturally, nobody wants to write a toggling method for every writable boolean property of their objects. So either there needs to be automatic support in the platform or some ability to provide a general toggling abstraction.

One such example of a crude toggling abstraction would be a Ruby module defined like the following.

module Toggler
 
  class ToggleHelper
 
    def initialize(target)
      @target = target
    end
 
    def method_missing(sym)
      @target.toggle(sym)
    end
 
    def toggle; end
 
  end
 
  def toggle(*sym)
    return ToggleHelper.new(self) if sym.empty?
 
    self.send("#{sym}=", !self.send(sym))
  end
 
end

Such a module could be mixed-in at the appropriate levels of an inheritance hierarchy, or maybe even at the root level if you’re game.

With the mix-in mixed-in, toggling code would be more concise and less repetitious:

the_object.toggle.happy
the_object.toggle(:happy)
the_object.toggle(:wanted, :happy, :virtuous)

Doesn’t a declarative syntax such as this feel much more happy?

Please note—The following story is not meant to imply that the residents of Chernobyl were:

• tax evaders; or
• incompetent home builders; or
• mean spirited; or
• comparable to swine; or
• given to formulaic naming of their children.

Any resemblance to any person, living or dead, is purely (and tragically) coincidental.

The Three Little Taxpayers

by C. D. Owen. (Age 10)

Once upon a time, there were three little taxpayers and they lived in a Russian town called Chernobyl. Two lived in the outskirts of the town and they had made their homes of poor building material. One whose name was Yuri had made his house of straw. The other, whose name was Yori, had made his house of sticks and branches. Everyone in the town made fun of the them. The other taxpayer lived in the upper-crust of the city and he was very well-off. His name was Yari and he lived in a magnificent sky-scraper and he made fun of Yuri and Yari as well.

One day, the big bad tax-collector came along and his name was Yiri. He came to Yuri’s house and knocked on the woven door.

“Little tax-payer, little tax-payer, let me in!”
“Not by the vinyl of my skinny wallet!”
“Then I’ll have to demolish your house!”

So the big bad tax-collector went away and then came back with a bull-dozer. He then knocked over Yuri’s residence. He then went and on and came to Yori’s house of sticks.

“Little money bag, little money bag, let me in!”
“Not by the leatherette of my medium filled wallet!” came the reply.
“Then I’ll have to demolish your house!”

And again he went away and this time brought back a demolishing ball. He then knocked down Yori’s house. Then he continued along collecting debts. He then came to the sky-scraper belonging to Yari.

“Little dollar-sign, little dollar-sign, let me in!”
And Yari replied, “Not by the one hundred percent leather of my fat wallet!”

And so away went the big, bad tax-collector yet another time. He then came back with a demolishing squad but they couldn’t destroy the sky-scraper because they didn’t have a permit to destroy large buildings.

As you have probably known, the big bad tax-collector was very greedy and he just had to have Yari’s wallet. So the big bad tax collector went to the Chernobyl nuclear power plant and he shut off the reactor’s cooling systems and then the power plant blew up causing Yari’s building to glow and melt.

The next day the big bad tax-collector came back in his protective clothing and he searched the rubble for Yari’s wallet, which he never found but he was glad he gained his revenge.

The moral to this story is: pay your debts or you’ll be sorry!

Today Yahuda Katz posted his 10 favourite things about the ruby language. His list certainly reflects most of the things I find very appealing about the language. The sixth item highlights Ruby’s excellent support for blocks and lambdas and an argument is mounted that when performing file operations in languages without them, programmers are forced to use an inline “ensure” block every in the same lexical scope that they originally opened the file in, to ensure that the resource is closed. As is often the case the comparison is made to Java, but as any seasoned Java developer will tell you (and this point has probably be made many, many times) it just isn’t true. Java supports a safer and comparable idiom via the anonymous inner class.

The example given is a very succinct Ruby method to print out the lines of a text file. Ruby’s File.open ensures the file is properly closed after the block has completed, normally or otherwise:

def run(input)
  File.open(input, "r") do |f|
    f.each_line {|line| puts line }
  end
end

The Java version listed does the same but, predictably, is far more verbose and laborious:

static void run(String in) 
throws FileNotFoundException {
  File input = new File(in);
  String line; Scanner reader = null;
  try {
    reader = new Scanner(input);
    while(reader.hasNextLine()) {
      System.out.println(reader.nextLine());
    }
  } finally { reader.close(); }
}

However no Java developer that values their sanity is ever going to sprinkle this pattern through their code base any time they want to use a File and ensure that it is closed properly. Here’s what they are going to use instead:

public interface Processor<T> {
  void process(T target);
}

import java.io.*;
import java.util.Scanner;
 
public class FileSlurper {
 
  public static void slurp(String fileName, Processor<Scanner> processor) 
    throws FileNotFoundException {
 
    File input = new File(fileName);
    Scanner reader = null;
    try {
      reader = new Scanner(input);
      processor.process(reader);
    }
    finally {
      reader.close();
    }
  }
 
}

Once that infrastructure is in place, the Java implementation of the example becomes:

FileSlurper.slurp(input, new Processor<Scanner>() {
  public void process(Scanner reader) {
    while(reader.hasNextLine())
      System.out.println(reader.nextLine());
  }
});

No one can argue that this is as pretty or convenient as the Ruby version, but it does ensure that file opening and closing is handled correctly without any effort from the client code. The code in the anonymous inner class can even access variables in the current lexical context, as with the Ruby block, with the caveat that they must be declared final (not quite a lexical closure!). This pattern, in conjunction with the Processor interface may be used any time there is a need for similar resource acquisition and clean–up procedures, as might be the case for locks or database connections.

Lambdas and blocks are very useful constructs, and the anonymous inner class can act as an acceptable, if far from ideal, analogue. What an anonymous inner class can’t do is act as a co–routine; this is a truly powerful feature of Ruby’s blocks and associated method invocation features that Java can’t directly compete with.

One thing’s for certain: the Ruby community won’t win over Java developers by giving examples of deficiencies where none exist.

If I could choose, if I truly had free will,
I’d run, I’d break out, I’d be unbonded, free.
but while I’m here in this state, a listless nowhere,
I can’t, I won’t, I’ll never be.

and even now, when I feel almost alive, I’ll falter
search for words that won’t come, that will never say what I want to say
I’ll think that at the very least, I’ve created something
but for what purpose? In the end, I’ll hate them, hate it, loathe it all the same.

And the sleep still won’t come, but maybe I always am.

An existing shell that aims to provide a better interactive experience is the Friendly Interactive SHell — Fish. I’ve recently started to spend some time with this shell although there is a problem with it: my collection of Bash functions that I’ve accumulated over the years in .bashrc are rendered impotent in this environment. Sure, I could spend some time and redefine them all in Fish’s shellscript dialect; or I could just abandon trying something new in the name of efficiency and laziness and head back to Bash. That does seem sad, and fortunately there is a way to bridge the gap.

For other souls in a similar situation to me, here’s some script you can pop in your ~/.config/fish/config.fish (Fish’s equivalent to .bashrc)

function bash_env
    set -x BASH_ENV ~/.bash_functions
    bash -c "$argv"
end

for BASH_FUNCTION in (bash_env 'declare -F' | awk '{print $3}')
    eval "function $BASH_FUNCTION; bash_env $BASH_FUNCTION \$argv; end"
end

You’ll need to change the BASH_ENV setting on the second line to point to the file where you declare your Bash functions. I’ve moved my functions out of .bashrc and into a separate file that I source from .bashrc. This is because I also source /etc/bash_completion from .bashrc, and that is quite a time consuming process to do every time you want to run a simple Bash function from Fish.

Once that’s done, simply fire up Fish and type ‘functions’. You should see all of your old, dear Bash functions appear in the list, ready to aid you in your daily endeavours, just like times of old. Now, try the Fish!

This is a photograph I took of Auguste Rodin’s “The Three Shades” on the Palo Alto campus of Stanford University. I find myself mesmerized by its other-worldly, almost divine qualities. Awe and fear; peaceful yet harbouring a latent, almost callous, indifference.

Enter the Rails Searchable API Doc

A few weeks ago I was directed to the Rails Searchable API Doc beta by Vladimir Kolesnikov: a nicely bundled, offline, HTML Rails API reference with full search facilities. Simply download a bundle (Rails, Ruby and gem documentation bundles are available) and unpack in a convenient location. Open the index.html file and voila! You now have a nice and fast Rails API reference available offline. The only problem with this is that a web browser is a very ad-hoc environment. I often have scores of tabs open, browsing random resources around the web. This meant that I now had the problem of trying to find my current Rails documentation amidst all of the other random guff that builds up in my browser.

Enter Fluid

Fluid is a Mac OS X application that enables the configuration of site-specific browsers. An SSB can essentially make a web application appear much like a first-class desktop application via a dedicated web browser sandbox. An SSB is a great way to keep your Google Reader, Facebook or other web sessions completely separate from each other, hosted in separate processes complete with individual Dock icons. It also turns out to be a really handy way of keeping HTML based references close at hand.

Simply:

1. Grab Fluid and the Rails Searchable API.
2. Snag a nice Ruby on Rails icon. This is to be used for the Dock.
3. Unpack all of these bundles into appropriate places.
4. Launch Fluid and set up a Rails API site-specific browser.



5. Consider dragging the generated SSB to the Dock.
6. Enjoy!
   

Fluid uses WebKit as its rendering engine, and configuration of the browser is naturally very similar to Safari. By default it maximizes browsing area by eliminating the tool and status bars but these can be added via the menu. In the screen shot you can see I’ve added back, forward and font resizing buttons. For a documentation SSB, it also makes sense to set Fluid to only hide the window when the window is closed. Such a setting is available in the Behaviour tab of the application preferences.

For those with open source cravings, Mozilla Labs has an SSB project called Prism that offers similar functionality, although I find their offering a little more sparse.

Over three months ago now, I left my position as Technical Lead on Atlassian’s Confluence team. It’s still an odd thing to state. I still believe that Atlassian is one of the best companies in Australia to work for as a software or technical support engineer, especially if Java development takes your fancy. Some of the most passionate and knowledgeable Java developers I have ever known work there. I’d like to thank everyone at Atlassian for their tremendous work and invaluable friendship. I had a truly memorable, enjoyable and productive three years there; they will always be a highlight and serve as a formidable benchmark.

But I’m a hopelessly restless person. I still feel like such an amateur in many respects. I’ve been developing software professionally for coming on a decade now plus many years tinkering with programming before my first paid position and I still feel I’ve much more to learn. I crave new experiences and problems. As such, I’ve taken a new position, working as a software engineer at Silverbrook Research. My first project is being built using Ruby on Rails, something I’ve wanted to learn but never managed to find the time along with everything else I want to do. My new position offers some unique opportunities, and I’m excited to be involved. I hope to blog more about my experiences using this platform.

The wheel keeps turning, and there appears to be never a shortage of interesting problems to solve, or interesting tools to help solve them. Even after all of this time, I still love doing what I do, and working with people who love what they do too.

Energy suddenly drains from me instantaneously, my legs sag and I flop against the blue wash wall, totally spent, the bag that I’m carrying falling limply to the ground. People stroll pass; some look at me, but through me, no recognition apparent, no friendly hand or aid. The remainder continue on oblivious. I’m not going any farther; this is where I’m going to stay, anchored to this ground, destination unknown and irresistibly unreachable.

Two young girls ride pass on bikes, they giggle as they pluck the sunglasses from my face. The sun flares in my eyes angrily, yet its heat still plays truant. Cute I think and wait for them to return them to me, but they don’t – they ride off, content with their spoils, unsympathetic to the fire in my mind. How could they? I ponder as if it really matters.

Time passes; an age; an instant. I return and I’m still affixed. I look down to my bag, the pound cake I was carrying is gone, no evidence of its existence, unless a bent clipboard and a crumpled piece of paper are a new confection.

I’ll go no farther I think, this is where I’ll stay.

Charles added some additional, thoughtful alternatives:

Depending on your belief or not in an afterlife/reincarnation, it could be 301 Moved Permanently, or if you believe John Edward, 305 Use Proxy.

Yes — we do think this is funny If you do to, perhaps you should consider joining us?