Builds

Going Faster Guided by Data

I’ve been doing track days for a while now. The appeal is immediately obvious: closed circuit, no speed limits, no traffic, just you and the bike. But once the initial thrill settles, a different kind of obsession takes over—going faster.

The thing is, motorcycles give you very little feedback about why you’re slow. You can feel it. But feeling it and knowing it are different things. Memory is unreliable, especially when your brain is busy calculating corner entry lines at 150km/h.

And I had a GoPro. So I had footage—hundreds of gigabytes of it, sitting on drives going nowhere. Clipped for a few Youtube videos, otherwise completely untouched. Track days I couldn’t learn from because the data was locked inside a camera.

So I built the tool I actually wanted.

First Attempt: Electron

My first instinct was Electron. You want a desktop app, you already know JavaScript, Electron gets you there fast. It worked—the core pipeline was proven on Electron first, and that mattered.

The problems were predictable in hindsight.

Electron ships its own copy of Chromium—roughly 100–200 MB before a single line of application code. For an app that also bundles FFmpeg, FFprobe, and a full Node.js runtime for processing telemetry, the installed footprint hit around 700 MB. Memory usage was the next issue. And then there were all the small things: a title bar that never looked quite right on macOS, scrollbars that felt slightly off, the general sense that it wasn’t a native app.

Yes, I’m aware of the irony. I wrote a whole post about building Fokus because I was tired of RAM-hungry Electron apps, and then I went and built one. It was the right tool to prove the concept. Ship now, fix later.

Switching to Tauri

Tauri uses the platform’s native WebView instead of bundling Chromium. It’s already installed, already maintained by the OS, and costs nothing in bundle size. Application logic that would’ve lived in Electron’s main process moves to Rust.

The installed size dropped from ~700 MB to ~300 MB. Still not small—the bundled Node.js runtime and FFmpeg binaries account for most of it—but half of what it was. And Tauri 2 requires you to explicitly allow every filesystem path and plugin permission, which forced me to actually think about what the app needs access to rather than just letting it do whatever.

The Data Pipeline

When you import a session, a lot happens before you see anything on screen.

GoPro cameras split recordings into ~4 GB chapters, so the importer first figures out which files belong together by matching filename prefixes—GX010142.MP4, GX020142.MP4, and so on—and concatenates them with FFmpeg. Then it extracts the telemetry. GoPro cameras embed sensor data in a binary format called GPMF in a dedicated MP4 track, recording GPS at 18 Hz (10 Hz in older devices) alongside accelerometer and gyroscope streams. A Node.js processor (bundled inside the Tauri app as a subprocess) parses all of this into structured data, runs lap detection, and outputs GeoJSON.

Running the processor as a Node.js subprocess rather than in the WebView was a pragmatic call—the GPMF parsing libraries live in the Node ecosystem, and keeping that layer separate means no bundler headaches. The Rust layer passes file paths in, waits, reads the output. Each part does what it’s good at.

Making the GPS Data Useful

Raw GPS at 18 Hz is noisy. Positional jitter is worst at low speeds, and you occasionally get hardware artefacts that need filtering. Coordinates are parsed to six decimal places—around 10 cm of precision at the equator, which is plenty for track-scale work.

Heading between consecutive samples is computed using the standard bearing formula. Below 2 m/s the GPS noise makes heading meaningless, so the previous value just carries forward.

The most involved calculation is lateral acceleration—the sideways force that maps to cornering load and, on a motorcycle, allows you to calculate a physic-derived estimate of lean angle. It’s derived from angular velocity multiplied by forward speed, but the raw derivative of heading is too noisy to use directly. The angular velocity stream goes through a Kalman filter first: a predict-and-update loop that balances how much you trust the model versus how much you trust each individual measurement. The parameters are tuned to favour the smoother model estimate over any single noisy reading. What comes out the other side is actually useful.

Counting Laps

Lap detection uses geometric line intersection. Each sector boundary—the start/finish line, or intermediate splits—is defined by two GPS coordinates. A lap is detected when consecutive GPS samples cross these boundaries in the correct sequence. The intersection test checks whether two consecutive samples A→B straddle the sector line using cross products. Timestamps at the crossing are interpolated to sub-sample precision so sector times are accurate.

Partial laps at the start and end of a session are stored separately from timed laps, which matters if you’re comparing your clean flying laps across different track days.

Visualisation

GPS traces are rendered with MapLibre GL—each session’s GeoJSON loaded as a source and drawn as a line layer. You can view multiple sessions at once, which is useful for comparing lines through a corner across different track days.

The multi-lap telemetry charts are built with D3 on a WebGL canvas. A five-minute segment of data at 10 Hz is around 5,400 data points—compare ten laps and you’re at 54,000. SVG at that scale is too slow to interact with, so WebGL it is.

The lean angle and G-force gauges are custom SVG components. They update as fast as the underlying data changes, which is exactly how it should feel.

Supporting More Than GoPro

GoPro is the most common source but not the only one. SpeedAngle make a dedicated motorcycle data logger which includes all the necessary data points to work with TrackChronos—GPS, lean angle via IMU, longitudinal acceleration. No video, so the processing path is simpler: no FFmpeg, no GPMF extraction. The parser just reads the SpeedAngle file and feeds the data through the same lap detection and GeoJSON pipeline.

The output is identical from the app’s perspective. That was the goal. The GeoJSON schema is the common language—any device that records GPS and inertial data needs only a parser that produces that schema, and nothing else in the system needs to change. I want this to work regardless of what logger you ride with.

What’s Next

The plan is straightforward: every data source a track day rider might use should eventually be importable. GoPro was the first step, and SpeedAngle was the second. The pipeline is ready for more.

The riders I built this for are the ones who care enough to buy a data logger, who watch their data between sessions, who want to know exactly where they lost those two tenths in sector two. That’s me. I built it for myself first, and if it’s useful for anyone else who rides on track, that’s exactly what I was hoping for.

Try It Out

Head to the website to learn more: TrackChronos.

---

Photo credits: John Pickett Photography.

The Problem

I fold my notes. A lot. Headers, lists, code blocks, callouts, everything. It’s how I keep long documents manageable and my brain from melting when I’m trying to focus on one section at a time.

The problem? Obsidian stores all your fold states in localStorage, which isolates fold states to individual devices. Open the same note on any of your other devices, and everything is expanded again. Every. Single. Time.

For a while, I just dealt with it. I’d open a note, find myself frustrated that fold syncing isn’t already a feature built into Obsidian, and move on. It ultimately wasn’t that big of a deal, right?

It wasn’t until moving my Vault from iCloud to my newly built NAS that this annoyance became one I could no longer tolerate.

As part of my process of moving all my data, there were lots of times I had to recreate my Vault, thus destroying the fold states within localStorage, and necessitating the tedious process of having to go through and re-fold my entire Vault (although, made much easier due to my other fold plugin: Obsidian Fold Properties). This was a huge pain…

The Solution

So I made this plugin. It’s pretty simple, really:

1. Intercepts and monkey patches all localStorage actions related to folding
2. Puts them in the plugin’s data.json file (which does sync across devices)
3. Updates the localStorage necessary when you open your Vault on another device

That’s it. No complicated setup—it works out of the box. Just move the data from the thing that doesn’t sync to the thing that does.

How It Actually Works

When you load the plugin, it checks: “Hey, do I have fold states saved in settings?” If yes, it imports them into localStorage. If not, it exports whatever’s currently in localStorage so you don’t lose anything.

Then it just… watches. Every time you fold or unfold something, it saves the change to the plugin’s data.json. When that file syncs to your other devices, the plugin notices and updates localStorage there too.

Open a file, and boom—your folds are exactly where you left them. On any device.

What’s Left

I still need to make it apply fold changes to files you already have open when a sync comes in. Right now it works perfectly when you open a file fresh, but if you’ve got a note open on both devices and fold something on one, the other won’t update until you close and reopen it. Not a huge deal, but I want to fix it. I want this to be a good enough solution for the core Obsidian team to adopt it.

The rest is pretty much done. V1 is stable, settings are minified to keep the file size down, and it works with any sync solution—Obsidian Sync, iCloud, Dropbox, git, SyncThing, whatever.

Why This Matters (To Me, Anyway)

This plugin exists because I got tired of the same tiny friction point happening over and over, and it’s been a feature request since 2022. It’s not a revolutionary feature. It won’t change how you take notes. But it removes one small annoyance that was breaking my flow whenever I switched devices. I’m sure it will do the same for you.

2026-02-02: I’m currently waiting for the Obsidian dev team to approve and merge it into their repo, but you can manually install it in the meantime.

2026-05-13: It’s available via the Obsidian community now! Check it out here Sync Folds.

The Concept

I’m constantly trying to improve my effectiveness when working on things, especially with projects that have deadlines—uni assignments, client projects, side projects that somehow become main projects. It’s so easy for me to over-engineer these types of things, as I’m the kind of person who does things because I love them—I’m a passionate person.

Well, enter not procrastination, but rather, the opposite: the never-ending cycle of wanting to make this as perfect as humanly possible. This is where Fokus comes in.

I’ve been into Pomodoro timing for a long time, using random apps to help myself stay focused, but all these apps have had at least one thing wrong with them. Some were RAM hogs, using hundreds of MBs for what’s essentially a glorified countdown timer. Others had terrible UI, burying simple controls under hidden menus. The worst offenders managed to be both: Electron apps.

I decided to simplify the concept into a simple Rust TUI (terminal user interface). If I’m in front of my computer, I have my terminal open, either using Spotify, NeoVim, or some other cool TUI app. So I thought, a Pomodoro timer here would be perfect.

Why Rust?

This was my first real Rust project, and honestly, it was motivated as much by wanting to learn Rust as it was by needing a better timer. Coming from a frontend background—JavaScript, TypeScript, React—Rust is the lowest-level programming language I’ve ever worked with. I’ve never been this close to the hardware with software before.

The performance characteristics aligned perfectly with my “no RAM hogs” philosophy. I wanted something that would sit idle at basically zero CPU usage and consume maybe a few megabytes of memory. Spoiler: mission accomplished.

But beyond performance, there was something appealing about Rust’s reputation for being difficult—I wanted a challenge. I wanted the compiler to yell at me. I wanted to understand what people meant when they talked about ownership and borrowing.

The Learning Curve

Coming from JavaScript (jQuery was my initial introduction to JS 15 years ago) where you can just… do whatever and hope for the best at runtime, Rust has safety measures in place that required a philosophical change to my coding. Rust isn’t being pedantic for fun, it’s preventing you from writing code that would cause a race condition or a use-after-free bug.

My IDE was riddled with squiggly lines in the beginning. I’d write something that seemed perfectly reasonable, create a value, and use it in two places. Then Rust would hit me with a “cannot move out of self.timer because it is borrowed”. I’d stare at the error for five minutes, google it, read three Stack Overflow answers, and still not quite get it.

Then something clicked. These preventative measures weren’t just the language being difficult, they were safety nets that I’d never experienced in any other language to date. These difficulties ended up being the most satisfying part of using Rust. If it compiled, there were no errors.

The Architecture

App State

pub struct App {
    // Core timer state
    current_state: TimerState,
    remaining_timer: u64,
    countdown_running: bool,
    timer_active: bool,

    // Async communication channels
    transmitter: mpsc::Sender<u64>,
    running_tx: broadcast::Sender<bool>,
    countdown_task: Option<JoinHandle<()>>,

    // UI state
    current_screen: Screen,
    settings_field: SettingsField,
    editing_field: bool,
    input_buffer: String,

    // Session tracking
    long_break_count: u64,
    stats: SessionStats,
    settings: Settings,

    // ... and more
}

You might notice I have both countdown_running and timer_active. This is one of those things that emerged from necessity: timer_active tracks whether a timer session has been started at all, while countdown_running tracks whether it’s currently ticking down or paused. This distinction matters because you can pause a timer without resetting it, and the UI needs to know the difference.

The Async Runtime Dance

Here’s where things get interesting: Tokio. The main event loop uses tokio::select! to balance two asynchronous streams:

while self.app_running {
    terminal.draw(|frame| self.draw(frame))?;

    tokio::select! {
        event = self.event_stream.next().fuse() => {
            // Handle keyboard input
            match event {
                Some(Ok(Event::Key(key))) if key.kind == KeyEventKind::Press => {
                    self.on_key_event(key);
                }
                _ => {}
            }
        }
        Some(secs) = rx.recv() => {
            // Handle timer tick updates
            self.remaining_timer = secs;
            if secs == 0 && !self.transition_pending {
                // Timer finished! Show notification and transition state
                self.handle_timer_completion();
            }
        }
    }
}

This pattern is the heartbeat of the entire application. The select! macro lets me wait on multiple async operations simultaneously—user input from the terminal and timer updates from a background task. Whichever one completes first gets handled, then we loop back around.

Coming from JavaScript’s event loop, this felt familiar but more explicit. In JS, everything’s async by default and you just trust the runtime. In Rust, you’re making conscious decisions about task spawning and communication patterns.

Even when paused, the app consumes virtually zero CPU but still responds instantly to any keypress—such as resume, skip, or reset. The select! isn’t busy-waiting, nor polling, it’s using OS event notifications to sleep until something actually happens. Coming from Electron apps that idle at 2–3% CPU, this felt like magic.

Channel Communication

I’m using two different types of channels for different purposes:

1. Multi-producer, single-consumer (mpsc) for timer updates: The countdown task sends the current remaining seconds back to the main loop. This is one-way communication—the timer talks to the UI.
2. Broadcast channel for pause/resume signals: When you hit pause, the main loop needs to tell the countdown task to stop ticking. Multiple receivers can subscribe to this channel (though I only use one), and it handles the case where the receiver might miss messages (if they’re not listening).

fn start_timer(&mut self) {
    // ... setup code ...

    let tx = self.transmitter.clone();
    let running_rx = self.running_tx.subscribe();

    let _ = self.running_tx.send(true);  // Tell countdown to start

    self.countdown_task = Some(tokio::spawn(async move {
        timer::countdown(duration, tx, running_rx).await;
    }));
}

The countdown runs in a separate Tokio task, ticking down and sending updates. If you pause, I broadcast a false signal and the task stops sending updates. Resume? Broadcast true and it continues.

This was one of those moments where Rust’s ownership model really shined. The channels enforce at compile-time that only one thing can receive timer updates, and I can’t accidentally create data races between the UI and timer threads.

The Details That Matter

Vim-Style Keybindings

Because I live in NeoVim, I added vim-style navigation to the settings screen:

fn handle_settings_navigation(&mut self, key: KeyEvent) {
    match key.code {
        KeyCode::Up | KeyCode::Char('k') => self.previous_setting(),
        KeyCode::Down | KeyCode::Char('j') => self.next_setting(),
        KeyCode::Enter => self.start_editing(),
        KeyCode::Esc => self.current_screen = Screen::Timer,
        _ => {}
    }
}

j and k for down and up, just like in vim. It’s muscle memory at this point, and having to use arrow keys would genuinely annoy me.

Notifications

What good is a Pomodoro timer if it doesn’t tell you when the timer is finished?

Notification::new()
    .summary("Pomodoro")
    .body(summary)
    .sound_name("Blow")
    .icon("alarm")
    .show()?;

This seems simple, but getting notifications working on macOS was… a journey. macOS requires apps to have a bundle identifier to send notifications, and terminal apps don’t have one by default. The solution was to set the bundle identifier to match Terminal.app (even though I use iTerm2):

#[cfg(target_os = "macos")]
let bundle = get_bundle_identifier_or_default("terminal");
set_application(&bundle).unwrap();

There’s commented-out code in there for interactive notifications (buttons to start the next session), but I couldn’t get the response handling working reliably across different notification systems. Something to revisit.

Using Ratatui

I chose Ratatui for the TUI framework because it’s mature, actively maintained, and relatively easy to pick up coming from a frontend dev background. The component model felt familiar—you have a render function that gets called every frame:

fn draw(&mut self, frame: &mut Frame) {
    ui::draw(self, frame);
}

Inside that ui::draw function, I’m building up the interface using Ratatui’s layout system, which is surprisingly similar to CSS flexbox. You define constraints, and it handles the positioning.

The nice thing about Ratatui is it’s immediate mode: you describe what the UI should look like right now based on the current state, and it handles the diffing and updating. Coming from React, this felt natural.

The End Result

Fokus does exactly what I need it to do. It sits in my terminal, uses basically zero resources, and alerts me when timers are finished. The entire compiled binary is smaller than a single hero image on a modern website. It starts instantly. It’s built with my own hands.

More importantly, I learned Rust. I had previously used Rustlings to get a grasp on how to write in this language, but what really cemented my knowledge was building a tool born from my own idea and something that I actually use every day. The frustrations were real, but so was the satisfaction when things would finally compile and work.

This project sold me on Rust completely. Now I’m incredibly excited to ditch Electron and try Tauri for my future web apps. I currently have a motorcycle data analysis tool built with Electron, but having learnt Rust, I’m eager to switch. But that’s a project for another time.

If you want to try out Fokus, you can simply run cargo install fokus, or you can check out the code here.