The Unmitigated Gall of AT&T

Mar 14, 2018
Tags: Complaining Twouts

The wife and I recently upgraded our iPhones through Apple’s iPhone Upgrade Programhas not a thing in the world to do with AT&T. Yet, @ATT somehow got up the gall to charge us each a $20 upgrade fee—WTF!?! One support call later, they’ve credited us for the cost of the fee—but how many people didn’t notice, or didn’t bother to complain. For charging me $40 while “layin in the cut”—watching me move my SIM card from one phone I own, to another phone I’m paying a third party to own—@ATT wins my coveted “dick of the month” award: 🖕 Thanks for playing.

Git Branch in the Bash Prompt

Feb 25, 2018
Tags: Command Line Tooling

Waaaay late on this one—but you know what they say. For a while I’ve had a text trigger in iTerm2 to catch and highlight the currently active Git branch—but it never occurred to me to just add it directly into the command prompt.


Trivial to do, and super helpful—as soon as you open up the directory, you immediately know what branch you’re working in. Below is what the setup for the prompt looks like, just drop that into your .bash_profile and you’re all set.

parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
export PS1="⚑$RED\$(parse_git_branch) $NO_COLOR\w > "

VS Code: Hope, Hype, and Hijacking

Feb 21, 2018
Tags: Tooling Text Editors

I’ve always been a bit promiscuous with my text editors. The whole chronology probably looks a little something like this:

Dreamweaver => Coda => BBEdit => TextMate => Espresso => Sublime Text => Espresso (again) => Sublime Text 2 => Atom => TextMate (again) => BBEdit (again) => Sublime Text 2 (again) => Espresso (yet again) => Sublime text 3 => Atom (again) => Espresso (yet again, again) => Sublime Text 3 (again) => VS Code.

As you can see, I’m not shy about “picking up stakes” and moving from one to another—and back again. I’d like to think that I’m always hopeful for better features, performance, extensibility, etc.—that I’m always looking for ways to procrastonate, and avoid acutally doing any work with the editor du jour is probably closer to the mark. Nevertheless, my promisquity has given me a pretty good sense for what does and doesn’t make for a good editor.

Espresso App

From a purely UI/UX perspective I still think Espresso is one of the most elegant editors I’ve ever used—unfortunately its workflow model is a bit anachronistic. I really appreciate the thought that went into some of the features like Dynamo—their proprietary static site generator—but ultimately, it’s playing in the proverbial walled garden. And, I can’t remember the last time I used FTP to send files to the server.

Like most, I’ve welcomed our new decoupled, extension based, Git enabled, Electron App overlords—and it’s probably for the best. Electron apps will never be as blazingly fast as a well written native app, but VS Code does “OK”—better than Atom, I think. The Git integration is nice, though I do most of that stuff from the command line anyway. What really gets me are the extensions and the configuration. Granted, it’s a pain in the ass to setup—Sublime is too—and though VS Code makes it easier than most, it still takes a real investment to get everything configured as you’d like. But the good news is that everything, and I mean everything is configurable, and the extensions are killer.

Killer Extensions

All the usual suspects are there: git gutter, file icons, linting, Emmet, syntax highlighting for every language you can imagine (these are much easier to fine-tune to your liking in VS Code). The IntelliSense—Microsoft’s version of code completion/hinting—extensions are what really seal the deal though.

VS Code

Sure, you get hinted to the right method in Ruby, or ES6—but better than that, you can autocomplete on filenames, CSS class names, even Sass variable, mixin, and function names—I never remember that stuff. There’s no lack of hype around VS Code right now—but on the whole, I’d say it’s living up to it.

Hijacking the Community

Honestly, I feel kind of bad for the Sublime Text folks. Atom, and now VS Code are in many ways a direct hijack of the package/plugin/extension approach—pioneered in TextMate and brought to scale in Sublime—to say nothing of the command pallete, and some other directly hijacked bits of UI. It’s telling that the extension which ports Sublime keyboard shortcuts over to VS Code already has 1/2 a million downloads. But just like any other suffeciently advanced technology these days—it’s the ecosystem that really matters. When TextMate was TextMate, there was a vibrant community around it—creating bundles, themes, and addons—this made the editor much more than it could have been on its own. When development of newer versions stalled, the community moved on to Sublime—and did it all over again. Today VS Code has the community mindshare, but what came before is never really lost—most of the syntax files I’ve seen for VS Code are still based on the original TextMate Grammar scheme from 2004.

Busting CSS Cache with Jekyll

Feb 16, 2018
Tags: Jekyll Ruby

If you’re setting long expires headers on your static assets—as God demands—then at some point, you will want to bust that browser cache. If you’re also using Jekyll, there’s a plugin for that. Here’s the thing though: not everyone needs a full-fledged, sprockets based, asset pipeline for their project. In the world of Jekyll—I’d actually say that the majority of folks don’t need that particular sledgehammer. It adds quite a lot of complexity to your build and, to be fair, the documentation is a bit inscrutable.

There’s nothing wrong with simple workarounds like this:

<link rel="stylesheet" href="/css/main.css?{{site.time | date: '%s'}}">

Which uses the site.time variable formatted as seconds since the epoch (1970). When outputed, the ?1518881511 query paramater gets appended to the end of the filename—browsers see this as a new asset and download it. This is great, and will bust browser cache of the file everytime the site is built.

A Middle Path With MD5 Hashing

Ideally though, you’d only invalidate the browser cache when your asset has changed somehow. You could manually increment when changes occour using semantic versioning e.g. main.css?v=1.2—but my Mtv addled brain would never remember to do that. Somewhere between a Rails asset pipeline and manually incrementing—lies a middle path. A custom plugin that reads in your _sass files, geneartes an MD5 Digest—and then lets you append that digest to your css filname with a filter, e.g.:

<link rel="stylesheet" href="{{ site.baseurl }}/assets/css/{{ 'site.css' | bust_css_cache }}">

Which will give us something like this in the markup: <link rel="stylesheet" href="/assets/css/site.css?c86a8588967580cc0631f5115d9d6b18">. This way, the hash at the end only changes when the content of your Sass files change. A browser could hold onto your stylesheet for a year—but as soon as you make a change to the _typesetting.scss partial, it will ask for the new version.

It’s not as complicated as it sounds. You can add a custom plugin by including an .rb file in the _plugins directory at the root of your project. There are some caveats though, so first have a look at the documentation for running with custom plugins. Plugins can get pretty complicated, but for our purposes we just need to register a simple filter with Liquid.

module Jekyll
  module CacheBust
    # put the stuff that does stuff here


Basically, Liquid Filters take an input and return an output. In our case, our input will be the name of our CSS file, and the output will be the name of our CSS file with an MD5 Digest of our Sass files appended to it. I dropped the full plugin into this gist if you want to give it a look. The key bits are a CacheDigester class that will take a file or directory of files and generate a digest, and the bust_css_cache method which you call as a filter in Liquid.

We’re passing our _sass directory to the CacheDigester object because we write in Sass and our CSS file will only be generated at the end when the site is built. I keep my Sass files in assets/_sass so if you plan to use this plugin you may have to change that bit in the bust_css_cache method.

Simplicity, and Context

What I love about Jekyll, is what I love about Liquid, is what I love about Ruby, is what I love about Vue. They all do complex things, but offer simple affordances to the user. Extending the functionality of Liquid and Jekyll is relatively straightforward, as you can see above. This means you can build the right solution for your particular context—without being forced to use a sledgehammer to swat a fly.

The Politics of Entertainment

Jan 9, 2018
Tags: Politics Twouts

The more that politics becomes entertainment—the more entertainers will want to become politicians. This is bad for a whole host of reasons—not the least of which is, you can’t change the fucking channel.

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.