<h1>The Books I Have Read Since April 2025</h1>
It has been a slow couple of months for my reading habit.
Although, now that I've said that out loud, I realize I say that every time.
I never quite read enough books by the time I feel ready to write one of these reading reviews.
In the interest of brevity, let's jump straight in.
<h2>How to Stop Time by Matt Haig</h2>
After reading The Midnight Library in <a href="/the_books_i_read_in_january_2025">January</a>, I was thoroughly impressed by Haig's work.
I wanted more, but wasn't sure what to read next.
So, the next time I saw a book with an interesting title which happened to be his, I picked it up.
If The Midnight Library was a literary therapy session, How to Stop Time is a history lesson.
It follows a man who ages at one-tenth the rate of a normal human.
Despite being given the gift of extra life, he regularly falls into spats of depression when his loved ones die before him.
While Haig's writing continues to be sentimental and appreciative of the small things in life (a trait few seem to possess these days), I ultimately found the book predictable and unengaging.
It was a good book, and I felt satisfied having read it, I had put it down for a few days at a time more than once to do so.
If you're going to read just one of Haig's books, it shouldn't be this one.
<h2>Everything is Tuberculosis by John Green</h2>
I've been a fan of John Green's work since I was kid.
I remember reading Looking for Alaska as I cruised down the Mississippi River on a school trip.
It was one of the most memorable books (and expeditions) I've had the pleasure of experiencing.
Naturally, I was ecstatic to hear John Green published something new: Everything is Tuberculosis, a book about the facets of our lives (of which there are many) that we can thank TB for.
I liked this book, but I don't think it matches the reflective attitude about the human experience you find in his other books—but that's a good thing!
Everyhitng is Tuberculosis is not a book you're supposed to relate to, but a book that tells a story about a life most in the western world find completely unfamiliar.
One where each and every day is counted.
One where the price of a medication is the most important number.
One where you might not survive.
The fact that I couldn't relate to the events in Everything is Tuberculosis is the exact reason why I'm glad I read it.
<h2>How to Win Friends and Influence People by Dale Carnegie</h2>
I read How to Win Friends and Influence People (a mouthful, I know) not because I needed advice on the subject.
I read it because I believe this book to be a telling window into the minds of the businessmen of the early 20th century.
I've been told that this book is still relevant today; that the advice still works.
I disagree.
The priorities, values, and culture are entirely different today than when this book was written.
I found it fascinating to compare and contrast between my own experience and the author's.

It has been a slow couple of months for my reading habit. Although, now that I've said that out loud, I realize I say that every time.

It has been a slow couple of months for my reading habit. Although, now that I've said that out loud, I realize I say that every time.

The Books I Have Read Since April 2025

<h1>Build a Wordle Solver Using Rust</h1>
<h2>The Game</h2>
<a href="https://www.nytimes.com/games/wordle/index.html">Wordle</a> is a relatively simple game. If you have ever played Mastermind, it should sound familiar. The goal is to figure out a mystery word with as few guesses as possible. The mystery word changes each day. Here are two example guesses.
<img src="/images/wordle_example.png" alt="Two example guesses from the game Wordle">
After a guess, each letter’s color changes.
Green — The letter is correct.
Yellow— The letter exists in the word, but not in that space.
Gray — The letter does not exist in the word.
As you can see, there are a maximum of six guesses. If you cannot find the mystery word within six guesses, you lose. I have been competing with my grandmother each day to find the word in as few guesses as possible.
<img src="/images/xkcd_nerd_sniping.png" alt="XKCD Comic #356">
This totally nerd-sniped me. I felt an overwhelming urge to build an app that could, conceivably find the mystery word in as few guesses as possible.
<h2>How I Did It</h2>
First things first, we need a list of English words. I initially used the <a href="http://www.mieliestronk.com/wordlist.html">corncob</a> list, but I found greater success with <a href="https://github.com/dwyl/english-words/">dwyl’s</a> list.
For this project, I decided to use Rust, just because I felt most confident in my ability to make an MVP quickly.
Both the word lists I used are formatted as a sequence of individual words, separated by <code>\n</code> characters. On Windows (which is what I am using), they also have pesky those little <code>\r</code> characters.
Wordle is heavily focused on letters. I can remove items from the word list based on what letters I know aren’t in the mystery word (these are gray letters in-game), and I can remove items based what letters I know are in the mystery word (the orange or green letters), but in a lot of cases that still leaves a lot of possible words. I need to way to sort words based on how likely their letters are.
To do this, I count how frequently each letter appears in the word list, and give each word a score based on how frequently its components appear.
The first step in the program is to load the word list and count the letters:
<pre><code class="hljs language-rust">// Store the total number of times a letter appears.
let mut letter_scores = HashMap::new();
// The final list of words. It will make like easier later in the program to store the words as Vec&#x3C;char>.
let mut word_list = Vec::new();
let mut last_word = Vec::new();
let file = std::fs::read("corncob_lowercase.txt")?;

// Iterate through all the bytes in the wordlist file, ignoring all `\r` instances.
for letter in file {
 let letter = letter as char;
 match letter {
 '\n' => {
 word_list.push(last_word);
 last_word = Vec::new();
 }
 '\r' => (),
 _ => {
 let entry = letter_scores.entry(letter).or_default();
 *entry += 1;
 last_word.push(letter);
 }
 }
}
</code></pre>
Using the default <code>HashMap</code> (which uses <code>SipHash</code>, which isn’t great for single-character lookup), probably isn’t the best, performance-wise, but this is just a toy program, and doesn’t need to be the fastest thing in the world.
Next, we need to go through the word list, and eliminate words that contain gray letters. Here is a function that helps do that:
<pre><code class="hljs language-rust">fn matches_found(
 word: &#x26;[char],
 found: &#x26;[char],
 not: &#x26;[char],
 must: &#x26;[char],
 masks: &#x26;[Vec&#x3C;char>],
) -> bool {
 // Check if the word contains a letter we know *isn't* in the mystery. &#x3C;-- The gray letters.
 for c in not {
 if word.contains(c) {
 return false;
 }
 }

 // Check if the word contains the letters we don't know the positions of, but know they are in the mystery word.. &#x3C;-- The orange letters.
 let mut found_letters = 0;
 for c in must {
 if word.contains(c) {
 found_letters += 1;
 }
 }
 if found_letters &#x3C; must.len() {
 return false;
 }

 // Check if the word has letters we know exist in the word, but not at the right spots. &#x3C;-- The orange letters.
 for mask in masks {
 for i in 0..min(word.len(), mask.len()) {
 if word[i] == mask[i] {
 return false;
 }
 }
 }

 // Check if the word contains the already found (green) letters.
 for i in 0..min(word.len(), found.len()) {
 if found[i] != ' ' &#x26;&#x26; word[i] != found[i] {
 return false;
 }
 }

 true
}
</code></pre>
It accepts a few different char slices:
<ul>
<li>Word: the word we want to check.
Found: this is a slice containing the letters we have found (the green ones), with “ “ (space) characters in the locations we don’t know the character of.</li>
<li>Not: this is a slice containing the letters we know aren’t in the mystery word.</li>
<li>Must: this is a slice containing the letter we know are in the mystery word, but we don’t know the position of.</li>
<li>Masks: this is a series of masks. We remove every word that has letters that match any mask here. This is useful for eliminating words in the wordlist that contain punctuation and for eliminating words that contain orange letters, but in positions we know they aren’t.</li>
</ul>
Now all we have to do is run each word in the word list and see if it matches our already known characters, updating the contents of each slice with new information after each guess.
<h2>Why You Should Care</h2>
This sounds like a useless problem. It is. There is no way this will benefit anyone other than me, and I definitely won’t use this when I’m actually competing with my grandmother.
Then why did you do it?
Useless answers to useless problems are useful. They teach us how to improve, without the pressure of real stakes. They are also just plain fun.
It’s also a reflection. How would you have approached this problem in the past? How has your thinking improved. Maybe it’s a bit magnanimous to say this little Wordle solver is the key to self reflection, but I don’t think it’s that far off.
<hr>
<h2>A Reflection From Months Later</h2>
Hi! I am returning to this project months later with a few thoughts.
When I first wrote this article, I completely neglected to share my fitness test for each word. In hindsight, it's a good thing I didn't. It was the exact method 3Blue1Brown described as "naive" in his (fantastic) <a href="https://youtu.be/v68zYyaEmEA">video</a> on this very topic.

I built a Wordle solver in Rust to beat my grandma. Follow the journey of how I did, and how I failed.

I built a Wordle solver in Rust to beat my grandma. Follow the journey of how I did, and how I failed.

Build a Wordle Solver Using Rust

<h1>3 Traits of Good Test Suites</h1>
As evidenced by my previous posts on <a href="https://elijahpotter.dev/articles/LLM_assisted_fuzzing">LLM-Assisted Fuzzing</a>, I've been dedicating a lot of my mental bandwidth to maintaining a low false-positive rate while we improve <a href="https://github.com/automattic/harper">Harper's rule coverage</a>. Part of that is through fuzzing and dogfooding, some can be through statistics, but the first lines of defense will continue to be unit and integration testing. This past week particularly, I've been reading up on how other <a href="https://github.com/rust-lang/rust-analyzer">big linting programs</a> approach this problem.
<h2>1. Test Features, Not Code</h2>
I often ask myself: am I spending more time thinking or talking about the thing, or am I spending more time doing the thing? I've personally seen how projects fall into decline because their leaders are more interested in planning than doing.
In the context of software testing, this mantra is transformed into "test features, not code." To my eye, good code is flexible and self-explanatory. Tests that hook deeply into application or library internals make code less flexible and harder to read.
I especially like Alex Kladov's heuristic for this: the neural network test.
<blockquote>
"Can you re-use the test suite if your entire software is replaced with an opaque neural network?" - Alex Kladov
</blockquote>
It's not a question of whether a neural network would pass the test suite, only whether the test suite could work for it. If the answer is no, the tests are likely testing code, not features.
<h2>2. Performance</h2>
The speed at which you can build and run tests (unit, static, integration, etc.) is a force-multiplier for everything else. You can validate ideas sooner, run CI faster, and get contributors on-boarded in less time.
Our goal to be fast at runtime dovetails quite nicely into this, so it's something Harper already does quite well. Moving forward, we need to make sure that we don't rely on any kind of IO in our tests, since that continues to be the slowest part of most Harper integrations.
<h2>3. Good Assertions</h2>
We can simplify programs like Harper down into a single function which consumes text and returns a list of observed problems.
<pre><code class="hljs language-rust">fn harper(text: String) -> Vec&#x3C;Lint>{
 // Implementation details...
}
</code></pre>
Most testing we are interested can be done with assertion functions that declare what qualities the output should have with a specific input.
For example, we have a function called assert_suggestion_result, which runs a grammatically incorrect string through Harper, applies the first resulting suggestion and checks whether the edited string matches a given value.
<pre><code class="hljs language-rust">/// An example of a test that uses assert_suggestion_result
#[test]
fn catches_less_then() {
 assert_suggestion_result(
 "I eat less then you.",
 ThenThan::default(),
 "I eat less than you.",
 );
}
</code></pre>
It's also vital that these assertions show good, readable error messages when they fail. Each time I've improved their logs, I get unprompted positive feedback from contributors.
Moving forward, I'd like to create a more diverse array assertions like this, as well as better-document their use. A lot of the current back-and-forth for rule contributions is related this.
<h2>Wait! I Disagree</h2>
I hope someone does. Good test suites are something I'm continuing <a href="https://automattic.com/creed/never-stop-learning/">to learn how to build</a>. I understand that a lot of what I've said here doesn't apply to other kinds of applications or codebases. If there's nuance I'm not covering here, let me know!

3 Traits of Good Test Suites

local-first_software_is_easier_to_scale

<h1>Local-First Software is Easier to Scale</h1>
<img src="/images/flatirons.webp" alt="The Flatirons">
The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.
<a href="https://writewithharper.com">Harper</a> recently received a massive increase in both traffic and user count.
How?
By making it to the front page of Hacker News.
If you couldn't tell by the extent to which I talk about this, I'm thrilled.
This amounted to a tremendous amount of free advertising, if nothing else.
I've been thinking a lot about the wondrous benefits of working at the edge.
That's just one term of many that people use to describe Harper: "edge-first".
Others include "local-first" or simply "on-device".
They are all just jargon for a simple idea: We run all the relevant grammar checking code as physically close to the users as possible.
That way, we can serve up suggestions faster than anyone else.
To achieve our goal, we make sure that everything is well-optimized and lean.
Harper barely uses any CPU or memory at all.
What does all this mean in the context of the recent uptick in user acquisition? Imagine, for a moment, we are LanguageTool.
Our software is written in Java, with questionable attendance to the efficiency of our code.
Since our software requires a big server to run, we have a certain number of servers on standby to handle a certain amount of expected load.
If suddenly the number of requests we received were to double (as it did for the Chrome extension), we would be big trouble.
To avoid increasing the latency on requests (or dropping requests all together), we would need to scale up the number of running servers.
This not only takes hiring an expert in cloud architecture, but also additional funding to pay the AWS (or whatever) bill at the end of the month.
Because Harper runs at the edge (no server required), we don't have to worry about that.
In fact, I only noticed that our user count had spiked after I visited Hacker News the morning after.
No hiccups at all.
Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all.

The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.

The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.

Elijah Potter

Local-First Software is Easier to Scale

Other Stuff

The Books I Have Read Since April 2025

Build a Wordle Solver Using Rust

3 Traits of Good Test Suites