ginvoke

I’m no Mac advocate like many of my peers seem to be these days, but it’s always been obvious to me just how powerful QuickSilver is for a desktop user. I used it all the time and it wasn’t long before I started looking for alternatives on other operating systems.

When I found myself stuck on Windows one day, I stumbled across Executor which is very similar to QuickSilver in concept, but is extensible using a simple but expressive settings Window. I would often combine my use of Executor with a scripting language to automate much of the time I would’ve previously spent in cmd.exe.

And so I came to Linux looking for something with the flexibility of Executor and the clarity of QuickSilver. The options that are available (GNOME Do being the most prominent) fell a bit short for me — so I wrote ginvoke:

The video should hopefully provide some idea of the possibilities, but it’s essentially a stripped down version of QuickSilver with semantics that can be easily extended using plain old Python code.

I use it all the time myself and, gosh, I even like it … but nobody else seems to be using GNOME/XFCE these days. :)

Flask and Flask-WTF rock my world.

That is all.

GNU Screen splitting

I’ve never been an avid user of GNU Screen despite a number of people giving it rave reviews. I never needed to resume remote sessions and the window management stuff seemed pointless (“Why not just open a new tab in gnome-terminal?!”).

However, today I discovered that newer versions of Screen are capable of splitting the terminal window horizontally and vertically. A light bulb came on, and after a bit of experimentation I wound up with something that looks like this:

GNU Screen showing a window with a vertical and a horizontal split

One window for editing, one for server output, one for shell commands and git. I’d normally use different tabs for this stuff, and now here it is — all in front of me. This is more like it! Something I’ll actually use.

Since it took a little digging to track down the relevant documentation, I thought it might be worth documenting how I got my screen session to this point:

1. Open a new terminal and execute “screen”

This should present you with the command prompt (you may get a message regarding GNU Screen licensing — simply hit “return” to skip this).

Step 1

2. Split the screen vertically

Press CTRL-a SHIFT-\ (CTRL-a |) to split the screen vertically.

You can use CTRL-a TAB to switch between the panes. Note the blank pane doesn’t do anything useful yet.

3. Start a command prompt in the blank pane.

Press CTRL-a TAB until you’re in the new, blank pane, then press CTRL-a c to create a new window with a command prompt in this pane.

4. Split the right pane horizontally

Ensure the right pane has focus (press CTRL-a TAB until the cursor is in the blank pane), then press CTRL-a SHIFT-s (CTRL-a S) to split the pane horizontally.

Again, the new pane is blank and seemingly unresponsive.

5. Switch to the lower right pane and create a new session.

Use CTRL-a TAB to move focus to the lower right pane we just created, then CTRL-a c to spin up a new shell prompt.

6. Use CTRL-a TAB to move between the panes and start coding!

Other useful commands

  • CTRL-a SHIFT-x (CTRL-a X) will close the pane that has focus
  • CTRL-a d will detach screen from the TTY and put it in the background. Resume with screen -r
  • CTRL-a n and CTRL-a p shifts input focus to the next & previous window, respectively.
  • CTRL-a SHIFT-a (CTRL-a A) will ask you to set the title of the focus window.
  • CTRL-” list available windows

Week 1 in Portland, Oregon

I moved to Portland, OR, USA from Brisbane, Australia a week ago and I’ve got to say, I’m already falling in love with the place. It’s like a colder-still version of Melbourne where everybody talks a little differently.

My time here has been made a million times easier (and hell, possible) by the wonderful folks at New Relic, who have really gone out of their way to make sure I feel welcome here. The guys at New Relic have been absolutely stellar, and the work ahead of me is really exciting.

But now the tricky part starts: finding apartments, getting a social security number, a bank account, setting everything up in an unfamiliar place. It’s a little weird how, as an Australian, I implicitly know little things like “I need a phone -> speak to iiNet, Telstra or Optus” or “I need electricity -> speak to AGL, Energex or Origin”. Then you start Googling around for the US equivalents and none of them really stand out.

Sigh. It’s going to be a long couple of months. The whole thing is still strangely enjoyable, though.

Anyway. Time for bed.

Help Us Sell Prints For Charity! (or: Introducing arti.com.au)

A while back I approached my good friend Pete to sanity check a crazy little idea I’ve had kicking around the back of my head for a while now:

“Let’s get up & coming artists to provide us original works of art, slap ‘em on shirts, sell them, then give the resulting profits to charity!”

Pete, being a little more forward-thinking than I am, pointed out that we’d have no idea how popular any given design would be — and that this would be exacerbated by things like shirt size. Then he made a suggestion:

“What about prints?”

Of course. Plain old paper. Why didn’t I think of paper?

A little more back and forth to nut out details, a bit of screwing around on Linode, a few dozen lines of nasty PHP code and arti.com.au was born.

The idea is this:

  1. We approach a charity to be our designated beneficiary.
  2. We approach artists to provide us with original works.
  3. Those works are advertised on the site, along with artist bios & portfolio links.
  4. We accept (unpaid) pre-orders for a period prior to a specified “go-live” date.
  5. Prints of the works are available for purchase for a month as at the go-live date. (Folks who have made pre-orders will be requested to make payment on this first day.)
  6. Orders are accepted and provisioned right up until the end of the month.
  7. 100% of all profits are given to the charity within 14 days of the closing date.

The “timeboxed” acceptance and provisioning of orders may seem a bit backwards, but it serves two purposes: (a) it allows us to more easily comply with local state legislation pertaining to fundraising; and (b) I’m personally concerned that processing and provisioning orders on an ongoing basis will drain Pete and I both emotionally & financially!

Still, if the pilot is successful, we’re hoping to run these “events” a few times a year, possibly for a new charity each time around. Our first run is scheduled for early/mid 2012.

We are already in talks with our first charity regarding this run and hope to be able to announce further details in the coming weeks, so if you happen to know anybody who can help with sponsorship once we get our fundraising seal of approval we’re still looking for help with:

  • Getting the word out! – Whether you simply tell your pals about what we’re planning to do, follow/retweet the arti Twitter account (@articomau), or plaster us over a giant billboard somewhere — it’s all very much appreciated!
  • Art! – If  you’re a talented artist, we want your stuff! We’re still trying to figure out some of the details here, but if you’re keen to express your interest please do so via the arti web site or contact me directly for a prompt response.
  • Feedback! – Do you think we’re crazy? Maybe have a better approach that we haven’t considered? Want to help but don’t know how? Fill out our very brief little survey.
  • Web design! – Evidently the current design is programmer art. I’m more than happy to pay for a nice design for the arti site out of my own pocket if it comes down to it, but if any talented web designers out there would be kind enough to step up to the plate it would be much appreciated!
  • Payment processing! – Lest we lose potential revenue to fees from a payment gateway.
  • Web hosting! – I’m currently paying for this out of my own pocket, but again if a kind sponsor could take this off my hands it would be much appreciated!

Of course, any sponsorship will be rewarded with prominent links, recognition and all-round love on the arti web site.

Finally, if you have any questions or concerns that aren’t being addressed here, you can always contact me directly.

Do it because you want to

Short one today.

So in the last twelve hours I’ve read this and this, and I’ve seen countless more like them in the past. And I think both sides of the argument are bullshit. Not because they’re wrong per se. In fact, I can understand both perspectives — I just completely disagree with telling developers and designers what they should be doing with their lives.

Why not do what interests you and see where your passions take you?

You’ll probably find those passions will lead you in weird and unexpected directions over time, even if you start out fascinated by something very specific. I’ve certainly been surprised by how willingly I’ve come back to topics I once found painfully boring or skills I felt were out of my reach.

In any case, it’s really just so much better if you pick this stuff up after developing a natural interest in it rather than forcing yourself to learn something you find — frankly — boring. You don’t retain much of anything in this state of mind.

Life’s too short. Enjoy what you do. And get the hell off my lawn.

Buildr: A Better Maven

Mostly out of pure stubbornness, I’ve resolved to use vim as my editor of choice while I build a small compiler in front of the audience at my OSCON presentation next week. Whilst messing with Maven POM files for the umpteenth time to get my Scala code compiling, I got frustrated and figured there must be a better way to do this crap that didn’t involve 150+ lines of XML.

Turns out there is: meet Apache Buildr.

buildr: a build tool for Java/Scala/Groovy

As an example, here’s a Buildfile that I was using earlier:

require "buildr/scala"

Buildr.settings.build["scala.version"] = "2.8.1"

define "oscon" do
  project.version = "0.1.0"

  test.using :junit

  compile.with "org.apache.bcel:bcel:jar:5.2"

  package :jar
end

Then from the command line I run this:

$ buildr package

At this point, Buildr downloads Apache BCEL (a dependency of my project) compiles all Scala code within $ROOT/src/main/scala, runs my JUnit tests in $ROOT/src/test/scala and packages the resulting class files into $ROOT/target before packaging them up into a nice JAR file.

Better still, you can run it within any subdirectory in your project — Buildr will walk up the directory tree looking for a Buildfile to execute.

I tried doing the same thing in Maven and came out some 140 lines of XML worse off.

Of course, I’m just scratching the surface of what’s possible with Buildr here. It’s also very extensible: I wrote a little plugin to support compilation of Mirah using Buildr: buildr-mirah. Surprisingly easy — took me a few hours from scratch (which included tracking down and submitting a fix for a bug in the Antwrap dependency!). You require “buildr/mirah”, drop your code in src/main/mirah and you’re set.

Seriously. Check out Buildr. IDE die-hards will miss the tooling, but for command-line junkies I’m yet to see a nicer solution.

Speaking at OSCON Java 2011

Exciting times. I’m off to Portland, Oregon in July to speak at OSCON Java on the topic of compiler construction for the JVM using Scala parser combinators and Apache BCEL. Should be interesting — can’t remember the last time I wrote more than a few lines of Scala.

What? No, no, it’ll be fine. I promise. You should come too. There may be cookies.

I may be lying about the cookies. Still. You should come. For science.

I’ll be hanging out in San Francisco for a few weeks prior to the conference to sorta celebrate my first little venture outside of Australia. Come one, come all and help me stay well clear of sobriety’s evil clutches.

I know I keep saying it, but I really must start writing geeky things here again on a more regular basis. Hmm.

Intro to jazz templates for node

I wrote the initial implementation of the jazz template engine for nodejs about a year ago for one of Shine’s clients (Sensis). Back then, template engines for node were somewhat lacking. An analysis by one of our client’s devs found json-template to be a little too restrictive, while Mu (mustache for nodejs) would inexplicably result in segfaults. Not to say these aren’t now fine projects, but we needed a way forward. It is still in use at Sensis to this day and, largely thanks to its small feature set, has required minimal maintenance.

Despite the project being a year old and now reasonably stable, I’ve neglected to write a proper tutorial for it yet. Let’s fix that.

Overview

Jazz has a fairly traditional interface as far as template engines go. You bind values to template variables, call a render function with the name of your template, and dump the result to the browser.

The template language itself is simple with few surprises, except perhaps where the surprises are warranted by the event-driven nature of node.

Installing jazz with npm

Cliff Subagio (another Shiner) kindly spent the time to integrate jazz with the npm package manager for node. So if you have npm, installing jazz is really as simple as running the following from the command line:

$ npm install jazz

Rendering a jazz template

Once installed, you can try jazz with just a few lines of code:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("Hello, World");
template.eval({}, function(data) { sys.puts(data); });

// output: Hello, World

Calling jazz.compile(…) compiles your template code to a JavaScript Function object, which is in turn executed by template.eval(…). This is for performance reasons: you can compile your templates once at application startup & reuse them with different sets of template variables.

Rendering Template Variables

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("Hello, {name}");
template.eval({name: "You"}, function(data) { sys.puts(data); });

// output: Hello, You

As you can see by the template code we pass to jazz.compile(…), variables can be referenced by simply using curly brackets.

The first argument to template.eval(…) is an object describing your global namespace. Everything outside the core jazz syntax must be supplied using this object, including any helper methods or input data.

The second argument to template.eval(…) is a callback that is executed when the template has finished rendering. In this case we’re simply printing the template output to the screen.

You can use similar syntax to access object attributes too:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("Hello, {person.name}");
template.eval({person: {name: "You"}}, function(data) { sys.puts(data); });

// output: Hello, You

Calling Helper Functions

Calling functions from a jazz template is very similar to rendering variables. Jazz supports two type of function call: asynchronous and synchronous.

Jazz will not wait for asynchronous function calls to return during template rendering, instead continuing with execution until the result of the async call returns. Due to their asynchronous nature, async calls cannot be used as expressions (e.g. as the test within an “if” statement).

On the JavaScript side, an asynchronous helper function must take a callback function as the final argument. This callback must be invoked by the asynchronous helper function upon completion, with the output value passed as its only argument.

var jazz = require("jazz");
var sys = require("sys");

function noop(value, cb) {
  cb(value);
}

var template = jazz.compile("Hello, {getWorld()}. " +
"And {noop('thanks for using jazz :) ')}.");
template.eval({
  getWorld: function(cb) { cb("World"); },
  noop: noop
}, function(data) { sys.puts(data); });

// output: Hello, World. And thanks for using jazz :) .

Synchronous calls on the other hand can be used as expressions, but you must take care that the call does not block the execution thread lest you suffer a performance hit.

Synchronous functions do not need the extra callback parameter used by asynchronous functions.

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("Hello, {@name()}")
template.eval({name: function() { return "You"; }}, function (data) { sys.puts(data); });

if/elif/else

Jazz supports conditionals, with simple expressions and comparisons available within tests.

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{if active}You are lazy!{else}You are not lazy!{end}");
template.eval({active: false}, function(data) { sys.puts(data); });
template.eval({active: true}, function(data) { sys.puts(data); });

// output:
// You are not lazy!
// You are lazy!

else/if is provided with the elif keyword:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{if a}A{elif b}B{else}C{end}");
template.eval({a: true}, function(data) { sys.puts(data); });
template.eval({b: true}, function(data) { sys.puts(data); });
template.eval({}, function(data) { sys.puts(data); });

// output:
// A
// B
// C

Comparisons available include eq, neq and gt. (lt would also be trivial to add — taking patches!).

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{if a eq 1}A{elif a eq 2}B{else}C{end}");
template.eval({a: 1}, function(data) { sys.puts(data); });
template.eval({a: 2}, function(data) { sys.puts(data); });
template.eval({a: 3}, function(data) { sys.puts(data); });

// output:
// A
// B
// C

Logical and and or operators are also available:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{if a and b}Both{elif a or b}One{else}None{end}");
template.eval({a: true, b: true}, function(data) { sys.puts(data); });
template.eval({a: true}, function(data) { sys.puts(data); });
template.eval({}, function(data) { sys.puts(data); });

// output:
// Both
// One
// None

Expressions can also be grouped using brackets:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{if (a and b) or c}true{else}false{end}");
template.eval({a: true, b: true, c: false}, function(data) { sys.puts(data); });
template.eval({a: true, b: false, c: true}, function(data) { sys.puts(data); });
template.eval({a: false, c: false}, function(data) { sys.puts(data); });

// output:
// true
// true
// false

foreach

Jazz also supports iteration over array-like objects:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{foreach item in items}Item {item}\n{end}");
template.eval({items: [1, 2, 3]}, function(data) { sys.puts(data) });

// output:
// Item 1
// Item 2
// Item 3

You can also iterate over the attributes of an object:

var jazz = require("jazz");
var sys = require("sys");

var template = jazz.compile("{foreach item in items}{item.key}: {item.value}\n{end}");
template.eval({items: {Apples: 1, Oranges: 3}}, function(data) { sys.puts(data) });

// output:
// Apples: 1
// Oranges: 3

Types

Jazz supports strings, integers and hashes at the syntax level. Support for arrays would be fairly trivial to implement, but is not currently present.

Summary

Looking at github, you would be forgiven for thinking that jazz was an inactive project. This couldn’t be further from the truth. Shine and Sensis are using jazz on a daily basis to build real software. Jazz simply meets all our needs for the time being & is very stable. Consequently, there are few commits because it meets our needs and works well. (Disclaimer: I found a bug while I was writing this article: synchronous method calls could not be used in an echo context — we’ve not had to do that before, but it should still be possible! The fix has since been committed.)

All that said, we’re always eager for useful patches and/or bug fixes. So if you like playing with compilers and have a bit of time to burn, feel free to shoot us a pull request on github with your improvements and/or new features!

Happy to address any questions in the comments for this post.

Mirah: Getting to “Hello World”

Mirah, the brainchild of Charles Nutter, piqued my interest a while back (statically typed Ruby? Yes please!), but I lost interest pretty quickly because a) it looked like an afterthought compared to JRuby at the time; and b) it took me more than ten minutes to figure out how to build it.

The good news is that there’s recently been a couple of new releases of Mirah, with versions 0.0.6 and 0.0.7 being released over the weekend. It looks like Mirah is actually going to get a bit of airtime, so I figured it was time to figure out how to get this thing building. So here’s how I did it.

Before you start

Before you do anything, you’re going to need git, a JDK and ant. Getting these guys installed is outside the scope of the tutorial, but there’s plenty of resources on  the web to help you along the way.

Build JRuby (from source)

I cloned the jruby git repository:

$ git clone git://github.com/jruby/jruby.git

It may take some time for the full repo to be cloned (you might want to consider git’s –depth option). I imagine building from a tarball would also work just as well, so you might want to try that.

Once that’s done, you’ll need to build it using the jar-complete target:

$ cd jruby
$ ant jar-complete

Again, this may take some time. Grab a coffee.

Install Rake

I then had to explicitly install the rake gem in my build of jruby.

$ bin/jruby -S gem install rake

Get bitescript

We don’t actually need to build bitescript, we just need the checked out source folder present in the same directory as the jruby directory. Mirah’s build scripts currently require everything to be set up in a particular way, so this is important! (i.e. if jruby was checked out to /home/me/code/jruby, bitescript should be checked out to /home/me/code/bitescript).

Simply clone the repo from github:

$ cd .. # back to the directory above “jruby”
$ git clone git://github.com/headius/bitescript.git

Build Mirah

The moment you’ve been waiting for! Grab a copy of the Mirah source code:

$ git clone git://github.com/mirah/mirah.git

(to reiterate: Mirah’s build scripts require the bitescript, jruby and mirah directories all be in the same directory)

Then build it using our JRuby build:

$ cd mirah
$ ../jruby/bin/jruby -S rake jar:complete

If all goes well, you should now have dist/mirah-complete.jar, which is all you’ll need to run “Hello World”.

Running Hello World

Put the following code in a file called helloworld.mirah:

puts “Hello World”

Now you can run it via the command line:

$ java -jar dist/mirah-complete.jar run helloworld.mirah
Hello World

Compiling Hello World

You can also compile your program to a Java class using your newly built Mirah jar, and then run it using java:

$ java -jar dist/mirah-complete.jar compile helloworld.mirah
$ java -cp . Helloworld
Hello World

Note that running the “Helloworld” class doesn’t require any external dependencies: the generated class files are currently entirely independent of any runtime outside of Java itself. So you only need the Mirah jars around at compile time. Neat!

The End

Hopefully this stuff saves somebody from doing what I did months ago and simply walking away from Mirah in frustration after struggling with it for ten minutes. It’s a cool little language, and absolutely worth a play. Now, time to try and contribute some patches…