My “Law of Coders-Writing-Dissertations”: If a coder starts writing a dissertation, pretty soon they will end up trying all the existing solutions to write the dissertation in Markdown and convert it to perfectly-typeset $\LaTeX$ . When existing tools the coder slightly dissatisfied, they will invent a new bespoke method of doing this task. Eventually, the dissertation might get written…

I think I have to extend that to include CVs (résumés) as well: I keep wishing for a way to easily track all the information necessary to build my CV in one declarative form, then generate any “view” of the CV I want quickly. In other words, if I want PDF, or Word, or Markdown, it should be easy and scriptable. Turns out, there are several different ways of maybe doing this. Coders seem to run into this problem, evaluate the alternatives, then make their own solution anyway. And so have I.

I really like the idea of HackMyResume… Quite honestly, I think I like it enough to try to adapt my process to use it (because why ever leave “good enough” alone?). But, I really wanted to use YAML (or maybe TOML) as my definition language since it is more editor-friendly than JSON, and I wanted to use pandoc to convert to different output types.

Here’s what I settled on.

First, I entered all of the information I wanted into a YAML format. I had already started down this road at some previous point in the past when I started (and abandoned) this quest, so it was convenient just to bring the YAML file up-to-date. I found that converting from YAML to JSON is easy with the remarshal tool. Then, I want to build my master “view” in Markdown, which Pandoc can convert into Word, HTML, PDF, or lots of other things. To turn the data into Markdown, I decided just to use the well-known Mustache js tool — I build a template that shows how I want to format and layout all the info, then I let Mustache do it. But since Mustache wants JSON-formatted item declarations, so I use remarshal to convert YAML-to-JSON, then Mustache to create the Markdown file the pandoc to change to other output formats.

This all seems like a lot of parts, but actually it is very simple to orchestrate with a Makefile. And since the declarative “data source” YAML is plain-text and the “master” view Markdown file is plain-text (as is the Mustache template) — it is dead simple to source control the whole thing in git.

In summary, here is the workflow:

• Define CV information in YAML format.
  • Hint for “Simple” bibliographic info: Export in “CSL-YAML” format from your reference manager (I use Zotero). (Or, export in “CSL-JSON then use remarshal to convert to YAML”).
• Prepare template:
  • Create a Mustache template that will match the Markdown output format you want, given the data you define in your YAML.
• Build Markdown:
  • Convert YAML database to JSON with remarshal.
  • Convert JSON database + Mustache template to Markdown with mustache.
• Build other formats (like Word) using pandoc.

If you have cv.yaml and cv.mustache, it could be as simple as:

remarshal -i cv.yaml --of json | mustache - cv.mustache cv.md
pandoc -f markdown -t docx -i cv.md -o cv.docx

Now you can start getting fancy with Pandoc templates to make the Word / PDF / etc. versions look “just right”. Enjoy!

When apple updated the MacBook Pro series in 2016, I immediately ordered a 15-inch version to replace a nearly 5-year old MacBook Pro that I had been running Linux on for the last two of those years. I received it on November 16, 2016. About two and a half years later, I’m still using it, and it still works great.

But I have to hop on the keyboard complaint bandwagon for a moment, since my experience seems to be a bit different than many others. I did experience the “stuck key” due to a piece of dust only a week after the new machine arrived — but that problem worked itself out soon after, and the affected L key has been fine ever since.

The problem I ran into was that the key caps themselves began to detach from the butterfly mechanism. It took a year and a half (ish) for the first key cap to loosen up (it was the left CMD key, immediately followed by the F key); but after those first two, I’ve been replacing them at a steady pace ever since. I’ve created a table showing the dates I ordered key replacements and which key I needed. Notice that as of the end of May, I’ve come full circle and the F key has come loose again.

I’ll update this post when new keys fall off, until I give up and get a different laptop anyway. Oh, and did I mention the screen discoloration?

PS: The supplier I’ve been using to get replacement keys is http://replacementlaptopkeys.com/. I’m not endorsing them, but I have to say so far the replacements have worked well. For me, it’s easier just to replace them myself than to make the trip to the closest Apple Store, but if you have one close by you should make use of Apple first, obviously.

Update 1: July 19, 2019: D key.

Update 2: January, 2020: T key (2^nd time).

Update 3: April, 2020: T key (3^rd time). I probably should have bought the updated 16-inch MBP by now…

Update 4: May, 2020: CMD key (2^nd time).

Update 5: Aug, 2020: E key. I wonder if those Apple Silicon MBP’s will be coming any time soon?

* Update 6: Aug, 2020: F key again… E key hasn’t come in yet, and as I was moving the laptop to my work desk for the first time since COVID-19, I noticed that the battery has swelled to the point the whole thing rocks when on a flat surface, and the top doesn’t close completely! That was it; I ordered a refurbished 16" MBP which came in yesterday and now I’m getting it all set up. I’m looking forward to the upcoming ARM Mac transition (hence the refurb, not a new purchase), but I’m pretty happy to close this particular chapter with Apple laptops. Oh, and that new keyboard feels much nicer. Fingers crossed…

About a year ago I started using the black formatter tool for all my new Python projects. I wrote about it here, explaining why it seemed like a good idea at the time, and left open the question of whether I would stick with it.

So, have I? Yes. I do not agree with all of the decisions that black makes when formatting my code, but I appreciate the consistency it gives and the reduced cognitive load of worrying about formatting the code before committing to Git. Most of my projects aren’t large collaborations, but I think it would be even more valuable for those. So, thumbs up to the black devs. And I invite you to try it out if you haven’t yet… See what the Zen of not worrying about formatting feels like.

P.S.: I am a very finicky code formatter. I love things like vertically-aligned operators and vertically-aligned in-code comments. Black doesn’t always do what I want in these cases, but at least I can shrug and say “well, that’s just how it is”. Again, reduced cognitive load — no need to sweat the small stuff if black is going to change it anyway. “Just learn to let go.”