We live in a time when companies are beginning to “wake up” to the reality of how vital (and difficult) digital security can be. At the same time, public awareness of the need for security is increasing.

But there is a difference between making a site that says it is secure and making a site that is actually both secure and usable. Here is a story about how not to do it.

I recently decided to try out a new digital game camera that has cellular radio capability. Online reviews raved about the Moultrie MCG-13310, so I bought one. In order to access the images from the camera remotely, Moultrie requires that you set up a “Moultrie Mobile” account. Fine, I get it. They want to be in control of your images, and they want to be your primary gateway you your images. I don’t love that, but it’s not so different from e.g. Wyze Cams or many other digital connected devices these days.

The Moultrie Mobile sign-up process is atrocious. For one thing, they want to know a lot about me just to start an account (not even for billing - we’re not there yet). Do I trust these guys to keep my info safe? I have no idea! I’ve never had any dealings with their site so far; I have no reason to trust them. I grumbled and pressed on.

Soon, they want me to create a password. The instructions seem OK:

(Password must be at least 8 characters long with one special character from the following: !@#$%^&*()+)

So I set a strong password with the help of my password manager and I pressed on. The site happily accepted the password and did the email-confirmation step. Then it redirected me to log in for the first time…

“The email or password is incorrect” — What? Well, since I use a password manager, I know I didn’t mis-type it. I’ve seen this before. Moultrie’s password instructions are hiding the fact that their implementation is more limited than they are letting on. Beware of this dark pattern: Now I don’t know which thing I did that didn’t pass some filter in their login process. Was it one of the special characters I chose? Was it the length of the password? I have no idea.

Experience tells me the password length is the most common culprit when other sites have given me this sort of issue, so I clicked “Forgot Password?” to try and set a shorter one. Now it becomes a race to the bottom. Just how short does this thing need to be? I went from > 60 characters to 40, 31, 26, all the way to 16. Nothing worked. What the hell, guys?

I finally decided that maybe their instructions were literal. Maybe when they say “one special character”, they really mean only one??? So I tried entering a password with 16 characters where one was a special character from their list. I got a little red message: “Enter a valid password”. Hmm… I tried a different special character and didn’t see the message.

Moultrie’s password rules are a lie. Some of the special characters in their list don’t seem to satisfy their filters. I tried adding each one in turn to map out what triggered the red text and which didn’t. Look like they actually accept: !@#$%^& but not *()+.

Don’t let me set a password you won’t actually let me log in with! And, while we’re at it: Don’t lie about your password requirements. Be clear. Set good minimum requirements, don’t force a maximum — but if you do be honest about it.

In the end, I got the account set up – it was the incorrect instructions about special characters that was the problem, not the length of the password or the number of special characters allowed. But it took 5 different passwords and over 30 minutes to figure out a combination that worked. Not great UI, for sure.

PS: Do I trust these folks who couldn’t make the sign-up process work correctly? NO. No I do not. They’ll be getting a one-time-use credit card number and as little of my real personal info as possible. Not a good impression, Moultrie.

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…