https://www.tpjnorton.com A blog about all things code, design and software engineering. Fri, 12 Jun 2026 13:11:58 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en Copyright © Tom Norton https://www.tpjnorton.com/blog/posts/predicting-my-first-half-marathon-time https://www.tpjnorton.com/blog/posts/predicting-my-first-half-marathon-time Sun, 07 Jun 2026 12:00:00 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/how-vibe-coding-made-me-a-hobbyist-again https://www.tpjnorton.com/blog/posts/how-vibe-coding-made-me-a-hobbyist-again Wed, 20 May 2026 12:00:00 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/testing-my-bike-split-calculator-against-real-data https://www.tpjnorton.com/blog/posts/testing-my-bike-split-calculator-against-real-data Wed, 29 Apr 2026 12:00:00 GMT Do its predictions match real rides? So I pulled four of my own rides, fed each one into the calculator at my actual average power for the day, and compared the predicted finish time to the time I actually rode. To keep things honest I refactored the calculator into a pure function and called the same code from a Node script that parses FIT and GPX files, so the validation runs the same simulation the web page runs. ## The setup I picked four rides that varied in length and climbing density: 1. A short hilly loop, 32 km 2. Another short hilly loop, 35 km 3. A medium-length climb-heavy ride, 56 km with one long climb 4. A long mountainous ride, 101 km with a 30 km descent Across all rides I held the parameters constant: - FTP: 300W (used for IF/TSS context. The prediction is driven by avg power directly.) - Rider weight: 85-88kg depending on the ride - Bike weight: 9kg - CdA: 0.35 m² (my normal hoods position) - Crr: 0.0035 (modern slicks) - Drivetrain loss: 2% - Air density: 1.16 kg/m³ (warm-ish days) - Headwind: 0 (none reported) For each ride I asked: at my actual average moving power, what finish time does the calculator predict? Then I compared to actual moving time from Strava (which strips out auto-pause for traffic lights and food stops). ## The four rides | Ride | Distance | Climbing | Climbing density | Avg power | Moving time | Predicted | Δ | | --- | --- | --- | --- | --- | --- | --- | --- | | [Getting the Suffering In](https://www.strava.com/activities/18200826742) | 35 km | +695 m | 20 m/km | 184W | 1:32:41 | 1:31:14 | **−1.6%** | | [Internal Center Lock Disc Brakes](https://www.strava.com/activities/18229900006) | 32 km | +667 m | 21 m/km | 220W | 1:17:43 | 1:15:03 | **−3.4%** | | [Monty P and More with the Girlies](https://www.strava.com/activities/18067166303) | 56 km | +1,261 m | 23 m/km | 169W | 2:49:31 | 2:36:47 | **−7.5%** | | [Here, There and Everywhere](https://www.strava.com/activities/18253328060) | 101 km | +1,472 m | 15 m/km | 175W | 4:13:18 | 3:55:33 | **−7.0%** | The calculator is consistently optimistic on these rides. Never once did it predict a slower time than I actually rode. The error sits between 1.6% and 7.5%, and it grows with duration. ## What's driving the bias The model is constant power plus physics. It doesn't see: - **Cornering on descents.** A 7% descent at my weight and CdA hits ~70 km/h in the model. In real life I'm braking for hairpins, sight-line corners, and other traffic. On the 30 km descent in ride 4 I was averaging 50 km/h. The model expected 70. - **Stops inside "moving time".** Strava's auto-pause kicks in at near-zero speed, but a 5 km/h crawl through a village still counts as moving and tanks your average. The model has no concept of villages. - **Fatigue.** A 4-hour effort at 175W avg is hiding the fact that the last hour was probably 165W with the same perceived effort as the first hour at 185W. The calculator assumes you can hold the average forever. - **Variable pacing helping on hills.** This one actually works in the calculator's favour on hilly rides. Surging on climbs at higher-than-avg power saves more time than the same wattage saves on flats. The 7.5% gap on the [Mont Pèlerin](https://en.wikipedia.org/wiki/Mont_P%C3%A8lerin) would be wider if I'd ridden it perfectly steady. The first three pulls predictions to be optimistic. The last pushes them to be slightly pessimistic. Add it up and you get the 2-8% optimistic gap I see on real rides. ## The shape of the error Two patterns from four rides. Small sample, but they line up: - **Error grows roughly with duration.** A 1.5-hour ride is within ~2-3%. A 4-hour ride lands closer to 7%. Real-world overhead doesn't compound, but it does accumulate. The longer you're out, the more time piles up in cornering, braking, and sitting up. - **Climbing density adds friction.** The 56 km ride had the highest climbing density (23 m/km) and the worst error (−7.5%). The 101 km ride had only 15 m/km and similar error. More climbs means more descents, and descents are where the model is weakest. A reasonable heads-up to put on a prediction: expect 2% baseline error, plus ~1-1.5% per hour, plus more if the route is descent-heavy. The number you see on screen is the floor for what's possible if everything goes right. Real rides land slower. ## What I did about it **1. Results are now a three-point prediction range.** The headline now shows a likely time with optimistic and worst-case below it, instead of a single confident-looking number. The likely figure is the physics prediction plus a real-world overhead that grows with duration: roughly 2% baseline plus ~1.2% per predicted hour. The worst-case adds a larger pad for technical descents and bad days. The race plan, fueling calculator, and target-time check all run off the likely time so the planning numbers stay self-consistent. Section-by-section times in the breakdown table stay as the physics estimate, since pacing power output is what those rows are for. **2. Cornering is still the unfinished business.** Modelling corner radius from GPX point geometry and capping local speed at `sqrt(μ·g·r)` is the biggest remaining lever for descent realism. It's also the hardest piece, so I'm sequencing it after the easier wins. Once it's in, the gap between optimistic and likely should narrow on technical courses. ## Try it yourself If you want to validate the calculator against one of your own rides, [it's here](/tools/bike-calculator). Pull up a GPX from a ride where you had power data, enter your actual average power as the climb / flat / descent power, and see how the predicted time compares to what you actually did. If your error is meaningfully outside the 2-8% range I'm seeing, I'd like to hear about it. ]]> info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/building-a-cycling-power-calculator https://www.tpjnorton.com/blog/posts/building-a-cycling-power-calculator Fri, 10 Apr 2026 12:00:00 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/building-a-swiss-transport-mcp-server https://www.tpjnorton.com/blog/posts/building-a-swiss-transport-mcp-server Fri, 27 Mar 2026 12:00:00 GMT **Update (April 2026):** Since publishing this, I've renamed the project from `swiss-transport-mcp` to **`swiss-public-transport-mcp`** to avoid a clash with [an existing server of the same name](https://github.com/malkreide/swiss-transport-mcp) that wraps the `opentransportdata.swiss` APIs. Mine is the one built on `transport.opendata.ch` — different data source, different scope, but the original name was already taken. References below have been updated accordingly. If you've been anywhere near the AI developer space recently, you've probably heard of MCP. The Model Context Protocol is Anthropic's open standard for giving LLMs access to external tools and data. Think of it as USB-C for AI: a universal way to plug capabilities into models like Claude. I've been living in Switzerland, and the Swiss public transport system is incredible. Trains run on time (mostly), trams connect everything, and boats cruise across lakes on a schedule. There's a free, open API that exposes all of it at `transport.opendata.ch`. So naturally, I thought: what if Claude could just... use it? That's how **swiss-public-transport-mcp** was born. ## What It Actually Does The server exposes four tools to Claude: - **`search_locations`** finds stations by name or GPS coordinates - **`plan_journey`** gets connections from A to B, with real-time delays, platforms, and occupancy - **`get_stationboard`** shows live departure/arrival boards for any station - **`get_booking_link`** generates a deep link straight to sbb.ch to buy tickets You can ask Claude "How do I get from Lausanne to Brig this morning?" and it'll give you actual, real-time train options, then hand you a link to book. Here's what that looks like in practice:  ## Why Not Just Use the SBB App? Fair question. The answer is context. When you're mid-conversation with Claude, maybe planning a trip or working out a multi-city itinerary, switching to a separate app breaks the flow. MCP lets the transport data live inside the conversation. Claude can reason about connections, compare options, and factor in things you've already told it. It's the difference between looking something up yourself and having a knowledgeable friend who just knows. ## The Architecture I wanted this to be more than a weekend hack. The codebase follows a clean layered architecture: ```md Tools (FastMCP) → Service → Client → Models → Formatters ``` **Models** are plain Python dataclasses. No heavy validation framework where it's not needed. Pydantic only shows up at the tool boundary, where it validates the inputs Claude sends. The **API client** wraps `transport.opendata.ch` with retry logic using exponential backoff and jitter for rate limits and server errors. It also handles some fun API quirks, like the coordinates being reversed (`x=latitude`, `y=longitude`) and durations coming back in formats like `"00d01:18:00"`. **Formatters** turn raw data into human-readable text rather than JSON. This is deliberate. LLMs process structured text more naturally than nested JSON, and it makes the output immediately useful in conversation. Delays get a ⚠ symbol, walking segments show 🚶, and occupancy displays as `●●○` so you know which carriages to avoid. ## The Fun Bits A few things I particularly enjoyed building: **Deep linking to SBB.** Generating booking URLs sounds simple until you realise SBB's URL format uses underscores instead of colons for times and has its own parameter conventions. Getting this right means Claude can end a journey plan with a link to actually book it, which feels genuinely useful. **Station ambiguity handling.** Ask for "Basel" and the API returns multiple stations (Basel SBB, Basel Badischer Bahnhof, Basel SNCF...). Rather than failing, the service returns a clarification prompt listing the options so Claude can ask you which one you meant. **Real-time awareness.** The server doesn't just give you the timetable. It shows predicted times vs. scheduled, computes delay minutes, flags cancellations, and reports per-class occupancy levels. It's the kind of information that makes the difference between catching your connection and watching it leave. ## Getting Started If you want to try it yourself, clone the repo and add it to your Claude config: ```json { "mcpServers": { "swiss-public-transport": { "command": "uv", "args": ["run", "--directory", "/path/to/swiss-public-transport-mcp", "swiss-public-transport-mcp"] } } } ``` The whole thing is open source and MIT licensed. ## What I Learned Building an MCP server is surprisingly satisfying. The protocol is simple enough that you can get something working fast, but there's real depth in making the output good. Raw API data is rarely what an LLM, or a human, actually wants to read. The formatting layer ended up being where most of the thought went: deciding what to show, what to hide, and how to make a timetable scannable in a chat window. If you've got a favourite API that you wish Claude could access, I'd genuinely encourage you to build an MCP server for it. The barrier to entry is low, and the result feels a bit like magic. Your AI assistant suddenly knowing things it couldn't know before. ]]> info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/building-electronic-press-kit https://www.tpjnorton.com/blog/posts/building-electronic-press-kit Sat, 08 Apr 2023 08:54:29 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/awesome-next-js-api-routes-with-next-api-decorators https://www.tpjnorton.com/blog/posts/awesome-next-js-api-routes-with-next-api-decorators Tue, 09 Nov 2021 17:31:10 GMT /todos/mine` . Anything under the path `pages/api` will only run on the server. There we have it! What we refer to as [Next API Routes](https://nextjs.org/docs/api-routes/introduction). This now means we can build a full-stack application with a single codebase, a "monolithic" architecture. Right off the bat we get several nice-to-haves for free: - Single build process & easy-to-run dev environment for whole app (just run `next dev` ) - Simpler deployments ( `next build` then `next start` in any node-compatible environment) - No CORS worries by default, the frontend and backend are on the same origin! - Monorepo-like sharing by default (think same `tsconfig`, `jest`, `eslint` ) without having to use monorepo managers like `lerna` More experienced developers may see an approach like this as a step backwards, but it's arguable more like a step towards better consolidation of code & resources. Logical concerns can be separated without physical separation itself, and a monolithic architecture is beginning to make more sense for Web apps, most notably with the rise of Incremental Static Regeneration and Server Side Rendering. #### API Routes As listed in the documentation, building API routes with Next looks a lot like building a basic API with Node.js: `gist:tpjnorton/f4d0e18d77ef78f4280dd7abae783d75` Nice and simple. You can use this approach to very quickly and simply build out some server-side functionality! But what if we wanted to start building a REST API, differentiating between different HTTP methods on the same endpoint, modelling our API in terms of resources? What if we wanted to start composing behavior into our API endpoints? Our example quickly swells to something like this: `gist:tpjnorton/ac814805485f8bb2a2652425eefd0f1c` And that's probably the best case, as we've been able to factor out all the actual business logic into the functions `doSomething`, `checkAuth`, `doSomethingElse` and `doAThirdThing`. It'd likely get worse once we'd start getting request bodies etc. Not terrible, but we can likely make this a little easier to read, and a little easier to maintain. ### NestJS Often, developers opt for a framework when building out APIs, as they offer alternative means of representing resources, and many tools and utilities designed to make this process easier. One such example is [NestJS](https://nestjs.com) (Not to be confused with Next.js!). This is a batteries-included, powerful "framework for building efficient, scalable [Node.js](https://nodejs.org) server-side applications". Heavily inspired by [Angular](https://angular.io), this framework allows developers to use abstractions to represent API routes, including reusable services, controllers, modules and more. Here is a simple example copied from its documentation: `gist:tpjnorton/36ef6276e6bf15b27dad5246784992bb` As we can see, this approach uses OOP ideas and decorators to achieve the goals described previously. We specify only the HTTP methods we intend to make available as methods on a class, instead of control flow paths in a function. A little more declarative, and a great foundation if we're looking build out a REST API. So how do we make use of this approach for Next.JS API Routes? ### next-api-decorators This library, written by the wonderful folks at [Story of AMS](https://storyofams.com), an eCommerce tech agency based in Amsterdam, decided to develop a solution using these concepts to make building an API easier to scale with Next.js. Let's revisit our earlier complex example rewritten using their library to demonstrate how it works: `gist:tpjnorton/2d5f2288df65c6211e6ce4a129b15b7c` As we can see, we have changed the way we express our resource handler, swapping a function for a class. On top of this, methods of the class are annotated with decorators to express their purpose. Now, it's up to you which you prefer, as it's not as if this approach makes it much more concise. But it does, as mentioned earlier, transform our approach to describing our resources from an imperative one to a declarative one. I have found while building Next.js APIs out that this approach is a good deal easier to maintain, as eventually each route and each handler **can** and **will** get more complex as your application grows. #### Custom Decorators The last thing I wanted to look at from this example is the `requiresAuth` decorator we see on some of the methods in this handler now. I wrote something like this custom handler for a project recently, and it's proven very useful. This is done using the `createMiddlewareDecorator` utility provided by `next-api-decorators`: `gist:tpjnorton/5411d6fdc26d6da787df1d90a7ca9c2d` Pretty strong stuff 💪 This approach is very flexible and can be applied to both classes and their methods to fit a variety of use cases and declutter your actual business logic. ### Wrapping Up The example I've shown here is very simple and just to give you an idea of the a practical monolithic approach to building a full-stack application using Next.js and its API routes, and how it can be made scalable server-side using `next-api-decorators`. If you're interested in learning more, check out the [documentation](https://next-api-decorators.vercel.app/) and [repo](https://github.com/storyofams/next-api-decorators) for this amazing library. Thanks for reading! 💙 ]]> info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/next-js-12-performance-test-builds-appear-to-be-slower-not-faster https://www.tpjnorton.com/blog/posts/next-js-12-performance-test-builds-appear-to-be-slower-not-faster Mon, 01 Nov 2021 13:31:10 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/if-it-isnt-already-your-startups-react-project https://www.tpjnorton.com/blog/posts/if-it-isnt-already-your-startups-react-project Wed, 25 Nov 2020 07:02:47 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/5-lessons-from-releasing-a-mobile-app https://www.tpjnorton.com/blog/posts/5-lessons-from-releasing-a-mobile-app Mon, 26 Oct 2020 08:54:29 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/useful-custom-hooks-for-tired-react-developers https://www.tpjnorton.com/blog/posts/useful-custom-hooks-for-tired-react-developers Sun, 25 Oct 2020 07:31:10 GMT EDIT: [This tutorial](https://reactnavigation.org/docs/status-bar/#tabs-and-drawer) from the `react-navigation` docs provides a more declarative version of this hook for achieving the same effect. When writing a React Native app using React Navigation, we often run into a particular problem. In short, the device’s status bar is controlled by rendering a `StatusBar` component. But if we have an app with multiple screens, where more than one screen is rendered at once, rather than being lazy-loaded, this approach may fail. This is because rendering this `StatusBar` updates the config under the hood, but only reflects the state when it was last rendered. What this means is if your app has screens A and B, even if you have A visible, if B rendered after A, the status bar will have the config from screen B, which is wrong for screen A. Luckily, the `StatusBar` module from React Native also exports imperative means of setting this config. So what if we could write a hook that makes these imperative calls when a screen focuses, so that we always have the right config? This is a hook I wrote for a project that does just so: `gist:tpjnorton/1cc9b95e1216aca748539eda05866b7e` Only drawback here is it’s not super future-proof for API changes. Now we can set the config on each screen with just a call to `useStatusBar` and it’ll always be correct when the screen becomes focused. This hook-based alternative helps keep your markup clear of rendering `StatusBar` in every screen. ### Going Further — useAppearanceAwareStatusBar What if we have an app that supports both dark and light modes using the phone’s color scheme + preferences, which could change behind the scenes? We can go one further: `gist:tpjnorton/a15db455677b5cf6806527467911a8ff` _A little more complicated, but super powerful!_ Now if the user changes their color preference in your app’s settings, or, for example, the sun sets and your phone’s color scheme changes, this `StatusBar` will be aware of it and match the rest of the app. Here obviously we’re not taking into account the other methods in the `StatusBar` API, which would be a welcome enhancement. ## Wrapping Up As mentioned before, React apps can get same-y. We often find ourselves maintaining the same behavior for lots of components, and hooks are a great way to reuse behavior and make maintenance and iteration speed lightning fast. Thanks for reading! 💙 ]]> info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/animations-in-react-native-just-got-easier https://www.tpjnorton.com/blog/posts/animations-in-react-native-just-got-easier Mon, 05 Oct 2020 00:00:00 GMT info@tpjnorton.com (Tom Norton) https://www.tpjnorton.com/blog/posts/better-react-code-using-functional-programming https://www.tpjnorton.com/blog/posts/better-react-code-using-functional-programming Wed, 30 Sep 2020 00:00:00 GMT { const toast = useToast(); return ( <> Call Go <> ) } ``` Note: I’m being very generic here with my component names, and an imaginary toast hook based off the one from Chakra UI. Looks fine, right? But what if either of those calls fail? You tell yourself you need to write an error handler. So you go ahead and write the following: ```jsx const onApiSubmit = async () => { try { await apiCall(); } catch (e) { toast('Oh no!', e.message, 'error'); } }; ``` Then you add that to the local scope of your component. Not too bad. You’ve now handled that error and sorted it for the user. Then you realize that you’re going to have to do the same thing for that other API call. So you chug along and write the other wrapper: ```jsx const onOtherApiSubmit = async () => { try { await someOtherApiCall(); } catch (e) { toast('Oh no!', e.message, 'error'); } }; ``` You’ve just basically written the same thing twice. Now picture the scene for three, or five buttons. It’s going to be a long day. Fortunately, we can do better, using a little concept from functional programming - known as a Higher-Order Function. ## Higher Order Functions According to Wikipedia, a Higher-Order Function is: “a function that does at least one of the following: takes one or more functions as arguments (i.e. procedural parameters), returns a function as its result”. For example, if you’ve ever used `map`, `filter` or `reduce` in JavaScript, you’ve used a Higher-Order Function. This is because they are **functions you call, giving them a function to call on each element**. The most classic example in the Web world is probably JavaScript’s `setTimeout` : ```js const callback = () => alert('something happened!'); setTimeout(callback, 1000); ``` `setTimeout` is a Higher-Order Function because it takes a callback as a parameter, a function to be executed later. This is a very common pattern we saw in the early days of JS. ## Putting Higher-Order Functions To Work So returning to our examples above: ```jsx const onApiSubmit = async () => { try { await apiCall(); } catch (e) { toast('Oh no!', e.message, 'error'); } }; const onOtherApiSubmit = async () => { try { await someOtherApiCall(); } catch (e) { toast('Oh no!', e.message, 'error'); } }; ``` Can you spot the WET code here? The only difference between both these wrappers is the actual API call that gets made. Every other part of those functions is the same. So what if we could make the wrapper into a Higher-Order Function? That way, the API function could be given as an argument to a single wrapper. ```jsx const withErrorHandling = (callback) => async () => { try { await callback(); } catch (e) { toast('Oh no!', e.message, 'error'); } }; ``` There we go! A single wrapper for that can be used for as many actions as you want. So how do we use it? Simple! Let’s update our example from before: ```jsx import { someApiCall, someOtherApiCall } from './api'; const SubmitButtonGroup = () => { const toast = useToast(); const withErrorHandling = (callback) => async () => { try { await callback(); } catch(e) { toast('Oh no!', e.message, 'error'); } } return ( <> Call Go <> ) } ``` **Much** better. One handler, that provides local error handling to external code. A solution that scales! 🙌 This is just a simple example to show how we can use functional programming on the Web to create concise, elegant applications. There are many more other things we can do in the same vein to make improvements, which I’ll cover in other posts. I use functional programming daily as a React & React Native developer. In fact, I can’t remember the last time I actually wrote a `for` loop. It is, in my opinion, one of many luxuries we web developers enjoy. Thanks for reading! 💙 ]]> info@tpjnorton.com (Tom Norton)