2019 in Review

2019 was quite a year for me both professionally and personally. I think 2019 may mark the most travel I’ve done in a single year. My wife made it her New Year’s resolution to travel somewhere each month of the year. Whenever I could join her, I did. Thanks to a good remote work policy and a pretty good amount of vacation time, I was able to join her on several trips.

This year we ended up in:

  • San Diego, CA
  • Seattle, WA (a few times)
  • Traverse City, MI
  • Hill City, SD
  • Des Moines, IA (for the one and only Iowa State Fair)
  • Manzanita, OR
  • Montréal, Canada
  • Eau Claire, WI
  • Lihue, HI
  • Tuscan, AZ

I’m very thankful to have been able to visit so many places throughout the year. Montreal marks the only location that was not a vacation or getaway this year, but it marks an important professional milestone. I was accepted to speak at Craft CMS’s Dotall conference in Montréal this year, which took me to my first real conference. I spoke about Headless Craft Commerce with Gatsby, not something I have ever done in production, but something we’re very interested in at One Design. You can see the video of the talk here.

Dotall was a fantastic experience for a first conference. It was great to be around so many people who are passionate about and betting on Craft. I enjoyed making connections and getting out of my comfort zone a little bit.

On the professional side of life, this year saw a continuation of my interest and experience with React and front-end frameworks in general. For the first half of the year, I worked on a fairly large and complex application built with React, Typescript, and Node. I learned a ton about Typescript throughout this process. Typescript paired with a good editor truly changed my development experience. It's wonderful when your editor can understand your code and keep you from making little mistakes. The project was also a great opportunity to dive farther into testing the front-end. I implemented a large suite of Cypress tests for the front-end and gave myself more confidence in my code than ever. It’s great to know your code is going to work.

The back half of the year saw appropriately saw more focus on the back-end. We picked up a project to help a client build out a headless Craft instance. The client was working with Craft for the first time and had made it pretty far but needed a fair bit of help getting across the finish line. As it was their first time using Craft they made some poor decisions (in my opinion) when setting up the site. This meant we ended up writing a lot of content migrations to get their data in order. This was my first chance to use Craft 3 very seriously and the first time writing content migrations for it. I quickly fell in love with them. While they aren’t perfect, it’s great to be able to change content with code over multiple environments, especially when you need to change hundreds or thousands of entries all at once.

This was also my first real headless Craft implementation. Unfortunately, the client had picked Next and the element-api when they started their implementation so I haven’t gotten to really mess with the new GraphQL features and implementing it with Gatsby, but this project has shown me a lot about the pros and cons of a statically generated site, especially one with around 4,000 pages that need to be generated.

On some other fronts, this year I’ve continued doing some freelance work on the side but with all the travel my revenue was a bit down overall. It was a bit nice to have a bit of a break over the course of the year but I feel a bit of the freelance guilt when I’m not generating extra income. So far I don’t feel like it’s much of a danger to my work-life balance, but given how much balance is in the collective conversation, I’ll be keeping an eye on it.

I also continue to maintain a few WooCommerce plugins which provide a very different development experience to Craft’s plugin system. I find I miss Craft’s plugins when working on them, especially since I didn’t write the code of the WooCommerce plugins originally and haven’t invested any time in rewriting them or reorganizing them. They continue trucking along providing a nice bit of residual income in exchange for not much work, as well as giving me an outlet to improve my PHP skills a little bit. I hope to create another one someday, or rewrite them and add features to keep them valuable, however, I’m not sure I have a ton of leftover energy for that.

Last year I made a loose resolution to read more, specifically, I got a subscription to the New Yorker and did my best to read it every week it arrived. I did an alright job at this. I never forced myself to read an article I wasn’t very interested in and tried not to force myself to finish something if I lost interest. Overall it was great to read good writing all year, but as is the stereotype I just couldn’t keep up. Before our last few vacations, I had about five issues with me that I hadn’t even started. It’s a bit relentless. I didn’t end up renewing my subscription for the next year, but I’m sure I’ll miss it. Right now I plan to read more fiction instead. I’m finding it harder to stay up to date with the world news these days. It’s a bit too depressing to steep yourself in it. I continue to listen to Up First, The Daily, and the NPR Politics Podcast to stay up to date with things, but after those three I’ve pretty much reached my news quota for the day.

As the year comes to a close I feel like overall it was a pretty good year, at least for me personally. I’m looking forward to what 2020 brings.

Move Stash to Another Computer

I spend my development time split between two computers, my work laptop and my home desktop. Inevitably, I start some work on my laptop and want to resume it on my desktop or vice versa. In the past, a lot of times I would create a new branch or a new commit and prefix it with [WIP] but lately I’ve been curious if there was a cleaner way to do this.

Turns out there is! And it’s fairly simple.

On computer A, we stash all of our changes

# Stash all the changes (stash-all is an alias to stash untracked too)
$ git stash save --include-untracked

Then we create a patch files from the stashed changes

# Create patch file from stash
$ git stash show -p > patch

Finally, we move that patch file to the other computer and run

# Apply the patch changes back to our project
$ cd path/to/project
$ git apply path/to/patch

I still think creating a WIP branch is probably easier overall, but this way we don’t have to create anything to clean up later.

New Entry Script

When starting this site, I wanted to keep things really simple. Just me, Gatsby, and some markdown files. This was great for lowering the barrier to launch, but it's not so great for lowering the barrier to posting a new entry quickly and easily. After drafting a post or two, my developer brain went off while copying frontmatter between posts and trying to format dates in a consistent way.

I decided to create a simple node script that would help me create frontmatter consistently every time. My goal is to run something like ./bin/new Post Name and have the script create a new markdown file with the frontmatter already populated. Thankfully I don't have a ton of frontmatter yet (just path, date, title and status) so I can keep my script pretty simple.

Here's the script I ended up with:

const fs = require("fs")
const path = require("path")
const pwd = process.env.PWD
const dataPath = path.resolve(pwd, "./src/data")
const { _: title } = require("yargs").argv
const slugify = require("slugify")
const format = require("date-fns/format")

const now = new Date()
const slug = slugify(title[0])

const FRONTMATTER = `---
path: "/${slug}"
date: ${now.toISOString()}
title: "${title}"
status: "published"
---
`

const fileName = `${format(now, "yyyy-MM-dd")}-${slug}.md`
const fullPath = path.join(dataPath, fileName)

fs.writeFile(fullPath, FRONTMATTER, err => {
  if (err) {
    console.error("Failed to create file") 
    throw err;
  }

  console.log("Successfully created file:\n%s", fullPath)
})

Next, I added my script to my package.json file, so I can run npm run new -- "Post Title" in order to generate a new file that will have today's date prepended to the slug and will have all my frontmatter filled out accordingly. I have it set to create a published entry by default for now, but I might add an option, or update that default if I don't like it.

Hello World

I've been a fan of Jonnie Hallman and his product Cushion for a little while now. So when I saw him launch his 2020.destroytoday.com site, I thought it would be cool to follow suite. Here's the fruits of that. Unlike him, I spent a bit more time hammering out the little things before launching, but I love the idea of building out in the open and documenting it along the way. This site is still pretty bare bones, but I'm hopeful I can get into a routine of updating it with some of my progress.