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:

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.

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:

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.

Recursive Learning

There’s an interestingly recursive nature to learning programming. As part of my ongoing project to build my programming skills to a higher level, I would like to learn Node and modern JavaScript frameworks/libraries like React and Redux. So, that’s my starting point: What do I need to do to learn these new technologies?

Except that conventional wisdom holds (and I agree) that it makes more sense to become very comfortable with vanilla JavaScript before jumping to a framework. This makes a lot of sense, actually: A framework is a powerful tool, but at the end of the day it is compiling down to JavaScript—if I don’t understand the strengths and weaknesses of JavaScript, I won’t understand the problems that these frameworks were built to solve or the trade-offs they make. And I won’t be able to learn them nearly as well.

So, I’m off to learn vanilla JavaScript. Time to read books like Crockford’s JavaScript: The Good Parts and Eloquent JavaScript.

Except …

Hello World! (And past writing)

Welcome! Don’t you just love that new-blog smell?

This blog is my new home for technical topics, book reviews, whatever else catches my attention. I firmly believe that web developers should have their own digital space, one that they build, control, and fully understand. For me, this site is that space.

Colophon

As of this writing, this site is built using Hugo (EDIT: The site is now built with Gutenberg, which is much better than Hugo) the leading static site generator. It uses a self-written theme and the source code lives in a publicly available GitHub repository (EDIT: Now a GitLab repository). If you’re curious about what I was trying to achieve with this site, I’ve written a whole page about what I was aiming for and how well I did.

Past writing

While this is the first post on this blog, it’s far from the first public writing I’ve done. Past highlights include: