Drunken Coder

Just fucking say it

2012-05-04T00:00:00+00:00

I hate the term "pet peeve", but that doesn't stop me from having them in spades. Most of them are just geeky annoyances: if you use various programming phrases imprecisely, I will lecture you. At length. Obnoxiously, even, and probably only for the benefit of my own ego. If you act obliviously to the concept of sunk cost, I will put you into the Stupid Until Proven Otherwise bucket. I'm a judgmental prick like that. Maybe you're pathologically incapable of being honest when I ask you a direct question. I will roll my eyes and talk about something else, forever incurious about your future opinions. So a lot of things bug me. But this post isn't about the stuff that just bugs me; this post is about the one thing that boils my blood, that sends me into hysterical fits of primordial rage, the ice pick in my brain that keeps me up at night. Especially when I'm drunk, which, right now, I am. I will try to remain calm while writing this.

If you want to curse, curse. If you don't, don't.

An example

This might require an example. So here you are, on Facebook, writing a post about your awesome job. Or Twitter or Tumbler or Gmail (this anger of mine is medium-independent). You want to say something strongly worded, something to express on no uncertain terms how great your day at work was. So far, so good. I love my job too; no shame in sharing on the internet. But then, in your excitement, you type out, "My job is the sh*t!". You hit enter. Everyone can see it now: your job is the sh*it.

If there were such a thing as baby angels, you would have just killed six-hundred and twenty of them.

"Shit" has an "i" in it. I'm pretty sure. Now, I'm not a great speller either, and one of the weapons not regularly stocked in my arsenal of petty neuroses is anger about spelling. But you knew that "shit" doesn't have any asterisks in it, didn't you? And you wrote it anyway. On purpose. Why did you do that? WHY DID YOU DO THAT?

I honestly, seriously, in all earnestness, do not understand. You misspelled a word with four letters in it.

You said the curse word. You wrote it to express the word and you successfully communicated that word to your audience, along with any associated meaning and connotation. So why the game of replace-the-letter?

It's everywhere

Once something like this bugs you, you see it everywhere. It's in articles. It's in web comics (Jesus, you self-censor your own web comic? Why do you even have one?). Book titles. Album covers. Magazines (Newsweek used to kill me with this, but it has apparently stopped). It's in emails from your coworkers.

Since there doesn't seem to be an appropriately specific word for this, I've decided to call it cursfuscation. It's a subspecies of bowdlerization. And it's one of the most irritating things on Earth.

It bothers me because it's utterly pointless; it detracts from the readability without changing the content. Sure, you can read it, but you can also read th*s and it's still annoying. And no one has a cogent explanation for why they do it. Part of some shared fiction about properness? Just a thoughtless habit? An honest fear of the literal letters in curse words?

If "LOL" is the nervous tick of the internet, then cursfuscation is its stutter.

Don't pretend you're not cursing

Maybe you don't like cursing. You think it's crass or just wrong. We differ in this respect, but fine, you think there are certain combinations of consonants and vowels which are off-limits to polite human communication. I sort of get where you're coming from, actually, and there are a few words I don't make a habit of saying. But you know what? I respond to my qualms about those words by not saying them. For example, I don't use the word "nigger" because I think it's shitty word that expresses a bunch of stuff I don't want to express. But, by trivial extension, I also don't write "n*gger" or "n----r" or say "nignog" and pretend I'm in the clear, because it's the same word. If the word is so bad, then why are you saying it? Do you really think that the morally reprehensible part of the word is the little vertical line with a dot above it? How has your s/i/\* avoided whatever culpability you feel for having used the word, in all of its actually-spelled-correctly glory? What's offensive about "shit" that isn't offensive about "sh*t"?

My dad doesn't curse, ever, out of a strong ethical commitment of some kind. I don't understand it, but I give him props for not actually cursing. He doesn't say "freakin" or "effin" or "f&#!ing" or--pretending for a moment that he watches TV other than Law and Order--"fraking". He doesn't pretend that the letters F-U-C-K form some kind of hyper-specific satanic incantation, the apocalyptic consequences of which can only be avoided by not saying the exact right combination of sounds involved, but which it's perfectly reasonable to express the substance of whenever you feel like. He just doesn't say "fuck" because he thinks it's wrong to say "fuck". Not complicated.

Who are you fooling?

Or maybe you're OK with cursing, but only in certain contexts, like hanging out with your friends. Maybe you're writing an email to a coworker and you want to be professional and serious. Professional, serious people, you think, speak only in the set of English words minus this particular seven. Maybe innocent children or prudish grandmas will read your writing, and they will be corrupted or offended by the raw power of your words. Fine, I get there are boundaries, sensibilities you don't want to offend. Mores.

But who are you fooling? You think those bosses, children, and octogenarians will have no idea what you mean by "b*tch" and couldn't possibly figure it out? They'll think it says "botch", right? Right?

You've only succeeded in insulting their intelligences. It's not even censorship, really; it's just minor obfuscation.

But in fact, it's even worse than that: the asterisk doesn't even work if the reader doesn't know what it means. The whole point of saying something is to communicate that something to the listener, and the only thing distorting your words can accomplish is to sabotage that goal. That's why you made sure it was easy for everyone to understand by using a known cursifiscation convention. You wanted to make sure that everyone knew the word was "bitch" without, you seem to think, the word actually being "bitch". You wanted to obfuscate your communication in name only, a sort of half-hearted nod and wink in the form of awkward reading. Who benefits?

You said "bitch"; come to terms with that or stop saying it altogether. The middle road is wholly imagined.

Some kind of disconnect

Much better, right?

As I understand it, cursfuscation started as a tacky way to circumvent obscenity laws, just like beeping on TV. In other words, the convention came about to make cursing in newspapers easier. Those newspapers that used "f------" could have just not cursed. They used dashes so that they could curse; they wanted to say "fucking" without getting in trouble. It stands to reason that if they prefer to curse, they would simply have done so plainly, had they been allowed. How the convention turned into a knee-jerky way of pretending not to curse is beyond me. Those laws are either no longer on the books or don't apply to you anyway, and you're allowed to curse to your heart's content. And you're making cursing harder for yourself and everyone who reads your writing. Why would you do that?

So stop. Please. No more cursfuscation. Your intentionally transparent word manglings do no one any good. It's insulting to our intelligences and cringe-inducing to read. You will offend no one who won't be offended regardless. Spare us your dashes, your asterisks, your beeps, your twisted versions of the words you're trying, awkwardly, to communicate to us and just fucking say it.

Or don't say it.

Twix.js

2012-01-09T00:00:00+00:00

I've been working on a simple project for handling date and time ranges in JS. I have a long ways to go, but I have the first part working well: formatting date ranges. And that makes for a good introduction to the topic as a whole, so I figured I'd blog about it.

Displaying time ranges

See, formatting date ranges so they can be read naturally isn't very easy. The general format on the web is something like:

Jan 26, 7:00 PM - Jan 26, 9:00 PM

Which isn't something you'd ever say, but it's what happens when you treat a date range as nothing more than two dates, call toString() on each one, and then join them with a dash. It's easy, so everyone does it.

But what I want to say is:

Jan 26, 7 - 9 PM

You might disagree. Maybe you live in France or something, and you want to say:

Jan 26, 19:00 - 21:00

Or maybe you're just the verbose type and want:

Thursday January 26th, 7pm - 9pm

Twix

In any case, I have a JS library that can handle that. It's called Twix.js, and it's pretty cool. Here are those three examples:

//takes dates or parses them
var twix = new Twix("1/26/2012 7:00 PM", "1/26/2012 9:00 PM");

twix.format()                           //=> Jan 26, 7 - 9 PM
twix.format({twentyFourHour: true})     //=> Jan 26, 19:00 - 21:00

//so I admit, this one is complicated
twix.format({
  showDayOfWeek: true,
  weekdayFormat: "dddd",
  monthFormat: "MMMM",
  dayFormat: "Do",
  groupMeridiems: false,
  spaceBeforeMeridiem: false,
  meridiemFormat: "a",
})                                     //=> January 26th, 7pm - 9pm

It can also handle all sorts of different range sizes as well as all-day events.

Get it

I have a lot left to do, but the formatting stuff seems usable. Comprehensive docs, downloads, and finger paintings live on Github.

Another year, another editor

2011-12-24T00:00:00+00:00

The constant search

I'm pretty much always looking for a new text editor. Every once in a while, I get pissed off enough at Emacs to sit down with a six-pack and a freshly downloaded editor and see if I can, you know, use the damn thing. I usually last about 15 minutes before I go scurrying back to Emacs, tail between my legs and slightly drunk.

The thing is, I hate Emacs. It's terrible at so many things. Its ecosystem is a clusterfuck of poorly maintained modes and broken extensions. It's chalk full of interface idiosyncrasies that make it painful when toggling between other programs. The default keybindings require you to make a cat's cradle with your fingers. The shell is broken in half a dozen ways. ELisp is weird. And goddamn is Emacs slow.

And yet...I come back to it every time. It's the editor I can't break up with. This is not because it has some special place in my heart; it's because every other editor really blows. They require you to use the mouse to do the most basic things. They throw weird dialogs at you, and those dialogs break all the conventions the rest of the editor uses. They think in files instead of buffers. They provide you cool autocomplete and go-to-definition features but ignore your need to actually edit text. They come with crummy defaults and then make them painful to change.

All that, and I'm actually a casual Emacs user. I'm not one of those guys with 5000-line .emacs files who check their email in it. For all my time using it, I'm a noob in Emacs land, struggling to efficiently edit text. It's just that it sucks less than other editors.

But that doesn't stop me from trying to do better. Here at Drunken Coder, we're always stumbling blindly into the arms of new, shiny editors, having sloppy one-night stands with them, and never calling them back.

A brief history of time

Sometimes those one-night stands turn into flings, or get drawn out into rebound relationships driven by some particularly nasty fight with E (we're going to call it E from now, I've just decided). They're not necessarily any better than the quickly discarded JEdits and Bluefishes and so on; it's just that they stuck around somehow. Maybe it's just that they wanted me? Here are the ones who made it to a second date:

Eclipse/RAD - It knows Java and understood the ~~Byzantine boondoggle~~ sophisticated project I was working on. Otherwise, Eclipse is just a bloated, sluggish mess of menus and modes and clicking and NullPointerExceptions.
SlickEdit - It's great at editing text, is hugely customizable, and has a few features I still miss. But it's ugly, the UI is awkward, the customizations are in a weird C-like language, and--when I used it--it couldn't parse non-ancient versions of C#. Oh, and it's expensive and you have to pay each year to keep up.
Visual Studio - Can parse C#, but is completely unhelpful without an expensive third-party plugin (which is itself very nice). More importantly, VS may be the worst text editor I've ever used. Seriously, just awful. And out of contention anyway -- I don't run Windows anymore.
RubyMine - It's packed with nice Ruby features and it runs well on Linux, but it can't escape its Eclipse heritage. Too clunky.

My number one issue with random editors, if you want to know the slightly inebriated and tangential truth, is that they don't treat their menus as first-class buffers. They've let you make whatever customizations you want to how text in the actual file is edited (ctrl+k for "kill line" or ctrl+~ ctrl+\ for "transpose then upcase then wrap in playful emoticons" or whatever), but those customizations don't work when you've called up a file switcher dialog, because the guy who wrote it just used the system's text box control. It's fucking infuriating.

Sublime Text 2

I've been working in Rails and Node and random stuff for almost two years now, and I'm once again tired of E. In fact, it's been doing this weird thing where sometimes the text disappears for no reason. Also, I have now tried every JS mode I can find and not one is even passable. I could debug all that or hack away at a JS mode until it does what I want, but then again, I could also be hacking on something new and exciting instead of old and broken, or, you know, doing actual work.

Of course, it's not like any of my old complaints about E have been magically fixed. That thing is stuck in time. It's like hunting with a musket.

It's time for another breakup.

Enter the new flavor of the week. Sublime Text 2 is gorgeous, fast, and customizable. And it's made it past round one: can I stand it?

Bullet points? Bullet points:

It's really clean and acts like a real text editor.
It uses TextMate language modes, so it taps into a big existing ecosystem (I've been amazed at how much better its understanding of Ruby is than my Emacs mode).
It's got that cool minimap. I can't even imagine how that would ever be useful, but it's sexy as hell.
The file switching and code browsing is quite good, though I'd rather get rid of the tabs and groups and just have a list of open files.
You customize it in Python and there seems to be a solid community around doing just that.

The long hard road out of Hell

Switching editors is really hard, and I'm not where I want to be with Sublime yet. Partially that's my desire to go whole hog. For example I'd like to give up the ctrl+x prefix on commands (I'm sick of mindlessly hitting them in other programs) even though I think they're mostly reasonable. So there's a steeper learning curve and I keep accidentally closing buffers trying to do kill-region, or cutting text while trying to save a file. It would be like coding drunk if I weren't already coding drunk.

Not there isn't enough mental retraining to do just from switching editors.

I also need to get it customized to where I'm actually reasonably productive relative to E, regardless of how painful E is. That's a big time investment and one of the reasons I've dropped many would-be editors. It doesn't help that the Sublime documentation is almost non-existent and you have to glean even the basic customization paradigm from the support forums. (I'm sure it's harder for me; I have the feeling most of the user base is TextMate converts and have some relevant prior knowledge.)

And I already have complaints:

I can't seem to make misspelled words not show up in retina-searing red.
- Oh, and there seems to be some sort of bug about spell-checking words in brackets. See that in the screenshot?
I can't run a terminal in it (for Linux anyway; it has one for Mac).
I don't know how to override parts of a theme without forking the whole theme.
The mark/kill/yank stuff is poorly implemented and I had to pull in (and edit) a third-party plugin just for that.
It's a tiny bit weird with line wraps.
There's what I suspect is Linux-specific clunkiness in opening files and projects.

So we'll see. I might be slinking back to Emacs a few weeks.

Scale and Google's Customer Support

2011-10-15T00:00:00+00:00

This Hacker News item is a complaint about a website being delisted by Google without a good, easily-understood explanation. Matt Cutts, who runs the webspam team at Google, jumped into the comment thread and provided some explanations. While the reasons he gave for delisting do make sense, one of the main counterarguments was that Google's customer support for webmasters is terrible, and the company is rather opaque and abrupt about the process. Why did the site owner have to find out how to fix it by getting his post at the top of Hacker News?

In the thread, Cutts says, in reference to a premium support option, "Normally when we consider it, we end up saying things like 'Why don't we just try to make it so that people don't need that option?'" And that's fine; not needing customer support is better than needing it. But until they figure that out, Google does need it; you can't just dismiss it with a hand wave and a vague goal. Google has a huge transparency problem. Their rankings and delisting decisions are opaque and seemingly arbitrary. For good evidence of this, just take a look at how quacky the gigantic SEO industry is; witchcraft shouldn't seem like a viable option here. More generally, Google just doesn't have customer support worth much of anything, and they just don't seem to care about it. Why?

Cutts has an answer there, although I suppose I should point out that he's not acting as some sort of official spokesperson for Google. In responding to the opacity/abruptness/support complaint, he says this:

I know that Google can seem abrupt sometimes, and I dislike that, but part of the issue is also scale. See https://plus.google.com/117377434815709898403/posts/1hRWj489... that notes that if each Google user had a single 10 minute issue every three years, that would need 20,000+ support people to handle that load. Or consider that there's 200M domain names, and all those webmasters want to talk to Google and ask questions.

For the record, I think this kind of direct engagement by important employees is great. But I don't buy Cutt's scale angle at all. Here's the thing: 20,000 seems like a lot of people, but it's not. Consider this statement I just made up:

I know McDonald's can be impersonal sometimes, and I dislike that, but part of the issue is also scale. If each McDonald's customer needed to be served a burger in person by a McDonald's employee, that would require 400,000 employees to physically make and serve all those burgers.

And, of course, that's exactly what McDonald's does, and you'd be really annoyed if you walked into McDonald's one day and your burger was sitting premade on a little heated tray that had been filled with foil-wrapped food hours earlier, and there was no one working there. McDonald's is actually a somewhat smaller company than Google ($24 billion vs $29 billion) and has far lower profits ($5 billion vs $9 billion). So Google makes a lot more money per dollar it spends. Those are obviously very different companies, and there are a lot of reasons McDonald's has lower profits than Google, but one of them is that Google doesn't employ tens of thousands of people to do customer support. But maybe it should!

We could debate whether 20,000 support people is enough, or actually way more than they'd ever need, or whatever, but that's not the point. The fact is that Google isn't having difficulty scaling its customer support team. It's just not trying to build one at all. Yet it could clearly afford one as big or bigger than the 20,000 people it thinks of as crazily huge.

No, it's simpler: Google doesn't have an army of support people because it can make more money by having poor customer service. It has a monopoly on search, and if you want your website listed there, you'll play their game no matter how difficult it is. It's just not under any meaningful pressure to improve in this area. So instead of employing a bunch of people in call centers to answer your questions and fix mistakes, it pockets more money. Corporations are greedy--maximizing profits is their job--but we shouldn't be giving them a free pass on this sort of thing just because they've complained it's expensive. Making billions of dollars is supposed to be hard work. We should all be demanding better customer support from Google, and maybe we should be taking a good hard look at their competitive practices in this area.

Programming Languages Matter

2011-10-14T00:00:00+00:00

Ben Bitdiddle and Alyssa P. Hacker are at a bar, at least three martinis deep. You're at nearby table and overhear their loud conversation:

BB: I don't want that job, because I'm a Java programmer and they're a Python shop, and--

APH: What do you mean, you're a "Java programmer"?

BB: Well, you know, some people are Perl programmers, and other people are Java programmers, and other--

APH: No. Of all the stupid ways you can sort programmers into buckets--back-end vs front-end, application vs operating system, enterprise vs consumer--why would you choose to define yourself by the programming language you typically use?

BB: Well, I know Java. I don't know Python. It says "Java programmer" next to my name on my resume.

APH: If you want to put yourself into a box, then define yourself by the kinds of problems you want to solve, your style of problem solving, or something like that. A programming language is a tool; within certain parameters, you can do anything with any of them. I mean, honestly, how long does it take you to learn a new language? Some new syntax should be trivial compared to learning, say, how to architect a scalable system, and that's the same in any language.

Then you go back to whatever more interesting conversation you were having. You're pretty sure they go home together and have loud, punny sex. But let's talk about what they said. To a first order approximation, APH > BB. As Steve Yegge has observed, "an 'X programmer', for any value of X, is a weak player." It's true enough, and I'm always annoyed when I'm called a [whatever language I'm using at the time] programmer. But APH is very wrong about why BB shouldn't care so much about his Java identity.

Defining yourself as, say, a Java programmer has some serious pitfalls. First, Java isn't the right tool for every job, and in fact is very awkward for some of them. As a trivial example, you wouldn't use it to write a shell script to copy around some files. I think everyone gets that it's just too verbose and structured to do job well.

To generalize that, the reason BB and APH are both wrong is that defining yourself by a language limits your thinking. Like a real-life spoken language, you can't think about things you can't put into words. Language isn't a way of capturing thoughts; it's the building blocks of those thoughts. To give a simplistic example, people in some primitive cultures can't differentiate green and yellow because they don't have different words for them. Similarly, if you're stuck thinking in Java (and you are, even if you're thinking about something wildly abstract, like APH's "architecting scalable systems", whatever that means), then you're missing entire programming paradigms, and the chances are you're building something the wrong way. Maybe the best way to think about structuring your program is in terms of Lisp macros or Haskell existential types or continuations or Erlang actors or Node events or monads. But those aren't primitives you know, so you can't build the higher-level structures of your program around them.

And worse, you don't even know it. You can't even conceptualize it. If you'd never seen a "scripting" language, you would start your little file-copying programs with public static void main(String[] args), and you wouldn't think anything of it. It would just be The Way Things Are Done.

In any language, I find myself mixing and matching programming paradigms borrowed from other languages, or approximating language features I don't have available. Java programmers sometimes fake closures by creating anonymous inner types, and while it's a pretty crummy approximation, it goes a long way towards solving some otherwise painful programming problems. But first you have to know what a closure is and what it's good for. And you might know that because you've worked with programming languages where functions are first-class. To get more exotic, if I knew Haskell in any depth, I might use monads as part of problem solving toolkit, and that might allow me to structure, say, a Ruby program with better data abstractions. But I can't really know that until I figure out what monads are all about. Note to self: learn Haskell.

Of course, it goes deeper than language features: languages are more than just syntax trees. A lot more. In practice, languages are tightly coupled with standard libraries, platforms, and ecosystems. These are usually impedance-matched with the language itself; have you ever noticed that Java libraries tend to be verbose and explicit while Ruby libraries tend to be terse and slick? That extends to how the API interfaces are structured, the extension points, the level of programatic openness, everything. When you choose a language, you're also choosing a programming philosophy, because everything built for you is built with that philosophy.

You might have decided you strongly programming under a certain philosophy. Let's say--and we're being incredibly simplistic about the salient features of languages--you really like dynamic, hack-friendly languages with lots of syntactic shortcuts, because you're a dynamic, hacky, slick kind of dude. That's fine, I'm with you. But what happens when you come across a problem that's best solved with a statically typed language with lots of imposed structure? Do you abandon the whole problem, or do you pigeon hole it into your programming aesthetic? You should instead learn some alternative techniques indigenous to other languages, or even just solve the problem in one of those languages. Do you really think your language is so perfect that it contains every concept you might need?

There are some good reasons you might build something in Java (or any other language). But there are also an awful lot of bad ones, the greatest of which is that you just happen to know Java. So yeah, BB should maybe look more closely at that Python gig. And APH should think a bit harder about programming languages, and why they might be important.

Introducing Spandex

2011-09-29T00:00:00+00:00

So you're a programmer, and you want to start a blog. You've got some pretty cool opinions about software construction and that wine from dinner has you thinking the entire world has just got to know all about them. And maybe some neat posts about the aardvarks you've seen lately. Sitting down with your digestif, you get to work. You go the standard route: you find one of the dozen crummy WordPress hosts, pick a theme, and start typing your brilliance into a form in the admin section of your site. And it sorta works.

But then you start thinking about it:

Why can't you use your favorite editor? I mean, you spent all this time customizing the crap out of your Emacs experience, and now you're typing tons of content into a form in your browser?
Man do these WISYWYG editors blow. Wouldn't you rather be using a nice markup language, like maybe something similar to what StackOverflow uses?
WP's admin interface is your content management system. But you're already very proficient with a much fancier, more powerful CMS: your source control system. You can use it from the command line instead of a clunky interface, and you can do a lot more with it. Why can't you use that?
Your posts live in a database somewhere that you don't really have access to.
No, but really, did I mention your WP host totally sucks ass? I guess you could install WP on an EC2 instance, but that seems like overkill, right? Maybe you could host it on Heroku?

A different model

A better idea might be a site that reads your posts from files (like, on the filesystem!) and generates web pages from them. Now you can manage those files in Git and edit them however you want. And if they're built on a cool stack, you'll be able to host it somewhere free and nice. So, you look around, and there are some pretty cool options:

Jekyll: Generate static HTML pages from Textile or Markdown files and then host them wherever you want.
Nesta: Dynamically generate a site from markup files. Themes, plugins, and all that jazz.
Toto: Another dynamic site that generates the blog from static Markdown files.

I'm sure there are others. I lean more towards the Nesta/Toto model of generating the HTML dynamically. That narrows my hosting options (because my host will have to support whatever web framework the engine runs on), but means there's less for me to actually do (I don't have to generate the site before pushing it to the host). But whatevs.

What's a blog, anyway?

But you're feeling a bit greedy and you want to do even more with less. So you think, what, in a technical sense, is a blog? It's two things: 1) a simple content management system that keeps track of your posts, figures out which ones to show your user, turns them into HTML, and generates an RSS feed; and 2) a web application to actually show those posts in. A blog engine tackles both things.

But here's the thing: you're good at building websites. You want to build your own website, where you control what the URLs mean, and how the framing markup gets generated, and all that jazz. Maybe you want to integrate the blog into an existing site. Maybe you want customize the framing HTML (you know the chrome stuff like the title and footer and sidebars), but you really hate Haml for some reason and Nesta uses it for just that purpose. And you don't really want to think about "themes"; you want to have some HTML and write some CSS for it, and that's that. The world has built you a bunch of awesome web frameworks to build sites with, and dammit you want to use them. It's just the CMS part that's annoying; there has to be some code somewhere that pulls the right files off of disk and formats them when the user, say, clicks on the links for posts tagged "aardvarks". (You love aardvarks, it turns out. No one is sure why.)

I'm going to assume, for no real reason, that you're the kind of programmer who likes Ruby. It's a good thing you are, because I have some good news: I wrote you the piece that does all the content management. It's called Spandex.

Spandex!

OK, so first of all, what kind of abject moron names a programming library "spandex"? When you hear it, all you can think about is this:

Yeah, I don't know. The gem name wasn't taken. Anyway, Spandex lets you do stuff like:

some_posts = spandex.find_articles(:tag => 'aardvarks')
some_posts.each do |post|
  puts "Title: #{post.title}"
  puts "Stuff about aardvarks: #{post.body}"
end

How do you make these awesome posts about aardvarks? Here's omg_aardvarks.md:

Title: Oh my God I saw some aardvarks!
Tags: aardvarks, things i saw today
Date: 2011/9/2011

I was just riding my bike down the street and **LO AND BEHOLD**, an aardvark!!!

Yeah, your aardvark obsession is a bit creepy; let's more on. The top part of the file consists of key-value pairs that provide metadata to Spandex. Stuff like whether it's in draft mode. The bottom is the content. You can write it in any markup language supported by Tilt; it'll decide which to use based on the extension. And you can customize that through Tilt itself.

There are a lot more details, examples, and awkward non sequiturs on Spandex's Github page.

Sounds easy, right? So finish your glass of port, get a sixpack of beer, and let's build a blog.

Build ye blog

You're going to want to start simple. A blog with some posts, an about page, something allows all of your avid fans to comment, and an atom feed.

Let's get to work. We've got our spandex on, so now we just need to build a website. Let's use Sinatra, Haml (which I guess you don't hate after all), and the SCSS variety of Sass. OK, here's our directory structure:

   +- app.rb              # Your Sinatra app
   |
   +- config.ru           # Config file for making Sinatra sing. Get it?
   |
   +-content/             # Bucket of your content
   | |
   | +- omg_aarvarks.md   # Your first post!
   | |
   | +- about.md          # Some stuff about you
   |
   +- views/              # HTML templates for the chrome
      |
      +- index.haml       # Shows all of the posts in descending order
      |
      +- layout.haml      # Title bars and such
      |
      +- page.haml        # Display and individual post and its comments

So, app.rb handles the web requests:

require 'sinatra'
require 'spandex'
require 'haml'

content_dir = File.expand_path('content', File.dirname(__FILE__))
@@spandex = Spandex.new(content_dir)

#render the index
get '/' do
  posts = @@spandex.all_articles
  haml :index, :locals => {:posts => posts}
end

# render the atom feed
get '/feed.xml' do
  content_type :xml, :charset => 'utf-8'
  @@spandex.atom_feed(10, 'Tiny Blog of Doom', 'Your name here', 'tinyblog.net', '/feed.xml')
end

# render stylesheets
get '/css/:sheet.css' do
  content_type 'text/css', :charset => 'utf-8'
  scss params[:sheet].to_sym
end

#render individual posts
get '*' do
  post = @@spandex.get(params[:splat][0])
  haml :page, :locals => {:post =>  post, :show_comments => true}
end

The Haml files are also pretty simple. I won't cover all of the details, but here's page.haml:

%h2
  %a{:href => post.path}= post.title
%div= post.body
- if show_comments && ENV["DISQUS_NAME"]
  - if Sinatra::Application.environment == :development
    %script var disqus_developer = true;
  #disqus_thread
  %script{:type => 'text/javascript', :src => "http://#{ENV['DISQUS_NAME']}.disqus.com/embed.js", :async => true}

That shows a single post and pulls in comments from Disqus.

You can run the whole thing with shotgun config.ru or you can just check it into Git and push the whole thing to Heroku. The source for the entire tiny blog is here. Check it out! DO IT NOW.

You can also check out the code to this blog, which naturally uses Spandex, and does some other neato things.