About
I'm Ricardo, an electrical engineer. My working world is data centers and energy: capacity and redundancy, asset registers moving between teams, dispatch and financing questions, the operational discipline that keeps critical facilities running. The software on this site exists because parts of that world are tedious and error-prone in exactly the ways software is good at — checking a register field by field, redoing capacity arithmetic without slipping a unit, walking a financial scenario through every convention the same way twice. The projects are based on recurring engineering problems, operational workflows, or questions I wanted to examine more rigorously.
How things are built here
A few habits run through every repository, and they come from engineering practice rather than software fashion:
- Tests are first-class. Behaviour worth having is behaviour worth pinning. Reference results are committed separately from the engines that produce them, and CI reconciles the two.
- Conventions are written down. Where a calculation admits more than one defensible convention — day counts, rebalancing, rounding — the chosen one is documented, so a result can be checked rather than debated.
- The math is hand-verified. Reference fixtures use numbers deliberately chosen so a reviewer can recompute them on paper, and the paper calculation is the acceptance oracle.
- Limitations are published. Every project states what it does not do and where it stops being dependable, because a tool's edges are part of its specification.
- All data is fictional. Every snapshot, register, price series, and scenario across these projects was invented for the repository it lives in. Nothing here derives from any real site, client, or dataset.
The case studies show these habits in action on specific incidents and decisions, each linked to the code that backs it.
On the name
The work here is published under the NishikawaButterfly handle, and this site deliberately carries no surname, employer, or biography. The repositories, their tests, and their documentation are the argument, and I would rather they speak for themselves than lean on a CV.