Moving from a Rails-based content system to Jekyll offers several advantages:
The new design is inspired by Mozilla Protocol — a design system that emphasizes:
Over the coming weeks, I’ll be migrating the existing blog posts from the Rails application. This includes:
Stay tuned for more content!
This blog is open source. Find a bug or want to suggest an improvement? Open an issue on GitHub.
]]>KidsUI is a small UI kit for kid-friendly web projects. I built it because I keep finding small reasons to make little things for my daughter, her kindergarten, and the teachers who sometimes reach out for help.
I did not set out to make a design system. I just kept needing the same kind of parts.
A few little projects for my girl in kindergarten. A small page or tool when one of her teachers reaches out for help. And a few simple web apps I want to build later, partly for fun and partly for educational use.
So I pulled those pieces into one place and called it KidsUI.
The goal is not completeness. The goal is a small set of components that already feel right for children: friendly, clear, a little playful, and easy to drop into tiny projects without dragging in a whole frontend stack.
The stack is web components with motion. I do not want the kit bound to any one library.
Not React. Not Vue. Not even my usual favorite, ViewComponent.
If a project is plain HTML, Rails with Stimulus, or some other stack entirely, the UI pieces should still work. That portability matters more to me here than framework convenience.
Motion is part of the language too. Kids notice movement immediately. Used lightly, it makes an interface feel alive and welcoming instead of static and dry.
That is the whole idea behind KidsUI: small components, small projects, and a softer place to start building simple web apps for kids.
]]>HomeAway is a tiny macOS CLI that flips my Wi-Fi between manual and DHCP mode. It exists because I got tired of digging through System Settings every time I left home.
At home, my setup is a little strange but very effective.
I keep a side router around specifically for traffic that needs to get past the Great Firewall. When I am home, I point my Mac at that router with manual Wi-Fi settings and let it handle the first proxy layer. From there I can add a second VPN on macOS, like NordVPN, if I want another layer on top.
Outside, that setup falls apart. The side router is not with me, so manual mode is useless. I need DHCP just to get normal internet access. And without that first router-based proxy layer, NordVPN is usually not an option either. I can still use Clash or another local proxy for basic GFW bypass, but the network setup on the Mac has to change first.
That small switch between home and away turned into a recurring nuisance: open settings, find Wi-Fi, flip from manual to DHCP or back, recheck router and DNS values, then hope I did not leave something half-configured.
So I made HomeAway.
HomeAway is not a full network manager. It is a thin wrapper around the one thing I actually keep doing.
Install it:
gem install homeaway
Run it:
homeaway
On first run it asks for the router address, DNS server, and whether DHCP mode should clear DNS settings. After that, it just remembers.
The point is not sophistication. The point is removing friction from a real routine.
I know exactly when I want manual mode: at home, with the side router. I know exactly when I want DHCP: everywhere else. That should be a one-command decision, not a small trip through macOS settings.
That is all HomeAway does. Small tool, specific job, less clicking.
]]>This is a practical list of the symbols most students meet in primary school and middle school, grouped by grade band and by category. Each symbol is clickable to learn more on Wikipedia.
This post was shaped by the broader symbol reference from Math Vault: Compendium of Mathematical Symbols.
At this stage, kids mostly need counting, comparison, and the four basic operations.
Equal sign (=)
Means the values on both sides are the same. Three plus two equals five:
[3 + 2 = 5]
Less than (<)
Means the first number is smaller. Four is less than seven:
[4 < 7]
Greater than (>)
Means the first number is larger. Nine is greater than six:
[9 > 6]
These three carry a lot of early math. If a student can read them comfortably, word problems start to feel less mysterious.
Plus sign (+)
Means add.
[2 + 5 = 7]
Minus sign (−)
Means subtract.
[9 - 4 = 5]
Multiplication sign ($\times$)
Means multiply.
[3 \times 4 = 12]
Division sign ($\div$)
Means divide.
[12 \div 3 = 4]
Students also see the multiplication sign written as a dot ($\cdot$) in some books, but the times sign is the one most kids meet first.
Parentheses ( )
Mean do this part first.
[(2 + 3) \times 4 = 20]
Comma (,)
Separates numbers in a list.
[2, 4, 6, 8]
Decimal point (.)
Separates whole numbers from parts. Three and a half:
[3.5]
Parentheses are worth teaching early. They help kids see that math is not just left to right button pushing.
Now the work gets broader: fractions, decimals, measurement, and geometry show up more often.
Fraction ($\frac{1}{2}$)
Shows parts of a whole. One half means one part out of two equal parts:
[\frac{1}{2}]
Fraction bar or slash (/)
Can also mean division.
[6 / 2 = 3]
Fractions are often the moment when symbols start to feel like a new language. A little repetition helps a lot.
Percent sign ($\%$)
Means "out of 100." Twenty-five percent equals twenty-five hundredths:
[25\% = \frac{25}{100}]
By this point, students should start seeing that $0.5$, $\frac{1}{2}$, and $50\%$ are different ways to say the same amount.
Angle symbol ($\angle$)
Marks an angle. The angle at point $B$ formed by points $A$, $B$, and $C$:
[\angle ABC]
Degree symbol ($^{\circ}$)
Measures angles. Ninety degrees is a right angle:
[90^{\circ}]
Parallel ($\parallel$)
Means lines that never meet.
[a \parallel b]
Perpendicular ($\perp$)
Means lines that meet at a right angle.
[m \perp n]
Two especially useful geometry facts for this age:
A right angle is $90^{\circ}$.
Perpendicular lines meet to make a right angle.
Approximation symbol ($\approx$)
Means "about equal to." Three point one four is close to pi:
[3.14 \approx \pi]
This is a nice symbol for helping kids see that some values are exact and some are close enough for the job.
Middle school math adds variables, exponents, ratios, inequalities, and basic statistics.
Variable ($x$, $y$, $n$)
Stands for an unknown number. If two $x$ plus five equals three, then $x$ equals negative one:
[2x + 5 = 3]
[x = -1]
This is where students learn that a letter in math is not a fancy decoration. It stands in for a number.
Exponent ($x^2$)
Means multiply $x$ by itself. Five squared equals twenty-five:
[5^2 = 25]
Cube ($x^3$)
Means $x$ multiplied by itself three times. Two cubed equals eight:
[2^3 = 8]
Square root ($\sqrt{x}$)
Asks what number times itself gives $x$. The square root of forty-nine equals seven because seven times seven equals forty-nine:
[\sqrt{49} = 7]
[7 \times 7 = 49]
Ratio ($:$)
Compares two amounts. Two parts to three parts:
[2:3]
Proportionality ($\propto$)
Means "is proportional to," though this usually shows up later in middle school or early high school.
For most students in this band, ratio language matters more than the fancy notation. The fraction form does most of the work.
Less than or equal to ($\le$)
Means the first number is smaller or the same.
[x \le 10]
Greater than or equal to ($\ge$)
Means the first number is larger or the same.
[y \ge 2]
Not equal to ($\ne$)
Means two values are different.
[x \ne 4]
This is the point where students stop solving only one-answer equations and start describing sets of answers.
Coordinate pair ($(x, y)$)
Names a point on a grid. Three units right and four units up:
[(3, 4)]
Delta ($\Delta$)
Means change. Delta $y$ means change in $y$:
[\Delta y]
Students may not love graphing at first, but these symbols keep showing up, so it is worth making them familiar.
Mean ($\overline{x}$)
Represents the average of a set of numbers.
Probability ($P(A)$)
Means the chance of event $A$ happening. The probability of heads equals one half:
[P(\text{heads}) = 0.5]
These are not always introduced formally in every middle school class, but they are common enough to recognize.
If a student only memorizes a short list, start here:
Addition and subtraction: +, −, $\times$, $\div$
Comparisons: =, <, >
Fractions and percents: $\frac{1}{2}$, ., $\%$
Geometry basics: $\angle$, $^{\circ}$, $\parallel$, $\perp$
Algebra basics: $x$, $x^2$, $\sqrt{x}$
Inequalities: $\le$, $\ge$, $\ne$
That set covers a surprising amount of school math.
Do not teach symbols as a vocabulary quiz. Teach them inside real problems.
For example:
Three plus four equals seven teaches addition and equality together.
Five is less than eight teaches comparison with a concrete fact.
One half of ten is five teaches a symbol and an idea at the same time.
$x$ plus two equals nine teaches that a letter can hold a missing value.
Kids usually learn symbols faster when the symbol solves a problem they already care about.
Most math symbols are not hard. They are just unfamiliar.
Once a student learns to read <, $\sqrt{x}$, or $\angle ABC$ without pausing, math gets lighter. Less decoding. More thinking.
]]>POSSE stands for Publish (on your) Own Site, Syndicate Elsewhere. The idea is simple: you own the canonical copy of your content, but you push copies to wherever your readers are.
The appeal is obvious. Your blog is yours. The URLs are yours. But your friends aren't all going to subscribe to your RSS feed. So you syndicate. Write once, publish everywhere.
I wanted to build it into my Rails blog. Write a post, hit publish, and have it automatically post a summary with a link to X. Classic POSSE.
X's developer documentation used to say "get started with a free API key." Now it says "purchase API credits."
The current model is pay-per-usage. You buy credits upfront. Different endpoints cost different amounts. There's a 24-hour deduplication window – request the same post twice in a day, pay once. The free tier is effectively gone for new developers.
For someone who posts occasionally – say, a few times a month – the economics don't work. You're buying credits upfront for a trickle of posts. The dream of automatic POSSE-to-X died quickly.
AI-generated content is cheap to produce. Ungodly amounts of it can be generated for pennies. If the API were free, X would be flooded with AI posts, bot replies, and automated engagement farming.
Nobody wants to use a platform where everything might be AI-generated. X is essentially saying: programmatic access costs money. This filters out low-value automation. It makes spam uneconomical.
The pricing isn't about extracting revenue from legitimate developers. It's a defense against the AI flood. Rate limits add another layer – even with credits, you can't fire off unlimited requests. Billing blocks abuse; rate limits protect infrastructure.
The website and official apps are free. The API costs money. How?
X's apps use first-party OAuth credentials that the gateway recognizes as trusted. Third-party developers get different keys. The gateway inspects every request: first-party passes through, third-party gets metered and billed. Same API, different treatment based on the key.
Could you extract the app's keys and impersonate it? Technically possible, but X layers defenses: certificate pinning, code obfuscation, device attestation, behavioral detection. The goal isn't perfect security – it's making the legitimate path easier than the adversarial one.
This pattern is spreading. OpenAI charges for API tokens while ChatGPT the app is free. Reddit has paid API tiers. Google Maps has for years. The model is: humans through the app, free; machines through the API, metered.
I'll keep posting to X manually when I feel like it. The POSSE dream lives on for platforms with friendlier APIs – Mastodon, Bluesky, RSS, webmentions.
A platform that costs a little to automate is better than one that's free to drown in AI slop. Sometimes the right technical decision is the one that makes the easy thing expensive.
]]>My sheet music project was heading there. Each piano score generated five files: SVG, PDF, MIDI, MP3, and the LilyPond source. Plus a bird guessing game with 13 bird photos and 8 audio clips. 32 files, 33MB, all checked into Git.
Cloudflare R2 fixes this. Zero egress fees, S3-compatible API, cheap storage. Here's the setup.
| Environment | Files served from | URL base |
|---|---|---|
| Development |
public/music/ and public/projects/
|
/music |
| Production | R2 bucket | https://cdn.goodbran.com/music |
Same code, different sources. Rails environment determines where files come from.
R2 uses S3-compatible API. rclone speaks that natively.
Configure once:
rclone config
# Choose "Amazon S3", enter your R2 access key and secret
# Endpoint: https://<account_id>.r2.cloudflarestorage.com
Then sync:
rclone sync public/music/ r2:goodbran/music/
rclone sync public/projects/ r2:goodbran/projects/
I added rake tasks for convenience:
rails assets:sync_music # Sync sheet music
rails assets:sync_projects # Sync project files
rails assets:sync_all # Both
The Content::Sheet model generates asset URLs. In production, they point to the CDN. In development, they point to local files.
class Content::Sheet < Perron::Resource
CDN_BASE = Rails.env.production? ?
"https://cdn.goodbran.com/music" : "/music"
def pdf_url
"#{CDN_BASE}/#{pdf_filename}" if pdf_filename.present?
end
end
No configuration files, no environment variables. The code knows where it lives.
After syncing to R2, I removed the assets from Git tracking:
# Update .gitignore
echo "/public/music/*" >> .gitignore
echo "/public/projects/*" >> .gitignore
# Remove from tracking but keep local files
git rm -r --cached public/music/
git rm -r --cached public/projects/
Local files stay for development. Fresh clones get an empty public/music/ directory. Run rails lilypond:compile or rclone sync to populate it.
Adding new sheet music:
.ly file in app/content/lilypond/
rails lilypond:compile[new-piece]
public/music/ — works immediately in devrails assets:sync_music — now on CDN for productionThe bird game works the same way. The ProjectsController builds URLs based on environment, feeding JSON to a Stimulus controller that plays sounds and shows images.
R2's free tier: 10GB storage, 10 million reads per month. My entire asset collection is under 35MB. It costs nothing.
Even if it grows to 1GB, that's $0.015/month for storage. Egress is free. The only risk is going over 10 million monthly reads, which would cost $0.36 per million after that. For a personal site, unreachable.
The repo contains source files. The CDN serves generated files. Separation of concerns, finally.
]]>It is exactly what I needed: a volunteer-run archive of public domain scores, all typeset in LilyPond and freely licensed. No sketchy PDFs from questionable corners of the internet. Just clean, engrave-ready source files.
When you are learning piano, finding good beginner material is harder than it should be. Most free sheet music online is either:
The Mutopia Project is none of that. Every piece is verified public domain, professionally typeset, and available as a .ly source file.
The first piece I grabbed was the Minuet in G Major (BWV Anh. 114) from the Anna Magdalena Bach notebook. It is the perfect beginner piece: simple hand positions, clear melody, just enough ornamentation to teach mordents.
The source file compiled cleanly. One rake task later I had PDF, SVG, MIDI, and audio rendered with my Grand Piano soundfont.
The beautiful part is that Mutopia scores integrate directly into a code-based pipeline:
.ly fileBecause the source is plain text, you can version it, diff it, and review changes like any other code file.
The collection spans centuries: Bach minuets, Burgmüller etudes, Clementi sonatinas, Beethoven dances. Most of the standard beginner repertoire is there, waiting to be compiled.
For anyone building a piano learning tool or just collecting repertoire, Mutopia is a goldmine. Free, legal, and built for the same source-code mindset that makes LilyPond appealing in the first place.
]]>The flow remains simple: write LilyPond, compile it, publish the results. But the output is much wider. The build task now emits five artifacts for each piece:
SVG for inline display on the pagePDF for printingMIDI for raw performance instructionsMP3 for broad browser supportOGG for an open audio formatA score page is no longer just something to look at. It is something to read, download, and hear.
LilyPond can write MIDI, but MIDI is not audio. It is a set of instructions: play this note, at this time, with this instrument.
To turn that into sound, the build now pipes the MIDI through fluidsynth with a piano SoundFont, then hands the result to ffmpeg for MP3 and OGG encoding.
That small change shifts everything. The pipeline feels complete. Text in, sheet music out, audio out.
I do not need a hundred synthetic instruments. I just need one decent piano.
Our setup leans hard into that constraint. The score asks for acoustic grand, the local build uses a dedicated piano SoundFont, and the audio path is tuned for that single instrument instead of general MIDI convenience.
It is still a simple system. But it is simple in the right direction.
The score page keeps the engraved notation, adds fast download links for the new files, and includes a plain native browser audio player.
That is the part I appreciate most. The same text source file now serves three jobs simultaneously:
It is not a massive feature on paper. But it completes the experience. Write the music. Compile it. See it. Hear it.
]]>rails g model. If you already run a Rails app, everything you need for a proper double opt-in newsletter is already in the box. Here's how ours works.
A subscriber goes through three states: pending, confirmed, and unsubscribed. One table tracks all three with two timestamp columns:
create_table :subscribers do |t|
t.string :email, null: false
t.datetime :confirmed_at
t.datetime :unsubscribed_at
t.string :source
t.timestamps
end
add_index :subscribers, "lower(email)", unique: true
No status enum, no state machine gem. A nil confirmed_at means pending. A present confirmed_at with a nil unsubscribed_at means active. Both present means they left. The scopes write themselves:
scope :pending, -> { where(confirmed_at: nil, unsubscribed_at: nil) }
scope :confirmed, -> { where.not(confirmed_at: nil) }
scope :active, -> { confirmed.where(unsubscribed_at: nil) }
The functional lower(email) index catches duplicates regardless of casing. Combined with create_or_find_by!, re-subscribing the same address is a no-op instead of an error.
The confirmation flow uses Rails' built-in signed IDs — no token column, no custom crypto:
# Generating the confirmation link
confirm_newsletter_url(
token: subscriber.signed_id(purpose: :newsletter_confirm, expires_in: 7.days)
)
# Verifying it
subscriber = Subscriber.find_signed!(params[:token], purpose: :newsletter_confirm)
subscriber.mark_confirmed!
signed_id encodes the record's ID with a purpose and expiry into a tamper-proof token. Rails handles the signing, verification, and expiration. The token lives in the URL, so there's nothing to store.
The same pattern works for unsubscribe links, just with a different purpose:
Subscriber.find_signed!(params[:token], purpose: :newsletter_unsubscribe)
One mechanism, two use cases.
Newsletters are campaigns. Each one is a database row with a subject, an HTML body, and a plain-text body. A rake task ties everything together:
bin/rails newsletter:send SUBJECT="Monthly note" MARKDOWN_FILE="path/to/issue.md"
The task reads a Markdown file, converts it to HTML with Kramdown, strips tags for the text version, and enqueues a delivery job for every active subscriber:
campaign = NewsletterCampaign.create_from_markdown_file!(subject:, file_path:)
Subscriber.active.find_each do |subscriber|
NewsletterMailer.issue(subscriber, campaign).deliver_later
end
Each email gets its own unsubscribe link. The List-Unsubscribe and List-Unsubscribe-Post headers tell email clients to show an unsubscribe button natively — Gmail, Apple Mail, and others will render it without you building any UI on their end.
For a personal blog with a modest list, the answer is simplicity and cost. The goal is to minimize the budget for this blog system as much as possible. No API keys to rotate, no webhook endpoints to maintain, and no monthly bill that scales with your subscriber count. The entire subscription system is about 150 lines of application code. Rails' deliver_later handles background delivery, and Amazon SES (Simple Email Service) handles the actual sending for pennies.
If the list grows to thousands and you need analytics, A/B testing, or deliverability optimization — sure, migrate to a dedicated service then. But starting with your own gives you something no SaaS does: complete understanding of every line in the stack, and a monthly bill that rounds to zero.
]]>LilyPond takes a plain text file and produces engraved sheet music.
Instead of dragging notes around a canvas, you describe the music directly:
\relative c' {
\key c \major
\time 4/4
c4 e g e |
d4 f a f |
}
Even without knowing much music, I can read the shape of this. Key, time signature, notes, rhythm – all as text.
If you spend the day in a code editor, this feels familiar. You write a file, compile it, and get an artifact. It just happens to be music.
What makes LilyPond interesting is that the source stays readable and diffable. You can review changes, track revisions, and keep the .ly file in the same repository as the rest of your project.
The output matters too. LilyPond gives you professional-looking results without nudging everything by hand.
I started with a small experiment and quickly liked the workflow. A rake task compiles .ly files into SVG and PDF, so it fits naturally into a codebase.
Text file in, engraved score out, automated build. Exactly the kind of workflow I want.
]]>