Most teams run into the same problem sooner or later: technical documentation is spread across different repositories, but the natural destination for publishing it is a single, coherent site.

A central project may have its own development docs, but also depend on operations guides, infrastructure manuals, or integration documentation that live in other repositories and are often maintained by different teams.

The question is how to publish all of it together — with consistent navigation and cross-references — without forcing the sources to be centralized as well.

The idea we've been implementing at Fierro is fairly simple: a single published site, built with Sphinx from one main repository, but from sources maintained across several repos.

Read more…

Lobsters (lobste.rs) is probably my main source¹ of tech reading: it is a human-curated feed that prioritizes content quality, with no shady clickbait, abusive ads, or hostile comments. Even though I am not a member (it requires an invitation), I strongly identify with its "old internet" spirit.

Yesterday, mostly via ChatGPT on my phone, I built Lobstersgram, a bot that works as a fast Lobste.rs client on Telegram.

Every now and then, if the bot detects new posts, it sends you a short message with an intro and a link to the article copied to telegra.ph, plus the original source link and the discussion thread on the forum. Why republish on Telegraph? Because it supports instant view, which allows preloading the content with a simple, consistent style that is ideal for mobile reading.

If you have Telegram, you can try it at @lobstersgram_bot

Commands:

• /start to subscribe
• /unsubscribe to stop receiving

(Note: it only runs every 2 hours, so it will reply eventually, but do not expect immediacy.)

Here is a demo I recorded capturing my phone screen (with a notification from the family group included).

Read more…

Python is a pragmatic programming language and asks for very little to get started. A text file with valid code, conventionally ending in .py and forming a “module” in Python jargon, is already a small program (a script); we run it with python <file> and we are done. But when that simple piece of code needs to grow into more files or deserves to be distributed —maybe because it will be a dependency of another project or simply because someone else might benefit— then it needs some structure and metadata.

That is not exclusive to Python: when you start a software project there is always a basic set of files and structures that serve as a starting point; the minimum set of files, folders, configs, and "basic" code you need when you want to share code as an app or library: the project boilerplate. The boilerplate does not define logic, but it does lay the technical foundation—often based on conventions and sometimes on personal taste—on which everything else will be built.

This article details the decisions I made for the template and automated scaffolding I created for my projects, based on Copier.

In short:

• 🐍 Modern Python package (3.12+)
• 📦 Build and dependency management with uv, split by groups (dev/qa/docs)
• 🧹 Linting and formatting via Ruff with a broad set of rules enabled
• ✅ Type checking via ty
• 🧪 Tests with pytest, coverage.py and extensions
• 📚 Docs with Sphinx, MyST and a few extensions, deployed to GitHub Pages
• 🤖 GitHub project creation automated through GitHub CLI
• ⚙️ CI workflow on GitHub Actions
• 🚀 Automated releases via Trusted Publishing
• 🧠 Sensible defaults via introspection to minimize answers in the initial questionnaire
• 🛠️ Makefile with shortcuts for common tasks
• 📄 Generation of generic docs such as LICENSE/CODE_OF_CONDUCT/AGENTS.md, etc.
• 🌀 Initial setup of the development environment and git repo
• ♻️ Projects updatable with copier update

And a bunch more details I am surely forgetting.

Read more…

My wife Natalia, among many other talents she has, is a German-to-Spanish translator and, besides freelancing, works as a researcher and lecturer at the Universidad Nacional de Córdoba, Argentina.

Probably because foreign languages are almost as hard for me as dancing or singing (sorry to my colleagues who have had--and will have--to suffer through my spoken English), I have deep admiration for polyglots. Not for the mere ability to swap words or produce more vowel sounds, but for the power to know and feel different universes. That is what Jorge L. Borges was complaining about when someone mangled one of his tales with a translation:

According to dictionaries, languages are repertoires of synonyms, but they are not. Bilingual dictionaries make you believe that every word in one language can be replaced by another word in a different language. The mistake is ignoring that each language is a way of feeling the universe.

I extrapolate that admiration for polyglotism--the art of widening your vital universe--to people who know many programming languages deeply. They bring ideas from one universe to the next, bursting bubbles, prejudices, blind spots. They propose new ways and limits, taking inspiration from here to create over there. Python would not exist without that kind of people. Long live those "Marco Polos" who connect universes.

Since I'm ambitious (but not quite dedicated enough) to open a small window into the Rust universe, I compensate for my slowness and distraction with tools and shortcuts.

This is a simple way to expand my Python universe with a "Marco Polo" who knows the Rust world and can open a window to that other realm full of possibilities.

Read more…