Show HN: The Markdown Resume
mszep.github.io
mszep.github.io
I found myself spending so much time manipulating my resume to match each job description I was applying to, that I put all of my experiences, interests, etc. into a sqllite db. Using that, I created a UI to quickly select which items I wanted in this iteration of my resume, and then spit it out in a few different HTML formats that could be easily converted to txt or pdf. I eventually intended to do ngram matching with job description bullet points, but I got hired and moved onto other projects.
The sqllite db was overkill. Honestly I think what would have been better would have been a json format not unlike http://jsonresume.org, because it allows for more attributes, some of which could be used to group experience.
This markdown is nice because it's humanly intelligible, but what if you want to give hidden attributes to the different items - attributes which shouldn't be in the final media file?
This usage scenario had occurred to me, but didn't seem like a priority in the first version. It does seem like this is where vanilla markdown would fall down, but fortunately pandoc supports header attributes in markdown source [0], and filters with which you can programmatically alter the internal representation. So potentially, this seems doable without having to use a more structured representation like jsonresume.
1. Wasn't congruent with what Clojure's parser allows
2. Defined by whatever Hickey feels this year
I've worked on more than one edn parser in non-Clojure languages, it was Total Hell.
Hitching your wagon to EDN isn't advisable, there are better formats if you need them.
What changes have bothered you?
* Have you documented the ambiguities?
* Have you open-sourced your non-Clojure EDN parser(s)?I love putting "structured data" in formats like JSON as much as the next guy, but sometimes that approach misses the point a little bit IMO.
For example, how does this structured approach ensure that everything fits neatly on one page?
To expand on your point, it's true that this approach does not automatically fit a given amount of content neatly into N pages, but I don't think there exists a system that can; you'll always have to iterate on what exactly to include if you want to have exactly N fully filled pages, regardless of your document processing workflow.
Focusing on a model for your resume is kind of a helpful developmental tool itself imo.
Too bad this sort of thing will not ever catch on, or standardize. Either way it is very useful for me personally.
The approach in my post was specifically trying to be a more flexible format than the recently featured JSON resume, while giving ConTeXt as much freedom as possible in laying out the pdf.
I dunno maybe I'm lazy because I don't generate from LaTeX or Markdown or JSON or whatever but I feel that nobody reading your CV really cares as long as you present the information in a concise and clear way.
I mostly wanted to be able to style my resume using CSS3, which is not possible with your method, which is a shame - but this is still pretty great. Nice job :)
I considered this too, and indeed I was not able to find a way to use a single stylesheet with multiple formats. However, I found that many css commands have (near) equivalents in ConTeXt, so translating the css wasn't as much work as I was fearing. I don't know how this would have worked with LaTeX, but I get the impression it wants to do more of the layout work itself..
The HN post can be found here: https://news.ycombinator.com/item?id=7996464
Otherwise its aesthetically well rendered:)
You're right; I considered this aspect, but thought it was more important to preserve the flexibility to e.g. name sections whatever I want, or order them however I want. Ultimately I see the final document (html or pdf) as primarily intended for human, not computer consumption.
Which for a resume isn't a bad assumption. Additionally, if I choose to use something semantic to define the resume, this is a wonderful way to format it nicely:)
I thought about this too, but came to the conclusion that since markdown (or, more precisely, the pandoc internal format) does offer enough structure in the form of lists, tables, headers, even footnotes etc, it makes sense to stay in markdown because it's much more human-friendly than, say, json.
In the meantime, I actually am looking for a job, see https://news.ycombinator.com/item?id=7833969 for details :-)
</shamelessplug>
About your site, I used it extensively and it was a great help :-)
https://github.com/donatj/resume Build script https://github.com/donatj/Resume/blob/master/build.php
Interesting, I wasn't aware of DOMPDF...
Your pdf looks much nicer than what I was able to achieve going from html to pdf with wkhtmltopdf. Then again, your css stylesheet is a bit simpler than what I'm using, I wonder if that'd make a difference.
But that's exactly what my approach does though, it improves on an earlier approach which generated pdf via html by adding a ConTeXt template which allows pandoc to generate a pdf directly, and gives the resume a similar look and feel to the html version.
Using ConTeXt instead of LaTeX has the advantage that it's nicer for setting layout properties, is more of a coherent system (in contrast to LaTeX's maze of packages), and is not specifically geared towards producing scientific documents.
Flexibility in styling is not a strong point of my approach to be fair, since you'd need to write new styles in both css and tex.
If people want to contribute new css styles, I can try and come up with tex equivalents...
I get your sentiment, but I feel an important advantage of this approach is that the markdown file is much more appropriate to put in version control than a Word document would be. Also, the TeX typesetting is just that bit nicer than what you'd get from converting the .doc, but that's perhaps of secondary importance for some :-)
PDFs are fine. But, IMO, Markdown is better, because it's also demonstrating a skill that's usable in your job.
Honestly, I use Word for writing formal documents on the rare occasion when it happens, such as letters to the government. But not for resumes. The formatting is just too frustrating. I've been using HTML and markdown for that. www.rocketships.ca, for example. I never send .docs to anyone - .pdfs or raw text only.
Then I use @media print css to make it grayscale and exactly one page if printed.
Lastly I use chrome's Print to PDF option to make a PDF version of it.
I think I could prob jam the HTML into word if I really needed a .doc but who really wants to work a place mandating that.
What's left? a YAML resume?
Already done: https://github.com/divad12/resume
By 'standard' I pretty much mean PDF.
$ curl http://r.dakko.us/klange.7 | man /dev/stdin pandoc dir/*.md --to html
for f in *.md; do
pandoc $f --to html > $(basename -s.md $f).html
done
for f (*.md) pandoc $f --to html > $f:r.html