<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Notes on pragmaticp — Piotr’s corner of the internet</title><link>https://pragmadex.com/blog/</link><description>Recent content in Notes on pragmaticp — Piotr’s corner of the internet</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 24 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pragmadex.com/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Using OpenPencil on a real project</title><link>https://pragmadex.com/blog/openpencil-in-a-real-project/</link><pubDate>Sat, 24 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/openpencil-in-a-real-project/</guid><description>&lt;p&gt;A design tool is easy to like while making the first screen. The more useful test comes later: change a shared control, switch the theme, and see what happens to everything around it.&lt;/p&gt;&#10;&lt;p&gt;That was the interesting part of using OpenPencil for Coffee Diary. The design needed to follow the app as its screens and product model changed. A good-looking collection of frames was only the starting point.&lt;/p&gt;&#10;&lt;p&gt;One pass used fixed colours and duplicated controls. It looked plausible, but it missed what I wanted from the file. Light and dark needed to be actual theme modes. Buttons and fields needed to be instances of shared components. Otherwise, the next change would mean another round of manual repairs.&lt;/p&gt;</description></item><item><title>When a hobby needs a system</title><link>https://pragmadex.com/blog/when-a-hobby-needs-a-system/</link><pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/when-a-hobby-needs-a-system/</guid><description>&lt;p&gt;A hobby can produce a surprising amount of information. Recipes worth keeping, books to return to, things to try next. At some point, a small notebook or an app starts to look useful.&lt;/p&gt;&#10;&lt;p&gt;As a developer, I have an obvious way to respond: build something. Coffee Diary is one example. A coffee and its recipes have enough detail to be worth remembering, and making a tool for that is a hobby in its own right.&lt;/p&gt;</description></item><item><title>Two questions about a cup of coffee</title><link>https://pragmadex.com/blog/coffee-and-recipe-are-different-questions/</link><pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/coffee-and-recipe-are-different-questions/</guid><description>&lt;p&gt;Would I buy this coffee again? Did I enjoy this recipe?&lt;/p&gt;&#10;&lt;p&gt;They sound close enough to combine into a single rating. In Coffee Diary, separating them made the product model clearer.&lt;/p&gt;&#10;&lt;p&gt;A coffee can be worth buying again even if a particular recipe didn&amp;rsquo;t work out. A recipe can also produce a good cup without settling whether I want another bag. Those are different judgments, made about different things.&lt;/p&gt;&#10;&lt;p&gt;The revised model gives the Coffee its own preference and the Recipe its own enjoyment state. Both can remain undecided. A first-choice recipe is an explicit choice among the enjoyed recipes for that coffee.&lt;/p&gt;</description></item><item><title>A notebook for marathon preparation</title><link>https://pragmadex.com/blog/a-notebook-for-marathon-preparation/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/a-notebook-for-marathon-preparation/</guid><description>&lt;p&gt;I want to make room here for my marathon preparation. It belongs on a personal website just as much as the software projects do.&lt;/p&gt;&#10;&lt;p&gt;The useful starting point is a notebook. A short record of what happened, what seemed difficult, and what I want to pay attention to next. I don&amp;rsquo;t need every entry to explain a training method or turn a run into a lesson.&lt;/p&gt;&#10;&lt;p&gt;Some entries could be very small. What did I expect from the week? What actually fitted around the rest of life? Was there something about a particular run that I would otherwise forget? That feels like enough material for a note.&lt;/p&gt;</description></item><item><title>A screen is not a database table</title><link>https://pragmadex.com/blog/a-screen-is-not-a-database-table/</link><pubDate>Sat, 10 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/a-screen-is-not-a-database-table/</guid><description>&lt;p&gt;Imagine a mobile screen that shows an app&amp;rsquo;s recent activity alongside a small summary. The server has the information, but the client has to make several requests and join the results before it can draw anything useful.&lt;/p&gt;&#10;&lt;p&gt;It is tempting to treat that as an immediate argument for GraphQL. I would first ask whether the existing API is giving the screen the right response.&lt;/p&gt;&#10;&lt;p&gt;An HTTP/JSON API can return a composed read model. The public response doesn&amp;rsquo;t have to mirror the database tables, or require the client to discover how the backend stores everything. An endpoint for the activity screen might return the recent entries and the summary together.&lt;/p&gt;</description></item><item><title>Choosing an API for my Flutter app</title><link>https://pragmadex.com/blog/choosing-an-api-for-flutter/</link><pubDate>Fri, 09 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/choosing-an-api-for-flutter/</guid><description>&lt;p&gt;When comparing REST, GraphQL, and gRPC for a Flutter app, I found it more useful to start with a screen than with a protocol.&lt;/p&gt;&#10;&lt;p&gt;What does the screen need to show? Which operations change data? Does anything need to stream? Those questions give the comparison something concrete to work with.&lt;/p&gt;&#10;&lt;p&gt;For the project I researched, the recommendation was HTTP/JSON with OpenAPI, generated Dart clients, and read responses that bring together the data a screen needs. That was a design recommendation. I hadn&amp;rsquo;t run a benchmark proving one protocol faster than the others.&lt;/p&gt;</description></item><item><title>A voice for more than ten seconds</title><link>https://pragmadex.com/blog/a-voice-for-more-than-ten-seconds/</link><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/a-voice-for-more-than-ten-seconds/</guid><description>&lt;p&gt;A short text-to-speech demo answers a fairly narrow question: does this voice make a good first impression?&lt;/p&gt;&#10;&lt;p&gt;For listening to a chapter or a long article, I would want a different test. Can I comfortably follow the meaning after several minutes? Does the voice make sentence boundaries clear? Is the pacing still pleasant when the text gets complicated?&lt;/p&gt;&#10;&lt;p&gt;Fantasy would make useful test material. Invented names and unfamiliar place names can reveal awkward pronunciation quickly. Dialogue adds another question: can I tell where speech ends and narration resumes without concentrating on the voice itself?&lt;/p&gt;</description></item><item><title>When a level-up means something</title><link>https://pragmadex.com/blog/what-makes-litrpg-progression-interesting/</link><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmadex.com/blog/what-makes-litrpg-progression-interesting/</guid><description>&lt;p&gt;A character gains a level. The numbers go up. Whether that moment is satisfying depends on what the change allows them to do next.&lt;/p&gt;&#10;&lt;p&gt;The part of LitRPG I want to explore here is the relationship between a system and a story. A new skill can solve an old problem, introduce a difficult choice, or make a character reconsider how they have been doing things. It gives the progression consequences.&lt;/p&gt;</description></item></channel></rss>