DEV Community: Keith Solomon

Weekend Rec Builds: 3D Print Estimator

Keith Solomon — Mon, 08 Dec 2025 04:27:52 +0000

This project started (as so many do) with a message from my brother with 2 links. He was looking at printing some stuff for his kid, and asked the inevitable question:

“How much filament will this use, and how long will it take?”

And there were only 100 individual STL files to check.

Sure, my slicer could give estimates, but opening each file, slicing it, and checking the stats was tedious and time-consuming.

If you’ve spent any amount of time around 3D printers, you already know the eternal struggle:

“How long is this going to take?”
“How much filament will this use?”
“Do I have enough left to print this without discovering sadness at 3 a.m.?”

So for this week’s Weekend Rec Build, I put together something I’ve wanted for a long time: a stand-alone, slicer-agnostic print estimator that can scan STL files directly and give you reasonably accurate numbers for filament length, filament mass, and print time. From the command line or a lightweight web interface.

The project lives here: https://github.com/Solo-Web-Works/3D-Print-Estimator

Why Build This?

A surprising amount of 3D printing workflow friction happens before slicing.

If you maintain a library of dozens (or hundreds) of STLs, the usual preview-slice-estimate loop becomes tedious fast. I wanted something that works like a “pre-slicer inspector” — a little utility I can drop into any folder (or drop it into a folder in my path) and instantly get meaningful estimates.

Being able to run python estimator.py and get a spreadsheet of everything in the directory is incredibly convenient.

How It Works

At its core, the estimator analyzes STL geometry directly, binary or ASCII, and computes:

Volume
Surface area
Bounding box dimensions

All of that happens in read_stl() and accumulate_triangle_stats() in estimator.py, where the script walks every triangle in the mesh, updating bounds, area, and signed tetrahedral volume to get an accurate solid volume.

Once the raw geometry is known, the next step is turning that into actual printable material and time estimates. That logic lives in the estimate() function.

Here’s what the estimator computes:

1. Shell Volume

The surface area is multiplied by the shell thickness:

shell_thickness = settings.perimeter_count * settings.nozzle_diameter_mm
shell_volume = stats.surface_area_mm2 * shell_thickness

Is it perfect? No.
Is it “good enough for predicting if I have enough filament left on the spool?” Absolutely.

2. Infill Volume

Whatever remains after subtracting shell volume becomes the interior. That gets scaled by the infill percentage:

internal_volume = max(stats.volume_mm3 - shell_volume, 0.0)
infill_volume = internal_volume * settings.infill_density

3. Filament Usage

From the estimated extrusion volume, the script computes filament length and mass:

filament_cross_section = π * (diameter / 2)^2
filament_length = total_extrusion_volume / filament_cross_section
filament_mass = (total_extrusion_volume / 1000) * density

This is where your actual filament density pays off. PLA, PETG, ABS, and infused filaments all vary, so the config file lets you dial that in.

4. Time Estimate

Finally, the estimator uses three print speeds:

Perimeter speed
Infill speed
Travel speed

Actual slicers know more about retractions, acceleration, jerk, and optimization paths. This tool intentionally doesn’t. The goal is useful approximations, not G-code-level precision.

Still, the heuristic works surprisingly well.

Two Ways to Use It

1. Command Line Mode

As long as Python is on your system:

python estimator.py --config printer-config.json

It scans all .stl files in the folder and outputs CSV by default.

You can choose JSON or XLSX instead. The XLSX mode even builds formulas for totals and human-readable hour/minute formatting, all handled in build_workbook().

Output sample (formatting added after generation):

Totals row automatically generated

2. Web Interface Mode

Run:

python estimator.py --serve --port 5000

Open http://localhost:5000, upload an STL (or ZIP of STLs), and get a clean table of results. You can even offer downloads as CSV, JSON, or XLSX. Not by writing files, but by embedding them as data URIs for one-click downloading.

The web mode is entirely self-contained - no templates, no external static files - and uses a simple Flask-rendered HTML string defined as WEB_TEMPLATE in the script.

Web UI sample:

Configuration: Your Printer, Your Rules

Everything about your printer setup lives in printer-config.json, documented in the project’s README.md. These setting will typically mirror your slicer profile, but you can tweak them independently if you want to experiment with different speeds, layer heights, or infill percentages.

{
  "layer_height_mm": 0.2,
  "nozzle_diameter_mm": 0.4,
  "perimeter_count": 2,
  "top_layers": 4,
  "bottom_layers": 4,
  "infill_density": 0.25,
  "perimeter_speed_mm_s": 40.0,
  "infill_speed_mm_s": 60.0,
  "travel_speed_mm_s": 120.0,
  "filament_diameter_mm": 1.75,
  "filament_density_g_cm3": 1.24,
  "travel_factor": 0.1
}

Change it to match your printer, material, or printing preferences, and the estimator updates automatically.

What This Isn’t

This tool is not trying to:

Replace your slicer
Predict print time down to the minute
Handle variable layer heights
Model retraction, coasting, acceleration, or machine-specific quirks

But it is aiming to answer:

“Do I have enough filament?”
“Ballpark, how long will these prints take?”
“Which of these STLs is going to be a weekend print and which is a coffee break?”

And that’s exactly the problem it solves.

Where It Goes Next

Future improvements I’m toying with:

Per-model config overrides
Optional real-world calibration (feed it a known model + real print time, adjust heuristics)
A nicer web UI (I'm not a designer!)
A batch “compare the cost of these print settings” mode

This is one of those projects that’s small enough to stay enjoyable, but deep enough to keep offering fun ideas.

Weekend Rec Build: cifs-watch

Keith Solomon — Mon, 20 Oct 2025 19:31:07 +0000

It all started with an email from my Proxmox box, saying that the boot partition was out of space…

Every homelab has that one little annoyance that slowly drives you up the wall. For me, it was CIFS shares occasionally dropping off the radar. Sometimes it’s the network hiccuping, sometimes it’s the file server rebooting, and sometimes it’s just gremlins. Either way, when a mount goes stale, it breaks workflows and backups alike. So this weekend’s build tackled exactly that.
The Problem

I’ve got a handful of CIFS mounts defined in /etc/fstab across several machines, all pointing back to my central file server. When that server or a network hop goes down, the mounts don’t always recover cleanly. Manually remounting them works fine, but doing that across half a dozen machines? Not sustainable.
The Solution

Enter cifs-watch — a lightweight Bash script that monitors all CIFS mounts listed in /etc/fstab, checks if they’re reachable, and automatically remounts them when they’re not. It’s polite about it too: it verifies that the file server is online first, logs its actions, and only touches mounts that actually need fixing.

Think of it as a health check for your network shares. The script runs silently in the background, and you can set it up as a systemd timer or cron job depending on your setup.

How It Works

It’s a very simple script at it’s heart. There are four main processes it wraps:

Scans /etc/fstab for lines using the cifs filesystem type.
Verifies whether each mount target is currently available.
Pings the host to confirm it’s up before attempting a remount.
Logs every action — successful checks, reconnections, and errors — to /var/log/cifs-watch.log.

Setup is simple: drop the script into /usr/local/bin/, make it executable, and add it to cron or a timer unit. That’s it. Your mounts stay connected, your logs stay clean, and your sanity stays intact.

Why It Matters

In the spirit of Weekend Rec Builds, cifs-watch isn’t a massive overhaul or flashy new service — it’s one of those little quality-of-life automations that keeps the lab running smoothly. Small scripts like this free up brainspace for the next big idea (and save a few “why isn’t this mounted?” headaches along the way).

Weekend Rec Build: Hall of the Dwarven King – Web Edition

Keith Solomon — Mon, 08 Sep 2025 11:43:21 +0000

Sometimes a project doesn’t need to be a sprawling framework or a months-long refactor. Sometimes it’s just about taking something you love and making it more fun to play with.

This weekend, I built a browser-based version of the solo roll-and-build game Hall of the Dwarven King by Robin Gibson. The idea was simple: keep the heart of the original paper sheet, but drop the pencil-and-bookkeeping overhead. What came out is a quick, single-player web edition that’s fast, friendly, and saves your progress automatically.

What It Does

Play through 20 turns of dice-driven actions (Fight, Drink, Cook, Dig, Build, Mine).
Drop buildings onto a 5×5 grid with depth, adjacency, and uniqueness rules.
Earn and spend gold — funding Vaults, a Throne Room, or even a one-off die face change.
Auto-resolve phases and scoring so you can just focus on choices.
Autosave and resume later; keep a small local leaderboard of your best runs.
Share a one-line score summary straight to your clipboard.

To try it, all you need to do is download the repo from the above link and open index.html in a modern browser.

The Rules in a Nutshell

The game plays out with 7 dice that cover everything from Fighting (⚔️) to Mining (💰). Each turn flows like this:

Rolling Phase — Roll, reroll (discarding dice if needed), or spend 5 gold to set a die.
Action Phase — Resolve in order: Fight → Drink → Cook → Dig → Build → Mine.
Cleanup — Advance the clock, crown your Throne Room if you have one, and move on.

A few wrinkles keep it spicy: Cooking acts as a gate (skip it and you lose the rest of the turn unless you’ve got a Mushroom Farm on your current level), depth increases every 3 digs, and mining scales in risk/reward as you descend.

Building the Web Version

I kept the stack deliberately light:

Plain HTML/CSS/JS. No frameworks, no bundlers.
State in a JS object. Turn, depth, gold, dice rolls, map, everything.
Persistence via localStorage. Games autosave and can be resumed after a refresh.
Imperative rendering. Simple DOM updates, no virtual DOM needed.

The UI mirrors the original sheet but leans on responsive CSS and inline icons to feel at home on the web. Leaderboard scores stay local (top 5), and guardrails in the code ensure you only see the actions valid for the current phase.

A Few Design Calls

Explicit reroll selection. Click dice to mark them for reroll (more intuitive than “hold to exclude”).
Simplified digging pace. One depth every 3 steps — fast enough for web play, still tense.
Responsive layout. Grid + CSS icons instead of lifting image slices from the paper version.
Light guardrails. The UI simply doesn’t let you take invalid moves.

Where It Could Go Next

The current version is a fully-playable game, but there’s room for polish:

Make “Set Face” targetable instead of auto-assigning.
Rename some legacy variables (held → selected) for clarity.
Add micro-animations to dice rolls and map placements.
Improve touch/mobile usability with bigger targets and long-press gestures.

Why This Build?

Because sometimes you just want to play a game you love in a slightly different way, and because coding it is half the fun. This one took a weekend: a handful of files, a few hundred lines of vanilla JS, and I’ve now got a snappy little adaptation that anyone can open in a browser and enjoy.

Attribution

This web version is a fan-made, non-commercial adaptation of Hall of the Dwarven King (v1.2, 2017) by Robin Gibson — metalsnail.net.

Unexpected Transformations: A Year of Growth Through Adversity

Keith Solomon — Fri, 10 Jan 2025 13:00:08 +0000

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

A ruptured tendon in my dominant hand just before Christmas 2023 didn't just derail my coding - it catalyzed an unexpected transformation in my career. Within weeks, I found myself thrust from being 'just another dev' into leading a team of six junior developers, compressing what should have been a gradual transition into a sudden leap.

The Crucible of Leadership

The transition from developer to team leader brought countless sleepless nights and moments of self-doubt. What started as a physical limitation became the catalyst for profound professional growth. The most striking challenge wasn't the injury itself, but bridging a 30-year age gap with our youngest team member. Through persistent communication and a commitment to mutual learning, we've cultivated an environment where experience and fresh perspectives complement each other beautifully.

What began as uncertainty has evolved into a distinctive leadership style, shaped by both successes and setbacks. Our team has developed a culture where questions are encouraged, innovation is celebrated, and growth is constant. The age difference that initially seemed daunting has become one of our greatest strengths, combining decades of industry knowledge with fresh, contemporary approaches to problem-solving.

Technical Evolution Against the Odds

Despite the physical limitations, my commitment to hands-on development remained strong. Logging 707 hours of coding time - averaging over two hours daily with just one functional hand - proved that adaptation trumps limitation. This dedication helped maintain credibility with the team while demonstrating that obstacles can become opportunities for innovation.

Under our collective leadership, we successfully launched eight new sites, with most beating their deadlines. More significantly, we revolutionized our approach to quality by implementing comprehensive SonarQube testing and establishing strict accessibility standards. Every project now launches with WCAG 2.0 AA compliance as a minimum requirement, not an afterthought.

The Project That Changed Everything

One particular project became a crucible for growth, though not in the way we expected. A perfect storm of challenges - my injury, an expansive scope, a demanding client, and scope creep - resulted in a five-month delay. While it marked the most challenging period of my career, it also sparked crucial improvements in our processes.

Instead of deflecting responsibility onto my team, I shouldered the accountability for our setbacks. This decision, though difficult, strengthened team trust and demonstrated the importance of leadership through adversity. The support from upper management during this period revealed that vulnerability in leadership isn't weakness - it's an opportunity for organizational growth.

Documentation Renaissance

Moving beyond tribal knowledge became a top priority. We've transformed our documentation from the informal "ask Keith" approach to comprehensive, accessible resources. This shift not only improved our efficiency but created a foundation for sustainable team growth and knowledge sharing.

Creative Renaissance

Amidst the professional turbulence, an unexpected creative awakening emerged. What began as a simple website redesign project blossomed into a profound artistic journey. A modest six-paragraph story expanded into a 50,000-word narrative, launching me into an unexpected parallel career as a writer. Three additional stories now simmer in development, each offering a different refuge from the demands of technical leadership.

This creative outlet has become more than just an escape - it's a complementary force that enhances my technical leadership. The storytelling skills have improved my ability to communicate technical concepts, while the creative problem-solving strengthens my approach to coding challenges.

Looking Forward

The year's experiences have shaped a clearer vision for the future. We're continuing to refine our project management practices and documentation standards while exploring new ways to leverage our team's diverse perspectives. The creative writing projects are evolving alongside our technical achievements, creating a satisfying balance between logical and artistic pursuits.

A Note of Gratitude

My team's resilience during our challenging projects, their enthusiasm for learning, and their willingness to embrace change have been invaluable. Specific mentors - especially those who guided me through the leadership transition - have profoundly influenced my growth. Their support transformed what could have been a career setback into a launching pad for new opportunities.
As we move into 2025, these experiences have equipped us with stronger processes, clearer communication, and a more cohesive team culture. What started as an injury-induced career pivot has evolved into a journey of unexpected discovery and growth.

Memory is a Funny Thing

Keith Solomon — Mon, 30 Dec 2024 15:56:07 +0000

Originally posted at My Blog

Memory is weird. This morning, as I emerged from a vivid dream about my first encounter with what we might call the “proto-internet,” I found myself marveling at how some memories fade within minutes while others resurface with stunning clarity decades later. The dream transported me back to the summer of 1989, when my mother had just begun her undergraduate studies at the University of Southern Mississippi, and I was about to stumble upon a connection that would change my life.

In those days, I was an outsider, a kid without many friends until fate led me to a group of college students who shared two passions: Dungeons & Dragons and computing. Through them, I discovered my sanctuary in an unlikely place: a small computer lab tucked away on the upper floor of Forrest County Hall. Unlike the other labs scattered across campus with their rows of PCs, this space housed something different—about twenty Wyse terminals with their distinctive green-on-black displays, all connected to a Honeywell Bull mainframe.

The memory of that space remains remarkably tangible. The constant symphony of cooling fans provided the backdrop, punctuated by the staccato rhythm of the massive dot matrix printer. The air conditioning kept the room cool enough for the equipment, but I remember the warmth of belonging that I found there. Through those tiny screens, I glimpsed a world far bigger than my small Mississippi town could contain.

What strikes me now is how different those early online interactions were from today’s instant gratification platforms. Everything moved at a more deliberate pace—communication was primarily through email, creating a thoughtful asynchronicity that seems almost foreign in our current age of instant messaging and social media dopamine hits. Each interaction felt more intentional, more precious.

The screens flickered as my newfound friends typed commands in what seemed like a secret language, each keystroke an invitation into their digital world. I spent countless hours that summer learning their arcane ways, watching the green text scroll across the screen, feeling like I was part of something larger than myself. The memory is so crisp that I can still hear the click-clack of the keyboards and see the monitor glow reflecting off my friends’ focused faces.

This morning’s unexpected memory has made me contemplate how profoundly the internet has transformed since those early days. What began as a small, intimate community has exploded into a vast, ever-expanding network connecting billions. The access to information and communication we have today would have seemed like science fiction to that wide-eyed kid in the computer lab. Yet with this progress has come a certain loss—the intimacy and simplicity of those early digital connections have been buried under an avalanche of notifications, likes, and shares.

As I write this on my iPad, I find myself holding two truths simultaneously: a nostalgia for that simpler digital age when computers were tools for connection rather than extensions of our identity, and a deep appreciation for how technology has enriched our lives, enabling us to bridge vast distances and share our stories with the world. Perhaps what I’m really longing for isn’t the technology itself, but the sense of wonder and possibility I felt in that humid Mississippi summer.

Memory shapes who we are, constantly evolving as we weave new experiences into the tapestry of our past. And while I cherish those formative moments in Forrest County Hall, I’m equally grateful for all the memories—both digital and analog—that have followed. In this ever-shifting landscape of memory and technology, one constant remains: our fundamental need for genuine human connection, whether mediated through green-on-black terminals or high-resolution touchscreens.

When those old memories surface unexpectedly, they offer us a chance to pause and reflect. They remind us that while technology evolves at a dizzying pace, the core human experience—our desire to connect, to belong, to understand and be understood—remains beautifully unchanged. Memory may be weird, but in its mysterious workings, it reveals the threads that connect our past and present selves, weaving together the story of who we are becoming.