Word-processing documents are, charitably, a less-than-ideal way to represent textual content. As a recipient, they necessitate the presence of current and often expensive application software (i.e. Microsoft Office) - at least if you want to view the document with its original visual fidelity intact. As a creator, they are even worse: one ends up pouring effort into a binary-blob1 artifact that is, practically-speaking, untraceable and unversionable. Even if all of these objections were addressed, a substantial existential quandary remains: Word processing workflows were built for a paper centric world. We no longer live in such a world.
And yet, the obvious candidate to replace these has existed for some time: the web!
For all of my philosophical objections to
.docx and its various derivatives and predecessors and workflows, there's only a single such document in my life that I begrudgingly find myself re-opening to replenish its life and relevance: my resume. I set out to build a better solution.
A better replacement for a word-processor-based resume requires the following:
- Built with web technologies (HTML, CSS)
- Easy to deploy and update at a URL endpoint
- Version controlled content with
- Responsive layout for acceptable mobile-sized viewing
- Reasonable print-to-PDF output for when that's inevitably requested
I've written a tool to address this need called curriculum-vitml2. It's a Ruby-Middleman static site generator which relies on Foundation for responsiveness, Sass/SCSS for styling and Slim partials and templates for the various resume elements. Its final output is a static HTML document with a single accompanying stylesheet, but the middleman server and SCSS/Slim components provide an easy update cycle. And of course the whole thing is inherently versionable3.
A single CV entry looks like this:
Each job or 'role' is represented by one of these Slim partials in the repository. I thought about using JSON or YAML for the data storage, but Slim is so readable and easy to update that I decided it wasn't even worth the translation. Additionally – keeping things in web markup allows for custom sections of data – an education section with a grade
<table> for instance.
The final web output looks quite notionally like a traditional resume at desktop size:
It's responsive on mobile:
And its print media queries allow for reasonable PDF output (this was generated from Chrome using OS X's 'print to PDF').
Of course, this is all very specific to resume-needs in general, and my resume-needs in particular. But it's the only 'document' in my life with a reasonable chance of still being requested in 'file' format instead of 'URL' format. This bridges that gap. Feel free to use it as a starting point for your own.
That may no longer technically be true with the onset of
.docbut it's true for all practical purposes. No one's putting their Word docs in
gitrepositories, and if they are, they aren't happy about it. ↩
A lazy portmanteau of curriulum-vitae and HTML. ↩
My own personal resume is now a private fork of this repo. ↩