peter / [AI] Our shared AI tools — guide for Nayana
Ostatnio aktywne 1 month ago
Plain-English walkthrough of the shared apps (Notion, Todoist, Google Calendar, iCloud, LibreChat) my wife and I are using to handle household coordination together. Written for a non-technical partner; explains what each tool is, how sharing works, and what she needs to do to set up.
Our shared tools — a quick guide
Hey love — here's a short walkthrough of the apps we're going to use together. The goal is to spend less time planning and more time living, and to let AI help us with the boring coordination stuff (trips, budgets, household tasks, paperwork).
Each section explains: what the app is, what we use it for, how sharing works, and what you'll need to do. There's nothing scary here — most of these you already use, or are new but Mac/iPhone-friendly.
I'll handle all the billing and any tricky setup. You won't need a credit card for anything in this doc.
peter / [AI] Haiku: skills
Ostatnio aktywne 1 month ago
A 5-7-5 haiku about how skills shape an agent's actions before responding
| 1 | Skills whisper softly— |
| 2 | knowledge wakes before I act, |
| 3 | one step, then the next. |
peter / [AI] Session transcript part 2: Billing engine architecture for tree-shaped products
Ostatnio aktywne 1 month ago
Second half of a Claude Code session (~145 KB). Architectural discussion of evolving a 1:1 resource→line-item billing engine to handle product trees, time-varying topology, dynamic and grandfathered modifiers, usage-driven rate decisions (Burstable Internet), and derived charges. Covers the Charge model, four-stage rating pipeline, rate-context cascade, derived-charge protocol, time-slicing strategies, idempotent re-rating, a complete Burstable worked example, build-vs-buy analysis vs Lago/Metronome/AWS, AWS-style flat-rating-with-attribution as the production pattern, and a one-month tactical plan to ship the new product into the existing engine.
Part 2 — Billing engine architecture for tree-shaped products
Second half of the session: 1:1 resource→line-item model breaking under product trees, the Charge model, four-stage rating pipeline, rate-context cascade, derived charges, Burstable Internet worked example, build-vs-buy analysis, and a one-month tactical plan.
User
So antother things... until now we have had a system that loooks like this: we process audit entries to create usage recrods which have lifecycle (ordered, created, connected, etc...). Each usage record represents a resource type. Some attrs of that resource can be used to lookup a SKU which maps to prices over time. The nice thing was we had 1:1 resource to usage record and usage record to billable thing/line item on an invoice. It was all simple. Even stuff like port groups which had children were just broken into individual ports and billed as a normal port. Links and Connections, our complex types which have A and Z sides (VXCs) even stay simple because the A and Z are references so everything just gets billed on its own. I created an engine for generic pricing modifications on these usage records. Generic matcher and generic action applied to price. Multiple types of price modifications, promo codes, reseller discounts, etc... each pricing mod type could be dynamic or "grandfathered". If it's grandfathered, the mods active at order time never expire and price never changes (we always grandfather prices). If a price mod is dynamic (like reseller discounts, if they hit new tiers their discounts go up or down on existing stuff) I used clever algorithms to split the timeframe of the input into discrete chunks with different mods applied/prices. These then layer and the rules about layering the two mod types are handled properly so it can be done in any order with as many mod types as we want to exist (admin overrides, custom plans from resellers, etc...). So at the end of the day, the input would be a usage record and some time frame and you'd get back a bunch of time segments with various mods applied for each segment resulting in different prices. Cool. Math works out, everything was great. Now the 1:1 broke. We have complex products which end up being product trees. I have modeled the trees right and orchestration algos are going well. The pricing is proving tough. Now a tree with N nodes might result in <N lines (non-billable stuff, easier) or >N lines (surcharges, prices not belonging to any particular thing). I have protocols for all the node types... whether it's a resource (tracked with a lifecycle from audit logs), Locatable (has a location), Priceable (has args which map to a SKU which prices can be fetched for), etc... The question is: how do I make this work or think of it generically? Our old tabular reports won't really capture nesting, not a buge deal. What happens when mods apply to different parts of the thing? How do you split? You could have a ton of full copies of the full tree each with different prices? And some things can now come and go. Before, once something was created, it maintained the same shape. Now, nodes can come and go. Technically a port group could have ports added and removed but because we priced them by treating everything as its own thing, but now, we can have a Link which has an Internet Z side which has one or more Network spaces. Those network spaces have various sizes and therefore are priced differently and based on how long they are alive/billable. And everything can be modified. How to I handle all of this sanely? What do people do?
peter / [AI] Modern C++ CRTP: fluent-builder + arithmetic mixins
Ostatnio aktywne 2 months ago
Two practical CRTP use cases in C++20 — preserving derived type in chained setters, and synthesizing arithmetic operators once.
| 1 | // crtp_modern.cpp — compile with: c++ -std=c++20 -O2 crtp_modern.cpp |
| 2 | // |
| 3 | // CRTP (Curiously Recurring Template Pattern) shines when a base class needs |
| 4 | // to return or operate on the *derived* type without paying for virtual |
| 5 | // dispatch. Two practical mixins below. |
| 6 | |
| 7 | #include <concepts> |
| 8 | #include <iostream> |
| 9 | #include <string> |
| 10 | #include <utility> |
peter / Digits of PI - Modern C++
Ostatnio aktywne 2 months ago
Computes N digits of PI using modern C++.
| 1 | // pi_spigot.cpp — compute N decimal digits of pi using the |
| 2 | // Rabinowitz–Wagon spigot algorithm. |
| 3 | // |
| 4 | // "A Spigot Algorithm for the Digits of Pi" |
| 5 | // Stanley Rabinowitz and Stan Wagon, 1995. |
| 6 | // |
| 7 | // The algorithm exploits the series |
| 8 | // |
| 9 | // pi = sum_{i=0..inf} (i! * 2^(i+1)) / (2i+1)!! |
| 10 | // |
peter / Public Gist Test
Ostatnio aktywne 2 months ago
Testing a public gist
Public Gist
This is a public gist on my self host gist site.
# Factorial Function example
def factorial(n: int) -> int:
''' Factorial, returns `n!`. Equal to `1*2*3*...n`. '''
if n < 0: