Operator Mono

Mar 5, 2016
Tags: Typography Tools

Recently, I’ve been trying out the ridiculously nice Operator Mono typeface in iTerm and Atom.

atom screenshot

TL/DR: it’s amazing.

As you can see, the italic style is strikingly different—I’ve been toying with using this style for tag labels, and when templating with Liquid I find it actually works rather well. Now, let’s be clear: spending $180 on a typeface for your text editor is pretty close to the height of privilege. When my free trial runs out, I doubt I’ll buy it outright—but if I was going to throw around cash like that on typefaces, Operator Mono would be at the top of the list.


Environment Variables, Bundler Groups, and Jekyll

Mar 4, 2016
Tags: Jekyll Web Development

Oh my. If you’re working with Jekyll and rolling your own build and deployment process, chances are you’re slowly but surely accumulating sundry plugins, gems, and build scripts. Some of these are for local development, some are for deploying your site, some are for both—but configured differently for each. How do you manage all this? Bundler groups and environment variables are here to help.

Let’s say you’re using something like Jekyll-Assets to manage your asset pipeline. You want it to process your Sass, concatenate and compress your Javascript and CSS, and bust cache with url digests—but you don’t want it to do all that stuff all the time. Or maybe you’re including a LiveReload script in your page to automatically refresh the browser as you develop locally—no need to have that in production. Luckily, you can tell Jekyll what to do when by setting JEKYll_ENV. It defaults to "development" and you can set it when building or serving e.g. JEKYLL_ENV=production jekyll build. Most plugins like Jekyll-Assets will look for the variable and act accordingly—only compressing and digesting in production, etc. The variable is also available in your templates at jekyll.environment so you can include and exclude things as appropriate.


{% unless jekyll.environment == 'production' %}
<script type="text/javascript" src="http://localhost:35729/livereload.js"></script>
{% endunless %}

When it comes to managing your site’s dependencies for a given environment, Bundler’s groups can help out. Organize your Gemfile into the approprate groups to make sure you’re loading the right gems when you need them.

source 'https://rubygems.org'

gem 'github-pages'
gem 'jekyll-paginate'

group :development do
  gem 'guard'
  gem 'guard-livereload'
end

group :production do
  gem 'rake'
  gem 'uglifier'
end

This is especially helpful when using something like a continuous integration service to build and deploy your site. By passing in the --without development flag as a bundler argument you can leave those gems behind and not bother loading them onto the build server since you don’t need them.


Jekyll and Continuous Integration with Travis CI

Feb 20, 2016
Tags: Jekyll Web Development

Using GitHub Pages to host your Jekyll site is great—it’s fast, secure, and free (as in beer)—but it’s also restrictive. There’s a whitelist of plugins Jekyll can build with, but it’s pretty limited. If you want to run your own plugins or post build scripts there’s no automated way to do that.

Of course, you could just build the site locally, and then deploy it—but if the site is for a client, or if you’re collaborating with others, that’s not really going to be sustainable.

One way around GitHub’s restrictions that I’ve been considering lately is using a continuous integration service like Travis CI. Basically, Travis looks for updates to a GitHub repo, clones the given branch, builds the site, runs any post-build scripts you want, and then commits the site straight to the GH-Pages branch for hosting.

Travis Output

This lets authors and content managers, using something like Siteleaf, add content as they wish—when they hit publish and the changes are sync’d to the repo, Travis takes over, builds the site, and then deploys it back to GitHub. Travis is primarily used for testing code in pull requests before merging it with a master branch. If we wanted to include tests into our workflow we could, but I’m mostly just interested in using it to build and deploy.

There are a couple hoops to jump through to get this all working. As an example, you can see the files I’m using with Travis to generate this very site below:

  • Setup a Travis CI account
  • Enable the repository you want it to work with. You can set it to build on pushes, pulls or both.
  • Add a travis.yml file to the root of your repo. The file will tell Travis how to build and deploy. Travis will run a bundle install before getting started so make sure any gems you need are in your Gemfile.
  • Add a deploy.sh script that Travis will use to commit the build directory to the gh-pages branch of the repo.
  • You’ll also need to generate a personal access token with GitHub and use it to set a GITHUB_URL environment variable in Travis. This will point to the remote repo to be used when Travis commits the built site. e.g.: https://[personal-access-token]@github.com/username/repo.git

That’s it, mostly. As always, there are a few landmines to look out for. You want to make sure that your _config.yml file excludes the vendor directory, or Jekyll will try to include those when it builds. Also, if you’re having Travis install any Node dependencies you will want to exclude them as well.


Clean URLs in Jekyll

Feb 10, 2016
Tags: Jekyll Web Development

GitHub Pages recently updated its service to start using the latest major version of Jekyll—that’s 3.0 for those keeping score at home. Aside from incremental regeneration—which I love when I’m working with rather large sites—the thing I’m most excited about in 3.0 is extension-less URLs.

No one want’s to look at those ugly extensions, right? The worst. Seriously though, if you’re migrating from a standard LAMP Stack CMS like Drupal or WordPress, you can now chop off those extensions without worrying about redirecting everything—an especially painful process on GitHub Pages where you can’t have a bunch of directives in an .htaccess file.

Here’s the trick, once you’ve set your permalink style in the config file, you still need a server that understands the extensionless route and can serve up the right file. For hosting, this shouldn’t be a problem—GitHub Pages even handles this right out of the box. In your local workflow, there are a few more hoops to jump through.

var hygienist   = require('hygienist-middleware');
var bs          = require('browser-sync');

gulp.task('serve', function() {
    bs({
        server:{
          baseDir: "build",
          middleware: hygienist("build")
        },
        notify: false,
    });
});

If, like me, you’re using a Node server for local development you can take advantage of some of the great Middleware available for Connect like this plugin to modify URLs before handing requests off to the server. Just pass in the root directory so it knows where to look for the files, see above.

Jekyll has really come a long way in the last year and a half. Collections, native support for pre-processors, a Liquid profiler, incremental regeneration, clean URLs, and more. Combined with a decoupled CMS like Contentful or Siteleaf, using Jekyll for clients is quickly becoming more and more of a solid choice.

The Distress Signal is the personal blog of Bryan Schuetz. Bryan has been complaining on the Internet since the 90s. If you'd like to get in touch with Bryan, you can find him on twitter.