The fediverse recently had an incident after a minor celebrity created an account. I very much do not want to talk about the details/merits of that incident¸ but I do want to use it as a prompt for thinking about how the fediverse should deal with some related issues.
Just published a gtypist lesson. The README is below.
GNU's gtypist program is a great way for Linux users to improve their typing speed from the comfort of their terminal, and it's widely available for every distribution. I personally used it extensively when I switched from practicing law to programming and discovered that the keyboard was full of keys I'd basically never needed before. (If you need convincing of the importance of typing speed to programming, please see the postProgramming's Dirtiest Little Secret.
However, despite fitting so perfectly into a programming/command-line workflow, gtypist doesn't actually have a lot of content focused on programmer-specific keys. This lesson fills that gap.
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 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.
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.
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.
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.
Fortunately, the solution is very simple. You to entirely avoid this issue, you need to take two steps.
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.
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.
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?
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?
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.