Blain Smith

Unbounded Concurrency is a Foot Gun

2026-04-16T00:00:00+00:00

Bluesky went down for half its users for about 8 hours on Monday. Jim Calabro wrote up an excellent post-mortem</a> that is worth reading in full, but the root cause is something I keep seeing across languages and runtimes, and it's worth talking about on its own.

One endpoint in their data plane, GetPostRecord</code>, fanned out concurrent work based on the size of the incoming request. Every other endpoint in the system used bounded concurrency viaerrgroup.SetLimit</code></a>. This one did not. A new internal client started sending batches of 15-20 thousand URIs at a time. That meant 15-20 thousand goroutines per request, each dialing memcached, each blowing through the idle connection pool, each leaving a TIME_WAIT</code> socket behind until the box ran out of ephemeral ports. From there it cascaded into GC pressure, OOMs, and a death spiral that took most of a weekend to unwind.

One missing line of code.

group.</span>SetLimit</span>(</span>50</span>)</span> // <-- this</span></span></code></pre>The Real Problem is Everywhere</h2>
The specific bug is Go and errgroup</code>, but the anti-pattern has nothing to do
with Go. Any runtime that lets you cheaply spawn concurrent units of work lets
you cheaply spawn too many of them. Some examples:</p>

Go</strong>: go func() { ... }()</code> in a loop over untrusted input. Goroutines are
cheap but not free. The scheduler, the GC, and the kernel resources each one
touches are not free either.</li>
Node.js</strong>: Promise.all(items.map(fetchOne))</code> where items</code> came from a
user. You just opened len(items)</code> sockets at once. Congratulations.</li>
Python</strong>: asyncio.gather(*[work(x) for x in items])</code> or a ThreadPoolExecutor</code>
with no max_workers</code>. Same shape, same outcome.</li>
Erlang/Elixir</strong>: Task.async_stream</code> without max_concurrency</code> set, or
spawn</code> in a loop without a supervisor boundary. The BEAM will happily let
you start a million processes.</li>
Java</strong>: CompletableFuture.allOf(...)</code> over a user-sized collection. The
common ForkJoinPool is shared and it will get thrashed.</li>
Rust</strong>: futures::future::join_all</code> or tokio::spawn</code> in a loop. The
executor does not protect you from yourself.</li>
</ul>
In every one of these, the code reads fine in review and the concurrency
primitive is idiomatic. The problem only shows up when items</code> gets big, and
items</code> is almost always something a client controls directly or indirectly.</p>
It gets worse since the entire point of spawning concurrent units of work is
to perform I/O against another resource. Now that resource is being saturated
with unbounded requests.</p>
Why This Keeps Happening</h2>
Unbounded concurrency is seductive because during development it looks like
the fastest and cleanest option. You want to do N things in parallel, so you
start N workers. No queue to set up, no worker count to pick, no backpressure
to think about. The test suite runs with N=10</code> and everything is fine. The
staging environment runs with N=100</code> and everything is fine. Production sees
N=20000</code> one Saturday morning and the whole thing falls over.</p>
The tradeoff gets papered over because the cost of an individual goroutine,
promise, or task is tiny. It is the aggregate cost that kills you, and the
aggregate is controlled by your input size, which you do not own. "Small and
cheap per unit" is not the same as "free at any scale."</p>
The Fix is Older than Go</h2>
Fixed pool of workers, buffered channel of work, drop or block when the channel
fills up. It is not a novel idea. It is the standard answer and has been for a
long time. There are many ways to address this, but one way to do it in Go is:</p>
func</span> GetPostRecords</span>(</span>uris</span> []</span>string</span>) ([]</span>*</span>Post</span>,</span> error</span>) {</span></span>
	// Pre-allocate the results slice. Each worker writes to its own index</span></span>
	// so there's no contention and no need for a mutex.</span></span>
	posts</span> :=</span> make</span>([]</span>*</span>Post</span>,</span> len</span>(uris))</span></span>
</span>
	// The concurrency bound. This is the whole point of the pattern. No</span></span>
	// matter how big `uris` is, we will never have more than `workers`</span></span>
	// lookups in flight at once.</span></span>
	const</span> workers</span> =</span> 50</span></span>
</span>
	// Buffered channel of work. The buffer size is a small multiple of</span></span>
	// the worker count to keep workers fed without letting the queue</span></span>
	// grow unbounded. Values are indices into `uris` so the workers can</span></span>
	// write results back to the right slot in `posts`.</span></span>
	jobs</span> :=</span> make</span>(</span>chan</span> int</span>, workers</span>*</span>2</span>)</span></span>
</span>
	// Buffered error channel with capacity 1. We only care about the</span></span>
	// first error, so additional errors get dropped via the non-blocking</span></span>
	// send below.</span></span>
	errs</span> :=</span> make</span>(</span>chan</span> error</span>,</span> 1</span>)</span></span>
</span>
	// WaitGroup so the main goroutine can tell when every worker has</span></span>
	// finished draining the jobs channel.</span></span>
	var</span> wg</span> sync</span>.</span>WaitGroup</span></span>
</span>
	// Always add the number of workers you need right after the WaitGroup</span></span>
	// is initialized and avoid doing wg.Add(1) within loops.</span></span>
	wg.</span>Add</span>(workers)</span></span>
</span>
	// Spin up a fixed number of workers. This is the bounded part.</span></span>
	// Compare to the Bluesky bug, where the loop that spawned goroutines</span></span>
	// ran once per input URI.</span></span>
	for</span> w</span> :=</span> 0</span>;</span> w</span> <</span> workers</span>;</span> w</span>++</span> {</span></span>
		go func</span>() {</span></span>
			// Always, always, always put this immediately at the top of the</span></span>
			// spawned unit of work that way you know you have this covered</span></span>
			// and during code reviews others will also begin to notice when</span></span>
			// it is not present.</span></span>
			defer</span> wg.</span>Done</span>()</span></span>
</span>
			// Each worker pulls indices off the jobs channel until it's</span></span>
			// closed and drained. `range` over a channel handles both</span></span>
			// the receive and the close-detection for us.</span></span>
			for</span> i</span> :=</span> range</span> jobs {</span></span>
				// This is the expensive I/O work and all this setup ensures that</span></span>
				// this work does not also get hammered by user input.</span></span>
				post, err</span> :=</span> lookup</span>(uris[i])</span></span>
				if</span> err</span> !=</span> nil</span> {</span></span>
					// Non-blocking send: if the error channel already</span></span>
					// holds an error, skip. Prevents workers from</span></span>
					// deadlocking on an unbuffered send when multiple</span></span>
					// errors happen.</span></span>
					select</span> {</span></span>
					case</span> errs</span> <-</span> err:</span></span>
					default</span>:</span></span>
					}</span></span>
					return</span></span>
				}</span></span>
				// Safe to write without a lock because each worker</span></span>
				// owns a unique index `i` for the duration of this</span></span>
				// iteration.</span></span>
				posts[i]</span> =</span> post</span></span>
			}</span></span>
		}()</span></span>
	}</span></span>
</span>
	// Feed the workers. Sends block once the buffer fills, which is</span></span>
	// exactly the backpressure we want. The producer can't outrun the</span></span>
	// pool.</span></span>
	for</span> i</span> :=</span> range</span> uris {</span></span>
		jobs</span> <-</span> i</span></span>
	}</span></span>
</span>
	// Close the channel to signal "no more work." Workers see the close,</span></span>
	// exit their `range` loop, and call wg.Done().</span></span>
	close</span>(jobs)</span></span>
</span>
	// Block until every worker has returned.</span></span>
	wg.</span>Wait</span>()</span></span>
</span>
	// Surface the first error if there was one, otherwise return the</span></span>
	// results. Non-blocking receive so we don't hang if no error was</span></span>
	// ever sent.</span></span>
	select</span> {</span></span>
	case</span> err</span> := <-</span>errs:</span></span>
		return</span> nil</span>, err</span></span>
	default</span>:</span></span>
		return</span> posts,</span> nil</span></span>
	}</span></span>
}</span></span></code></pre>
errgroup.SetLimit(50)</code> collapses most of that boilerplate, which is why the
Bluesky fix was one line. The particular API does not matter. What matters is
that the number of in-flight operations is bounded by the server and not by
the caller.</p>
If the channel fills up you have to either block and apply backpressure, or
drop the work and return an error. Both are reasonable. Letting the caller
dictate how much work you do is not.</p>
What to Look For</h2>
When reviewing code, the pattern is easy to spot once you are looking for it.
Any loop that spawns concurrent work and whose iteration count comes from
input. Any gather</code>, join_all</code>, Promise.all</code>, Task.async_stream</code> that
takes a user-sized list. Any comment that says "we just parallelize the
lookups" with no worker count in sight.</p>
Ask the author one question: "What is the maximum number of concurrent
operations this can produce, and is that number bounded by the server or by
the request?" If they cannot answer, or the answer is "the request," that is
the bug. It might not fire this quarter. It will fire the first time a client
sends you something bigger than you planned for.</p>
One More Thing</h2>
The Bluesky post-mortem mentions that logging inside the hot path made the
death spiral worse. Millions of blocking write(2)</code> calls per second caused
the Go runtime to spawn a pile of OS threads, which tanked the GC, which
caused OOMs, which restarted the process into the same TIME_WAIT</code>-saturated
state it had just died from. Every layer of the stack had a foot gun of its
own and they all went off at the same time.</p>
The meta-lesson is the same one. Any resource whose consumption scales with
input size and is not explicitly bounded is a ticking bomb. Goroutines,
sockets, log writes, connections, database queries. Pick a bound, put it in
code, and flag it in code review when you see it missing.</p>
Unbounded concurrency is not a clever shortcut. It is a loaded gun you have
pointed at your production environment and handed to whoever happens to send
you the next request.</p>



Wired for Fairness
2026-04-13T00:00:00+00:00
I asked my son if he could learn to build anything, what would he want
to build. He is twelve years old and autistic and he does not elaborate
unless you ask him to. He said, "I want to measure the temperature
outside." That was the whole answer. No explanation, no context, no
story about why. Just the thing itself.</p>
So I asked the follow-up questions, because that is how we talk. "Do
you want to see that on your phone, or something else? Like, a sensor
outside and then you read the number on something inside?" He said yes.
That was enough. We are going to build a thermostat together.</p>
This is how every conversation with my son has gone for twelve years. He
is very smart, but his verbal skills are something he has to work at
constantly in order to get what is in his head out into words someone
else can follow. The ideas are there and they have always been there. Reaching them means
asking the right questions and waiting.</p>
He does not want an app or a platform. He wants to understand how a temperature gets measured, how that number travels
somewhere, and how it shows up on a screen. I recognize that impulse
from thirty years ago when I sat in front of my first computer and
wanted the same thing: to understand how something works and to build
something that made sense and did what it was supposed to do.</p>
I also think about what kind of world he is going to do that in, and I
am afraid.</p>
+++</p>
In 2020, during the pandemic shutdown, I was in the worst depression of
my life. The world had closed. Routine, which for an autistic person is
load-bearing architecture, had collapsed. I was raising my son alone,
trying to keep him stable while I could barely keep myself upright. I
was not sleeping well. I was not eating well. I had stopped training,
which for most of my adult life had been the one reliable place where my
body and my mind worked together instead of against each other.</p>
In the middle of this, a client asked me to fabricate user traffic. They
wanted the numbers to show ten times more users than actually existed.
The purpose was to inflate metrics for investors, to make growth look
real when it was not. They presented this casually, as a business
decision, as something that simply needed to get done.</p>
I could not do it. My body would not let me. There was no weighing of
pros and cons. The request hit something inside me that I did not have a
name for at the time, something that responded to dishonesty and
exploitation the way a nerve responds to a burn. The objection was
visceral, immediate, and total. I shut down. I could not think about anything else. I could not work on
anything else. The collision of being already depressed, already
fragile, already running on fumes, with a request that violated
something fundamental in how I understood my work and my responsibility
to the people who would be deceived by those numbers, broke something in
me that took years to rebuild.</p>
That moment did not just feel like it changed me. It did change me.
Research in neuroplasticity has established that chronic stress and
depression cause structural changes in the brain. Sustained exposure to
distress reduces dendrites and synaptic connections in the hippocampus
and prefrontal cortex, the regions responsible for memory, learning, and
decision-making. The amygdala, which processes fear and threat, becomes
hyperactive. Neural pathways are built by experience, the same way
learning builds them. Cells that fire together wire together, and the
reverse is equally true: sustained distress degrades and reshapes the
pathways you spent your career building. The brain does not merely
experience trauma. It encodes it into its physical structure. New
pathways form around the damage, and those pathways carry the weight of
what happened into everything that comes after.</p>
I did not know any of this at the time. I only knew that I was broken
and that I had a son who needed me not to be. So I forced myself to
sleep. I forced myself to eat. Eventually I forced myself back under a
barbell because that was the only place left where the rules were
simple: pick the weight up, put it down, do it again. The body
remembers discipline even when the mind has forgotten it.</p>
+++</p>
The wiring that made that moment so destructive was already there long
before the pandemic. It was there before I ever wrote a line of
professional code. I just did not have language for it until much later.</p>
Research over the past decade has identified a trait pattern common
among many autistic people that psychologists now call justice
sensitivity. It describes a heightened awareness of fairness, an
intense emotional response to perceived injustice, and a strong drive
to correct wrongs even when doing so is personally costly. This is not
universal to every autistic person, and the ways it presents vary
widely across the spectrum. But the pattern is well-documented and
consistent enough that researchers have studied it across multiple
populations and methodologies.</p>
A study published in Molecular Autism by Simon Baron-Cohen and
colleagues examined moral foundations in autistic people and people with
systemizing cognitive types. They found that people with systemizing
minds, a cognitive profile that overlaps significantly with autism,
scored higher on Fairness as a moral foundation than people with
empathizing cognitive types. Fairness in this context is defined by
rule-based reasoning: the application of consistent principles
regardless of social context, personal benefit, or group loyalty. The
study found that this commitment to fairness in systemizing minds was
linked to reasoning rather than social conformity, that the moral
judgment was driven by internal principle rather than external pressure.</p>
Al-Attar and Worthington, writing in Advances in Autism, went further.
They examined how moral distress and moral injury operate in the context
of autism. Moral injury is a clinical term for psychological damage
caused by witnessing or participating in acts that violate a person's
deeply held moral beliefs. They hypothesized that autistic individuals
may have a lower threshold for moral distress, and that the heightened
need for rules and the acute distress caused by rule violations can make
autistic people more prone to moral injury. For autistic people with
high justice sensitivity, exposure to dishonesty, exploitation, or
systemic unfairness does not produce a passing discomfort. It produces
genuine harm.</p>
This matters because the trait researchers are describing operates
closer to a reflexive response than a preference or opinion. Many
autistic people report that they cannot compartmentalize injustice the
way neurotypical peers seem to. Where someone else might notice
something unfair, feel briefly bothered, and move on, an autistic person
with high justice sensitivity may find the violation lodged in their
thinking, returning unbidden, producing physiological stress responses
that interfere with sleep, focus, and daily functioning. The brain does
not treat the violation as resolved just because the workday ended. It
keeps processing and signaling that something is wrong.</p>
The wiring works and when applied to the right environment, it produces
people who build honest systems, who fight for users over metrics, who
refuse to ship something they know is harmful, who care about craft and
correctness because those things are expressions of respect for the
people on the other side of the screen. Applied to the wrong
environment, it produces burnout, depression, withdrawal, and rage.</p>
The environment has been getting worse for a long time.</p>
+++</p>
I have been writing software professionally for nearly three decades.
For most of that time, the work felt aligned with something I cared
about. I built systems that connected people to games they loved, that
delivered video to devices in living rooms, that helped workers stay
safe, that moved packets across networks so other engineers could build
things on top of them. The work was hard and the organizations were
imperfect, but the underlying purpose was legible. You could see the
person on the other end. You could understand how what you built served
them.</p>
Somewhere in the last ten to fifteen years, that alignment broke. I
watched the industry shift from building things people needed to
building things that extracted from people as efficiently as possible.
Engagement metrics replaced user satisfaction. Growth at all costs
replaced sustainable design. The people making decisions about what got
built were increasingly people who had never written code or debugged a
production system, who had never sat across from a user and watched
them struggle with something they made. They understood spreadsheets and
fundraising decks and quarterly targets. They did not understand, or did
not care, what their products did to the people using them.</p>
For someone wired the way I am, this shift was a slow-moving injury.
Meetings where someone prioritized vanity metrics over real user needs
left a mark. Architecture decisions driven by "how fast can we ship
this" rather than "how will this serve the person using it" accumulated.
Pushing back and getting overruled, or worse, getting the dead-eyed
look that told me the person across the table did not even understand
what I was objecting to, made the cost go up every time.</p>
Autistic burnout is a condition that researchers are only now beginning
to study rigorously. A systematic review published in Clinical
Psychology Review by Ali, Bougoure, Cooper, and colleagues pulled
together findings across multiple studies and confirmed that autistic
burnout is distinct from occupational burnout. It arises from sensory
and social overwhelm, from the cognitive demands of masking and
camouflaging autistic traits in professional environments, and from
sustained conflict between a person's internal experience and the
external world's demands. People in burnout describe being entirely
drained of energy, losing previously acquired abilities, experiencing
heightened sensory sensitivity, and withdrawing from social contact. One
participant in an earlier study described it as a complete regression of
skills.</p>
I recognize every word of that description. I have lived it more than
once. The version that hit during the pandemic was the worst because it
combined the isolation of a global shutdown with the moral injury of
being asked to participate in fraud while my capacity to absorb any
additional harm was already at zero.</p>
What people who have not experienced autistic burnout may not understand
is what the withdrawal looks like from the inside. The mind reaches a
threshold where it can no longer sustain the gap between what it knows
to be right and what it is being asked to do, between who you are and
who the environment demands you pretend to be. The masking research
confirms this: the sustained effort of passing as neurotypical in
professional settings, of suppressing your natural responses, of
performing social scripts that do not come naturally, is cognitively
exhausting. It drains the same resources you need to actually do your
job. Add moral injury on top of that cognitive load and the system
crashes.</p>
I stopped training, building side projects, and reading technical papers.
For a period of time I stopped doing anything beyond the minimum
required to keep my son fed, safe, and stable. Without him I do not know
where the bottom would have been.</p>
Recovery was mechanical. Sleep. Food. Eventually the barbell again.
Enough days in a row of doing the basic things that the pathways started
to rebuild. Not the same pathways since the brain does not restore to a
backup. It builds new ones, and the new ones carry the scar tissue of
what happened. I am not the same engineer I was before that period. I am
more guarded, more selective about who I work with and what I work on. I
am faster to walk away from situations that trip the wiring. Some people
might call that growth. It feels more like adaptation.</p>
+++</p>
If you have read this far and recognized yourself in any of it, I want
you to know you are not imagining things and you are not too sensitive.
The thing you feel when you watch a company optimize for addiction over
wellbeing, when you see a colleague ship something they know is broken
because the deadline matters more than the user, when you sit in a
meeting and realize that nobody else in the room is bothered by what is
being proposed, that thing is real. It has a name and a neurological
basis, and it carries a cost that accumulates whether you acknowledge it
or not.</p>
There is a pattern among neurodivergent people in technology that does
not get talked about enough. Many of us entered this field because it
seemed like a place where the things we valued, precision, honesty,
systems that work the way they are supposed to, fairness encoded into
logic, were also the things the field valued. Programming rewarded the
way our minds worked. Building systems that were correct, reliable, and
honest felt like an extension of who we were. The alignment between our
wiring and our work was not just professional satisfaction. It was a
rare experience of belonging for people who had spent most of their
lives not belonging anywhere.</p>
The erosion of that alignment is what makes the current state of
technology so specifically damaging to neurodivergent engineers. The
work did not get harder. Hard work was never the problem. The purpose
of the work changed. The field we entered because it valued what we
valued started valuing something else, and the thing it started valuing
is in direct conflict with the wiring that brought us here.</p>
Research on justice sensitivity in neurodivergent populations
consistently finds that autistic people's moral reasoning is resistant
to peer pressure. Where neurotypical individuals often shift their
moral positions when confronted by social consensus, autistic
individuals tend to hold steady. Their sense of right and wrong is built
on internal principle, not social negotiation. In a healthy environment
this produces people of extraordinary integrity. In a toxic one, it
produces people who cannot adapt to the toxicity and burn out instead.</p>
If you are neurodivergent and working in technology and you have burned
out, or you are burning out right now, consider that the problem might
not be your resilience. The problem might be that you are responding
correctly to an environment that has become genuinely hostile to the
values that define how your mind works. Your response is information,
and you should treat it that way.</p>
+++</p>
My son is twelve. My stepdaughter is eleven. In ten years they will be
young adults navigating a world that I helped build and that I am
increasingly afraid of.</p>
My son's school issued him a Chromebook. It is a Google device running
Google software connected to Google services that track what he does,
when he does it, and how long it takes. He did not choose this. His
parents did not choose this. The school district chose it because Google
made the devices cheap and the software free, and the actual cost, his
behavioral data, his attention patterns, his developing digital
identity, is paid by him in a currency he does not yet understand. He
is twelve. He cannot opt out. The Chromebook is required for class.</p>
This is one device in one school in one district. Scale it out.</p>
Algorithmic feeds on platforms that children are socially required to
participate in, TikTok, YouTube, Instagram, are engineered to maximize
time on screen. The optimization target is not the child's wellbeing,
education, or development. The optimization target is engagement, which
in practice means emotional provocation, because provoked people scroll
longer. A twelve-year-old autistic boy with high justice sensitivity
being fed a stream of content algorithmically selected to provoke
emotional reactions is a resource being extracted from, not a user being
served.</p>
AI systems are being marketed into education as tutors, assistants, and
companions. Companies are positioning AI chatbots as tools that children
should interact with for learning, for emotional support, for
socialization. A generation of children is being trained to treat a
statistical model as a conversational partner, to trust the output of a
system that has no understanding of truth, no commitment to their
wellbeing, and no accountability for the consequences of what it tells
them. The children are not the customers. They are the training data.</p>
AI-generated content is flooding the information environment with
synthetic text, images, and video. A twelve-year-old trying to
research a school project now has to navigate an internet where a
significant and growing percentage of the content was not created by a
human being, was not reviewed by a human being, and may contain
fabricated information presented with the visual authority of legitimate
sources. Adults struggle to distinguish real from synthetic. We are
asking children to do it as a baseline life skill.</p>
The standard response to all of this is "digital literacy." Teach kids
to think critically about what they see online. Teach them to evaluate
sources. Teach them to recognize manipulation. All of that is fine, and
insufficient. Teaching someone defensive driving does not help when the
highway itself is designed to crash them. The systems are adversarial,
designed by teams of engineers and psychologists to defeat exactly the
kind of critical thinking that digital literacy programs try to instill.
You cannot educate your way out of an arms race when one side has
billions of dollars and the other side is a sixth grader.</p>
The thread that runs through all of this is isolation. Chromebooks
replace shared physical workspaces with individual screens. Algorithmic
feeds turn shared social experience into personalized content silos. AI
companions stand in for human relationships with synthetic ones. Every
layer of technology being introduced into children's lives is a layer
that moves them further from direct human contact, from the messy,
unpredictable, irreplaceable experience of being with other people.</p>
My son said he wants to measure the temperature outside. Six words. But
those six words carry the same impulse that built the technology
industry in the first place: the need to understand how something works,
to see the whole system from sensor to wire to screen. That impulse
produced engineers who cared about craft, about correctness, about the
people who would use what they built. It is the impulse that the current
trajectory of technology is systematically grinding out of the next
generation by replacing understanding with consumption, building with
scrolling, and human connection with algorithmic engagement.</p>
I am afraid that my son will grow up in a world that takes his beautiful
autistic mind, his need for fairness, his drive to understand systems
honestly, and treats those qualities as friction to be optimized away.
He might learn to trust platforms because they are ubiquitous and assume
they are benevolent because they are free. The false sense of security
that comes from living inside technology you did not build and do not
understand could become the default state of his generation. By the time
he realizes what he has given up, the alternatives may be harder to
find.</p>
+++</p>
I am more on the outside of the industry now than I have been at any
point in my career, and from the outside I can see things I could not
see when I was in the middle of it.</p>
I can see that the path we are on was built by human decisions and can
be changed by human decisions. There is nothing inevitable about the
current trajectory. Every platform, every algorithm, every exploitative
design pattern was chosen by people who could have chosen differently.
The choices are the problem. And choices can be refused.</p>
I choose differently now. At home, I built a central digital dashboard
for my family on a Raspberry Pi running open source software. It shows
our shopping list, the weather, the information we actually need. There
is no platform. There is no account. There is no company collecting data
on what my family buys or when we check the forecast. It is a computer
doing what a computer is supposed to do: serving the people who use it,
not the people who built it.</p>
My son asked to build a thermostat because he saw the dashboard and
understood something without needing to say it in a lot of words:
technology does not have to be opaque. It does not have to phone home.
It does not have to belong to someone else. He is twelve years old and
he already knows something that billion-dollar companies are hoping his
generation never figures out: that you can build your own tools, that
the tools can be simple, that the tools can belong to you.</p>
I choose the clients I work with based on whether their work serves
people honestly, I choose tools without platforms when the option
exists, and I teach my family that technology is something you build and
understand rather than something you consume and trust. These are
small choices. They do not scale. They do not disrupt anything. They are
acts of refusal so small that the systems I am refusing would not notice
if I described them in a board meeting.</p>
But refusal is where it starts.</p>
Every person who chooses to build instead of consume, to understand
instead of trust blindly, to walk away from work that violates their
sense of what technology should be for, is a crack in the consensus
that this is just how things are now. The consensus is a lie. Humans
built this path, humans maintain it, and humans can build a different
one.</p>
Unfortunately, I am not optimistic about the industry. I have seen too
much to believe that the companies driving the current trajectory will
change direction because someone wrote a persuasive essay or because
regulators caught up. They will not bwcause the incentives are too
strong and the money is too good and the people making the decisions are
too insulated from the consequences.</p>
But I am not writing this for the industry. I am writing this for the
person who recognizes themselves in what I have described. The autistic
engineer who burned out and thought it was their fault. The
neurodivergent parent who watches their kid on a school-issued device
and feels something wrong they cannot articulate. The person who cares
about fairness in a world that has decided fairness is not profitable.</p>
You are not broken. The thing you feel when something is wrong is a
signal, and it is accurate. The cost of carrying that signal in an
environment that punishes you for receiving it is real, and you are not
imagining it.</p>
Do not stop fighting for yourself and for yours. Build the thermostat.
Build the dashboard. Teach your kids that the tools can belong to them.
Choose the work that lets you sleep at night. Walk away from the work
that does not. Find the people who are wired like you and hold onto
them, because the isolation is the thing that breaks you and the
connection is the thing that keeps you whole.</p>
At the end of the day, you are the only one you can truly count on. That
is the foundation everything else gets built on. Remember the plaque
hanging above the Oracle's kitchen doorway.</p>

Temet Nosce: "It's Latin. It means 'know thyself'." - Oracle</p>
</blockquote>
Trust what your mind is telling you. And refuse, as many times as it
takes, to participate in systems that violate what you know to be right.</p>
The systems we build should support and serve the people who use them. A
twelve-year-old who said "I want to measure the temperature outside"
understands that instinctively. The fact that an industry of adults has
forgotten it makes insisting matter more, not less.</p>
+++</p>
References</h2>
[1]: Greenberg, Y.D.M., Holt, R., Allison, C., Smith, P., Newman, R.,
Boardman-Pretty, T., Haidt, J., & Baron-Cohen, S. (2024). Moral
foundations in autistic people and people with systemizing minds.
Molecular Autism</em>, 15, 20.
https://doi.org/10.1186/s13229-024-00591-8</p>
[2]: Al-Attar, Z. & Worthington, R. (2024). Moral distress and moral
injury in the context of autism. Advances in Autism</em>, 10(3), 200-219.
https://doi.org/10.1108/AIA-05-2023-0025</p>
[3]: Ali, D., Bougoure, M., Cooper, B., Quinton, A.M.G., Tan, D.,
Brett, J., Mandy, W., Maybery, M., Magiati, I., & Happe, F. (2025).
Burnout as experienced by autistic people: A systematic review.
Clinical Psychology Review</em>, 122, 102669.
https://doi.org/10.1016/j.cpr.2025.102669</p>
[4]: Raymaker, D.M., Teo, A.R., Steckler, N.A., Lentz, B., Scharer,
M., Delos Santos, A., Kapp, S.K., Hunter, M., Joyce, A., &
Nicolaidis, C. (2020). "Having all of your internal resources
exhausted beyond measure and being left with no clean-up crew":
Defining autistic burnout. Autism in Adulthood</em>, 2(2), 132-143.
https://doi.org/10.1089/aut.2019.0079</p>
[5]: Mantzalas, J., Richdale, A.L., Li, X., & Dissanayake, C. (2024).
Measuring and validating autistic burnout. Autism Research</em>, 17(5),
812-823. https://doi.org/10.1002/aur.3129</p>
[6]: Rădulescu, I., Drăgoi, A.M., Trifu, S.C., & Cristea, M.B.
(2021). Neuroplasticity and depression: Rewiring the brain's networks
through pharmacological therapy (Review). Experimental and Therapeutic
Medicine</em>, 22(4), 1131. https://doi.org/10.3892/etm.2021.10565</p>

Building Go APIs with Huma, sqlc, and Goose

2026-04-07T00:00:00+00:00

I've been building an API recently with a stack that I think hits a sweet spot of just enough structure to keep a team productive, not so much that you're fighting the tools. The stack is Huma</a> for the HTTP layer, sqlc</a> for database queries, and Goose</a> for migrations. Each tool does one thing well and stays out of your way for everything else.
The ideas is simple. Write SQL for your schema and queries to generate the Go code. Then, wire it into typed HTTP operations that produce an OpenAPI spec automatically. This avoids an ORM and its magic, especially no runtime reflection surprises. Also, a new engineer can clone the repo and understand the full request path in an afternoon.
Project Layout</h2>
my-api/ ├── cmd/ │ └── server/ │ └── main.go ├── sql/ │ ├── migrations/ │ │ ├── 001_create_widgets.sql │ │ └── 002_add_widget_status.sql │ └── queries/ │ └── widgets.sql ├── db/ │ ├── db.go │ ├── models.go │ └── widgets.sql.go ├── sqlc.yaml ├── go.mod └── Makefile</code></pre> There is nothing novel here. All SQL lives under sql/</code> with migrations and queries separated into their own subdirectories. sqlc dumps its generated Go code into db/</code> which becomes your importable package. The db/</code> directory is checked into version control so the project builds without needing sqlc installed, but it's also .gitignore</code>-able if your team prefers to generate on CI. Pick one and be consistent. Migrations with Goose</h2> Goose handles schema changes with plain SQL files. Each migration has an -- +goose Up</code> and -- +goose Down</code> block. There is no additional cognitive overhead to understand some migration DSL. It is just SQL. sql/migrations/001_create_widgets.sql -- +goose Up CREATE TABLE widgets ( id BIGSERIAL PRIMARY KEY, name TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); -- +goose Down DROP TABLE widgets;</code></pre> sql/migrations/002_add_widget_status.sql -- +goose Up ALTER TABLE widgets ADD COLUMN status TEXT NOT NULL DEFAULT 'active'; -- +goose Down ALTER TABLE widgets DROP COLUMN status;</code></pre> Run them forward with goose -dir sql/migrations postgres "$DATABASE_URL" up</code> and roll them back with down</code>. That's it. The migration files are also your schema source of truth, which matters for the next step. Queries with sqlc</h2> sqlc reads your schema, reads your annotated SQL queries, and generates type-safe Go code. The key decision here is pointing sqlc at the sql/migrations</code> directory for its schema instead of maintaining a separate schema.sql</code> file. sqlc.yaml version: "2" sql: - engine: "postgresql" queries: "sql/queries" schema: "sql/migrations" gen: go: package: "db" out: "db" sql_package: "pgx/v5"</code></pre> Setting schema</code> to sql/migrations</code> tells sqlc to read every .sql</code> file in that directory, parse the goose annotations, and build up the full schema from the migration history. This means adding a column in a new migration automatically makes it available to your queries without touching any config. sqlc understands the goose format natively so the -- +goose Up</code> and -- +goose Down</code> blocks are handled correctly. Now write some queries. sql/queries/widgets.sql -- name: GetWidget :one SELECT * FROM widgets WHERE id = $1 LIMIT 1; -- name: ListWidgets :many SELECT * FROM widgets ORDER BY created_at DESC; -- name: CreateWidget :one INSERT INTO widgets (name, status) VALUES ($1, $2) RETURNING *; -- name: DeleteWidget :exec DELETE FROM widgets WHERE id = $1;</code></pre> Run sqlc generate</code> and you get db/</code> with models that match your schema and methods that match your queries. The generated Queries</code> struct accepts a pgx</code> connection and gives you methods like GetWidget(ctx, id)</code> that return a typed Widget</code> struct. No interface{}</code>, no map[string]any</code>, no row scanning boilerplate. The generated code looks roughly like this (abbreviated): db/models.go package db import "time" type Widget struct { ID int64 Name string Status string CreatedAt time.Time }</code></pre> db/widgets.sql.go package db import "context" const getWidget = `-- name: GetWidget :one SELECT id, name, status, created_at FROM widgets WHERE id = $1 LIMIT 1 ` func (q *Queries) GetWidget(ctx context.Context, id int64) (Widget, error) { row := q.db.QueryRow(ctx, getWidget, id) var i Widget err := row.Scan(&i.ID, &i.Name, &i.Status, &i.CreatedAt) return i, err } // CreateWidget, ListWidgets, DeleteWidget follow the same pattern</code></pre> You write SQL and you get Go. The generated code is readable, boring, and correct. That's what you want. HTTP Operations with Huma</h2> Huma is a framework that generates OpenAPI specs from your Go types. You define input and output structs with struct tags and Huma does the rest: validation, documentation, request parsing, response marshaling, and serving the spec at /openapi.json</code> with an interactive doc site built in. Start with the input and output types for a "get widget" operation. type GetWidgetInput struct { ID int64 `path:"id" doc:"Widget ID" example:"42"` } type WidgetOutput struct { Body struct { ID int64 `json:"id" example:"42" doc:"Widget ID"` Name string `json:"name" example:"Sprocket" doc:"Widget name"` Status string `json:"status" example:"active" doc:"Widget status"` CreatedAt string `json:"created_at" example:"2025-04-07T12:00:00Z" doc:"Creation timestamp"` } } type CreateWidgetInput struct { Body struct { Name string `json:"name" required:"true" maxLength:"255" doc:"Widget name"` Status string `json:"status" required:"true" enum:"active,inactive" doc:"Widget status"` } } type ListWidgetsOutput struct { Body []struct { ID int64 `json:"id"` Name string `json:"name"` Status string `json:"status"` CreatedAt string `json:"created_at"` } }</code></pre> Every struct tag feeds directly into the OpenAPI spec. The required</code>, maxLength</code>, and enum</code> tags become validation rules that Huma enforces before your handler ever runs. If someone sends a widget name longer than 255 characters they get a 422 back with a clear error message and your handler never sees the request. That's free input validation from type definitions you were going to write anyway. Wiring It Together</h2> Here's what main.go</code> looks like when you connect all three pieces. cmd/server/main.go package main import ( "context" "fmt" "log" "net/http" "github.com/danielgtaylor/huma/v2" "github.com/danielgtaylor/huma/v2/adapters/humago" "github.com/go-chi/chi/v5" "github.com/jackc/pgx/v5/pgxpool" gendb "my-api/db" ) func main() { ctx := context.Background() // Connect to PostgreSQL pool, err := pgxpool.New(ctx, "postgres://localhost:5432/myapi") if err != nil { log.Fatal(err) } defer pool.Close() // Create the sqlc queries instance queries := gendb.New(pool) // Set up the router and Huma API router := http.NewServeMux() api := humago.New(router, huma.DefaultConfig("My API", "1.0.0")) // Register operations huma.Get(api, "/widgets/{id}", func(ctx context.Context, input *GetWidgetInput) (*WidgetOutput, error) { widget, err := queries.GetWidget(ctx, input.ID) if err != nil { return nil, huma.Error404NotFound("widget not found") } resp := &WidgetOutput{} resp.Body.ID = widget.ID resp.Body.Name = widget.Name resp.Body.Status = widget.Status resp.Body.CreatedAt = widget.CreatedAt.Format("2006-01-02T15:04:05Z") return resp, nil }) huma.Post(api, "/widgets", func(ctx context.Context, input *CreateWidgetInput) (*WidgetOutput, error) { widget, err := queries.CreateWidget(ctx, gendb.CreateWidgetParams{ Name: input.Body.Name, Status: input.Body.Status, }) if err != nil { return nil, fmt.Errorf("creating widget: %w", err) } resp := &WidgetOutput{} resp.Body.ID = widget.ID resp.Body.Name = widget.Name resp.Body.Status = widget.Status resp.Body.CreatedAt = widget.CreatedAt.Format("2006-01-02T15:04:05Z") return resp, nil }) huma.Get(api, "/widgets", func(ctx context.Context, input *struct{}) (*ListWidgetsOutput, error) { // Fill in logic here return nil, nil }) huma.Delete(api, "/widgets/{id}", func(ctx context.Context, input *GetWidgetInput) (*struct{}, error) { // Fill in logic here return nil, nil }) log.Println("listening on :8080") http.ListenAndServe(":8080", router) }</code></pre> That's the full loop. The handler receives validated, typed input from Huma. It calls a generated, typed query from sqlc. It returns a typed response that Huma serializes to JSON and documents in the OpenAPI spec. No reflection at runtime. No hand-written row scanning. No spec that drifts from the implementation. The OpenAPI Spec</h2> Start the server and hit http://localhost:8080/openapi.json</code>. You get a full OpenAPI 3.1 spec generated from the types you already wrote. Huma also serves interactive docs at /docs</code> out of the box. Every doc</code>, example</code>, enum</code>, required</code>, and maxLength</code> tag you put on your structs shows up in the spec and the doc site. This matters when you're working with a team. Frontend engineers, mobile developers, QA, whoever needs to know what the API does can pull up the docs and see the current state of things. The spec is always correct because it's generated from the code that's running. There is no separate YAML file to maintain, forget about, or let rot. The Makefile</h2> A simple Makefile</code> ties the workflow together so any engineer on the team can run the same commands. DATABASE_URL ?= postgres://localhost:5432/myapi .PHONY: generate migrate run generate: sqlc generate migrate-up: goose -dir sql/migrations postgres "$(DATABASE_URL)" up migrate-down: goose -dir sql/migrations postgres "$(DATABASE_URL)" down run: generate go run ./cmd/server</code></pre> make migrate-up</code> runs them forward, make migrate-down</code> rolls one back. If you add a new column just write a migration, write a query, run make generate</code>, and wire it into a handler. The cycle is short and the feedback is immediate because every step produces something you can read and verify. Why This Stack</h2> There are a lot of ways to build an API in Go. ORMs like GORM and Ent generate code too, but they also hide your SQL behind method chains and builders that make it harder to reason about what's actually hitting the database. sqlc flips this: you write the SQL and it generates the Go. The SQL is right there in your repo, reviewable, explainable, and directly runnable against your database for debugging. Goose stays out of the way. It's a binary that reads SQL files and applies them in order. No migration DSL to learn, no Go structs that model your schema changes. The migration files are the same SQL you'd run by hand and that makes them easy to review in a pull request. Huma earns its place by giving you an OpenAPI spec without a separate design step. The types you define for your handlers are the spec. The validation you need is expressed in struct tags, not in middleware or manual checks scattered across your handlers. And because Huma is bring-your-own-router, you're not locked into anything you can't swap out later. The three tools don't know about each other. They compose through the filesystem: goose writes migrations, sqlc reads them, Huma reads Go types. There's no plugin system, no framework coupling, and no vendor lock-in between them. If you outgrow one you replace it without touching the others. I've had new folks join a team with this stack and every single person was up and running adding new features in less than a few days, even folks who are not usually backend software developers. That's the whole point. Enough boilerplate to keep things consistent across a team. Not enough to make you hate the tooling and espcially obfuscate the important logic.

Vendoring Modules in Hare

2026-03-28T00:00:00+00:00

Hare doesn't have a package manager. This is by design and I'm glad for it. No dependency hell, no lock files, no node_modules</code> black hole. However, you still need a way to pull in third-party code. There are two approaches:
system-wide installation via make install</code>, and</li>vendoring directly into your project with git subtree</code>.</li> </ol> I'll use hare-json</a> as the running example throughout. Our goal is to be able to use this module like so: use encoding::json; use fmt export fn main() void = { let obj = json::newobject(); defer json::finish(obj); json::set(&obj, "hello", "world")!; json::set(&obj, "foo", "bar")!; json::set(&obj, "the answer", 42.0)!; ... };</code></pre> The encoding/</code> folder within the hare-json</code> module needs to be found by the Hare toolchain so that when we use</code> it it will then follow the folder path encoding/json/</code> via encoding::json</code> and find all the *.ha</code> files. How Hare finds modules</h2> When you write use encoding::json;</code> in your code, the build driver looks for a directory called encoding/json/</code> containing .ha</code> files. It searches a list of source roots in this order: The current working directory (.</code>) which is always first, always implicit</li> Each directory listed in the HAREPATH</code> environment variable, colon-delimited</li> If HAREPATH</code> is unset, a compiled-in default (typically the stdlib and third-party install locations)</li> </ol> Check yours with: $ hare version -v hare 0.26.0 build tags: +x86_64 +linux tool paths: HAREPATH (from environment): vendor/*/ /usr/src/hare/third-party /usr/src/hare/stdlib /usr/local/src/hare/third-party /usr/local/src/hare/stdlib toolchains: aarch64: AS=as CC=cc LD=ld riscv64: AS=as CC=cc LD=ld x86_64: AS=as CC=cc LD=ld</code></pre> This is the result of mine since I set my HAREPATH</code> in my .zshrc</code>, but on a typical Linux system with Hare installed to /usr/local</code>, the default HAREPATH</code> looks something like: /usr/local/src/hare/stdlib:/usr/local/src/hare/third-party</code></pre> First directory with .ha</code> files matching the module path wins. That's the entire resolution algorithm. Simple. The repo layout convention</h2> Most Hare libraries follow a naming convention: the repo is called hare-MODULE</code>, and the actual module code lives in a top-level directory named after the module. For hare-json: hare-json/ ├── encoding/ │ └── json/ │ ├── types.ha │ ├── lex.ha │ ├── value.ha │ └── ... ├── Makefile ├── README └── COPYING</code></pre> The code you import as encoding::json</code> lives under encoding/json/</code>. This means the parent directory of encoding/</code> is what needs to be on HAREPATH</code>. Not the json/</code> directory itself. Not the repo root unless the repo root is that parent directory. This is where most people trip up. Approach 1: System-wide install</h2> Clone, make, done. $ git clone https://git.sr.ht/~sircmpwn/hare-json $ cd hare-json $ make install</code></pre> The Makefile handles putting .ha</code> files into the right location. A typical Hare library Makefile looks like: .POSIX: .SUFFIXES: HARE=hare HAREFLAGS= DESTDIR= PREFIX=/usr/local SRCDIR=$(PREFIX)/src HARESRCDIR=$(SRCDIR)/hare THIRDPARTYDIR=$(HARESRCDIR)/third-party install: install -Dm644 encoding/json/* $(DESTDIR)$(THIRDPARTYDIR)/encoding/json/ uninstall: rm -rf $(DESTDIR)$(THIRDPARTYDIR)/encoding/json</code></pre> The default THIRDPARTYDIR</code> resolves to /usr/local/src/hare/third-party</code>, which is already in the default HAREPATH</code>. After make install</code>, use encoding::json;</code> just works. If your Hare installation lives under /usr</code> instead of /usr/local</code>: $ make PREFIX=/usr install</code></pre> Or a custom path entirely: $ make THIRDPARTYDIR=/opt/hare/libs install</code></pre> Just make sure whatever path you install to is in your HAREPATH</code>. This approach is clean and simple. Every project on the system can use the module with zero configuration. The downside is versioning: all projects share the same installed version. If project A needs an older hare-json and project B needs a newer one, you're stuck. There's no record in your project's repo of which dependencies you need or what versions they are either. A new contributor has to read your README and manually install each one. Approach 2: Vendoring with git subtree</h2> For reproducible builds and per-project dependency management, vendor the module source directly into your project. From your project root: $ git subtree add --prefix vendor/hare-json \ https://git.sr.ht/~sircmpwn/hare-json master --squash</code></pre> This creates vendor/hare-json/</code> with the full contents of the repo: my-project/ ├── main.ha ├── vendor/ │ └── hare-json/ │ ├── encoding/ │ │ └── json/ │ │ ├── types.ha │ │ ├── lex.ha │ │ └── ... │ ├── Makefile │ └── README └── Makefile</code></pre> Remember the layout convention: encoding/json/</code> is relative to the repo root vendor/hare-json/</code>. So the path that goes on HAREPATH</code> is vendor/hare-json</code>. Not vendor/</code>. Not vendor/hare-json/encoding/json/</code>. Updating a vendored dependency</h3> $ git subtree pull --prefix vendor/hare-json \ https://git.sr.ht/~sircmpwn/hare-json master --squash</code></pre> Upstream changes get merged in. --squash</code> collapses the upstream history into a single commit. Setting HAREPATH</h3> Important: when you set HAREPATH</code> as an environment variable, it completely replaces the compiled-in default. You must re-include the stdlib and third-party paths yourself or the build driver won't find the standard library. Run hare version -v</code> to see what those paths are on your system. The Hare docs mention establishing vendor/*/</code> as a default convention for HAREPATH</code>, but as of this writing it does not work. The glob does not expand the way you'd expect and the build driver won't find your modules. You need to specify each vendored module path explicitly. The way to do this is in your project Makefile: .POSIX: .SUFFIXES: HARE=hare HAREFLAGS= HAREPATH=vendor/hare-json:/usr/local/src/hare/third-party:/usr/local/src/hare/stdlib build: HAREPATH=$(HAREPATH) $(HARE) build $(HAREFLAGS) -o my-project cmd/my-project/ check: HAREPATH=$(HAREPATH) $(HARE) test $(HAREFLAGS)</code></pre> Multiple vendored deps, list each one: HAREPATH=vendor/hare-json:vendor/hare-xml:vendor/hare-http:/usr/local/src/hare/third-party:/usr/local/src/hare/stdlib</code></pre> Colon-separated, just like PATH</code>. Adjust the stdlib and third-party paths to match your system. The tradeoff is you need to update the Makefile every time you add or remove a vendored dependency, and the stdlib paths are hardcoded to one install prefix. Vendoring pros and cons</h3> You get reproducible builds, per-project versioning, and a self-contained repo that any contributor can clone and build immediately. Dependencies are explicit in the source tree. The cost is a larger repo since you're committing the dependency source and a slightly more complex build setup. You also need to manually pull upstream changes when you want them. Which to use</h2> Personal projects, scripts, small tools: make install</code>. Fast, simple, done. Anything collaborative, anything you want reproducible builds for, anything that might need pinned dependency versions: vendor with git subtree</code>. The overhead is minimal and the payoff is real. You can combine both. Install common modules system-wide for convenience during development and vendor them for CI and release builds. Since .</code> has the highest priority in HAREPATH</code> and vendored paths come before the defaults, the resolution order does what you'd expect. Hare's growing ecosystem</h2> You can find a lot of Hare projects on https://sourcehut.org</a> and https://codeberg.org</a>, but there is also a community currated list that is growing all the time on the Project Library</a> page of the official Hare website.
Crocker's Rules 2026-03-23T00:00:00+00:00 I came across an article</a> recently that references something called Crocker's Rules</a>. I had never heard of them by name, but when I read the definition I realized I've been operating this way for most of my career without knowing there was a term for it. The short version is this: if you declare Crocker's Rules you are telling people around you that they can optimize their communication for information, not for your feelings. You take full responsibility for your own emotional reaction to what someone tells you. It doesn't mean people get to be cruel. It means neither party wastes time on social padding that adds zero signal to the conversation. I've written before about discipline and posture</a> in engineering and about being allergic to unnecessary complexity</a>. If you've read any of those you already know I don't soften things much. I say what I mean. I expect others to do the same. Why This Matters in Engineering</h2> Think about the last code review you did. How much of the feedback was buried under "hey, great work overall, just a small thought, feel free to ignore this, but..." before the reviewer finally got to the point? That padding isn't politeness. It's noise. It trains people to skim your reviews, which means when you flag something that actually matters they'll probably miss it. Compare these two PR comments: "I hope this doesn't come across the wrong way but I was wondering if maybe the error handling here could potentially be improved? Just a thought!" </blockquote> vs. "This swallows the error silently. Propagate it to the caller so we can debug failures." </blockquote> The second one is more useful, faster to read, and honestly more respectful of everyone's time. Nobody reading the first one thinks better of the person who wrote it. They just have to dig through the fluff to find out what they actually need to change. The same applies to incident reports. If the payment service went down because a config value was wrong then write that. The fact that you were stressed, inherited the config from someone else, or that the docs were unclear is not relevant unless it leads to a structural fix you can attach a concrete action item to. Everything else is noise that buries what the on-call engineer needs to act on right now. It's a Discipline, Not a Personality Trait</h2> The original definition makes an important distinction. Crocker's Rules are a discipline, not a privilege. You don't get to be an asshole and call it "being direct." The point is that the receiver takes responsibility for managing their emotional reaction so the sender doesn't have to spend time softening the message. Both parties benefit because the information moves faster and cleaner. This also means you have to actually have the mental discipline to not take things personally when someone tells you your approach is wrong. That's the hard part. Most people skip right to the "I get to be blunt" side without doing the work on the "I can receive blunt feedback without spiraling" side. If you can't do the second part then don't bother with the first. Where I've Seen It Work</h2> The best teams I've been on didn't know about Crocker's Rules either, but they operated that way naturally. Code reviews had real questions and real feedback. Pull requests came with context, not apologies. When something broke we talked about what broke and why, not who was at fault or what extenuating circumstances led to the mistake. The worst teams I've been on were the opposite. Everything was wrapped in so much politeness that nobody said what they actually meant. Problems festered because pointing them out felt like an attack. PRs got rubber-stamped with "LGTM" because giving real feedback might hurt someone's feelings. That's not kindness. That's how you end up with systems nobody understands and nobody wants to touch. Adopt It or Don't</h2> I'm not going to preach that everyone needs to follow Crocker's Rules. Some people aren't wired for it and that's fine. But if you work with me you should know that when I say something is wrong I'm not attacking you, I'm telling you what I see so we can fix it together. And I expect the same in return. Tell me my code is bad. Tell me my design has a flaw. Skip the preamble and just say the thing. I'd rather hear it now than debug it at 2am. If you want to give me feedback on this you can hit me up via any of the links in the footer of this site. Humanities in the Machine 2026-03-13T00:00:00+00:00 There is something quietly remarkable about the people who built the foundations of modern computing. Not their technical achievements, though those are extraordinary. What is remarkable is where they came from before they ever touched a machine. Tony Hoare, who inspired the writing of this essay, studied Classics and Philosophy at Oxford: Latin, Greek, and modern philosophy under the "Greats" program at Merton College. As a schoolboy, he read George Bernard Shaw and Bertrand Russell and harbored a youthful aspiration to become a writer. He did not encounter computing until after he graduated in 1956 and only stumbled into programming after completing his National Service in the Royal Navy, where he had learned Russian. His interest in computers was awakened not by engineering curiosity, but by a fascination with the power of mathematical logic as an explanation of the apparent certainty of mathematical truth. That is a philosopher's question, not a programmer's. Hoare went on to create Quicksort, one of the most widely used sorting algorithms in the history of computing. He developed Hoare logic, which gave programmers a formal way to prove that their programs are correct. He introduced Communicating Sequential Processes, a language for reasoning about how concurrent programs interact. Each of these contributions changed the shape of computer science. And each of them carries the fingerprints of a mind trained not in engineering but in philosophy, in the careful construction of arguments, in the pursuit of clarity and correctness not as engineering goals but as intellectual virtues. Hoare himself said his interests went back to the ancient philosophers Aristotle and Euclid, and that their teachings provided an excellent basis for a general understanding, even today. A book of essays honoring his 60th birthday was titled A Classical Mind, a reference to his educational background in Literae Humaniores. His colleagues described his writing as having a "cultured style." When he spoke about software design, he said there are two ways to construct it: make it so simple that there are obviously no deficiencies, or make it so complicated that there are no obvious deficiencies. That is not an engineering observation. That is a philosophical one, rooted in the same tradition of clarity and economy of expression that the classical education instills. Tony Hoare passed away in March 2026. The field lost not just a computer scientist, but a classicist who happened to turn his attention to machines. +++ Before Hoare, before any of them, there was Ada Lovelace. Born in 1815 as the only legitimate child of the poet Lord Byron, Lovelace was steered deliberately away from poetry by her mother, who feared the "insanity" she associated with Byron's literary temperament. Mathematics and science were prescribed as a kind of intellectual medicine. Lovelace's mother ensured she received rigorous tutoring in logic and mathematics from some of the finest minds available, including the mathematician Augustus De Morgan and the scientific author Mary Somerville. But the poetical inheritance could not be suppressed. Lovelace described her own approach as "poetical science" and herself as an "Analyst and Metaphysician." She did not see mathematics and imagination as opposing forces. She saw them as collaborators. When she encountered Charles Babbage's Analytical Engine, a mechanical computing device that existed only in design, she saw something that Babbage himself and every other mathematician of her era did not see: that the machine could go beyond pure calculation. She wrote that if the fundamental relations of pitched sounds in the science of harmony were susceptible to such expression, the engine might compose elaborate pieces of music of any degree of complexity or extent. That insight, that a computing machine could manipulate any symbolic system and not merely numbers, is the founding conceptual leap of modern computing. It did not come from mathematics. It came from a mind that refused to separate the analytical from the poetical, a mind that understood machines not merely as calculators but as extensions of human creative capacity. A pure mathematician would not have made that leap. It required someone who lived between disciplines, who saw the world through both lenses at once. Lovelace died at 36. She never saw a working computer. But her "poetical science" anticipated the entire field by more than a century. +++ Edsger Dijkstra was born in Rotterdam in 1930. His mother was a mathematician and his father a chemist. Before he ever encountered a computer, he attended the Erasmiaans Gymnasium, one of the most prestigious secondary schools in the Netherlands, where he studied classical Greek and Latin alongside French, German, English, mathematics, physics, chemistry, and biology. He scored the highest possible marks in six out of thirteen subjects on his final exams. His early ambition was not to become a scientist. He wanted to study law and represent the Netherlands at the United Nations. He chose theoretical physics instead, and then stumbled into programming at the Mathematical Centre in Amsterdam, where he was offered a part-time job in 1952. But the classical education never left him. Dijkstra became one of the most important figures in the history of computing. He formulated the shortest path algorithm, developed structured programming, introduced the concept of semaphores for coordinating concurrent processes, and wrote the famous letter, "Go To Statement Considered Harmful", that reshaped how programmers think about control flow. His Turing Award lecture was titled "The Humble Programmer." What set Dijkstra apart from his peers was not only the depth of his technical insight, but the way he expressed it. Over the course of his career, he wrote more than 1,300 numbered manuscripts, known as the EWDs (Edsger Wybe Dijkstra), almost entirely by hand. They were not technical reports. They were essays, written in a prose style that his colleagues described as extraordinary. He could write about formal issues in the form of an essay, with hardly any formulas. He discussed algorithms in plain prose, deriving intricate solutions in distributed computing in a seemingly informal way. His handwriting was so distinctive that a computer font was later created from it. Colleagues who received one of his handwritten letters sometimes thought they were personal notes before realizing they were formal publications. Dijkstra increasingly viewed programming as a mental activity, an intellectual discipline that demanded clarity of thought above all else. His courses at the University of Texas at Austin had little to do with computer science in the conventional sense. They dealt with the presentation of mathematical proofs. On the department's homepage, his research summary read simply: "My area of interest focuses on the streamlining of the mathematical argument." He was not interested in machines. He was interested in how humans think, and in building systems of thought that were honest, clear, and beautiful. That concern for beauty, for the elegance of an argument, for the moral weight of clarity, did not come from computer science. It came from a gymnasium education steeped in classical languages and literature, from a young man who once dreamed of diplomacy, from a mind that never stopped treating writing as an act of care. +++ Alan Turing studied mathematics at King's College, Cambridge, beginning in 1931. His formal education was entirely in mathematics and mathematical logic. At school, his teachers noted the contrast between his absorbed interest in science and mathematics and his indifference to Latin and English subjects. He was not, by any standard account, a humanities student. But Turing's intellectual life was far wider than his formal education suggests. King's College in the 1930s was not merely a mathematics department. It was a place defined by its progressive intellectual culture, centered on figures like the economist John Maynard Keynes. Turing drew deeply from the work of Bertrand Russell, whose mathematical philosophy sits at the intersection of logic, language, and epistemology. Russell was not simply a mathematician. He was a philosopher who used mathematics to ask questions about the nature of knowledge, truth, and meaning. Turing absorbed that orientation. When Turing published his most famous non-technical work, "Computing Machinery and Intelligence," he did not publish it in a mathematics journal or an engineering journal. He published it in Mind, a quarterly review of psychology and philosophy. The paper, which introduced what we now call the Turing test, is fundamentally a philosophical argument about the nature of thought, consciousness, and what it means to say a machine can "think." It engages with objections from theology, from mathematics, from Lady Lovelace's own writings, and from the philosophy of mind. Turing was not building a machine in that paper. He was asking what it means to be human, and whether the boundary between human thought and machine process is as firm as one might assume. Turing's lasting fascination with problems of mind and matter was present throughout his life. He thought about consciousness, about biology, about morphogenesis; the process by which organisms develop their shapes. In the final years of his life, he was working on "The Chemical Basis of Morphogenesis," a paper that founded modern nonlinear dynamical theory. He moved fluidly between mathematics, philosophy, biology, and what we would now call cognitive science. He did not respect the boundaries between disciplines because the questions he cared about did not inherently respect them either. His schoolmasters wanted him to have a "well-balanced education." He resisted. But the philosophical questions found him anyway, and they produced some of the most consequential thinking in the history of human knowledge. +++ Grace Hopper arrived at Vassar College in 1924 to study mathematics and physics. Vassar was, and remains, a liberal arts college, and Hopper's education there was not confined to her concentrations. She took courses in economics, public finance, botany, physiology, geology, and electronics. She graduated Phi Beta Kappa in 1928 and went on to earn a master's degree and a PhD in mathematics from Yale. She returned to Vassar to teach, and her colleagues described her as both a great teacher and a sharp wit at the luncheon table. During the war, she joined the Navy and was assigned to work on the Harvard Mark I, one of the earliest electromechanical computers. After the war, she turned down a full professorship at Vassar to keep working with computers. It was in this second career that her humanities sensibility became most visible. Hopper's defining insight was not mathematical. It was humanistic. She realized that programming in mathematical symbols and machine code was a barrier that excluded the vast majority of people from using computers. She believed that computers should speak to people in English, not in the language of mathematics. When she proposed building a compiler that could translate English-language instructions into machine code, she was told flatly that she could not do it because computers did not understand English. She did it anyway. The result was FLOW-MATIC, the first programming language to use English words, and later COBOL, which became the dominant language of business computing for decades. Hopper said it plainly: "Manipulating symbols was fine for mathematicians but it was no good for data processors who were not symbol manipulators. Very few people are really symbol manipulators. If they are, they become professional mathematicians, not data processors. It is much easier for most people to write an English statement than it is to use symbols." That reasoning is not technical. It is an observation about human beings, about how people actually think and communicate, about the gap between expert knowledge and ordinary capability. It is the kind of observation that comes from someone who studied broadly, who taught across disciplines, who invented a mythical country to bring a dry mechanical drawing class to life for her students. Hopper understood that the value of a computer depended not on what it could compute but on who could use it. That is a humanities insight dressed in technical clothing. When she accepted the National Medal of Technology, Hopper said that the accomplishment she was most proud of was all the young people she had trained over the years; that it was more important than writing the first compiler. She understood that technology lives and dies by its relationship to people. +++ Dennis Ritchie grew up in Summit, New Jersey, the son of a Bell Labs scientist. He attended Harvard, where he studied physics as an undergraduate and applied mathematics as a graduate student. His education was entirely technical. He completed a draft of his PhD thesis on subrecursive hierarchies of functions but never formally received the degree. He described his own trajectory with characteristic dry humor: "My undergraduate experience convinced me that I was not smart enough to be a physicist, and that computers were quite neat. My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones." Ritchie went to Bell Labs in 1967 and stayed for forty years. There he created the C programming language and, with Ken Thompson, the Unix operating system. These two creations are arguably the most influential artifacts in the history of software. C is the ancestor of nearly every widely used programming language today. Unix and its descendants power the majority of servers, phones, and embedded systems on Earth. The conceptual DNA of modern computing flows directly through Ritchie's work. Ritchie had no formal humanities training, but his colleagues paint a picture of someone whose intellectual life extended far beyond programming. He was widely read and was interested in classical music. He was knowledgeable on a broad range of topics. One colleague recalled being at the San Diego Zoo with Ritchie and discovering that he knew the details of seemingly every animal they encountered. He was described universally as modest, kind, and generous, always giving credit to others while downplaying his own contributions. What is most telling about Ritchie's humanities sensibility is his writing. The book he co-authored with Brian Kernighan, The C Programming Language, is still considered one of the finest technical books ever written, more than four decades after its publication. It is precise, economical, and elegant. Every sentence does work. There is no bloat, no unnecessary complexity, no showing off. The book teaches not just C, but a way of thinking about programming that values clarity and simplicity above all else. That is not a technical achievement. That is a literary one. Ritchie was also shaped by Bell Labs itself, which in its golden era was one of the most extraordinary intellectual environments ever assembled. Physicists, mathematicians, linguists, and engineers worked side by side. The culture valued breadth, curiosity, and the freedom to pursue ideas across disciplinary boundaries. Ritchie did not study humanities in school, but he spent his career in a place that embodied the humanities ideal of cross-pollination between fields. Dennis Ritchie died in October 2011, the same week as Steve Jobs. The world mourned Jobs loudly. Ritchie's death was quieter. One commentator noted that Ritchie's work played a key role in spawning the technological revolution of the last forty years, including technology on which Apple built its fortune. The tools that made the modern world possible were built by a quietly brilliant man who read widely, wrote beautifully, and never sought the spotlight. +++ Brian Kernighan was born in Toronto and studied engineering physics at the University of Toronto, then earned his PhD in electrical engineering from Princeton. Like Ritchie, his education was purely technical. He spent thirty years at Bell Labs, where he contributed to the development of Unix, co-authored The C Programming Language, and created the AWK programming language. But something interesting happened when Kernighan moved from Bell Labs to Princeton's Computer Science department in 2000. He began to gravitate, with increasing purpose, toward the humanities. He started teaching a course called "Computers in Our World," designed not for computer science majors but for students studying literature, politics, history, and other humanities disciplines. He co-taught a course with a professor from the French and Italian department and he co-taught another with a professor from the English department on "data in the humanities." He became involved with Princeton's Center for Digital Humanities. He ran independent work seminars where computer science juniors explored data from the humanities, looking at properties of books, history, social interactions, and patterns in human behavior. A New York Times profile of him was titled, "To the Liberal Arts, He Adds Computer Science." This is a man who spent three decades building some of the most important systems-level software ever written and then spent the next two decades trying to connect that work back to the humanities. He has said in interviews that Princeton stresses breadth over depth, and that his job as an advisor is to get students to sample the amazing collection of different things that humankind does. He encourages computer science students to explore broadly because he believes exposure to those other disciplines is part of what makes a complete thinker. Kernighan did not arrive at computing through the humanities. But his career arc suggests that he recognized something was missing, that technical excellence alone was not enough, and he spent the second half of his professional life trying to build the bridge he never had as a student. That search is itself a kind of evidence. When one of the most accomplished systems programmers in history spends his later years teaching literature majors about computers and computer scientists about poetry, it tells you something about what the field needs and does not have. +++ Richard Stallman graduated from Harvard in 1974 with a bachelor's degree in physics, magna cum laude. He had been programming since high school and had been working at MIT's Artificial Intelligence Laboratory since his freshman year. His formal education was entirely in the sciences. He chose physics over mathematics for a pragmatic reason: the physics degree did not require a thesis. Stallman's contribution to computing is not primarily technical, though he is a gifted programmer who created GNU Emacs, the GNU Compiler Collection, and the GNU Debugger. His lasting contribution is philosophical. He founded the Free Software Foundation and articulated a moral framework for software that treats user freedom as a fundamental ethical principle, not a business strategy. He argues that the ability to study, modify, and share software is a human right, and that proprietary software is antisocial and unethical. He has framed control over software as a civil liberties issue, speaking and writing about it for decades with the intensity of a moral philosopher. Stallman is an interesting case for this essay because his thinking is deeply humanistic while his training is not. He arrived at ethical philosophy through personal conviction and lived experience, not through formal study. The free software movement is, at its core, a philosophical argument about freedom, autonomy, and the relationship between creators and users. It draws on traditions of thought that belong to ethics and political philosophy, whether Stallman studied them formally or not. But there is something instructive in the gap between the depth of Stallman's ethical insight and the way he has communicated it over the years. His positions are often correct and almost always principled. His delivery has frequently been abrasive, uncompromising, and alienating to potential allies. Eric Raymond, one of the founders of the adjacent open-source movement, argued that Stallman's moral arguments, rather than pragmatic ones, alienate potential allies and hurt the end goal. Whether one agrees with Raymond or not, the observation points to something worth considering: having the right ethical instincts is not the same as having the skill to communicate them in ways that move people. The humanities do not just teach you what to care about. They teach you how to bring others along. +++ There is a pattern in these stories, and it is not subtle. The earliest figures in computing, Lovelace, Turing, Hoare, and Dijkstra, were either formally educated in the humanities or deeply immersed in philosophical thinking as a central part of their intellectual lives. Lovelace called herself a poetical scientist. Hoare studied Latin, Greek, and philosophy before he ever wrote a line of code. Dijkstra studied classical languages and wanted to be a diplomat before he became a programmer. Turing published in philosophy journals and spent his life asking questions about consciousness and the nature of thought. The next generation, Hopper and Ritchie, came through educational environments that still valued breadth. Hopper's Vassar education exposed her to economics, botany, physiology, and geology alongside mathematics. Ritchie's Harvard and Bell Labs years immersed him in a culture where intellectual curiosity across disciplines was the norm, not the exception. By the time we reach Kernighan and Stallman, the humanities influence has thinned to almost nothing in their formal education. Kernighan studied engineering physics. Stallman studied physics. Both are brilliant. Both are consequential. But Kernighan has spent the second half of his career actively seeking out the humanities connection he never had, and Stallman's philosophical contributions, while profound, have sometimes suffered from a lack of the communicative skill that humanities training cultivates. And after them? The pattern does not continue. It ends. Look at the technology leaders and influential engineers of the last twenty years. Look at the people building the platforms, the social networks, the AI systems, the attention economies. How many of them studied philosophy? How many of them read classical literature or engaged seriously with ethics or political theory or the history of human thought? How many of them could write an essay in the style of Dijkstra, or articulate a vision of human-centered computing like Hopper, or reason about consciousness and moral responsibility like Turing? The answer is vanishingly few. And we can see the results. +++ This is not an abstract concern. The absence of humanities thinking in modern technology has consequences that are felt by real people in their daily lives. Social media platforms were designed by engineers who optimized for engagement metrics without understanding, or perhaps without caring, what the deliberate manufacture of outrage and addiction does to a human mind. Attention economies were built by people who studied computer science and business but never studied propaganda, rhetoric, or the psychology of manipulation. Algorithms that determine what billions of people see, read, and believe every day were written by teams that included no one trained in ethics, epistemology, or the philosophy of information. The result is a generation of technology that is technically sophisticated and humanistically bankrupt. We have systems that can predict what you want to buy but cannot be bothered to consider whether showing a teenager an endless feed of curated suffering is a good idea. We have AI models trained on the full breadth of human knowledge being deployed by people who have never seriously asked what responsibility comes with that power. We have apps that children are required to use for school that crash, load slowly, and harvest data, built by engineers who never stopped to think about the family on a slow internet connection whose only concern is whether their kid got to school safely. Alan Turing was asking whether machines could think in 1950. He published that question in a philosophy journal because he understood it was a philosophical question, not a technical one. Seventy-five years later, we are building machines that increasingly influence how humans think, and the people building them have largely abandoned the disciplines that would help them understand the gravity of what they are doing. Lovelace saw that computing could touch music, language, and art. She saw that because she lived between poetry and mathematics and refused to choose. Hopper saw that programming had to speak human language because she understood that most people are not symbol manipulators. Dijkstra wrote essays instead of technical reports because he believed clarity of expression was a moral obligation. These were not decorative sensibilities. They were the insights that shaped the field itself. When you strip the humanities out of the people who build technology, you do not get more efficient engineering. You get engineering that has lost its sense of purpose, its awareness of consequence, and its ability to see the people on the other side of the screen. +++ None of this is meant to suggest that every programmer needs a philosophy degree or that studying Latin will make you better at writing Go. The point is not about credentials. It is about disposition. The people who built the foundations of computing shared something that went beyond technical brilliance. They had a concern for clarity that extended past code into how they communicated with other human beings. They had a sense that their work existed in a larger context, that the systems they built would be used by people whose lives would be shaped by those systems. They asked not just "does it work" but "is it good," and they understood that "good" meant something more than functional correctness. That disposition does not require a degree. But it does require more than casual interest. Reading a philosophy book on a weekend is a hobby. Spending serious, sustained time with literature, with history, with ethics, with the long conversation that humanity has been having with itself for thousands of years about what it means to live well and treat each other justly, that is something different. It changes how you see problems. It changes what questions you think to ask. It changes what you are willing to ship and what you refuse to. Higher education bears some responsibility for the current state of things. Computer science programs at most universities require little to no engagement with the humanities. Students can graduate with the technical skills to build systems that affect millions of lives without ever having been asked to seriously consider what that responsibility means. But blaming institutions only goes so far. The choice to engage with the humanities is ultimately a personal one, and it is available to anyone with a library card, an internet connection, and the willingness to sit with difficult, unfamiliar ideas long enough to let them change how you think. +++ This essay has asked you to spend some time with the stories of people who built the world you work in every day. It has asked you to slow down, to read about their lives, to notice that the things you admire most about their work, the elegance, the clarity, the concern for people, the refusal to accept unnecessary complexity, came not from their technical training but from something deeper and older. If you are a technically oriented person and you have made it this far, you have already demonstrated something. You have invested time in a piece of writing that does not teach you a new framework or show you a clever optimization. You have sat with ideas that do not have immediate practical application. You have, for a few minutes, done the thing that this essay is asking you to consider doing more of. The founders of your field read philosophy and wrote essays and studied classical languages and asked questions about consciousness and beauty and the nature of human thought. They did not do these things because they had spare time or because someone made them. They did them because they understood, implicitly or explicitly, that building machines worthy of human trust requires understanding what it means to be human. That understanding is not going to come from another tutorial, another side project, or another Hacker News thread. It is going to come from the long, slow, sometimes difficult work of engaging with the humanities. Read philosophy. Read literature. Read history. Study how humans have thought about ethics, about power, about communication, about what it means to build something that lasts. Sit with those ideas long enough to let them reshape how you approach your own work. The tradition that produced Lovelace's poetical science and Hoare's classical mind and Dijkstra's handwritten essays and Hopper's insistence that computers must speak to people is not dead. But it is diminishing, generation by generation, as the field grows further from its roots. You have the opportunity to reverse that. Not by going back to school, necessarily, but by taking the humanities seriously enough to let them into your professional life, your design decisions, your code reviews, your conversations with the people who will use what you build. The machines we build reflect the minds that build them. If those minds are nourished only by technical knowledge, the machines will be technically competent and humanistically hollow. If those minds are broad, curious, and grounded in the long tradition of human thought, the machines will be something better. They will be worthy of the people who depend on them. The choice, as it has always been, is yours. 10th Person 2026-02-13T00:00:00+00:00 In World War Z, Israel survives the zombie apocalypse because of a simple rule: if nine intelligence officials agree on something, the tenth must assume they're all wrong and explore alternatives. Not to be difficult. Not to play devil's advocate. But because consensus is dangerous and groupthink kills. I've spent my career being that tenth person. The one questioning why we need Kubernetes for a service with three endpoints. The one asking if we really need to rewrite the whole thing in Rust. The one mapping out what happens when your "temporary workaround" becomes permanent infrastructure that nobody understands. People think I'm being difficult. I'm not. I'm being the 10th person. Consensus is a Red Flag</h2> When everyone in the room agrees, someone isn't thinking. They're following. They're deferring. They're nodding along because it's easier than asking the question that makes them look stupid. Let's use microservices. </blockquote> We should add GraphQL. </blockquote> This needs to be event-driven. </blockquote> Nobody asks why. Nobody maps the decision three moves ahead. Nobody considers what happens when the junior engineer who built this quits and we're left maintaining a distributed system that could've been a monolith with a cron job. The 10th person asks those questions. Not because they're smarter. Because they're wired differently. The Autism Advantage</h2> I'm autistic. That means I can't not see the decision tree. When you propose a solution, my brain immediately forks into every possible timeline: What if this scales? </blockquote> What if it doesn't? </blockquote> What happens when the database fills up? </blockquote> What happens when the cache gets stale? </blockquote> What happens when the person who wrote this leaves? </blockquote> What happens when we need to debug this at 3 AM? </blockquote> Most people see one path forward. I see thirteen. Most people are surprised by outcomes. I'm not. I've already lived them in my head before we wrote a single line of code. This isn't a superpower. It's fucking exhausting and I can't just turn it off. But it's also why I'm good at being the 10th person. I can't ignore the futures everyone else hasn't considered yet. Question Everything, Especially the Easy Stuff</h2> The hardest part of being the 10th person isn't questioning big decisions. It's questioning the small ones. The "obvious" ones. The ones where everyone assumes there's only one right answer. We'll just add a new service for that. </blockquote> We'll just add another dependency. </blockquote> We'll just patch it later. </blockquote> No. Stop. Why? Why do we need another service? </blockquote> Why can't the existing one handle this? </blockquote> Why are we optimizing for convenience over maintainability? </blockquote> Why are we assuming future-us will have more time than present-us? </blockquote> These aren't rhetorical questions. They're the 10th person protocol. Assume the consensus is wrong. Map the alternatives. Force the room to think instead of react. It's Not Contrarianism, It's Discipline</h2> Being the 10th person isn't about being contrarian for sport. It's not about saying "no" to everything. It's about disciplined skepticism. It's about recognizing that the path of least resistance is usually the path to technical debt, production outages, and systems nobody understands. When I question your design, I'm not attacking you. I'm stress-testing the decision. I'm forcing us to articulate why this is the right call instead of just the easiest one. If you can defend it, great. We move forward with confidence. If you can't, we just saved ourselves months of regret. Don't Waste My Time If You Just Want Agreement</h2> Here's what pisses me off: teams that bring me in, ask for my input, and then get upset when I don't just nod along. They don't want the 10th person. They want a rubber stamp. If you already decided on the solution and you're just looking for validation, don't waste my time. Use some fucking LLM. It'll tell you your idea is great. It'll suggest some optimizations. It'll never ask "why are we doing this at all?" That's not what I'm here for. When you pull me into a meeting, a design review, or a code review you're asking me to map the decision tree. To consider the futures you haven't thought about. To question the assumptions you're making. That's the job. That's what my brain does whether I want it to or not. But if you've already made up your mind? If you're just checking a box so you can say you "got feedback"? Then you're wasting both our time. Mine, because I'm going to give you real feedback anyway. Yours, because you're going to ignore it and then act surprised six months later when everything I predicted comes true. So here's the deal: if you want agreement, go find it somewhere else. There are plenty of people who will tell you what you want to hear. There are infinite blog posts that will validate your choices. There are LLMs that will generate enthusiastic affirmations on demand. But if you want the 10th person and you actually want someone to stress-test your thinking then bring me in. But don't get mad when I do the job. And here's the brutal trueth... If this happens again and again I will do what the 10th person should be doing, but I won't tell anyone. I will prepare for the invetiable future to protect my own mental health when there comes a time when the brilliant, clever, or lazy decision crashes at midnight. The Room Needs a 10th Person</h2> Most teams don't have one. They have nine people who all think the same way, went to the same bootcamps, read the same blog posts, and worship the same thought leaders. They add complexity because everyone else is doing it. They chase trends because nobody wants to be the one who didn't adopt the hot new framework. That's how you end up with a "simple CRUD app" running on Kubernetes with a service mesh, an event bus, three databases, and a deployment pipeline that takes 40 minutes. Someone needed to be the 10th person. Someone needed to ask "why" before it was too late. How to Be the 10th Person</h2> You don't need to be autistic. You don't need to see thirteen futures. You just need discipline: Assume consensus is wrong. If nine people agree, somebody isn't thinking.</li> Map the decision tree. Don't just ask "will this work?" Ask "what happens when it doesn't?"</li> Question the small stuff. Big decisions get scrutiny. Small ones compound into disasters.</li> Force articulation. Make people explain their reasoning out loud. If they can't, the decision isn't ready.</li> Accept the discomfort. Being the 10th person is lonely. Do it anyway.</li> </ol> In Closing</h2> Tech doesn't need more consensus. It needs more 10th people. People who question the defaults. People who map the futures everyone else ignores. People who have the discipline to say "wait, why are we doing this?" even when it's easier to just nod along. I've been that person my whole career. It's made me difficult to work with sometimes. It's also made me right more often than I'm wrong. So be difficult. Be the 10th person. Because if everyone agrees, someone isn't thinking. Also, Happy Friday the 13th! 30 Years of Programming at 44 Years Old 2026-01-13T00:00:00+00:00 In 1995, I built my first website. It was a Metallica fan page. Black background, red text, animated GIFs of pixelated flames, a MIDI file that autoplayed "Enter Sandman" whether you wanted it to or not. I thought it was the coolest thing I had ever made and I was only 14. I had no idea what I was doing. I just knew that if I typed the right words into Notepad and saved the file with .html</code> at the end, something would appear in Netscape Navigator that didn't exist before I made it. That feeling of conjuring something from nothing hooked me immediately. By 1998, I was one of the kids in computer shop tasked with redesigning our high school's website</a>. It was a technical high school where kids learned trades like HVAC, automotive, masonry, IT, etc. Our IT shop teachers supervised us as we figured it out. Same tools I'd been using at home: Notepad, HTML. No frameworks, no build steps, no dependencies. Just text files that turned into something the whole school could see and use. There was something pure about that. We were students building something real, supervised by teachers who understood the work. No pitch decks or growth metrics. They just wanted us make it work, make it useful, and learn something in the process. Growing and Learning</h2> The next 15 years were a blur of growth. I learned PHP, then Java, then Ruby, then ColdFusion, then Node.js. I worked at Harvard building school-wide course evaluation and inventory management systems for research labs. I built tournament systems for Riot Games, streaming platforms for media companies, backend services for mobile games you've probably played. I got good at the craft. I learned how to build systems that didn't fall over, how to write code that other people could read, how to lead teams without being an asshole about it. Then in 2016, I found Go. Something clicked that hadn't clicked in years. Here was a language that felt like the tools I started with since it was simple, direct, and with no magic, but capable of building the distributed systems the modern internet demanded. No runtime to babysit and no framework churn. It was just a compiler, a standard library that actually had what you needed, and code that did exactly what it looked like it did. I went all in. Compiled languages. Concurrent systems. I started caring deeply about performance, about memory, about what was actually happening when my code ran. I read RFCs for fun. I traced packets through the kernel. I wanted to understand the machine, understand the network, not just ship features on top of abstractions I couldn't explain. For a while, it felt like the joy was back that I didn't know I lost. Programming with purpose. Building things that worked because I understood why they worked. I climbed the ladder. Senior engineer then to Staff engineer. I worked on CDNs pushing packets at the edge. I wrote eBPF programs to measure network latency at the kernel level. I helped build the infrastructure that routes traffic for millions of users. The problems got harder and more interesting. The compensation got better. By any reasonable measure, I had made it. Tapped Out</h2> And then I looked around. The industry I had grown up in that promised to connect people, to democratize information, to make the world smaller and more accessible had become something else entirely. The fun was and the discovery was gone. What remained was a ruthless machine optimized for extraction. I watched companies I respected pivot from building useful things to chasing metrics that looked good in pitch decks. I sat in meetings where the question was never "does this help anyone?" but "how do we increase engagement?" I saw smart and talented engineers burn themselves out building features designed to manipulate rather than serve. The word "hustle"</a> got thrown around like a badge of honor instead of the warning sign it actually is. The VCs wanted growth at any cost and the founders wanted exits. The middle managers wanted to hit their OKRs. And the users? They became the product. Their attention, their data, and their habits were all commodified and sold to the highest bidder. I burned out. Multiple times. Not the cute kind of burnout where you take a long weekend and feel better. The kind where you stop eating. The kind where you lose weight you can't afford to lose. The kind where the barbell sits untouched in the garage for months because you can't find the will to pick it up, even though lifting was one of the few things that kept you sane. The kind where you're sitting alone wondering how you got here and whether any of it was worth it. And through all of it, I was raising my son. He's autistic, and he's brilliant, and he's growing up in a world that this industry helped create. A world designed to hijack attention, to exploit dopamine loops, to turn human connection into engagement metrics. Every dark pattern I helped normalize, every addictive feature I stayed silent about, every compromise I made to hit a deadline. I think about what that world means for him. For all the kids who deserve better than to be optimized against. I worked at companies during this era that were doing genuinely interesting technical work. Layer 1 networking. Real-time packet routing. Security research. The engineering was excellent. But even in those places, I could feel the pressure of the constant pull toward whatever would juice the numbers, whatever would impress the board, whatever would get us closer to the next funding round or acquisition. This wasn't what I signed up for. The kid in 1995 who made a Metallica fan page wasn't dreaming of surveillance capitalism. The teenager in 1998 who built his high school's website wasn't imagining a future where every click would be tracked, analyzed, and monetized. I got into this because I loved making things. Somewhere along the way, the industry decided that making things wasn't enough anymore and instead you had to scale them, monetize them, disrupt them, exit them. Fuck that. End Game</h2> I'm 44 today</a>. If I'm lucky, I have maybe 20 more years of writing code in me. Probably less at the pace this industry moves. That's not a lot of time, but it's enough to be deliberate about how I spend it. Here's what I've realized... The skills I've accumulated over 30 years— the system design, the networking knowledge, the understanding of how software actually works at a low level—those skills have value beyond making rich people richer. They can be used to build things that matter. Things that respect the people who use them. Things that don't treat privacy as an obstacle or users as resources to be harvested. I'm thinking about co-ops and nonprofits and community organizations that need software but can't afford to have their data sold to advertisers. I'm thinking about tools that are secure by default, that don't phone home, that do one thing well and then get out of the way. I'm thinking about the kind of software I would have wanted to use when I was 14. The software that felt like it was made by someone who gave a damn. The irony isn't lost on me. I spent years building expertise in distributed systems and cloud infrastructure, and now I want to use that expertise to help people who are actively trying to avoid the cloud. I learned how to scale services to millions of users, and now I'm more interested in software that works for thousands. I got really good at the game, and now I want to play a different one. Maybe that's what 30 years buys you: the clarity to know what you actually want. I don't have all the answers. I'm still figuring out what this next chapter looks like. But I know it involves simpler tools, smaller communities, and software that exists to serve rather than extract. I know it involves working with people who share those values. The Metallica fan page is long gone and so is the high school website. But the feeling I had when I made them, that sense of wonder at creating something from nothing, that belief that I could build things that mattered, that's still there. It just got buried under two decades of sprints and standups and growth metrics. The next 10 to 20 years will be about protectng my own peace and working on things that make me proud of myself. Read the Fucking Manual 2025-11-19T00:00:00+00:00 There's a particular kind of engineer I've been noticing more and more lately. They show up in Slack channels with half-formed questions. They post screenshots of error messages on Twitter asking "anyone know what this means?" They copy-paste compiler errors into ChatGPT and treat whatever hallucination comes back as gospel. They interrupt their teammates with questions that could be answered in thirty seconds of reading documentation. This isn't engineering. This is learned helplessness dressed up in collaborative clothing. The Death of Self-Sufficiency</h2> Engineering used to mean something. It meant you knew how to research. You could read a language specification and understand what the compiler was doing. You could trace through library source code to figure out why something wasn't working. You read academic papers, man pages, and RFCs. You debugged your own problems before asking for help. Somewhere along the way, we convinced ourselves that this was inefficient. Why spend thirty minutes reading documentation when you could ask someone and get an answer in five? Why dig through source code when you could prompt an AI and get code back immediately? Why think for yourself when the collective intelligence of social media is just a post away? Here's what we've traded for that convenience: actual engineering skill. The Problem with Modern "Research"</h2> Stack Overflow is dead. I'm not being dramatic. The quality has been declining for years, and lately it's gotten worse. The good answers are buried under years of outdated advice, version-specific solutions that no longer apply, and increasingly, AI-generated nonsense that looks helpful but doesn't actually work. The experts who used to answer questions there have moved on because why would they waste time competing with bots? AI will confidently lie to you. ChatGPT and its cousins will generate API calls that don't exist. They'll suggest libraries that were deprecated years ago. They'll write code that compiles but does completely the wrong thing. And they'll do it all with the confidence of a junior developer on their first day, which is to say, absolute certainty masking complete ignorance. Social media is full of grifters. Post a technical question on Twitter and watch the replies roll in. Half will be people trying to sell you their course, their book, their SaaS product. The other half will be people who didn't read your question carefully and are answering something completely different. The actual helpful responses? Buried somewhere in the noise. Slack is a nerd snipe waiting to happen. Every time you drop a question into a channel, you're potentially derailing someone else's deep work. They see the notification. They context switch. They try to help because they're good people. And now you've cost the team thirty minutes of productive time across three people instead of spending ten minutes reading the docs yourself. What Engineering Actually Is</h2> Engineering is problem-solving through research and experimentation. It's: Reading the fucking language specification when you don't understand how something works</li> Tracing through library source code to see what it's actually doing</li> Writing small test programs to verify your understanding</li> Reading error messages carefully and understanding what they're telling you</li> Consulting API documentation as your first source of truth</li> Looking at academic papers when you need to understand the theory</li> Checking the release notes when something breaks after an upgrade</li> </ul> It's doing the work. The real work. The thinking work. When you skip this step and go straight to asking someone else, you're not learning. You're getting a fish instead of learning to fish. And unlike the proverb, in engineering, you need to catch new fish every single day. The Collaboration Fallacy</h2> Someone is going to read this and say "but collaboration is important!" Sure. But collaboration isn't what's happening when you post "how do I parse JSON in Go?" in a Slack channel. Real collaboration happens in: Code reviews where everyone has done their homework</li> Design discussions where people have researched the problem space</li> Standups where blockers are identified and documented</li> Office hours where dedicated time is set aside for helping others</li> Pair programming sessions where knowledge transfer is the explicit goal</li> </ul> What's not collaboration: Interrupting someone's flow state with a question you could answer yourself</li> Expecting teammates to debug your code for you</li> Using your colleagues as a replacement for documentation</li> Treating your team as a just-in-time search engine</li> </ul> Respect for other people's time isn't optional. It's fundamental to being a good teammate. And the first way to show that respect is to try figuring things out yourself before you ask. The Skills You're Not Building</h2> Every time you take the shortcut, you're weakening your engineering muscles. You're not learning: How to read technical documentation effectively</li> How to trace through unfamiliar codebases</li> How to form and test hypotheses about what's wrong</li> How to narrow down the root cause of a problem</li> How to verify your understanding is correct</li> </ul> These skills compound. The engineer who has spent years reading source code can scan a new codebase and understand it in hours. The one who's always asked others for answers gets lost immediately. The engineer who reads specifications knows not just what works, but why it works and when it breaks. The one who copies from Stack Overflow has a collection of magic incantations they don't understand. The engineer who's debugged hundreds of issues can look at a stack trace and immediately narrow down the problem. The one who's always been handed solutions is helpless when something goes wrong. When Asking Is Appropriate</h2> I'm not saying never ask for help. I'm saying exhaust your options first. Ask when: You've read the docs and still don't understand</li> You've traced through the code and the behavior doesn't match what you expected</li> You've spent a reasonable amount of time (30-60 minutes) trying to figure it out</li> You have a specific question about a specific thing, not a vague "how do I...?"</li> You can show what you've tried and where you're stuck</li> </ul> Don't ask when: You haven't looked at the documentation yet</li> You got an error message and didn't bother reading it</li> You want someone to write code for you</li> You're being lazy and hoping someone else will do the work</li> You're interrupting people's flow state for something non-urgent</li> </ul> Sources of Truth</h2> When you do research, use actual sources of truth: Language specifications - Want to know how something works? Read the spec. Not a blog post about the spec. Not someone's interpretation on social media. The actual specification. API documentation - Official docs from the library maintainers. Not random tutorials. Not AI summaries. The actual documentation. Source code - When the docs aren't clear, read the code. It's the ultimate source of truth about what something actually does. Man pages - For Unix tools, the man page is the authority. Not a blog post from 2015. RFCs and academic papers - For protocols and algorithms, go to the source. The people who invented the thing wrote down how it works. Release notes and changelogs - When something breaks after an upgrade, start here. Don't ask why something changed. Read what changed. Building the Skill</h2> If you've been taking shortcuts, it's going to feel slow and frustrating to start doing the work. Good. That friction is where learning happens. Start small: Next time you get a compiler error, read it carefully before asking</li> When you need to use a library function, read its documentation first</li> Set a timer for 30 minutes and try to solve the problem yourself</li> Keep notes on what you learn so you don't have to learn it again</li> Build a habit of checking the source code when docs are unclear</li> </ul> Over time, you'll get faster. You'll learn where to look. You'll develop intuition for what kinds of problems have certain solutions. You'll become self-sufficient in a way that makes you more valuable and less dependent. Respect and Discipline</h2> This comes back to the themes I keep hitting in my writing: discipline and respect for others. Discipline means doing the work even when it's easier not to. It means reading the manual instead of asking. It means thinking through the problem instead of outsourcing your thinking to someone else. Respect means not wasting other people's time. It means not interrupting their flow state with questions you could answer yourself. It means coming to code reviews prepared. It means treating collaboration as something precious, not something to be squandered on laziness. If you want to be a senior engineer, this is part of it. Not just writing good code, but being someone who can solve their own problems. Being someone who does the research. Being someone who reads the fucking manual. Do Better</h2> The next time you're about to fire off a question in Slack, or paste an error into ChatGPT, or post "anyone know how to...?" on social media, stop. Open the documentation. Read the error message. Look at the source code. Think about the problem. Try something. Fail. Learn. Try again. This is engineering. This is the job. And if you're not willing to do it, you're not engineering. You're just asking other people to engineer for you. Read the fucking manual. Your future self and your teammates will thank you for it. If you want to challenge yourself, cut the internet connection from your machine for an hour and see if you can without direct and immediate access to Slack and social media and use the local instance of your library documentation and in-memory unit tests to figure shit out. How I Write HTTP Servers 2025-10-31T00:00:00+00:00 I am surprised I haven't written this sooner, especially since I have written about How I Write HTTP Clients</a>. It was inevitable this post was going to be written. With that said, I want this post to follow the same format so a lot of this will read very similar since I copied a lot of the language from it and just adapted it for HTTP servers. I have written a lot of HTTP server that serve APIs with different types of content over the years and there have been some patterns that have emerged and so I thought I would share them in hopes they help others. The major concepts I want to highlight are: Composing Server Dependencies and Options</li> Composing Middleware</li> Data Encoding/Decoding/Validation</li> Testing Handlers</li> </ul> To illustrate these concepts I am going to write a REST API with the following key features: Support JSON / XML</li> Authorization Tokens</li> Stores data in a database</li> </ul> Write Handlers First</h2> Most of you might think to start writing the main HTTP server first, which makes a lot of sense, but I like to focus on the micro and write my individual handlers first. This allows me to discover dependencies as they come and keeps me focused on small bits of single-purpose and testable logic first. I also like to start with the routes that create data since we need data to exist to read it and delete it. func CreateArticle(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... }) }</code></pre> The CreateArticle()</code> is a simple function that takes in its dependencies as arguments and returns a http.Handler</code> which we can mount to a route. This particular handler requires a Logger</code> and a DataStore</code> to do its work. By keeping these as interfaces we can pass in any implementation of them we want. For now lets complete the rest of the handlers for working with articles. func CreateArticle(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... }) } func DeleteArticle(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... }) } func ListArticles(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... }) } func GetArticle(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... }) } func GetArticleImage(logger Logger, bs BlobStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... }) }</code></pre> Looking over the dependencies for all of these handlers we can can see we need a Logger</code>, DataStore</code>, and a BlobStore</code>. Interface Implementations</h2> Since we discovered the dependenices we need for our handlers we can rough out what those would be. The important concept here is that it doesn't matter how each of them are implemented since we are only concerned with the handlers themselves. For illustrative purposes we could have the following interfaces defined as: type Logger interface { Log(lvl Level, msg string, kvpairs ...string) } type DataStore interface { SaveArticle(ctx context.Context, article *Article) error QueryArticles(ctx context.Context, filterby string) ([]Articles, error) FindArticle(ctx context.Context, id int) (*Article, error) DeleteArticle(ctx context.Context, id int) error } type BlobStore interface { ReadBlob(ctx context.Context, path string) (*Blob, error) WriteBlob(ctx context.Context, path string, r io.Reader) error }</code></pre> Each of these could have a few implementations and in most scenarios they would have only one, especially when the server is running in production. However, there are times where they might need to change and/or its impossible to test these handlers with a concrete implementation of something that requires network access to a 3rd party system. Logger</code> could be implemented with log/slog</code>, zap.Logger</code>, etc.</li> DataStore</code> could be PostgreSQL with pgx</code> or as simple as database/sql</code>.</li> BlobStore</code> could be the local filesystem, AWS S3, or even scp</code> if you're feeling spicy</li> </ul> JSON / XML Support</h2> APIs should leverage the Content-Type</code> and Accept</code> HTTP headers to negotiate what encoding format should be used during the lifecycle of a request and response. Let's just focus on the CreateArticle()</code> handler since the rest will follow the same idea. func CreateArticle(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { var req ReqPayload var res ResPayload switch r.Header.Get("Content-Type") { case "application/json": // ... case "application/xml" // ... } article := Article{ Title: req.Title, Contents: req.Contents, } err := ds.CreateArticle(r.Context(), &article) res = ResPayload{ ID: article.ID, CreatedAt: time.Now(), } switch r.Header.Get("Accept") { case "application/json": // ... case "application/xml" // ... } }) }</code></pre> This would be the ideal setup for each. Set up the request and response structs</li> Decode the request depending on the Content-Type</code> header</li> Do the work of the handler and build the response</li> Encode the response depending on the Accept</code> header</li> </ol> This can get very repetative for every route so, fortuately, we can leverage some generics to make this a bit easier on ourselves. func decode[T any](r *http.Request) (T, error) { var req T switch r.Header.Get("Content-Type") { case "application/json": if err := json.NewDecoder(r.Body).Decode(&req); err != nil { return nil, err } case "application/xml" if err := xml.NewDecoder(r.Body).Decode(&req); err != nil { return nil, err } } return req, nil } func encode[T any](w http.ResponseWriter, r *http.Request, status int, res T) error { mimeType := r.Header.Get("Accept") w.Header().Set("Content-Type", mimeType) w.WriteHeader(status) switch mimeType { case "application/json": if err := json.NewEncoder(w).Encode(v); err != nil { return err } case "application/xml": if err := xml.NewEncoder(w).Encode(v); err != nil { return err } } return nil }</code></pre> Now that we have some nice encoding/decoding functions we can reuse these in our handlers and the proper encoding format will be used based on the headers in the http.Request</code>. func CreateArticle(logger Logger, ds DataStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { var res ResPayload req, err := decode[ReqPayload](r) article := Article{ Title: req.Title, Contents: req.Contents, } err := ds.CreateArticle(r.Context(), &article) res = ResPayload{ ID: article.ID, CreatedAt: time.Now(), } err := encode[ResPayload](w, r, http.StatusOK, res) }) }</code></pre> We can even take this a step further and introduce some nice request validation too. We can accomplish this by expanding the decode()</code> to not just use any type T</code>, but a certain Validator</code> and if the request is invalid decoding fails. type Validator interface { Valid(ctx context.Context) error } func decode[T Validator](r *http.Request) (T, error) { var req T switch r.Header.Get("Content-Type") { case "application/json": if err := json.NewDecoder(r.Body).Decode(&req); err != nil { return nil, err } case "application/xml" if err := xml.NewDecoder(r.Body).Decode(&req); err != nil { return nil, err } } if err := req.Valid(r.Context()); err != nil { return nil, err } return req, nil }</code></pre> We define a new Validator</code> interface and change our decode[T Validator]()</code> to work with that interface. Once decoding is completed we can call Valid()</code> on the struct and return any validation errors that occur back to our handler. We didn't even need to change out handler at all! Testing Handlers</h2> Now that we have a fully built handler we can begin to test it. I do want to stress that what we are testing should be the HTTP logic only. We should not be testing the behavior of DataStore.CreateArticle()</code> since that should be handled by its own tests of its own implementations. We are merely testing the request / response lifecycle to ensure out payloads uphold the contracts with HTTP clients. type mockLogger struct {} type mockDataStore struct {} func TestCreateArticle(t *testing.T) { handler := handlers.CreateArticle(&mockLogger{}, &mockDataStore{}) // Create the reqPayload := bytes.NewStringBuffer(`{"title":"Article Title","contents":"This is the contents of the article"}`) // The "/" path does not matter since we're calling the handler directly r := httptest.NewRequest(http.MethodPost, "/", reqPayload) r.Header.Set("Content-Type": "application/json") r.Header.Set("Accept": "application/json") w := httptest.NewRecorder() handler.ServeHTTP(w, r) if w.StatusCode != http.StatusOK { t.Fail("expected 200 response code") } if !strings.Contains(w.Body.String(), "id") { t.Fail("expected response to contain generated article id") } }</code></pre> Notice we didn't even need to start a real HTTP server and bind to a port to test this. We only needed to create an instance of the handler with its dependencies. We were able to provide our own in-memory implementation of them since they are just interfaces. Next, we created a request with httptest.NewRequest()</code> with the body of the request as some JSON. bytes.NewStringBuffer()</code> lets us make some JSON that implements the required io.ReadCloser</code>. Then we make a httptest.NewRecorder()</code> so our handler can write results to an in-memory buffer that simulates the client end of the connection. We can use parts of the record to test the status code and the contents of the response body to ensure our handler is doing what it is meant to do. Layers of Middleware</h2> At this point we have all of our handlers written and tested and everything is working as expected. All tests run in-memory and can also run in parallel. Next we need to layer some middleware on top of them to protect them with authorization tokens and get insight into them with some basic logging. We just keep following the rule of writing functions that return http.Handler</code>, but now they also accept a http.Handler</code> as their first argument. func LoggerMiddleware(next http.Handler, logger Logger) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { logger.Log(logger.INFO, "request", "method", r.Method, "path", r.RequestURI) next(w, r) }) } func AuthorizationMiddleware(next http.Handler, as AuthStore) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { authheader := r.Header.Get("Authorization") method, token, found := strings.Cut(authheader, " ") if !found { http.Error(w, http.StatusUnauthorized, "not authorized") return } if method != "Bearer" { http.Error(w, http.StatusBadRequest, "invalid authorization method") return } err := as.ValidToken(r.Context(), token) if err != nil { http.Error(w, http.StatusUnauthorized, "not authorized") return } next(w, r) }) }</code></pre> Both middlewares accept and return http.Handler</code> which will allows us to chain them together. It also allows us to test them in a similar fashion as our other handlers. Pulling it All Together</h2> We have handlers and middleware all ready to go now. Each are small discrete functions that can be reasoned about and tested by themselves. Now it is time to pull them all togther to make our HTTP server. I like to make a NewServer()</code> function that does all of this for me and, you guessed it, it will return a http.Handler</code>. Shocking, I know. func NewServer( logger Logger, ds DataStore, bs BlobStore, as AuthStore, ) http.Handler { mux := http.NewServeMux() mux.Handle("GET /articles", handlers.ListArticles(logger, ds)) mux.Handle("GET /articles/{id}", handlers.GetArticles(logger, ds)) mux.Handle("POST /articles", handlers.CreateArticle(logger, ds)) mux.Handle("DELETE /articles/{id}", handlers.DeleteArticle(logger, ds)) var handler http.Handler = mux handler = LoggerMiddleware(handler, logger) handler = AuthorizationMiddleware(handler, as) return handler }</code></pre> Now we have one http.Handler</code> to rule them all. We composed a http.ServeMux</code> which is also a http.Handler</code> so we can attach our handlers to routes. Then we layer on the middleware passing one into the next to build it up and finally returning the completed http.Handler</code>. The Real HTTP Server</h2> The last piece is attaching all of our work to a real HTTP server and binding it to a port with some additional options. This is where http.Server</code> gets used in main.go</code>. func main() { var logger logger.Logger = logger.NewNoOp() { switch config.logger { case "slog": logger = logger.NewSlog() case "zap": logger = logger.NewZap() } } var ds datastore.DataStore = datastore.NewSQLite() { switch config.datastore { case "postgresql": ds = datastore.NewPostgreSQL() case "in-memory": ds = datastore.NewInMemory() } } var bs bs.BlobStore = bs.NewLocalFileSystem() { switch config.bs { case "s3": bs = bs.NewS3() case "scp": bs = bs.NewSCP() } } var as as.AuthStore = as.NewSQLite() { switch config.as { case "redis": as = as.NewRedis() case "in-memory": as = as.NewInMemory() case "bypass": as = as.NewByPass() } } handler := handlers.NewServer(logger, ds, bs, as) srv := http.Server{ Addr: ":8080" Handler: handler, ReadTimeout: 5*time.Seconds, WriteTimeout: 20*time.Seconds, IdleTimeout: time.Minute, } idleConnsClosed := make(chan struct{}) go func() { sigint := make(chan os.Signal, 1) signal.Notify(sigint, os.Interrupt) <-sigint if err := srv.Shutdown(context.Background()); err != nil { logger.Log(logger.ERROR, "server shutdown", "error", err) } close(idleConnsClosed) }() if err := srv.ListenAndServe(); err != http.ErrServerClosed { logger.Log(logger.ERROR, "server stopped listening", "error", err) } <-idleConnsClosed }</code></pre> Based on some configurations we set up each of the Logger</code>, DataStore</code>, BlobStore</code>, and AuthStore</code>. Since NewServer()</code> only cares about interfaces we can compose many different permutations on dependencies our API can use and decouples the HTTP request / response lifecycle from the core business logic in each of the inferface implementations. Each layer of this API can also be tested thouroughly as independent units or as one service. func TestServer(t *testing.T) { tests := []struct { name string req *http.Request resCode int }{ { name: "sample request", req: httptest.NewRequest(http.MethodGet, "/articles", nil), resCode: http.StatusOk, }, // Many more requests to test } for _, test := range tests { t.Run(test.name, func(t *testing.T) { t.Parellel() logger := logger.NewNoOp() ds := logger.NewInMemory() bs := logger.NewLocalFileSystem() as := logger.NewBypass() handler := handlers.NewServer(logger, ds, bs, as) w := httptest.NewRecorder() handler.ServeHTTP(w, test.req) if w.StatusCode != test.resCode { t.Fail("failed to get expected status code") } }) } }</code></pre> We set up our test harness to test the entire server with no logging, in-memory data store, a local filesystem blob store, and we bypass auth all together. We also run each test within its own t.Run()</code> so we can then call t.Parallel()</code> indicating all subtests should run concurrently. This will drastically speed up our tests. Take notice that we set up everything inside each subtests so we do not share resources among them. By doing this we ensure test isolation and each subtests gets its own instance. This can be expanded to set up different states for each subtests as well if some requests require existing data in a database or file on disk too. Since this is all composable the options are pretty endless. server.Shutdown(ctx)</code></h2> This concludes this post on how I write my HTTP servers. They are not always the same every time, but these are the goals I try to strive for. You can even use these ideas when refactoring, adding features, or bug fixing. If you focus on trying to always return http.Handler</code> and pass in your dependencies to those handlers your life and you're team's lives will be much easier. Feedback is always welcome so feel free to send me a message or even a patch to my public inbox</a>! I Don't Care 2025-10-28T00:00:00+00:00 There's been a recurring thought I've been having as I've gotten older and I'm coming up on being in tech for 30 years. Granted, that would make me 14 when I started, but yes, I was that young when I realized I wanted to make this my career. As I've seen a lot change in those three decades, I've come to care less and less about most of the things mainstream tech blows the megaphone for on a daily basis. Most of this thought process has brought me peace and reduced my anxiety, and allows me to spend more time with things that actually matter to me. All of AI</h2> I don't care what good it does. I don't care what harm it does. If anyone brings it up from now on, I will most likely disassociate and ignore it. I honestly do not give a shit anymore. The hype cycle is exhausting. The think pieces are exhausting. The doom prophecies are exhausting. The utopian promises are exhausting. I've watched enough tech hype cycles to know how this plays out. Some useful tools will emerge. Most of it will be noise. The world will keep turning. I'm not interested in debating whether it's transformative or destructive. I'm not interested in your hot takes on consciousness or job displacement or copyright law. I've already spent my allocated lifetime bandwidth on this topic. It's zero now. Big Product Launches and "Innovation"</h2> It's all hype and ego-driven bullshit. We all see through your facade and what you actually want is to raise money, cash in, and dump whether the product succeeds or fails. I will not join you on your hype wagon. I do not care. I've seen too many world-changing platforms collapse. I've watched too many revolutionary products disappear overnight. I've sat through too many launch events where someone in a black turtleneck tells me they're reinventing something that didn't need reinventing. Most "innovation" is just normal iteration with a marketing budget attached. The truly innovative stuff rarely comes with a press release. It just quietly works and slowly gets adopted because it's actually useful. Everything else is theater. Language Wars</h2> I don't care which language is faster than the other. Which one is easier to read than the other. Which one is compiled or not. They all suck in their own way and they all are good in their own way. It is a subjective argument and I am not wasting my breath over it. Use what works for you. Use what works for your team. Use what solves the actual problem in front of you. Preferably use something boring and well-understood so the next person doesn't have to rewrite it in six months. I've written enough code in enough languages to know that the language is rarely the bottleneck. The bottleneck is usually the problem itself, or the team's understanding of it, or the architecture, or the requirements that keep changing. Arguing about syntax and compile times is a distraction from the real work. Operating Systems</h2> Operating systems are different. I care about Linux only. Mac and Windows are dead to me. I don't care what folks think they are good at. Enjoy it yourself. Your arguments will fall on deaf ears to me. This isn't about purity or ideology. It's about what I need to get work done. Linux gives me control. It doesn't hide things from me. It doesn't force updates at inconvenient times. It doesn't treat me like a consumer who needs protection from myself. If you love macOS or Windows, genuinely, that's fine. Use them. Be productive. I'm not here to convert you. I'm just done pretending I care about the debate. I made my choice. You made yours. Let's move on. Process and Productivity Theater</h2> All organizations are slow and that isn't changing anytime soon. Management, process, production, planning, marketing, etc. are all big giant experiments that are all different in every organization because every organization is made up of completely different people. Yet most think "kanban" or "agile" or "waterfall" planning with Jira, Notion, GitHub issues, etc. are "the way" every project should work. I don't care anymore. I will use whatever and be as slow as your planning decisions make me, provided you're delusional enough to think it's improving productivity. No more arguments from me. I've seen too many process improvements that slowed things down. Too many tools that created more work than they solved. Too many meetings to discuss how to have fewer meetings. Too many retrospectives that resulted in no actual change. The uncomfortable truth is that productivity comes from giving smart people clear problems and getting out of their way. Everything else is overhead. Some overhead is necessary. Most of it isn't. But organizations will keep adding it because doing something feels better than doing nothing, even when doing nothing would be more effective. I'll follow your process. I'll fill out your tickets. I'll attend your standups. But I've stopped believing it matters as much as everyone pretends it does. What I Do Care About</h2> Since this has turned into a list of things I've given up caring about, it's worth saying what I still care about deeply. I care about writing software that works. Not software that's clever or impressive or uses the latest framework. Software that solves a real problem for real people and keeps working when you're not looking at it. I care about making things simple. Not easy, not dumbed down, but genuinely simple. Taking a complex problem and finding the straightforward solution that doesn't require a PhD to maintain. I care about my time and the time of the people around me. Every hour spent in a pointless meeting or debugging someone's overengineered abstraction is an hour I'm not spending with my family or working on something that matters. I care about being honest. Not brutally honest or performatively honest, just plainly honest about what works, what doesn't, what we know, and what we're guessing at. The Peace of Not Caring</h2> Letting go of these things has been liberating. I don't feel pressure to have an opinion on every new JavaScript framework. I don't feel obligated to weigh in on the latest tech controversy. I don't feel like I'm missing out when I skip the conference or ignore the launch event. It took me almost three decades to learn what actually matters in this industry and what's just noise. The noise is louder now than it's ever been. But I've turned down the volume. You're welcome to keep caring about all of it. You're welcome to passionately debate these things. You're welcome to think I'm wrong, or bitter, or checked out. That's fine. I genuinely hope you find fulfillment in whatever you care about. As for me? I'm going to keep writing code that works, using tools that make sense, and spending the rest of my time on things that actually matter. The hype train can leave without me. The End...of Caring</h2> I'm well aware this all comes off as elitist, dismissive, and mean. Guess what? I still don't care. I can hold these thoughts while also working with folks who think the opposite. That is life. You co-exist. I don't care. Excitement is Relative 2025-09-30T00:00:00+00:00 Does this happen to you? Someone shows you something they built. You look at it carefully, think through the implications, and give specific, considered feedback. They walk away deflated. Later, someone tells you that you "seemed dismissive" or "came across as negative." You were not dismissive. You were engaged and thinking. But because your face did not change, your voice stayed level, and you did not perform excitement in the expected way, it read as indifference or criticism. This happens to me constantly. The Excitement Gap</h2> Since I am autistic, I have a hard time meeting people at their excitement level. This applies both to things I find interesting and things others find exciting. When I do not match their energy, I look and sometimes sound mean, like I am raining on their parade. My face stays neutral. My voice stays flat. Over time, people think I am generally abrasive and too blunt because of my lack of visible excitement or happiness about something. When these situations come up in text chats I find myself needing to constantly add emojis and "haha" to the end of things I say so people don't read into it that I am being mean. The problem is not that I lack enthusiasm. The problem is that my enthusiasm does not perform the way neurotypical social scripts expect it to. When I care deeply about something, it shows up as sustained focus, careful consideration, and methodical engagement. I read documentation thoroughly. I think through implications. I build things with discipline and precision. That is what excitement looks like for me. But in real-time interactions, people are not reading for depth of engagement. They are reading for facial expressions, vocal inflection, and energy levels. When those signals are absent or muted, they assume disinterest. Constantly Trapped</h2> This creates a confusing set of traps: Trap 1: I share something I find exciting. Because I do not appear visually excited, people assume I am not actually interested or that I am being sarcastic. They respond with confusion, mild concern, or just don't respond at all. Trap 2: Someone shares something they are excited about with me. They are animated, smiling, speaking quickly. I am engaged and listening carefully, but my face and voice do not mirror their energy. They interpret this as rejection or judgment of their interest. Trap 3: My interests are niche - plain text protocols, minimal tooling, systems programming, powerlifting/strongman, cars, heavy metal music. When I share these, people often just do not respond at all. The silence feels like confirmation that sharing was not worth it. No matter which trap I land in, the result is the same: I look like I do not care, even when I care deeply. What this Costs</h2> Over time, I have learned to share less. If I cannot predict how my flat affect will be misread, it feels safer to just not volunteer interests or opinions. This is not ideal for anyone. People lose out on perspectives and ideas. I lose out on connection and collaboration. Everyone ends up working in a narrower space than necessary. The cost shows up in code reviews where I hold back useful observations because I know they will land wrong. It shows up in meetings where I do not advocate for technical approaches I believe in because I cannot perform the enthusiasm that makes ideas seem worth considering. It shows up in casual conversations where I do not mention what I have been working on or learning because I do not know how to handle the mismatch when someone responds with more visible excitement than I can return. All of this could be addressed by masking and faking the enthusiasm, but then that will cost me mental health and leads to burnout. How do I know? Trust me, I've done it many times. What I Have Learned</h2> Some contexts are better than others. Written communication tends to work in my favor. Email, pull request descriptions, documentation, and blog posts let my care and precision come through without requiring real-time emotional performance. People can read my thoroughness as engagement rather than watching my face for cues I am not giving. Niche communities help too. The folks on Mastodon, people working in Hare, anyone deep in the smallweb space - they share enough context that my signal can land without needing to be wrapped in performative energy. When I say "this plain text protocol is elegant," they understand that is genuine appreciation, not sarcasm or indifference. I have also started being more explicit about this pattern with people I work closely with. "I am really interested in this, even though I probably do not look excited in the way you would expect." It is work I should not have to do, and it does not always help, but sometimes it short-circuits the misinterpretation before it morphs into "Blain does not care about anything." For Other Autistic Engineers</h2> If this sounds familiar, you are not imagining it. The mismatch is real, and it is exhausting to navigate. You are not too blunt or too negative or too detached. You are engaged in ways that do not fit the script people expect, and that is their limitation, not yours. Find the contexts where your signal lands clearly. Lean into written communication when it works better. Seek out communities where substance matters more than performance. You do not owe anyone a particular flavor of enthusiasm, and the people worth working with will learn to read your actual engagement rather than expecting you to perform it their way. For Neurotypical Colleagues</h2> If you work with autistic engineers, consider that engagement might not look like what you expect. Someone can be deeply invested in your work without smiling or raising their voice. Careful, specific feedback is often a sign of respect and interest, not dismissiveness. Flat affect is not the same as flat engagement. When someone shares something and does not seem "excited enough" about it, ask yourself: are they actually disengaged, or are they just not performing engagement in a way that reads clearly to you? Sometimes the most enthusiastic person in the room is the one quietly taking notes and thinking through implications while everyone else is performing energy and hyping for hype's sake. True to Myself</h2> I am not going to suddenly start matching energy levels I do not feel. I am not going to perform enthusiasm I do not experience in the shape people expect. What I can do is keep showing up, keep engaging with precision and care, and keep building things that matter. That has to be enough. If you read my code, my documentation, or my writing and see discipline and thoroughness, that is my excitement showing. If you do not see it, that is fine. But do not mistake my flat affect for apathy. I care deeply. I just do not look like I do. AI Coding 2025-09-12T00:00:00+00:00 It had occurred to me that I haven't really solidified my position on coding with "AI" so I thought I would jot down some thoughts on the subject. Come to think of it... It's the exact opposite of... Hmmm... Wait, I already have written about it</a>! Allergic to Unnecessary Complexity 2025-08-18T00:00:00+00:00 I don't sit down to design systems with complexity as the point. But I've met some that engineers do. They'll never say it outright, but you can see it in their work. They write layers on top of layers, abstractions stacked on abstractions, and clever tricks that only they can explain. Complexity makes them feel smart. It's designed to impress peers in the code review, not to make the system better. Over time this cleverness fades and complexity is left in its wake. Most of the time complexity shows up quietly. It presents itself as a workaround here, a "just in case" abstraction there, or a premature optimization that felt necessary in the moment. At first glance none of it seems bad on its own, but fast forward a year later and the design looks like a maze, spaghetti, or a ball of yarn that was played with by a cat. That's the problem with complexity: it doesn't announce itself. It grows like cancer in the code if no one is watching out for it and by the time noticeable to everyone it is probably too late. Personally, I’ve learned to treat complexity like an allergen. My first reaction is avoidance. Do we really need this extra piece of code? What happens if we don't add it yet? What's the simplest or most straight forward way to get this done without painting ourselves into an immediate corner? This posture isn't about being lazy. It's about respecting the potential cost of every moving part added. Every part has to be maintained, debugged, explained to the next engineer, and kept running long after the excitement of launch has worn off. The tricky part is pointing out complexity when you see it. If you say "this is too complicated" in a code review then it just sounds like a complaint. Instead, ask specific questions. "Can you walk me through why we need all three layers here? I wonder if we could collapse them." Another approach is to tie it to outcomes. "If this broke in the middle of the night, would we have a clear way to debug it?" Or another way, "How long would it take a new hire to grok this?" Framing it with curiosity and outcomes cut through defensiveness and turn what sounds like nitpicking into something the team can act on. Another driver of complexity that doesn't get talked about much is apathy. When engineers stop caring, complexity thrives. Apathy says, "ship it, someone else will figure it out later." Apathy leaves tangled dependencies in place because "it's good enough." It accepts bad abstractions without asking questions, because pushing back takes effort. It's easier to add another patch than to clean up what's already there because there is only ever a task or a ticket for bugs and features, not quality and improvements, despite what engineering cultures claim. Apathy doesn't fight for simplicity. That silence is exactly what lets unnecessary complexity take root. Apathy is the catalyst which leads to complexity. Fortunately, you can spot apathy in small ways: Code reviews that boil down to "LGTM" without a single comment or question.</li> TODOs left to rot in the codebase for months or years.</li> A reflex to add "just another service" instead of asking if the existing ones could be extended.</li> Shrugs when inconsistent naming or half-finished abstractions are pointed out.</li> Teams normalizing duct-tape fixes because "we’ll clean it up later," and later never comes.</li> Missing automated tests in favor of "QA will test it for us".</li> </ul> Each one is a signal that the guardrails are down and apathy is up. If it is left unchecked, those signals turn into systems that nobody fully understands, where adding anything new feels like wading through mud. That is what apathy buys you and now you are going to pay for it with poorly running systems and aggravated engineers. Sometimes, of course, complexity is unavoidable. Certain domains might warrant it like finance, compliance, distributed consensus. In those cases, the job is not to run from complexity but to embrace it, understand it, and contain it. This is where leadership really comes into play. A lead engineer's role is not just shipping tickets. It is their job to keep the whole system from going off the rails. It requires stepping back from the churn of bugs and features and focusing on the bigger picture. How do the parts fit together?</li> Where are the risks when services are modified?</li> What are the long-term costs if today's choices go unchecked?</li> Do we have documentation that supports the behavior of the system?</li> How do we observe the system behavior to build confidence it's working as designed?</li> </ul> This work doesn't always feel productive in the short term because it is never tied to a bug or feature ticket in [INSERT SHITTY PRODUCTIVITY APP HERE]. It is, however, what keeps a team from drowning in its own cleverness and has a direct impact on fewer bugs, faster feature turnaround, and more confident engineers that what they build is, in fact, correct. True seniority isn't proven by how much complexity or code you can build into a system. It's proven by how much of it you can keep out. Simple is not naïve. Simple is discipline, restraint, and the willingness to say "no" when adding another abstraction would make you look clever but leave the system brittle. Software shouldn't be built as monuments to our cleverness since it will undoubtedly change in the future. It should be built to solve problems and stand the test of time until there comes a time to change it. Complexity is a destination software will sometimes reach, but it should never be the purpose. So stay allergic to it. Fight it when you see it. However, when you do have to accept it, make sure it is because the problem demands it and not because your ego, or your apathy, let it in. Bare Essentials Development Tools 2025-08-01T00:00:00+00:00 As a software engineer who's been through the cycle of tooling bloat and complexity creep, I've come full circle to embrace radical simplicity. After years of wrestling with heavyweight IDEs, managing dozens of extensions, and debugging my development environment more than my actual code, I've distilled my entire setup to just four tools: a compiler, git, Helix editor, and tmux. The Unix Philosophy Still Rings True</h2> The Unix philosophy has always resonated with me: "Write programs that do one thing and do it well." This principle doesn't just apply to the software we build—it should guide the tools we choose to build it with. Every additional tool in your arsenal is another dependency, another configuration to maintain, another potential point of failure. When I look at modern development environments, I see a concerning trend toward complexity. IDEs that consume gigabytes of RAM, plugin ecosystems that require their own package managers, and configuration files that span hundreds of lines. We've somehow convinced ourselves that more features equal better productivity, but I've found the opposite to be true. My Four-Tool Philosophy</h2> Compiler</h3> I most work in compiled languates whether it is Go, Rust, or C, but the majority of my work involves Go. Using the languages official toolchain and mastering the features it offers is essential to understanding how your program will run in production and make it much easier to debug. Go, specifically, embodies the same minimalist philosophy that drives my tooling choices. The compiler is fast, the language is simple, and the standard library is comprehensive. I don't need multiple language runtimes, dependency managers, or build systems cluttering my environment. The Go toolchain handles formatting, testing, and building with built-in commands that just work. Git</h3> While others reach for GUI clients or IDE integrations, I stick with git on the command line. It's available everywhere, works identically across all platforms, and forces me to understand what's actually happening with my code history. No visual noise, no abstraction layers, but simply direct, predictable version control. Helix</h3> Helix struck the perfect balance for me. It is more capable than traditional editors like vim or nano, but without the complexity of modern IDEs. It provides syntax highlighting, basic language server support, and efficient text manipulation without requiring hours of configuration. I can install it on any system and be productive immediately. tmux</h3> Tmux gives me everything I need for managing multiple terminal sessions without the overhead of a desktop environment or complex window manager. I can detach from sessions, work across multiple panes, and maintain my workflow whether I'm on a local machine or SSH'd into a remote server. The Power of Minimal Configuration</h2> Each of these tools requires virtually no configuration to be useful. My entire setup can be replicated on any Unix-like system in under ten minutes: Install Go, git, Helix, and tmux</li> Copy over a handful of configuration lines (less than 50 total across all tools)</li> Clone my repositories and start coding</li> </ol> This portability has been a game-changer. Whether I'm working on my laptop, a colleague's machine, a cloud instance, or a production server, my environment feels identical. There's no vendor lock-in, no licensing concerns, and no compatibility issues between operating systems. What I've Gained by Subtracting</h2> By embracing this minimalist approach, I've discovered several unexpected benefits: Mental clarity: With fewer tools to think about, I can focus entirely on the problem I'm solving rather than fighting with my environment. Reduced maintenance: No more time wasted updating plugins, resolving configuration conflicts, or debugging tool interactions. Universal accessibility: I can be productive on any machine, anywhere, without needing specific software versions or licenses. Deeper understanding: Working closer to the metal has improved my understanding of how compilation, version control, and text processing actually work. The Resistance to Simplicity</h2> I've encountered pushback from developers who argue that modern IDEs provide essential features like advanced debugging, intelligent code completion, and integrated testing. While these features can be valuable, I've found that they often become crutches that prevent us from truly understanding our code and development process. When you can't rely on an IDE to auto-import packages, you learn your dependencies better. When you run tests from the command line, you understand your test structure more clearly. When you debug with print statements and logs instead of graphical debuggers, you develop better intuition about program flow. Rediscovering the Joy of Simple Tools</h2> Software development is fundamentally about solving problems with code. Every tool that doesn't directly contribute to that goal is overhead. By stripping away the unnecessary complexity and embracing the Unix philosophy of simple, composable tools, programming is full of joy. My four-tool setup isn't about being contrarian or nostalgic. It's about optimizing for what actually matters, which is, writing good code efficiently and reliably. In a world of increasing complexity, sometimes the most radical thing you can do is subtract rather than add. If you're feeling overwhelmed by your development environment or spending more time configuring tools than using them, I challenge you to try the minimalist approach. You might be surprised by how much you can accomplish with so little. Software Engineering Discipline and Posture 2025-07-23T00:00:00+00:00 There's something quietly dignified about a clean commit history, well written patch/pull requests, and documentation. It tells you someone gave a damn. That they weren't just slinging code to pass tests, but writing with others, including you, in mind. They knew they were stepping into a shared space, and they acted accordingly. That's what engineering discipline looks like. And it's what posture looks like when you're working in a team. Respect is Written Into the Code</h2> You don’t respect your teammates by slapping a thumbs-up emoji in Slack. You respect them by naming your variables well. You respect them by writing a README.md</code> that doesn't assume someone already knows what you know and DEPLOY.md</code>/DESIGN.md</code> files that explain how the system gets deployed and runs. You respect them by writing documentation as plain text and not assume everyone uses MacOS with the expensive MacOS-only diagram visualizer and editor. You respect them by explaining the why, not just the what, in your pull request description. Discipline isn't some grueling formality. It's kindness in disguise. When you write clear code, when you separate concerns, when you squash the "fixes typo" commits into the thing you meant to say in the first place then you are making life easier for the person coming after you. You are creating room for someone else to think clearly. Commits Are a Conversation</h2> Commits are not just little logs of activity. They are sentences in an ongoing conversation across time. If your message is "wip" or "fix" or "asdf", you're not holding up your end. Write a commit message like someone else is going to read it on a dark night, months from now, debugging a production issue you never saw coming. Because they probably will. ... 809de69 Blain Smith May 22 09:06:40 2025 Cache results per user session ccc4b9d Blain Smith May 20 10:09:02 2025 Fix off-by-one pagination 538ea53 Blain Smith May 19 17:39:54 2025 Retry logic for external API ...</code></pre> That's not verbosity. That's posture. That's thinking of your team, your future self, and the next engineer who clones the repo to start working. Pull Requests Are Invitations</h2> A pull request is not a demand this code needs to get merged. It's an invitation to start a conversation about finding the best solution as a team. It says: Here is something I've built. Here's what I was thinking. Here's what I need help reviewing. It should come with context. A clear title. A summary. Maybe some notes on what to look at closely, which parts are up for discussion, how it was tested, or how it improves a previous version with benchmarks. When you open a pull request with care, you're saying: I respect your time. I've thought this through. I want your perspective. Compare that to the dump-and-run: 400 changed files, vague title, no description. That's not collaboration. That's cowardice hiding behind automation. Leave the Place Better Than You Found It</h2> You don't need to overhaul the whole system. But you can write one more docstring. You can rename one more unclear function. You can add a test that wasn't there before. You don't need a Jira ticket or persmission from some "manager" to leave the place better than you found it. It is easier to ask for forgivness later than permission right now. Every time you touch a shared repo, you have a choice: contribute to the mess or clarify the system. Discipline is what makes that second choice possible. Posture is what makes it visible. In Closing</h2> Engineering isn't just about shipping features. It's about shaping the experience of others. Our colleagues, our future selves, and those who will maintain the code long after we’re gone will appreciate it. If you care about your craft, it shows. If you care about your team, it shows even more. Write and code like someone else will read it. Because they will. Work like you're part of something larger. Because you are. Be disciplined. Be respectful. If you can't, learn. If you won't, GTFO. Towards Teaching 2025-07-10T00:00:00+00:00 I’ve been writing code for about thirty years now. I say that with no small amount of gratitude and a touch of disbelief. Thirty years of debugging, designing, deleting, rewriting. Of shipping things that broke and patching things that probably should not have seen the light of day. Of staying up way too late for launches that no one remembers but me. Of being woken up at 2AM because of a service that went down for a mere 10 seconds only to come back just time, but long enough to trip a critical alert. If you’ve been in this field long enough, you know the feeling. You build. You burn out. You move on. Repeat. But lately, something has changed. I've crossed into my 40s, and while I am still writing code, still solving problems, I feel a pull in a different direction. I am being pulled towards teaching and spreading the knowledge I've gained. I don't mean this by brand-building. Not some content grind that churns out bite-sized wisdom for likes on LinkedIn with animated GIFs showing AWS architecture diagrams or super pretty image code snippets that tend to nerd snipe the best of us. I am talking about teaching the craft. The real thing. Teaching students how to think clearly, write software that's correct, sustainable, and ethical. Teaching them to write code they can be proud of ten years down the road, not just code that makes a slick demo on launch day because management fucked up planning the timeline and now it is "all hands on deck" to finish the vaporware demo. I'm not interested in helping anyone "crack the algorithm interview" or "launch their SaaS in 30 days." We've got enough of that. What we are short on is people who can build systems that respect users, that last, that are not just glued together with libraries stacked five deep and a prayer to the CI gods. We're short on people who know that "clean architecture" is far more than a buzzword, it's a form of respect for your coworkers, for your future self, and for the users who trust you. I have nil interest in teaching students how to get rich. I want to teach them how to do their best to get it correct. And that means we do not start with frameworks. We start with thinking. With curiosity. With constraints. I want them to know what it is like to really understand the stack, to trace through a function call without needing multiple browser tabs open. I want them to know what good failure modes look like. What accountability in code looks like. What it means to write something that can still be read and trusted years later. Most of all, I want to pass down a vision of software that isn't about conquest. Not every line of code needs to scale to millions. Some of the best systems I've seen run quietly for years with no fanfare. That's the kind of work I want them to know exists. If you're a certain kind of person there's a weird freedom that comes with time in this industry. You stop needing to prove so much. You start wanting to give more than you get. You realize your legacy will not be the startups or the codebases since they’ll be gone, eventually. But the people you help? The ones you teach how to think deeply and build responsibly? They carry that forward. So that is the direction I am facing now. Slower. More thoughtful. More human. No AI shortcuts. No "move fast and break things." Just clear thinking, solid systems, and the hope that a few people will build software that serves others without manipulating them. I am not quitting the keyboard anytime soon</a>. I will still be feeding my family by coding. But if you're someone who's been in this field a while and you feel that same pull to give back then maybe it's time. Let's stop hustling</a>. Let's start teaching. Introducting: Hare by Example 2025-07-02T00:00:00+00:00 Whenever someone asks me about learning Go</a> and what online resources I would recommend they check out I always point them to Go by Example</a>. This quick reference style site lets someone who is already good at programming in another language get up to speed on the basic semantics and idioms without having to read the offical language specification or verbose tutorials. How do I loop over items? </blockquote> Pull up the site and head to Rage over Built-in Types</a> and there is your answer. No need to read lengthy prose explaining anything. Just an example and some annotations to get you your answer. If you know me at all you also probably know I've been enjoying spare time using Hare</a> because it reminds me a lot of Go, but also C. While Hare does offer great documentation and tutorials on the language I wanted something even more concise like Go by Example for Hare. Nothing existed so I decided to make it myself. Introducing, Hare by Example</a> for all your quick Hare needs. I would strongly recommend you still check out the other great resources the Hare website has to offer. As always, my inbox</a> is open and I am happy to accept patches to the project</a>. Block Non-Human Crawlers with Go 2025-04-23T00:00:00+00:00 Recently, Adële wrote</a> about how to block non-human crawlers by setting a cookie to prove a human is visiting a website. I won't go into details here about how the mechanics work, but I wanted to see if I could adapt this to Go</a> middleware to provide the same result. Middleware</h2> This is the configurable middleware http.Handler</code></a> you can use to wrap other http.Handler</code>s when building a Go web app when it serves HTML. // The template used to render the form with placeholder for the hashed // User-Agent value when inserted at runtime var form string = `<!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta name="color-scheme" content="light dark" /> <title>Human check</title> </head> <body> <main> <form method="GET"> <input type="checkbox" name="hash" value="%s" /> I am a human <button type="submit">Submit</button> this will set a dummy cookie (AI crawlers do not manage cookies) </form> </main> </body> </html>` // Protect is the middleware func used to wrap other http.Handlers func Protect(next http.Handler, cookieName string, hasher hash.Hash) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // Skip if the request is not asking for HTML content if !strings.Contains(r.Header.Get("Accept"), "text/html") { next.ServeHTTP(w, r) return } // Set the cookie if the hash value is set then continue to the next // handler in the chain if hash := r.URL.Query().Get("hash"); hash != "" { http.SetCookie(w, &http.Cookie{ Name: cookieName, Value: hash, SameSite: http.SameSiteLaxMode, Path: "/", }) next.ServeHTTP(w, r) return } // Hash the User-Agent value with the configured hash.Hash as a // Base64-encoded string value for safe use in the form and cookie // value ua := r.Header.Get("User-Agent") if _, err := hasher.Write([]byte(ua)); err != nil { http.Error(w, "failed to hash cookie value", http.StatusInternalServerError) return } uahash := fmt.Sprintf("%x", hasher.Sum(nil)) // Get the cookie by the configured name and if it does not exist // then render the form for the human to prove themselves worthy cookie, err := r.Cookie(cookieName) if err != nil { if _, err := fmt.Fprintf(w, form, uahash); err != nil { http.Error(w, "failed to render form", http.StatusInternalServerError) return } return } // If the cookie does exist, but the value of it does not match the // hashed value of the User-Agent header then render the form for // the human to prove themselves worthy if cookie.Value != uahash { if _, err := fmt.Fprintf(w, form, uahash); err != nil { http.Error(w, "failed to render form", http.StatusInternalServerError) return } return } // Finally, if we reach this point then the cookie is set with the // correct hashed value of the User-Agent proving the worthiness of // the human who submitted the form next.ServeHTTP(w, r) }) }</code></pre>Example Usage</h2> This middleware can be used to protect any single or group of routes in your app as long as it is an http.Handler</code>. func main() { // Decide on a cookie name that you want to use cookieName := "bot-blocker-5000" // Decide on a `hash.Hash` type to use hash := hmac.New(sha256.New, []byte("s3cr3t!")) // Sample unprotected route with a normal `http.Handler` http.HandleFunc("/unprotected", unprotected) // Sample protected route wrapped with the `Protect()` func http.Handle("/protected", Protect(http.HandlerFunc(protected), cookieName, hash)) http.ListenAndServe(":8080", nil) } func unprotected(w http.ResponseWriter, _ *http.Request) { fmt.Fprint(w, "I am unprotected") } func protected(w http.ResponseWriter, _ *http.Request) { fmt.Fprint(w, "I am protected") }</code></pre>Notable Differences</h2> The core principal is the same as Adële's version, but I made some changes to make it configurable for whoever wants to use it. Specify what the name of the cookie is</li> Specify what hashing method</a> to use</li> Ensures this only protects content when the Accept: text/html</code> header is so it won't break images, RSS feeds, or any other non-HTML content</li> </ol> Outro</h2> Sure, this isn't perfect from protecting all content from non-human crawlers, but its pretty good at it if your writing a web app in Go and you don't want to configure you proxy to do this or stand up an instance of Anubis</a>, Nepenthes</a>, etc. I also have no intention of publishing this as an official Go module because: I don't want to deal with managing versions of this</li> Its not that hard to copy/pasta this into your project and change it as needed</li> K.I.S.S., smolweb, and all that stuff</li> </ol> If you want to give me feedback on this you can hit me up via any of the links in the footer of this site. Consider this another option in the fight against "AI" and LLM bots! Limeleaf Co-op 2025-01-17T00:00:00+00:00 This past January 13th I turned 43, and as I approached that day, I spent a lot of time over winter break reflecting on the past decades I worked in the tech industry. About a year ago I had a similar reflection when I rage-quit</a>, but I eventually came around to doing some contract work to make some money and then took a job to get health benefits. This was before my wife and I got married and before she found her career job with amazing people and a great place that offered her benefits as well. So, I quit! I came to realize that I am no longer cut out for working at a company in the traditional sense in the tech industry. I just do not care about any company's product. There are some cool gems out there being worked on, but most of them are useless, wasteful, and wouldn't be missed if they did not exist since they are not actually needed. Not to mention the capitalistic money grab craziness that is tearing through the industry with "AI" right now. Being a software engineer working on hard problems over 10 years ago was novel. It was challenging. It was deliberate. It was purposeful. It was fun. Now, it isn't, and that is fine, but I am choosing not to engage or take part in a lot of it. Instead, I took steps over the past year to create and learn about co-ops</a>. Limeleaf</a> has legally existed for almost a year now, and while it isn't self-sustaining just yet, we have started to network and get people to notice us, especially in the co-op movement. We feel this is our chance to challenge the status-quo about earn a living without selling our souls (and your data) to big tech. For me, personally, this is the next phase of my career where I can be "the master of my fate.". This will give me the opportunity to not only be selective about what I want to work on but also give me the freedom to focus on my family that is growing up as my wife and I enter our 40s and our kids enter their teenage years. I am extremely passionate about what the co-op movement will afford my family and me, and so if you have any questions about the movement, then do not hesitate to reach out and ask! "Be excellent to each other." - Bill S. Preston, Esq. "Rot Economy" and Software Bloat is Increasing the Digital Divide 2024-03-25T00:00:00+00:00 I have been involved in writing software professionally for almost 3 decades. A lot has changed since the days of </code> tags and cgi-bin scripts. A lot of the changes have redefined how software is written, organized, collaborated on, and delivered to its users. As more people came online with the commoditization of internet access and the increasing thread count of CPUs the software tools have adapted to those changes. We are seeing a lot of critical software that was once written in C being re-written in Rust to drastically improve memory safety and decrease security flaws. We have virtual cloud servers capable of simulating 256+ CPU cores per machine in large cluster thus making massive high performance cluster computations available by folks with a credit card to sign up and use. We have Go stepping in and becoming the networked cloud programming language to write these complex distributed system tools the world depends on. We have browsers now that act more like operating systems capable of loading complex HTML and enhancing it with even more complex JavaScript to give users desktop-like experiences on the web. While all of this was inevitable given varying applications of Moore's Law and layering in the tech world's obsession with hustle culture, grow quick, ship fast, raise more money, approach to building software we see the digital divide grow even wider. Once we had (still have) "developing countries" struggle to gain access to the internet, but now we have "developing states" in the US that have such sub-par internet access, even if it is better than developing countries, they struggle to keep up with the rest of the country, let alone the world. The Middle-East, India, Africa, and parts of rural China are well known for having limited or even no internet access. However, we are now seeing rural parts of the US, mainly in the midwest and the south, start to show signs of lagging access to internet speeds that the rest of the country takes for granted. I am currently writing this paper on my 8 core CPU, 32 GB RAM, and 1 TB HD laptop connected to a 1 GB symmetrical speed internet connection with Google Docs opened in my web browser. The experience of this is nothing short of amazing considering only 20 years ago I would have to do this by paying a lot of money for a license to Microsoft Office to use Word. However, there are a lot of hidden costs to this seemingly free online document editor now. This site had to loa ~25 MB of data over a network connection consisting of ~250 requests in which my browser is now consuming ~2 GB RAM in order for me to type black text characters onto a white screen. Windows 95 came available on 13 3.5" floppy disks so I essentially needed about 18 of those floppy disks just to run a document editor in a browser. Punishing all that data across a 1 GB network connection is fine, but what about those with connections in the low MB or even high KB range? It would be effectively useless. While the advancements and tools created to make systems and experiences like this possible the hubris and elitist stance these advancements also tend to create is also undeniable. To address these concerns the Single-Page App (SPA) was introduced to give users a more native experience using a web app, but also to enable background processing and caching techniques to deliver a better experience. The same experience can be delivered by offering a native build mobile or desktop app, but without the need to write it in multiple native languages. Writing a SPA requires only the use of modern web technology and tools to write a single codebase usable cross-platform on mobile and desktop browsers. The promise of convenience, usability, and consistency is usually met with over complexity, bloat, and rotten experience. The PWA movement has led software engineers into laziness by picking up tools and frameworks for quick fixes to ship faster and more often instead of being deliberate, concerned, and sympathetic software developers to their user's hardware and internet connection status in this world. What good is a SPA if the user still has to download 5 MB of React JavaScript framework bloat that takes up hard drive space on cheap hardware over a 2 MB internet connection only to be met with a SPA to consume GBs of precious RAM because it needs Google Chrome to run it which is well known for being a RAM hog. Google even recognized this and shipped a "Memory Saver" feature in Chrome that users can adjust. Why would anyone not want this enabled all the time? Most users of this wouldn't even know where to begin to set this appropriately. SPAs are not addressing the root cause of slow and poor app experiences on slow internet connections. The root cause is "rot economy"</a> thinking forcing software engineers to build bloated tools and software to ship more things faster to show their company is growing to a board of investors and directors. Over the last 30 years I have experienced some amazing changes in the software world. It used to be a small group of us that understood and used computers on a daily basis, but now large portions of people own smartphones, tablets, multiple TVs, and multiple computers requiring increasingly better hardware and internet connections in order to sustain the growth and features of the software companies that have made tech so commonplace it's amazing how we lived without some of these things. However, those of us with the luxury, affordance, education, and understanding to keep up we still have our counterparts in not only developing countries, but developing states who do not have all of those things. There is an increasing digital divide not only technically, but also educationally since software has become pervasive and commonplace in most everyone's lives. Local municipalities, school districts, small business, and rural families are being left behind and forgotten when it comes to the software they are required to depend on for daily life. They don't care about SPAs, multi-core cloud computers, nuances of internet speeds, and the frameworks and languages used to build apps. They just want their kid's school bus app to work on their 4 year old phone because it gives them a sense of comfort that their children got back and forth to school safely. They want the local pizza shop's app that doesn't crash, load slowly, or mis-charge them when they order delivery for Friday movie night. They want to be able to conveniently pay their municipal bills and fees safely online so they don't have to wait for checks to clear or take precious time off work to run down to the town hall to pay fees. This is the population of people the digital divide is also affecting and PWAs written in the new hot JavaScript cross-platform web framework is not going to fix it and software engineers should take a step back before using them and think who their audience could be. An HTML page with good compression with a table of data is enough for a slow internet connection. Extra time making an Android and iOS app that runs on the last 4 versions of mobile phones to be able to make deliberate use of the phone's amazing hardware to ensure the experience is delightful, correct, and comforting should be a priority. These choices lead to longer term sustainable software because they are built on foundational technology and simple ideas. Done 2024-03-19T00:00:00+00:00 Well, I think I finally hit a breaking point and I am officially done with the bullshit spreading through the "big" tech industry lately and I don't want to be a part of it anymore. I've been doing some sort of tech work for almost 30 years (27 to be exact) at this point and I am only 42 years old. I had my birthday on January 13th</a>. As I come to terms with moving through my 40s as a father of two great kids I find myself giving less and less fucks about the traditional work and culture in "big" tech. What I mean by "big" tech is essentially what you expect to find in mainstream media, LinkedIn, Twitter (I am not calling it X, deal with it), and other garbage and fake "social media" platforms. The vomit inducing "greater good" mission statements about changing the world and making it a better place while systematically collecting data on everything to justify the lies companies are telling themselves about what they are building is novel, innovative, and creating synergy in the world. It is all crap. Behind the veil of fakeness is a house of cards that constantly breaks under the weight of its own hubris and needless complexity. Hundreds of engineering hours spent on "agile" sprints doing story points and making plans that change on a weekly basis anyway. Infrastructure, tools, and architectures that are so overengineered because the industry celebrates clever and unique solutions over simple and proven ones. All of this leading towards products that are either crap or serve no real purpose and are only existing to make a play at VC money and "play" running a company. Software engineers as a whole are WILDLY overpaid because of all of the above. Companies need to pay to deal with the death by a thousand cuts and the sunk cost fallacy in order to retain their extremely smart folks. Folks are literally paid to babysit the computers that run products because shit is so unpredictable and unstable because they chose that complexity and think a MOMENT of downtime is life or death. Did I mention hubris yet? Fortunately, there is a world of tech that is actively against all of this drivel. The world of hackers, open source enthusiasts, digital activists, technology generalists, and tech co-ops is real and they are making a living at it. They are not falling for the overly positive marketing lies and "cold call" sales pitching techniques people spend money on LinkedIn classes to learn. This other tech world actually gives a shit about climate change, DEI, privacy, ethics, and socially good tech choices. There are even a few VC funded companies that actually give a shit about what they are doing. They take the privilege of being handed millions of dollars in cash very seriously and don't squander it. This is where I am going. I am done with the other world. I will see you in the smol, humane, solarpunk tech world from now on. static-httpd 2024-03-01T00:00:00+00:00 Today I get to release the first working version of static-httpd</code></a>. I have always found value in using an HTTP static file server to serve up some quick sites out of the current working directory. I've even written an article way in the beforetimes</a> about some options to spin up a quick server. Since then there has been a flood of them to hit the open source scene and so I wanted to build one myself, but use Hare</a> to do it since I've been spending a lot of time using this new language. Design Goals</h2> My aim was to keep the final binary small and dependancy free as much as possible. By keeping simple-httpd</code> single-threaded I was able to achieve that. There are options to support multi-threaded and multi-connections with either forking the process or using hare-ev</code></a> to do evented I/O. I decided against this given the use cases I was aiming to support. Since only needed the Hare standard libary the final compiled binary weights in at ~700kb. I think this is pretty nice considering the other options are significantly higher or need an interpreter. I could probably get this smaller, but staying under the 1mb limit is good enough for me. Future Features</h2> If there is a lot of interest in evented I/O support I could be convinced to pull in hare-ev</code></a>.</li> Let's Encrypt</a> or local certificates would be a nice to have leveraging hare-tls</code></a>.</li> </ul> If you feel so inclined my public inbox</a> is open for patches. Writing Bitcask in Hare 2023-10-06T00:00:00+00:00 TL;DR Read the source code for https://git.sr.ht/~blainsmith/hare-bitcask</a>. I have been writing modules</a> for Hare</a> for a while now. It has been a lot of fun to write and helping expand the open source ecosystem of modules for this language has made me feel very fulfilled. Up until this point I've been mostly focused on small modules, but I really wanted to tackle something much more ambitious. I found that opportunity when I started my Fall 2023 semester at Georgia Tech and joined a Virtically Integrated Projects team</a> with some undergraduate students. Since a lot of my career I have spent in gaming I thought this was perfect to be able to focus an entire semester using a modern language to make a game. I got permission from the professor to use Hare to make a MUD/text adventure accessible online. There will be a blog post about that towards the end of the semester, but this post and work covered below was the result of needing to save game state for players. As work on the game itself progressed it was finally time to decide how to save game state. At first I considered just writing a file per player to disk based on their chosen player handle and updating that periodically. While that would be good enough for this style of game I wanted to try my hand at making a database from scratch since I have a lot more time this semester. Since I didn't want to spend a lot of time designing a database itself I wanted to find a pre-existing database that would not only fit my needs for the game, but also make for an interesting experience writing it in Hare. After searching around research papers and articles I finally found the perfect candidate. The Bitcask</a> backend for Riak KV. The design paper</a> was even available cover some of the implementation details. Bitcask API</h2> I wanted the API to match as closely as possible to the original so what I ended up with was: export type db = struct { ... }; export fn put(db: *db, key: str, val: []u8) (void | error) = { ... }; export fn get(db: *db, key: str) ([]u8 | void | error) = { ... }; export fn del(db: *db, key: str) (void | error) = { ... }; export fn keys(db: *db) ([]str | void | error) = { ... }; export fn merge(db: *db) (void | error) = { ... };</code></pre> Most of the functions are self-explanitory. However, merge(...)</code> is used to merge and compact all of the underlying data files on disk to clean up history of old values and deleted keys since the data files are append-only. Without this the files would grow indefinately. Some implementations of Bitcask in other languages might call merge in a background job when data files reach a configurable max size. I chose to omit this functionality for now and put the responsibility on the programmer using this library to call merge(...)</code> at any interval they need to. Data File Encoding/Decoding</h2> All of the files written to disk following the original design document so in theory this implementation should be able to encode/decide those same files. I have not tested this and there might be some minor differences in field sizes, but that should be pretty straightforward to accomplish. The endian</code></a> modules make it really easy to perform this work, but I do with there was something like binary.Read(...)</code></a> and binary.Write(...)</code></a> for Hare to be able to read/write binary data to a file handle instead of needing to use []u8</code> as intermediate data types. Maybe it will come in the future. // Make an array of 2 bytes let klen: [2]u8 = [0...]; // Encode the length of the key as a u16 into that array endian::little.putu16(klen, len(key): u16); // Write the array as a slice to the file handle io::write(w, klen[0..])?;</code></pre>Hash Maps</h2> I make use of a few hash maps in order to have quick lookups of keys and data files. Unfortunately, Hare does not natively have hash maps as a built-in data type like other languages do. Fortunately, it was trivial to implment one for the key/values I needed. // Meta contains information about the record and file id location. type meta = struct { ... }; // keydir is a hash map of 64 buckets with a str key and a *meta value tuple. type keydir = [64][](str, *meta); fn keydir_get(kd: *keydir, key: str) (*meta | void) = { let bkt = fnv::string(key) % len(kd); for (let i = 0z; i < len(kd[bkt]); i += 1) { if (kd[bkt][i].0 == key) { return kd[bkt][i].1; }; }; return; }; fn keydir_set(kd: *keydir, key: str, val: *meta) void = { ... }; fn keydir_del(kd: *keydir, key: str) void = { ... }; fn keydir_finish(kd: *keydir) void = { ... };</code></pre> This gives me similar functionality of a Go map that would be map[string]*meta</code> that I can use throughout Bitcask. The keydir_finish</code> function is used to free allocated memory of all of the items in the map and then the actual map itself since I have to allocate and deallocate my own memory. The TYPE_finish(...)</code> pattern you will see a lot in Hare to do exactly that kind of work. The basis of this implementation was inspired by one of Hare's author's, Drew DeVault</a>, public gist</a> he showed me. What's next?</h2> Now that I have a working database for my game I can move forward with the game itself, but I will certainly come back to Bitcask to add more features from the design paper. Most notably they would be: Setting an expiry on keys</li> Auto-merge on a configurable interval</li> 1:1 encoding parity with the official implementation from Basho</a></li> </ul> Let me know what you think about it and if you have any questions or would like to send me patches feel free to reach out to me using my public inbox at https://lists.sr.ht/~blainsmith/public-inbox</a> or email me directly. Auto-Generating an OpenAPI Specification for gRPC and gRPC Gateway 2022-07-29T00:00:00+00:00 When building new services, gRPC</a> can be very handy to not only define those services, but also generate a lot of the boilerplate code for server implementations and client libraries. We get the added benefit of a more efficient wire protocol, Protocol Buffers</a>, because it's in binary and a lot smaller than JSON. However, sometime we still need to support HTTP and some REST-ful behavior of our services. It would be nice to still be able to leverage all the benefits of using gRPC and Protocol Buffers without sacrificing or needing to write a lot of wrapper/proxy code to expose those services over HTTP. Taking this even further, it would be even better to leverage auto-generated documentation of our HTTP endpoints with the OpenAPI Specification</a> and allow developers to interact with it with a hosted version of the Swagger UI</a>. Fortunately, the gRPC ecosystem has plugins to support this setup, and requires minimal code to wire everything together. Defining a gRPC Service</h2> Here we define a simple gRPC CRUD ExampleService</code>. For the sake of brevity, we'll just use google.protobuf.Empty</code> messages for the requests and responses. Typically, we would define message CreateRequest {...}</code> and message CreateResponse {...}</code> types with the appropriate fields. protos/service.proto syntax = "proto3"; package protos; import "google/protobuf/empty.proto"; option go_package = "github.com/blainsmith/grpc-gateway-openapi-example/gen/proto/go/protos;protos"; service ExampleService { rpc Create(google.protobuf.Empty) returns (google.protobuf.Empty) {} rpc Read(google.protobuf.Empty) returns (google.protobuf.Empty) {} rpc Update(google.protobuf.Empty) returns (google.protobuf.Empty) {} rpc Delete(google.protobuf.Empty) returns (google.protobuf.Empty) {} } </code></pre>Generating and Implementing the Server in Go</h2> Now that we have our service defined, we can generate the Go server interface and client using the Protocol Buffer compiler and the appropriate plugins. We'll be using buf</code> to do this work, which uses protoc</code> under the hood. We'll create two configuration files for buf</code> so it knows what to generate. This is a basic buf</code> configuration that defines our service name and the dependencies we need to build our protos/service.proto</code> file. We need to define buf.build/googleapis/googleapis</code> as a dependency in order to use google.protobuf.Empty</code> as our request and response messages. buf.yaml version: v1 name: buf.build/blainsmith/grpc-gateway-openapi-example deps: - buf.build/googleapis/googleapis breaking: use: - FILE lint: use: - DEFAULT </code></pre> The second configuration file tells buf</code> how to generate our Go code and where to put the output files. buf.gen.yaml version: v1 plugins: - name: go out: gen/protos/go opt: paths=source_relative - name: go-grpc out: gen/protos/go opt: - paths=source_relative</code></pre> After running buf build</code> and buf generate</code> we end up with 2 new files. The first file contains our generate wire Protocol Buffer messages, and the second contains the gRPC server and client. gen/protos/go/protos/service.pb.go // Code generated by protoc-gen-go. DO NOT EDIT. // versions: // protoc-gen-go v1.25.0 // protoc (unknown) // source: protos/service.proto package protos ...</code></pre> gen/protos/go/protos/service_grpc.pb.go // Code generated by protoc-gen-go-grpc. DO NOT EDIT. package protos ... type ExampleServiceClient interface { Create(ctx context.Context, in *emptypb.Empty, opts ...grpc.CallOption) (*emptypb.Empty, error) Read(ctx context.Context, in *emptypb.Empty, opts ...grpc.CallOption) (*emptypb.Empty, error) Update(ctx context.Context, in *emptypb.Empty, opts ...grpc.CallOption) (*emptypb.Empty, error) Delete(ctx context.Context, in *emptypb.Empty, opts ...grpc.CallOption) (*emptypb.Empty, error) } ... type ExampleServiceServer interface { Create(context.Context, *emptypb.Empty) (*emptypb.Empty, error) Read(context.Context, *emptypb.Empty) (*emptypb.Empty, error) Update(context.Context, *emptypb.Empty) (*emptypb.Empty, error) Delete(context.Context, *emptypb.Empty) (*emptypb.Empty, error) mustEmbedUnimplementedExampleServiceServer() } ...</code></pre> Now we can implement the server in our own Go file. Implementing the gRPC Server</h2> We now need to define the logic that implements protos.ExampleServiceServer</code>, and to do that, we just make our own file and import the generated protos</code> package. We create our source file, define our own struct</code>, and implement the CRUD functions that are required by protos.ExampleServiceServer</code>. service/example.go package service import ( "context" "github.com/blainsmith/grpc-gateway-openapi-example/gen/protos/go/protos" "google.golang.org/grpc/codes" "google.golang.org/grpc/status" "google.golang.org/protobuf/types/known/emptypb" ) type ExampleService struct { *protos.UnimplementedExampleServiceServer } func (ExampleService) Create(context.Context, *emptypb.Empty) (*emptypb.Empty, error) { return nil, status.Errorf(codes.Unimplemented, "method Create not implemented") } func (ExampleService) Read(context.Context, *emptypb.Empty) (*emptypb.Empty, error) { return nil, status.Errorf(codes.Unimplemented, "method Read not implemented") } func (ExampleService) Update(context.Context, *emptypb.Empty) (*emptypb.Empty, error) { return nil, status.Errorf(codes.Unimplemented, "method Update not implemented") } func (ExampleService) Delete(context.Context, *emptypb.Empty) (*emptypb.Empty, error) { return nil, status.Errorf(codes.Unimplemented, "method Delete not implemented") }</code></pre>Starting the gRPC Server</h2> Now that we have an implemented service, we need to start it by listening on a port to expose it. cmd/example.go package main func main() { lis, err := net.Listen("tcp", ":9090") if err != nil { log.Fatalf("failed to listen: %v", err) } grpcServer := grpc.NewServer() protos.RegisterExampleServiceServer(grpcServer, &service.ExampleService{}) err = grpcServer.Serve(lis) if err != nil { log.Fatalf("failed to serve: %v", err) } }</code></pre> Now we have our gRPC server running so clients can connect and call our CRUD functions. Annotate the gRPC Service with HTTP Routes</h2> Now comes the interesting part of exposing an HTTP server to handle REST calls to the same ExampleService</code> implementation we defined in service/example.go</code> without changing that code. We start by modifying our .proto</code> file an annotate the RPC calls to include optional HTTP routes to be attached to. syntax = "proto3"; package protos; import "google/api/annotations.proto"; import "google/protobuf/empty.proto"; option go_package = "github.com/blainsmith/grpc-gateway-openapi-example/gen/proto/go/protos;protos"; service ExampleService { rpc Create(google.protobuf.Empty) returns (google.protobuf.Empty) { option (google.api.http) = { post: "/create" }; } rpc Read(google.protobuf.Empty) returns (google.protobuf.Empty) { option (google.api.http) = { get: "/read" }; } rpc Update(google.protobuf.Empty) returns (google.protobuf.Empty) { option (google.api.http) = { put: "/update" }; } rpc Delete(google.protobuf.Empty) returns (google.protobuf.Empty) { option (google.api.http) = { delete: "/delete" }; } }</code></pre>Generate the gRPC Gateway</h2> Now that we have our service annotated with routes, we can use another gRPC plugin to generate a new server which will accept HTTP calls and proxy them to gRPC calls. We modify our buf.gen.yaml</code> file to include a new plugin. buf.gen.yaml version: v1 plugins: - name: go out: gen/protos/go opt: paths=source_relative - name: go-grpc out: gen/protos/go opt: - paths=source_relative - name: grpc-gateway out: gen/protos/go opt: - paths=source_relative</code></pre> Now we can run buf generate</code> again, which will output another file. gen/protos/go/protos/service.pb.gw.go // Code generated by protoc-gen-grpc-gateway. DO NOT EDIT. // source: protos/service.proto /* Package protos is a reverse proxy. It translates gRPC into RESTful JSON APIs. */ package protos ... // RegisterExampleServiceHandlerServer registers the http handlers for service ExampleService to "mux". // UnaryRPC :call ExampleServiceServer directly. // StreamingRPC :currently unsupported pending https://github.com/grpc/grpc-go/issues/906. // Note that using this registration option will cause many gRPC library features to stop working. Consider using RegisterExampleServiceHandlerFromEndpoint instead. func RegisterExampleServiceHandlerServer(ctx context.Context, mux *runtime.ServeMux, server ExampleServiceServer) error { ... } ...</code></pre>Starting the HTTP Server</h2> We have to add two things to our main()</code> function now to connect the HTTP server to the gRPC server. The first thing is we need a gRPC client, which our HTTP server will use to talk to the gRPC server. The HTTP Server accepts incoming requests</li> It converts the request to a gRPC call</li> It uses the gRPC Client that has an open connection to the gRPC Server</li> the gRPC Server invokes the ExampleService function</li> The result is returned to the gRPC Client</li> The HTTP Server transforms the result to a response back to the caller</li> </ol> ┌────────────────────────┐ ┌────────────────────────┐ Request │ HTTP │ │ gRPC │ ──────────► Server │ │ Server │ │ │ │ │ │ │ │ │ │ ┌──────────┐ │ │ │ │ │ gRPC ◄─┼───────────► ┌────────────────┐ │ Response │ │ Client │ │ │ │ ExampleService │ │ ◄─────────┤ └──────────┘ │ │ └────────────────┘ │ │ │ │ │ └────────────────────────┘ └────────────────────────┘</code></pre> cmd/example.go ctx := context.Background() ctx, cancel := context.WithCancel(ctx) defer cancel() // start the gRPC server lis, err := net.Listen("tcp", ":9090") if err != nil { log.Fatalf("failed to listen: %v", err) } grpcServer := grpc.NewServer() protos.RegisterExampleServiceServer(grpcServer, &service.ExampleService{}) go grpcServer.Serve(lis) // dial the gRPC server above to make a client connection conn, err := grpc.Dial(":9090", grpc.WithInsecure()) if err != nil { log.Fatalf("fail to dial: %v", err) } defer conn.Close() // create an HTTP router using the client connection above // and register it with the service client rmux := runtime.NewServeMux() client := protos.NewExampleServiceClient(conn) err = protos.RegisterExampleServiceHandlerClient(ctx, rmux, client) if err != nil { log.Fatal(err) } // create a standard HTTP router mux := http.NewServeMux() // mount the gRPC HTTP gateway to the root mux.Handle("/", rmux) // start a standard HTTP server with the router err = http.ListenAndServe(":8080", mux) if err != nil { log.Fatal(err) }</code></pre> Now we have a service listening on 2 different ports. The gRPC server port is :9090</code> and the HTTP server port is :8080</code>. The routes we have defined in our .proto</code> file can be hit with Postman, cURL, or your favorite REST API tool. The problem now is what do these HTTP request and responses look like in JSON? How do we know what request body to create, and what do the responses contain? This is where another plugin and the Swagger UI comes in to play. Generating the OpenAPI Specification</h2> The last few steps are to pull in another gRPC plugin to generate the OpenAPI Specification JSON file, and then expose that file and the Swagger UI in our HTTP server. Back in the buf.gen.yaml</code> file we add in the last plugin for openapiv2</code>. buf.gen.yaml version: v1 plugins: - name: go out: gen/protos/go opt: paths=source_relative - name: go-grpc out: gen/protos/go opt: - paths=source_relative - name: grpc-gateway out: gen/protos/go opt: - paths=source_relative - name: openapiv2 out: gen</code></pre> Running buf generate</code> again will output a JSON file that contains the OpenAPI Specification of our annotated gRPC service. gen/protos/service.swagger.json { "swagger": "2.0", "info": { "title": "protos/protos/service.proto", "version": "version not set" }, "tags": [ { "name": "ExampleService" } ], "consumes": [ "application/json" ], "produces": [ "application/json" ], "paths": { "/create": { "post": { "operationId": "ExampleService_Create", "responses": { "200": { "description": "A successful response.", "schema": { "type": "object", "properties": {} } }, "default": { "description": "An unexpected error response.", "schema": { "$ref": "#/definitions/rpcStatus" } } }, "tags": [ "ExampleService" ] } }, ...</code></pre> Now we can use this and render the Swagger UI for it, similar to https://generator.swagger.io</a>, but for our generated specification file. To do that, we need to grab the entire dist</code> folder from https://github.com/swagger-api/swagger-ui/tree/master/dist</a> and add it to our repository as swagger-ui</code>. Next, we will modify our HTTP server to have 2 new routes. One for the specification file, and the other for the Swagger UI. cmd/example.go ... // mount the gRPC HTTP gateway to the root mux.Handle("/", rmux) // mount a path to expose the generated OpenAPI specification on disk mux.HandleFunc("/swagger-ui/swagger.json", func(w http.ResponseWriter, r *http.Request) { http.ServeFile(w, r, "./gen/protos/service.swagger.json") }) // mount the Swagger UI that uses the OpenAPI specification path above mux.Handle("/swagger-ui/", http.StripPrefix("/swagger-ui/", http.FileServer(http.Dir("./swagger-ui")))) // start a standard HTTP server with the router err = http.ListenAndServe("localhost:8080", mux) if err != nil { log.Fatal(err) } ...</code></pre> Lastly, we will change the Swagger initializer url</code> to load the swagger.json</code> path we added to our HTTP server. swagger-ui/swagger-initializer.js ... window.ui = SwaggerUIBundle({ url: "swagger.json", // this should be dom_id: '#swagger-ui', ...</code></pre>Play the API with the Swagger UI</h2> Now that everything is wired up, all we need to do is start our service again and then open up http://localhost:8080/swagger-ui</a> in a browser, and we get an interactive Swagger UI to play with. Closing Thoughts</h2> Now that you have the foundation set up, you can expand upon this to build a full fledged gRPC service and continually re-generate the OpenAPI Specification to support HTTP calls, all without compromising or leaving the comfort of your service.proto</code> definition. This stays as the source of truth as you implement the server itself in Go as normal gRPC function calls. You can find the complete example at https://git.sr.ht/~blainsmith/grpc-gateway-openapi-example</a> and if you have any questions feel free to file an issue or contact me any way you're comfortable with. Network Programming with Hare 2022-05-10T00:00:00+00:00 I've been reading It has a fairly small Features of each Listen on an IP and port</li> Accept incoming Accept incoming Log out what data Echo the data back For TCP it should </ul> UDP Since UDP is connectionless use use use export The same basic idea I set up a listener descriptors inside poll</code> use use use use def export Overall, I like Hare. The standard library 40 2022-01-13T00:00:00+00:00 Drew Devault's blog</a> for quite some time. Recently, he and a small team released a new programming language</a> called Hare</a> that is laser focused on systems programming and meant to compete with C, Rust, Zig, but have some of the simple design choices of Go. The biggest differences from Go I can see is Hare's lack of a garbage collector so memory management like C, Rust, and Zig is completely up to you, the programmer and lack of built-in concurrency support. standard library</a> with some additional batteries included for doing a lot of common tasks and so I wanted to see what it could do when compared to Go specifically since that is my main programming language these days. I like to create simple UDP and TCP servers in new languages so see how they stack up against Go in terms of readability and conciseness. server include: connections</li> data from those connection</li> came in and what was the client's IP and port</li> to the client</li> allow for multiple simultaneous client connections</li> Server</h2> the server is pretty straightforward and I don't have to do any multiplexing of client connections. The server just sets up a listener and waits for incoming data, logs it, and writes it back to the client. TCP, however, is much more complicated to handle multiple simultaneous connections. style="color: #BFBDB6; background-color: #0D1017;">use fmt; net::udp; net::ip; strings; fn main() void = { // create a udp listener on the local v4 ip and a port const listener = udp::listen(ip::LOCAL_V4, 8000)!; for (true) { // define buffer to hold incoming data let buf: [1024]u8 = [0...]; // define ip address to hold source of data let src: ip::addr = ip::ANY_V4; // define port to hold source's port of data let port: u16 = 0; // block and wait for incoming data on the listener // and write the buf, src, port accordingly let n = udp::recvfrom(listener, &buf, &src, &port)!; // re-slice the buffer to the length of the // data that came in let buf = buf[..n]; // print out the variables and format the buffer // as a string fmt::printfln("{}:{} says {}", ip::string(src), port, strings::fromutf8(buf))!; // echo it back to the client udp::sendto(listener, buf, src, port)!; }; };</code></pre> TCP Server</h2> is the same as UDP, but in order to handle multiple simultaneous I need to store and hold onto those and periodically check when data is incoming from them. There is a lot of bookkeeping of these connections, but Hare does support poll</code> which allows us to check for activity on those connections. as before, but then I add it to a list of file and start checking for events on all of them. If an event comes in from the listener</code> file descriptor I know it is a new client connection so I add it to the file descriptors for poll</code> to watch. If an event happens on one of the client file descriptors I know it is data incoming so I can read from it, log it, and then write it back to the client. The biggest differences from Go I can see is Hare's lack of a garbage collector so memory management like C, Rust, and Zig is completely up to you, the programmer and lack of built-in concurrency support. style="color: #BFBDB6; background-color: #0D1017;">use net::tcp; net::ip; strings; unix::poll; io; MAX_CLIENTS: u8 = 10; fn main() void = { // create a udp listener on the local v4 ip and a port const listener = tcp::listen(ip::LOCAL_V4, 8000)!; // create a bunch of poll file descriptors and set the first one to the // listener created above let fds: [MAX_CLIENTS]poll::pollfd = [ poll::pollfd { fd = listener, events = (poll::event::POLLIN | poll::event::POLLPRI), ... } ... ]; // fill the rest of the polling file descriptors with empty ones for // clients that want to connect for (let i: size = 1; i < MAX_CLIENTS; i+=1) { fds[i] = poll::pollfd { fd = 0, events = 0, ... }; }; for (true) { // poll all of the file descriptors and block until there is // activity on one of them poll::poll(fds, poll::INDEF)!; // once we get activity check if it was from the first one which // is the listener which means we have a new incoming client connection if (fds[0].revents == poll::event::POLLIN) { // accept the client connection from the listener let conn = net::accept(listener)!; log::println("client conn accepted"); // loop over the remaining file descriptors and find and empty // slot for the client and set the appropriate events to poll for for (let i: size = 1; i < MAX_CLIENTS; i+=1) { if (fds[i].events == 0) { log::printfln("client conn added to position {}", i); fds[i].fd = conn; fds[i].events = (poll::event::POLLIN | poll::event::POLLPRI); break; }; }; }; // lastly loop over all the client file descriptors to check if any // of them have written data for (let i: size = 1; i < MAX_CLIENTS; i+=1) { if (fds[i].events > 0 && (fds[i].revents == poll::event::POLLIN || fds[i].revents == poll::event::POLLPRI)) { // set up a read/write buffer with the client's file // descriptor let rbuf: [1024]u8 = [0...]; let wbuf: [1024]u8 = [0...]; let buffered = bufio::buffered(fds[i].fd, rbuf, wbuf); // attempt to read the line match (bufio::scanline(&buffered)) { // if a line is read then grab the client's ip/port and log out // the data they sent and also echo it back to the client case let line: []u8 => let peer: (ip::addr, u16) = tcp::peeraddr(fds[i].fd) as (ip::addr, u16); fmt::printfln("{}:{} says {}", ip::string(peer.0), peer.1, strings::fromutf8(line))!; io::writeall(&buffered, line)!; bufio::flush(&buffered)!; // if reading the line returns and EOF then we can assume the // client disconnected so we close the file descriptor and reset // the events to open up a slot for a new client to connect to case io::EOF => io::close(fds[i].fd)!; fds[i].events = 0; fds[i].revents = 0; // any other error we reset the events for a new client slot case let err: io::error => fds[i].events = 0; fds[i].revents = 0; }; }; }; }; // shut down the listener if we ever get here net::shutdown(listener); };</code></pre>Thoughts</h2> It writes like Go since a lot of it was inspired by Go, but it's target audience is C, Rust, and Zig programmers who are doing more low level systems programming like sockets, device drivers, and kernels. is pretty complete with all the tools you need to do sorting, crypto, basic encoding, working with files, etc. Some of the extended library packages will get SQL/database support, additional encoding, but they might just stop there. While you could write a REST HTTP API with Hare, it would take a monumental effort to support the HTTP protocol so if this is what you're thinking of doing I would just use Go instead. However, if CPU and safe memory matter then Hare might be a good fit if the other systems programming languages are too unsafe (C) or complex (Rust/Zig) and you need a simple language with fast compile times and good tooling like Go. I guess society celebrates turning 40 as a big milestone birthday. I might have some wisdom, anecdotes, and pithy quotes to share that might serve others well since I've been alive on this big ball of rock for 4 decades. Here are 40 things I've learned during my time here in no particular order: Mental and physical health form a symbiotic relationship. Make both a priority and take care of them.</li> People will move in and out of your life. The ones that stay are the ones worth your time.</li> You can't know everything no matter how much you read and research. Trust the expertise in others.</li> You can disagree with someone, but still be civil and acquaintances. You don't have to be close friends.</li> Social media connections are not friends.</li> Social media feeds off negativity and contention. You are a product and a means to an end for them.</li> A pandemic is a good way to force you to take stock in your life and find out who you really are. You can then change or stay the same.</li> Introverts are not anti-social, they are "pro-quiet".</li> The advice you give when it is asked for isn't required to be heeded, but you can choose to stop giving it.</li> Prioritize your time. There are do-overs, but they take additional time.</li> 40 doesn't have to feel old if you don't want it to be. I am in the best shape of my life competing in powerlifting and strongman with a 600lbs deadlift, 500lbs squat, 300lbs bench, and 200lbs shoulder press. I can carry 200lbs in each hand and go for a walk. All of this strength makes daily life a piece of cake.</li> Stop giving a fuck about things you can't change.</li> Just because you can doesn't mean you should. Solutions that solve pre-existing problems are worth while. Solutions that create artificial problem to solve are meaningless. (See cryptocurrencies, NFT, etc.)</li> "Crypto" is short for "cryptography", not "cryptocurrencies".</li> Social media influencers are just another form of ads.</li> You cannot have a meaningful debate with an ignorant person.</li> Low bar squats and high bar squats serve different purposes and one isn't better than the other.</li> Conventional deadlifts and sumo deadlifts serve different purposes and one isn't better than the other.</li> Training and exercising are different things. Training is planned exercising with a goal. You can exercise all you want, but without a plan it will take longer to reach your goal.</li> Typed languages are better than untyped dynamic languages.</li> JavaScript is a necessary evil.</li> Simpler is better than complex. Start with the former and move to the latter only when needed.</li> SQLite is grossly underestimated.</li> Unless you're Facebook, Google, Amazon, Apple, Netflix, etc. you don't need to promise your users 99.9% or above</a> uptime. Be realistic.</li> Software is rarely every done and left alone. There is always maintenance, patch, and/or feature work to do.</li> Using software as someone in the software field is a rollercoaster of frustration and bliss.</li> Software is a means to an end. Rarely is it center stage anymore since it is becoming a tool to solve problems in other disciplines.</li> Anyone can be a software developer if you write code. Some write more than others in their day to day.</li> Take some time and learn the tools and underlying technology you depend on to do your work. It will bring a new perspective and appreciation to work.</li> Some people are better suited to be managers and some are better suited to be individual contributors.</li> Tools should reduce time and overheard to accomplish work. If they don't then throw it away for something else.</li> "eth" is short for "Ethernet", not "Ethereum".</li> You can't be a good person and work for a bad company.</li> Today's web sucks to browse ever since ad companies got their hands on it with tracking and bullshit JavaScript.</li> Cable TV isn't worth the cost. The content of the shows and the commercials are pure garbage.</li> Help others as much as you can, but if you start feeling used and taken for granted, drop them like a bad habit. People can be very selfish.</li> Coffee should be drank black.</li> Shop the perimeter of grocery stores to get the best possible food to eat. Avoid the aisle. Only exception to this rule is frozen vegetables since they are considerably cheaper than fresh.</li> Problem solving and critical thinking are paramount to any one specific discipline, trade, or profession.</li> 40 years is a long time. 1 year is a long time. A lot can happen in those time frames if your life needs to change.</li> </ol> Onto the next 40 years. Software I'm Thankful For 2021-11-29T00:00:00+00:00 I read David Crawshaw</a>'s recent post about the same topic</a> and I thought it would be nice to do the same. Go</h2> I've always tried to be a polyglot programmer to allow myself to learn and be a well rounded software engineer, but as time went on I realized that specializing in a small set areas is also important. I made a choice to really focus on Go back in 2015 when I was primarily doing Node.js at the time and even though it was a relatively new language and it was risky to bank on it being as popular and as marketable as it is today I felt it was the right move. I am thankful that I was right. While becoming more proficient in the language itself I also became more a more proficient distributed and systems software engineer as well. I was exposed to a lot more complex topics such as lower level CPU and memory management, consensus algorithms, software teams productivity, fundamental networking protocols, and the list goes on. Go even made me return to college</a> to build up my academic understanding of computer science itself. IP & UDP</h2> I read the IP</a> & UDP</a> RFCs periodically to remind myself where parts of the internet started and how simple technology can have such a significant impact. So much of the internet today still relies on these two pillars of technology to allow you to do what you do on the internet today. If you haven't read the RFCs I urge you to do so. Redis</h2> I always enjoy pulling Redis into a project since it feels like a blank canvas when I need to reason about what data I need to store. Relational databases always forced me to think about objects, but Redis always makes me think about data structures. Having the flexibility to store and manipulate data structures felt more freeing when designing a new system or a feature. Connect over a socket and away you go playing with keys, lists, sets, and graphs. SQLite</h2> When I do need a relational database I like to use SQLite to start off with given its simplicity. Since it is just a file on disk there is no network issues or operational overheard that come with running a dedicated database server. The database file can even be backed up via Litestream</a> which is another fantastic piece of technology. Git, GitHub, GitLab, sourcehut, et al.</h2> My background in source control many moons ago was Visual SourceSafe</a> and most recently I've been exposed to Perforce</a> and PlasticSCM</a> which are heavily used in game studios. Git and the code sharing sites still continues to shine when it comes to building software as a group of software engineers with it's distributed model and its diffing capabilities. elementary OS</h2> elementary OS has been a fantasic operating system that reminds me of using a wonderful UI from the macOS days while still having a full Linux system at my fingertips to do anything I need to. I get the best of both worlds with a well supported and great ecosystem of native apps with thoughtful attention to details in their designs while still spending most of my data in Terminal working on what I need to do to ship software. I even start to install it on older systems to revive them and give them to family members instead of recommending they buy a new machine. I really hope this distro has a bright future and is around for a long time as the poster child for what a Linux laptop/deskop should be like for the masses. Twitter</h2> Despite the toxicity that can arise there is still some great parts to it to connect with other like-minded people. I have learned a lot from people I've carefully curated into lists and I even landed a job after seeing a job posting come from a person a friend of mine and I were mutually following. At the end of the day here it has been a great social tool since I've worked at making sure it is a positive environment for myself. How I Write HTTP Clients 2021-11-09T00:00:00+00:00 I have written a lot of HTTP clients that talk to 3rd party APIs over the years and there have been some patterns that have emerged and so I thought I would share them in hopes they help others. The major concepts I want to highlight are: Composing Client Options</li> JSON Encoding/Decoding to Go Types</li> HTTP Request Signing</li> Convenience Methods</li> Binary Readers</li> </ul> To illustrate these concepts I am going to pick through the Infogram Go client I created specifically for this article since one did not exist. Composing Client Options</h2> Most HTTP clients share 3 things in common with each other. They use http.Client</code></a> to make HTTP calls</li> They talk to a base endpoint URL of some kind</li> They require some sort of credentials so the API can authenticate requests</li> </ol> Starting with the Client</code></a> struct we can define what is needed: type Client struct { HTTPClient *http.Client Endpoint string APIKey string APISecret string }</code></pre> This is a pretty common starting point for all HTTP clients and this also allows the user to supply their own http.Client</code></a> and endpoint based on their needs. httpClient := http.Client{ Timeout: 10 * time.Second, } client := infogram.Client( HTTPClient: &httpClient, Endpoint: "https://example.com/infogram", APIKey: "api-key", APISecret: "api-secret", )</code></pre> For convenience, I use sync.Once</code></a> to ensure the first time to Do()</code> is called there is a configured HTTPClient</code> and Endpoint</code> set to avoid nil pointer exceptions and missing endpoints. Another benefit of this approach is making the package easily testable without needing to make HTTP calls over the internet to the Infogram API. I can create a new http.Client</code></a> from a httptest.Server</code></a>. mockInfogramAPIServer := httptest.NewServer(...) defer mockInfogramAPIServer.Close() client := infogram.Client( HTTPClient: mockInfogramAPIServer.Client(), Endpoint: mockInfogramAPIServer.URL, APIKey: "api-key", APISecret: "api-secret", )</code></pre>JSON Encoding/Decoding to Go Types</h2> JSON encoding/decoding is relatively straightforward if you can utilize struct tags, but some times there are other Go types you want to support that do not support JSON encoding/decoding via struct tags out of the box. However, we can implement the JSONMarshaler and JSONUnmarshaler interfaces to support those types. In the case of Infograms API there are some URLs that get returned in the JSON and instead of just keeping them as string</code> types I would like them to be url.URL</code></a> types. // Theme defines the type returned by the Infogram API type Theme struct { Id int Title string Thumbnail *url.URL } // MarshalJSON implements json.Marshaler func (t *Theme) MarshalJSON() ([]byte, error) { data := make(map[string]interface{}) data["id"] = t.Id data["title"] = t.Title data["thumbnail_url"] = t.Thumbnail.String() return json.Marshal(data) } // UnmarshalJSON implements json.Unmarshaler func (t *Theme) UnmarshalJSON(bytes []byte) error { data := make(map[string]interface{}) if val, found := data["id"]; found { v, ok := val.(int) if !ok { return errors.New("id needs to be an int") } t.Id = v } if val, found := data["title"]; found { v, ok := val.(string) if !ok { return errors.New("title needs to be an string") } t.Title = v } if val, found := data["thumbnail_url"]; found { v, ok := val.(string) if !ok { return errors.New("thumbnail_url needs to be an string") } var err error t.Thumbnail, err = url.Parse(v) if err != nil { return errors.New("thumbnail_url needs to be a parsable URL") } } return nil }</code></pre> The Infographic</code></a> type is similar, but I omitted it for brevity. HTTP Request Signing</h2> One of the most common ways to authorize HTTP requests to an API is to specify a token of some kind that the API provides to you. This token is set in one of two places. Query Parameter</li> Authorization HTTP Header</li> </ol> Query Parameter</h3> Merely attaching a predefined query parameter to every call that the API specifies is a simple way to authorize requests. http://exmaple.com/api/v1?api_key=<token></code></pre> The Go way: req, _ := http.NewRequest(http.MethodGet, "http://exmaple.com/api/v1?api_key=<token>", nil)</code></pre>Authorization HTTP Header</h3> The other, more common, method is setting the Authorization HTTP Header with the same token. GET /api/v1 HTTP/1.1 Host: example.com Authorization: Bearer <token></code></pre> The Go way: req, _ := http.NewRequest(http.MethodGet, "http://exmaple.com/api/v1", nil) req.Header.Add("Authorization", "Bearer <token>")</code></pre> While these methods work just fine, there is another method you might come across called request signing. I specifically like to implement this step in its own method to make building and performing requests more composable if the user wants to manipulate more of the http.Request</code></a> itself. The specific rules for request signing depends on the API, but Infogram lists their implmentation</a> to be recreated. // SignRequest adds the `api_key` and `api_sig` query parameter in accordance with https://developers.infogr.am/rest/request-signing.html func (c *Client) SignRequest(req *http.Request) error { var data url.Values switch req.Method { case http.MethodGet, http.MethodDelete: data = req.URL.Query() default: req.ParseForm() data = req.Form } query.Set("api_key", c.apiKey) var sig bytes.Buffer sig.WriteString(req.Method) sig.WriteByte('&') sig.WriteString(req.URL.EscapedPath()) sig.WriteByte('&') ... h := hmac.New(sha1.New, []byte(c.APISecret)) h.Write(sig.Bytes()) signature := h.Sum(nil) data.Add("api_sig", base64.StdEncoding.EncodeToString(signature)) switch req.Method { case http.MethodGet, http.MethodDelete: req.URL.RawQuery = data.Encode() default: req.Form = data } return nil }</code></pre> The result of calling this adds a api_sig</code> query parameter with the signature of the request data signed by the API secret provided by Infogram. Convenience Methods</h2> Now all that is left is the API calls themselves and for that we need to create methods to invoke them. What I like to do is to keep these as small as possible and move as much of the boilerplate logic into their own functions. The main endpoints we need for Infogram follow the same pattern. // Infographics fetches the list of infographics func (c *Client) Infographics() ([]Infographic, error) { // 1. Create Infographics request // 2. Sign the request // 3. Send the request // 4. Decode the response and handle API errors // 5. Return the resulting Go type } // Infographics fetches a single infographic by identification number func (c *Client) Infographic(id string) (*Infographic, error) {...} // Infographics fetches a available themes to use for infographics func (c *Client) Themes() ([]Theme, error) {...}</code></pre> Instead of putting most of the duplicated logic into each function we can create more generic function to handle them like we did with SignRequest()</code> and just call it with the appropriate parameters. func (c *Client) Do(req *http.Request, v interface{}) (*http.Response, error) { req.RequestURI = "" res, err := c.HTTPClient.Do(req) if err != nil { return nil, err } defer res.Body.Close() if res.StatusCode > 299 { _, err := io.ReadAll(res.Body) if err != nil { return nil, err } return res, fmt.Errorf("http error code: %d", res.StatusCode) } if v != nil { if w, ok := v.(io.Writer); ok { io.Copy(w, res.Body) } else { decErr := json.NewDecoder(res.Body).Decode(v) if decErr == io.EOF { decErr = nil // ignore EOF errors caused by empty response body } if decErr != nil { return nil, decErr } } } return res, nil }</code></pre> Do()</code> now handle most of the heavy lifting of preparing requests, sending them, and decoding the API responses. With these functions our convenience methods for each endpoint becomes small and easily repeatable for adding additional endpoints. This also allows to ensure good test coverage over each of the three methods used inside since the convenience methods just call them in a specific order. Notice it also returns the raw http.Response</code> to the caller as well in case that is needed for any reason. I did not want to limit the caller's ability to inspect that response. // Infographics fetches the list of infographics func (c *Client) Infographics() ([]Infographic, error) { req, err := http.NewRequest(http.MethodGet, fmt.Sprintf("%s/%s/%s", c.Endpoint, "infographics", id), nil) if err != nil { return nil, fmt.Errorf("new infographic request: %w", err) } err = c.SignRequest(req) if err != nil { return nil, err } var infographic Infographic _, err = c.Do(req, &infographic) if err != nil { return nil, fmt.Errorf("performing infographics request: %w", err) } return &infographic, nil }</code></pre>Binary Readers</h2> Infogram offers more than just JSON responses to their API. When interacting with the /infographics</code> endpoint specifically you can request to have a PDF, PNG, or HTML version of the infographic returned to you. We can create an io.Reader</code> for each one of these formats for the Infographic</code> type to make this downloading possible. type Infographic struct {...} func (i *Infographic) reader(client *Client, format string) (io.Reader, error) { req, err := http.NewRequest(http.MethodGet, fmt.Sprintf("%s/%s/%s?format=%s", client.Endpoint, "infographics", i.Id, format), nil) if err != nil { return nil, fmt.Errorf("new infographic PDF reader request: %w", err) } err = client.SignRequest(req) if err != nil { return nil, err } res, err := client.HTTPClient.Do(req) if err != nil { return nil, err } return res.Body, nil } // PDFReader returns an io.Reader of the Infographic in PDF format func (i *Infographic) PDFReader(client *Client) (io.Reader, error) { return i.reader(client, "pdf") } // PNGReader returns an io.Reader of the Infographic in PNG format func (i *Infographic) PNGReader(client *Client) (io.Reader, error) { return i.reader(client, "png") } // HTMLReader returns an io.Reader of the Infographic in HTML format func (i *Infographic) HTMLReader(client *Client) (io.Reader, error) { return i.reader(client, "html") }</code></pre> Since these functions are flexible and composable I can do this and still use the SignRequest()</code> after than and then perform a standard http.Client.Do()</code> call and just return the http.Response.Body</code> back to the call to complete the reading of the response to a file, buffer, or anything else that accepts a io.Reader</code>. // get infographic 100 from the API ig100 _ := client.Infographic(100) // get the PDF from the API as an io.Reader ig100reader, _ := ig100.PDFReader(client) // create a local file for the PDF infographic pdf, _ := os.Create("infographic-100.pdf") // copy the results from the API to the local file io.Copy(pdf, ig100reader)</code></pre>Conclusion</h2> Now I have a complete and composable Infogram API client in Go with a clear surface area. client.go // Client is used to interact with the Infogram API type Client struct { HTTPClient *http.Client Endpoint string APIKey string APISecret string } // Do performs the *http.Request and decodes the http.Response.Body into v and return the *http.Response. If v is an io.Writer it will copy the body to the writer. func (c *Client) Do(req *http.Request, v interface{}) (*http.Response, error) {...} // SignRequest adds the `api_key` and `api_sig` query parameter in accordance with https://developers.infogr.am/rest/request-signing.html func (c *Client) SignRequest(req *http.Request) error {...} // Infographics fetches the list of infographics func (c *Client) Infographics() ([]Infographic, error) {...} // Infographics fetches a single infographic by identification number func (c *Client) Infographic(id int) (*Infographic, error) {...} // UserInfographics fetches the list of infographics for the user's identification number func (c *Client) UserInfographics(id string) ([]Infographic, error) {...} // Infographics fetches a available themes to use for infographics func (c *Client) Themes() ([]Theme, error) {...}</code></pre> types.go // Infographic defines the type returned by the Infogram API type Infographic struct {...} // PDFReader returns an io.Reader of the Infographic in PDF format func (i *Infographic) PDFReader(client *Client) (io.Reader, error) {...} // PNGReader returns an io.Reader of the Infographic in PNG format func (i *Infographic) PNGReader(client *Client) (io.Reader, error) {...} // HTMLReader returns an io.Reader of the Infographic in HTML format func (i *Infographic) HTMLReader(client *Client) (io.Reader, error) {...} // MarshalJSON implements json.Marshaler func (i *Infographic) MarshalJSON() ([]byte, error) {...} // UnmarshalJSON implements json.Unarshaler func (i *Infographic) UnmarshalJSON(bytes []byte) error {...} // Theme defines the type returned by the Infogram API type Theme struct {...} // MarshalJSON implements json.Marshaler func (t *Theme) MarshalJSON() ([]byte, error) {...} // UnmarshalJSON implements json.Unmarshaler func (t *Theme) UnmarshalJSON(bytes []byte) error {...}</code></pre> I've had really good luck with designing HTTP clients in Go this way and I hope this helps others as well. You can find the full implementation of the Infogram API Go client</a> on GitHub. I plan to keep iterating on the client more and more so if there is something you see missing or there is a problem feel free to file an issue or submit a change. Why Do You Lift? 2021-08-25T00:00:00+00:00 I get this question a decent amount from people who don't lift and my answers usually consist of: "I spend all day staring at a computer screen and it offers a nice balance to work life behind a desk." </blockquote> "It facinates me what the human body is capable of doing if it is trained and taken care of so I want to see how far I can push it with measureable results." </blockquote> "Because being strong as fuck makes normal life a lot easier like picking up my son, carrying groceries, or any other physical demand life throws at me." </blockquote> "Heart disease runs in both sides of my family so I am stressing my body to adapt to potentially avoid that future." </blockquote> While all of these answers are true I've come to realize another and deeper reason why...If something fails in my training it is entirely my fault. Considering what I do for a living and the dependancies I rely on to do their job whether it is tools or people there is a high probability they will fail and it is out of my control. Laptop blue screens</li> Internet outages</li> Semver contract violations</li> Fragile build systems</li> False promises by people</li> Customer's unplanned context switching</li> Forced inefficient tooling and processes</li> It's not DNS. There's no way it's DNS. It was DNS.</li> </ul> Software engineering is a dicipline of solving hard problems while also dealing with it's own self imposed problems that make things even harder. All of these are out of my control. These systems of dependancies remind me of a house of cards</a> and yet the momentary bliss of solving that hard problem overshadows the days and weeks and months of consistant failures and setbacks. Unfortunately, I cannot fix most of these systems to make my progress more efficient and more enjoyable so I just deal with it...with some venting here and there. Now looking at all of the systems of dependancies involved when I lift their probabolity of failure is effectively zero which makes the only system that would cause a failure is me. I am the only system in control of the entirety of my progress, efficiency, and results. The dependancies I rely on for results out of my control are a barbell made of steel and ball bearings,</li> a steel cage of welded steel posts and cross members,</li> cast iron weights,</li> triple-ply canvas fill with sand,</li> vulcanized rubber weights,</li> and the list goes on.</li> </ul> The failure rate of any of these dependancies is extremely low not only because of their manufacturing process, but also because of their analog and mechanical nature. Since the probabily of failure of these dependancies is zero I can eliminate the cognitive load worrying about these failing and focus solely on myself. I can concern myself with reducing failure in myself by using proper form when lifting, eating appropriately, sleeping consistantly, and recovering accordingly. If any of these are off then my training suffers and the only thing to blame is myself. I and I alone can control and modify my behavior to fix things to get back on track to progress and see results. Spending my professional life wrought with constantly experiencing failures and overcoming them by problems solving it begins to make more sense as to why I lift as much as I do and make it such a priority in my life. "The Iron is the best antidepressant I have ever found. There is no better way to fight weakness than with strength. Once the mind and body have been awakened to their true potential, it’s impossible to turn back. The Iron never lies to you. You can walk outside and listen to all kinds of talk, get told that you’re a god or a total bastard. The Iron will always kick you the real deal. The Iron is the great reference point, the all-knowing perspective giver. Always there like a beacon in the pitch black. I have found the Iron to be my greatest friend. It never freaks out on me, never runs. Friends may come and go. But 200 pounds is always 200 pounds." – Henry Rollins "Iron and the Soul"</a>. </blockquote> Programming is Easy, Software Engineering is Hard 2021-06-15T00:00:00+00:00 Over the years I've been programming and people ask me what I do for a living, I try to explain to them as best I can. Inevitably, they respond with something along the lines of "that sounds very hard and complicated". To someone without programming skills, this sure sounds hard. To me, performing open heart surgery sounds hard, but to a seasoned surgeon, I am sure it is like riding a bike. Sure, there may be challenges in the middle of these tasks that need to be addressed, but the training acquired should be enough to work through those challenges. Anyone with the proper skills can: implement Quicksort in any language;</li> read and understand the SHA-512 algorithm;</li> write a REST or GraphQL API that connects to a SQL or NoSQL database with a proper caching strategy</li> utilize a matchmaking algorithm, like TrueSkill or Openskill, to properly match people together based on skill level;</li> track statistics that are computed in near real time to update a leaderboard;</li> write an authorization service which validates some combination of credentials using security industry best practices such as password hashing, randomization, and data encryption.</li> </ul> These are varying degrees of difficulty based on skill level, but at the end of the day, programming by itself is largely an easy thing for most of us to do. We are good at it and we educated ourselves by learning new techniques, languages, and concepts to solve these complex problems. If left to our own devices, we all could build a very stable and successful solution. However, programming does not become stressful, frustrating, and downright hard until we factor in two more variables...time and other people. "Software engineering is what happens to programming when you add time and other programmers." -Russ Cox on "What is Software Engineering?"</a> </blockquote> Russ hit the nail on the head when he was using this to explain the reason why Go needed module support, but this also holds true in the larger context of what we all do day in and day out. I would like to amend that quote to be: Software engineering is what happens to programming when you add time and other PEOPLE. </blockquote> The people I am referring to here are managers, stakeholders, investors, SCRUM masters, sales people, marketing people, the list goes on. So now, we should circle back and address the solutions above. We can take into account the plethora of other people involved who impose time constraints on problems of which they do not have complete understanding. Not only are we no longer just programming, we are engineering software systems that need to fit neatly within an arbitrary box, that was not chosen by us even if we may be able to influence that box size. 9 times out 10, our influence over those constraints will not help if we are up against another agenda driven by time, other people, and money. Can you create a websocket service to accept 1 million concurrent connections to broker messages to multiple internal services? I am sure you can, but now consider doing it within 3 weeks and having to sit in on 5 hours of meetings per week over those same 3 weeks. Can you get a 50 node Kubernetes cluster up and running on bare metal? Sure, but how about you also do sprint planning and retro meetings every 2 weeks while also onboarding a new hire that joined your team? What we do now is no longer focused on technical problems, which we know fully well how to solve, but now there are other non-deterministic and uncontrollable factors mixed into that task. Now things are stressful, frustrating, and downright hard. The daily juggling of context switching, meetings, cost/benefit analysis, personality differences, time constraints, priority changes, and anything not involved in programming is what makes what we do hard. The sooner everyone involved (not just programmers) understand this, the better off we all will be. Hugo to Zola 2021-03-06T00:00:00+00:00 I managed to switch my site over to using Zola</a>. It was very tempting since the template engine looked a lot simpler than Hugo</a>. It took me about 3 hours to figure out how to map each of the Hugo features to the Zola equivalent. I've included the diff from the both versions for comparison. You can see that zola requires a lot less boilerplate and template files to achieve the same result which I was very happy with. > git diff hugo..zola --compact-summary .build.yml | 5 ++-- LICENSE.md => LICENSE | 0 Makefile (gone) | 5 ---- README.md (mode -x) | 0 config.toml | 53 +++++++++++++---------------------------- content/articles/3-years-at-madglory.md | 13 ++++------ content/articles/_index.md (new) | 7 ++++++ content/articles/build-it-live-nasa-video-app.md | 9 ++++--- content/articles/case-insensitive-sorting-in-mongo-db.md (gone) | 46 ------------------------------------ content/articles/convention-over-configuration-web-servers.md | 8 +++---- content/articles/easy-profiling-go-benchmark-tests-with-bash.md | 8 +++---- content/articles/encoding-images-with-go-for-the-ssd1306-oled.md (gone) | 34 -------------------------- content/articles/farewell-to-harvard-and-onward-to-madglory.md | 8 +++---- content/articles/fuck-your-hustle.md | 8 +++---- content/articles/go-go-import-container-list.md | 8 +++---- content/articles/go-made-me-return-college.md | 8 +++---- content/articles/gophercon-2017-generating-hundreds-of-video-catalog-feeds-in-seconds.md | 8 +++---- content/articles/i-love-my-fear.md (gone) | 21 ----------------- content/articles/linux-system-metrics-with-collectd.md | 8 +++---- content/articles/plain-text-protocols.md | 8 +++---- content/articles/quick-and-dirty-local-domain-names-for-mamp.md (gone) | 73 -------------------------------------------------------- content/articles/reverting-back-to-a-simpler-time.md | 8 +++---- content/articles/sharatoga-techtalks-git-a-free-highly-scaled-web-host.md (gone) | 14 ----------- content/articles/side-projects.md | 8 +++---- content/articles/signing-jwts-with-gos-crypto-ed25519.md | 8 +++---- content/articles/single-command-static-file-web-server.md | 8 +++---- content/articles/tedxalbany-the-master-of-my-fate.md | 9 ++++--- content/articles/the-20-year-5-school-bachelors-degree.md | 8 +++---- content/articles/vpscheapnet-review-for-the-server-savvy.md (gone) | 71 ------------------------------------------------------- content/articles/writing-a-web-server-in-go-without-dependancies.md | 10 ++++---- content/book-recs/_index.md (new) | 26 ++++++++++++++++++++ content/book-recs/a-philosophy-of-software-design.md (gone) | 5 ---- content/book-recs/a-programmers-introduction-to-mathematics.md (gone) | 5 ---- content/book-recs/neurotribes.md (gone) | 5 ---- content/book-recs/the-atheists-guide-to-reality.md (gone) | 5 ---- content/book-recs/the-coddling-of-the-american-mind.md (gone) | 5 ---- content/book-recs/the-elements-of-programming-style.md (gone) | 5 ---- content/book-recs/zen-and-the-art-of-motorcycle-maintenance.md (gone) | 5 ---- content/favicon.ico (gone) | Bin 1150 -> 0 bytes content/go/_index.md (new) | 5 ++++ content/go/baconian-cipher.md | 13 ++++++---- content/go/goreds.md | 13 ++++++---- content/go/seahash.md | 13 ++++++---- content/go/shardcache.md | 13 ++++++---- layouts/book-recs/list.html (gone) | 22 ----------------- layouts/for-sale/list.html (gone) | 15 ------------ layouts/for-sale/single.html (gone) | 6 ----- layouts/go/list.html (gone) | 17 ------------- layouts/go/single.html (gone) | 12 ---------- {themes/text-only/static => static}/favicon.png | Bin templates/article.html (new) | 14 +++++++++++ templates/articles.html (new) | 9 +++++++ templates/base.html (new) | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ templates/go-package.html (new) | 12 ++++++++++ templates/go-packages.html (new) | 13 ++++++++++ templates/index.html (new) | 10 ++++++++ templates/section.html (new) | 11 +++++++++ themes/text-only/archetypes/default.md (gone) | 2 -- themes/text-only/layouts/404.html (gone) | 5 ---- themes/text-only/layouts/_default/single.html (gone) | 17 ------------- themes/text-only/layouts/index.html (gone) | 14 ----------- themes/text-only/layouts/index.rss.xml (gone) | 26 -------------------- themes/text-only/layouts/partials/footer.html (gone) | 13 ---------- themes/text-only/layouts/partials/header.html (gone) | 33 -------------------------- themes/text-only/layouts/partials/styles.html (gone) | 100 ----------------------------------------------------------------------------- themes/text-only/static/favicon.ico (gone) | Bin 1150 -> 0 bytes themes/text-only/theme.toml (gone) | 6 ----- 67 files changed, 374 insertions(+), 727 deletions(-)</code></pre> Easy Profiling Go Benchmark Tests with Bash 2021-02-18T00:00:00+00:00 Update: This idea got popular enough that I decided to turn it into a tool. You can grab it from http://pprof.sh</a>. There are a lot of great articles on the interwebs about profiling entire Go applications for CPU and memory usage, however I can never remember the syntax for doing the same thing for specific Benchmark-prefixed tests. Editors have great support for running these tests, but sometimes I want to be able to produce binary and profile output files to open in the visualizer for further inspection. So like any lazy programmer I made a few scripts to do all the work for me. bench.sh #!/bin/sh if [ $# -eq 0 ] then printf "Runs a specified benchmark test func and opens the profile in Chrome.\n\n" printf "Usage:\n" printf "\t./bench.sh <cpu|mem> <dir> <function>\n\n" printf "Example:\n" printf "\t./bench.sh cpu ./internal BenchmarkBinaryEncoding\n\n" exit 0 fi go test -bench=${3} -benchmem -${1}profile profile.out -o bench.test ${2} go tool pprof -http=:6060 bench.test profile.out</code></pre> trace.sh #!/bin/sh if [ $# -eq 0 ] then printf "Runs a specified benchmark test func and opens the trace profile in Chrome.\n\n" printf "Usage:\n" printf "\t./trace.sh <dir> <function>\n\n" printf "Example:\n" printf "\t./trace.sh ./internal BenchmarkBinaryEncoding\n\n" exit 0 fi go test -bench=${2} -trace trace.out -o trace.test ${1} go tool trace -http=:6060 trace.test trace.out</code></pre> Lets consider a sample Go project layout that looks something like the following: my-go-project/ ├─ cmd/ │ ├─ server/ │ │ ├─ main.go ├─ internal/ │ ├─ encoding.go │ ├─ encoding_bench_test.go │ ├─ encoding_test.go ├─ scripts/ │ ├─ bench.sh │ ├─ tests.sh │ ├─ trace.sh ├─ go.mod ├─ go.sum ├─ README.md</code></pre> Inside the internal directory there is encoding_bench_test.go which has a benchmark function called BenchmarkBinaryEncoding that we want to profile. ./internal/encoding_bench_test.go package internal_test ... func BenchmarkBinaryEncoding(b *testing.B) { ... } ...</code></pre> You can see we placed bench.sh and trace.sh inside the scripts folder so we can run it from the root of the project and see the help menu. my-go-project on master via Go v1.16 > ./scripts/bench.sh Runs a specified benchmark test in app's package and opens the profile in Chrome. Usage: ./bench.sh <cpu|mem> <dir> <function> Example: ./bench.sh cpu ./internal BenchmarkBinaryEncoding</code></pre> Running it with the correct arguments will perform the following: Run the benchmark test BenchmarkBinaryEncoding within the internal package and capture the cpu|memory profile</li> Write a test binary and profile file to disk</li> Launch the profiler visualizer on port :6060 with test binary and profile</li> </ol> Now let's run the BenchmarkBinaryEncoding function in the internal package. my-go-project on master via Go v1.16 > ./scripts/bench.sh cpu ./internal BenchmarkBinaryEncoding goos: linux goarch: amd64 pkg: my-go-project/internal cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz BenchmarkBinaryEncoding-8 567564 1916 ns/op 979 B/op 3 allocs/op PASS ok my-go-project/internal 2.047s Serving web UI on http://localhost:6060</code></pre> At this point the browser should open automatically so you can poke around the CPU profile. Once you are done you can close the browser and quit the bash process and go about your business. The trace.sh script operates the same way as bench.sh, but it opens the trace visualizer in the browser. my-go-project on master via Go v1.16 > ./scripts/trace.sh ./internal BenchmarkBinaryEncoding goos: linux goarch: amd64 pkg: my-go-project/internal cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz BenchmarkBinaryEncoding-8 567564 1916 ns/op 979 B/op 3 allocs/op PASS ok my-go-project/internal 2.047s 2021/02/18 13:17:50 Parsing trace... 2021/02/18 13:17:51 Splitting trace... 2021/02/18 13:17:51 Opening browser. Trace viewer is listening on http://[::]:6060</code></pre> I found these scripts to be super helpful to reduce the feedback loop of changing code and running a benchmark to see if things changed. I hope this helps you as much as it has helped me in my day-to-day work and if there are things that can be improved please reach out and let me know. Happy pprof-ing! Plain Text Protocols 2020-09-01T00:00:00+00:00 If you haven't noticed already I really love plain text so I thought I would find some plain text protocols that are used in different software systems. The Redis Protocol specification states it best by describing its own protocol, but this applies to all of the plain text protocols I will cover. Simple to implement.</li> Fast to parse.</li> Human readable.</li> </ul> The next time you are building a software system and have to exchange data start with using a simple plain text protocol and then add in the complexity for optimization later. All of these protocols can be sent as plain text data over a TCP or UDP. They are easily inspected, small, and direct. Graphite plaintext protocol</h1> Starting off with the simplest one in the list is the Graphite plaintext protocol for delivering metrics into Graphite via Carbon. The protocol: <metics_path> <metics_value> <metrics_timestamp></code></pre> The example: /cpu_load/core_0 0.08 1599009388 /cpu_load/core_1 0.07 1599009388 /cpu_load/core_2 0.07 1599009388 /cpu_load/core_3 0.05 1599009388</code></pre> Full Specification</a> Influx Line Protocol</h1> The next simplest one in the list is the Influx Line Protocol. While this is similar to Graphite it does add some additional metadata to its specification. The protocol: <measurement>[,<tag_set>...] <field_set>... <timestamp></code></pre> The example: cpu,core=0 load=0.08 1599009388 cpu,core=1 load=0.07 1599009388 cpu,core=2 load=0.07 1599009388 cpu,core=3 load=0.05 1599009388</code></pre> Full Specification</a> Redis Serialization Protocol (RESP)</h1> Here is where things get more complex, but the same 3 characteristics from above apply still. Simplifying the protocol for the sake of brevity in this article we see that the protocol is a single line of text and the initial command dictates what argument data types are allowed after it. The protocol: COMMAND arguments...</code></pre> The example: GET key1 SET key2 100 HSET hash key1 value1 HGETALL hash</code></pre> There is more to this particular protocol to denote strings, numbers, arrays, etc in a text format which is outlined in the official specification. Full Specification</a> Hypertext Transfer Protocol (HTTP)</h1> Yes, HTTP is just plain text. Since the protocol itself has lots of permutations of metadata lets just look at some examples of an HTTP request and response. The request example: GET /articles/plain-text-protocols/ HTTP/1.1 Host: blainsmith.com Accept-Language: en-us Accept-Encoding: gzip, deflate</code></pre> The response example: HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 6262 Content-Type: text/html; charset=utf-8 Date: Wed, 02 Sep 2020 01:41:35 GMT Last-Modified: Wed, 02 Sep 2020 01:37:33 GMT <THE HTML OF THIS ARTICLE></code></pre> Your browser constructs the request when you visit http://blainsmith.com/articles/plain-text-protocols/ and parses the response when it comes back from the server. There are a lot more allowable headers, but the basics of this protocol are pretty straightforward. Full Specification</a> Keep it simple</h1> The world runs on these types of plain text protocol so don't reinvent the wheel if you find yourself building a software system and there is an existing protocol available. If there is an existing plain text protocol that you can adapt to your purposes then do that since there might be a library available already to serialize and deserialize the protocol so you don't have to write your own. If any of these protocols do not fit your needs and you need to write your own then keep it simple. If everyone's web browsers are using HTTP which has worked for decades there is no reason for you to create a complicated protocol unless your can prove the need to otherwise. Additional Protocols</h1> StatsD</a></li> collectd</a></li> File Transfer Protocol (FTP)</a></li> Simple Mail Transfer Protocol (SMTP)</a></li> Finger user information protocol</a></li> Memcached</a></li> </ul> Reverting Back to a Simpler Time 2020-06-23T00:00:00+00:00 Every since the world started shutting down when COVID-19 hit I've been finding myself reverting back to simpler things. With the constant firehose of information from the news channels, social feeds, and just general information overload I've been burning out on almost a weekly basis. It sucks and I am tired. I recognize that my personal issues with all of this pales in comparison with what other people are going through in this world. However, if I am not operating at a healthy mental level then not only can I not help myself, but I cannot help others. At the end of day all that really matters is being happy and trying to help others as we spin around this ball of water and rock to make a life worth living with the time we have. My approach to fixing this for myself is essentially reverting everything I do to simpler versions to reduce the cognitive load and allow my brain to recover. Leaving social media, except Instagram (I interact with my powerlifting coach there)</li> Reducing my public profile on GitHub/Gitlab and moving to sourcehut</li> Leaving most Slack groups I am in</li> Leaving my computer off outside of 8:00 AM - 4:00 PM EST</li> Catching up on news a few times a week to still be a well informed citizen</li> Read non-technical books for pleasure</li> Spend more time with human beings in person</li> </ol> Social media like Twitter and LinkedIn have been great for so long, but now they have just become overly political streams of consciousness that is just overwhelming. The software we all write has direct political impact and we need to recognize that, but Twitter swings to the extremes a lot and I find it hard to follow so it is personally best for me to remove myself from it. LinkedIn generally doesn't suffer from too much politics, but it does suffer from overly marketed and fake bullshit that just gets on my nerves. The "visionaries", "thought leaders", and "startup hustlers" are far too common now and it is best we agree to disagree and part ways. These anti-social media platforms have now done more harm than good and they are not worth it anymore. GitHub/Gitlab provide a great platform for code sharing and fostering the open source idea. There was a time in my life where I wanted to contribute to open source as much as possible, but as time went on and I starting having more important things in my life outside of coding I realized a commitment to open source would eat into the rest of my life. This prompted me to start archiving and moving my public repos. I will still hack around on things when I feel like it, but I will not advertise I am doing so as much anymore so I can keep them personal. I know I have a big dependency on Google for my phone, email, etc. so this will come off a hypocritical, but I also feel like I need to move to more ethical software choices from here on out. Someday I hope to look back on my software choices and my uses for them and be happy not regret supporting ones that were involved in questionable ethical and political practices. So far I am happy with my choices of Linux for my daily operating system, Signal for messaging, and now sourcehut for source control. Everything else is pure fluff that I haven't gotten value out of in a long time so it is time to remove it. This isn't a goodbye, but is it is me reverting back to simpler times. Email me, call me, text me, and read this blog (text only with no tracking) for tech things I experiment with. Any code worth sharing will end up on sourcehut, but I make not promises to accept patches or support bug fixes in any way if you choose to use it. Talk to you later. The 20 Year 5 School Bachelor's Degree 2020-05-10T00:00:00+00:00 Well, my undergraduate career is finally over. Rensselaer Polytechnic Institute</h2> I was fortunate enough to get accepted to my first choice back in 2000 when I graduated high school. Unfortunately, however, it wasn't without its speed bumps. I had received the Rensselaer Medal prior to receiving my acceptance letter so when I got notified I was awarded the scholarship I assumed my acceptance letter was just around the corner. As it turned out, I was wrong. I actually got officially rejected at first. Naturally I was very confused since I was awarded an academic scholarship to a school that rejected my admission. My mother ended up calling the school while I was in my high school and they told her they had made a mistake. They sent me the wrong letter. I had been accepted all along. I spent about a year attending Rensselaer until I came to the realization I was not personally ready for college life. I was still mentally unprepared and immature to be on my own 3 hours away from my home town with no mode of transportation for myself. I ended up leaving Rensselaer at the end of my freshman year to move back home and chose a school closer to home in Worcester, MA. Worcester Polytechnic Institute</h2> My next attempt at college was closer to home and with being allowed a vehicle on campus I had the freedom to move around as I pleased. Home was now only 45 minutes away so I could head back whenever I needed to. Knowing that choice was available made studying a lot easier to focus on. However, this college attempt was met with not only going through 9/11 my first year there, but also contracting mononucleosis, commonly known as "mono", my second year there. This put me behind in school work and required me to undergo surgery over the summer to have my tonsils removed. After playing lots of catch up and realizing I was paying a lot of money per course for content I was just buying books on Amazon to learn I decided to end pursuing my degree in Computer Science and focus on a degree that justified the high-priced tuition to be taught in a classroom. Bentley College</h2> Third time is a charm right? Bentley College is more known for its business and information technology curriculum which sounded like a better choice given the state of the world at this point. I thought I would focus more on a business oriented technical degree since at lot of the statistics for graduates with Computer Science degree showed their salaries dropped significantly. With mounting student load debt it made more sense to change to another degree to be more marketable when I graduated to pay back the ever increasing loans. As it turns out I hated the business side of technology. My heart was more in the scientific side, but it wasn't marketable in my area so I made a very hard to decision to drop out of college completely. I couldn't justify taking out more money for an education I hated doing. Harvard University</h2> After working for a few years for a local technology startup I ended up being laid off for financial reasons. Interview after interview yielded nothing I cared for or I was not the right fit. Eventually I came across an ad in Craigslist that ended up being posted by a recruiter. They told me it was for Harvard University. After my last position I thought it would be a smart move to focus on this one as much as I could. They would certainly not go out of business for lack of finances. On top of that I learned that employees got the added perk of taking courses for a ridiculous discount. Sounded like a win/win. Work for one of the most prestigious universities in the US and continue my college career part time at a discount. So that is what I did. I spent almost 5 years chipping away at my degree one course at a time each semester. Unfortunately, on two different occasions, the graduation requirements changed which forced me to take more classes than I anticipated to meet the graduation requirements. During this whole time I was getting older and my life was changing. I had moved to upstate New York and start building a life there while trying to finish online classes. A new job opportunity presented itself to work for a company locally and really put down roots where I lived so, again, I made the choice to drop out of college completely to work and live my life accepting the fact I will never end up with my degree. SUNY Empire State College</h2> Fast forwarding a lot of years and a few different jobs I ended up leaning a new programming language, Go, which piqued my interest in going back to college for Computer Science</a>. At this stage of my life as a father to an autistic son and a working professional as a software engineer I didn't have the time or the means to just stop all of that and return to college full time taking classes during the day. I set out to find a college that accommodated working adult professionals. As it turns out SUNY Empire State College is essentially in my back yard only 10 minutes from my house and their focus is offering degree programs online for adults. This sounded like a perfect choice for someone like me. I spent the next 3 years taking all the final classes I needed to achieve a Bachelor's Degree in Computer Science. While there were some classes I could have taken in my sleep I pushed through since I could see the light at the end of the very very long tunnel I entered 20 years ago as an 18 year old kid. Now that this part of my life has finally come to an end I have come out the other end with a renewed vigor for academic learning to augment the Computer Science knowledge I have. Master's Degree, Certificates, Courses?</h2> I am still doing as much research a possible, but I do think that I won't stop taking courses in some fashion. The more I pay attention to where the world is headed with respect to technology and computers the more I realize that coding, software engineering, and computer science is only part of the puzzle. Picking up topics in mathematics, physics, material sciences, and other engineering disciplines will only strengthen my understanding and capacity to solve more complex problems in my career as a software engineer. Physicists, mathematicians, and engineers are starting to leverage coding and software engineering principals to do their job so it would be advantageous of me to learn parts of their primary disciplines to do mine. While I do spend most of my time solving problems in the video gaming and entertainment space; having other points of view would make me a more well rounded software engineer to apply those problems solving skills to new and exciting projects. Signing JWTs with Go's crypto/ed25519 2019-12-07T00:00:00+00:00 The crypto/ed25519</a> package was added to the standard library in Go 1.13</a>. This package implements the Ed25519</a> Edwards-curve Digital Signature Algorithm. It offers significant speed and security improvements over RSA and it makes for a perfect signing method for JWTs. Unfortunately, the most popular JWT library for Go</a> does not natively support it yet. It only supports ECDSA, HMAC, RSA, and RSAPSS, however, it is trivial to extend the package and satisfy the interface (github.com/dgrijalva/jwt-go).SigningMethod</a> for EdDSA. Implementing (github.com/dgrijalva/jwt-go).SigningMethod</h2> type SigningMethodEd25519 struct{} func (m *SigningMethodEd25519) Alg() string { return "EdDSA" } func (m *SigningMethodEd25519) Verify(signingString string, signature string, key interface{}) error { var err error var sig []byte if sig, err = jwt.DecodeSegment(signature); err != nil { return err } var ed25519Key ed25519.PublicKey var ok bool if ed25519Key, ok = key.(ed25519.PublicKey); !ok { return jwt.ErrInvalidKeyType } if len(ed25519Key) != ed25519.PublicKeySize { return jwt.ErrInvalidKey } if ok := ed25519.Verify(ed25519Key, []byte(signingString), sig); !ok { return ErrEd25519Verification } return nil } func (m *SigningMethodEd25519) Sign(signingString string, key interface{}) (str string, err error) { var ed25519Key ed25519.PrivateKey var ok bool if ed25519Key, ok = key.(ed25519.PrivateKey); !ok { return "", jwt.ErrInvalidKeyType } if len(ed25519Key) != ed25519.PrivateKeySize { return "", jwt.ErrInvalidKey } // Sign the string and return the encoded result sig := ed25519.Sign(ed25519Key, []byte(signingString)) return jwt.EncodeSegment(sig), nil }</code></pre> In order to work with the JWT methods above we need to have a (crypto/ed25119).PrivateKey</a> and (crypto/ed25119).PublicKey</a> loaded into our application to sign and verify tokens. For this case we will assume these keys are in PEM format and we can load them in from a file or environment varible. Private and Public Keys in PEM Format</h2> These are strings converted to []byte which is needed by (encoding/pem).Decode()</a>. privateKeyPEM := []byte(`-----BEGIN PRIVATE KEY----- MC4CAQAwBQYDK2VwBCIEIEFMEZrmlYxczXKFxIlNvNGR5JQvDhTkLovJYxwQd3ua -----END PRIVATE KEY-----`) publicKeyPEM := []byte(`-----BEGIN PUBLIC KEY----- MCowBQYDK2VwAyEAWH7z6hpYqvPns2i4n9yymwvB3APhi4LyQ7iHOT6crtE= -----END PUBLIC KEY-----`)</code></pre> We have to parse these from their string format into actual (crypto/ed25119).PrivateKey and (crypto/ed25119).PublicKey types. We only have to do this once when our application starts up and we can pass these keys around to the functions that need them to do signing and verifying. Decoding the Private Key</h2> type ed25519PrivKey struct { Version int ObjectIdentifier struct { ObjectIdentifier asn1.ObjectIdentifier } PrivateKey []byte } var block *pem.Block block, _ = pem.Decode(privateKeyPEM) var asn1PrivKey ed25519PrivKey asn1.Unmarshal(block.Bytes, &asn1PrivKey) privateKey := ed25519.NewKeyFromSeed(asn1PrivKey.PrivateKey[2:])</code></pre>Decoding the Public Key</h2> type ed25519PubKey struct { OBjectIdentifier struct { ObjectIdentifier asn1.ObjectIdentifier } PublicKey asn1.BitString } var block *pem.Block block, _ = pem.Decode(publicKeyPEM) var asn1PubKey ed25519PubKey asn1.Unmarshal(block.Bytes, &asn1PubKey) publicKey := ed25519.PublicKey(asn1PubKey.PublicKey.Bytes)</code></pre> Now that we have implemented the (github.com/dgrijalva/jwt-go).SigningMethod and have a (crypto/ed25519).PrivateKey and (crypto/ed25519).PublicKey we can put this all together to sign and verify JWTs. var Ed25519SigningMethod SigningMethodEd25519 jwt.RegisterSigningMethod(Ed25519SigningMethod.Alg(), func() jwt.SigningMethod { return &Ed25519SigningMethod }) token := jwt.NewWithClaims(&Ed25519SigningMethod, jwt.StandardClaims{ IssuedAt: time.Now().Unix(), Issuer: "urn:ed25519-jwt", Subject: "[email protected]", }) jwtstring := token.SignedString(privateKey) fmt.Println(jwtstring) // Outputs: eyJhbGciOiJFRDI1NTE5IiwidHlwI... token, _ := jwt.Parse(jwtstring, func(token *jwt.Token) (interface{}, error) { return publicKey, nil }) fmt.Println(token.Issuer, token.Subject) // Outputs: urn:ed25519-jwt [email protected]</code></pre> The jwtstring</code> can be used by clients to verify their identity as any other JWT, but now we are using Ed25519 for signing and verifying tokens like you can with RSA. The https://jwt.io</a> website is a great tool for working with JWTs and you can see other libraries that support different signing methods. Since Ed25519 is fairly new you will notice that a lot are missing the "EdDSA" algorithm, but now you can at least implement this yourself with not a lot of code or importing a 3rd party dependency. Linux System Metrics with collectd 2018-08-03T00:00:00+00:00 This tutorial assumes you have the following software installed. https://collectd.org</a></li> https://www.docker.com</a></li> </ul> collectd is a general purpose system metrics collection tool that supports various plugins for reading metrics from sources and writing results to destinations. Multiple sources can be read and then written to multiple destinations which makes collectd very flexible. For example, you can collect CPU, Memory, and Load information and write those results every 10ms to CSV, Redis, and RDD (we will get to that). For this tutorial we will be collecting very basic system metrics and writing them to a few output formats. We will set up collectd to monitor and store the following metrics. CPU usage</li> CPU temperature</li> Load</li> Memory (virtual and swap)</li> Disk</li> Battery</li> </ul> Each of these metrics above represent a read plugin in collectd and each can be configured separately. We will assume the defaults though. Then we will set up collectd to write to the following output formats. RDD (TL;DR efficient binary data format made for collecting time series data in a ring buffer)</li> CSV</li> </ul> Each of these metrics above represent a write plugin in collectd and each can be configured separately. There is a full list of plugins</a> available on the collectd wiki. Configure collectd</h2> The default path collectd keeps its configuration file is in /etc/collectd/collectd.conf</code>. We need to edit this file to set up the plugins we want to use. $ cd /etc/collectd # Create a backup of the default configuration $ cp collectd.conf collectd.default.conf</code></pre> Open /etc/collectd/collectd.conf</code> in your preferred editor and overwrite it with the following: # This tells collectd to lookup the hostname for storing data # in a folder with that name FQDNLookup true # This is the read interval in milliseconds Interval 5000 # Load the syslog plugin LoadPlugin syslog # Configure the syslog plugin to log only errors <Plugin syslog> LogLevel error </Plugin> # Load the following plugins for collectd to read/write with LoadPlugin battery LoadPlugin cpu LoadPlugin csv LoadPlugin disk LoadPlugin load LoadPlugin memory LoadPlugin rrdtool LoadPlugin swap LoadPlugin thermal # Configure the csv plugin <Plugin csv> DataDir "/var/lib/collectd/csv" StoreRates true </Plugin> # Configure the rrdtool plugin <Plugin rrdtool> DataDir "/var/lib/collectd/rrd" </Plugin></code></pre> Save the file and now we have a minimal configuration. Running collectd</h2> If you installed collectd via a package manager then chances are there will be a SystemD service available to use. # Start the collecd system service $ sudo systemctl start collectd</code></pre> collectd should now be running and collecting metrics and writing data to the folders specified in the configuration file. Verify collectd</h2> We set up the CSV plugin to verify we are collecting information since the RDD plugin can't be read by humans. CSV is easier to read via the command line. # View some metrics $ cd /var/lib/collectd # List the host folders, the folder name will differ on your machine $ ls -lah total 12K drwxr-xr-x 3 root root 4.0K Aug 13 11:13 ./ drwxr-xr-x 4 root root 4.0K Aug 13 11:13 ../ drwxr-xr-x 44 root root 4.0K Aug 13 11:14 pop-os.localdomain/ $ cd pop-os.localdomain $ ls -lah total 176K drwxr-xr-x 44 root root 4.0K Aug 13 11:14 ./ drwxr-xr-x 3 root root 4.0K Aug 13 11:13 ../ drwxr-xr-x 2 root root 4.0K Aug 13 11:13 battery-0/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-0/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-2/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-3/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-4/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-5/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-6/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 cpu-7/ d--xrwxrwx 2 root root 4.0K Aug 13 11:15 disk-dm-0/ d--xrwxrwx 2 root root 4.0K Aug 13 11:15 disk-dm-1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-dm-2/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop0/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop2/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop3/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop4/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop5/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-loop6/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-nvme0n1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-nvme0n1p1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-nvme0n1p2/ d--xrwxrwx 2 root root 4.0K Aug 13 11:15 disk-nvme0n1p3/ d--xrwxrwx 2 root root 4.0K Aug 13 11:14 disk-nvme0n1p4/ drwxr-xr-x 2 root root 4.0K Aug 13 11:13 load/ drwxr-xr-x 2 root root 4.0K Aug 13 11:13 memory/ drwxr-xr-x 2 root root 4.0K Aug 13 11:13 swap/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device0/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device2/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device3/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device4/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device5/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device6/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device7/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-cooling_device8/ drwxr-xr-x 2 root root 4.0K Aug 13 11:13 thermal-cooling_device9/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-thermal_zone0/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-thermal_zone1/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-thermal_zone2/ d--xrwxrwx 2 root root 4.0K Aug 13 11:13 thermal-thermal_zone3/</code></pre> You can see how the metrics are actually being stored on disk. The RDD plugin has a similar folder structure under /var/lib/collectd/pop-os.localdomain/rdd</code> which you can browse as well. # View system load $ cd load/ # You will have different filenames here with a different date $ cat load-2018-08-13 epoch,shortterm,midterm,longterm 1534182073.078,0.500000,0.550000,0.430000 1534182083.078,0.660000,0.580000,0.440000 1534182093.078,0.560000,0.560000,0.440000 1534182103.078,0.550000,0.560000,0.440000 1534182113.078,0.700000,0.590000,0.450000 1534182123.078,0.830000,0.620000,0.460000 1534182133.078,0.700000,0.600000,0.460000 1534182143.078,0.670000,0.600000,0.460000 1534182153.078,0.560000,0.580000,0.450000 1534182163.078,0.480000,0.560000,0.450000 1534182173.078,0.640000,0.590000,0.460000 1534182183.078,0.540000,0.570000,0.450000 1534182193.078,0.780000,0.620000,0.470000 1534182203.079,0.660000,0.600000,0.470000 1534182213.078,0.640000,0.590000,0.470000 1534182223.078,0.540000,0.570000,0.460000</code></pre> Now we see the load information collectd has been collecting on the interval we have specified. For this example I have 10ms specified for the interval to show more data. The corresponding RDD binary file is at /var/lib/collectd/rdd/pop-os.localdomain/load/load.rdd</code> which we will use for the UI in the next section. Viewing collectd metrics with charts</h2> The CSV files are all well and good, but we can actually generate charts from the raw binary RDD files with a simple docker container running Collectd Graph Panel. This web UI read RDD files from disk and displays charts for each host it has data for. Now that you have the metrics on your local machine you can simply run the docker container to run a local web app that will allow you to browse the results. # Run the container and mount a volume of the RDD data $ docker run -v /var/lib/collectd/rrd:/var/lib/collectd/rrd -p 8080:80 konjak/cgp</code></pre> Open a web browser and go to the following address: http://localhost:8080 and you should see something like this. You can see I have multiple hosts so it will list every host (device) it has data for. Click on the host you want to view charts for and you should see something like this. The multiple hosts are just multiple folders listed on disk. $ cd /var/lib/collectd/rrd $ ls -lah total 20K drwxr-xr-x 5 root root 4.0K Aug 13 14:10 ./ drwxr-xr-x 4 root root 4.0K Aug 13 11:13 ../ drwxr-xr-x 44 root root 4.0K Aug 13 14:10 78dsJIOLHJK78bnjk.localdomain/ drwxr-xr-x 44 root root 4.0K Aug 13 14:10 dasKH90321KJsaa8.localdomain/ drwxr-xr-x 44 root root 4.0K Aug 13 11:14 pop-os.localdomain/</code></pre> You can continue to drop host folders in here and the UI will pick them up and parse them. Oooooo charts! Now you can click on the left menu to drill down. You will also notice that the URL has a predictable pattern so you can even add these links to other systems you have to link directly to these charts. Adding a link in the form of https://cgp.example.com/host.php?h=<HOST_FOLDER></code>. Enjoy and reach out to me if you have any questions. Go Made Me Return to College 2017-09-12T00:00:00+00:00 A long time ago I gave a TEDx talk</a> about how I ended up where I am and the choices I made. Most notably, the choices I made to transfer to many different colleges and eventually drop out. As I got more comfortable in my developer career at Harvard and then MadGlory I convinced myself that I never needed a formal education in Computer Science to do well. Convincing myself of that helped minimize the annoying itch I had that reminded me I never graduated, specifically from the school I worked my ass off to get into when I was a senior in high school, Rensselaer</a>. I started with using Go</a> back in the Summer of 2016 for a small project. A co-worker of mine, Patrick</a>, suggested we try it out since he was showing interest in it as well. So we took the chance on it and used Go to write it. We finished if fairly quickly while learning the language and got it into production. It performed better than we imagined it would and I was immediately hooked after that. I started spending more and more time learning the language and also, more importantly, the reasons why it was created and why it works at a conceptual level. It felt deliberate. Well thought out. Intentional. I liked those feelings, especially in world of being forced to ship software too fast. And now GopherCon 2017... Talk about being a small stupid guppy fish in a big ocean full of really smart dolphins! I have never been hit so hard with imposter syndrome in my life and to make it even worse I agreed to give a lightning talk</a> at the end of the conference. The first two days had a lot of tough acts to follow. However, after that weekend that annoying itch returned about never graduating. I spent over a year with Go and being a part of the community. Not only did I fall hard for the language, but I fell even harder for the message it conveys. The community's outlook on writing software has pushed me to educate myself more and how to build better software. This sparked the idea of returning to school to finish my degree since a lot of the concepts I was hearing from Go programmers was stuff I was never taught or I just happened to stumble upon accidentally. I felt like I needed more formal education around these concepts. So, I started to check out Rensselaer to see if that was a viable option to return to and complete my degree since I only live 30 minutes away. Unfortunately, given my lifestyle of doing dad and full time work things I couldn't make that work. However, I did end up finding Empire State College</a> basically in my back yard that prides itself in educating students in a non-traditional way. For me this meant I could complete my degree entirely online from and accredited SUNY</a> school. Sold! After being accepted I was pleasantly surprised to find out I am a mere 4-5 courses shy of a bachelor's degree in Computer Science and after speaking with my advisor it sounds like I may end up on a graduate degree path afterwards. Perhaps graduating from Rensselaer will actually happen if I am crazy enough to actually pursue it. The thought of that does sound very exciting though. Now that I have begun classes I am experiencing the value of the knowledge that comes from a formal education. The upcoming courses on Operating Systems, Software Engineering, and Systems Analysis and Design are really piquing my interests. These areas will certainly put me where I want to be in my career as a software engineer. This is going to be fun! Thank you, Patrick, for recommending Go and thank you, Gophers, for making me yearn for more and to go back to school. Now I leave you with Rob Pike's 2015 dotGo: Simplicity is Complicated talk to give you a taste of what contributed to my decision to return back to school. </iframe> Fuck Your Hustle 2017-02-06T00:00:00+00:00 This word is used throughout the startup and tech worlds and it annoys the shit out of me. Not only does it seem to stroke the egos using it, but it is also being used in completely the wrong context. Both of these definitions indicate no decisions being made on the person being hustled. How does this have anything to do with successfully launching a startup, product, or completing any task that is worth a damn? hustle (verb) force (someone) to move hurriedly or unceremoniously in a specified direction. "they hustled him into the back of a horse-drawn wagon"</li> obtain by forceful action or persuasion. "the brothers headed to New York to try and hustle a record deal"</li> </ol> Haste makes waste. </blockquote> When taking on a job or a task does telling the world at 10pm at night that you are working on it and "hustling" actually help get the work done right? How does rushing to get the job done make it any better? Wouldn't you prefer to take your time and methodically execute on it so its done right the first time? I work at a startup now and I am proud to say that none of us fuckin' hustle on a daily basis. Under certain conditions there may be a deadline that needs to be met, but that is on a rare occasion. The rest of the time is spent building quality systems that will stand up to future demand. Why? Because we didn't fuckin' hustle. Sometimes I feel sorry for those who feel the need they have to hustle to be successful. Shame on those who preach that as the way to achieve that success. Those who do preach it remind me of religious con men who make their money by spewing falsehoods to the masses so they pay for their books and conferences. Whatever is worth doing at all, is worth doing well. Philip Stanhope, 4th Earl of Chesterfield, Letters to His Son on the Art of Becoming a Man of the World and a Gentleman (1774)</li> </ul> </blockquote> Passion and planning yields success so stop fuckin' hustling and do it right. Go, Go import "container/list"! 2017-02-01T00:00:00+00:00 On a few different occasions I've needed to keep a registry of interface implementations to iterate over later on. The first time I did it was to have define an EventWriter</code> interface. // writers/writers.go package writers type Event stuct { Action string `json:"action"` Details string `json:"details"` CreatedAt string `json:"createdAt"` } type EventWriter interface { WriteEvent(event Event) } var Writers []EventWriter func Add(writer EventWriter) { Writers = append(Writers, writer) }</code></pre> Elsewhere, in my program I initialized a few implementations of EventWriter</code> and added them to the list of available ones. This is a stupid use, but for the sake of explaining I show it this way. My actual use was handling HTTP POST requests and so this really lives in a handler. // main.go package main import ( "sync" "writer-app/writers" ) func init() { // Add a bunch of EventWriter implementations to the registry writers.Add(&mySQLWriter{}) writers.Add(&s3Writer{}) writers.Add(&boltDBWriter{}) } func main() { event := &writers.Event{"load", "the app loaded", "2017-02-01T00:00:00Z"} // Loop over the slice that is the registry and call WriteEvent on each one for _, writer := range writers.Writers { writer.WriteEvent(event) } }</code></pre> While this proved effective and worked perfectly fine it isn't very idiomatic in Go. It also felt very dirty to me so I looked around for a better way to handle this. I immediately went into the Go standard library because it seems to always have what I need. In this cases I needed something like a slice, but with some methods to make working with the underlying elements nicer. As it turns out Go has a container/list</code> package that does exactly what I wanted to have this registry pattern I could work with. Refactoring the interface file I now have: // writers/writers.go package writers import ( "container/list" ) var Registry = list.New() type Event stuct { Action string `json:"action"` Details string `json:"details"` CreatedAt string `json:"createdAt"` } type EventWriter interface { WriteEvent(event Event) }</code></pre> And now for using the Registry</code> list in my main program I have just a standard list.List</code> provided by the standard library, which is an implementation of a doubly linked list data structure. I also get all the documentation around this as well so that the next developer that looks at this can understand this a lot quicker. One thing to notice when I call WriteEvent</code> within the loop is that I need to cast the writer.Value</code>, into an actual Writer</code>. That is because list.List</code> works with interface{}</code> types as you can see from the documentation. // main.go package main import ( "sync" "writer-app/writers" ) func init() { // Add a bunch of EventWriter implementations to the registry writers.Registry.PushFront(&mySQLWriter{}) writers.Registry.PushFront(&s3Writer{}) writers.Registry.PushFront(&boltDBWriter{}) } func main() { event := &writers.Event{"load", "the app loaded", "2017-02-01T00:00:00Z"} // Loop over the list that is the registry and call WriteEvent on each one for writer := Registry.Front(); writer != nil; writer = writer.Next() { // Convert the Value to an actual Writer writer.Value.(Writer).WriteEvent(event) } }</code></pre> This seems like a trivial example, but it shows how nice the Go standard library is by providing this out of the box instead of having to implement my own every time. References container/list GoDoc: https://golang.org/pkg/container/list/</li> Doubly Linked List: https://en.wikipedia.org/wiki/Doubly_linked_list</li> </ul> 3 Years at MadGlory 2015-10-07T00:00:00+00:00 This may have been the first job that when I look back over the years I am absolutely shocked with how much I have been exposed to and learned. I couldn't be more grateful towards everyone I work with. After all, MadGlory would be nothing if it wasn't for the people that work there and I am glad to call them my family. MadGlory opened its doors only 3 years ago</a>, but over those years we have gone from a 4 person team with no office and a few clients to a team of 20+ in our now 2nd office. We are starting to outgrow that now too. I think the next step is just just build our own office campus, but that is just my opinion. ;-) I remember when I started that I was just this ColdFusion developer with some WordPress, Drupal, and PHP experience. Barely used git and GitHub or any source control for that matter. Apache was the web server of choice and manually configured VMWare machines was the architecture of choice. I thought I had a good handle on engineering on the web. I was sadly mistaken. Fast forwarding today the list things I've learned is almost exhausting to talk about and it is growing every day. Never in a million years would I have thought that I would have a chance to write and successfully launch an Xbox 360 app driven by a Node.js API I helped design, engineer, and deploy, all in 5 months, but that just happened this week. By the way, there is also an iOS</a>, Android</a>, FireTV</a>, Roku</a>, and XboxOne</a> app that was also launched powered by the same API as well. </iframe> Things are only going to get bigger and better from here on out. Side Projects 2015-02-27T00:00:00+00:00 I've been hearing a lot of chatter about side projects</a> lately. First was from fellow Glory Lord, Mubs</a>, when he gave a talk at Sharatoga TechTalks</a> in February 2015. He is basically the king of side projects north of Albany, NY as far as I am concerned. So what he had to say was very inspiring. A few weeks later Twitter started getting more activity about side projects and then one very popular dev's tweet came into my timeline about his side projects. Salvatore Sanfilippo</a> aka "Antirez", the creator of Redis</a>, wrote about his list of side projects</a>. Yes Redis started as a side project and now look at where it is today. Pretty amazing. In the spirit of side projects I decided to add a new "Side Projects"</a> page to my site that listed some of the bigger efforts I have completed. There is still a bunch of other projects I have on my GitHub profile</a>, but these are the ones I felt deserved to be featured on my side. "Side projects are the projects making your bigger projects possible. Moreover they are often the start of new interesting projects." - Salvatore Sanfilippo </blockquote> Single Command Static File Web Server 2014-03-12T00:00:00+00:00 I have been building a lot of Javascript apps lately. I started to prototype one recently, but I did not want to set up an Apache host or a connect server to run it. I found a little gem of a command that was already installed on OSX. ~/Projects/static-app > python -m SimpleHTTPServer</code></pre> This was the perfect solution for me. SimpleHTTPServer</code> is a Python library and when you send that to Python with the -m</code> flag it tells Python to run the library as a script. Running this within the root of your static file project just fires up a web server at http://localhost:8000</a>. There is also a PHP version that will actually read a .htaccess</code> file so you don't have to use Apache. ~/Projects/static-app > php -S localhost:8000</code></pre> This is perfect for: Wireframing and protoyping</li> Javascript apps</li> Designers converting their PSDs into static templates who don't want to deal with build tools right away</li> </ul> The next time you need something really basic to run a HTML/CSS/JS app try it out for a quick win. Farewell to Harvard and Onward to MadGlory 2012-10-15T00:00:00+00:00 Well believe it or not after 7 memorable years working in the Harvard School of Public Health Information Technology Department</a> I have decided to leave. I will be taking up my new post at MadGlory Interactive</a> as Chief Architect. MadGlory is a web software company that creates awesome stuff for the video gaming and entertainment industry. This new direction is bitter sweet, but it was an opportunity I couldn't pass up. The guys that are working in the company are some of the smartest and creative people I know. I needed to become apart of their, now our, growing company. Over the past years at Harvard I have had the pleasure of working with some really great people throughout the Harvard community. A few noteable friendships are Kevin Wnek who I run Adjacent Concepts</a> with, Tina Haupert who blogs over at Carrots N' Cake</a>, and my boss, Deane Eastwood. Kevin and I actually redesigned his golf club's website</a> so I will always be in touch with him. On top of meeting so many great people I had numerous opportunities to expand my skillset. I entered knowing a few programming languages, but I am leaving knowing a lot more. My writing, communication, and project management skills improved dramatically. I was also able to get down and dirty with server admin work which I never thought I would get into. Harvard gave me a lot over my years so I wanted to take this opportunity to thank them very much and wish them the best on all of their future projects. I may be leaving, but I will never be gone. Convention Over Configuration Web Servers 2012-07-13T00:00:00+00:00 I am seeing more and more bootstrap projects for HTML, CSS, PHP, and the like. This is great because it really removes a lot of the configuration time when starting a new project so you can get down to business. Even frameworks for Ruby and PHP have basic web app skeletons in place before you being working. With both front end and middleware levels covered its time we focus our efforts on the backend servers that power these apps. Too often I find myself manually installing and configuring a server. Create the VM</li> Install Linux</li> Install Apache</li> Install MySQL</li> Install PHP</li> Remove mod_php and replace with mod_fcgi</li> Install PHP accelerator (XCache, APC, etc.)</li> Install content caching (Redis, Memcache, etc.)</li> Finally install WordPress, Drupal, or being working on an app</li> </ol> Seems like a lot of shit to deal with when a lot of these programs and settings are becoming standard, especially for high traffic websites. Why would we build a website expecting low traffic anyways? Some sites will not need the more advanced caching settings, but why not have them there and ready to go if needed. A few places have started to embrace the need for a single install web server. TurnKey Linux</a> and BitNami</a> offer a wide range server stacks that you can download, install, and a lot of the configurations done. TurnKey Linux LAMP Stack</a></h3> SSL support out of the box.</li> PHP, Python and Perl support for Apache2 and MySQL.</li> XCache - PHP opcode caching acceleration.</li> PHPMyAdmin administration frontend for MySQL (listening on port 12322 - uses SSL).</li> Postfix MTA (bound to localhost) to allow sending of email from web applications (e.g., password recovery)</li> Webmin modules for configuring Apache2, PHP, MySQL and Postfix.</li> </ul> This stack is also available with PostgreSQL</a> instead of MySQL. There are also many others for Ruby on Rails, Tomcat, and Java. More specific web app versions for Drupal, WordPress, Redmine, etc. are also available. Once you get up and running with the configuration you need then you can certainly take a snapshop of that web server and deploy it as many times as you need. However, for us jack of all trade types it would be nice to see this taken a step further to include other emerging technologies and best practices. My wish list includes: Nginx</li> Node.js</li> Redis and Memcache</li> Optimized WordPress/Drupal with caching and tuned PHP</li> GitLabHQ</li> </ul> It only makes you a better programmer when you understand the underlying powerhouse of your app, but sometimes you don't give a shit and just want to build an app without messing around in web server configuration hell. I hope to see TurnKey Linux and BitNami thrive that more and more flavors become offered. Happy Friday the 13th!

Blain Smith

Unbounded Concurrency is a Foot Gun

Wired for Fairness

Building Go APIs with Huma, sqlc, and Goose

Vendoring Modules in Hare

Hare's growing ecosystem</h2> You can find a lot of Hare projects on https://sourcehut.org</a> and https://codeberg.org</a>, but there is also a community currated list that is growing all the time on the Project Library</a> page of the official Hare website.</p>

Crocker's Rules

Humanities in the Machine

10th Person

30 Years of Programming at 44 Years Old

Read the Fucking Manual

How I Write HTTP Servers

I Don't Care

The End...of Caring</h2> I'm well aware this all comes off as elitist, dismissive, and mean. Guess what? I still don't care. I can hold these thoughts while also working with folks who think the opposite. That is life. You co-exist.</p> I don't care.</p>

Excitement is Relative

AI Coding

Allergic to Unnecessary Complexity

Bare Essentials Development Tools

My Four-Tool Philosophy</h2>

Software Engineering Discipline and Posture

Towards Teaching

Introducting: Hare by Example

Block Non-Human Crawlers with Go

Example Usage</h2> This middleware can be used to protect any single or group of routes in your app as long as it is an http.Handler</code>.</p>

Notable Differences</h2> The core principal is the same as Adële's version, but I made some changes to make it configurable for whoever wants to use it.</p>

Limeleaf Co-op

"Rot Economy" and Software Bloat is Increasing the Digital Divide

Done

static-httpd

Writing Bitcask in Hare

Hash Maps</h2> I make use of a few hash maps in order to have quick lookups of keys and data files. Unfortunately, Hare does not natively have hash maps as a built-in data type like other languages do. Fortunately, it was trivial to implment one for the key/values I needed.</p>

What's next?</h2> Now that I have a working database for my game I can move forward with the game itself, but I will certainly come back to Bitcask to add more features from the design paper. Most notably they would be:</p> Setting an expiry on keys</li> Auto-merge on a configurable interval</li>

Auto-Generating an OpenAPI Specification for gRPC and gRPC Gateway

Network Programming with Hare

40

Software I'm Thankful For

How I Write HTTP Clients

Composing Client Options</h2> Most HTTP clients share 3 things in common with each other.</p>

HTTP Request Signing</h2> One of the most common ways to authorize HTTP requests to an API is to specify a token of some kind that the API provides to you. This token is set in one of two places.</p> Query Parameter</li>

Query Parameter</h3> Merely attaching a predefined query parameter to every call that the API specifies is a simple way to authorize requests.</p>

`Hare's growing ecosystem</h2> You can find a lot of Hare projects on https://sourcehut.org</a> and https://codeberg.org</a>, but there is also a community currated list that is growing all the time on the Project Library</a> page of the official Hare website.</p>`

The End...of Caring</h2>
I'm well aware this all comes off as elitist, dismissive, and mean. Guess what? I still don't care. I can hold these thoughts while also working with folks who think the opposite. That is life. You co-exist.</p>
I don't care.</p>