u/Ok_Calligrapher_8210

Hey everyone,
I had some spare parts lying around and decided to build a standalone dual-gauge metric monitor for my personal Kubernetes cluster (specifically tracking CPU and memory on my two worker nodes).

the MetricGauge

Unlike my previous display setups that required an intermediary server to scrape and push frames, this device is completely standalone: the ESP32-C3 scrapes Prometheus endpoints directly over Wi-Fi and renders the UI itself.

The Build Overview

• MCU: ESP32-C3 Super Mini
• Displays: Dual GC9A01 240x240 circular LCDs
• PCB & Enclosure: Designed the custom PCB in KiCad and coded the parametric case in OpenSCAD.
• Firmware: Written in Rust using AI coding agents (Zed + Cursor)
• Power: Upgraded to an internal Li-ion battery + charging module for a completely wire-free desk setup.

The Fun Challenges (Troubleshooting)

1. Font Porting: Initially prototyped the UI on macOS with TTF fonts, which the AI agent quickly helped convert to lightweight bitmap fonts for the ESP32 environment.
2. SRAM Constraints & AI Over-Optimization: The ESP32-C3 has 400KB of SRAM. Between HTTPS overhead for Prometheus scraping and display buffers (taking ~120KB), the AI agent panicked and "over-optimized" by quartering the buffer and drawing in 4 passes, which caused terrible screen flickering. Since the MCU isn't running heavy background tasks, I dialed it back to render one full display buffer at a time, completely fixing the flicker.
3. Case Iteration & Wireless Mod: My initial 3D print sizing was slightly off, allowing only the front panel to fit. Seeing the extra space needed, I iterated the design to pack a Li-ion cell, a charge/discharge protection board, and a power switch inside, turning it into a truly wireless desktop gauge.

Everything is open source. If you're interested in the code, KiCad schematics, or 3D models, feel free to check out the repo below:

• Github : https://github.com/suapapa/metric-gauge
• Youtube : https://youtu.be/ck8P2s1PN7U?si=lgz8Yw5uzvvvdpSD

Let me know what you think or if you have any questions about the Rust on ESP32 setup!

Hi everyone,

I wanted to share a small project I've been working on: openscad-wasm-mcp. It's a Model Context Protocol (MCP) server that runs OpenSCAD entirely via WebAssembly.

The main advantage is that you don't need to install OpenSCAD locally on your machine. You can directly let your AI assistants generate, compile, and render 3D models seamlessly. You can check out the source code and how to use it here:

• https://github.com/suapapa/openscad-wasm-mcp

I also recorded a quick demo video showing how it works in action:

• https://youtu.be/SMOajTSFkgk

\"Make me a simple 3D model of a turtle\"

I'd love to hear your feedback or any suggestions for improvement!

Hi everyone,

I’ve always loved how npx allows me to run tools without cluttering my global space or manually managing installations. I wanted that same seamless experience for the Go ecosystem,

so I built gox, https://gox.homin.dev.

---

What is gox?

It’s a CLI tool that lets you run Go binaries directly from their repository or package path. It handles fetching, building (and caching), and executing in one go.

How is this different from go run?

While you can use go run package@latest, gox is designed with a "Run, don't just compile" mindset, offering several key improvements:

• Persistent Binary Caching: go run often re-evaluates or re-compiles dependencies, which can be slow for larger tools. gox builds the binary once and caches it. Subsequent executions are near-instant because it runs the cached binary directly.

• Cleaner Workspace: go run downloads source code into your module cache. gox manages its own binary cache, keeping your development environment and GOBIN clean from one-off utilities.

Perfect for the MCP Ecosystem

Recently, I've found it incredibly useful for Model Context Protocol (MCP) servers. If you are developing or testing Go-based MCP servers for Claude or other LLMs:

• You can run them instantly without a permanent go install.
• It’s perfect for testing different MCP tools in your config.json by simply pointing to the repo.
• It makes sharing and trying out new Go-MCP implementations much faster for the community.

---

I’d love to hear your thoughts, especially from those building MCP tools or CLI utilities in Go.

Any feedback is welcome!

Happy coding!