Guilherme Colombo

Most systems don’t just care about the current balance. They need to know what the balance was, what it will be, and whether planned actions will cause problems later. A future payment might overdraw an account. A scheduled order might push inventory negative. These questions need fast answers. What’s really needed is an engine that does this automatically, one that keeps balances up to date at all times and can answer “what happens if…?” instantly, even across long timelines. Not by replaying transactions or running batch jobs, but by maintaining the right data as changes happen.

FinanceDB is built on a time-ordered B-tree that naturally keeps balances correct as the tree changes. Transactions are stored by time, and every node stores the total balance of everything beneath it. When a transaction is inserted, updated, or removed, the normal B-tree traversal already walks the exact path needed — so recalculating balances is just part of that process. Because each node knows the balance of a whole time range, the system can answer balance and projection questions by skipping over large sections of the tree. That same information makes it easy to detect when a balance would go invalid at any point in the future.

Most blockers are interchangeable; the difference is whether the data is trustworthy enough to drive decisions. If measurement is vague or inflated, you end up tuning limits blindly and the product becomes a temporary speed bump instead of a system that helps you change habits.

A Manifest V3 service worker listens to tab and window focus signals to build browsing sessions based on actual attention, not just page loads. Those sessions are aggregated into rollups that power the charts and rankings, with settings synced across devices. Enforcement is handled separately using declarativeNetRequest rules that efficiently intercept and redirect blocked sites to a local block page you can customize. For the full-stack side, sessions can be persisted to a backend with authenticated endpoints and a Postgres store optimized for analytics queries, so you get longer history and faster reporting than a purely local extension.

Because modern solutions are NOT good! Unintuitive UI, lack of flexibility, ads and plans being forced down your throat, forced cloud storage, come on! Users should have full control over their data.

Users can create multiple activities and track them simultaneously. When an activity is stopped, a session object is created and its raw data is persisted to a local SQLite database. Each session is uniquely identified by a UTC ISO-8601 timestamp and the associated activity ID. Activity IDs are used instead of activity names because names are user-editable. This allows activity updates to be handled by modifying a single row in the activities table, without needing to traverse or rewrite all related session records.

I was eager to play around with 3D physics and procedural level generation. I also wanted to learn about the pipeline from Godot to shipped app on mobile devices.

Godot is pretty versatile and 4.X releases have a mature 3D engine. For procedural generation, the platforms are spawned in a random position within a range of 45 degrees in front of the previous platform. The disks are spawned using guassian distribution to define their size, speed, and deterioration rate. Every new platform jumped is a higher difficulty.