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.

(read more)

Benchmarking & Comparing Static Site Generators: Gutenberg versus Hugo

As of this post, this blog is now powered by the static site generator Gutenberg instead of hugo. I was pretty happy about Hugo and don't have much bad to say about it, but I'm even happier with Gutenberg. This post provides an in-depth comparison between the two on five dimensions (speed, template syntax, features, documentation/support, and hackability) and explains why I decided to switch.

Speed

In some sense, this is the least important of the five metrics—both Hugo and Gutenberg are fast. Really fast. So fast that, at least with small sites, you'll likely never have a noticeable wait when using either program.

However, I'm still starting with speed because Hugo's tagline has always been that it's "the world's fastest framework for building static sites", and I really wanted to know if that's actually the case. Hugo is constantly bragging about it's speed, but Gutenberg is built in Rust which—at least to hear the Rust partisans tell it—should give it a definite speed edge. So, who is the ultimate speed champion?

(read more)

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.

(read more)

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:

xkcd 538

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?

(read more)

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:

100% score from Pingdom tools

(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.

(read more)

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.
(read more)

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:

(read more)

Fixing the One Problem With Password Managers

I recently tweaked the way I use my password manager, and it's already saved me considerable frustration. Not only that, it's also brought my usage more in line with the Unix philosophy of using tools that do only one thing, and do it well—and illustrated, once again, why that philosophy is so great.

This post explains my tweak, and how you can apply it. But first, some background.

(read more)

Greatness of Static Site Generators, Part II

In the last post, we talked about the history of website hosting and the rise of dynamic websites powered by PHP. Now, we’re going to turn to more recent history and see how content delivery networks have changed the nature of the modern web.

Content Delivery Networks and the Global, Mobile Web

One of the biggest advantages of the Internet is how global it is—if your site is hosted in Atlanta, it might get visitors from down the block, but it just as easily might get visitors from New York, or London, or Tokyo. And that’s pretty incredible. But it also raises a fundamental problem:

(read more)

Why Static Site Generators Are Great

What makes static site generators so great? And what is a static site generator, anyway?

To answer that, let’s take a step back and think about how a website works. Skipping over some (interesting and important!) details not relevant here, to display a website all you need to do is to send visitors of the website an HTML document.

As an example, take this stripped-down version of the current codesections homepage. To keep things simple, I've striped out all the CSS and the parts of the HTML related to how the page would look, which leaves us with just the basic HTML.

(read more)
← Later posts Earlier posts →