Personal knowledge management, or PKM, describes an ecosystem of tools and methodologies that help you manage notes. You can think of it as building your own, personal Wikipedia.

Use node:test (nodejs v18+), node:assert, react-test-renderer (official React library), and circumvent jsx parsing with createElement (React API).

My website gatlin.io is sourcing content from my Obsidian vault. In my opinion this is an exciting setup because I can create content in Obsidian as I do normally, adding a property public: true when I want to share it with others. Finally, I run a script within my website repo to scan my vault and turn all public: true notes content.

In this article we are going to reverse-engineer parts of React from scratch as we build out a counter app. We will stay well under 100 lines of spacious code the whole time. We start with a counter app built with Web APIs and imperative commands, and slowly refactor our way to core React abstractions, ending in declarative functional components using hooks and JSX. Along the way, the reader will hopefully gain an intuitive understanding for why React looks the way it does, the logic behind some of React's design, and finally, understand why React is so popular, namely, that it represents a suite of improvements over the "vanilla" alternative of sequential, imperative Web API invocations, as we will see.

(Update: I have modified my setup since writing this article. The new setup is discussed in How I Use Obsidian as a CMS for my Website.)

This blog post will walk through refactoring a simple todo app built with React hooks. Each section will introduce a small refactor. These small refactors will often involve writing small helper functions with familiar sounding names for people who have used Redux before. By the end of the journey, we will have intuitively discovered, and reinvented with our own simple implementations, some of the core Redux and Redux Toolkit abstractions like createStore, Provider, useDispatch, useSelector, createSlice, and combineReducers.

This blog post focuses on ideation around building quick-start codebases that are more than just prototypes or proofs of concept. Approaches I've tried in the past (personalized template repos and tool-maintainers' guides and example repos) have some problems. I have an idea for a better solution utilizing a guided walkthrough approach with links as the primary information source.

In this blog post I will attempt a concise introduction to how a website works, conceptually speaking. I will make sweeping generalizations. My target audience are new tech workers, tech-adjacent workers, etc.

Or: What I wish I knew about Lua before I started writing my Neovim init.lua config file, from scratch, and with no previous Lua experience.

In this blog post I'm going to defend the position that you should try to avoid using Ecto.Repo.preload/3. I am going to propose an approach utilizing secondary contexts and Ecto.Query.preload/3.

Serverless design patterns are a revolution in web app development because they simplify the developer responsibility space. In the zero-sum game of spending time, every second spent in application-adjacent tech (e.g., architecture, platform, etc.) is a second taken away from application tech (e.g., feature development, user experience, etc.). My perfect world would have all responsibility taken away from me except for application development.

(An associated slide deck was presented for Tech & Startups Conference 2019.)

This article is about the perils of CSS position: sticky. It's a fantastic development for CSS, nevertheless, there are some pitfalls to watch out for, as well as some non-intuitive behaviors to keep in mind.

Who is the end user of the software?

Java can be intimidating for people new to programming, or people coming from a dynamic language background. When I first learned Java (coming from Ruby and JavaScript) it felt esoteric, scary. It felt like there were many unknown unknowns: I didn't know what I didn't know.