Matthew Ernisse

March 10, 2017 @20:00

Over the years I have had many different BlackBerry phones. I started with a 7100t, one of the first candybar-style BlackBerry devices and just finished up a several-year relationship with a Passport.

I loved every minute of it.

I still think that RIM/BlackBerry had the best device for communication out there, but as they sunset the BlackBerry 10 operating system, there is no longer any reason to continue.

Yes, BlackBerry now makes Android software and TCL makes BlackBerry branded hardware but if you are going to switch away from a platform, you might as well evaluate all the options.

I chose an iPhone.

There are lots of reasons, and none of them are perfect, but at the end of the day it works for me, and that's what is important.

The tl;dr of it all is that I trust Apple more than I trust Google.

They are both huge multi-national corporations who don't really care about anything but driving shareholder value... but Google basically only makes money on selling out its users.

My Collection

I will miss you, you crazy Canadians.

My BlackBerry Collection

September 19, 2016 @16:00

I have actually been building the static content of the site from a python(1) script for a while, though until recently it ran from cron(8) and rebuilt all the pages every hour. This wasn't too bad since there were a few internal pages that also got rebuilt, including my graphing pages that are built from SNMP queries of various network gear.

So a little bit about the page generation. The script uses the Cheetah Template engine to assemble the files for each static page. There is some logic in each template to ensure the proper elements are included based on which page is being created.

ScreenShot of code.html

For example code.html is made up of 4 files.

  1. header.html.tmpl - This is not visible, it is everything up to the closing head tag.
  2. nav.html.tmpl - This is the nav element, including the other page buttons. This is actually even included on the index.html page but it hides itself since it knows it is not needed.
  3. code.html.tmpl - The content of the page.
  4. footer.html.tmpl - the footer element and the closing body and html tags.

This lets me build a wide variety of content out of the same style. There are configuration provisions in that allow me to add additional JavaScript and CSS links in header.html.tmpl if I need to. This is used by the network information page to include additional style and the JavaScript that allows for dynamic hiding of the lists.

        elif page == "network.html.tmpl":
            extras["custom_css"] = [
            extras["custom_js"] = [

The whole build process is fired off by the following post-receive hook in git.

# post-receive hook
# (c) 2016 Matthew J. Ernisse <>
# All Rights Reserved.
# Update the on-disk representation of my website when I push a new
# revision up to the git repository.

set -e

GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)

if [ -z "$GIT_DIR" ]; then
    echo >&2 "fatal: post-receive GIT_DIR not set"
    exit 1

echo "updating $BUILD_DIR"
GIT_WORK_TREE=$BUILD_DIR git checkout -f

echo "building html from templates"

while read oldrev newrev refname; do

echo "optimizing JPGs."
find "$BUILD_DIR" -name \*.jpg -print0 | xargs -0 jpegoptim -qpst

echo "optimizing PNGs."
find "$BUILD_DIR" -name \*.png -print0 | xargs -0 pngcrush -reduce \
    -rem alla -q -dir "$BUILD_DIR"

echo "setting rev to $REV"
sed -e "s/GIT_REV/${REV}/" "$BUILD_DIR/index.html" > "$BUILD_DIR/"
mv $BUILD_DIR/ $BUILD_DIR/index.html

echo "site deployed."

The result is that a git push looks like this:

Counting objects: 11, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 195.70 KiB | 0 bytes/s, done.
Total 11 (delta 2), reused 0 (delta 0)
remote: updating /var/www/
remote: building html from templates
remote: optimizing JPGs.
remote: optimizing PNGs.
remote: setting rev to 3ac149f570d379bf71ed78a7734042af2200591a
remote: site deployed.
   197843c..3ac149f  master -> master

It works pretty well, allows me to serve static files, have a long Expires: header and in the end causes the pages to load reasonably fast.

First test using GTMetrix from San Jose

Result of GTMetrix Page test

Even if I test from Australia using PingDom...

Result of PingDom Page test

Next time we will talk about the gallery generator. In the mean time... 🍺

September 06, 2016 @16:00

I am hoping this will be the first of three or four posts detailing some of the technical bits under the covers of the new website. In this particular post I'll talk mostly about the design decisions that went into the whole infrastructure.

All of this works for me, and is based on my use-case. It is entirely possible that your application may be different and some of the decisions I made won't work for you, but at least you can hopefully understand the reasons behind it all.

So first, the givens

What I chose to do


This allowed me to hand-create a single HTML template that gets applied virtually everywhere (the gallery has bespoke templates for it). I was able to craft a responsive design with almost zero JavaScript (only the mobile interface for the gallery uses JavaScript (jQuery)), which makes me happy. The site looks reasonable across desktops, phones, and tablets. It doesn't expose any data to any third-party sites. It is fast to load and render. It takes almost no server resources to serve.

Most of the pieces (which I will go into detail in the next few posts) have been around for a while but it is how I'm putting them together that makes it so much easier to maintain. I collapsed a lot of the templates down to a single base template class and only customize the bits needed to make each page. I also went from triggering this all out of cron(8) on the hour to building it when a change is pushed to the server. This not only saves server resources rebuilding things when nothing has changed, but also makes it so the errors are immediately noticed (in the git push output instead of in a cron mail that I may ignore).

Hopefully this makes sense. Next time I'll start talking about the oldest part of the site -- the template builder.

Subscribe via RSS. Send me a comment.