<h1>What Is Randomness?</h1>
<img src="/images/numbers_on_a_screen.jpg" alt="Numbers on a screen">
In case you were born yes­ter­day, let’s go over it.
Randomness is, at the most ba­sic level, some­thing that can­not be pre­dicted.
In com­puter sci­ence, when we talk about ran­dom­ness, we are usu­ally talk­ing about ran­dom num­bers and the tools we use to get them, ran­dom num­ber gen­er­a­tors (RNGs).
<h2>Pseudorandomness</h2>
We say an RNG is “pseudorandom” when we have to give it a ﬁxed seed, and it gen­er­ates ran­dom num­bers based on that seed.
If we give it the same seed, we will get the same num­bers.
It is de­ter­min­is­tic.
I thought, for a very long time, that com­put­ers could only cre­ate pseudo­ran­dom num­bers.
The main rea­son I thought this, and why you might too, is be­cause util­i­ties like the Random class in&nbsp;.NET are pseudo­ran­dom and are seeded by some ar­bi­trary in­for­ma­tion, like the cur­rent time.
Computers aren’t use­ful if they aren’t de­ter­min­is­tic.
In a per­fect, en­closed sys­tem, it would be im­pos­si­ble for a com­puter to gen­er­ate truly ran­dom num­bers.
<h2>True Randomness</h2>
The phrase “true ran­dom­ness” is used to de­scribe things that are im­pos­si­ble to pre­dict. Provably so. This is dif­fer­ent from chaotic sys­tems, which are pre­dictable un­der short spans of time.
True ran­dom­ness is im­pos­si­ble to pre­dict on all scales.
<h2>The Everyday Method</h2>
Allow me to in­tro­duce you to <a href="https://en.wikipedia.org/wiki/RDRAND">RDRAND</a> and <a href="https://en.wikipedia.org/wiki/RDRAND#RDSEED">RDSEED</a>, two CPU in­struc­tions orig­i­nally in­tro­duced by Intel, that al­low pro­grams ac­cess to truly ran­dom num­bers.
These in­struc­tions gather data from an on-chip en­tropy source to pro­vide ran­dom num­bers.
These in­struc­tions uti­lize ther­mal noise to pro­duce white noise, which is used to gen­er­ate said ran­dom num­bers.
The ad­van­tage of ther­mal noise is that it pro­duces ac­tu­ally ran­dom val­ues, as ex­plained here.
Its also fast, which means it can be used for every­day things, like gen­er­at­ing SSL or TLS keys and the like.
<h3>Do It Yourself</h3>
If you hap­pen to be on a Linux sys­tem, you can ac­tu­ally use these in­struc­tions your­self. Just run this com­mand:
<pre><code class="hljs language-bash">dd if=/dev/random count=4 bs=1 status=none | od -An --format=dI
</code></pre>
This com­mand uses <code>dd</code> to gen­er­ate 4 ran­dom bytes.
Then it pipes those bytes into <code>od</code>&nbsp;, which will for­mat those 4 bytes into hu­man-read­able text as a signed 32-bit in­te­ger.
<h2>The Nuclear Method</h2>
<img src="/images/nuclear_plant.jpg" alt="A Nuclear Plant">
One of the big ad­vance­ments of the 20th Century was the cre­ation of a branch of re­search called quan­tum physics.
One of the things we learned was that on the scale of in­di­vid­ual par­ti­cles, it be­comes prov­ably im­pos­si­ble to pre­dict state.
Every time a mea­sure­ment is taken of a sub­atomic par­ti­cle, its state changes ran­domly.
One way we could sam­ple sub­atomic par­ti­cles is by plac­ing a Geiger counter next to a bit of ra­dioac­tive ore.
Be­cause whether an in­di­vid­ual atom will de­cay at any given mo­ment, we can know that the time be­tween ticks of the Geiger counter is ran­dom.
<h2>The Cloudﬂare Method</h2>
<img src="/images/lava_lamp.jpg" alt="A Lava Lamp">
Cloudﬂare uses some es­pe­cially in­ter­est­ing sources of en­tropy to seed its ran­dom num­ber gen­er­a­tors.
One way is via lava lamps.
In their lobby, they have a large ar­ray of lava lamps.
There is a cam­era run­ning a live feed of the lava lamps to their servers.
There are two main sources of ran­dom­ness.
First, the lava lamps them­selves.
The move­ment of even a sin­gle lava lamp, if we for­get the sec­ond law of ther­mo­dy­nam­ics, is far too chaotic to pre­dict.
If we in­clude the sec­ond law of ther­mo­dy­nam­ics, it be­comes true ran­dom­ness.
Second, the cam­era sen­sor’s noise.
Thanks to the pho­to­elec­tric ef­fect the noise that ap­pears on a cam­er­a’s sen­sor, how­ever un­no­tice­able, is truly ran­dom.
By com­bin­ing these two sources, you get a pool of truly ran­dom num­bers ~60 times a sec­ond.
If that does­n’t ﬁt your needs, you can use those num­bers to feed a cryp­to­graph­i­cally se­cure pseudo­ran­dom num­ber gen­er­a­tor (CSPRNG) to get as many as you want.

We look at several interesting ways computers generate random numbers. It may fascinate you to know that some methods are not *truly* random, but only an approximate.

We look at sev­eral in­ter­est­ing ways com­put­ers gen­er­ate ran­dom num­bers. It may fas­ci­nate you to know that some meth­ods are not truly ran­dom, but only an ap­prox­i­mate.

3 Awesome Ways Computers Generate Randomness

<h1>A Case for Procrastination</h1>
<img src="/images/model_t.jpg" alt="A linup of Model T Fords">
The most valu­able, unique as­pect of soft­ware de­vel­op­ment is the speed at which we can it­er­ate.
Soft­ware pro­jects that don’t it­er­ate quickly and fre­quently usu­ally stag­nate and fail, while pro­jects that work with user feed­back on an al­most real-time ba­sis are the most suc­cess­ful.
I’ve no­ticed the dif­fer­ence per­son­ally, with my work at <a href="https://archytasinc.com/">Archytas Automation</a>.
Most re­cently, I’ve read The Lean Startup, Zen and the Art of Motorcycle Maintenance and The Pragmatic Programmer.
While each uses their own ter­mi­nol­ogy, both go into depth on the depth on the topic of fast it­er­a­tion cy­cles.
<h2>Lean Manufacturing and Lean Thinking</h2>
Lean man­u­fac­tur­ing, as ex­plained in The Lean Startup is a pro­duc­tion method­ol­ogy fo­cused on avoid­ing waste.
The book’s pri­mary ex­am­ple is the Toyota Production System.
In the mid 1930s, the world’s largest car man­u­fac­turer was Ford.
Ford’s fac­to­ries pro­duced thou­sands of unique parts, which to­gether could form a car.
They pro­duced these parts in bulk, and each dis­tinct part had an en­tire ma­chine ded­i­cated to pro­duc­ing it.
There was a ma­chine that made springs, a ma­chine that made nuts, and a ma­chine that made bolts.
No ma­chine could make any part other than the one it was de­signed for.
This was great: it meant that cars would be cheaper than ever, and more peo­ple could ex­pe­ri­ence car own­er­ship.
Around this time, Toyota en­tered the au­to­mo­tive in­dus­try.
How­ever, they did not have the time, nor the money to de­sign and build the same kind of hy­per-spe­ciﬁc man­u­fac­tur­ing ma­chines that Ford used.
In­stead, they chose to pur­chase com­par­a­tively few hy­per-gen­er­al­ized ma­chines.
Their strat­egy was to build one car at time, and sell it as soon as pos­si­ble (ideally the mo­ment it rolled off of the fac­tory ﬂoor).
This way, if there is an is­sue with the ve­hi­cle, the de­sign can be mod­i­ﬁed be­fore too many faulty cars are as­sem­bled.
The Toyota Production System em­pha­sized ﬂex­i­bil­ity over ef­ﬁ­ciency.
By stay­ing ﬂex­i­ble, Toyota gave it­self the abil­ity to op­ti­mize all as­pects of the busi­ness in the mid­dle of a pro­duc­tion run.
On one hand, the Ford process looked like this:
<ul>
<li>Get ma­te­ri­als for one hun­dred cars.</li>
<li>Fabricate over a thou­sand dis­tinct parts re­quired for each car (likely more than a hun­dred thou­sand to­tal parts).</li>
<li>Assemble one hun­dred cars&nbsp;.</li>
<li>Sell one hun­dred cars.</li>
<li>Receive feed­back on ve­hi­cle and pro­duc­tion process.</li>
<li>Perform all pos­si­ble changes to the ve­hi­cle’s de­sign and pro­duc­tion process (which would be very lit­tle).</li>
</ul>
With this many steps, each tak­ing place over a com­par­a­tively long time, the it­er­a­tion cy­cles are few and far be­tween.
On the other hand, the Toyota Production System looked like this:
<ul>
<li>Get ma­te­ri­als for one car</li>
<li>Fabricate the rel­a­tively few dis­tinct parts re­quired for the car</li>
<li>If there is an is­sue with the pro­duc­tion process (a ma­chine breaks, some­one gets hurt, etc.).
Stop the whole process and ﬁx the is­sue, so it will not af­fect fu­ture cars.</li>
<li>Assemble one car.</li>
<li>Sell one car.</li>
<li>Receive feed­back on ve­hi­cle and pro­duc­tion process.</li>
<li>Perform all pos­si­ble changes to the ve­hi­cle’s de­sign and pro­duc­tion process (which could be quite a lot, given the ﬂex­i­bil­ity of both).</li>
</ul>
Counterintuitively, per­form­ing each step with a batch size of one ac­tu­ally ended up be­ing more ef­ﬁ­cient.
Even though Ford ex­pe­ri­enced a higher level of ef­ﬁ­cient within each batch, their process led to many more wasted parts be­ing man­u­fac­tured,
as well as a lack of com­mu­ni­ca­tion be­tween steps, which dra­mat­i­cally in­creased the amount of wasted ef­fort.
Ad­di­tion­ally, be­cause the Toyota Production System al­lowed com­par­a­tively rapid it­er­a­tion, Toyota ve­hi­cles were sim­ply bet­ter: more durable, and more use­ful to their cus­tomers.
<h3>Lean Thinking In Software</h3>
In soft­ware de­vel­op­ment, it can be tempt­ing to go the Ford route:
cre­ate a de­tailed plan of all the fea­tures you wish to add to your ser­vice,
then, de­velop the fea­tures, and de­liver them all at once.
Only then do you ac­cept feed­back and eval­u­ate the use­ful­ness of each fea­ture.
In The Lean Startup how­ever, Eric Ries sug­gests an al­ter­na­tive method­ol­ogy, in­spired by the Toyota Production System.
Before de­cid­ing on which fea­tures to in­clude in your ser­vice in an all-at-once, shot-in-the-dark man­ner, per­form ex­per­i­ments.
Cre­ate an ab­solutely min­i­mal pro­to­type of the fea­ture, give to a cus­tomer, and ob­serve how they use it.
It is pos­si­ble they ﬁnd the fea­ture un­help­ful, or they use it in a way you did­n’t ex­pect.
By run­ning the ex­per­i­ment early on, there are far fewer un­help­ful fea­tures in­tro­duced, and the cus­tomer gets a prod­uct more closely tied to their needs.
Further, it is pos­si­ble that your un­der­stand­ing of the prob­lem do­main is mis­in­formed.
Plan­ning out the en­tire prod­uct re­lease months in ad­vance is prob­lem­atic when the re­quire­ments of the pro­ject change (and they will, of­ten).
<h2>Why Interpreted Languages Can Be So Productive</h2>
Interpreted pro­gram­ming lan­guages are al­most laugh­ably per­va­sive.
Of the top ten most pop­u­lar pro­gram­ming lan­guages on the 2023 StackOverﬂow Developer sur­vey, six were in­ter­preted.
That count does not in­clude TypeScript, which can be used in a semi-in­ter­preted man­ner.
In­ter­preted lan­guage pop­u­lar­ity is of­ten chalked up to their ease-of-use, ab­strac­tion, and sim­ple, English-like syn­tax.
How­ever, I be­lieve there is an ad­di­tional rea­son: they al­low one to it­er­ate much, much faster.
<h2>Micro-iterations</h2>
Iterations can hap­pen on any timescale.
Micro-iterations oc­cur hap­pen over the short­est time scale.
These are small, in­cre­men­tal changes that oc­cur (usually) when de­bug­ging or op­ti­miz­ing code.
It is the amount of time (and by ex­ten­sion, men­tal over­head) that re­sults from a change.
The longer it takes for tests to com­pile and run, the longer it takes to de­bug.
I be­lieve you can model it like so:
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><mtext>time to de­bug</mtext><mo>=</mo><mo stretchy="false">(</mo><mtext>time to test</mtext><msup><mo stretchy="false">)</mo><mn>2</mn></msup><mo>∗</mo><mtext>text edit­ing</mtext></mrow><annotation encoding="application/x-tex">\text{time to de­bug} = (\text{time to test})^2 * \text{text edit­ing}</annotation></semantics></math>time to de­bug=(time to test)2∗text edit­ing
<blockquote>
This is not an ex­act, rep­re­sen­ta­tive equa­tion, merely an ab­strac­tion to il­lus­trate my point, based on per­sonal ex­pe­ri­ence.
</blockquote>
In other words, the to­tal de­bug­ging time in­creases su­per-lin­early as the time it takes to test a change to the pro­gram in­creases.
No­tice how, as the <code>time to test</code> in­creases, the ac­tual amount of time <code>text editing</code> falls to a neg­li­gi­ble ra­tio of the to­tal.
I be­lieve this comes from the fact that as com­pi­la­tion time in­creases, the amount of in­for­ma­tion gleaned per mi­cro-it­er­a­tion tends to de­crease.
<h3>JIT Compilation and Hot Reload</h3>
This is where we get to the ti­tle of the ar­ti­cle.
The con­cepts of lean think­ing ex­tend into com­piler tech­nol­ogy.
The Toyota Production System in­cludes the con­cept of “Just-in-time”, mean­ing,
“to only pro­duce ex­actly what is needed for the prod­uct, ex­actly when in the process it is re­quired.”
Avoid plan­ning re­source re­quire­ments ahead of time and build sys­tems that only pro­duce what is ac­tu­ally needed.
While the mean­ing of “Just-in-time” is dif­fer­ent when we re­fer to com­pil­ers, the line of think­ing is ul­ti­mately the same.
In­stead of wast­ing valu­able, hu­man-scale time on com­pi­la­tion and op­ti­miza­tion of ir­rel­e­vant code, just com­pile the code you need, when you need it.
This dras­ti­cally re­duces the amount of time to test, and ul­ti­mately, the time to de­bug.
Further, tech­nolo­gies like React and Flutter’s Hot Reload make it pos­si­ble to com­plete these mi­cro-it­er­a­tions with­out hav­ing to restart your pro­gram.
I be­lieve this is partly why in­ter­preted lan­guages are so be­gin­ner-friendly (other than the high level of ab­strac­tion they typ­i­cally pro­vide).
New­com­ers to pro­gram­ming spend most of their time on syn­tac­tic is­sues and sim­ple run­time er­rors.
By mak­ing mi­cro-it­er­a­tions hap­pen as fast as pos­si­ble, you make these is­sues less an­noy­ing to deal with.
<h3>Procrastination</h3>
If you are in uni­ver­sity (like I cur­rently am), or any other level of ed­u­ca­tion, it can ac­tu­ally be ben­e­ﬁ­cial to hold off on do­ing your home­work.
It is not un­com­mon (at least in my ex­pe­ri­ence) for the pro­ject or pa­per re­quire­ments to change at the last minute.
Some of your peers may choose to com­plete the pro­ject or pa­per as soon as pos­si­ble.
If this is the case, you may ben­e­ﬁt from their ex­pe­ri­ence.
If a cer­tain chain of logic or analy­sis is con­fus­ing or mis­lead­ing, they can warn you to avoid los­ing time.
As­sum­ing they are will­ing, they can also pro­vide in­sight­ful feed­back on your work mid-way through your writ­ing or study process.
<h2>Conclusion</h2>
Iteration is in­cred­i­bly im­por­tant to any de­sign and de­vel­op­ment cy­cle, es­pe­cially in soft­ware.
Since I have em­braced it­er­a­tion, I’ve seen a dra­matic im­prove­ment in my pro­duc­tiv­ity and ef­fec­tive­ness.
So I en­cour­age you: if your build process takes 30 min­utes, spend some time on im­prov­ing it.
If you are work­ing on a pro­ject that has­n’t been put in front of a cus­tomer, try show­ing it to a fam­ily mem­ber or non-tech­ni­cal friend.
Ask them for bru­tal hon­esty, and your pro­ject will be much bet­ter off.

Or: why doing things at the last minute actually saves time. I talk about the importance of shockingly fast iteration cycles and lean manufacturing.

Or: why do­ing things at the last minute ac­tu­ally saves time. I talk about the im­por­tance of shock­ingly fast it­er­a­tion cy­cles and lean man­u­fac­tur­ing.

A Case for Procrastination

<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 rel­a­tively sim­ple game. If you have ever played Mastermind, it should sound fa­mil­iar. The goal is to ﬁg­ure out a mys­tery word with as few guesses as pos­si­ble. The mys­tery word changes each day. Here are two ex­am­ple guesses.
<img src="/images/wordle_example.png" alt="Two example guesses from the game Wordle">
After a guess, each let­ter’s color changes.
Green — The let­ter is cor­rect.
Yel­low— The let­ter ex­ists in the word, but not in that space.
Gray — The let­ter does not ex­ist in the word.
As you can see, there are a max­i­mum of six guesses. If you can­not ﬁnd the mys­tery word within six guesses, you lose. I have been com­pet­ing with my grand­mother each day to ﬁnd the word in as few guesses as pos­si­ble.
<img src="/images/xkcd_nerd_sniping.png" alt="XKCD Comic #356">
This to­tally nerd-sniped me. I felt an over­whelm­ing urge to build an app that could, con­ceiv­ably ﬁnd the mys­tery word in as few guesses as pos­si­ble.
<h2>How I Did It</h2>
First things ﬁrst, we need a list of English words. I ini­tially used the <a href="http://www.mieliestronk.com/wordlist.html">corn­cob</a> list, but I found greater suc­cess with <a href="https://github.com/dwyl/english-words/">dwyl’s</a> list.
For this pro­ject, I de­cided to use Rust, just be­cause I felt most con­ﬁ­dent in my abil­ity to make an MVP quickly.
Both the word lists I used are for­mat­ted as a se­quence of in­di­vid­ual words, sep­a­rated by <code>\n</code> char­ac­ters. On Windows (which is what I am us­ing), they also have pesky those lit­tle <code>\r</code> char­ac­ters.
Wordle is heav­ily fo­cused on let­ters. I can re­move items from the word list based on what let­ters I know aren’t in the mys­tery word (these are gray let­ters in-game), and I can re­move items based what let­ters I know are in the mys­tery word (the or­ange or green let­ters), but in a lot of cases that still leaves a lot of pos­si­ble words. I need to way to sort words based on how likely their let­ters are.
To do this, I count how fre­quently each let­ter ap­pears in the word list, and give each word a score based on how fre­quently its com­po­nents ap­pear.
The ﬁrst step in the pro­gram is to load the word list and count the let­ters:
<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 de­fault <code>HashMap</code> (which uses <code>SipHash</code>, which is­n’t great for sin­gle-char­ac­ter lookup), prob­a­bly is­n’t the best, per­for­mance-wise, but this is just a toy pro­gram, and does­n’t need to be the fastest thing in the world.
Next, we need to go through the word list, and elim­i­nate words that con­tain gray let­ters. Here is a func­tion 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 ac­cepts a few dif­fer­ent char slices:
<ul>
<li>Word: the word we want to check.
Found: this is a slice con­tain­ing the let­ters we have found (the green ones), with “ “ (space) char­ac­ters in the lo­ca­tions we don’t know the char­ac­ter of.</li>
<li>Not: this is a slice con­tain­ing the let­ters we know aren’t in the mys­tery word.</li>
<li>Must: this is a slice con­tain­ing the let­ter we know are in the mys­tery word, but we don’t know the po­si­tion of.</li>
<li>Masks: this is a se­ries of masks. We re­move every word that has let­ters that match any mask here. This is use­ful for elim­i­nat­ing words in the wordlist that con­tain punc­tu­a­tion and for elim­i­nat­ing words that con­tain or­ange let­ters, but in po­si­tions 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 al­ready known char­ac­ters, up­dat­ing the con­tents of each slice with new in­for­ma­tion af­ter each guess.
<h2>Why You Should Care</h2>
This sounds like a use­less prob­lem. It is. There is no way this will ben­e­ﬁt any­one other than me, and I def­i­nitely won’t use this when I’m ac­tu­ally com­pet­ing with my grand­mother.
Then why did you do it?
Useless an­swers to use­less prob­lems are use­ful. They teach us how to im­prove, with­out the pres­sure of real stakes. They are also just plain fun.
It’s also a re­ﬂec­tion. How would you have ap­proached this prob­lem in the past? How has your think­ing im­proved. Maybe it’s a bit mag­nan­i­mous to say this lit­tle Wordle solver is the key to self re­ﬂec­tion, but I don’t think it’s that far off.
<hr>
<h2>A Reﬂection From Months Later</h2>
Hi! I am re­turn­ing to this pro­ject months later with a few thoughts.
When I ﬁrst wrote this ar­ti­cle, I com­pletely ne­glected to share my ﬁt­ness test for each word. In hind­sight, it’s a good thing I did­n’t. It was the ex­act method 3Blue1Brown de­scribed 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 jour­ney of how I did, and how I failed.

Build a Wordle Solver Using Rust

How I built a software render engine from scratch, and you can too.

How I built a soft­ware ren­der en­gine from scratch, and you can too.

Building a Software Render Engine from Scratch

It didn't work for me, and if you reading this, it probably won't work for you either.

It did­n’t work for me, and if you read­ing this, it prob­a­bly won’t work for you ei­ther.

Do Not Type Your Notes

<h1>For The Love of <code>iframe</code>s.</h1>
I adore a good <code>iframe</code>.
They’re so el­e­gant as a web com­po­nent.
Just ex­pose an end­point, say <a href="https://writewithharper.com/editor?initialText=This%20is%20an%20interactive%20buffer%20you%20can%20use%20to%20to%20check%20your%20work"><code>https://writewithharper.com/editor</code></a>, set it up to ac­cept some query pa­ra­me­ters and get it hosted.
Now you can ac­cess this web-com­po­nent from any page that has a loose enough Content Security Policy.
For me, that means my <a href="https://elijahpotter.dev/articles/the_simplest_neovim_markdown_setup">school as­sign­ments</a> and other as­sorted doc­u­men­ta­tion.
It also means that I can avoid set­ting up a com­plex build sys­tem for MDX, while still be­ing able to in­clude in­ter­ac­tive com­po­nents.
The ex­am­ple from ear­lier:
<pre><code class="hljs language-html">&#x3C;iframe
 src="https://writewithharper.com/editor?initialText=See, we can now embed the the Harper editor%0Arght into this document!%0A%0AIt's a little too easy."
 width="100%"
 height="400px"
 style="border-radius:10px;border:0px"
>&#x3C;/iframe>
</code></pre>
One ma­jor caveat though: when we pass our ar­gu­ments to the com­po­nent through the query URL, this gets sent to the com­po­nen­t’s server as well.
I cer­tainly trust the Harper web­site’s server, since I main­tain it and the code is <a href="https://github.com/elijah-potter/harper/tree/master/packages/web">open source</a>, but that is­n’t al­ways the case.
<iframe src="https://writewithharper.com/editor?initialText=See, we can now embed the the Harper editor%0Arght into this document!%0A%0AIt's a little too easy." width="100%" height="400px" style="border-radius:10px;border:0px"></iframe>
You should also prob­a­bly avoid do­ing this too much.
Most browsers spawn a whole new process for every <code>iframe</code>, so if you want things to stay snappy it is best to limit your­self to just one (maybe two) per page.

Chronically underrated, chronically over-prescribed

Chronically un­der­rated, chron­i­cally over-pre­scribed

For the Love of Iframes

<h1>How to Write a Discord Bot in Rust</h1>
Discord is an in­stant mes­sage plat­form with more than 150 mil­lion monthly ac­tive users. The main ap­peal seems to a com­bi­na­tion of the wide reach that plat­forms like StackOverﬂow have, as well as the in­stant de­liv­ery of the in­stant mes­sag­ing con­cept. One of the best fea­tures of Discord is it’s seem­ingly un­lim­ited hack­a­bil­ity of the plat­form via it’s “Bot” sys­tem. The Bot sys­tem al­lows de­vel­op­ers to add func­tion­al­ity to Discord com­mu­ni­ties by writ­ing soft­ware that in­ter­faces in a sim­i­lar way that peo­ple do. I want to give you an in­tro­duc­tion on how to do that in Rust.
<img src="/images/flat_ferris.png" alt="A Flat Render of Rust&#x27;s Mascot, Ferris">
<h2>Interaction</h2>
Most in­ter­ac­tion with Discord bots hap­pens via com­mands, not dis­sim­i­lar to ter­mi­nal ap­pli­ca­tions. Commands may look like <code>!play Eat it by Weird Al</code>.
<img src="/images/ping_pong.png" alt="Ping! Pong!">
The bot we are go­ing to make now will sim­ply re­spond to <code>!ping</code> with “Pong!”.
<h2>Template</h2>
<img src="https://github.com/elijah-potter/discord-bot-template" alt="cargo generator template">
<h2>Setup the Project</h2>
Using a func­tion­ing Rust en­vi­ron­ment, use cargo to cre­ate a new pro­ject. E.g:
<pre><code class="hljs language-bash">cargo new tutorial-bot
</code></pre>
Next, we have to add <a href="https://github.com/serenity-rs/serenity">Serenity</a>, the li­brary for cre­at­ing Discord bots in Rust. We also have to drop in Tokio, be­cause Serenity takes ad­van­tage of it’s async run­time.
You can do this ei­ther via cargo-edit:
<pre><code class="hljs language-bash">cargo add serenity
cargo add tokio --features full
</code></pre>
or by just adding them to Cargo.toml:
<pre><code class="hljs language-toml">[dependencies]
serenity = "0.10.5"
tokio = { version = "1.5.0", features = ["full"] }
</code></pre>
<h2>Setting up the Standard Framework</h2>
Serenity has a lot of ﬂex­i­bil­ity. You have ac­cess to a event han­dler that al­lows ﬁne grain con­trol of events. You also have ac­cess to a stan­dard frame­work that makes it ridicu­lously easy to re­spond to com­mands.
Be­fore we do any­thing else, we have to make our main func­tion async. It is su­per easy to do that, just re­place it with:
<pre><code class="hljs language-rust">#[tokio::main]
async fn main() {
}
</code></pre>
First, we want to get our bot to­ken in. In an ac­tual bot, please ob­tain it via an en­vi­ron­ment vari­able or some other method. We are only do­ing it this way for sim­plic­ity.
<pre><code class="hljs language-rust">let token = "{your bot token}";
</code></pre>
If you do not know how to get a bot to­ken, please fol­low <a href="https://www.getdroidtips.com/discord-bot-token/">this tu­to­r­ial</a>.
The Serenity Standard Framework splits your bot’s com­mands into groups. Each group can have mul­ti­ple com­mands. For ex­am­ple, a bot might have two groups: one fo­cused on fun and one fo­cused on math. The for­mer has com­mands like !meme, while the lat­ter may have var­i­ous math func­tions, like sin!. This is also how we will add com­mands to our bot.
First, add the needed structs and macros to the ﬁle:
<pre><code class="hljs language-rust">use serenity::{Client, client::Context, framework::{StandardFramework, standard::{CommandResult, macros::{group, command}}}, model::channel::Message};
</code></pre>
Next, cre­ate a struct that we will at­tach our com­mands to:
<pre><code class="hljs language-rust">#[group]
#[commands()]
struct HelloWorld;
</code></pre>
Once we have added our com­mands, we will en­ter them into the com­mands sub-macro.
Create an in­stance of <code>StandardFramework</code> and add our group to it. We can also con­ﬁg­ure our com­mand pre­ﬁx now.
<pre><code class="hljs language-rust">let framework = StandardFramework::new()
 .configure(|c|{
 c.prefix("!")
 })
 .group(&#x26;HELLOWORLD_GROUP);
</code></pre>
Notice that we used a ref­er­ence to a sta­tic struct called HELLOWORLD_GROUP in­stead of just adding our group. This is the out­put of the #[group] macro.
Now that we have cre­ated our frame­work, we have to at­tach it to a Discord client.
<pre><code class="hljs language-rust">let mut client = Client::builder(token).framework(framework).await.expect("Could not start Discord");
</code></pre>
Start it.
<pre><code class="hljs language-rust">client.start().await.expect("The bot stopped");
</code></pre>
<h2>Adding the Command</h2>
Now that we have the frame­work set up, let’s add a com­mand.
<pre><code class="hljs language-rust">#[command]
async fn ping(ctx: &#x26;Context, msg: &#x26;Message) -> CommandResult{
}
</code></pre>
This com­mand only needs the Discord clien­t’s Context, the mes­sage that con­tains the com­mand, and re­turns a <code>CommandResult</code>.
 Do not for­get to add the com­mand to the group:
<pre><code class="hljs language-rust">#[group]
#[commands(ping)]
struct HelloWorld;
</code></pre>
If you don’t, it will sim­ply not get run.
We want the bot to re­ply to the !ping com­mand with “Pong!”, so let’s add that to the in­side of the ping func­tion:
<pre><code class="hljs language-rust">msg.reply(ctx, "Pong!").await?;
Ok(())
</code></pre>
<h2>Full Code</h2>
Here is the full code for the bot:
<pre><code class="hljs language-rust">use serenity::{Client, client::Context, framework::{StandardFramework, standard::{CommandResult, macros::{group, command}}}, model::channel::Message};
#[tokio::main]
async fn main() {
 let token = "Your bot token";
 let framework = StandardFramework::new()
 .configure(|c|{
 c.prefix("!")
 })
 .group(&#x26;HELLOWORLD_GROUP);
 let mut client = Client::builder(token).framework(framework).await.expect("Could not start Discord");
 client.start().await.expect("The bot stopped");
}
#[group]
#[commands(ping)]
struct HelloWorld;
#[command]
async fn ping(ctx: &#x26;Context, msg: &#x26;Message) -> CommandResult{
 msg.reply(ctx, "Pong!").await?;
 Ok(())
}
</code></pre>
<h2>That’s it</h2>
If you build and run your app, you should have a func­tion­ing Discord bot!
Seren­ity is an amaz­ing crate and is an ab­solute joy to work with. I hope you learned some­thing. There is a ton more stuff that I did not cover here. Feel free to look at the <a href="https://docs.rs/serenity/latest/serenity/">Serenity docs</a> and ex­am­ples to learn more!

We go through step-by-step how to build a Discord bot using the Rust Serenity Framework.

We go through step-by-step how to build a Discord bot us­ing the Rust Serenity Framework.

How to Write a Discord Bot in Rust

<h1>How I Designed (and built) My Own Pen Plotter</h1>
For the last few months, af­ter read­ing Preslav Rachev’s book <a href="https://p5v.gumroad.com/l/generative-art-in-golang">Generative Art in Go</a>, I have been play­ing around with writ­ing al­go­rithms that cre­ate in­ter­est­ing graph­ics. I even­tu­ally ended up build­ing a <a href="https://github.com/elijah-potter/denim">mod­u­lar can­vas li­brary</a> for Rust to make that eas­ier to do, for me and other peo­ple.
After mak­ing a few al­go­rithms and post­ing them to the web, I started look­ing around for more in­spi­ra­tion. I hap­pened upon a video with this pen plot­ter:
<img src="/images/reddit_pen_plotter.png" alt="A screencap of a pen plotter from Reddit">
I was amazed. A ro­bot that could draw vec­tor graph­ics? I had been nerd sniped.
<img src="/images/xkcd_nerd_sniping.png" alt="XKCD Comic #356">
<h2>The Math</h2>
The math­e­mat­ics in­volved in­ter­ested my es­pe­cially. How do you trans­late <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo fence="true">[</mo><mtable rowspacing="0.16em" columnalign="center center" columnspacing="1em"><mtr><mtd><mstyle scriptlevel="0" displaystyle="false"><mi>x</mi></mstyle></mtd><mtd><mstyle scriptlevel="0" displaystyle="false"><mi>y</mi></mstyle></mtd></mtr></mtable><mo fence="true">]</mo></mrow><annotation encoding="application/x-tex">\begin{bmatrix} x &#x26; y \end{bmatrix}</annotation></semantics></math>[x​y​] to ro­ta­tions of mo­tors? It in­tim­i­dated me a lit­tle at ﬁrst, but once I sat down and worked it out, I re­al­ized it was sur­pris­ingly sim­ple.
<img src="/images/plotter_math_diagram.png" alt="A diagram of the math involved to create the plotter">
We con­sider that the two mo­tors are sim­ply length­en­ing or short­en­ing each string a spe­ciﬁc amount. Here are the equa­tions that dic­tate the length of each string, given a point <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo fence="true">[</mo><mtable rowspacing="0.16em" columnalign="center center" columnspacing="1em"><mtr><mtd><mstyle scriptlevel="0" displaystyle="false"><mi>x</mi></mstyle></mtd><mtd><mstyle scriptlevel="0" displaystyle="false"><mi>y</mi></mstyle></mtd></mtr></mtable><mo fence="true">]</mo></mrow><annotation encoding="application/x-tex">\begin{bmatrix} x &#x26; y \end{bmatrix}</annotation></semantics></math>[x​y​], and a dis­tance <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>m</mi></mrow><annotation encoding="application/x-tex">m</annotation></semantics></math>m be­tween the two mo­tors.
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msqrt><mrow><msup><mi>x</mi><mn>2</mn></msup><mo>+</mo><msup><mi>y</mi><mn>2</mn></msup></mrow></msqrt><mo>=</mo><msub><mi>r</mi><mn>0</mn></msub></mrow><annotation encoding="application/x-tex">\sqrt{x^2+y^2} = r_0</annotation></semantics></math>x2+y2<svg xmlns="http://www.w3.org/2000/svg" width="400em" height="1.28em" viewbox="0 0 400000 1296" preserveaspectratio="xMinYMin slice"><path d="M263,681c0.7,0,18,39.7,52,119
c34,79.3,68.167,158.7,102.5,238c34.3,79.3,51.8,119.3,52.5,120
c340,-704.7,510.7,-1060.3,512,-1067
l0 -0
c4.7,-7.3,11,-11,19,-11
H40000v40H1012.3
s-271.3,567,-271.3,567c-38.7,80.7,-84,175,-136,283c-52,108,-89.167,185.3,-111.5,232
c-22.3,46.7,-33.8,70.3,-34.5,71c-4.7,4.7,-12.3,7,-23,7s-12,-1,-12,-1
s-109,-253,-109,-253c-72.7,-168,-109.3,-252,-110,-252c-10.7,8,-22,16.7,-34,26
c-22,17.3,-33.3,26,-34,26s-26,-26,-26,-26s76,-59,76,-59s76,-60,76,-60z
M1001 80h400000v40h-400000z"/></svg>​=r0​
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><msqrt><mrow><mo stretchy="false">(</mo><mi>x</mi><mo>−</mo><mi>m</mi><msup><mo stretchy="false">)</mo><mn>2</mn></msup><mo>+</mo><msup><mi>y</mi><mn>2</mn></msup></mrow></msqrt><mo>=</mo><msub><mi>r</mi><mn>1</mn></msub></mrow><annotation encoding="application/x-tex">\sqrt{(x-m)^2+y^2} = r_1</annotation></semantics></math>(x−m)2+y2<svg xmlns="http://www.w3.org/2000/svg" width="400em" height="1.28em" viewbox="0 0 400000 1296" preserveaspectratio="xMinYMin slice"><path d="M263,681c0.7,0,18,39.7,52,119
c34,79.3,68.167,158.7,102.5,238c34.3,79.3,51.8,119.3,52.5,120
c340,-704.7,510.7,-1060.3,512,-1067
l0 -0
c4.7,-7.3,11,-11,19,-11
H40000v40H1012.3
s-271.3,567,-271.3,567c-38.7,80.7,-84,175,-136,283c-52,108,-89.167,185.3,-111.5,232
c-22.3,46.7,-33.8,70.3,-34.5,71c-4.7,4.7,-12.3,7,-23,7s-12,-1,-12,-1
s-109,-253,-109,-253c-72.7,-168,-109.3,-252,-110,-252c-10.7,8,-22,16.7,-34,26
c-22,17.3,-33.3,26,-34,26s-26,-26,-26,-26s76,-59,76,-59s76,-60,76,-60z
M1001 80h400000v40h-400000z"/></svg>​=r1​
<h2>Is This Actually Going to Happen?</h2>
I ini­tially sat down and did the math out of cu­rios­ity. I was­n’t plan­ning on build­ing any­thing. After re­al­iz­ing the el­e­gant sim­plicty of the math, I falt em­pow­ered to go through with it. I threw to­gether a parts list.
<img src="/images/pen_plotter_parts.png" alt="A visual of all the parts needed for the plotter">
<h3>Materials</h3>
<ul>
<li>Whiteboard</li>
<li>Expo Marker</li>
<li>2 Stepper Motors</li>
<li>3D Printer Timing Belt</li>
<li>Arduino</li>
<li>Adafruit Motor Shield</li>
<li>12V 2A Power Adapter</li>
<li>Duct Tape (as any pro­ject re­quires)</li>
</ul>
I wanted to build this from scratch, with­out us­ing any­one else’s de­signs or soft­ware.
I or­der the ma­te­ri­als off Amazon and soon enough, I had every­thing I needed.
<h2>Putting It All Together</h2>
The ﬁrst step was to sol­der the mo­tor shield onto the Arduino, and wiring up step­per mo­tors. I used my school’s laser cut­ter to make a lit­tle bracket.
<img src="/images/mounted_motors_pen_plotter.jpeg" alt="The stepper motors mounted to a bracket">
I am us­ing weights to bal­ance the belts on the mo­tors. I mounted it to a white­board so I can it­er­ate in soft­ware faster/​eas­ier.
<img src="/images/mounted_bracket_on_whiteboard_pen_plotter.jpeg" alt="Everything taped onto an old whiteboard. It&#x27;s super rough, but that&#x27;s OK">
I ini­tially did­n’t have the tim­ing belt, so I pro­to­typed with an old length of wire. This is the last pic­ture be­fore I wrote all the soft­ware, which I want to talk about be­fore I show you that ver­sion.
<h2>The Software</h2>
There are two, sep­a­rate pro­grams that, to­gether, make the plot­ter work. The ﬁrst is run­ning on the Arduino, ac­cept­ing com­mands over se­r­ial from the sec­ond, which is run­ning on a USB-connected com­puter (my lap­top).
There are three main rea­sons there needs to be a lap­top in the sys­tem:
<ol>
<li>The Arduino does­n’t have enough pro­gram mem­ory</li>
<li>The Arduino can­not eas­ily ac­cept ﬁles (like SVGs)</li>
<li>It takes for­ever for an Arduino pro­gram to com­pile and up­load, which makes it­er­a­tion frus­trat­ing.</li>
</ol>
<h3>Arduino</h3>
The Arduino is run­ning a very sim­ple loop:
<ol>
<li>Receive two 32 bit signed in­te­gers over se­r­ial (one for each mo­tor)</li>
<li>Linear in­ter­po­late the step­per mo­tors to po­si­tions de­scribed by re­ceived in­te­gers</li>
</ol>
That’s it. It’s im­por­tant that the time it takes for each mo­tor to reach it’s des­ti­na­tion is the same.
<h3>Laptop</h3>
The lap­top is do­ing all the math.
I am used my can­vas li­brary <a href="https://github.com/elijah-potter/denim">Denim</a> to do all the vir­tual draw­ing. I just added a ren­derer that:
<ol>
<li>Converts all points to a se­quence of belt-lengths</li>
<li>Converts belt-lengths to se­quence of mo­tor move­ments</li>
</ol>
And sent the re­sult­ing mo­tor move­ments over se­r­ial to the Arduino.
I also wrote a quick lit­tle parser us­ing <a href="https://github.com/Geal/nom">nom</a> to parse and ex­e­cute the math com­mands you can ﬁnd in­side SVG <code>&#x3C;path></code> el­e­ments.
<h2>Final Results</h2>
<img src="/images/pen_plotter_drawing_a.jpeg" alt="The first drawing on the plotter: the letter A">
As you can see, I also made a big, rec­tan­gu­lar box, to hold the marker. It worked al­right, but not great. You also prob­a­bly no­ticed the main lim­i­ta­tion of my de­sign: it can­not lift the marker off the white­board.
I ﬁg­ured the rough­ness was mainly due to un­bal­anced weights and the slant of the white­board. I ad­justed every­thing and tried again.
<h3>Take Two</h3>
<img src="/images/pen_plotter_drawing_a2.jpeg" alt="A slightly improved letter A">
This one is much bet­ter. The lines are crisp, and ex­actly where they are sup­posed to be. At this point I wanted to try some­thing a lit­tle more ad­vanced out. Something a lit­tle more gen­er­a­tive.
<h3>The First Hilbert Curve</h3>
<img src="/images/pen_plotter_drawing_hilbert.jpeg" alt="An attempt at drawing a hilbert curve">
After see­ing the plot­ter draw a Hilbert Curve, I felt proud and a lit­tle dis­ap­pointed. The cor­ners aren’t crisp, the lines aren’t straight. Frankly, it looks like it was drawn by a two-year old.
<h3>Solving the Issue</h3>
<img src="/images/pen_plotter_drawing_hilbert2.jpeg" alt="The final attempt at a Hilbert Curve">
It worked! Now all the lines are pre­cise, crisp, smooth. The biggest is­sue is that the marker it­self ro­tates as it moves. That would­n’t nor­mally be an is­sue, but the marker is chis­eled, so it re­sults in vary­ing lev­els of pres­sure on the white­board.
<h2>Conclusion</h2>
This was a re­ally cool pro­ject. I learned a lot. I am not very ex­pe­ri­enced with ro­bot­ics, so this re­ally chal­lenged me. I in­tend on con­tin­u­ing work­ing on it. I want to add the abil­ity for the pen to lift off the can­vas, and re­ally so­lid­ify the marker holder. Most of all, I look for­ward to tak­ing my pro­jects into the real world.

In which I go through the process of designing, building, and testing a vector graphic pen plotter.

In which I go through the process of de­sign­ing, build­ing, and test­ing a vec­tor graphic pen plot­ter.

I Designed My Own Pen Plotter

Back in my day, we used math for autocomplete.

Back in my day, we used math for au­to­com­plete.

Markov Chains Are the Original Language Models

<h1>Naming Harper</h1>
<a href="https://github.com/elijah-potter/harper/issues/103">Someone</a> re­cently asked me where the name <a href="https://writewithharper.com">Harper</a> came from.
When I ﬁrst sat down to start work on Harper, I had one goal in mind.
I wanted to cre­ate a gram­mar checker that would­n’t im­pinge on the artis­tic free­dom of au­thors.
Part of that meant that I did not want lit­er­ary de­vices to be ﬂagged as gram­mat­i­cal er­rors.
Harper should speed up the writ­ing process rather than slow it down as Grammarly tends to.
To em­body this orig­i­nal goal, I wanted to make the pro­ject a name­sake of an au­thor known for their lit­er­ary de­vices and prose. I also had three other (practical) cri­te­rion:
<ol>
<li>It could not be oc­cu­pied on <a href="https://crates.io/">crates.io</a>.</li>
<li>It could not be oc­cu­pied on GitHub.</li>
<li>It should not be more than two syl­la­bles.</li>
</ol>
I asked around for some ideas and some­one sug­gested I name the pro­ject af­ter <a href="https://en.wikipedia.org/wiki/Harper_Lee">Harper Lee</a>.
It ﬁt the bill, so I went with it.

Naming Harper

An experiment on how to live in a seemingly hopeless world.

An ex­per­i­ment on how to live in a seem­ingly hope­less world.

Quantifying Hope on a Global Scale

<h1>Stupid-Simple Spell-Check</h1>
<img src="/images/antiques.webp" alt="A sign advertising for antiques, but misspelled.">
For the last month, I’ve been spend­ing a lot of time re­plac­ing one key com­po­nent
of my writ­ing and pro­gram­ming en­vi­ron­ment: my gram­mar checker.
Up un­til now, I’ve been us­ing the epony­mous <a href="https://languagetool.org/">LanguageTool</a>
via <a href="https://github.com/valentjn/ltex-ls"><code>ltex-ls</code></a> and <a href="https://github.com/neovim/nvim-lspconfig"><code>nvim-lspconfig</code></a>.
Don’t get me wrong, these tools are re­ally good, and I would rec­om­mend them to any­one and every­one.
How­ever, they come with a few key an­noy­ances.
<h2>LanguageTool Grievances</h2>
<h3>Performance</h3>
LanguageTool is slow.
I’m not ex­actly sure why.
Every time I would run LanguageTool over my Markdown or <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mtext>LaTeX</mtext></mrow><annotation encoding="application/x-tex">\LaTeX</annotation></semantics></math>LATE​X doc­u­ments (which are rea­son­ably sized),
I would have to wait sev­eral sec­onds be­fore even the rudi­men­tary spell-check­ing would show up.
Additionally, I would ﬁnd <code>ltex-ls</code> reg­u­larly be­com­ing the most mem­ory-hun­gry ap­pli­ca­tion on my lap­top,
of­ten ex­ceed­ing 4 gi­ga­bytes.
After hours of scour­ing their code base, I have come to no bet­ter ex­pla­na­tion
than that it is writ­ten in Java.
There are a cou­ple ques­tion­able al­go­rith­mic de­ci­sions in there as well.
<h3>Download Size</h3>
As I said: LanguageTool is re­ally quite good.
How­ever, to get every­thing it can of­fer, you need to not only in­stall a Java Runtime
Environment (>150 MB on my sys­tem), the ac­tual <code>.jar</code> ﬁle (>300 MB), but you also need to down­load
a 16 GB n-gram dataset.
<h2>Grammarly Grievances</h2>
“But Elijah,” I hear you say, “just use Grammarly!”
No. I’m not go­ing to drop $12 a month for some­thing even slower and worse.
Not to men­tion how they are likely go­ing to use my work to train their large lan­guage mod­els.
Gram­marly is a great prod­uct, just not for me.
<h2>The Algorithm</h2>
Now that I’ve thor­oughly ex­plained my rea­son­ing for im­ple­ment­ing a new gram­mar checker (one that I’m call­ing <a href="https://github.com/elijah-potter/harper">Harper</a>), I’d like to re­count
my ﬁrst, ad­mit­tedly naive, at­tempt at spellcheck­ing.
The ﬁrst idea we need to get a grip on is Levenshtein edit dis­tance.
In essence, edit dis­tance is the least num­ber of sin­gle-char­ac­ter ed­its (insertions, dele­tions or re­place­ments) nec­es­sary to turn one word into an­other.
For ex­am­ple, the edit dis­tance be­tween “cat” and “bat” is one; the only edit in­volves re­plac­ing the “c” with a “b”.
Similarly, the edit dis­tance be­tween “kitten” and “sitting” is three: re­move the “g”, re­place the sec­ond “i” with an “e” and re­place the “s” with a “k”.
For this naive spellcheck­ing, we aren’t too con­cerned with the ex­act ed­its (atomic er­rors) that oc­cur in a given mis­spelling, only the mag­ni­tude of the er­ror.
From a high level view here’s how the al­go­rithm is go­ing to work:
<ol>
<li>Determine whether a given word is mis­spelled.
If not, exit.</li>
<li>Calculate the Levenshtein edit dis­tance be­tween the mis­spelled word and all valid English words.</li>
<li>Pick the three words with the short­est edit dis­tance and pre­sent them to the user as al­ter­na­tive
spelling op­tions.</li>
</ol>
<h3>Step 1.</h3>
To de­ter­mine whether a given word is mis­spelled, we will need a list of all the valid words in the English lan­guage.
Turns out, this is­n’t too easy.
For to­day, we will just use a sub­set of the English lan­guage with this short list:
<pre><code>into
the
a
cat
tree
jumped
</code></pre>
To check if a given word is within the list, we can place the list into a hash set,
and grab it’s con­tents.
<pre><code class="hljs language-rust">let words: Vec&#x3C;String> = vec!["into", "the", "a", "cat", "tree", "jumped"]
 .into_iter()
 .map(|s| s.to_string())
 .collect();

let word_set: HashSet&#x3C;String> = words.iter().cloned().collect();

let word = "thw";
let word_chars: Vec&#x3C;_> = word.chars().collect();

if word_set.contains(word) {
 println!("It is a valid English word!");
 return;
}

println!("Are you sure you meant to spell \"{}\" that way?", word);
</code></pre>
<h3>The Wagner-Fischer Algorithm</h3>
Now that we know our word is ac­tu­ally mis­spelled, we can move on to ﬁnd­ing the cor­rect spelling.
We need to ﬁnd the edit dis­tance be­tween the mis­spelled word and all the words in our set.
To do this, we will be us­ing the <a href="https://en.wikipedia.org/wiki/Wagner%E2%80%93Fischer_algorithm">Wagner-Fischer</a> al­go­rithm.
<pre><code class="hljs language-rust">// Computes the Levenstein edit distance between two patterns.
// This is accomplished via the Wagner-Fischer algorithm
fn edit_distance(source: &#x26;[char], target: &#x26;[char]) -> u8 {
 let m = source.len();
 let n = target.len();

 // Create an m-by-n matrix.
 let mut d = create_empty_matrix(m + 1, n + 1);

 // Since we know we can transform each word into the other by replacing
 // successive characters (or deleting them), we can fill the first column and
 // row with values from 0..m and 0..n, respectively.
 for i in 0..=m {
 d[i][0] = i as u8;
 }

 for i in 0..=n {
 d[0][i] = i as u8;
 }

 for j in 1..=n {
 for i in 1..=m {
 // The total edit distance of two given letter indices i and j, one from each word
 // will be the sum of the edit distances of prior combinations + whether the characters
 // at the two indices are equal.

 let cost = if source[i - 1] == target[j - 1] { 0 } else { 1 };
 d[i][j] = (d[i - 1][j] + 1)
 .min(d[i][j - 1] + 1)
 .min(d[i - 1][j - 1] + cost);
 }
 }

 // After all possible edits have been explored and minimized
 // the resulting minimum edit distance will be in the final item in the matrix.
 d[m][n]
}

// Create an empty matrix of size [m, n]
fn create_empty_matrix(m: usize, n: usize) -> Vec&#x3C;Vec&#x3C;u8>> {
 let mut d = Vec::with_capacity(m);

 for _ in 0..m {
 d.push(vec![0u8; n]);
 }

 d
}
</code></pre>
This works pretty well.
There are a num­ber of op­ti­miza­tions we could ap­ply to this func­tion alone.
I’ll leave that as a prob­lem for the reader, since they aren’t par­tic­u­larly rel­e­vant to the meat of the larger al­go­rithm.
<h3>Steps 2 + 3</h3>
Now that we can de­ter­mine the edit dis­tance be­tween two words, we can per­form a brute-force search.
In this short ex­am­ple, we’re go­ing to use <code>sort_by_key</code> to do this, since our data set is so small.
If we were work­ing with a larger dic­tio­nary (say, the en­tire English lan­guage), there would be a num­ber of things we would need to do to re­duce time and mem­ory con­sump­tion.
<pre><code class="hljs language-rust">let mut suggestions: Vec&#x3C;(String, u8)> = words
 .into_iter()
 .filter_map(|possible_word| {
 let possible_chars: Vec&#x3C;_> = possible_word.chars().collect();

 let dist = edit_distance(word_chars.as_slice(), &#x26;possible_chars);

 if dist &#x3C;= 2 {
 Some((possible_word, dist))
 } else {
 None
 }
 })
 .collect();

suggestions.sort_by_key(|(_, d)| *d);

println!("Possible alternatives: ");

suggestions.iter().for_each(|(s, _)| println!("- {}", s));
</code></pre>
If we run the whole pro­gram again, we get an out­put some­thing like:
<pre><code class="hljs language-output">Are you sure you meant to spell "thw" that way?
Possible alternatives:
- the
</code></pre>
That looks pretty good to me!
If you would like to look at the whole pro­gram, and maybe try out your own in­puts, <a href="https://play.rust-lang.org/?version=stable&#x26;mode=debug&#x26;edition=2021&#x26;gist=fb7910ad1fb3a6c944cbc2ae8659bb31">go right on ahead</a>.

It al­most feels wrong. Maybe it is.

Stupid Simple Spell Check

<h1>The Best 25 Bucks I Ever Spent</h1>
Earlier this year (I don’t re­mem­ber the ex­act day or month) I de­cided, screw it, I’m go­ing to try us­ing a ﬂip phone.
For years I’ve won­dered what it was like be­fore the in­for­ma­tion rev­o­lu­tion, but <a href="https://en.wikipedia.org/wiki/Generation_Z">as a Zoomer</a>, I’ve never had the op­por­tu­nity.
I got the cheap­est Verizon-compatible ﬂip phone Amazon had to of­fer and I com­mit­ted my­self to us­ing it ex­clu­sively for at least a week.
A week with­out the en­tirety of hu­man knowl­edge in my pocket.
A week of us­ing my voice to com­mu­ni­cate, rather than a touch-screen key­board.
<img src="/images/flip_phone.jpg" alt="The phone in question">
Beside two fac­tor au­then­ti­ca­tion for GitHub, that ﬁrst week was a breeze.
I found my­self so­cial­iz­ing more, since it turns out that most peo­ple in my so­cial cir­cle are just a phone call and a 10-minute walk away.
I also found my­self read­ing bet­ter qual­ity lit­er­a­ture.
Rather than re­sort­ing to HackerNews to ease my bore­dom, I be­gan de­vour­ing full books at a fright­en­ing pace.
That ﬁrst week turned into two, then four, then twelve.
All the while, I was prov­ing to my­self that I did­n’t need a smart­phone.
For a num­ber of rea­sons, I’m back to us­ing a smart­phone.
But this ex­pe­ri­ence has taught me some im­por­tant lessons that I don’t think can be taught any other way.
Organizing so­cial en­coun­ters over text just does­n’t work.
Some peo­ple don’t check their phone too of­ten.
Call­ing them make it clear that their par­tic­i­pa­tion is im­por­tant to you.
This may sound triv­ial or ob­vi­ous to some of the older mem­bers of my au­di­ence, but to pretty much every Zoomer I’ve talked to about this, it is a rev­e­la­tion.
Quiet is sa­cred, and should be pro­tected.
I see loads of peo­ple who walk around every day with their head­phones in, barely pay­ing at­ten­tion to the mu­sic blar­ing out of them.
I’ve done this my­self.
It closes you off the world.
From the tap­ping of wa­ter off an ici­cle.
From the shaky but warm greet­ing from a col­league.
From the chortling roar of an en­gine.
But most of all, it closes you off from your own mind.
The best think­ing and imag­in­ing hap­pens in the quiet, when your brain has noth­ing more stim­u­lat­ing to do.
Overall, us­ing a ﬂip phone was a very qui­et­ing ex­pe­ri­ence.
It helped the world feel larger and more mag­i­cal.

The Best 25 Bucks I Ever Spent

<h1>The Best Books I Read This Year</h1>
This year I’ve been read­ing a lot more.
Is there a par­tic­u­lar rea­son?
Other than sim­ply ad­mir­ing those that do, no.
I have found some gems of lit­er­a­ture that I would like to share.
<h2><a href="https://app.thestorygraph.com/books/d0a652d7-2461-46ce-9bf8-b684c45a67ea">Social Intelligence by Daniel Goleman</a></h2>
Social Intelligence is truly a trea­sure.
I heard of Daniel Goleman’s work ﬁrst from an episode of <a href="https://www.youtube.com/watch?v=-hoo_dIOP8k">Talks at Google</a> and later from psy­chol­o­gists who raved about his pre­vi­ous book, Emotional Intelligence.
It gives a deep dive into the sub­con­scious and light­ning-fast sys­tems the un­der­lay every so­cial in­ter­ac­tion.
As I read it, I found my­self an­a­lyz­ing my own be­hav­ior, as well as the be­hav­ior of oth­ers.
As some­one who has been over­think­ing my own so­cial life from a young age, Daniel’s ad­vice to let my brain go to its de­fault mode was re­liev­ing.
If you’re the type to feel anx­ious in so­cial sit­u­a­tions, this book is per­fect for you.
<h2><a href="https://app.thestorygraph.com/books/d57e098f-82dc-41f1-94f3-8fcb02dfab1b">Tomorrow and Tomorrow and Tomorrow by Gabrielle Zevin</a></h2>
Tomorrow and Tomorrow and Tomorrow is prob­a­bly one of the best ﬁc­tion books I’ve read.
Period.
At ﬁrst glance, it is just the story of the ca­reers of two game de­vel­op­ers and their pro­ducer.
But if you dig a lit­tle bit deeper, it re­veals it­self to be the story of how the re­la­tion­ships be­tween peo­ple who work to­gether can be in­cred­i­bly deep and com­plex.
Specif­i­cally, how the pas­sion to cre­ate some­thing can both bond and break peo­ple.
I don’t think it is pos­si­ble for me to ac­cu­rately de­scribe the emo­tional roller­coaster this book took me on.
Which is why you should read it!
<h2><a href="https://app.thestorygraph.com/books/73e8dabf-d6bc-432e-98f0-a48e30a470ad">Why We Sleep by Matthew Walker</a></h2>
I was cu­ri­ous why some peo­ple in my life sleep very lit­tle and other sleep quite a bit, both with vary­ing lev­els of gen­eral wake­ful­ness.
So, I ran a search: “Why do we sleep?”
To my sur­prise, I dis­cov­ered some­one wrote a book with al­most that ex­act ti­tle.
Since I’ve read it, I’ve in­creased the du­ra­tion of my sleep by nearly two hours.
This prac­tice has had an out­size im­pact on my health and hap­pi­ness.
I could not rec­om­mend it more.
I’ve <a href="./the_optimal_workspace">writ­ten about this book ex­ten­sively</a>, so I won’t re­peat my­self fur­ther.
<h2>That’s It!</h2>
I could wax po­etic about these books and how they’ve changed me—but I won’t.
In re­al­ity, I read them be­cause I en­joyed read­ing them.
In an age where peo­ple <a href="https://www.youtube.com/watch?v=A3wJcF0t0bQ">read less than ever</a>, I im­plore you: try pick­ing up a book, you might just like it.

I might be starting to sound like a broken record.

I might be start­ing to sound like a bro­ken record.

The Best Books I Read This Year

<h1>The Climate Change Progress Bar</h1>
<img src="/images/blue_marble.jpg" alt="The Blue Marble">
<h2>The Problem</h2>
Over the last cou­ple years, I’ve no­ticed a grow­ing dis­tinc­tion be­tween two groups of peo­ple.
On one hand, we have those who deny cli­mate change is a prob­lem.
Some be­lieve it is a <a href="https://en.wikipedia.org/wiki/Climate_change_conspiracy_theory">hoax</a>, while oth­ers merely don’t grasp the grav­ity of the sit­u­a­tion.
This per­spec­tive is mis­in­formed.
On the other hand, there are some who be­lieve cli­mate change is a prob­lem be­yond their abil­i­ties to im­pact.
They be­lieve that, as mere in­di­vid­u­als, there is not a sin­gle thing they can do that could have a mean­ing­ful ef­fect to­ward re­duc­ing car­bon emis­sions.
This per­spec­tive is equally mis­in­formed.
In re­al­ity, the cli­mate prob­lem is huge.
It will re­sult in mas­sive habi­tat losses for hu­man life and wildlife.
In all like­li­hood, hun­dreds of mil­lions of peo­ple will lose the abil­ity to farm their land, ei­ther from drought, ﬂoods, lost soil fer­til­ity or wild­ﬁres.
<blockquote>
Side Note: If you want to learn more about hu­man mi­gra­tion in the 21st cen­tury, I highly rec­om­mend the doc­u­men­tary Climate Refugees.
</blockquote>
The point of this ar­ti­cle is not to con­vince you that cli­mate change is a real prob­lem that has real so­lu­tions.
At this point, I don’t need to tell you that the cli­mate prob­lem is ac­tively be­ing solved by some of the most coura­geous, in­ﬂu­en­tial, in­tel­li­gent minds in the world.
There are so­lu­tions out there that are hav­ing a <a href="https://www.ted.com/talks/al_gore_the_case_for_optimism_on_climate_change">huge im­pact</a>, but peo­ple don’t have a straight­for­ward way to dis­cover them.
The prob­lem I want to solve is this: there is no sin­gle met­ric or dash­board to see the progress of cli­mate change and its so­lu­tions.
<h2>What’s the Pitch?</h2>
As I am sure you ﬁg­ured out from the ti­tle, I want to make a progress bar for cli­mate change.
A sin­gle place peo­ple can go to see where we, as a planet and as a species, stand.
Func­tion­ally, I want to repli­cate how we can view <a href="https://www.usdebtclock.org/">fed­eral gov­ern­men­t’s debt in real time</a>, but for cli­mate change.
I’ve con­versed with a friend of mine, Anyll Markevich, who knows much more about cli­mate is­sues than I do.
While we would ob­vi­ously need mul­ti­ple rounds of peer re­view be­fore we can put any­thing of sub­stance out, Anyll has rec­om­mended I start my re­search in a cou­ple spe­ciﬁc ar­eas.
<h2>Planetary Boundaries</h2>
There ex­ist some pro­jects and tools that hold a sim­i­lar goal as the cli­mate change progress bar.
The clos­est I could ﬁnd was the Planetary Boundaries pro­ject.
When hav­ing an ar­gu­ment with some­one, there are some lines you just can­not cross.
Some lines are un­avoid­able.
God­win’s law states that “as an on­line dis­cus­sion grows longer, the prob­a­bil­ity of a com­par­i­son to Hitler ap­proaches 1.”
While com­par­ing your ar­gu­men­ta­tive op­po­nent to a geno­ci­dal dic­ta­tor is al­most never nec­es­sary or use­ful, the line gets crossed even­tu­ally.
The plan­et’s ecosys­tem is sim­i­lar.
There are cer­tain eco­log­i­cal lines that can­not not be crossed, like hav­ing more than 10 ex­tinc­tions per mil­lion species in a year, with­out sig­nif­i­cant im­pact on global eco­log­i­cal health.
The planet can han­dle a cer­tain amount of car­bon diox­ide in the air, but it can­not han­dle more than 350 parts per mil­lion with­out sig­nif­i­cant dam­age oc­cur­ring. At the time of writ­ing, <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>C</mi><msub><mi>O</mi><mn>2</mn></msub></mrow><annotation encoding="application/x-tex">CO_2</annotation></semantics></math>CO2​ is cur­rently at 418 ppm.
<img src="/images/planetary_boundaries.webp" alt="The Planetary Boundaries Graph, Credit Azote for Stockholm Resilience Centre, based on analysis in Richardson et al 2023.">
The above graph shows where the planet is on sev­eral plan­e­tary bound­aries.
As you can see, we’ve ex­ceeded most of them.
While plan­e­tary bound­aries are a great way of com­mu­ni­cat­ing where we are on a bunch of en­vi­ron­men­tal met­rics, it falls short of our goal in a few key ways.
For one, it does­n’t spe­cial­ize in cli­mate change.
While it does show cur­rent car­bon diox­ide lev­els, it does­n’t in­clude any other green­house gases, or how deepy they are ef­fect­ing global tem­per­a­tures.
Fi­nally, it is only up­dated an­nu­ally.
The Climate Change Progress Bar’s key trait is that it is real-time, so peo­ple can see how we stand in the cli­mate bat­tle right now.
<h2>Possible Data Sources</h2>
This is some­thing I need to speak to more cli­mate ex­perts on.
How­ever, at the bare min­i­mum there are a few el­e­ments our tech­nol­ogy can look at.
<h3>Real Time Carbon Data</h3>
Anyll sug­gested I look into the <a href="https://www.nature.com/articles/s41597-020-00708-7">Carbon Monitor</a>, a real-time car­bon emis­sions’ dataset.
Since it does­n’t look like their API is ac­ces­si­ble, but their code is, it looks like we can just run in on our in­fra­struc­ture.
I need to look into the tech­ni­cal im­ple­men­ta­tion de­tails a bit more, but ini­tial prospects are good.
<h3><a href="https://en.wikipedia.org/wiki/Normalized_difference_vegetation_index">Normalized Difference Vegetation Index</a></h3>
NDVI is an in­dus­try-stan­dard way of mea­sur­ing the pho­to­syn­thetic pro­duc­tiv­ity of plants around the globe.
It works by ap­ply­ing some sim­ple math on two bands of satel­lite im­agery, both of which are widely avail­able.
The com­par­a­tive low com­pu­ta­tional cost of get­ting the NDVI of an area is a boon for our real-time goals.
It seems like its main draw­back is that it does­n’t give us many met­rics on bio­di­ver­sity.
<h2>Getting Started</h2>
We want to get started on an MVP as quickly as pos­si­ble.
The rel­a­tive sim­plic­ity of the NVDI gives us a great way to set up and test a real-time data pro­cess­ing pipeline.
We aim to in­clude other met­rics, like pop­u­la­tion growth and clean in­vest­ing, but we want to pre­pare a pipeline ﬁrst.
<h2>Feedback</h2>
This post, as well as all other posts re­lated to this pro­ject, ex­ist to serve two pur­poses:
<ol>
<li>Bookkeeping and white­board­ing de­vice.</li>
<li>To get feed­back on every stage of the process.</li>
</ol>
In other words, I want to hear from you!
If you have any ideas to how we can make the Climate Change Progress bar bet­ter, let us know by email­ing <a href="mailto:feedback@elijahpotter.dev">feed­back@eli­jah­pot­ter.dev</a>
If there are bet­ter met­rics we should be in­clud­ing in our in­dex, tell us!

The Climate Change Progress Bar

<h1>The Easiest Way to Run LLMs Locally</h1>
<img src="/images/llama.webp" alt="A Goofy Lookin&#x27; Llama">
<h2>LLMs</h2>
Unless you’ve been liv­ing un­der a rock for the past year, you al­ready know what LLMs are.
If you do hap­pen to be one of the lucky few un­aware of the cur­rent hype around these things, I’ll go through it real quick.
A large lan­guage model (or LLM) is a sta­tis­ti­cal model ca­pa­ble of “predicting” a sub­se­quent word or let­ter, given a body of text.
Es­sen­tially, it is a com­puter pro­gram ca­pa­ble of ﬁll­ing in the blank.
If you let it pre­dict the next word, then feed the re­sult back in, you can get some pretty hu­man-look­ing text.
<h2>Let’s Be Clear</h2>
I hold a lot of skep­ti­cism on the prac­ti­cal ap­pli­ca­tions of LLMs as a tool.
As a blan­ket rule, I never use LLMs or any sim­i­lar tech­nol­ogy in my ed­u­ca­tion.
I know some peo­ple ask LLMs ques­tions like “explain the fun­da­men­tal the­o­rem of cal­cu­lus to me like I’m ﬁve.”
While they may get good re­sults for ques­tions, I do not want to lean on them as a crutch.
Col­lege is not only an op­por­tu­nity to learn the raw ma­te­r­ial, but also an op­por­tu­nity to learn how to learn.
If we know any­thing about LLMs, it’s that its abil­ity to an­swer com­plex ques­tions break down as you move to more spe­cial­ized classes.
Which is all to say: I did not in­ves­ti­gate this with the in­ten­tion of us­ing it as a tool, I just wanted to play around.
<h2>My Circumstance</h2>
I use <a href="https://archlinux.org/">arch, btw.</a>
While I en­joy the level of con­trol it pro­vides, I don’t think it’s for every­body.
This is partly be­cause some things are quite dif­ﬁ­cult to set up.
For ex­am­ple, GPU sup­port is lim­ited and ﬁnicky, es­pe­cially if you run an Intel Arc card, like I do.
While it works per­fectly for some apps, like <a href="https://www.blender.org/">blender</a>, it does­n’t work so well for other things.
My card only has 3 GB of VRAM, so it would­n’t be able to ﬁt most mod­els any­way.
So when I took on the task of run­ning an LLM on my lo­cal ma­chine, I started at look­ing at CPU-only so­lu­tions.
Initially, I tried to raw-dog <a href="https://github.com/ggerganov/llama.cpp">llama.cpp</a>.
That worked but only so.
The com­mand-line in­ter­face left a lot to be de­sired, and the process of down­load­ing and load­ing var­i­ous mod­els was te­dious and con­fus­ing.
<h2>Ollama</h2>
That’s when I dis­cov­ered <a href="https://ollama.ai/">Ollama</a>.
Installing it was as easy as run­ning:
<pre><code class="hljs language-bash">sudo pacman -S ollama
</code></pre>
To avoid wast­ing re­sources on mul­ti­ple in­stances of each model, Ollama uses a server ar­chi­tec­ture.
You can start the server by run­ning
<pre><code class="hljs language-bash">ollama serve
</code></pre>
Then, you can down­load an start chat­ting with a model with:
<pre><code class="hljs language-bash">ollama run llama2
# Or:
ollama run mistral
</code></pre>
<h2>That’s It</h2>
That’s it!
It re­ally is that sim­ple.
Again, you might have no rea­son to do any of this.
Es­pe­cially if you are happy with the pri­vacy night­mare that is OpenAI, Google or Anthropic, or if you al­ready have a sys­tem that works for you.

It saved me enough time, I had some to share about it.

It saved me enough time, I had some to share about it.

The Easiest Way to Run Llms Locally

The Optimal Workspace

<h1>The Simplest Neovim Markdown Setup</h1>
I am not one who en­joys com­plex­ity.
I am also some­one who likes to make their <a href="https://github.com/elijah-potter/harper">own tools</a>.
As a stu­dent, I write a lot.
That in­cludes notes, pa­pers, and doc­u­men­ta­tion for my wide va­ri­ety of pro­jects.
A lot of classes re­quest to sub­mit as­sign­ments as ei­ther PDF, HTML or <code>.docx</code>.
For a while, I sub­mit­ted PDF’s.
I had a whole or­ches­trated setup.
I would write every­thing in <a href="https://neovim.io/">Neovim</a>, save it, and <a href="https://github.com/frabjous/knap">KNAP</a> would ren­der it us­ing <a href="https://pandoc.org/">Pandoc</a>.
Finally, it would be ren­dered to my screen us­ing <a href="https://sioyek.info/">Sioyek</a>.
This worked ﬁne, I guess, but it was far from per­fect.
<ol>
<li>It was slow. Each edit I made in Markdown could take as many as 10 sec­onds to show up in Sioyek.</li>
<li>It was­n’t in­ter­est­ing. While I made mod­i­ﬁ­ca­tions to my Pandoc set­tings, my PDF’s still looked like every other <code>pdflatex</code> doc­u­ment ever made.</li>
<li>I could­n’t make my doc­u­ments in­ter­ac­tive if I wanted to.</li>
</ol>
Markdown was de­signed to be turned into HTML, I rea­soned.
So why not just do that?
<img src="/images/tatum_screenshot.webp" alt="A screenshot of Tatum at work">
That’s why I cre­ated <a href="https://github.com/elijah-potter/tatum">Tatum</a>.
It does one thing, re­ally well.
Point it at a Markdown ﬁle, and it will run a tiny web server to ren­der the re­sult­ing HTML to.
If the ﬁle changes, a WebSocket con­nec­tion tells the browser to re­fresh.
Tatum ren­ders in mil­lisec­onds and cre­ates beau­ti­ful pages with <a href="https://katex.org/"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mtext>KaTeX</mtext></mrow><annotation encoding="application/x-tex">\KaTeX</annotation></semantics></math>KATE​X</a>, <a href="https://simplecss.org/">Simple.css</a> and <a href="https://highlightjs.org/"><code>highlight.js</code></a>.
I can em­bed in­ter­ac­tive HTML, CSS and JavaScript el­e­ments di­rectly into my Markdown to get the in­ter­ac­tiv­ity and aes­thet­ics I de­sire.
Once I’m done work­ing, I just run <code>tatum render &#x3C;file.md></code> and I get a sin­gle ﬁle (images and all) that I can sub­mit for my as­sign­ments.
Tatum is­n’t for you to use.
Feel free to poke around at how it works, or even fork it and make your own mod­i­ﬁ­ca­tions.
It ﬁts my use case per­fectly.

How I preview my Markdown quickly and reliably.

How I pre­view my Markdown quickly and re­li­ably.

The Simplest Neovim Markdown Setup

<h1>The Three Steps to an Apology</h1>
My grand­mother is a won­der­ful woman. She never leaves the house with­out a least a lit­tle bit of pur­ple. Maybe a key­chain or a purse. Sometimes, she would leave the house with­out a lot of pur­ple, head to toe. She also never for­gets a smile and a good at­ti­tude.
She’s a wise woman. With more than 70 years and ﬁve chil­dren un­der her belt, she’s seen some stuff. All that ex­pe­ri­ence comes with a lot of ad­vice. The three steps to an apol­ogy are some of the best bits of ad­vice she’s ever given me.
<h2>Step One: “I am sorry”</h2>
Admit you’ve done some­thing wrong. Recognize your fault and imag­ine what would have hap­pened if you had done the right thing.
<h2>Step Two: “It will not hap­pen again”</h2>
If you’re ac­tu­ally sorry, you’ll want to avoid repli­cat­ing the same mis­take at a later date. Figure out what you need to do to make sure you this is a one-time er­ror.
<h2>Step Three: “What can I do to make it bet­ter?”</h2>
Attempt re­pair. In a fan­tasy world, you could go back in time and stop your­self from do­ing what­ever it is you did in the ﬁrst place. But we don’t live in a fan­tasy world, so you have to ﬁnd a way to make it right, as soon as pos­si­ble.

The Three Steps to an Apology

<h1>What Blasterhacks Taught Me About Leadership</h1>
<h2>The Beginning</h2>
Although it was sev­eral months ago, I re­mem­ber it like it was yes­ter­day.
It was what I would call a dusty Colorado Friday.
The sky was over­cast and the trees de­press­ingly bar­ren.
The air smelled of cow farts, which was typ­i­cal when the winds changed, blow­ing in cold air from the beef farms in the nearby town of Greeley.
In my mind, this sig­naled snow.
I walked into the Green Center, the build­ing in hous­ing the open­ing cer­e­mony of BlasterHacks, the hackathon run by the Colorado School of Mines.
I sign in at the en­trance and walk down into the au­di­to­rium.
As I greeted my team­mates, <a href="https://grantlemons.com/">Grant Lemons</a>, <a href="https://lukaswerner.com/">Lukas Werner</a> and <a href="https://b-sharman.dev/">Byron Sharman</a>, I no­ticed the ner­vous smiles on their faces.
You know the kind, the smile with the in­ner eye­brows slightly raised, shoul­ders tense.
We were ex­cited, but we also knew we had 36 solid hours of pro­gram­ming ahead of us.
After col­lec­tively down­ing sev­eral whole piz­zas and lis­ten­ing to the rules of the com­pe­ti­tion, we made our way over to Labriola Innovation Complex, the hours-old man­u­fac­tur­ing build­ing the com­pe­ti­tion would take place in.
<h2>The Plan</h2>
We brain­stormed some ideas un­der the over­cast sky:
<ul>
<li>A Bennett Foddy-inspired bat­tle-royale game where all the con­trols were <code>vim</code>-keybindings.</li>
<li>A health in­sur­ance app that es­ti­mates the cost of your care at all lo­cal hos­pi­tals.</li>
<li>An app that en­cour­aged you to stand up and move every thirty min­utes.</li>
</ul>
It was that last one that we all got ex­cited about.
We imag­ined it to be so­cial: at a ran­dom in­ter­val (which would av­er­age to thirty min­utes), the app would si­mul­ta­ne­ously send out a no­ti­ﬁ­ca­tion to every user.
Should the user choose to par­tic­i­pate in the StandUp mo­ment, the app would guide them all through the same short work­out ac­tiv­ity.
Fi­nally, the user had the choice to up­load “evidence” of the work­out, which could be a short cap­tion about what they were do­ing, or a photo.
The idea of StandUp (as we would go on to name our pro­ject) was in­spired si­mul­ta­ne­ously by <a href="https://bereal.com/en/">BeReal</a>, re­cent re­search in the detri­men­tal health ef­fects of re­mote work, and the use of so­cial li­a­bil­ity for com­par­a­tively more ex­treme work­outs (Strava).
<img src="/images/screenshot_standup.webp" alt="The Feed page of standup after a user has posted">
Of course, most of this had yet to be nailed down yet, for we were just en­ter­ing the Labriola Innovation Complex.
I re­mem­ber ask­ing my­self if I would leave be­fore the com­pe­ti­tion was over.
Al­though I was tired from the days classes and home­work, I felt a drive to ded­i­cate my whole self to this pro­ject.
<h2>The Board</h2>
We sat down and cre­ated a new <a href="https://github.com/grantlemons/blasterhacks2024">git repos­i­tory</a>.
That’s when I started think­ing about how we were go­ing to or­ga­nize our work.
I pro­posed we setup a KanBan board, a pro­ject man­age­ment tech­nique I had picked up at <a href="https://archytasinc.com">Archytas Automation</a>.
<img src="/images/kanban_blasterhacks.jpg" alt="Our KanBan board near the end of the Hackathon">
If you’ve never heard of–or used a KanBan board, here’s the gist.
There are three buck­ets:
<ol>
<li>To Do.</li>
<li>Doing.</li>
<li>Done.</li>
</ol>
The sec­ond bucket is di­vided up by per­son, so in our case, it was re­ally four sep­a­rate buck­ets.
When some­one needed some­thing new to work on, they would go to the “To Do” bucket and se­lect a new task (which in our case, was a sticky note).
They would place the task into their cor­re­spond­ing “Doing” bucket.
Once the task was done, they would move the sticky note into the “Done” bucket and re­peat.
As a gag, we added an ad­di­tional (superﬂuous) bucket: IDGAF.
If a task was unan­i­mously deemed no longer im­por­tant or rel­e­vant to the pro­ject, that’s where we would put it.
So, we got to work.
We had de­cided to use <a href="https://firebase.google.com/">Firebase</a>, <a href="https://kit.svelte.dev/">SvelteKit</a> and <a href="https://go.dev">Go</a>.
I started set­ting up Firebase, Grant started re­search­ing the no­ti­ﬁ­ca­tion ser­vice, Lukas started work­ing on a cir­cu­lar sta­tus page and Byron started re­search­ing the Camera API.
As I look back at this mo­ment to­day, I re­al­ize some­thing im­por­tant about all of these tasks that ended up ben­e­ﬁt­ing us in the long term: they were all in­de­pen­dent.
None of these orig­i­nal tasks re­lied on any other to get done.
We could work in par­al­lel.
Down the road, this would change, but the fact that we were par­al­lel at the be­gin­ning set us up for suc­cess.
<h2>The Snow and the Crash</h2>
We kept work­ing through the night, down­ing en­ergy drinks and laugh­ing as we worked. We got the im­por­tant ser­vices and UI el­e­ment up and run­ning.
Around mid­night, as my nose had pre­dicted sev­eral hours ear­lier, it started snow­ing.
As the snowﬂakes grew larger and ever more ﬂuffy, I felt the teams en­ergy be­gin to dip.
We were en­coun­ter­ing road­blocks, one-by-one, as our mo­ti­va­tion waned and the threat of sleep be­came more promi­nent.
Then, some­one in the main atrium (who, I don’t re­mem­ber) pro­nounced, “we are go­ing out­side.”
We ran down the halls like chil­dren spread­ing the an­nounce­ment, and soon enough, there were dozens of tired com­puter sci­ence stu­dents throw­ing snow­balls in their jeans the t-shirts.
As I threw (and re­ceived) a num­ber of snow­balls, I re­al­ized some­thing im­por­tant: we were mak­ing an app about tak­ing care of your­self phys­i­cally, but had ne­glected to do so our­selves.
As im­por­tant as the pro­ject may be, it won’t get done when every­one is tired, mus­cles cramped, and un­happy.
To keep the mo­men­tum go­ing, breaks are re­quired.
As we ﬁled back in­side to warm our hands un­der tap wa­ter, I swore to make sure the rest of the team would take care of them­selves–and each other.
<h2>The Conclusion</h2>
The rest of the hackathon was un­event­ful.
We sat at our lap­tops, crank­ing out line af­ter line of code.
We took breaks and slept when we were blocked by other tasks.
Although it was our ﬁrst hackathon, we de­cided to run our pro­ject in the ad­vanced track, nor­mally re­served for hackathon vet­er­ans.
It paid off, be­cause we won sec­ond-place!
Look at us: hag­gard but sat­is­ﬁed.
<img src="/images/secondplace_blasterhacks.png" alt="The team receiving our second-place win.">

What Blasterhacks Taught Me About Leadership

<h1>Why Rust Might Attract More Developers Than Java and JavaScript</h1>
Rust is un­de­ni­ably a greatly ap­pre­ci­ated lan­guage, af­ter all, it has placed as “#1 Most Loved Programming Language” on the StackOverﬂow Developer Survey for 6th year run­ning.
Reading this, you are prob­a­bly very aware of why so many peo­ple like it, but I will be go­ing over those rea­sons any­way, at least be­fore I re­veal its se­cret weapon.
It’s fast, very fast. While it may not be a great bench­mark, The Computer Language Benchmarks Game, mea­sures that it falls just a hair be­hind the fastest lan­guage, C.
That makes sense, given that Rust was meant to re­place C/C++. Even bet­ter than the bench­mark, it has been shown that in many sit­u­a­tions, the Rust com­piler is able to op­ti­mize code sig­nif­i­cantly bet­ter than C or C++, just be­cause it has more in­for­ma­tion about the de­vel­op­ers in­tent.
It’s con­sis­tent. For more than pretty much any other lan­guage, Rust de­vel­op­ers can ex­pect that, if their code com­piles, it works. When it does­n’t com­pile, the com­piler gives bet­ter feed­back and ad­vice than any other lan­guage. It can even check if your arith­metic is wrong.
It’s com­pli­cated, but only where it needs to be. The lan­guage it­self, as well as its stan­dard li­brary are built very con­sciously, by its users. Most places where you might ﬁnd you have to write te­dious boil­er­plate, Rust makes it easy. It also gives you the free­dom to write code that does ex­actly what you want, ex­actly how you want. We will get back to this later.
<h2>The Problem</h2>
When start­ing a new pro­ject what is the ﬁrst thing you are go­ing to do? It de­pends on what stack you are us­ing.
If you want to use NodeJS, it might look some­thing like:
<pre><code class="hljs language-bash">mkdir new_project
touch index.js
npm install
</code></pre>
That is just the bare min­i­mum. If you want to add any de­pen­den­cies, you have to go through an un­rea­son­able num­ber of hoops, and the stan­dard pack­age repos­i­tory, npm, is known for be­ing quite in­se­cure, not to men­tion it be­ing con­trolled by a pri­vate cor­po­ra­tion.
If you want to use Java, you have to use some kind of tem­plate, oth­er­wise it’s im­pos­si­ble to cre­ate a pro­ject from scratch. Even then, you have to de­cide be­tween two or three pack­age man­agers, and deal with it when li­braries don’t sup­port your choice.
If you want to use C or C++ for­get it. As a be­gin­ner, you are go­ing to be stuck ﬁg­ur­ing out how to use the lo­cal linker and com­piler to get any li­brary to work.
<h2>The Rusty Solution</h2>
Cargo is one of the sim­plest, eas­i­est to use build tools out there. It does every­thing you might need, and it may be why Rust may soon be­come a ma­jor player. 99% of the time, you can just copy and paste a given li­brary’s string di­rectly from <a href="https://crates.io">crates.io</a>, which is a repos­i­tory owned and op­er­ated by the Rust Foundation, and you are off to the races.
Testing is easy too, just run <code>cargo test</code>, and you’re done. It cov­ers both unit tests, and in­te­gra­tion tests if you need it.
`cargo doc`` pro­vides a con­sis­tent, and easy way to doc­u­ment code. It’s also great for users, al­low­ing de­vel­op­ers ac­cess to a straight­for­ward rep­re­sen­ta­tion of what a li­brary looks like.
It’s ex­ten­si­ble, some of the great­est bi­nary crates out there ex­ist to ex­tend the func­tion­al­ity. So, in the few ar­eas where <code>cargo</code> on its own does­n’t cut it, there are ad­di­tional crates to ﬁll the gaps.
<h2>Closing</h2>
At least for the mo­ment, of all the great rea­sons to use Rust, <code>cargo</code> will be the most sig­nif­i­cant rea­son it will in­crease in pop­u­lar­ity.
<img src="/images/most_loved_stackoverflow_2021.png" alt="Most loved programming languages, according to the 2021 StackOverflow Developer Survey">
Rust can be tough to learn, es­pe­cially for peo­ple who are used to dy­namic lan­guages like JavaScript. But what Rust has beat for most lan­guages is the build sys­tem. <code>cargo</code> alone makes Rust more ap­proach­able than C/C++, Java and many oth­ers.
More and more new de­vel­op­ers will be go­ing to Rust in­stead of those other lan­guages, be­cause it is eas­ier to start with, eas­ier to learn, and has a great com­mu­nity to re­quest help from.

A key part of Rust is far better that what JavaScript has to offer.

A key part of Rust is far bet­ter that what JavaScript has to of­fer.

Why Rust May Be More Attractive than Javascript

<h1>Why You Need <code>sccache</code></h1>
As the main­tainer of a <a href="https://writewithharper.com">rea­son­ably pop­u­lar open source pro­ject</a> writ­ten in Rust, I ﬁnd my­self cloning PRs and swap­ping be­tween branches dozens of times a day.
In do­ing so, I of­ten blow away Rust’s com­pi­la­tion cache ei­ther via <code>git clean -xf .</code> or by chang­ing de­pen­dency ver­sions.
Having a build cache that is sep­a­rate from the pro­ject is a huge win for com­pile times, which is why I use <a href="https://github.com/mozilla/sccache"><code>sccache</code></a>.
For those un­aware, <code>sccache</code> is a build tool for C, C++ and Rust pro­jects that stands in front of the com­piler.
If a given ﬁle’s hash is the same across calls to the com­piler, <code>sccache</code> reuses the pre­vi­ous re­sult.
This cache is com­piler–and pro­ject ag­nos­tic.
In my case, it sits in <code>$HOME/.scccache</code>, but you can set it up with AWS S3, Redis or a myr­iad of other op­tions.
If a de­pen­dency is cached from a com­pile in one pro­ject, it is avail­able for a build in an­other.
In short: you need <code>sccache</code> if you are fre­quently swap­ping be­tween branches with sim­i­lar (but not iden­ti­cal) de­pen­den­cies or ex­pect to fre­quently delete Rust’s disk cache.
<h2>Why You Don’t Need <code>sccache</code></h2>
If you are work­ing in a sin­gle branch on a pro­ject whose de­pen­den­cies re­main some­what sta­ble, <code>sccache</code> might ac­tu­ally in­crease your com­pile time.
Since <code>sccache</code> has to hit the disk (or even the net­work) re­gard­less of whether it is a cache hit, a lit­tle bit of la­tency is added.
If you ex­pect most com­piles to be cache hits or most com­piles to be cache misses, <code>sccache</code> is no more use­ful than the built-in caching <code>cargo</code> pro­vides.
In that case you should not use <code>sccache</code>.
<h2>Wrap-Up</h2>
Regardless of whether you in­stall <code>sccache</code> on your ma­chine, it is a neat lit­tle tech­nol­ogy.
I would rec­om­mend the cu­ri­ous reader take a look for them­selves.
You might be in­spired.

You might not ac­tu­ally need it.

Elijah Potter

The Three Steps to an Apology

Step One: “I am sorry”

Step Two: “It will not happen again”

Step Three: “What can I do to make it better?”

Elijah Potter

The Three Steps to an Apology

Step One: “I am sorry”

Step Two: “It will not hap­pen again”

Step Three: “What can I do to make it bet­ter?”

Step Two: “It will not happen again”

Step Three: “What can I do to make it better?”