Piet van Zoen

How to setup Copilot to autocomplete commit messages

2023-07-08T00:00:00Z

Copilot, GitHub's AI programming assistant, has been a great addition to my development environment by giving (mostly) intelligent suggestions and autocompletion. Somewhat accidentally I found that Copilot was also good at writing commit messages. In this post, I will show how you can use Copilot to autocomplete your Git commit messages.

On writing good commits

Writing clear and accurate commit messages is super helpful for future developers (including yourself) to understand why changes were made. It's great for debugging and getting a grasp on the code you're working with.

Luckily, Copilot can assist with this and works best when the content of a commit is specific and related. And that's exactly what we want! There are plenty of resources available on writing commit messages, so I won't dive into that more here. Feel free to check out these links for some excellent content on the topic:

Setting up your commit environment

Setting up a commit message template

For a long time, I have used the a git commit message template to improve the quality of my commit messages. The template consists of a sentence starter which helps me write a commit message in an imperative voice.

To setup a commit message template add a file in your home directory called .git-commit-message.txt. Inside setup your template comments. Mine looks like this:

# When applied, this commit will (in less than 72 characters)...

# Why is this change needed?

# How does it address the issue?

# Provide links to any relevant tickets, articles or other resources

Including the character limit ensures Copilot doesn’t get too verbose with the message.

To configure git to use this as your commit message template run:

git config --global commit.template ~/.git-commit-template.txt

Once setup, Copilot can use this prompt and try to form a commit message. But without knowing what’s changed it probably won’t be very successful. This is where verbose mode comes in.

Git commit verbose mode

Verbose mode shows a unified diff of what would be committed at the bottom of the commit message template.

To use verbose mode we can use the --verbose flag. E.g. git commit --verbose. We can also enable verbose mode by default by running:

git config --global commit.verbose true

Now that the commit diff is in the commit message template, Copilot can use this as context for generating the commit message.

Commit message keyword

Finally, Copilot needs at least one word to begin suggesting a commit message. You can check out the Git Commit Message guide for a list of suggested keywords to get you started.

A few example keywords are Add, Drop, Fix, Make, Refactor, Reformat, among others. Once you've staged some changes using git add, run git commit and start writing the commit message using one of these keywords. Copilot will then begin suggesting the rest of the commit message. 🚀

Copilot in action

Example of copilot completion in neovim. 😙👌

Obviously, Copilot isn't always spot-on. It can make mistakes and give wrong suggestions at times. So, it's important to take its input with a grain of salt and trust your own judgment. Good commit messages should be informative and accurate, so don't forget to review and confirm the commit messages before finalising them.

Apart from that, have fun!

My favourite sci-fi reads

2023-03-05T00:00:00Z

A friend and I were sharing book recommendations and I found myself getting pretty excited about this list of books, so I thought I’d share them here. To be fair, all I read right now is sci-fi. So I could just say “My favourite reads”. Ah well. 🤷

Follow the links and read better descriptions than mine.

So, in no particular order…

The Murderbot Diaries - Martha Wells

A series of novella’s about an antisocial security cyborg that just wants to be left alone to binge watch tv. Murderbot (as it likes to call itself) is an instantly lovable and relatable introvert.

Mystery, adventure, and sarcasm. Oh my.

This is How You Lose the Time War - Max Gladstone, Amal El-Mohtar

A time traveling espionage love story. Need I say more? Well yes actually. The writing in this book is beautiful. There are points where I didn’t understand what was going on, but it didn’t matter, it was just... beautiful.

Monk & Robot series - Becky Chambers

I loved Becky Chambers' Wayfarer series so I quickly picked up her new Monk & Robot series. It’s beautiful and optimistic and challenged how I think about purpose and being.

Also, now I just want to be a tea monk.

Project Hail Mary - Andy Weir

Project Hail Mary is a super fun and exciting read and my favourite of Andy Weir's books so far. Lots of fun science, problem solving, and a delightful side-kick.

Stories of Your Life and Others- Ted Chiang

The movie Arrival (2016) is based on the titular short story in this book. I enjoyed Arrival but it took a far more actiony blockbuster approach to the story. I remember coming away from reading this story feeling like my brain had been rewired. I loved it, along with most of the stories in this book.

My IndieWeb tech stack

2022-11-21T00:00:00Z

I run a single server for most of my projects. Here's the rundown of the stack and apps.

Server - "BMO"

Linode VPS based in Frankfurt, DE (shameless referral link for free credit).
Debian.
Docker compose.
Caddy via caddy-docker-proxy for web server and auto-cert renewals.
Healthchecks.io for cronjob monitoring.
rclone backups to Dropbox.

Apps

Piet.me (source)

My own digital garden.
Eleventy static website.
Build via GitHub actions and committed to dist branch.
Cronjob on server pulls updates periodically.
Caddy file_server mostly handles the rest.

Dolphin

Microblogger tool for cross posting to twitter, mastodon, and GitHub.
Powers piet.me/updates. Updates repo.
Updates pulled into piet.me repo via git submodule.

Plausible

Privacy friendly analytics.
Self hosted (docs) via docker compose.
Sendgrid via smtp relay.

Miniflux

Feed reader.
Self hosted via docker compose (example docker-compose.yml).

Yoto: Our favourite device for kids

2022-11-07T00:00:00Z

For a long time we were looking for some kind of audio player for our 4 y/o that wasn’t a screen device. Not that we’re totally anti-screen but we wanted something that could be dedicated to playing audio without the distraction of a screen.

Teddie (our daughter) loves listening to stories but so far we've been playing things from our own phones through her headphones, which isn't super convenient. We thought about getting a CD player, maybe even a mini-disc or cassette player. But alas, CD audio books are pretty expensive, and who has a CD writer these days?

Then we stumbled on ✨ Yoto ✨. We got Teddie the Yoto Mini which is a handheld device designed for kids that plays basically any audio content. Besides the huge library of cards you can buy, you can make your own playlists of whatever you want. Yoto devices have a small pixel screen which shows different pixel art for each track on a playlist.

We love it!

There’s a daily kids podcast which Teddie has loved and Yoto radio is so good we just listen to it at home. Also, it turns out there’s tons of kids podcasts out there and Yoto supports podcast feeds.

I’ve been super impressed with it and would recommend it to any parent looking for a modern alternative to their cassette tape player they had growing up.

Remember these??

Also, you can get a 10% discount on your first order using this link! ✨https://prz.io/EDbezxZTK✨

Tips

Here's a running list of useful things I've discovered:

When you’re making your own playlists you can assign pixel icons to each track. Someone made a website where you can find and upload custom icons: https://www.yotoicons.com
For the more technical folks, youtube-dl is a command line tool for downloading whole YouTube playlists. Super useful for fetching content for your Yoto.
Create perfectly sized custom labels for your Make Your Own Yoto cards using self-adhesive labels for your printer. I found these labels that fix perfectly: HERMA 5028 universal labels A4 83.8 x 50.8 mm

Early Mornings

2022-07-30T00:00:00Z

I love early mornings.

I love getting up before everyone else. I’m refreshed, awake, it’s quiet, and I’m alone. (Yes I guess I am an introvert.) There’s a peacefulness of spaces before everyone starts their day.

Fortunately I don’t have a set an alarm because my daughter normally wakes up at 7am. As a result my body has kindly adopted an internal alarm of 6am so I have lots of opportunities to enjoy early mornings.

Summer and spring are obviously lovely times for early mornings. It’s light early, the air is fresh and birds are singing.

In particular I love getting up early while I’m traveling. Hotels have their own peacefulness early in the morning. Staff arrive to get things ready for the breakfast rush. Looking out the window at an unfamiliar city as people begin (or end) their day. Maybe it’s something about catching a normally hectic space at a moment of peacefulness.

In April I went with the Cutr team for an offsite at a hotel in the country side outside Arnhem. Even though I wasn’t being woken up by my daughter my body normally wakes up at 6am regardless, and having a hotel room to myself doesn’t really change that. So I made myself a coffee and sat on a bench outside and enjoyed the morning.

Branch based sessions in Vim

2021-12-23T00:00:00Z

Vim sessions are a great way to save the state of vim so you don’t have to reopen all your files after closing it. I use tpope’s Obsession plugin which ensures a session file is always up to date. But by default this will only setup one session file per project.

I tend to be working on multiple branches at the same time, which means that I’m switching between a few groups of files depending on the branch I’m working on. So I came up with a couple scripts for automatically maintaining a session for each branch.

Creating and opening branch based sessions

My approach relies on tpope’s Obsession plugin. If you don’t have it already, follow the instructions to get it installed: https://github.com/tpope/vim-obsession

Next add this function to your shell configuration file (E.g. Your ~/.bashrc or ~/.zshrc):

vm() {

  # Create .sessions directory if it doesn't exist
  if [[ ! -d './.sessions' ]]; then
    mkdir './.sessions'
  fi

  # Create a session file name based on the current branch
  local session_name=".sessions/$(git rev-parse --abbrev-ref HEAD)-session.vim"

  if [ -e $session_name ]; then
    # If the session file exists open it
    vim -S $session_name
  else
    # Otherwise create it
    vim -c "Obsession $session_name" .
  fi
}

After adding this script reload your shell and the function will be available by running vm.

After changing branches I run vm to either open an existing session for the branch or create a new one.

Cleaning up session files

Ideally we want to clean up our session files when branches are deleted. This script will keep your session files up to date with your current list of locally checked out branches.

#!/usr/bin/env bash
set -e

# Get the root directory of the repository
git_root_dir="$(git rev-parse --show-toplevel 2> /dev/null || echo '.')"

# Get a list of local branches
branches="$(git branch | sed -r 's/\*?\s*(.*?)\s*$/\1/')"

# Get a list existing sessions, trimmed down to the branch name portion of the filename. (This line handles sessions in directories up to 4 levels deep).
sessions="$(find $git_root_dir -maxdepth 4 -wholename '*/.sessions/*-session.vim' | sed 's/.*\.sessions\/\(.*\)-session\.vim/\1/' | sort | uniq)"

# Loop through session names
for session in $sessions ; do
  if [[ "$branches" != *"$session"* ]]; then
    # If session name isn't in the branches list, delete it.
    rm -v `find $git_root_dir -maxdepth 4 -wholename "*/.sessions/$session-session.vim"`
  fi
done

Add this script to a file named git-prune-sessions in a directory in your $PATH. Make it executable by running chmod +x ./git-prune-sessions. Then you can run git prune-sessions to clean out any unused sessions.

Questions? Comments? Post a message below or ping me on twitter.

My email workflow in Fastmail

2021-05-05T00:00:00Z

When I switched to Fastmail from Hey, there were elements of Hey's approach that worked well for me and I wanted to replicate. I found several articles about setting up a Hey workflow with Fastmail, but the suggested setup relied on creating custom rules for each contact and I found this to be cumbersome. I figured out a slightly different approach and wanted to document what I ended up with.

Why Fastmail?

Fastmail came recommended by several friends and has a long history of providing a solid privacy conscious service. Here’s what drew me to Fastmail:

It’s a paid service, which means they don’t need to sell your information to advertisers to make money.
Tracking pixel blocking and image proxying.
Half the price of Hey.
Supports multiple custom domains.
Decent iOS apps.

Check out this more detailed comparison with Hey.

The Workflow

After a little experimentation and playing with the settings, this is the workflow I’m now using with Fastmail:

Receive a new email from an unknown sender. The email lands in the Screener label.
Review the email and then either:
- Block the sender so any future emails go straight to the trash.
- Add the sender to my contacts and then select which contact group it should belong to. “Feed” or “Paper Trail”. If I want to receive notifications I can make the contact a “VIP” contact.
Contacts in the Feed group land in the Feed label. Contacts in the 'Paper Trail' group land in the Paper Trail label. If a contact isn't in either group the email goes to the inbox.

This is working well so far and reflects what I liked about Hey's workflow.

The Setup

The key to this workflow is using contacts and contact groups to filter incoming mail into various labels.

(Fastmail can organise emails using folders (one email, one folder) or labels (one email, many labels). For my purposes I’m using labels. This is configured in Settings -> Preferences under the Labels section.)

1. Feed & Paper Trail

First let's setup the Feed and Paper Trail groups and labels. Of course, you don't have to use these specific groups. If you find it useful to have different or more groups then you have the flexibility to add them.

Go to Contacts and tap + in the sidebar to create a new group. Create two groups called Feed and Paper Trail.
Go to Settings -> Filters & Rules and tap + Create Rule.
Select Sender is a member of group... and select Feed for the condition.
Tap Continue.
Tap Create Rule next to the search box.
In the create rule drop down check the Archive (remove Inbox label) and Add Label. Create a new label called Feed.
Repeat steps 2-6 for Paper Trail.

Once this is setup we can move on to setup the screener.

2. The Screener

Next we'll setup the Screener which will redirect any unknown senders to the Screener label. This is where we can review the emails and decide how we want to handle them in the future.

Go to Settings -> Filters & Rules and tap + Create Rule.
Select Sender is not a contact for the condition.
Tap Continue.
Tap Create Rule next to the search box.
In the create rule drop down check the Archive (remove Inbox label) and Add Label. Create a new label called Screener.

At this point you'll be able to use the workflow I described above. But there are a few extra tweaks I made to improve the overall experience.

3. Extras

Recycling old emails

For the Feed label I setup 'Auto Purging'. This means that emails with this label that are older than 31 days will be deleted. In Hey this is configured in the 'Recycling Center'.

Go to Settings -> Labels and tap Edit on the label you want to setup auto-purging for.
Tap Show advanced preferences.
Check the option for Auto-purge and set the purge time to what ever you prefer.

Cleaner sidebar

By default the sidebar will include the usual list of folders (Inbox, All Mail, Sent, Spam, etc). I wanted a simplified sidebar with only what was important. Fortunately this is configurable in Fastmail via Settings -> Labels. You can configure labels to always be hidden, always show, or hide when empty.

In my sidebar I now have:

Inbox - always show.
Screener - hide when empty.
Paper Trail - always show.
Feed - always show.

You can still navigate to other labels/folders by tapping Find at the bottom of the sidebar.

Notifications

I wanted to only receive emails from specific senders so that I’m not constantly receiving notifications for unimportant messages.

To do this I configure the Fastmail apps to only send notifications for VIP contacts. Then for the senders I want notifications from, I set them as VIP contacts.

Reply Later & Aside

I'm still figuring out the best approach for Hey's Reply Later and Aside feature. For now I use pinned messages as an alternative to Aside, and I use a label for Reply Later.

Missing features in Fastmail

While I managed to replicate the core functionality of Hey in Fastmail, there are a couple UX things I miss from Hey that I'd love to see in Fastmail one day.

Feed view

In Hey, emails in the Feed are rendered in place making it feel more like, well, a feed. This allowed you to casually scroll through newsletters without having to open individual emails.

Thread notifications

While you can mark individual contacts as VIP and get notifications from them in Fastmail, you can't get notifications for specific threads. This would allow you to follow a specific email chain without having to receive notifications for all messages from a sender.

Contact avatars in email list

Several email apps, including Hey, will show a contact's avatar next to messages in email lists. As someone who works better with visual prompts (rather than pure text) this worked well to help me distinguish between different types of emails, particularly in the Paper Trail.

Conclusion

Hey did a lot of things right and gave me a starting point for an email workflow that's a lot better than the inbox firehose of emails, or "smart" email sorting as seen in Gmail. Setting this up in Fastmail required a bit of work, and screening emails is not quite as fluid as in Hey, but it works well for me. Fastmail also offers much more flexibility to evolve your email workflow to suit you.

I'd love to hear how other folks like to optimize their email workflow. Comment below or shoot me a message via email or twitter.

If you like the look of Fastmail and want to try it out, please use this referral link to receive a 10% discount.

End-to-end testing (WIP)

2021-04-05T00:00:00Z

Delivering a working software product to end users is not a trivial task and there are a lot of things that can go wrong along the way. The end user experience of your product is not just made up of the code that your team writes. It’s also 3rd party software, deployment processes, configuration, servers, operating systems, databases, networks, caching systems, and much more. Each of these components can and have gone wrong.

End to end (e2e) testing is a powerful tool to help reduce the uncertainty of delivering and maintaining a functional product. But e2e testing has a lot of pitfalls and isn’t a silver bullet.

What is end-to-end testing?

An end-to-end test is one that tests your whole technology stack. From the client (such as a browser), to server, to database, and back. The goal is to test all the components of your product in the same way that your end users use it, as one unified system.

The client can also be a simple http request in the case of a REST API e2e test. But for the purposes of this post I’m mostly going to talk about browser based e2e testing.

Test regularly

Just because it was working 2 hours ago, doesn’t mean it’s working now.

Focus your tests

E2e tests are flakey and expensive. Focus on what really matters.

Balance with monitoring and other testing

Unit testing. Integration testing. Production monitoring.

Field recording

2021-02-01T00:00:00Z

Sound has a way of transporting me to a moment or a space in a way that an image can't.

Over the last few years I've recorded little moments in various spaces. There was something about the sound landscape in those spaces that captured my experience more vividly than a picture or video.

Here are a few of my favourites:

More field recordings

My box of mistakes

2021-01-27T00:00:00Z

I got myself a 3d printer and I am hooked. I'm hoping to post about some of my projects and learnings soon.

But first I wanted to share this picture of my little box of 3d printing mistakes.

Some are mistakes, some are prototypes, but all of them represent little moments of learning. For each thing in this box I learned something new, which is why I started keeping them rather than throwing them away.

This got me thinking a bit about mistakes I make every day, at work, at home, with people. Some big mistakes I've made in the past that I still cringe at. What if I thought about these like I think about this box of 3d printed pieces? Rather than a mistake representing how I messed up, I could think of them as moments where I learned something.

There's a Thomas Edison quote that seems appropriate for this train of thought:

I have not failed. I've just found 10,000 ways that won't work.

Some of my projects

2021-01-21T00:00:00Z

Here are a few of the projects I've built. Some are alright. 😛

Gifable

Gifable is a gif/meme library manager. I enjoy throwing the odd gif reaction around so I like having them easy to search and post. So I built Gifable. Check it out at www.gifable.club.

Git get

Keep your cloned repos nice and neat in a go get esk directory tree. Read more here: How I organize my cloned git projects.

Hint

A command line tool to help you remember those little nuggets of knowledge.

Secrets

CLI for setting and getting secrets using MacOS's keychain.

Dotfiles

These are my dotfiles. There are many like them. But these are mine.

I live in the command line with zsh and vim. There's some good stuff here, some bad stuff, don't judge.

Customised PiBow case for Raspberry Pi + PiJuice + PiTFT

2020-12-27T00:00:00Z

I recently setup a PiHole for my home network. I’m using a Raspberry Pi 3B+ with a PiJuice and a 3.5 inch PiTFT screen. Finding a case to fit all these was a little tricky. I don’t have a 3D printer (yet) and the tall cases I could find were a bit ugly.

I ended up using a PiBow case designed for PiTFT and made a couple modifications to get it to work with the PiJuice. I’m pretty happy with the result and wanted to share it.

What I used

Links are to where I purchased.

Raspberry Pi 3b
PiJuice
PiTFT 3.5”
PiBow PiTFT+ case
PiBow Lego base (optional)
3x PiBow expansion layers
Longer PiBow screws
Some M2.5 washers, standoffs, and screws

The build

Before starting, be sure to remove the protective film from each of the layers of the PiBow. I put this all together with the film attached and had to redo the whole thing. 🤦 Fortunately this gave me the opportunity to take photos of the process.

Here’s the mess of stuff I started with.

Mount the PiJuice on the raspberry pi with Layer 3 of the PiBow in-between. Use the nylon standoffs and screws that come with the PiJuice.

Turn the Pi over and use 5mm stand offs to secure the PiJuice to the Raspberry Pi.

On the PiBow layers you’ll see numbers etched on the tops. Add layers 2, 1, and the base. I have the Lego PiBow base but the regular base will work too. Be careful to put the Lego base the right way up or it won’t work.

Secure the base using the extended PiBow bolts in the corners and use M2.5 screws going into the standoffs to secure the Raspberry Pi and PiJuice.

Rather than using layers 4, 5, 6, and 7 that come with the PiBow kit, we’ll use 4 nylon washers on each corner bolt. Because of the buttons and power socket on the PiJuice I couldn’t use the standard PiBow layers that normally surround the Raspberry Pi HDMI and power ports.

Now add layer 7 and three clear expansion layers. These layers will surround the PiTFT.

For the PiTFT to fit on top of the PiJuice I had to carefully clip the 26 pins on the back of the screen.

Finally I used layer 9 and secured it all using the nylon bolts.

Done!

That’s it! Pretty good looking if I say so myself. :) Especially running with no cables and PADD on the display.

Here’s the PiHole running. To mount the Pi I attached a flat piece of Lego to the wall in my utility closet using some removable adhesive strips.

I may find some slightly longer bolts in the future because I’d like to add the last clear layer included in the PiBow kit. The extended bolts weren’t quite long enough.

Questions? Comments? Post a message below or ping me on twitter.

Rethinking my piece of the internet

2020-07-02T00:00:00Z

I am a strong proponent of people owning their own personal space on the internet. A space where they can express their interests and who they are as they see fit. (And preferably not owned by a social media giant.) But as a person who builds things on the internet for their profession, it’s easy to feel that my website should be a professional brand website for Piet the developer.

I’ve started various more personal projects but I kept them separate from this site, to keep it as my professional website. For a long time, I’ve struggled with this balance. On the one hand, I would love to represent myself better and be a little more personal and human. On the other hand, I feel pressure to maintain a professional brand.

I read an article recently that inspired me to rethink what content I produce for this space. The article was about how the ‘attention economy’ of social media platforms (Instagram in particular in this case), have forced artists to build a brand for their art that is tailored to be easily and quickly digestible. The author challenged artists not to lose their human side while building their professional brand. This paragraph caught my attention in particular:

When the system tries to hack you, why not try to hack it back? Rather than obtaining the perfect surface of your professional selfie, here it might be interesting to turn yourself into a more human creature again. Art has been full of those stories showing alternative ways, and while we adore these stories from the past we do tend more and more to annihilate those stories when they’re happening around us. […] Our ideas of professionalism have become distorted, as it only presents a surface of boxes that are checked to give an easy read.

~ Monika Senz. “(Your) Attention Please!” Pfeil Magazine #12, 33-34

This particularly resonated with me and my struggle to balance the professional and personal. Inspired by this, I am challenging myself to reclaim my space. Let it be me with all my interests and not just the developer’s brochure! I have interests in aircraft, running, keyboards, and making the odd field recording, to name a few.

My plan is to post a broader range of content along these lines that I feel better represents me. Hopefully, this means I actually produce some content more than a couple of times a year. Wish me luck!

More soon.

Focus on the problem

2019-12-01T00:00:00Z

Way too often I find myself thinking, 'Oh I should setup this super complicated solution to a problem that maybe one day, in an apocalypse, I might encounter.'

Example: My local Dropbox backup. For some reason I've had it in my head that I need a backup of my Dropbox files on a locally accessible hard drive. The solution I've tried to implement several times is a raspberry pi setup in a cupboard that runs rclone and syncs my dropbox to an external hard drive. It was kind of fun to setup once. But the maintenance was a little frustrating and the solution was fairly unreliable.

I keep thinking, 'I need to setup that up again'. Because why?? Dropbox might collapse and loose all my stuff?? Fairly unlikely.

Anyway, this is a post to persuade myself that I really don't need to solve this problem and should focus on the dozen other hobby projects I've wanted to work on. Such as my shitty game written in Lua that I'm way too proud of already, Spacecaret. 🚀

Things I wish I knew before my daughter was born

2019-11-29T00:00:00Z

https://twitter.com/brianmwang/status/1199748365103161344?s=21

There's no right way to feel when your baby is born

When my daughter was born I was so emotionally overwhelmed after a difficult birth. You hear so many stories about people “falling in love as soon as they held their new child”. I expected that, and when I didn’t feel that immediately it made me feel like I was a bad parent, in the first moment of holding my child!

You are the professional

You are the professionals of your own child.

This is something our homecare nurse told us when our daughter was born and it always stuck with me.

People have all sorts of opinions about bringing up kids. People can give advice, but you know your child the best out of everyone in the world. Trust that first.

The baby phase is only about 6 months

Most of what you're learning before your kid is born is how to look after an infant. That phase goes by so quickly. After 6 months you have a crawling tiny human with many opinions.

Martín's Triathlon

2019-09-22T00:00:00Z

On a surprisingly warm September Sunday morning I went to support my friend Martín doing a triathlon. I’m only just getting to the point where I can run a 5k, let alone a 750m swim, a 20km cycle plus a 5k. Martín and I went running together once. At the end of the 30 minute run he hadn't broken a sweat. Whereas I came home drenched. Suffice it to say, Martín is an athlete and I (currently) am not.

I captured some sounds from a spot about 10 meters before the finish line. The beep you can hear is the moment a runner crosses the finish line.

The first part is the best audio I caught of runners passing by. The second part is the moment Martín completed his triathlon. You can hear his wife and me cheering him on.

Summer Storm

2019-08-31T00:00:00Z

The summer we moved to the Netherlands the was lovely. As we were settling into our new lives we got to enjoy some beautiful sunny days. The evenings, however, were different. With all the heat and humidity came these amazing lightening storms.

It was still 25+ degrees centigrade but outside it was pouring. We loved it. We would lay on our bed with the window open, listening to the rain, watching the flashes, and waiting for the noise.

Last month we were away for the weekend at a vacation house. After a full day escaping the heat at the swimming pool, we settled into our quiet evening. It began to pour outside, and with it came the thunder and lightening.

Headphones on and volume up for the full effect.

Polderbaan

2019-08-02T00:00:00Z

I recently took a flight from Amsterdam to London. The flight time is only 40 minutes, but before that there's a 20 minute taxi from the terminal to the runway. You cross a motorway and a canal to get this runway. It's in the middle of a field far from any buildings besides a small control tower. This runway is the Polderbaan.

Right next to the Polderbaan there's a carpark that's a really nice spot to watch (and hear) the planes landing or taking off. I finally took Teddie there to watch the planes. We got there and Teddie was more interested in playing in the car or running around the carpark, which was fine.

I got this recording of a Boeing 747 landing. As it's passing the recorder it kicks in the reverse thrust. Teddie held on to my legs as the noise went by.

P.S. This is also the first post using my new Zoom H1n recorder. Enjoy!

Ten years

2019-07-23T00:00:00Z

On this day in 2009 Keven and I met a small group of friends and family at the McMenameins Edgefield Hotel in Oregon. We gathered together in a shady part of the gardens and said a few words.

My brother brought his camcorder. He recorded everything for my mum who couldn't make it half way across the world with only two weeks notice.

We could hear children playing and people enjoying their drinks at the outdoor bar nearby. It wasn't the most private cerimony, but it was a space for us.

Less Ordinary

2019-06-21T00:00:00Z

I recently rediscovered this old recording I made in February 2006.

I was visiting my mum and step-dad in Minehead in the UK. I brought my guitar and my 2006 white MacBook with me. I'd been playing around with a song for a while and decided to put a recording together.

I layered about 5 guitar pieces together, all recorded using the MacBook microphone. At one point you can hear the fan from the laptop kick in.

The song is called Less Ordinary, I have no idea why. Maybe I got it from the film Life Less Ordinary. I might have liked that film at the time.

I remember pretty distinctly listening to Sleater-Kinney's The Woods for the first time on this trip. My song is nothing like Sleater-Kinney, but somehow these two things are related in my memory.

Mama!

2019-06-07T00:00:00Z

Dinner time Teddie noises.

7 reasons not to skip the tests

2018-12-05T00:00:00Z

We've all been tempted to skip writing the tests. Whether it's time pressure, business pressure, the complexity of testing, or we just want to get on with something else. We might be tempted to say "YOLO!" and move on. So here's a list of reasons why you might want to think twice before doing that.

The Reasons

There are 7 of them, I counted. Why 7? That's how many I thought of. I may add more.

Feature security

Making changes to existing programs is risky. You and your team have spent a lot of time and hard work getting it to where it is. Are you confident that if you implement a new feature you won't break an existing one? Tests give you this confidence.

If you think you have confidence in your code without tests, then I would ask you to prove it. If you start poking around the program, triggering various behaviour, I'm pretty sure we could be sat around most of the day validating edge cases. This is not easily repeatable proof.

With good test coverage, you can run one command to quickly validate that your changes have not broken any tested behaviour.

They're not just tests, they're documentation

Well structured tests with good descriptions provide a clear picture of expected behaviour. Including how the program should and shouldn't be used. If you come across a piece of code and don't understand it's purpose, try this: Make some changes, run the tests and see what failed. The failing test should tell you about the expected behaviour of that code.

Viewing tests as documentation is also a great way to get to know how a program works. This is particularly useful if you're new to a code base. Also if you're on-boarding new people, walking through the tests is a great way to help them get familiar with a project.

Obviously, if you skip writing the tests you loose this valuable resource.

Testing makes you faster

Despite common misconceptions, sticking to the tests makes you ship value faster. This works in two ways:

First, with a well tested code base you can massively reduce the amount of time code spelunking. This is where you go from line to line, debugging, reading, and figuring out what some piece of code does. The tests give you picture of what the program is doing in a fraction of the time. You still need to do code reading, but the tests provide an invaluable companion to understanding what code is doing.

The second way tests make you ship value faster, is by vastly reducing the number of bugs you're shipping. Bugs are a debt against your time and the features you want to build. Bugs take your time away from shipping value, and they are a drain on the value of what you're shipping. If users want x feature, but they end up y, and z bug too, the value of x is going to be reduced.

Tests are automatable, you are not

The time a person spends running one off commands, or clicking around a screen to validate behaviour, is lost time. Wouldn't you rather spend this time actually writing features? These things are not automatable. Tests, on the other hand, can be configured to run as a part of your continuous integration processes. You create a pull request and tests run automatically, and your whole team can see the results. Manually validating code for all your team is laborious, and not easily repeatable, so the time is wasted.

That's not to say that all manual testing is wasted time. Some is necessary. But manual testing that could be easily automated, is time wasted. And when you'd rather be shipping value, time is your one of your most important resource.

Green just looks good

Ok, this is a rather subjective point but... Green looks and feels good. Seeing that beautiful green band streak across the screen is just lovely. The confidence, the speed, the ease. Ugh. I love it.

You probably won't go back and do them later

"How about we ship it now and write the tests later." If you've ever said or heard this before, I challenge you to find out if those tests were ever written. If you're lucky there's a tech-debt ticket floating around that no-one really wants to work on. Once code hits the master branch, the expectation, the motivation, and the incentive to write those tests all but disappear.

Even for someone who has experience writing tests, writing tests after merging is much harder than when you're actually working on the feature. When you're working on a feature, your mind is centered around the problem you're trying to solve. In that state it's much easier to think about what tests you need to write. Once you've moved onto another problem, remembering everything about that old one will be a struggle.

Your later self (or a colleague) will appreciate it

Imagine this.

You settle down to add a new feature. Your good self (or a colleague) has left a nicely structured test suite documenting the behaviour of this program you need to modify. You add new tests, make your changes, fix some things you broke, and submit your PR. You feel confident about your newly added functionality. You feel good that you didn't break any existing behaviour. The process went quite smoothly.

It can be this blissful. Not all the time. Shit can hit the fan in a myriad of ways with software. But it can be blissful. Either way, consider the alternative.

You settle down to add a new feature. There are some tests. But it turns out there are tests missing for some of the behaviour. What do you do? If you implement your feature you may unknowingly break some untested feature. So, you have to first put your new feature on hold, find out what logic is not tested, then reverse engineer tests for it. But you're not working on your feature! You're doing someone else's work for them. That's no fun.

Do your future self (or colleague) a favour and keep a program tested. And with that, be sure to thank your past self (or colleague) for leaving a nicely tested program.

Caveats and tips

These reasons are all well and good. But we don't live in a perfect code base. Here are some notes and tips on keeping the tests while living in an imperfect world.

Caveat: Good coverage

Good coverage is a life saver. Obviously if you're starting from an existing code base with little or no tests you're going to have a harder time writing tests. But I strongly encourage you and your team to set the standard that any new code is tested. As the test coverage grows, so will your confidence, and ability to ship value quickly.

Caveat: Testing is a skill

Unfortunately writing good tests is a skill learned with experience. If you're not comfortable writing tests or are having a hard time figuring out how to test a program, then this is the perfect time for pairing. Find that person that enjoys testing (they do exist), and ask them to help you. You may find that their enjoyment of testing rubs off on you. You never know.

Tip: What (not) to test

Not everything is worth testing. But a lot is. I don't believe in 100% coverage. Most apps have a lot of startup logic and configuration that isn't worth testing, because without it the app just won't start.

My golden rule for what to test is, 'if it makes a decision, test it'. I guess you could add to that, 'unless it kill's the app on start'.

Caveat/Tip: Perseverance

Stick at it, especially if you're adding tests to an existing code base. Coverage reports in CI builds (such as Coveralls) can be a great motivator. Make the coverage public, put it on a dashboard, and watch it go up!

Conclusions

Forfeiting tests in the name of shipping faster is deceivingly harmful to your productivity. Be vary wary if you're being asked by colleges to skip test writing to save time. Ultimately it is slower and it will hurt your team. Find other ways to save time if deadlines are an issue, such as reducing the scope of the feature. But making testing a integral part of your workflow will benefit you, your future self, and anyone else who touches that code.

Happy testing!

Minsk Tunnel

2018-10-29T00:00:00Z

I was in Minsk for work. On my walk back to the hotel I could hear singing coming from one of the pedestrian tunnels going under the main road. I took a diversion and recorded as I walked through the tunnel.

How I organize my cloned git projects

2018-05-31T00:00:00Z

For a while I've been looking for a better way to organize the git repos I work with. I've tried just dumping them into a single directory, and I've tried adding sub folders such as personal, work, and tools. But both of these solutions had the same problems:

Repos that I clone to play around with cause clutter alongside projects I'm actively working on.
Cloning forked repos along with the original repos cause folder name conflicts. Meaning I would have to use a different a folder name to the project name, which might cause confusion when working on a project.
It's unclear who owns what without going to the cloned repo and running git remote -v.

I figured there's probably a better way.

Enter Go

I really like the way that Go organizes source code. The command go get <git-url> installs packages to $GOPATH/src. ($GOPATH defaults to $HOME/go in Unix systems.) From there, repos are organized in directories by git host, user name, and repo name. For example, go get github.com/pietvanzoen/pietvanzoen.com would clone the project into $GO_PATH/src/github.com/pietvanzoen/pietvanzoen.com. This gives you several benefits:

You avoid folder naming conflicts.
It's clear where a repo came from.
Your work/personal projects are automatically grouped.
Source code is organized in a consistent and easy-to-understand way.

But I don't work with Go

I occasionally work with Go, but I mostly work with JavaScript. Initially I thought I could just co-opt the go get command and organize my non-Go projects alongside the handful of Go projects I work with. But Go recognizes that a project isn't Go and prints a warning message. Apart from the warning message, I didn't feel comfortable co-opting Go functionality to organize folders unrelated to Go. It's not what the tool is intended for and there's no guarantee it won't break later on.

The Solution... `git get`

So... I came up with git get. It's just a single Python script that parses the given git url, creates the directory structure, and clones the repo into the created directory. I define a $GIT_PATH to store all my repos in (I chose ~/repos). Then I can run git get git@github.com:pietvanzoen/dotfiles.git, which clones my dotfiles into ~/repos/github.com/pietvanzoen/dotfiles. Also, git get can be run from any directory.

So now my projects look a bit like this:

~/repos
├── bitbucket.org
│   └── pietvanzoen
│       └── wibble
├── github.com
│   ├── LeidenDevs
│   │   └── leidendevs
│   ├── chriso
│   │   └── validator.js
│   ├── pietvanzoen
│   │   ├── discussie
│   │   ├── dotfiles
│   │   ├── pietvanzoen.com
│   │   └── validator.js
│   └── wting
│       └── autojump
└── gitlab.com
    └── pietvanzoen
        └── wibble

You can see I've cloned validator.js twice. One is the original project by github user chriso, and the other is my fork. With the single level folder structure I used before I would have to name the clone folder for one of those projects to something else.

But that's a lot of directories to navigate

One drawback to this approach is that we now have a lot of directories to navigate. Depending on your patience, this may or may not be an issue to you. If it is an issue, I really like using autojump. The autojump command (bound to j for brevity) builds an index of commonly visited directories. After visiting a directory for the first time, you can then run j <partial-dir-name> and you'll be taken to the first match in the autojump index. E.g j dot will take me to ~/repos/github.com/pietvanzoen/dotfiles.

Conclusion

I've been using this new directory structure for about a month and I love it. It feels clean and organized and I don't worry about where I'm cloning repos into. Check out the git-get source code and try it out. If you have ideas for improvement please submit an issue.

Heartbeats

2017-07-05T00:00:00Z

A happy heartbeat.

My top 3 lessons from JSConfEU 2017

2017-05-18T00:00:00Z

Our front end team at Usabilla had the amazing opportunity to attend JSConf EU in Berlin this year. It was a fantastic experience for us all and we came home having learned a ton. This is just a summary of my key take-aways from the conference.

Your site can (and should) be accessible

Whenever we think about accessibility on the web we tend to just think of providing access to people with disabilities. Laura Carvajal from FT.com suggests we reframe this idea:

"Beyond not deneying access, it's ensuring that access is fair for everyone."

There are a plethora of ways that people end up having trouble using the web, be it temporary or permanent. Our job is to build the web in a way enables access for all our users, and not just those that engage with the web the same way we do.

15% of the global population have some form of disability. After research FT.com found that 26% of their users had some form of disability. Depending on your demographics, you might find that a large segment of your user base are using tools (such as screen readers) that you do not test for or support.

So how do we work towards ensuring fair access for all our users? Here are some suggestions Laura offered:

Install pa11y

pa11ly is a great way to ensure your site is WCAG compliment. Make pa11y a part of your build process and have your build fail when there are issues.

Get an Accessibility Audit

Ensuring WCAG compliance only covers about 35% of accessibility issues. Accessibility audits provided by organisations like Digital Accessibility Centre put your app/site in front of people who face various accessibility issues. Laura showed an enlightening video from people testing FT.com, which highlighted the diverse range of issues people face with modern websites. There's no way you can anticipate all these issues, so putting your site in front of real people is a great way to gain insight.

Ditch the Mouse

Many internet users only use a keyboard to interact with the web. To really understand what these users experience Laura and her team got rid of their mice and went keyboard only. Check out Laura's talk slides for tons of tips for going keyboard only.

Relevant Links:

Getting out of our performance bubble

I'm gonna go ahead and say that Ben Schwarzx from Calibre has coined the phrase "Wealthy Western Web" to describe the web that most of us develop in.
We work on €2000+ computers on 100+ Mbit/s fiber. Even on mobile we're often working with high-end devices on 20 Mbit/s LTE connections. The World Wide Web is a very different place. The average device is about 5x slower than our laptops and 60% of the world are on 2g mobile data connections.

There are a number of ways to start testing the performance of our apps against devices that most people use. Calibre's platform and Google Lighthouse provide people-centric metrics for web app performance. Specifically Time to First Interaction is a much better metric for app performance than something like page load time because it considers the time it takes for the device to parse the application and render it to a point that it's usable. A 410kb gzipped bundle is nice and small to download but once uncompressed the device has to handle 3-4 megabytes of code.

There were lots of talks about performance optimisation at JSConf. But without metrics to judge against you have no idea how effective your optimisations are and if you're optimising the right thing. I'm really looking forward to giving Calibre a shot after chatting with Ben.

Relevant Links:

A new bar for conferences

JSConfEU was the best conference I have ever attended. First off, it achieved everything you would want from any conference. Amazing speakers, amazing topics, amazing community, amazing execution. The venue was beautiful, the day to day flow of things was almost flawless, the food was fantastic and they managed to serve 900+ people within 20 minutes for breakfast, lunch, and dinner.

But wait there's more.

The speakers were 50/50 men/women. Not all white. All food was vegetarian friendly, vegan friendly, and high quality. (I'm neither vegetarian or vegan but loved the food.) They provided childcare, an inclusive photo policy, live transcription, gender neutral restrooms, gender identity badges, scholarships, and drinks in glass bottles over plastic.

JSConfEU as an excellent example of what a conference should look like. Diverse, inclusive, and shamelessly advocating for those things.

Relevant Links:

JSConfEU 2017 Speaker line-up
Organisers:

Final Words (not really)

Building tools and events that are accessible to all people is achievable if you prioritise it. And you should because it's just the right thing to do, and if you need another reason, you should because it benefits everyone.

Making code performant for the average device improves performance on all devices. Making apps work for all platforms (browsers, screen readers, keyboards) results in a better user experience for all. Continuously striving to provide spaces (physical or digital) accessible to all people make your communities more cohesive and wiser.

The talks and the conference itself were an eye opening example of what events and the web could and should be, and it's an awesome picture. There are lots of hard problems to solve, but that's what we as developers signed up for, to solve hard problems. So let's do it.

Final Final Words… Thank you

First, thanks to all the organisers and speakers at JSConf for putting on a terrific and inspiring event.

I also want to thank Usabilla for giving us the opportunity to attend. The company paid for our flights, accommodation, and the conference fees. I'm well aware that without a company that prioritises all the points above I probably would not have been able to attend.

Last, thanks to all my team mates for making the weekend in Berlin a blast. 😬

Paris Metro

2017-05-17T00:00:00Z

French accordion player on the Paris metro.

Paris Market

2017-05-16T00:00:00Z

Strolling through a Parisian market with my wife and mother-in-law. French, and ambulances, and squid, oh my!

Windmolens Harp

2017-05-13T00:00:00Z

On national windmill day we came across an art performance in a field by a windmill. It was a mix of ambient audio coming from speakers attached to the sails of the windmill accompanied by a harp and poetry recitals.

This is a short recording from that performance.

Automated middleman deploy to Github pages

2017-02-27T00:00:00Z

I recently switched from Jekyll to Middleman for my personal website. After using Middleman for a couple projects I felt that Middleman was much easier to setup and manage than Jekyll, also I really don’t like liquid templating. The one thing I missed from Jekyll was automated deploys to Github pages. It wasn’t very difficult but you have to jump through a few hoops. Since I’m running my own build I decided to add some tests for my static site too. So here’s the how-to.

Testing setup

I wanted to add some basic testing for my site, simple things like HTML validation and link checking. For that I found HTMLProofer which can run a variety of tests against a folder of html files.

Add HTMLProofer to your Gemfile and bundle install:

gem 'html-proofer'

HTMLProofer can run via command line, but for ease of running locally and remotely with all of my configuration I chucked it in a test.rb and included a simple check for the build folder.

# test.rb

require 'html-proofer'

raise IOError, 'Directory ./build does not exist. Run `middleman build` before running tests' unless Dir.exists?('./build')

HTMLProofer.check_directory('./build', {
  :check_img_http => true,
  :check_html => true, :validation => { :report_missing_names => true },
  :check_favicon => true,
  :check_opengraph => true,
  :http_status_ignore => [0,999,403,401]
}).run
# Check out the config docs for more: https://github.com/gjtorikian/html-proofer#configuration

If you’re already using a Rakefile you could add the HTMLProofer code to a :test task. This test was going to be the only task in my Rakefile so I decided to stick with a plain old .rb file I could run.

Run ruby test.rb and you should see something like this:

Running ["ImageCheck", "FaviconCheck", "ScriptCheck", "OpenGraphCheck", "HtmlCheck", "LinkCheck"] on ["./build"] on *.html...

Checking 62 external links...
Ran on 13 files!

The first time I ran this I discovered a handful of links that were either just wrong or had gone stale over time. Nice to know these will be caught in advance moving forward!

Deploy configuration

The middleman-deploy gem has what you need to “deploy” your site to git. Basically what that means is that middleman will build your site, copy the files to an orphan branch, commit the changes and push. By default middleman deploys to the gh-pages branch for sites using Github pages.

Add the gem to your Gemfile and bundle install. To work with middleman v4 I had to install the pre-alpha gem. This hasn’t been a problem for what I need so far.

gem 'middleman-deploy', '~> 2.0.0.pre.alpha'

Then in your config.rb add your deploy setup:

activate :deploy do |deploy|
  deploy.deploy_method = :git
  deploy.branch = 'gh-pages'
end

Make sure the whole process works by running middleman build && ruby test.rb && middleman deploy.

CircleCI configuration

I’m using CircleCI for my build platform, but the configuration should be fairly similar for other platforms.

Add the following to your circle.yml in the root of your repo:

# circle.yml

compile:
  override:
    - bundle exec middleman build

test:
  override:
    - bundle exec ruby test.rb

deployment:
  build:
    branch: master
    commands:
      - git config user.email $GIT_USER_EMAIL
      - git config user.name $GIT_USER_NAME
      - bundle exec middleman deploy

For each build, this will compile the site, run the tests, and for builds on your master branch it will run the deploy. You’ll need to configure your git details too. For ease of configuration I’m using env vars for my git user config. Head to https://circleci.com/gh/you/test-repo/edit#env-vars to add your github info.

Git write access for the build

Next you need to configure CircleCI to have write access to the repo. By default Circle only has read access to the repo. Instructions for setting up a read/write deploy key are in the circle docs, but here’s the break down.

Generate a new SSH key

First we’ll need to create a new SSH key for Circle:

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key: /Users/<you>/.ssh/circleci_deploy_key
Enter passphrase (empty for no passphrase):

Give a location for your new ssh key and do not enter a passphrase, just hit return.

Add the public key to CircleCI

Copy the public version of your new new SSH key:

cat ~/.ssh/circle_deploy_key.pub | pbcopy

Go to https://circleci.com/gh/you/test-repo/edit#ssh and add the public key that you just created. Use github.com in the Hostname field.

Add the private key to Github

Next head to your repo in GitHub and add the private key to our repo.

cat ~/.ssh/circle_deploy_key | pbcopy

Go to https://github.com/you/test-repo/settings/keys on GitHub and add the public key that you just created and copied. Make sure to “Allow write access” and save the key.

Deploy!

That should be everything you need to run the build. Here’s an example build from my site.

You should now be able to simply push changes to your master branch and have the site automatically update, plus if there are any broken links your build will fail and the deploy won’t happen. 🎉 Enjoy!

Moving On: What I learned at Cozy

2016-07-08T00:00:00Z

Today is my last day at Cozy. 😢 My wife and I are flying to the Netherlands to start a new adventure close to my Dutch family. I started at Cozy in January 2014 as a front-end engineer. I have an agency background, and after spending several years working on client websites, I was excited to have a chance to do something different — to work on one product with a cool team.

I can’t possibly write about all the things I learned while I was at Cozy; I’m trying to keep this short. But here are the things that stand out when I think about what I know now versus what I knew then:

Process is fluid

One of my favorite things about working at Cozy is that we allowed our processes to evolve as our team and company evolved. No methodology is one-size-fits-all. In fact, most methods for organizing and prioritizing work don’t match any team perfectly. So, rather than sticking to a process that didn’t fit us, we developed our process to fit our needs as we grew. Try, tweak, repeat.

Teams are like family

Sometimes you disagree. Sometimes you have arguments. And sometimes you’re wrong. But that’s all OK. Tensions happen, but the end of the day you’re still a team and you still have the same goal. Then you can drink beer together.

Choice of work fosters ownership

At Cozy, engineers often have the opportunity to choose what to work on next. For me, this fostered a sense of ownership of my work. And with ownership comes pride, not just after the fact, but during the process of pushing yourself to produce excellent work.

Always be learning

During my first year at Cozy, I was constantly learning and being exposed to new ideas and concepts I hadn’t encountered before. I learned by just doing my job. But eventually that passive learning started to taper off.
At that point, I started reading technical books and articles during my bus ride to work. Those 20 minutes of reading each morning helped broaden my ideas about the work I was doing at Cozy, while making me a more well-rounded engineer.

Fight with the tech you have…

…not the tech you want. New ways to build a product can be shiny and exciting. But often enough, you have existing code that’s doing a good job. There’s no need to replace it wholesale when what you have fits your needs. If the way you’re building your product seems like it isn’t working in some way, try to evolve and improve it before throwing everything out. There’s a lot of value in something your team knows how to use, something that’s worked in the past.

I’m super excited for the new adventure ahead of me, but I’m sad to be leaving Cozy. My time at Cozy has been formative, and it’s been my absolute pleasure to work with such an amazing group of people. I’m gonna miss them. 👋 😢

Originally posted on Cozy.co.

Why I love test-first TDD

2016-06-10T00:00:00Z

Twelve months ago I had hardly written a single test. After some encouragement and guidance on how to write tests my world changed. Yes, there's lots of evidence that says writing tests reduces bug density (which is awesome), but that alone isn't necessarily going to persuade you to take the time to do them. What made me adopt a workflow where I write tests first? The fact that I enjoyed it!

Preface: I'm not going to cover how to test in this post. Just why I love it. But how you test and tooling for testing makes a big difference on the fun factor. My quick recommendation is checking out Wallaby.js. I'll try to do a post on TDD tooling and workflow in the future, or just find some more useful links.

What makes test-first TDD fun?

Immediate feedback

My old process involved a lot of leg work, and a lot of fumbling around in the dark. I would write some code, add some console logging, switch contexts to my browser, refresh, read and mentally parse what it returns, rinse, repeat.

Using a test runner that immediately runs your tests after each change is a glorious alternative. Write some code, test fails, adjust code, test passes, success! I don't even have to read what the code returns, all I need to worry about is green verses red. Pass vs fail. Not only am I getting faster feedback, but I'm also reducing the cognitive load. I'm not changing contexts, I'm not interpreting what the code returns, I just want it to pass.

Confidence in code

Before I used TDD extensively I would end up with some code that I was somewhat confident in. I would have thought about possible edge cases and tried to account for them. It felt okay shipping the code but there was always an element of trepidation.

It would be unwise to think that TDD gives you 100% bug free code. As Rich Hickey said in a talk once, "What do all production bugs have in common? They passed the tests." But, for me, I feel way better about my code when it's tested. In particular, it's way easier to account for edge cases. Once you have your happy path tests in place, you can add edge case tests and implement the code. Provided all the tests pass, you can be confident that adjusting the code for edge cases isn't going to break the primary function of you code.

Easy refactoring

Another wonderful benefit to TDD is how much easier it is to refactor code when you have a solid set of tests to work with. Feel like some code could be optimized? Refactor without fear! Testing makes it super easy to go back after the fact and make your tests more readable, more DRY, and more maintainable.

But wait there's more! For me the real benefit of easy refactoring comes when you know this before you begin. Your first version of a piece of code does not have to be perfect, it just needs to make the tests pass. Once your tests pass and you can go back and make it pretty and optimize it to your heart's delight. The point being, you don't have to waste cognitive power figuring out how all this behaviour is going to fit together for your first version of a piece of code. Do your worst! Then make it awesome when tests are green.

Conclusion

What I hope you get from this is that test-first TDD doesn't have to be a slog. It doesn't have to be additional work you have to do when you could have been done 20 minutes ago. I believe it can be enjoyable to everyone and that it can be a huge benefit to your work flow.

If you still think writing tests is a slog but you haven't ever tried test-first development then I strongly recommend at least giving it a go. I really enjoy TDD, but I find writing the tests after the fact pretty unbearable. Challenge yourself to do testing first for a couple weeks and let me know how it goes!

I'd love to hear about your experience with TDD. What do you like/dislike about it? What tools do you find most useful? I'm @pietvanzoen on twitter or just leave a comment below.

Lodash, Knockout, and functional programming

2016-03-20T00:00:00Z

Lodash and functional programming offers some wonderful ways to make code cleaner and more readable. But they don't always play nice if you happen to use Knockout observables. I'm going to introduce a way to make handling observables in functional style easier.

Let's start with a plain object example. Say you want to create an array of people's age in years from this array:

var people = [
  { name: "Ron Swanson", age: { years: 55, months: 6 } },
  { name: "Leslie Knope", age: { years: 41, months: 2 } },
  { name: "Andy Dwyer", age: { years: 34, months: 8 } },
];

// the plain js way
people.map(function (person) {
  return person.age.years;
});
// => [55, 41, 34]

// a better way with _.property
people.map(_.property("age.years"));
// => [55, 41, 34]

// even better still with _.map
_.map(people, "age.years");
// => [55, 41, 34]

Clean succinct code. Excellent!

Adding Observables

If you're using Knockout, this becomes a little more tricky because your object path might include observables that need to be unwrapped:

var people = ko.observableArray([
  { name: "Ron Swanson", age: ko.observable({ years: 55, months: 6 }) },
  { name: "Leslie Knope", age: ko.observable({ years: 41, months: 2 }) },
  { name: "Andy Dwyer", age: ko.observable({ years: 34, months: 8 }) },
]);
_.map(people, "age.years");
// => []

Why an empty array? people is an observable array so we need to invoke it to get the value.

_.map(people(), "age.years");
// => [undefined, undefined, undefined]

Here Lodash is traversing the property path without invoking the observables, so rather than retrieving the value of years from inside the observable it's trying to find the property years on the actual observable instance. Since years does not exist, it just returns undefined for each person.

Here's how we might get around this:

_.map(people(), function (person) {
  return persion.age().years;
});
// => [55, 41, 30]

We're back to writing callbacks. That succinct, readable code we had earlier is gone. And what if someone's age ends up being null?

people.push({ name: "Ann Perkins", age: null });
_.map(people(), function (person) {
  return person.age().years;
});
// => Uncaught TypeError: person.age is not a function

Dammit. If this were a written without observables and using _.map(people, 'age.years'); we'd simply get [55, 41, 30, undefined]. Lodash is robust enough that it will simply return undefined for that person.

Here's how we'd get around that problem:

_.map(people(), function (person) {
  return person.age ? person.age().years : undefined;
});
// => [55, 41, 30, undefined]

We have to use a conditional to get around our null problem, which adds complexity, which makes the code less readable.

Since we're using knockout, we probably want this to be a computed observable, so that the value we get is always up to date with our people array.

var peopleAgeYears = ko.pureComputed(function () {
  return _.map(people(), function (person) {
    return person.age ? person.age().years : undefined;
  });
});
peopleAgeYears();
// => [55, 41, 30, undefined]

Yikes. Let's take stock. We have two nested functions, a variable used twice, a path named twice, and an undefined return. This is manageable but damn, it's nowhere near as nice as _.map(people, 'age.years');.

Introducing Kompose

Kompose offers several helper functions that behave like Lodash's path traversing helpers (such as _.property and _.get), but with the added benefit of unwrapping observables along the way.

Let's start with our people again:

var people = ko.observableArray([
  { name: "Ron Swanson", age: ko.observable({ years: 55, months: 6 }) },
  { name: "Leslie Knope", age: ko.observable({ years: 41, months: 2 }) },
  { name: "Andy Dwyer", age: ko.observable({ years: 34, months: 8 }) },
  { name: "Ann Perkins", age: ko.observable({ years: 39, months: 5 }) },
]);

Let's write that peopleAgeYears computed using kp.computedMap.

var peopleAgeYears = kp.computedMap(people, "age.years");
peopleAgeYears();
// => [55, 41, 30, 39]

Nice! Just like the verbose peopleAgeYears example above, this computed will traverse the people objects in the observable array people and map their age in years. We're back to our clear, easy to read, code from earlier.

Going the extra functional mile

Like _.map, passing a path to kp.computedMap is a convenience feature that creates an iteratee function using kp.property. You can also pass your own iteratee function to kp.computedMap. Instead of everyone's age, say we wanted a computed that calculated everyone's "half your age plus seven" age.

Let's start with the long(ish)form:

var youngestDatableAges = kp.computedMap(people, function (person) {
  var personAgeYears = kp.get(person, "age.years");
  return personAgeYears / 2 + 7;
});
youngestDatableAges();
// => [34.5, 27.5, 22, 26.5];

(kp.get is like _.get except that it unwraps observables along the way.)

We can do much better than this though. If we break the above example down into it's element parts we can make this much easier to reason with. Let's start by breaking out our equation:

function datableAge(age) {
  return age / 2 + 7;
}

We can also do away with setting the personAgeYears variable and just pass the return value from kp.get straight into the datableAge function.

var youngestDatableAges = kp.computedMap(people, function (person) {
  return datableAge(kp.get(person, "age.years"));
});
youngestDatableAges();
// => [34.5, 27.5, 22, 26.5];

Not bad! But wouldn't it be great if we didn't have to define the callback function and the person variable? Well, there's a way with _.flow.

If you've never used _.flow before (sometimes called pipe in other functional libraries), I really recommend reading up and trying it out. _.flow returns a function that allows you to pipe a value through several functions, with each function passing it's return value into the next. Here's how it fits in our example:

var youngestDatableAges = kp.computedMap(
  people,
  _.flow(kp.property("age.years"), datableAge)
);
youngestDatableAges();
// => [34.5, 27.5, 22, 26.5];

That's it! No function declarations. No unnecessary variables. This is Point Free (or Tacit) Functional Programming:

Tacit programming, also called point-free style, is a programming paradigm in which function definitions do not identify the arguments (or "points") on which they operate. Instead the definitions merely compose other functions, among which are combinators that manipulate the arguments. ~ Wikipedia

Conclusion

In the these examples I've tried to illustrate how Kompose might work alongside Lodash to produce succinct, point-free, functional code that's easy to read. But it's not limited to the examples above. When I wrote Kompose I did not want to replace Lodash, I wanted to give Knockout users a tool to make it easier to write functional code that handles observables.

Right now the kompose API offers alternative methods for _.get, _.property, _.method and _.matchesProperty. Plus computed generators kp.computedApply and kp.computedMap. Check out the docs and please make any suggestions for improvements.

Professional Resolutions

2015-01-11T00:00:00Z

I've never been big on New Years resolutions. I've always leaned towards a ’let my yes be yes, and let my no be no’ mindset, and I've never been confident in my ability to keep a resolution so making them just seemed disingenuous for me. But this year I feel different about it. Perhaps it's due to hitting the big 3-0. So here's what I'd like to focus on this year:

Reading: As a friend put it, reading is a wonderful source of new ideas, and I need some new ideas. I find it too easy to get in a rut with learning just happening in the workplace. Not that workplace learning is bad by any means, but I feel like I need diversify my learning a little.
Writing: Writing is another great tool for learning. It forces you to solidify and document ideas. I've never been confident in writing, probably because I've never made myself do it regularly. So this is the year.
Speaking: Lastly, I would like to challenge myself to speaking at least once this year. Similarly to writing, speaking is a good way to solidify ideas and to share them. Also, I've never spoken publicly so I think it will be a good personal challenge. They say the first is the worst, so let's get that out of the way.

So there you go. If you feel so inclined, please help me by keeping me accountable. Also if you have any suggestions for good reading sources, please do share.

Happy new year!

Using local environment (ENV) variables.

2014-05-15T00:00:00Z

Often enough you'll need to reference sensitive credentials in your project, or give an easy way for people using your project to change environment relative information in your project. Normally it's not ideal to commit sensitive information to a public repository. Neither is it ideal to commit code which only works for your setup. Enter 'Environment Variables'.

Setting Environment variables

In terminal you can easily set environment (or ENV) variables by running this command: export VAR_NAME=foo. For multi word variables be sure to wrap the variable in quotes: export VAR_NAME="foo bar". But when you reboot your shell you'll lose these variables. So lets look at how to set variables that persist.

Open up .bash_profile or .bashrc in your home folder using your text editor, if you don't have a bash file create it like so:

Start up Terminal
Type cd ~ or just cd to go to your home folder.
Type touch .bash_profile to create your new file.
Edit .bash_profile with your favorite editor (or you can just type open -e .bash_profile to open it in the default editor.

Once you have your .bash_profile open you can add export VAR_NAME=VALUE to set an environment variable. Once you're done save, exit and type . .bash_profile in your terminal to reload .bash_profile. That's it.

Update: A note about case-sensitivity. Depending on what system/software you're using variables are or are not case-sensitive. Always be sure not to accidentally overwrite other variables in your environment. In some systems Var_Name will be the same as VAR_NAME.

Using ENV variables in code

ENV Variables are accessible by basically any server-side programming language. Here are a few examples:

Say I set this in my .bash_profile:

export WIBBLE=woo

Ruby

wibble = ENV['WIBBLE']
print wibble
# => 'woo'

Node

var wibble = process.env.WIBBLE;
console.log(wibble);
// => 'woo'

Python

import os
wibble = os.environ['WIBBLE']
print wibble
# => 'woo'

Looking up ENV variables

Finally here are a couple quick commands for looking up what ENV variables have already been set.

To print out a list of all your ENV variables just use the command env.
To sort the output of ENV alphabetically use env | sort.
To search for a ENV variable use env | grep WIBBLE. ~~Remember this is case-sensitive~~. Be aware that this can be case-sensitive depending on what system/software you're using.

If you have any questions or corrections just comment or email me.

Code for Everyone

2013-11-10T00:00:00Z

I've been excited to hear more about initiatives like Code Club and Code.org, which aim to make code a normal part of a child's education.

Learning to code is an important skill now we’re living in a digital age. It’s not just enough for children to know how to use technology. They should know how it works too.

Learning to code doesn’t just mean you can become a developer it strengthens problem solving skills and logical thinking and supports key academic subjects such as science, maths and technology.

~ Code Club

One of my favourite things about the internet is it's ability to empower people to learn and create, but I've never thought about how the code itself could also do that.

I'm excited to see how Code.org and Code Club progress. In particular I'd be interested to see if initiatives pop up here in Portland too.

Moving from shared hosting to Github pages

2013-10-12T00:00:00Z

When my shared hosting plan was coming up for renewal I struggled to find a hosting service that I liked. I was hoping for good uptime, something that didn't break the bank, and preferably something with a decent UI. (Maybe I was asking to much.) Webfaction was a great option for a while but $9.50 a month for a few small sites was more than I wanted to spend. That said, the UI and features make Webfactions my favourite shared hosting option.

In the end I went for something a little different. Between Jekyll and Github Pages I now host this site for free.

Launching a not-so-static 'static site'

Github Pages provides free hosting for static pages. So all you can use is html, css, and javascript. No server-side scripts and no databases. You can do custom domains, and your site is deployed straight from a repo every time you push to it.

But obviously this wouldn't work for a most blog platforms which rely on databases and server-side scripting to store and serve pages. This is where Jekyll comes in. You setup your includes, layouts, variables, pages, and blog posts, and Jekyll will generate a static site from them. The added bonus is that you can write your posts and pages in markdown and Jekyll renders them as html.

What's also fun, is that Github pages will build your Jekyll site for you each time you push a change. So that's what I'm doing. My site is Jekyll generated and hosted on Github, and I love it. No database, great uptime, really fast, and free.

But it's not for everything

The catch with Github pages is that A) for it to be free you have to use a public repo, and B) it's intended purpose is for "you and your projects". As far as I can tell there aren't any actual restrictions on content, but I wouldn't feel comfortable using Github pages for Cafe van Zoen, which is more of a personal blog.

For Cafe van Zoen I ended up using Amazon S3. It took longer to setup than Github pages, but I figured out a pretty good workflow for setting up sites on S3. I'll write more about that in another post soon.

In the meantime, here are some links:

Setting up your Github Pages repo.
Using Jekyll with Github Pages
The Web Ahead: Jekyll and CMS-less websites with Young Hahn and Dave Cole. A great interview with a couple folks from Development Seed about Jekyll.

Getting Involved: Giving something back to the web dev neighborhood

2013-07-12T00:00:00Z

A year ago my wife and I bought our first house. Like any other unprepared first-time homeowners we asked neighbors for advice, tools and a helping hand with projects. A year later we're a little more confident, own a few more tools and now we get be the neighbor who can lend a hand. I think I've reached a similar point with web development.

When I started out I was a bit green and I looked to the community for advice, tips, tools and help with projects. I'm never going to stop going to people for advice/tools when I need them. But now I've gained some knowledge and I've got some useful tricks and ideas, I can offer something back to the web dev community.

Where to start?

Someone – I can't remember who, sorry :( – gave me a great piece of advice on getting involved. Github. The social coding community is a great place to dive in and get involved with a project. You can check the issues page for a project and see if there's a bug you can tackle. Get to know the project and suggest enhancements, or check the issue page again for someone else's suggestion you think you can get involved in.

Choosing a challenge

For me, a great way to pick a project is to look at what I'm already using. If I'm already using it, I'm already invested and care about it. Something I'm already using is Fuel CMS. Fuel is an open source CMS built by and used at Daylight. I may be bias, but it's rather fantastic. I use Fuel everyday and I care about it being better. For me this is a great starting point. I have got to know fuel well and I can begin to think about how I can be involved with improving it.

There's also the option of starting something new. I'm working on something with a friend right now that I'm pretty excited about, but I'll save that for another post.

Getting my feet wet

There are so many positives to getting involved with the wider web dev community, same as there is with getting involved with your neighborhood: You get to know some awesome people; you can learn from them; and it's a great way to challenge and grow your abilities.

So, I'm diving in. Well, maybe less "diving in", more "paddling around". But it's a start.

Wish me luck.

Front-end Legos: Keeping your CSS maintainable!

2013-06-13T00:00:00Z

It doesn't take long for a project to get unwieldy if you don't have a good system for creating your styles. I recently attended Webvisions where Shay Howe ran a workshop titled "Front-end Legos" that gave some pretty good advice on keeping CSS clean and maintainable. Here's the run down of the best tips I took away from the workshop:

Organize

It's wise to start with a good foundation by organizing your CSS with sections, headers and comments.

Sections and headers will make navigating your CSS much easier for you and especially for other developers in your team. Comments help someone new to your CSS figure out what something is used for. It's particularly useful to comment on styles that seem unusual or styles that are a hack or browser fix.

Here's a good starting point for organizing your CSS:

Core - Your typography, layout and normalize/resets
Components - Buttons, forms, sliders, callouts etc.
Modules - Header, footer

Check out this CSS organization example.

Stop thinking about pages and start thinking about components.

A big piece of keeping your CSS tidy involves changing the way you think about a website. Rather than viewing a website as a collection of pages (or even page templates), begin to look at a page as a collection of components. Even components that seem to only occur on one page should be built to be reusable on other pages, there may be a time when you want to export that component to another page.

Checkout this annotated example where I've highlighted some of the main components on this page. The purple and orange differentiate presentational and layout components which I'll talk about later. Together all of these components build the whole page. But every component can be used on any page to build a new unique page.

This leads to a more 'modular' way of thinking about your CSS. Break your pages into little chunks and identify chunks on other pages that match, even if they vary slightly. Then build your CSS in components. If a component is slightly different somewhere else, give it a modifier class and adjust what needs to be adjusted rather than duplicating CSS.

Separate layout from presentation

Try to keep layout styling such as widths and floats separate from presentational styling. The aim here is to create separate CSS classes that deal with layout that can be shared by multiple components on your site. This helps to reduce code repetition within your components.

Eg. Rather than:

.news {
  width: 480px;
  margin: 0 10px;
  color: #333;
  background: #eee;
}
<div class="news"></div>

Try:

.col_6 {
  margin: 0 10px;
  width: 480px
}
.feat_box {
  color: #333;
  background: #eee;
}
<div class="col_6 feat_box"></div>

In the first example .news has a specific use and probably a specific placement in a layout. In the second example we've created a layout class that can be used for multiple components and a .feat_box which can be used on more than just a news article.

Use a CSS grid system (such as foundation's grid system) or create your own grid system, then keep your components reusable throughout your layout by focusing on presentation/theme only.

Keep specificity low

High specificity makes it much harder to modify elements without writing long strings of selectors, which in turn makes your CSS bloated, more complicated and harder to maintain.

#primary #main div.media ul li span {
  color: #ccc;
}

Here we have two IDs, a few element selectors and a class. To modify this style we'll need all of these selectors plus one or use !important to trump everything. Typing out all these selectors again just to overwrite the first style easily leads to code bloat and is frustrating to maintain. Use of !important should never be used reactively, but rather proactively such as for a class which you know will always need a particular style. E.g. .error { color: red !important; }.

Avoid IDs. IDs are 255 times more specific than a class and a class can do everything that an ID can do. Finally, avoid using element selectors in your CSS. Doing this frees your CSS from a specific HTML elements and maintains reusability. Here's a better approach to the previous example:

.media-date {
  color: #ccc;
}

This is much nicer. It's descriptive, clean and reusable.

Conclusion

All of these techniques are going to help you end up with cleaner code, fewer lines of CSS to manage, and some wonderfully modular code that is easier to maintain. "The Pipe Dream", as Shay Howe put it, is to build everything in HTML with your arsenal of classes at hand. The dream is that you'll never need to touch your CSS because you'll have created all the classes you need to build anything. It's quite a grand Pipe Dream but definitely worth striving for. Focusing on the organization, reusability and modularization of your CSS is the key.

Check out these great resources for more info on this theme.

Shay Howe's Learning site - A great resource for learning more about HTML & CSS.
OOCSS (Object-Oriented CSS) and SMACSS (Scalable and Modular Architecture for CSS).
Code smells in CSS - Great article from Harry Roberts on this subject.

Piet van Zoen

How to setup Copilot to autocomplete commit messages

On writing good commits

Setting up your commit environment

Setting up a commit message template

Git commit verbose mode

Commit message keyword

Copilot in action

My favourite sci-fi reads

My IndieWeb tech stack

Server - "BMO"

Apps

Yoto: Our favourite device for kids

Tips

Early Mornings

Branch based sessions in Vim

Creating and opening branch based sessions

Cleaning up session files

My email workflow in Fastmail

Why Fastmail?

The Workflow

The Setup

1. Feed & Paper Trail

2. The Screener

3. Extras

Recycling old emails

Cleaner sidebar

Notifications

Reply Later & Aside

Missing features in Fastmail

Feed view

Thread notifications

Contact avatars in email list

Conclusion

End-to-end testing (WIP)

What is end-to-end testing?

Test regularly

Focus your tests

Balance with monitoring and other testing

Field recording

My box of mistakes

Some of my projects

Customised PiBow case for Raspberry Pi + PiJuice + PiTFT

What I used

The build

Done!

Rethinking my piece of the internet

Focus on the problem

Things I wish I knew before my daughter was born

There's no right way to feel when your baby is born

You are the professional

The baby phase is only about 6 months

Martín's Triathlon

Summer Storm

Polderbaan

Ten years

Less Ordinary

Mama!

7 reasons not to skip the tests

The Reasons

Feature security

They're not just tests, they're documentation

Testing makes you faster

Tests are automatable, you are not

Green just looks good

You probably won't go back and do them later

Your later self (or a colleague) will appreciate it

Caveats and tips

Caveat: Good coverage

Caveat: Testing is a skill

Tip: What (not) to test

Caveat/Tip: Perseverance

Conclusions

Further reading/watching

Minsk Tunnel

How I organize my cloned git projects

Enter Go

But I don't work with Go

The Solution... git get

But that's a lot of directories to navigate

The Solution... `git get`