I used to keep a list above the bench. Tape, marker, half-illegible. Drill sizes for the taps I use most. The voltage drop on a 12-foot run of 14-gauge wire. The two resistor color codes I can never remember because my eyes argue with me about whether that band is red or orange.

The list grows. The list also disappears, taken down for paint, lost behind a cabinet, written over when a project ends.

This is the universal experience of working with your hands. The reference you need is never in your hand. It is in a book on a different shelf. It is in a PDF on a laptop that died. It is in a forum post from 2009. It is on a poster you owned and then somebody borrowed and then forgot, and now you are paying for premium printable charts from a website that pops up six modals before it lets you see the chart.

So I made my own.

Maker Almanac is Field Instrument 007 in my ongoing series of small handmade tools. It is a single HTML file. You open it in any browser. It runs entirely offline once loaded. There are no logins. There are no ads. Nothing phones home. It does not know who you are. It will not remember what you searched for. It is a catalog, not a service.

What is in it:

Fifty-six sections across four categories. Electrical and electronics. Mechanical. Software. Shop and studio. Resistor color bands. SMD codes. Tap and drill charts in metric and imperial. Sheet metal bend allowance. Spring design. Beam deflection. Geometry solvers. Pyrometric cones for kiln work. Tannage references for leatherwork. Yarn count converters for weaving. Signature math for bookbinding. Adhesive selection. Finish selection. Composite layup. Jig design. Shop safety with noise exposure math. Photography exposure triangle. Videography codec reference. Audio recording fundamentals. Hardness conversions. Welding heat input. Pressure vessel hoop stress. Saddle stitch thread length. Pulley and belt calculations. Hardware sizing.

It is the closest thing I have ever made to that taped-up list above the bench. The difference is that it does not disappear behind the cabinet, and that I get to share it.

There is a philosophy underneath this thing that I want to name. Same one as MILEPOST (FI 003): the tool should get out of the way. The Maker Almanac does not nudge you. It does not have streaks. There is no leaderboard for how many laser cuts you ran this week. The page you do not need is not on screen. The page you do need is one keystroke away. Command-K, type three letters, hit return. It is the same gesture as flipping to a tabbed page in a real almanac, except it never sticks together because you got finish on your fingers last Tuesday.

I built it for me. I am putting it on the web because if it is worth building, it is worth sharing. Same principle that runs everything I make. The only ethical place to keep a reference like this is in public, where anyone who is going to start a bench tomorrow can find it.

A few specifics worth mentioning. The unit conversions are reversible everywhere. You can punch in 4.7k and get yellow, violet, red, gold, or you can pick the bands and read out the value. Same for the yarn count converter, same for the paper weight converter that bridges GSM and the strange American “100 lb cover” basis-weight system that nobody can ever remember. Calculators show their work, not just their answers, because if you cannot see the formula you cannot tell when the answer is wrong.

The whole thing is one HTML file. About 800 kilobytes. Fits on a thumb drive ten thousand times over. It will keep running in 2040 if browsers still load HTML, which I expect they will, because HTML is older than most of the software I have ever paid for and it is still here.

I am not selling anything. There is no paywall. There is a print button that will print a single section clean. If you want to pin a tap chart over your drill press, that is what the button is for. I tested it.

The list above my bench is going to come down soon. Not because I do not need it. I will still need it. But the file is going to be the thing I reach for. The list will still be there in spirit. The Almanac is just the version of it that does not blow away when I open the door.

The Maker Almanac lives at https://mbparks.com/almanac. It is free. It works offline. It is not done, because nothing I make is ever done, but it works, and you can use it today.

If you have a thing you wish was on the list, tell me. I will build it. The whole point of an almanac is that it keeps growing.

This is a thing every embedded developer has lived through. You want something between printf statements and pulling out the proper bench oscilloscope. You want a window into the board that shows you everything it is doing right now, calibrated, time-aligned, with a strip chart, an FFT if you need one, alerts you can set, an I2C scanner when the bus goes quiet for no reason. A field instrument for the microcontroller itself.

What I had was the Arduino IDE Serial Monitor, which is a tiny window showing numbers scrolling by.

That mild irritation turned into a six-week build that I now use every time I touch a board. It is one HTML file. No build step, no framework, no install. I am calling it PinScope, and the source is up at:

https://github.com/mbparks/pinscope

The docs site is at https://mbparks.github.io/pinscope/.

What it does

PinScope is a browser console for any Arduino-compatible board that can speak a tiny JSON line protocol. You flash one of the firmware sketches that ship with the repo (serial, BLE, or MQTT variants). You open pinscope.html in Chrome or Edge. You click a transport button. The page connects and you get this:

A live map of every digital and analog pin. Click a pin’s mode badge to cycle through input, input-pullup, output, PWM, or an interrupt-counted frequency mode for pulses and tachometers. Outputs toggle on click; PWM pins get a duty slider. Analog channels stream into a strip chart that holds up to 14 traces with per-channel stats, calibration in real units, threshold alerts, and oscilloscope-style triggering on rising or falling edges. There is an FFT tab and a waterfall spectrogram for the frequency-domain stuff, an XY scatter for Lissajous-style plots, an I2C scanner with four polling slots that feed virtual channels at up to 50 Hz, and a cross-pin math engine that lets you derive any channel as an expression of any other channels.

You can save the whole device’s configuration as a JSON file and restore it later. You can capture a run and replay it. You can stream samples straight to a CSV file as they arrive. There is a small scripted automation sandbox if you want to ramp a PWM pin and log the response. There is a sandboxed plugin system if you want to add your own panel that shows something I have not thought of.

All of it is one file. Once the page loads it makes zero further network requests. You can serve it from a Raspberry Pi, drop it on a USB stick, run it from a thumb drive in the field, embed it inside a CI pipeline, or pin it to localhost. It is the only file there is.

The hard parts were the boring parts

The interesting-looking pieces of this project (strip chart, FFT, spectrogram) were almost free. There are good algorithms for that stuff, JavaScript on a modern laptop can comfortably FFT a few thousand samples sixty times a second, and the visuals are just <canvas> work. None of that was where the weeks went.

The weeks went into the seams.

I needed the wire protocol to be small enough that any embedded person could speak it from a fresh sketch in an hour. That meant JSON over newline-delimited lines, hand-parsed on the firmware side without pulling in a JSON library. Each command and response had to be a single object on a single line, short enough to fit on a 9600-baud link if it had to.

I needed transports to be interchangeable. The same browser-side device card had to work whether bytes were coming over Web Serial, a WebSocket to a custom firmware, an MQTT topic, or a Bluetooth GATT characteristic. The transports each have their own quirks, and the device code had to not care which one was underneath.

I needed calibration to behave. A two-point fit wizard sounds simple until you realize the user might apply the same reference for both captures, and the math now divides by zero. The wizard refuses to fit in that case and tells you why, instead of silently producing a calibration that pegs every reading to one value.

I needed the plugin system to be safe. Anyone running PinScope can paste arbitrary JavaScript into the plugin manager and load it. That JavaScript runs inside an iframe sandboxed to allow-scripts only, with no same-origin access, no network, and a randomized postMessage bridge id so plugins cannot impersonate each other. The plugin source gets embedded into the sandbox via JSON.stringify and eval’d, which prevents template-literal breakout attacks on the host. There is a two-line dance around splitting <scr + ipt> tags so the host HTML parser does not terminate the script block early when a plugin’s srcdoc contains the closing tag as a string. Tiny detail, total silent failure if you do not handle it.

I needed the firmware to identify itself. The Arduino Uno R3 has a 10-bit ADC. The Uno R4, Nano 33 IoT, and Uno Q all have 12-bit ADCs. The firmware detects the host MCU at compile time and reports its adcMax value in the hello packet, so the browser-side scaling lines up with reality without the user ever having to set it.

None of these are interesting in isolation. All of them were necessary. This is the part of every project that nobody writes blog posts about, and it is where most of the actual craft lives.

What I keep relearning

The gap between “I can imagine the tool” and “the tool works reliably on the real-world inputs people will throw at it” is wider than it ever feels at the start. I wrote about this same gap a few months ago in the Gerber Viewer post, and here it is again. Two completely different projects, same lesson.

The first half of any maker project is the part you can picture in your head. The second half is the part the real world hands you that you had no way of picturing. The 1200-bps touch-to-reset that some Arduino bootloaders need. The fact that browsers terminate inline scripts on the first literal </script> they see, including ones inside strings. The way Google Fonts loads asynchronously, which means your hero font is fine online and looks wrong in any offline test environment. The 50 Hz upper cap on the wire protocol that comes from how many bytes will actually fit per state packet at 115200 baud, not from any clean theoretical reason.

Plan for that second half. Budget for it. Do not be surprised by it. Half the time it is the second half that turns a project into something worth keeping.

Where to find it

PinScope is open source under GPL-3.0.

• Source, install instructions, and the full feature reference: https://github.com/mbparks/pinscope

• Docs site with screenshots and the bring-up walkthrough: https://mbparks.github.io/pinscope/

• The hardware bring-up checklist (Arduino Uno Q on macOS, phase-by-phase): https://mbparks.github.io/pinscope/bringup.html

The firmware compiles for classic Arduino Uno, Uno R4 WiFi, Nano 33 IoT, and (experimentally) Uno Q. Real bench-side verification on Uno Q is the next thing on my list. If you give it a try and something breaks, the bug-report shape that helps me most is which bring-up phase you got to, what the pass criterion was, and what actually happened.

If you want me to build something like this for your project, hardware diagnostics or otherwise, that is what Green Shoe Garage does for a living. Reach out.

There is a sentence that gets said in every workshop, every studio, every conservatory, in every century, by someone who has spent their whole life mastering one way of making things. The sentence is some version of that isn’t real art. It has been said about the pencil, the press, the camera, the phonograph, the synthesizer, the mouse, and now the prompt. The accent changes. The complaint does not.

I want to walk through the history of that sentence, because once you see the pattern, you cannot unsee it. And once you cannot unsee it, you stop being afraid of whatever tool happens to be scaring everyone this week.

The first person to panic was Socrates

Start at the beginning, or close enough. In Plato’s Phaedrus, Socrates tells a little story about the Egyptian god Theuth, who invents writing and proudly presents it to the king as a gift that will make people wiser and improve their memory. The king is not impressed. He warns that writing will do the opposite. People will stop remembering things and start trusting marks on a page instead. They will seem to know a great deal while actually knowing nothing, because the words cannot answer a question or defend themselves.

Sit with that. The most foundational technology of human civilization, the one that lets me reach you across distance and time right now, was greeted by one of history’s great minds as a threat to genuine knowledge. He thought the new tool would hollow us out.

He was not entirely wrong about what we would lose. He was completely wrong about what we would gain.

The scribes saw the press as the enemy

Fast forward to the fifteenth century. The printing press arrives, and the people who feel it most sharply are the monks and scribes who have spent their lives copying books by hand. A German abbot named Johannes Trithemius wrote a whole treatise, In Praise of Scribes, defending the holy labor of hand-copying against the cold mechanical reproduction of print. Copying by hand, he argued, was an act of devotion that printing could never match.

Here is the detail I love. To get his argument out to as many people as possible, Trithemius had it printed. He could not resist the reach of the very machine he was warning against. The tool he distrusted was already more useful to his message than the craft he was defending.

They laughed at the Impressionists

By the 1870s the threat was not even a new machine. It was a new way of seeing. When a group of French painters showed work that looked loose, unfinished, full of visible brushwork and light instead of polished surfaces, the critics tore into them. One reviewer, Louis Leroy, mocked a Monet canvas titled Impression, Sunrise and sneered that the whole lot of them were mere “impressionists,” painters of sketches who could not be bothered to actually finish a painting.

The insult stuck. The painters kept it. Today the word he meant as a slur hangs over a wing of nearly every major museum on earth. The academy that defined “real” painting in 1874 is a footnote. The people they laughed at are the canon.

Painting was supposed to die when the camera arrived

Then came the machine that was truly going to end it all. When photography matured in the mid nineteenth century, painters genuinely believed it was the end of their art. Why would anyone pay for a painted portrait when a camera could capture a face in seconds, perfectly, cheaply? Legend has it the painter Paul Delaroche took one look and declared that from that day on, painting was dead. (Whether he actually said it hardly matters. Plenty of people felt it.)

The poet Charles Baudelaire went further and dismissed photography as a refuge for failed painters, a servant to art at best, never art itself. A machine could not have a soul, so its pictures could not either.

Painting did not die. It did something far more interesting. Freed from the job of literal representation, which the camera now handled better, painters went and invented modern art. No camera, no pressure to abandon realism. No abandoned realism, no Impressionism, no Cubism, no abstraction. The tool everyone thought would kill painting is the reason painting got weird and brave and alive.

Sousa called the phonograph a menace

In 1906 the composer John Philip Sousa published an essay with the wonderful title “The Menace of Mechanical Music.” He was furious about the phonograph. Recorded music, he argued, would destroy the amateur tradition. Why would families gather around a piano and learn to play and sing together when a machine could do it for them? He predicted the decay of musical skill, the withering of the human voice, a nation of passive listeners instead of makers. He called recorded sound “canned music,” and he did not mean it kindly.

Some of what he feared came true. Fewer of us sit around a piano. But he could not have imagined that the same technology would put Robert Johnson, Aretha Franklin, and a thousand voices from a thousand traditions into the ears of a kid in a town that no orchestra would ever visit. The machine he called a menace became the single greatest engine for spreading music in human history.

And on, and on

The pattern just keeps running. Early film was dismissed as a cheap fairground novelty, beneath the dignity of real theater. Jazz was condemned as crude, degenerate, dangerous to public morals. The electric guitar was not a real instrument. The synthesizer was cheating. The drum machine would put drummers out of work and strip music of its human pulse. Sampling was theft, not composition. Photoshop meant photographers were no longer photographers. Digital painting was not painting because your hand never touched a physical surface. Computer animation had no soul next to drawn-by-hand cels.

Every single one of those tools is now simply a tool. We no longer argue about whether a Stratocaster is a real instrument. We argue about whether someone wrote a good song with it.

What the panic always misses

So here we are with artificial intelligence, and the same sentence is being said again, in the same tone, by people who feel the ground moving under a craft they love. I understand the fear better than most. I make things with my hands and with machines, with chisels and code, and I have felt that flicker of wait, does this still count more than once.

But look at what the panic gets wrong every single time.

The complaint is never really about the tool. Socrates was not worried about ink. Trithemius was not worried about movable type. The painters were not worried about lenses and silver salts. The complaint is about the loss of hard-won mastery, the fear that a difficult skill is about to be made easy, and underneath that, a quiet terror about identity. If anyone can do the thing I spent my life learning to do, then who am I.

That is a deeply human fear and it deserves compassion. But it is a fear about the maker, not about the art. And it has been wrong every time, because it confuses the difficulty of a technique with the value of a work. Those were never the same thing.

The thing that actually survives

Walk through any museum, listen to any song that has outlived its century, read any story that still grabs you by the collar, and ask what you are actually responding to.

You are not moved by the chisel marks. You are moved by the Pietà. You do not care that the cave painters at Lascaux used ground ochre and the charred end of a stick. You care that seventeen thousand years ago, in the absolute dark, someone held up a flame and reached out to press a hand against the stone and say I was here, I saw these animals, I was alive. The pigment is gone from memory. The reaching is not.

The tool is the most forgettable part of any work of art. It is the scaffolding. Nobody weeps at the scaffolding.

What survives, across every form and every century, is always the same handful of things. The message. The story. The feeling. The fingerprint of a real human consciousness trying to tell another human consciousness what it is like to be alive. That is the cargo. Everything else, every brush and lens and string and circuit, is just the truck it rode in on.

Which brings me to what I make

I am not writing this from outside the argument. I have spent a good while now building things in a form most people do not yet have a word for, and the missing word is half the point.

I call them Imagination Engines. Living Paintings. Interactive graphic novels. The Mech Simulator, the Starship ASMR Sim, the Tricorder Sim, Afterware, The Forgotten One, Not Wanted/Not Forgiven. People reach for the closest word they already own and call them games, and they are not games. There is nothing to win and nothing to lose. They reach for simulator, and they are not simulators either. They are not trying to model the real world or test your skill against it. They are doing what a painting does. They are putting you somewhere. The only difference is that in mine you can lean in and turn a dial, and the somewhere leans back.

That is the whole experiment. Atmosphere over challenge. Mood over mastery. The small specific feeling of sitting in a cockpit at three in the morning, alone with the hum and the lights and the slow sweep of a scanner across nothing in particular. A landscape painting with a pulse. A graphic novel you can sit inside of.

If that sounds like a small ambition, look back through the history above. Every new form on that list was dismissed at first for being too easy, too passive, too gimmicky, too unserious, until somebody used it to say something the older forms could not say. I am not claiming I have done that. I am claiming the form can, and that somebody is going to, and the people who do it will not be the ones guarding the old fences. They will be the ones who picked up the new tool and pressed a hand against the new stone.

Where that leaves us

This is the whole reason I keep “ideas over tools” nailed to the wall of how I work. Not because tools do not matter. They matter enormously, and I love them, the more obscure and dangerous the better. But a tool is a means, never the meaning. The soapstone carving, the laser-etched slate, the line of firmware, the chapter of a novel set in these mountains, they are all the same act underneath. A person, reaching out of the dark, trying to say something true.

To make is to be human. That was true with a burnt stick and it is true with a neural network, and the only question worth asking has never changed. Forget whether the tool is real. Ask whether the thing you made with it is honest, whether it carries a message, whether it makes another person feel less alone.

Get that right, and history is on your side. It always has been. The people who master the new tool and pour something true through it are the ones we remember. The people who stood at the door insisting the new thing was not real art are the ones whose names we have to look up.

Pick up the tool. Any tool. Then say something only you could say.

Annie Dillard, The Writing Life

I have always kept journals. Spiral notebooks, leather-bound things, voice notes, a stack of index cards from 2008 I keep meaning to scan. The problem with all of them is the same problem. You can remember what you felt. You almost never remember what was happening.

Open a journal from five years ago. You wrote that you were anxious. About what? You wrote that the world felt off. Off how? The cultural texture of that day is gone. What was on the radio, what was on Wikipedia’s front page, what the air pressure was doing, where the moon was in the sky. None of that survives. The weather report from the day you got the bad phone call is gone forever. The headline you scrolled past on the day you decided to quit your job is gone forever. The world was doing something. You did not write down what. The global context is lost to the ages.

So I built a thing. It is called MILEPOST.

A marker, not a metric

Out along the old C&O Canal Towpath hat runs near my place there are still a few of the original mile markers. Cast concrete posts about knee high, with a number on one face that indicates the miles left until you reach Georgetown in Washington, D.C. The C&O is a 184.5-mile long National Park now. The canal boats are gone mostly. The markers are still there because they were built to be there, forever, and they mostly are.

That is the spirit. A milepost does not measure your performance. It does not optimize anything. It marks a point in space and asserts: this was here, and so were you. Then it gets out of the way.

When you sit down to write a journal entry in MILEPOST, two things happen at the same time. You write whatever you would write in any other journal, in plain text, on a manila-paper background that is supposed to remind you of a clipboard or a field guide page. While you are writing, the instrument is quietly going out across the internet and pulling down everything it can find about the world you are sitting in.

Where you are. What time. Weather conditions, dewpoint, barometric pressure, whether the pressure is rising or falling and how fast. Air quality and pollen counts. The Kp index. Solar wind speed. The moon’s phase, age, and illumination. The Dow close. Bitcoin’s price. The crypto fear and greed index. What song is number one on the Apple Music chart right this minute. What article Wikipedia chose as the day’s featured. Today’s Quote of the Day on Wikiquote. The nearest active wildfire and how far away it is. The current US Drought Monitor classification for your county. The METAR from the closest airport. The most recent eBird sighting in your area. What is trending on Hacker News, on Reddit, on GitHub. NASA’s Astronomy Picture of the Day. The latest xkcd. The most recent arXiv paper in the field you care about. Where the International Space Station is overhead right this second.

There are over forty of these signals. Some are weather. Some are markets. Some are sky. Some are culture. Some are infrastructure. None of them, individually, matter very much. That is exactly the point. What you are building, over a year of entries, is texture. The dataset is not the goal. The dataset is the answer to the question what was the world doing while I was thinking this?

What is built

MILEPOST is four single-file HTML applications. You open them in a web browser. They do everything in the browser. There is no backend, no account, no login. Nothing you type goes anywhere except files you save to your own machine.

Field Instrument 003. The capture page. Open it, write your entry, click capture. The instrument fetches everything in parallel, lets you watch the network conversation tick by in a log down the right side of the screen, and gives you a JSON file plus a PDF you can save. The PDF looks like a calibration certificate from a Cold War instrument lab, because that is what felt right.

MILEPOST Reader. Drag a folder of your saved JSONs onto it. It renders any entry as a readable page, with all of the data flowing through clean typography. You can leaf backwards through your archive the way you would leaf backwards through a notebook.

MILEPOST Analyzer. Same drop zone, different question. Once you have a few dozen entries built up, drop the whole folder onto the Analyzer and it tells you what is correlated with what. Your mood tends to be higher when the barometric pressure is rising. Your focus collapses on overcast days. You consistently feel less energetic on the days the market drops more than two percent. The Analyzer is honest about sample size. With ten entries it warns you that almost everything you see is noise. With a hundred entries it shows you what is actually there.

MILEPOST Status. A diagnostic page that pings every data source and tells you which are reachable from where you are sitting. Some sources require a CORS proxy because their servers refuse cross-origin browser requests, so the Status page also tells you whether your proxy is working and which signals are flowing through it.

How it relates to the principles

This project is what every single one of those Design Principles I wrote a year ago looks like in practice. I did not set out to demonstrate any of them. I set out to solve a problem I actually have, with the materials in front of me. Then I noticed, looking at what I had built, that every choice was a principle.

#14, reuse what you’ve got. Every data source MILEPOST queries is a free public API that someone else already built and runs. NOAA’s Space Weather Prediction Center. The US Geological Survey. Open-Meteo. Wikipedia. Wikiquote. The Federal Reserve Economic Data service. The Apple Music marketing RSS feed. NASA APOD. arXiv. I wrote no scrapers. I run no server. I am piggybacking on the open data infrastructure of the world. My junk drawer is the entire public internet.

#20, design for future you. This is the whole project. You will not remember what the world was doing. The world will not remember either. Write it down. Save the JSON. Future You will be grateful for the texture.

#21, design for the next pair of hands. The whole thing is open source, GPL-3.0, on GitHub. One HTML file per surface. No build step. No npm install. No framework. If you can open a text editor and read JavaScript, you can fix any bug, add any data source, change any color. The source code is the manual.

#24, build like you might need to escape with it. Single file. Save the HTML to a thumb drive. It works without internet for everything the browser can do locally, things like sun position, moon phase, planetary positions, anything computed in JavaScript with no network call. When the internet comes back, the rest fills in. The whole stack fits on a floppy disk if floppy disks still existed.

#25, optimize for repair, not perfection. When a data source breaks, and they do, you fix that one fetcher in that one file. There is no dependency tree. There is no node_modules. You ship the patch by copying one HTML file to your web server. The thing that lets MILEPOST exist at all is that nobody has to maintain it. Including me, most of the time.

#28, if it’s worth building, it’s worth sharing. Hence this post, hence the GitHub repo, hence the public URL. If you would find this useful, use it.

What it is not

MILEPOST is not a productivity tool. It is not a habit tracker. It is not a quantified-self device that wants to optimize your sleep. It will not nudge you. It does not have streaks. It does not gamify anything. There are no notifications. There is no leaderboard.

It is a journal. The data is wallpaper. The point of the wallpaper is to let you remember what room you were standing in.

I have been using it for a few weeks now and the strangest thing happens. I find that writing in it makes me more present, not less. The instrument is doing the work of looking around and noting what the world is doing. That frees me up to look at myself, which is what a journal is for.

How to use it

Go to mbparks.com/milepost. Bookmark it on your phone. Open it when you want to write something down. The first time it runs it will ask for location permission. Grant it or not, your call. Without it the instrument falls back to IP geolocation, which is less accurate but works fine.

Write. Click capture. Save the files somewhere you will not lose them. Build up a few weeks of entries. Then drop the folder into the Analyzer and see what you find.

You will need a CORS proxy for some of the data sources, because the modern web blocks scripts from talking to most servers unless those servers explicitly invite cross-origin requests, which most do not. The Status page explains all of this. You can use a public proxy, or run your own using the Cloudflare Worker script that ships with the repo. The whole thing costs zero dollars to run for personal use.

The source is on my GitHub under GPL-3.0. Pull requests welcome. Bug reports welcome. Forks especially welcome. If you build something with it, or build something better than it, tell me. I want to know what your version looks like.

MILEPOST is for everyone.

A small admission. I have spent more of my life than I want to count staring at someone else’s YouTube channel, scrolling, scrolling, scrolling, trying to answer one question. Is this person on the way up, on the way down, or just there. The platform itself will not tell you. It gives you total views, the subscriber count, and the warm fog of vibes. That is the whole dashboard.

So I made a tool.

It is called View Ledger. It is one HTML file. You open it, you paste a free Google API key, you type a channel, and a few seconds later you get a real read. Cadence. Reach. Engagement. Whether the thing is heating up or cooling down or just sitting there. Estimated revenue, if you want to play that game. The full catalog as a sortable table you can export. No login. No server. No tracking. It runs in your browser and goes home when you close the tab.

I made it for me. I am sharing it because I think it is useful, and because the journey of building it taught me something about honest analytics that I keep coming back to.

The Itch

I run Green Shoe Garage. I write here. I publish on YouTube. I watch other people’s channels. Some are friends. Some are competitors. Some are heroes. I want to know how they are doing. Not their bank balance. Their trajectory.

YouTube hides that on purpose. The analytics that would tell you live behind the owner’s login. The public API gives you lifetime totals, which is like trying to read a heartbeat from a photograph.

But there is a way. The Data API exposes every public upload’s individual stats. If you pull every video, you can compute the trends yourself. It is fiddly. It involves walking a playlist. It is exactly the kind of thing I love. So I started.

The First Version Was Wrong

The first version of View Ledger did the obvious thing. It pulled every video, divided views by days online to get a “views per day,” compared the newest videos to the oldest, and printed a verdict. Gaining momentum. Cooling off. Holding steady. It looked very confident.

It was lying.

The bug took me a while to see. A YouTube video gets most of its views in the first few weeks. After that, it tapers off and accumulates slowly forever. So an older video has a lower average-views-per-day than a newer one of identical popularity, just because the slow tail dragged its average down. The math I was doing made every channel look like it was heating up. The math was punishing time.

Worse. A channel that had not posted anything in three years still read as “Gaining momentum” if its old videos happened to be evergreen and kept slowly accumulating. There was no check for alive.

I had to throw the verdict out and start again. This is the part of the project I am proudest of.

What I Built Instead

The new verdict has two stages. First, an activity gate. The tool measures how often the channel posted historically, and how long ago the last upload was. If the silence is past about two and a half times the channel’s normal posting gap, with a six-month floor, the verdict reads Dormant and refuses to call a trend. Trends do not happen to corpses.

Then for live channels it does not look at one signal, it blends four.

That headline at the top, Heating up, comes from a weighted blend of:

• Reach. Median lifetime views of the newest third of the catalog versus the oldest third. Not views-per-day. Total views. Among videos at least 90 days old, so the steep-tail bias is mostly out of the system.

• Comment rate and like rate. Engagement as a share of views, recent versus older. These are ratios, and ratios stabilize fast. A video’s like-rate is roughly settled within weeks while its view count keeps drifting forever. That makes them a much cleaner read of “is the audience getting more invested” than raw view counts.

• Cadence. Whether the gap between uploads is shrinking or widening. Pure timestamps, completely age-independent, a perfect effort signal.

Each gets a direction. Each gets a weight. The blend produces the headline. The table beneath shows the work. A channel cooling on views but heating on engagement is right there, in plain sight. Not buried in a number.

The point of the sub-signals is that I do not want anyone, including me, to trust the headline blindly. If you are going to give a one-word verdict on someone’s creative output, you owe the reader the receipts.

The Bug That Taught Me the Most

There is one more layer in there worth talking about, because it is what made me trust the tool.

A channel can fake an “uptick” by pivoting to Shorts. Shorts pull big view counts, especially after YouTube changed how they count Shorts views in March 2025. So if a channel’s newest third is mostly Shorts and the oldest third is mostly standard uploads, the reach signal will read off the charts even though nothing real changed. The channel just changed format.

I tested this. I built a fake channel that did exactly that. Recent videos were all Shorts pulling 400,000 views each. Older videos were flat standard uploads. The old logic would have screamed “GAINING MOMENTUM.” The new logic detects the format shift, compares standard-uploads-only, finds the actual underlying trend was flat, and prints Stagnant. The little phrase next to the reach signal says “format mix shifted, so this compares standard uploads only.”

I cannot tell you how satisfying that was. Honest defeat of a confounding variable. That is craftsmanship.

What Else Is in There

Once you have pulled the catalog, you might as well look at everything.

The catalog tab is a sortable table of every video. Views, views per day, length, estimated revenue, likes, comments, thumbnails, badges for Shorts and livestreams and made-for-kids and AI-flagged content. CSV export. The bar chart up top is a quick visual answer to “which videos worked.”

The content tab asks a different question. What is this channel made of, and what kind of content works for it. Performance by content type, broken into Standard, Shorts, and Livestreams (a Shorts pivot looks different here than in the verdict). The tags the uploader set, ranked by the median views of videos carrying them, which is a more honest read of “what works for you” than vanity tags. A category breakdown, a caption coverage rate compared against views (correlational, not causal, the tool says so out loud), and the channel’s own keywords as chips. There is also a small reconciliation table that shows what YouTube reports for the channel versus what the tool fetched, because deleted and private videos exist and the gap is honest information.

The revenue tab is the place I am most nervous about. Real ad earnings are private. The tool estimates, by multiplying views by an assumed RPM, and clearly labels it as a guess. Shorts get their own RPM (they monetize at a tiny fraction of long-form). Livestreams ride with long-form. The country the channel is in sets a coarse default. You can plug in a production cost per video and get a profit number. It is back-of-envelope, on purpose. But it is useful back-of-envelope, and I caveat it everywhere it appears.

The tracking tab is the only honest answer to “is this channel really growing.” A single pull cannot tell you, because YouTube only hands back lifetime totals as they stand right now. So the tool lets you save a snapshot today and load it back next month, after a fresh pull, to compute actual views gained, actual subscribers added, actual marginal subs per new video. Run it on a calendar and you build a real longitudinal record.

What I Got Wrong

A few things I want to be honest about.

The momentum verdict is still a single snapshot. The ratio signals carry a little age drift (older videos accumulate slightly different audiences than their first weeks). The blend weights are a judgment call, not science. I show the weights and the underlying numbers because I do not want the verdict to be a black box, but it is a verdict, not a measurement.

The revenue estimate is not your channel’s earnings. It is a rough multiplier. Real numbers live behind your login. The tool tells you this on the page.

Shorts detection is a duration heuristic. There is no “is a Short” flag in the API. YouTube allows Shorts up to about three minutes now, so the cutoff is adjustable.

A lot of the analyses are correlational. Captioned videos in this channel get a few percent more views than uncaptioned ones. The tool says so. It also says, in print, that this is not proof captions cause reach. They are just associated. That distinction matters.

Why I Made It This Way

I think there is a version of this tool that hides all that. That gives you a single confident number, a green or red arrow, and lets you feel smart. I am not interested in building that tool. It would not be useful and it would not be true.

The reason View Ledger has a verdict at all is so you have somewhere to start. The reason every signal is exposed underneath the verdict is so you can argue with it. The reason the limitations are printed on every tab is because I would rather you trust the tool a little less and use it a little more carefully.

I am of an age where I grew up taking things apart to see how they worked. That is still the right move. Use the tool. Click around. Pull a channel you know well and see if the verdict matches your gut. If it does not, look at the sub-signals and figure out which of you is wrong. Most of the time, in my experience, it has been me.

How to Try It

View Ledger is a single HTML file. The source is on GitHub. The license is GPL-3.0. You will need a free YouTube Data API key from Google Cloud Console (about two minutes), and you will need a browser. That is the entire stack.

Pick a channel that interests you. Pull it. Save a snapshot. Come back next month. That is when the tool earns its keep.

If you build something with it, or find a bug, or have an idea for what to add, I want to hear about it.

The next thing I am thinking about is whether to let the snapshot history hold more than two points, so you can chart real growth across many pulls. That feels like the right next move. But I want to use the current version for a few months first, on real channels, and see what I learn before I add more knobs.

That, more than anything, is the lesson of this build. Make the smallest honest thing. Use it. Then let what you learn shape what comes next.

Read Online Here.

Download a Copy.

A few weeks ago I was poking around an open hardware repo on GitHub, trying to remember whether a board I’d cloned a while back had any decent ground stitching. Clicking on the .GTL file brought up a wall of text. Right. GitHub r

enders Markdown, PDFs, STL meshes, GeoJSON maps, even Jupyter notebooks natively in the browser. But Gerbers, the de facto industry format for getting a PCB fabricated, just sit there as raw RS-274X gibberish.

That mild irritation became a weekend project. I now have a Chrome extension that renders Gerber and Excellon drill files inline on any GitHub blob page, with proper top and bottom composite views, mouse wheel zoom, drag pan, 90-degree rotation, and an outline toggle for boards whose edge files are a little messy.

https://github.com/GreenShoeGarage/GitHub_GerberViewer_ChromeExtension

or

https://chromewebstore.google.com/detail/gerber-viewer-for-github/kjempphffigplmkbpjamikbfgpmdfbfn

What it does

Open any Gerber or drill file on GitHub. The extension fetches the raw file, parses it client-side using the tracespace v4 toolchain, and drops a preview panel above the raw text view. The original raw view is still there underneath, so nothing is hidden from you.

If the same folder contains a full layer set (top and bottom copper, mask, silkscreen, drill, outline), the extension also calls the GitHub Contents API to fetch the siblings, hands them to pcb-stackup, and assembles realistic Top and Bottom composite renders. Zoom anchors on the cursor, drag-to-pan keeps working in the rotated frame, the whole thing happens in your browser. No file content leaves your machine.

The real problems were the boring ones

The technical core of “render Gerber files in a browser” is well-trodden ground. Tracespace has been doing it for years and the libraries are excellent. The hard parts of this project turned out to be the messy edges of real-world hardware repos.

There’s a board on GitHub whose outline file (.gko) is full of fab markings, fiducials, and disconnected line segments rather than a clean closed polygon. Pass that to pcb-stackup and you get a render with the board boundary mangled where the segments don’t quite meet up. The fix is an Outline toggle that flips between “trust the file” and “use the union of features as the boundary.” Turns out plenty of legitimate boards exhibit exactly this pathology.

There’s also a long-standing quirk where Eagle’s standard drill extension (.drd) gets classified as an outline layer by whats-that-gerber, the upstream library that infers layer types from filenames. Pass an Eagle-style board to pcb-stackup with default settings and the drill positions get treated as additional board-edge geometry, producing weird artifacts and zero visible drill holes. A four-line content sniff that recognizes the Excellon M48 header and overrides the type fixed it.

I also tried to be clever and route the single-layer view through pcb-stackup for a realistic gold-on-FR4 look. Looked great on the Arduino Uno fixtures. Broke a real-world bottom copper layer by silently clipping content. Reverted in the next patch. Lesson logged.

What I keep relearning

Most of the time on this project went into edge cases I could not have predicted from the spec. The 60-request-per-hour unauthenticated GitHub API limit. The fact that some EDA tools encode ground pours as 500-plus thinly stroked lines instead of using G36/G37 region fills. The way GitHub’s React-driven blob view DOM keeps shifting under my content script. Soft navigation handling via Turbo events. None of these are interesting on their own. All of them were necessary.

This is something I keep relearning as a maker. The gap between “I can imagine the tool” and “the tool reliably works on the real-world inputs people will throw at it” is wider than it ever feels at the start. That gap is where most of the craft actually lives. Plan for it. Budget for it. Don’t be surprised by it.

Where to find it

The extension is open source under GPL-3.0. Source, install instructions, and the roadmap (multi-layer composite for inner planes, WASM rendering for dense boards, OAuth to lift the API rate limit) are at [link to repo]. Drag and drop install for now. Chrome Web Store eventually, maybe.

If you spend time browsing hardware repos on GitHub, give it a try and let me know what breaks. There are a lot of weird Gerber files out there and I have only seen a small fraction of them.

If you want me to build something similar for your project, hardware or otherwise, that is what Green Shoe Garage does for a living. Reach out.

https://github.com/GreenShoeGarage/InjectionMoldFromSTL

The setup

The premise was simple. Feed in an STL of a part. Get back two STLs, an upper half and a lower half, with all the features a real mold needs: sprue, runner, gate, vents, alignment dowels, optional ejector pins. The plumbing is mostly mesh boolean operations, and trimesh plus manifold3d handle that part well.

The first version was up and running fast. I tossed a gear STL at it, and it produced two halves that looked correct in any 3D viewer. Bounds were right. Watertight. Cross-sections through the parting plane showed a clean gear cavity, two vents, four dowel sockets at the corners. Job done, I thought.

It was not done.

Five bugs, in the order I should have caught them

Vents straddled the parting plane. I centered the vent box on the parting line, which meant each half got a 75-micron-deep slot. Geometrically present, functionally invisible. Real molds put the full vent depth on one half and let the opposite half’s flat parting face seal the channel.

Vents at evenly-spaced Y positions landed on tooth tips. A gear’s silhouette is mostly tooth tips reaching almost to the bounding box edge. Even spacing dropped one vent right where the tooth was practically touching the mold edge, leaving a stub two millimeters long.

Silhouette-aware placement still anchored the vent inner edge to the bounding box. When the silhouette analysis correctly found a deep tooth valley, the vent box’s inner edge stayed at a fixed offset from the bbox, sitting in empty space that did not overlap the part. Result: a slot in the mold, but no path to the cavity. Worse than the original bug, because it looked correct in renders.

Dowel pins at four-times-pin-radius from the mold edge ended up inside the part bounding box. Pin position collided with vent position. In a real mold this means plastic leaks past the alignment pin into the vent channel.

The vent’s bottom face sat exactly coplanar with the parting-plane cut. Boolean operations on coplanar surfaces leave non-manifold edges. The upper half came back with four broken faces and was no longer watertight.

Each fix exposed the next bug. Each bug had been invisible in the cross-section previews I had been trusting.

The lesson

After bug number three, I switched from rendering cross-sections to point-sampling the actual mesh. Pick a spot inside the slot, ask mesh.contains([[x, y, z]]). If it returns True, that point is solid mold material. If False, it is void. Run this at ten points along the slot’s path from cavity to mold edge. If any of them are solid, the slot is broken.

That single check would have caught bugs three, four, and five immediately. It is also the kind of test you can write into the build pipeline so the same bug does not come back later.

The renders are still useful for finding things you did not think to test. The tooth-tip vent placement was something I would not have looked for if I had not seen the picture. Eyes catch silhouette issues. Point sampling catches connectivity issues. Use both, but trust the latter.

What it does now

The tool slices the part at the parting plane to find the actual silhouette, places vents at the deepest tooth valleys, anchors each vent’s inner edge to its specific silhouette point, opens the slot through the parting face by extending the vent box across the plane by a micron, and puts the dowels in the padding region between the part bounding box and the mold edge. Both halves come out watertight. Both vents connect to the cavity. The audit script confirms it.

Five bugs and a lesson, and now a tool I can throw any reasonable part at and get a usable first-pass mold in seconds. Worth the evening, even if it took five.

Here’s the question I keep poking at: if you strip a generative model of every well-formed prompt, no curated nouns, no “in the style of,” no mood board, no helpful adjectives, and just shove pure entropy through it, what comes back?

I’ve been running two experiments to find out. One is dumb on purpose. The other is dumb on the radio.

Experiment One: 100 Random Word Visions

I had an LLM cough up 100 random words. No theme. No vibe. No “make these cohere, please.” Just one hundred unrelated chunks of human language pulled from whatever the model felt like generating that day. Then I fed those words one by one into a video model and let it dream up an experimental short, one micro-vision per word.

The result is a stitched-together fever dream. Some clips snap together with weird accidental rhyme. Others are completely unrelated. The whole thing has the rhythm of channel-surfing through a parallel cable system that only exists inside a server rack.

Here’s the wild bit, though. The transitions feel intentional even though nothing about this was. Your brain does the editing job for free. You start narrating connective tissue between “wagon” and “elapsed” and “blueprint” because that’s what brains do. They reach for story even when there isn’t one. The AI didn’t compose anything coherent. You did, after the fact, in your head.

That’s a wild thing to watch happen in real time.

Experiment Two: Paintings From RF Noise

The second one is more physical, and honestly more fun. I plugged an RTL-SDR dongle into my laptop. That’s a $30 USB radio dongle and wrote a Python tool that:

1. Tunes to a random frequency between 24 MHz and 1.7 GHz

2. Listens for a couple of seconds

3. Renders the IQ samples as an image: spectrogram, constellation plot, or polar phase map

4. Chains a randomly-chosen subset of sixteen filters over the result (chromatic shift, kaleidoscope, bloom, datamosh slice shifts, the whole funk pile)

5. Drops the PNG in a date-stamped folder with a JSON manifest of every parameter, so when one of the random outputs is great I can reproduce or remix it precisely

The radio is the random number generator. The actual electromagnetic ambient mess of my workshop: neighbor’s wifi, FM broadcast bleed-through, an ADS-B aircraft transponder ten miles overhead, whatever else is in the air. It is doing the creative work. The code is just a translation layer between physics and pixels.

Code’s on GitHub →

Some runs land on a frequency where nothing’s transmitting and the output is a smooth Gaussian blob, the visual equivalent of a held breath. Other runs catch a busy ISM band or an FM station and you get structured rings and lattices that look like somebody tried to sketch a circuit diagram in a dream.

I never know which one I’m going to get. That’s the whole point.

I then took the raw data (a .csv file) and fed it directly into an AI tool. I got this back:

So, does AI dream in noise?

Here’s what I think is actually going on with both of these projects, and why I keep building them.

• A generative model is a giant compressed atlas of human pattern. Prompting it well is asking the model to navigate that atlas to a specific destination.

• Prompting it with noise is asking it to navigate to no specific destination. This means the model has to fall back on its own internal gravity. The places it drifts toward when nothing’s pulling on the wheel.

• That drift is, I’d argue, the closest thing you can get to seeing the model’s own aesthetic. Its defaults. Its dreams. Whatever you want to call it.

The radio version goes one notch further. It introduces an entropy source the model has no relationship to whatsoever. The actual electromagnetic state of a room in western Maryland on a Tuesday afternoon. The model didn’t train on that. Nobody did. It’s just there. It’s only ever been there.

When I generate art from it, I’m not really making art. I’m making a transcription of a moment of physical reality nobody, human or machine, has ever bothered to pay attention to before.

The point

I’m a tradigital craftsman. I like making things with my hands and my code and the weird overlap between the two. But I also like asking the tools I use what they’re actually doing when nobody’s micromanaging them. I want to find more ways to feed these tools with noise from the real-world.

Every prompt-engineered output is, in some sense, a duet between you and the model. Both of you are steering. Pull your hands off the wheel and feed the model garbage on purpose, and you start to see what it does when it’s alone in the room.

Sometimes it’s beautiful. Sometimes it’s a Gaussian blob. Both answers are interesting.

More noise to come.

*Word soup used to generate this article’s image:
ablaze, bungalow, cleaver, dapple, ewer, flounder, grapple, hatchet, idle, jangle, kindle, looseleaf, mottled, niggle, oblong, perch, quickstep, rasp, scribble, twiddle, unhinge, vex, wobble, yelp, zoom, ample, brisket, chortle, dimple, ease, fizzle, grumble, hover, itch, jostle, knit, lounge, muddle, nudge, oust, pluck, quack, rouse, smudge, trudge, undo, veer, waft, yank, zap, amble, brood, chuckle, dawdle, ebb, fumble, gulp, heave, ink, jab, knack, lurch, mumble, nuzzle, ogle, prod, quench, rummage, snicker, totter, unwind, vault, wheeze, yawn, zest, awash, brisk, clamp, dodge, evade, flick, gnash, huddle, irk, jolt, kink, limp, mope, nod, oaf, peer, quaff, ruffle, scour, tug, undulate, vie, whisk, yelp, zigzag, antic, bluff

I like making things. I also like collecting things that speak to me as “well designed”. I have opinions on what makes an object well-designed or not. Obviously, this is skewed to my own aesthetic and may not work for everyone. But for me, an object is designed well if...

1. I can immediately tell what it is, what it does, and how to interact with it. No user manual required.

2. All parts, including form, mechanics, electronics, and software, feel like one thing.

3. It still works and looks right under real-world use.

4. It invites interaction, not just observation. Interacting with the object sparks a sense of wonder and magic.

5. I can understand it, modify it, and keep it alive over time.

6. It uses materials honestly and appropriately.

7. It has meaning, character, or emotional weight beyond function.

8. I can see how it is made, and it embraces both traditional and modern tools in its construction.

9. It is minimally maximalist, rich and expressive, but nothing is unnecessary.

10. It does not exploit the user, compromise safety, violate privacy, or create downstream harm.

I’ll be the first to admit it: I didn’t want to like this. As a “maker” who values the grit of technical implementation, the idea of “vibe coding”—using high-level AI prompts to manifest a functional game—felt like a betrayal of the craft. I expected the results to be hollow, a low-effort imitation of creativity.

I think I was wrong.

I am of an age where I grew up with text-based adventures. I loved them dearly. For a while now, I have wanted to make my own. I wanted to take my life journey and build something from the good and the bad memory piles (see Doctor Who episode “Vincent and the Doctor”). In building The Forgotten One, I realized that shifting the burden of syntax to an AI didn’t diminish my role; it fundamentally changed it. It moved me from being the software mechanic to being the Digital Craftsman.

The End of the “God View”

The greatest tragedy of solo game development is that you can never truly play your own game. You know where every ghost is hidden because you’re the one who put them there. You’ve read every line of dialogue a thousand times during debugging.

Vibe coding solves the “spoiler” problem. Because I am defining atmospheres rather than exact sequences, I don’t actually know all the details. I know the vibe of the nursery—the faded blue paint, the one-eyed bear—but I don’t know exactly when the music box will trigger its three rising notes.

I’ve authored the “why,” but the machine handles the “how” and the “when.” This means I get to be the First Explorer of my own world. I can sit down, run the code, and actually feel the tension because I’m experiencing the execution for the first time, right alongside any other player.

From Software Dev to Game Author

Traditional development feels like plumbing. You spend 90% of your time ensuring the pipes don’t leak so that the 10% of “story” has a place to go. Vibe coding feels much more like painting.

• Software Dev is about the mechanics: “How do I map these coordinates?”

• Game Authorship is about the intent: “Why does this room feel heavier than the last?”

When you write a game like a story, the narrative becomes the primary driver of the logic. You are layering textures—the smell of old paper, the pressure in the walls, the warmth of a memory. You aren’t just writing code; you’re conducting a mood.

The Cat is Out of the Bag

Let’s be real: AI is here. The question for us now isn’t whether we should use it, but how we use it to bring out our best versus becoming its slave.

If we use AI to do our thinking, we’ve lost the plot. But if we use it to handle the “drudge work” of logic so we can focus on the soul of the project—the craftsmanship of the experience—we reclaim our creative agency.

I started this project as a skeptic, convinced that “real” games required manual labor at every level. I ended it as a resident of a house I built, yet barely recognize—and for the first time in my life, I’m actually having fun playing a game I made. I might be wrong on all this. But then again, maybe I am just evolving. Just like the journey of life and death.

You can try the game here.

Read Online Here.

Download a Copy.

The principles that guide my creations include:

1. Polymath Mindset

Explore. Experiment. Cross boundaries.
Curiosity-driven making that blends disciplines without permission.

2. Tradigital Craftsmanship

Honor traditional skills. Embrace new technology.
A deliberate fusion of past and future. Hand tools and digital fabrication as equals.

3. Tools Are Extensions, Not Hierarchies

A laser cutter is just a hammer with better marketing.
No tool is sacred. CNC, code, chisels. They’re all means to create.

4. Anti-Gatekeeping Creation

Reject and prevent professional priesthoods.
Making is not exclusive. Everyone has the right and ability to build.

5. Creation as Human Expression

Make to celebrate being human. It is a ritual.
Not everything needs utility. Creation itself has intrinsic value.

6. Sustainable Pragmatism

Maximize reuse. Minimize consumables.
Design with material awareness and long-term responsibility.

7. Intentional Maximalism

More is more when it means something.
Rich, layered, expressive design that reflects lived experience.

8. Modular & Evolving Systems

Nothing is ever finished.
Design for iteration, adaptability, and continuous transformation.

9. Interactive by Nature

Objects should invite engagement.
Tactile, responsive, and participatory experiences over passive ones.

10. Radical Transparency

Show the process. Show the flaws.
Expose how things are made. No black boxes.

“Yeah. Yeah, but your scientists were so preoccupied with whether they could that they didn’t stop to think if they should.”

— Jurassic Park (Dr. Ian Malcolm)

I think about this line more often than I probably should.

Not because it’s clever, or because it’s a pop-culture shorthand for “ethics in tech,” but because it captures something I’ve seen repeatedly in real engineering work: the quiet way momentum replaces judgment.

We live in a moment where technical capability is advancing faster than our willingness to sit with its consequences. Speed, scale, and disruption are treated as virtues almost by default. If something can be built, deployed, and grown quickly, that alone is often taken as evidence that it should exist. Reflection, restraint, and responsibility are framed as friction—nice ideas, but luxuries we can’t afford under real deadlines.

The result is a landscape full of systems that are impressive on paper and fragile in practice. They function, but only within narrow assumptions. They scale, but not gracefully. And when they fail, they tend to fail in ways that feel less like accidents and more like inevitabilities we declined to notice.

Most of the serious failures I’ve seen aren’t the result of incompetence. They come from narrow framing. From incentives that reward delivery over durability. From design conversations that never quite make room for uncomfortable questions early enough to matter.

Engineering decisions don’t happen in a vacuum. Every system encodes values—sometimes deliberately, often accidentally. When we focus only on can we build it, we quietly defer harder questions:

Who bears the risk when this system fails?

What assumptions are we making about users, operators, or downstream communities?

What happens when this technology scales beyond its original context?

What tradeoffs are being hidden behind efficiency, automation, or abstraction?

Those questions aren’t philosophical in the abstract. They’re architectural. They shape interfaces, defaults, error handling, and escalation paths. They determine whether a system fails loudly or silently, locally or globally, recoverably or catastrophically.

I’ve come to believe that ethics, when applied seriously, isn’t a brake on engineering—it’s a design constraint. Like gravity, material limits, or latency. Ignoring it doesn’t make it go away; it just guarantees it will show up later, under worse conditions and with fewer options.

Trust, for example, isn’t something you add at launch with messaging or polish. It’s an emergent property of systems that behave predictably, transparently, and fairly over time. If trust isn’t designed into the architecture—into how decisions are made, how failures are handled, how edge cases are treated—it won’t survive contact with reality.

What worries me most is not that we sometimes get things wrong. Engineering has always involved uncertainty. What worries me is how often we avoid asking should we because the answer might slow us down, complicate the roadmap, or force tradeoffs we’d rather postpone.

But postponing those questions doesn’t eliminate them. It just externalizes the cost—to users, to communities, to environments, or to the future.

I don’t think the answer is less technology. I don’t think it’s fear or paralysis or nostalgia for simpler systems. I think it’s better engineering—engineering that acknowledges consequence as part of the work, not an afterthought.

That means treating ethics as an input, not a post-mortem.

It means respecting abstractions without worshiping them.

It means being willing to say “we don’t know yet” when scale outruns understanding.

It means remembering that elegance often shows up as restraint.

The question isn’t whether we can build powerful systems anymore.

We’ve answered that.

The harder question—the one that doesn’t go away—is whether we’re willing to be accountable for what we set in motion.

Read Online Here.

Download a Copy.

Circuitsmith

A Circuitsmith is a modern craftsperson who shapes electricity the way a blacksmith shapes metal. They design and build physical systems that live in the real world—circuits, sensors, kinetic mechanisms, interactive objects. Their work happens at the intersection of engineering and craftsmanship.

Core ideas:

• Works with matter and electrons

• Builds hardware with a soul

• Blends electronics, mechanics, and design

• Values hands-on experimentation

• Sees circuits as expressive materials—not just functional

What they do:

• Prototyping with microcontrollers and analog components

• Building interactive sculptures or devices

• Repairing and repurposing old tech

• Exploring physical computing

Closest real-world analogs: hardware engineer • creative technologist • interactive artist • maker • electrical craftsperson

Bitwright

A Bitwright is a digital craftsperson—an artisan of logic and information who shapes behavior rather than matter. Like a playwright arranges scenes, a Bitwright composes software, code systems, and algorithms that give ideas form and function in the digital space.

Core ideas:

• Works with logic and code

• Designs behavior, systems, interaction flows

• Crafts clean, expressive code

• Sees software as storytelling through structure

• Believes code is a creative medium

What they do:

• Write embedded firmware or system logic

• Sculpt algorithms and interaction models

• Build custom tools or creative software

• Translate human intention into machine behavior

Closest real-world analogs: embedded software engineer • computational artist • systems designer • creative coder

1. Tradigital Exploration and Experimentation – Fuse traditional craft with emerging digital technology through hands-on experimentation.

2. Sustainable Re-Creation – Transform broken, discarded, or obsolete materials into meaningful new forms.

3. Modular Evolution – Build systems that adapt, upgrade, and change over time—art as a living process.

4. Human Connection Through Interaction – Invite participation to provoke reflection, emotion, and discovery.

5. Radical Transparency, Don’t Hide The Lines – Reveal the process of how things are made, celebrate imperfection, and honor the honest character of materials.

Read Online Here.

Download a Copy.

I, a human (I think), asked ChatGPT the following question:

Prompt:
How can the lessons learned of the photography versus painting as art debate inform the discussion around human and AI made art?

ChatGPT Said:
Great question. The 19th-century fight over whether photography “counted” as art maps surprisingly well onto today’s human vs. AI-made art debate. Here’s a tight set of lessons you can lift directly from that history—and how to apply them now.

1) “New tool” ≠ “no art”

Then: Early critics called photography a merely mechanical process; artists proved authorship lived in choices (framing, exposure, printing, retouching).
Now: With AI, authorship similarly rests in intent + constraint + iteration (dataset curation, prompting strategy, model fine-tuning, selection, editing, presentation).

Takeaway: Evaluate artistic decisions, not just the tool. Ask: What problem was the artist solving? What constraints were set? What was rejected and why?

2) New media find their own aesthetics

Then: Photography won legitimacy by leaning into what it did uniquely well (movement, candidness, seriality, reproducibility), not by imitating painting.
Now: AI art’s strengths are scale, combinatorics, probabilistic variation, and fast iteration.

Takeaway: Don’t judge AI only by how well it mimics human mark-making. Judge how it extends the visual/semantic space beyond human-only throughput.

3) Process transparency matters (but doesn’t define value)

Then: Pictorialists vs. straight photographers debated manipulation; both gained acceptance once processes were named and understood.
Now: Disclose model, dataset sourcing (at least categories), prompt/fine-tune steps, and post-processing.

Takeaway: Create a process label (like a wine label):

• “Human-only, analog/digital”

• “Human + AI (curated data; directed prompts; hand-edited)”

• “AI-primary (automated batch; minimal human selection)”

4) Indexicality, aura, and the “hand”

Then: Walter Benjamin’s “aura” vs. mechanical reproduction reframed value around context, not just uniqueness. Photography still developed forms of aura (vintage prints, signed editions, process rarity).
Now: AI outputs are infinitely reproducible, but aura can re-enter via provenance, editioning, performance/installation context, and live generation.

Takeaway: Build aura with edition control, cryptographic provenance, performance-based display, or time-bound generative runs.

5) Skill shifts, not skill disappearance

Then: Skill moved from brushwork to optics, chemistry, darkroom craft, sequencing.
Now: Skill shifts to data ethics, model steering, prompt engineering as design brief, multimodal compositing, curation.

Takeaway: Update curricula and juries to read AI craft (dataset design, failure-mode management, long-loop iteration logs).

6) Democratization + gatekeeping

Then: Cheap cameras broadened who could make images; institutions adapted with new canons and genres.
Now: AI lowers barriers even further; expect volume explosions and new folk/vernacular genres.

Takeaway: Curate with new rubrics (original problem setting, iterative risk-taking, conceptual coherence) instead of pedigree or tool purity.

7) Economic + labor questions must be addressed head-on

Then: Photo threatened portrait painters; new markets (editorial, advertising, art photography) emerged.
Now: AI threatens illustration and stock markets; new roles appear (model custodians, data curators, AI art directors).

Takeaway: Build fair-use norms, licensing schemes, and revenue-share models for training data; commission frameworks that explicitly price human direction.

8) Legal and ethical clarity enables cultural acceptance

Then: Copyright for photography matured; authorship became clearer.
Now: Clarify authorship (human intent), rights in training data, consent, credit, and disclosure.

Takeaway (policy sketch):

• Disclosure: Identify AI involvement and process level.

• Consent/Credit: Respect opt-out datasets; credit notable sources when practicable.

• Provenance: Attach verifiable metadata (CID/hash, model/version).

• Review: Flag sensitive content and bias audits for juried shows.

9) Hybridity becomes the mainstream

Then: Photo + paint, collage, photogram, mixed media flourished.
Now: Expect AI + photography + 3D + robotics + performance.

Takeaway: Stop binary framing. Curate hybrid categories: “Generative Assemblage,” “Performative Generation,” “Algorithmic Documentary,” etc.

A practical evaluation rubric (usable by juries, galleries, or teams)

1. Intent & Concept

• Clear inquiry or thesis? Novel question or perspective?

2. Process & Craft

• Demonstrable human direction (logs, iterations, dataset rationale)?

• Mastery of AI’s failure modes and constraints?

3. Form & Aesthetics

• Does it leverage the medium’s native strengths (variation, scale, recombination) rather than copy analog looks?

4. Context & Ethics

• Transparent provenance; considered stance on data use and bias.

5. Impact

• Resonance, originality, and contribution to discourse or practice.

Score each 1–5; publish the rubric alongside the show or portfolio.

Implementation quick-start (for creators and orgs)

• Creators

  • Keep an iteration journal (key prompts, forks, rejects, edits).

  • Ship with a process label + provenance file (model, version, seed if relevant).

  • When possible, license or self-source datasets; document consent posture.

• Galleries/Competitions

  • Require a disclosure card (tools, datasets, human role).

  • Judge with the 5-part rubric; allow hybrid categories.

  • Offer editioning guidance for AI works (caps, on-chain proofs, or time-windowed generation).

• Educators

  • Teach dataset ethics and prompt as design brief.

  • Assign projects that force medium-native exploration (e.g., controlled variation studies).

Bottom line

From photography’s path we learn: legitimacy arrives when we judge by artistic intent, process rigor, and medium-native contribution—not by tool purity. If we build clear norms around authorship, disclosure, provenance, and ethics, the culture will absorb AI as another powerful—sometimes radical—art medium, just as it did photography.

End ChatGPT Response
=========

What are your thoughts, fellow human?
The image above, human or AI? Why do you think that?

For the last several years, I have used an ArcDroid in conjunction with a plasma cutter and a water table. It does great, but my use case is for much thinner metals that a plasma cutter tends to destroy. For the record, I am at best an amateur machinist and even less of a welder. Earlier this year, I procured Xlaserlabs’ X1 Pro laser cutter/welder/cleaner.

Out of the box, it worked great as all three, albeit by hand. What I really wanted is a CNC laser, however. The Xtool Metal Fab rolled out shortly after, and while I love Xtool and own many of their lasers (P2, F1 Ultra, M1 Ultra), the Metal Fab is just too big for a basement machine shop like mine.

The marketing material for the X1 Pro mentioned it was possible to use it for CNC use cases, but provided limited details. After some research and testing, here is how I got my ArcDroid and X1 Pro to play nicely together.

Here is the wiring diagram:

First thing we need to do is to change out the DB25 external control cable. I purchased a breakout DB25 connector from Amazon (https://www.amazon.com/dp/B07DPCGMLN). I ran two pairs of 20AWG stranded wire, one to the external emergency stop. Do NOT just short the e-stop! The second pair of wires ran to torch connectors on the rear of the ArcDroid. As far as I know, polarity doesn’t matter for either connection.

• Pins 5 and 6 connect to the external e-stop.

• Pins 3 and 4 connect to the ArcDroid external torch control on the rear of the ArcDroid.

I purchased the ArcDroid Extended Torch Mount (https://arcdroidcnc.com/collections/arcdroid-accessories/products/extended-torch-mount) to mount the laser gun. Ensuring a slight 2-3 degree offset from vertical to prevent the laser beam from reflecting up into the gun. This means perfect round or straight cuts will be a challenge, if not impossible, so this might limit you to more artistic cuts versus strict tolerance parts.

UPDATE: I have designed a mount for the X1 Laser to attach to the ArcDroid. I am selling the STL file for a nominal fee over on Etsy.

Next, let’s talk about kiln shelves.

Lastly, I drained the water table, removed the slats, and cleaned up the rust. I placed shelving typically used in kilns (https://www.amazon.com/dp/B0FG8DTXN8) under the sheet metal I am cutting. This, in theory, will protect the bottom of the water table from getting cut by the laser. This will be useful when I need to convert it back into a water table for materials that require cutting with the plasma cutter. Whether or not this is the best, or even a safe, option is still undergoing testing. I sometimes even place sacrificial aluminum or steel bars on top of the kiln shelf to elevate the sheet metal closer to the torch head.

This is the result!

I am also using a California Air Tools 10020C 2.0 HP Ultra Quiet and Oil-Free Air Compressor, 10 Gallon Steel Tank with Wheels (https://www.amazon.com/dp/B0188XBTLY)

The settings for this cut of 1/16” stainless steel are as follows:

• 55% power

• 1000 Hz

• 100% Duty Cycle

• 90psi compressed air

I loaded up a .DXF file on the ArcDroid and made some settings changes (definitely test different values depending on material and thickness). This is still a lot of room for testing here. But for 1/16” stainless steel, I used these settings:

• 0” lead-in

• Cut on the center of the line

• Kerf: .003” or 0.08 mm

• Feed: 75 ipm or 32 mm/s

• Clear Z: 0.394” or 10 mm

• Pierze Z: 0.100” or 2.5 mm

• Cut Z: 0.079” or 2 mm

• Pierce Delay: 0.5s

• Off Delay: 0.25s

P.S.

While exploring 3D printed solutions to the problem of mounting the torch to the ArcDroid, I stumbled across the following things you can print for your ArcDroid:

1. ArcDroid Torch Holder

2. Sensor Covers for the ArcDroid