At LShift we like to program on blackboards using untyped lambda calculus,
and we enter code into a computer only once we have a truly generic solution
to a problem. However, most of the time we need to earn money so that we can
eat and wear clothes other than LShift t-shirts – this usually involves
compromising our principled approach and using "real" programming
languages and libraries.
This can be quite painful! In my experience all real world projects need to
produce output for a customer and this usually uses a technology called
"mail merge" but as we are technical people we use the more
technical name of "templating" (If you are elderly and not a
computer scientist it is best to think of it as mail merge, this will have
been an activity you read about in PCW magazines when you were a spotty
teenager and hoped to never carry out and now looking back over your
illustrious career you have realised that you have spent most of your time
performing mail merge poorly). Templating sucks!
As we are rapidly moving into Movember
I will briefly describe templating with mustache (this is how colonial people
spell moustache, but searching for moustache on github will produce an
excellent Clojure library not a templating system). I propose that if you
are programming in Ruby,
Mustache sucks less than ERB and
will support my proposal with some examples.
As I said previously templating sucks! It especially sucks if you care
about the formatting of your output which is why I call templating mail
merge. If you received a printed letter from your electricity supplier and
Your request for
a further three phase supply to your premises
is denied as we fear that you have upset the villagers
with your reanimation experiments.
you would probably be wondering about the extra spaces and carriage return
in the text. Most of the time in HTML you wouldn’t notice because browsers
eat whitespace, however if you were templating printed material or code it
can be quite painful.
Lets look at an example of this using ERB. We will define a simple Ruby
class to hold sections that have a name and may contain subsections.
Here is the ERB to render the output:
Which I render like this:
That output doesn’t look brilliant to me! I can feel a bug being raised in
the issue tracker already, it really shouldn’t have those empty lines in the
If I modify the ERB I can do better:
Perfect output, but the ERB template looks a bit fragile, three end tags all
in a row with no indentation to guide you will probably lead to difficult
maintenance. The ERB templates I am currently maintaining are much more complex
than the one I have used here and indentation really does help to make them
Now for mustache! The template looks like this:
We have to do a small amount more work to generate the output like this:
The code produces perfect output:
The template also looks more maintainable than the equivalent ERB. However,
you can still break the output quite easily with a very small change like this:
Which produces this broken output:
So it is best to keep your mustache sections on seperate lines to avoid
extraneous whitespace. In summary mustache is probably easier and will
produce cleaner output that ERB if you are performing a mail merge.
Additionally mustache is cross-platform and has support for a large
range of esoteric languages if you are tired of programming in Ruby.
Clojure has an interesting implementation of a Huet-style zipper. I started translating it to Smalltalk, and in the process discovered a number of things not really related to zippers. Given that the end result ends up looking very similar to something we’ve already seen , let’s talk more about the translation process itself.
Continuing on from my post a few months ago about playing with my Kindle, I’ve now amassed a fair number of books, and managing it is starting to be a bit of an issue. The main way to do this is with collections of books. However, Amazon in their infinite wisdom have decided not to provide any sort of tool for managing these outside of the Kindle itself, and the interface is somewhat lacking and slow for doing any sort of mass changes.
Life isn’t all that bad, as it turns out the collections are stored in a simple JSON file as “collections.json” in the “system” folder on your Kindle. It does however use various ways to generate a GUID for an ebook to store each collection, so we’re going to need a bit of help to figure out what those GUIDs are, and having someone else do the drudge work of working with the JSON would be nice. Enter Kindelabra (yes, that’s the author’s chosen spelling…). Primarily, it’s a little Python/Gtk app for managing collections, but there’s also a reasonable library sitting behind it that we can play with. I found a bit of the functionality was buried in the GUI as opposed to being in the library, but that was easily enough tidied up.
You are currently browsing the LShift Ltd. blog archives for October, 2011.