Sending Keybase Chats Using Vim

I cannot spell. Like, was-sent-to-special-classes-as-a-child-and-they-gave-up-on-me cannot spell. Luckily, this isn't an issue 99% of the time as an adult, because I'm never asked to operate in an environment without a spellcheck. Except … I just started using keybase.io's chat program, and it doesn't check spelling. Clearly, this needed to be fixed.

I found a way to fix it: I now write my chat messages in Vim and then pipe them to keybase chat. I thought this would be a pretty rare use case (how many other people really care about spelling, or want to edit one-line chat messages in Vim?) But a number of people expressed interest, so I decided to write this post as a how-to.

I'll give you the tl;dr how-to version quickly, and then I'll walk though what we're doing in a little more detail and talk about how you could customize it for your use-case.

Mastodon Is Better than Twitter: Elevator Pitch

Mastodon is a newcomer social media platform that is a lot like Twitter—short messages, followers, hashtags, all that. But Mastodon is much better than Twitter, and not just because being totally ad-free and keeping chronological timelines make it far more enjoyable to use (though that certainly helps!).

All that is nice, but the real advantage Mastodon has over Twitter is that Mastodon is not an outrage machine that's corroding our ability to view our politic opponents as real humans, deserving of sympathy and understanding.

To explain how much better Mastodon is, I'm going to give you three examples of how Mastodon is better, and then I'll step back and talk about why Mastodon is better.

Gutenberg quickstart 2: From "Hello, World" to macros

When we left of, we'd just created a "Hello, World" website—nothing that fancy, but enough to get a feel for the basic structure of Gutenberg's templating system.

[](https://v05--gutenberg-simple-demo.netlify.com/)

(source code, as always, in the GitHub repo.)

Today, we're going to dive in a bit deeper and take a look how we can use Gutenberg's templates to support a multi-page site.

An About page

First, let's create an About page for our demo site. Before we do, though, lets add a link to our new page from our homepage. Add the following HTML to your index.html file just after the body begins:

    <nav>
      <a href="/">Home</a> | <a href="/about">About</a>
    </nav>

Now that we have a link, lets make the page. To do that, we'll need a template that applies to pages—right now, we only have the index.html template but, as we talked about last time, that template only applies to the home page.

By default, all other pages are governed by the page.html template. (Note that I said pages, which are distinct from sections. We'll get to sections next time.) So, if we're going to have an About page, we're going to need a pages.html template.

How to avoid SEO penalties when using Netlify

The Problem

I've been really happy with my Netlify hosting. It's fast, free, and deploys my site on a global CDN. Even better, Netlify has all sorts of advanced deploy previews and other features that I'm only starting to play with.

All that said, today I realized that one consequence of how Netlify does things is that sites could end up penalized by Google and other search engines.
Specifically, because Netlify makes multiple versions of your site available, your site could be penalized for having "duplicate content"—the same penalty that search engines apply to content mills that steal other people's work and repost it as their own.

What is the problem, exactly? Well, with default settings Netlify makes every page available as a page on your domain and as a page in a subdomain inside Netlify.com. So, for example, the page you are reading right now would be available by default at both www.codesections.com/blog/netlify and at codesections.netlify.com/blog/netlify; since it shows up at both locations, it would be counted as duplicate content.

In fact, the problem is even worse than that: Netlify may also (depending on your settings) publish different branches of your site to different URLS (even with the same content) and will create "deploy-previews" that allow you to test live deploys before publishing them to your primary domain. These features are really great, and I make use of both of them. (In fact, branch deploys are what let me easily have passgen.codesections.com as a subdomain in my site). But they mean that you could end up with more than just two copies of each page on your site—way more, in fact.

The Solution

Fortunately, the solution is very simple. You to entirely avoid this issue, you need to take two steps.

Gutenberg Quick Start: from 0 to Hello, World

Gutenberg is a fantastic static site generator. It is likely the fastest generator in existence, it's got an easy-to-use yet powerful templating syntax, and it supports advanced features like syntax highlighting and Sass compilation out of the box.

This quick start guide will give you everything you need to know to build a custom static site, with your own templates, and taking advantage of all of Gutenberg's powerful features. At each stage, you'll be able to see demo sites that show exactly what a site like the one I've described looks like, and you'll be able to see the exact code that generated that demo site—it's all on GitHub, and there'll be links at every step.

In this first part, we'll start with creating a simple, single-page site. It won't be much, but it will give us a firm foundation to build on.

Hexo Review

As I've written about a couple of times already, I think static site generators are pretty great. But that still leaves picking the right static site generator.

As I've mentioned before, this site is built with Hugo, and I'm currently very happy with the setup. However, I didn't start with Hugo. My first experience with a static site generator was actually with Hexo—a static site generator that I wanted to love but found that I just could not.

This post is all about what drew me to Hexo in the first place. And then, part two of this review, I'll get into what ultimately pushed me away from it.

Just How Secure Is pass-gen?

The other day, I posted on Mastodon that pass-gen (my new passphrase generator written in pure bash and designed to follow the Unix philosophy) has achieved 100 bits of entropy with default settings and is now 128 times as secure as when it first launched. But how secure is 100 bits of entropy, really? And how do you even go about measuring the security of a passphrase generator, really?

Attack Vectors

The security of a given password depends entirely on the method used to attack that password. As xkcd famously pointed out, basically all passwords are weak against physical attacks:

But let's set aside the $5-wrench attack for the moment, and dive into the crypto-nerd's imagined attack. Just what would it take to actually crack the sort of password that pass-gen creates?

Image Compression for Website Speed: Turning it up to 11

A few months ago, I got very into maximizing the speed of my website. I feel pretty good about what I accomplished:

(I actually prefer the results from webpagetest.org, and not just because it show my site as loading even faster. It's open-source and seems to have a better methodology. But it doesn't generate as pretty a picture, so I went with the Pingdom screenshot above.)

My home page loads in well under a second, and transfers only 2.4kb of data. All of the pages in my site loaded their above-the-fold content without any blocking scripts or external CSS. Plus, my site is served of of Netlify's global CDN, so it attains basically the same speed for visitors from anywhere in the world. I was generally satisfied with that result, and stopped thinking much about my site speed.

Then, today, I realized that I'd let things slip a bit; I'd uploaded a few images without giving any thought to compression, and a couple of pages were much larger—and therefore slower—than they had any right to be.

So, I decided to fix that.

My (Paranoid) Git Setup

Until recently, I had a very simple git workflow: I worked in a local repository, and then pushed my changes to a single remote, which lived at GitHub. In the case of the code for this site, pushing to GitHub would automatically trigger a rebuild of the website and publish the changes live to the Internet. (Thanks, Netlify!)

This setup had the virtue of simplicity, but it had three important drawbacks:

• I had no backups of any changes I'd made but not published. For example, if I had a draft blog post, it lived only on my laptop, and thus could easily be lost. This isn't that big of a deal with my current workflow—unlike some some bloggers, I don't tend to keep a ton of posts as drafts. Still, though, I'd like to not lose what I do have, and I always might keep more drafts in the future.
• I was relying heavily on GitHub to publish updates to my site. If GitHub were down or locked me out of my account or something, I would have no easy way to make posts to my blog. I could migrate to a different git host or manually update Netlify, but it wouldn't be seamless.
• I had only one backup of the site, and that was on GitHub. If anything happen to my computer, I'd be 100% relying on GitHub for all of my site content.

So, over the past week, I decided to fix all of these issues. With my new setup, I have:

1. A git server on a Raspberry Pi on my home LAN.
2. A git server on a cheep shared host.
3. A GitHub-hosted repository.
4. A GitLab-hosted repository.

Announcing pass-gen

As I mentioned last time, I think many password managers have a serious flaw: they don't have a way for you to generate a secure, memorable passphrase. That means that, if you ever have to type your password in, you're stuck typing in something like {!]&Sk)r"ss|$K40:]PP''3k-—and nobody wants to type {!]&Sk)r"ss|$K40:]PP''3k-.

I also said that I've been using hsxkpasswd to solve that issue and generate usable passphrases. I like hsxkpasswd a lot, but there's one thing I hate about it—it's written in Perl. It's the only Perl program I have on my current computer, and it feels really burdensome to install an entire programming language just to generate a simple passphrase. So, after being bugged by that, I finally decided to do something about it.

I've written pass-gen, a pure bash password generator. I just used it to generate a password, and I got UPTURNED!​gone!​DASH!​renewable!​GUIDE!​joystick!524—hopefully much easier to type. I had several goals for pass-gen: