Inventive Labs: Weblog

Get your Notepods!

2009-09-11T15:55:10Z

Inventive Labs has teamed up with the Jacky Winter Group to produce Notepods - sketchbooks for your app ideas, in a package reminiscent of your favourite smartphone.

It's incredibly fun to come up with an idea in the pub over a few beers and have it produced in the space of ten short days, website and all. Get yours now!.

Harry, we are here to help*

2009-02-06T12:17:13Z

Last week, our colleagues at Collier and Associates asked if we'd donate some of our time to building a website in support of Harry Nicolaides, the Australian writer who has been imprisoned in Thailand for defaming the King. We, of course, were happy to oblige: freedom of expression is something we all hold dear.

Collier contributed the design and we put the site together in Blueprint; the whole process took about a day (in searing temperatures during last week's heatwave), and the site is now online.

You can help bring Harry home by signing the petition or donating money.

* A reference to a French thriller whose title I, for some reason, have never been able to forget.

Peeking at previews in Blueprint

2008-12-26T17:25:49Z

I just uploaded a little Quicktime movie of a recent change to Blueprint: spring-loaded previews.

It's only a small change, but one that has been on my list since, oh, the 4th of December 2006 — when our version control system tells me I started working on the 'drafting' functionality that is at the core of Blueprint.

Formerly, you just clicked the Preview tab to check your changes before saving them. The preview would pop up in the same grey frame you see in the movie. The recent change was to animate the transition — and to allow you to "pull" on the tab to "peek" at the preview.

Like I said, it's a small change, and you could argue it's mere eye candy. But it has stayed on my list of things to do because exactly these sorts of user interactions give an interface its handling — the sense that you're steering it, rather than poking at it. From this, the people using the system develop a confidence and an instinct.

Migrating from Lighthouse to Redmine

2008-12-15T17:46:27Z

We love Lighthouse, but here at the Labs our needs have begun to change and Lighthouse no longer feels like a best fit for us. So we've upped stumps and moved to Redmine, which is less flashy but better complements our workflow (such as it is).

I took a couple of hours to write a rake task that politely exploits the Lighthouse API and imports almost all available data from that system into a Redmine instance.

Here it is:

Download file (5Kb)
lighthouse_import.rake

Steps:

Install the task file into lib/tasks in your Redmine directory.
Add the lighthouse-api ruby library as a plugin. This essentially involves running the following command from Redmine's vendor/plugins directory:
```
$ git clone git://github.com/Caged/lighthouse-api.git .
```
If you haven't already:
- create your database and configure your database.yml
- rake db:migrate
- rake redmine:load_default_data
- Log into Redmine and create the projects that will contain the data you're importing from Lighthouse. Configure them however you like — in order for the import to happen, they must be named exactly as they are in Lighthouse.
- You can similarly create users and assign them to these projects. Any users with matching names to Lighthouse users will be recognised by the importer.
In Lighthouse, set up an API token if you haven't already. This can (and should) be a read-only token.

Now run the script:

$ rake import:lighthouse LH_ACCOUNT=abc LH_TOKEN=xyz...321

Obviously the LH_ACCOUNT and LH_TOKEN environment variables should be entered as per your Lighthouse account. You can also pass in CREATE_USERS=1 to actually create user accounts where they are referenced in the Lighthouse data — they will have dummy names and email addresses, and their passwords will match their login names. If you don't pass in this flag, any unrecognised user references will be assigned to the first admin user.

The script could use a little refactoring, but it worked very well for our needs. Let me know how you go.

A Bloggie for Ms Fits

2008-03-18T15:43:13Z

The fabulous Reasons You Will Hate Me has just been honoured with a Bloggie for Best Australian Weblog. Inventive Labs designed Ms Fits an appropriately sexy new site in the middle of 2007, and built a custom content management system to suit some of her specific requirements - in particular, the now world-famous 'Friday Q&A'.

Congratulations, Ms Fits!

The other things

2008-02-25T10:48:33Z

We do have a habit of saying how busy we are at the Labs, to the extent that it's almost a little obnoxious. We do, in fact, occasionally find time to craft software that is not for particular paying clients, but has a wider audience.

Fridge, our Facebook app, is an example of this. That was a fun project, and the reception has been really rewarding. I worry about the commercial trajectory and privacy implications of Facebook, but in developing Fridge I gained a high regard for their technical platform.

By far our most popular project is Tabulate, released in October last year, for iPhones and iPod Touches. It gives you a slick interface for, well, power-browsing in multiple windows with MobileSafari. Tens of thousands of Apple device owners are using it.

Also for iPhones, released by stealth and only shortly after Tabulate, is Kapow! -- a digital comic book viewer. I think only about three people in the world use it, but they seem to love it.

On the weekend we released another project that's been in (mostly weekend) development for a month or so: Castanaut. In technical terms this is a Ruby DSL for writing executable scripts that control input and application interaction during screencast recording.

In layman's terms it's a way you can take the screencast notes that you're already writing down on paper before recording, double-click them, and have a screencast saved and ready for publishing. It's kinda freaky.

The many tentacles of Inventive Labs

So, we've had a recent proliferation of subdomains here at the Labs. Two of them may interest you:

Gadgets: this is where we put the publicly available goodies we develop.
Wisdom: a more frequently updated stream of mostly technical but occasionally humourous objects that preoccupy us.

Eight days at the Labs

2007-11-27T12:31:21Z

One of the items on our extremely well-populated todo list is to update our Portfolio page. It'll happen shortly, but meantime I thought I'd give you a quick look at three sites we've launched in the last eight days.

Several months in the making, the new Readings website gives this iconic Melbourne business the online stature it deserves. Integrating with their inventory and ordering systems, the site makes fascinating use of "product collections" to recreate the serendipity of browsing in-store. Added to that is a powerful and greatly simplified search, regular postings of events, news, product reviews and downloads, and a shopping basket that is secure, intuitive and remarkably fun.

We're rather proud of the Readings website, which we built from scratch in Rails.

BestQualityCrab is an unusual experiment in the convergence of blogging and geography. We constructed the site in Blueprint for a small cohort of Melbourne academics, who explain it like this:

It starts from the belief that blogs are usually created around time-centred ways of organising thoughts and narratives. BestQualityCrab starts from the idea that blog thinking and narratives can be organised in terms of space and place as well as time.

Blogs are rarely quite this interesting to explore. In fact, we think BQC might herald an entirely new category of weblogs.

Wired Consulting is a new Australian telecommunications consultancy with a remarkable pool of talent. This is our second collaboration with David Koopmans of Mokum Marketing, and once again shows the flexibility of Blueprint.

Three big sites in a little over a week is not bad for a team of two inventors. Obviously our pace isn't always so quick, but since August we've launched 14 Blueprint sites of varying complexity. And you wonder why we love our little CMS so much.

Scheduling periodic tasks in a Rails application

2007-11-08T17:49:28Z

There's a number of solutions around for forking out of the Rails http request cycle and performing intermittent or long-running operations within your Rails application environment. Some of the most well-documented options are summarised on the Rails wiki.

Looking for a way to schedule actions like 'fetch this feed every 15 minutes', 'clear out old sessions from the db', and 'take a snapshot of each site' for Blueprint, I investigated most of these options.

In the past I've used the reliable cron/runner combination, but this requires additional setup -- outside of your app -- on each server where the app is deployed. There are recipes out there for updating the cron table via Capistrano, but this is difficult to do in a way that preserves existing cron configuration. BackgrounDrb and AP4R both look accomplished, but are really intended to solve other (and bigger) problems.

OpenWFEru is a Workflow Engine, which sounds impressively enterprisey. I don't know much about that, but it comes with a pretty good scheduler — check out the API for it here.

This can be used to create a cron-like scheduler within Rails. I wanted the scheduler to run as a separate process alongside the pack of Mongrels that handle web requests, started and stopped by Capistrano. Ruby has a great 'daemons' gem that takes care of daemonising processes for you.

If you need something like this, install these two gems:

$ sudo gem install -y openwferu daemons

Then create script/schedule:

#!/usr/bin/env ruby
require 'rubygems'
require 'daemons'
APP_DIR = File.join(File.dirname(File.expand_path(__FILE__)), '..')

Daemons.run_proc(
  'schedule',
  :dir_mode => :normal, 
  :dir => File.join(APP_DIR, 'log'),
  :multiple => false,
  :backtrace => true,
  :monitor => true,
  :log_output => true
) do

  # Daemonising changes the pwd to /, so we need to switch 
  # back to RAILS_ROOT.
  Dir.chdir(APP_DIR)

  # Load our Rails environment.
  require File.join('config', 'environment')

  begin
    # Initialise the OpenWFE scheduler object.
    require 'openwfe/util/scheduler'
    scheduler = OpenWFE::Scheduler.new
    scheduler.start

    # Now assign jobs to the scheduler (see API). For example:
    scheduler.schedule_every('15m') { Feed.fetch_and_consume! }

    # Tell the scheduler to perform these jobs until the 
    # process is stopped.
    scheduler.join
  rescue => e
    RAILS_DEFAULT_LOGGER.warn "Exception in schedule: #{e.inspect}"
    exit
  end
end

Chmod this file to be executable, then test it:

$ chmod a+x script/schedule
$ script/schedule start

Monitor the file at log/schedule.output -- most errors will be reported here. It will log to log/<environment>.log. Run 'script/schedule' with no arguments to see how to stop and restart it, and do other daemonoid things if you like.

You can then create a task within your Capistrano deployment recipies along the lines of:

task :after_restart do
  run "RAILS_ENV=#{rails_env} #{current_path}/script/schedule stop"
  run "RAILS_ENV=#{rails_env} #{current_path}/script/schedule start"
end

Using Blueprint as a Drafting Tool

2007-09-11T10:50:03Z

A couple of weeks ago I spent a day designing and building simple default templates for each of Blueprint's core page types ('blueprints'), ostensibly to help us demonstrate the system more easily to clients and friends. There are currently ten generic blueprints – Page, News, Links, Search, Events, Contact, Projects, Blog, Gallery and People – and each of them has one or more templates, all mixing a bit of logic with some HTML. There are companion javascript and CSS files, too.

A by-product of completing this task is that Blueprint has gone from being something I started working with after the architecture of a new site was established (most often with pen and paper, followed by laborious and under-appreciated site maps put together in ~~Illustrator~~ Lineform), to being an indispensible tool in the drafting process: I can create a working site prototype in mere seconds, and manipulate it quickly within the drag-n-drop interface, testing hypotheses and seeing roadblocks much sooner than if I were starting from sketches.

Obviously this isn't a substitute for thinking through the more complex IA requirements of larger sites, but for a typical small Blueprint site it's both appropriate and efficient, since whatever is achieved at this stage is carried over seamlessly into the development.

It's also considerably easier for people we're working with to understand, since the results have the dimension and interactivity of a finished site.

Like that but with this: view inheritance in Rails

2007-09-05T16:47:16Z

Yesterday I wrote about a simple method that lets you to place default content in your Rails layouts. This default content can be optionally overridden by your views using the standard-issue content_for.

It's handy enough on its own, but it's also a piece of a somewhat larger puzzle — something I've called view inheritance. The principle is that, just as Ruby classes can extend from parent classes, so ERB templates should be able to extend from parent templates.

Consider this template, a.html.erb:

<html>
<body>
<% default_content_for :title do %>
  <h1>Bonjour</h1>
<% end %>
</html>
</body>

Now b.html.erb, which inherits a.html.erb:

<% inheriting_view 'a' do %>
  <% content_for :title do %>
    <h1>Aloha</h1>
  <% end %>
<% end %>

That says "do everything that the first template does, but make the title say 'Aloha'".

Of course we're not doing much different from what a layout does yet — we've just shifted responsibility for specifying the layout file from the controller (or outer view) to the view itself. Sometimes that's not very useful, and although view inheritance can be wielded as a general replacement for layouts, I'm not really recommending it.

But what about this scenario? You have a model X, and an XController that serves up a form for X. Then you need a model Y, which is like X but with a few extra fields. So you create the Y model:

class Y < X

And perhaps a YController:

class YController < XController

But how do you add the extra fields to the form? Like this:

<% inheriting_view 'x/form' do %>
  <% content_for :additional_fields do %>
    <fieldset>
      <legend>Geography</legend>
      <label>Latitude
        <%= @f.text_field('latitude') %>
      </label>
      <label>Longitude
        <%= @f.text_field('longitude') %>
      </label>
    </fieldset>
  <% end %>
<% end %>

So DRY you'll need a beer when you're done.

Here's the code:

  def inheriting_view(options = {}, &block)
    # We accept a shorthand syntax -- if options is a string, render as a file.
    return inheriting_view({:file => options}, &block) if options.is_a?(String)

    bind = options[:binding]

    # Get our differences and additions to the view we're inheriting.
    if block_given?
      bind ||= block.binding
      instance_variable_set(:@content_for_layout, capture(&block)) 
    end

    raise "Important: inheriting_view() requires a block. " +
      "An empty block (eg, using {}) is suitable." unless bind 

    # If we're inheriting a partial, lend our local context to that partial.
    options[:locals] = eval("local_assigns", bind) if options[:partial]

    # Render our parent view.
    concat(render(options), bind)
  end

(Yes, this works for partials inheriting other partials too.)

Providing default content in Rails layouts

2007-09-04T11:11:10Z

Another quick tip for Rails view developers. We commonly employ the following snippet in our layouts:

<%= (out=yield :sidebar) ? out : render(:partial => 'sidebar') %>

This thorny little one-liner says, if the view we're rendering for this layout has content_for :sidebar, show that content. Otherwise show the default content (which we've tucked away in the 'sidebar' partial).

It's a handy pattern because it lets your views opt to modify some aspect of the layout, without having to — they can go with the default sidebar content if they don't care.

However. Firstly, it's a bit unsightly. Secondly, you must put the default content in a partial (unless it's short enough to just be a string — an approach that is arguably uglier). In most cases, the default content for a block in a layout is best described in that layout, so that you don't have to go hunting down other files to get a picture of what the layout displays. Here's a better way:

<% default_content_for :sidebar do %>
  <p>This is the default sidebar content! (et cetera)</p>
<% end %>

So now, if the view specifies some content_for :sidebar, the contents of the block above (ie, the <p> tag) will not be rendered. If the view doesn't do that, then the layout will render the contents of the block.

If you'd prefer this idiom in your views, drop the following method into application_helper.rb:

def default_content_for(name, &block)
  name = name.kind_of?(Symbol) ? ":#{name}" : name
  out = eval("yield #{name}", block.binding)
  concat(out || capture(&block), block.binding)
end

This method is full of bindings and captures, which you can read up on at your leisure, or feel free to ask questions in the comments.

The writing's on the magnetic wall

2007-09-03T14:47:58Z

Many, many moons ago (thirty-seven, to be exact), I made a little DHTML application called The Fridge. You had a bunch of word tiles that you pushed and shoved into the shape of a poem, much like Magnetic Poetry on fridges all over the world. It was good fun and much loved by many people, but with the passage of time the flocking crowds dwindled down to a core of devotees. And then, as is the way of things, they too found other pastimes.

Last week we took a couple of days out at the Labs to turn The Fridge into a Facebook application. This manifestation is even more fun than the last, because you can now create your own sets of words and share them with others. Also, crafting miniature epics on your friends' walls for posterity is a rather satisfying pursuit.

Here's what it looks like:

If you have a Facebook account, take it for a spin.

Apache's 'internal dummy connection'

2007-08-21T00:32:01Z

Since version 2.2, the ubiquitous Apache webserver has begun intermittently issuing GET requests to itself. They hit the root '/' url. They appear in your access logs looking something like this:

::1 - - [...] "GET / HTTP/1.0" 403 16 "-" 
"Apache/2.2.4 (Unix) mod_ssl/2.2.4OpenSSL/0.9.8a 
DAV/2 (internal dummy connection)"

And in your Rails logs like this:

Processing Controller#index (for ::1 at ...) [GET]
<snip>
200 OK [http://127.0.0.1/]

Fine, GETs should be idempotent, so it's completely safe practice and don't you worry, son. Well, except...

Here's a common web application pattern wherein GETs are not quite safe: caching on demand. When a resource is requested, the web server is instructed to check whether a cached version of the resource exists (eg, a static .html page). If it does, it is served up. Otherwise, a web application is invoked and asked to serve the page. The web application does so, and saves a cached version for future requests. (It will have some internal or external logic that determines the expiry of cached resources.)

So there's a scenario where a request might be issued and the result saved for all future requests. What if that request comes from a local, rather than a remote, caller? This can have a bearing on the response. In the case of Ruby on Rails, urls constructed with url_for() use the local domain (127.0.0.1) rather than the remote domain (example.com).

If the response to an internal request is cached, it's going to get served up to all your remote clients. And all those localhost links aren't going to work for them. This is the problem we have with Apache's 'internal dummy connections': they intermittently corrupt our cache.

I deal with it rather bluntly:

  RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
  RewriteRule .* - [F,L]

This mod_rewrite snippet, which belongs in your .htaccess file or <VirtualHost> config, sends the internal connections a 403, keeping them well away from your application.

5-minute redesign: Ebay

2007-08-08T17:32:23Z

Here's what Ebay looks like:

I allocated some of my highly valuable time this afternoon to fix it:

It would have been shorter if I'd had the time.

Sortable Tables for Prototype

2007-07-19T18:04:48Z

We've used Stuart Langridge's original JavaScript library for sorting tables on a number of projects. As perhaps the first important application of unobtrusive JavaScript techniques, it was a ground-breaking piece of code. But four or five years on, its ~480 lines of code were beginning to look a little hoary. Stuart has recently updated it with a more modern approach, but I still baulk at 20kb of JS for what is often a non-essential UI feature.

Since we use Prototype on most projects, my ideal was a slimmed-down implementation of sortable tables that leveraged Prototype to gain some efficiency and concision. Out of long habit I began with a Google search to see if anything had already been done — after all, we're inventors, not re-inventors. I found Inigo Surguy's impressively brief implementation, developed during a pedagogical analysis of recent developments in JavaScript.

Testing it out, I had a few issues with it — it was quite slow, it required markup that I considered unnecessarily verbose, it relied on a superfluous logging library, and there was some potential for namespace clashes when let loose amongst other JS (init() is a pretty common function name). There was also a function or two that duplicated Prototype functionality. And, as a purely personal aesthetic preference, I like my JavaScript to be OOP and mindful of 80 character line limits.

So I ended up borrowing Inigo's useful approach to the problem and rewriting the code mostly from scratch. This implementation resolves the issues listed above and does some caching of comparison data to gain a little speed. Also, it's 4kb. Download it:

Sortable Tables for Prototype (0.00Mb)

Like Inigo's version, this is released under the Creative Commons Attribution-ShareAlike 2.5 license.

Here's a simple demo. Click the headings to re-sort the table:

ID	Inventor	Price	Expires
1	Thomas Edison	$13.50	13 Feb 2008
2	Nikolai Tesla	$21.00	4 Aug 2007
3	James Harrison	$13.27	25 Dec 2007

* Obviously, this may not work within your feed reader.

Not bad for a one-year-old

2007-07-02T15:24:55Z

Yesterday, Inventive Labs was one year old. Rough calculations reveal that in the last twelve months we:

Wrote 41 proposals
Had 48 meetings with clients, including one former Prime Minister of Australia
Designed 14 websites
Built 8 web applications, including 5 for clients and 3 for use in-house
Invented Blueprint
Made 2,196 check-ins to our Subversion repository
Had 19 'business meetings', most of them at The Gem in Collingwood
Ate 26 pizzas from Bomb in Abbotsford
Rose to ridiculous heights in Wii Tennis (Joseph)
Rose to moderate heights in Wii Tennis (Virginia)
Cursed Internet Explorer 234,511 times, mostly while wrangling the alpha transparency for this site
Praised Capistrano 1,200 times
Drank the odd beer on a Friday afternoon

We also met our financial targets (modest and unscientific as they were), worked with and for a host of excellent people, and never for a second regretted our leap into the Unknown Unknowns of business ownership. Not bad for a one year-old.

iPhone development bookmarklets

2007-06-27T16:58:54Z

Part 1, where I go off on a tangent.

There's a mad techno-media lather working up over the launch of the iPhone, like someone dumped a shipload of hype concentrate into the oceans of geekery. Our office houses at least one particularly fervent Apple watcher and thus we're all immersed in the bubbles, despite being on the other side of the world to every iPhone in existence right now (and, sadly, for the forseeable future).

This post does have some genuine relevance to Apple's Jesus phone, but first I have to tell the story.

While we were developing this site, I scrapped together a couple of bookmarklets to help us compose screengrabs for our portfolio. Virginia had provided me with pixel-precise dimensions for the images (667x225, fyi), and I thought it would be useful to frame the shots in the browser before copying the screen to the clipboard for cropping.

What I wanted was a bookmarklet that set the viewport of my browser to exactly 667x225 pixels. This is different from setting the browser window to specific dimensions — what I wanted was the visible page area to be a certain size.

Which is something of an idiosyncratic situation, I suppose. Anyway, I ended up writing both bookmarklets, available below. Drag and drop them to your browser toolbar.

Resize Window (prompt)

Resize Viewport (prompt)

Note that Render Viewport won't work in:

IE — didn't have a need, and IE's bookmarklet support is woeful
Quirks mode — too many quirks

Part 2, where I bring it all back to the device du jour.

So, the iPhone. A lot of folks are going to be making apps specifically for, or with a special compatibility mode for, the iPhone. Now the iPhone's Safari has pretty good support for displaying the 800x600+ layouts on which the web floats its boat, but still, you won't always want to force your iPhone users to zoom each time they use your application. You'll want to give them something that works at 320x480 (or 480x320). And for convenience, you'll want to preview it on your development machines, running Safari or Firefox. Which means you're going to want these:

Resize Viewport (iPhone vertical)

Resize Viewport (iPhone horizontal)

Note: I've extrapolated the viewport dimensions by multiplying the ratios of the Safari chrome in published screenshots against the known screen resolution of the display. In both modes, the status bar is 18 pixels high; in vertical mode the toolbar appears to be 46px and horizontal it's 32px. So, I'm going on 320x416 for vertical and 480x270 for horizontal. I might be out by a pixel or two—if so, let me know and I'll update accordingly.

A conundrum

2007-06-14T16:56:53Z

How can a web development company stay in business for a year without a proper website?

It became a bit of a running joke down here in the laboratories, but the truth is (like our placeholder site said): we've been busy. Really busy.

Nevertheless, with the end of Year One In Business fast approaching, we cleared a little room between our various projects to knock something together, and here it is. In the unlovely expression of the industry, we're eating our own dog food—this site is powered by Blueprint, our delightfully simple and endlessly flexible Content Management System.

Anyway, this is our 'Hello World' post. Stick around—there's way more interesting stuff to come.