Building My Site: Publishing

10 June 2015

I finally built a blog.

To get past the blank page problem (and for my own future reference), I’m going to write a few posts about how I did it and why I did it that way. I’ll start with the publishing process.

About a year ago, I decided to redesign my 10-year-old portfolio site. As my career focus had settled on UX design, I took a Beatrice Warde approach: I wanted the site to be ‘transparent’, to just present the content as simply as possible with a minimum of technical and visual flourishes. That meant keeping both the technology and the design as simple as possible.

So when I decided to add a blog I chose to use Jekyll, which publishes a static site (i.e. just plain HTML pages served straight from the filesystem), rather than something like WordPress, which assembles pages using text pulled from a database and various bits of code. Vito Botta has written some rather thorough posts on the advantages and disadvantages of Jekyll relative to WordPress, if you’re interested in that sort of thing. What swung the decision for me were WordPress’s ‘security’ (I’ve been bitten by that before), constant updates, and the relative complexity of implementing a custom design.

The downside of Jekyll is that to publish, you have to use whatever computer hosts your Jekyll source files to build the site, then move the files to the server. That means no editing from, say, a smartphone without setting up SSH access to the main machine. It also means no remote editing without opening a port on your home router. Ugh.

The ‘simple’ solution is to run Jekyll right on the server and have the source files there. It’s still pretty secure, as you need to be able to access the shell to run Jekyll. And it allows me to build the site and move the files into position with a couple of shell commands. First I run:

jekyll build –source [jekyll directory] –destination [directory to build the site in]

Which builds the site in a ‘safe’ directory. Jekyll clears everything out of the directory before putting the site files in, so I don’t want it just building to the www directory.

Then I run:

cp -r [directory the site was built in]/. [www directory]

Which overwrites the old site files with the new ones, but leaves everything else alone.

Of course, I also want to be able to test the site in my live environment before actually making it live. By default, Jekyll assumes everything will be placed in the www root, so just publishing the site to a subdirectory will break the links unless you change the default site path in the configuration file. Rather than risk putting the wrong configuration live, I created a subdomain on my site (staging.setmajer.com) and publish to that.

The drawback to generating the site on my server is it leaves me editing remotely, which means some combination of a command line editor, no offline editing, lag when saving, or edit, then upload to view your changes. None of which is ideal.

I needed source management anyway, so I decided to use Git to keep everything in sync. I created a bare repository on my server and set that as the master for the working repository on my local machine. Next, I created a second repository on the server to be a working repository so I can edit remotely via SSH when needed. I can also set up Git repositories and Jekyll on my Dell Venue tablet, my work laptop, etc. As long as I remember to commit my changes, all should be well.

I could have used Github for the master, but getting to grips with Github seemed like another layer of complexity. Plus, I’m not ready to display my ropey liquid templates to the world just yet.

It’s working fine so far in tests with my home and work laptops. The next thing I need to do is find an editor for my iPad, Moto G, and/or Kindle that will let me edit offline and then push the edits onto my server when I have connectivity.

Even after creating shell aliases to combine commands, the setup feels like it’s too clever by half. Just look at how much verbiage it took to explain it (and well done you for getting this far — now for the love of dog go find something more interesting to do, like watching some paint dry). That said, it does seem more straightforward than many of the deployment methods documented on the Jekyll site, and lets me control where and when to deploy without mucking about with Git branches or the like.

In any case, 17 years after I first launched setmajer.com I finally have a live and usable blog. That’s something, anyway.