christopherowen.id.au

I’ve been writing a lot of UI code lately, and one of the bread-and-butter operations in UI code is toggling boolean state, usually in response to a button press. Now, what does toggling code look like?

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?

I love shells. I spend an inordinate amount of every working day in one. That one happens to be Bash, arguably the most ubiquitous CLI shell in the world. It’s not bad at all, although sometimes I think CLIs could be so much more than they are today. Some other people agree too, but that delectable future seems a little way off.

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!

Having quick access to API documentation is one of the absolutely essential requirements during my development day. I have knowledge of so many different technologies, APIs, syntaxes, runtime behaviours, protocols, editing environment commands and shortcuts crammed into my head that I’m well beyond having perfect recall of every single detail of whatever I happen to be working with. At the start of my Ruby programming adventures, I was always trawling through the online Ruby and RoR documentation, either using Google to find references or Firefox’s inbuilt page search to find a method, module or class in the framed documentation lists. This was wholly unsatisfying, particularly with how web browsers search through frame-sets. I also seem to have a major personality defect in which I will persist in certain kinds of suboptimal practices for far too long; I’m often loath to steal time from a current task to thrash out a solution to something that is bothering me at the fringes. Eventually I snapped and asked my colleagues what they used to satisfy their API reference needs when working with Rails. I was dismayed when I was told they used the same strategy as mine. There had to be something a little less primitive.

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.

Today I posted this picture to an internal discussion at Atlassian on RESTful APIs.

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?