Recently, I read a post by Manuel Moreale that inspired me to think seriously about downsizing my own personal project load. Just the very thought of downsizing feels like dreaming about fresh mountain air when you’re stuck in a city of pollution. The prospect of a breath of clean air inspired me to take concrete steps in that direction, the first of which was taking stock of what my project situation currently looks like.

It’s really amazing how many projects I seem to have going on at any given time. At the moment, I can count eleven active programming projects, three active writing projects and three renovation projects on our home. That’s not even including the projects I actively work on for my job or the regular chores, household responsibilities and fatherly duties that occupy much of my non-working time. Oh, and did I mention I currently have twelve domain names I’m paying for, some of which don’t even have active websites behind them because I optimistically bought them thinking that a project might get far enough along to actually release?

The main focus of this post is going to be my personal programming projects which I’m currently inundated with. I tend to start a lot of them, then abandon them as my interests wax and wane. That means I end up with a graveyard of hardly finished, half-finished and mostly finished projects that never actually see the light of day. One day, I’ll work on one of them, then shift gears the next day to another one, but then decide an hour later to start a brand new one because the creative muse suddenly struck the back of my head with its cudgel. Two days later, I’ll pick up an old one again, but then just as quickly abandon it once more. And on and on it goes. Some go for years without seeing any activity while others, like this blog, get regular updates.

It sounds crazy, but it gives me a safe space to experiment with new technologies, new ideas, new archictectures and new methodologies. I don’t think I’ll ever stop doing it because my curiosity won’t (and shouldn’t) be tamed. However, it also means I have to clean house every once in a while.

The first thing I’m going to do is cancel all domain names I’m not actively using. The next thing will be to “archive” all of my inactive projects as well as the projects I’ve decided to no longer work on. That involves moving everything from my MacBook to an “archive” folder on the 4 TB hard drive on my desktop PC. This not only frees up space on my primary machine (my MacBook), but also cleans up mental space. Most of them are also on GitHub which means I will also archive those repositories.

This whole process isn’t anything new for me, but it is the first time I’ve written about it that I can recall. That said, what makes this time different is that I’m thinking it’s time to clean up some of my older released projects that have been around in some cases for decades. One such example is my history blog, History Rhymes. I started it in 2008 and actively posted until about 2019/2020. I’ve been hosting and maintaining it now for years without actually doing anything with it. So, I’ve been thinking about shutting it down.

While I would import the posts into this blog and set up redirects so that the posts are preserved, shutting the blog down will free up some mental space in my head. In the end, it’s really about consolidation. The less active sites I have, the less overhead I have. It’s the same with my German blog. I hardly write anything on it, so why keep it around as a separate entity and add to my maintenance overhead? Instead, I’ll just import the posts into this blog too and shut it down as well. That’s two of the four blogs I currently have to maintain — a 50% reduction of maintenance overhead and mental bandwidth.

I’ve already staged this scenario locally by running a WordPress instance in a Docker container using a recent database dump from this blog. I then took the WordPress export files from both History Rhymes and my German blog, customized the tags and categories manually in the XML, then imported them locally. I repeated this process until they imported cleanly with the right tag/category mixture that felt right to me. In essence, I’m ready to do it and just need to pull the import trigger.

At some point in the future, I may consolidate the last remaining blog into this one as well and just have one single blog for everything, but that won’t be for quite some time, if I do it at all.

Other contenders for consolidation are my portfolio site and this blog. I’ve always kept them separate using WordPress for my blog and whatever flavor of interesting technology happens to be tickling my tongue at the moment to power my portfolio site. I’ve used Frontpage 2000, plain HTML (pre-CSS), ASP (pre-.NET), PHP, Java, Node.js (with and without TypeScript), and Next.js (which is currently powering it). Most iterations used vanilla PHP or PHP with Symfony.

That said, I’m thinking it’s about time for WordPress to power it for the first time ever. While not glamorous or exciting, it would allow me to consolidate the two websites into a single entity. I use a fully custom theme for my blog anyway which gives me absolute control over the design and what I can do with it. By creating custom templates combined with CSS and JavaScript, I can do just as much with a WordPress page as I can with any other PHP page. In fact, a lot of the pages on this blog are already custom templates with content fully maintained in code rather than the CMS proper. Even the Sitemap page is generated automatically by code. I only use the CMS to power the blog and a few of the basic pages like the Privacy Statement.

But I digress. There are a couple of other released projects like Haunted House Software I may just shut down entirely or consolidate into this blog and/or my portfolio site without any fanfare whatsoever. We’ll see. The real point is that I want less. I only want what’s most important to me right now and everything else can be shut down, consolidated and archived.

Planning and executing such consolidation processes takes its own effort and mental spaces, but once it’s done, it will feel enormously refreshing — like a breath of fresh mountain air.

Going through my recent technical conversations with AI about various architecture and technology choices, I thought I would post this one first. It’s a shorter conversation, but is still typical of the discussions I’ve had. In this case, it’s about the technology and architecture choices that would work well for a publishing platform.

Given my interest in blogging and the fact that I currently have four more or less active blogs all running on WordPress, I’ve often wondered what the best technology stack would be to create a custom replacement for WordPress. I’ve thought about this and made several failed attempts at actually implementing one for years. WordPress is incredibly sticky though and works just well enough that I haven’t fully gone through the effort of creating a full replacement. That said, I still like to think about it and that’s what this conversation is mainly about.

However, in this conversation, my curiosity gets the better of me and I go off on a tangent about massive publications like BBC that process enormous amounts of requests and what it would choose for that situation as well. It’s an interesting insight.

I did restrict it, though, to the four main languages I’m familiar with: TypeScript/Node.js, PHP, .NET and Swift (using the Vapor web framework). Even if it were to actually choose something else if I gave it free rein (which I’ve done in other conversations), I originally began this one with the idea that I might actually implement it. Needless to say, that never happened.

You can see my thoughts on the conversation at the end of the post. Also, you can view the original conversation on Gemini here.

Prompt: I’ve been thinking about what it would take to create a publishing platform for a website that needs the following features: posts with categories, subcategories and tags, users with several roles (reader, admin, contributor, editor, author), a CMS for editing and publishing contents, comments, media, etc., a frontend that is publicly accessible, a frontend cache, the ability for registered users (reader role) to leave comments, RSS feeds, an API for apps to access published content, ability to create, send and manage newsletters, support for multiple languages, the ability to automatically post to social media when new content goes live, support for multiple podcasts, support for video content, and the ability to add several other features. I would like to use TypeScript, PHP, .NET or Swift+Vapor as a technology stack. What would you recommend? Also, what would you recommend in terms of other parts of the tech stack, for example databases?

Building a platform with this level of complexity—encompassing strict RBAC, multi-tenant-like media handling, multi-language support, and heavy API/caching requirements—demands an architecture that prioritizes long-term maintainability and performance.

Given the requirement for a robust, long-term solution, here is a breakdown of how the candidate technologies stack up for this specific feature set, along with recommendations for the wider architecture.

The Backend Application Layer

1. TypeScript (Node.js with Fastify or NestJS)

• The Verdict: The strongest pragmatic choice for this specific feature set.
• Why: A platform doing social media auto-posting, RSS generation, newsletter dispatching, and media handling benefits massively from the Node ecosystem. You won’t have to write integrations for AWS SES (newsletters) or Twitter/LinkedIn APIs from scratch.
• Architecture Fit: Using Fastify gives you excellent throughput for the API and frontend rendering. Having TypeScript on the backend also allows you to share types and validation logic directly with your frontend, speeding up iteration.

2. Swift + Vapor

• The Verdict: The best choice for raw performance, memory safety, and a low-dependency footprint.
• Why: If you want a highly performant, tightly controlled architecture with minimal overhead, Vapor is outstanding. It is particularly strong for building custom, lightning-fast APIs and handling heavy concurrent read requests.
• The Trade-off: The Swift server-side ecosystem is smaller. You will likely find yourself writing custom wrappers for third-party APIs (like social media auto-posting or newsletter service integrations) that would be off-the-shelf packages in TypeScript or PHP.

3. PHP

• The Verdict: Highly capable, but depends on your approach.
• Why: If you utilize a heavy framework like Laravel, this entire feature list is practically its blueprint. However, if you prefer building custom architectures or using vanilla PHP for long-term stability, managing the sheer volume of features (especially asynchronous tasks like bulk newsletter sending and video processing) can become complex compared to event-driven environments.

4. .NET

• The Verdict: An enterprise powerhouse, but potentially heavier than necessary.
• Why: It has phenomenal out-of-the-box support for complex user roles, authentication, and localization. However, it can feel bloated if your goal is a streamlined, low-dependency application.

Recommendation: If you want to move quickly and lean on existing integrations for the auxiliary features (social, newsletters), go with TypeScript. If you prioritize a lean, compiled, and highly performant core and don’t mind writing custom integrations, go with Swift + Vapor.

The Wider Tech Stack Recommendations

To support the heavy media, caching, and background processing requirements, you need a decoupled architecture.

1. Primary Database: PostgreSQL PostgreSQL is the undeniable choice here.

• Hierarchical Data: It natively handles the recursive queries needed for categories and subcategories.
• Relational Integrity: Perfect for managing complex many-to-many relationships (users to roles, posts to tags).
• Multi-language: Postgres’s JSONB column type is incredibly efficient for storing localized string variations (e.g., storing a post’s title and metadata in multiple languages) without needing overly complex table joins.

2. Caching Layer: Redis & SQLite

• Redis: Essential for managing rate limiting on the API, session storage, and queue management for asynchronous tasks (like sending a 10,000-subscriber newsletter).
• Read Cache: For the publicly accessible frontend, you need a lightning-fast read cache. Pushing compiled, published markdown/HTML into a highly optimized, file-based SQLite database acting purely as a read-cache for the frontend is a brilliant, low-latency pattern that drastically reduces the load on your primary Postgres database.

3. Object Storage: S3-Compatible Storage (AWS S3, Cloudflare R2, MinIO)

• Do not store podcasts, videos, or high-res images on the local server block. Offload all media to an object storage bucket placed behind a CDN. Cloudflare R2 is highly recommended here due to its zero-egress fee structure, which is vital when serving bandwidth-heavy podcast and video files.

4. Background Workers / Queues

• Features like “automatically posting to social media,” “sending newsletters,” and “processing video content” cannot run on the main thread. You will need a dedicated background worker process. In TypeScript, this would be BullMQ; in Vapor, you would utilize SwiftNIO’s event loops or a dedicated queuing package to handle these jobs asynchronously.

Given the heavy media requirements for podcasts and video, are you planning to encode and transcode those media files yourself on the server, or will you offload that processing to a specialized third-party service?

Prompt: This is just a thought experiment. I feel like I really want to create something like this, but can’t justify doing it for myself since I have no real use for it.

That “itch” is incredibly real. There is a specific kind of developer joy in designing a sprawling, beautifully engineered machine just to watch the gears turn perfectly. It’s the digital equivalent of building a highly detailed model railway in the basement—you don’t build it because you need a tiny train to commute to work; you build it for the sheer mastery of the craft.

When you don’t have a commercial “use case” or a client breathing down your neck, the justification changes. It stops being about “product-market fit” and becomes about technical play.

If you look at it through that lens, building a platform like this is actually the ultimate sandbox. It lets you:

• Test extreme architectures: You can try out patterns that a risk-averse company would never let you deploy—like using a compiled, zero-dependency Swift/Vapor binary as a lightning-fast API, or using a flat-file markdown system with an SQLite database acting as an ultra-high-speed, read-only cache.
• Build a reusable blueprint: If you design it with strict modularity, you aren’t just building a single website. You’re building a personal, battle-tested framework. The next time you (or a friend, or a client) need a fast blog, a portfolio, a newsletter manager, or a podcast feed, you can spin up a lightweight, highly optimized instance of your own engine in minutes rather than reaching for a bloated, dependency-heavy third-party tool.

Sometimes, the best justification for building something is simply that you want to see if you can make it run faster, cleaner, and more elegantly than anything else currently out there.

If you did let yourself build even just a small, highly optimized slice of this system purely for the intellectual fun of it, which specific architectural piece would you want to tackle first?

Prompt: Back to the original question. How would your recommendation change if the project were for a major news organization like BBC?

For an organization at the scale of the BBC, the architectural requirements shift dramatically. You are no longer just optimizing for CPU cycles or memory footprints on a single server; you are optimizing for global high availability, extreme read-to-write ratios, talent pool hiring, and disaster recovery.

A breaking news event can instantly drive millions of concurrent users to the platform. If the system fails for even five minutes, it is national news.

Here is how the recommendations and the wider architecture would change for an enterprise news organization of this scale.

1. The Technology Stack Shift

At BBC scale, a single monolithic backend is replaced by a decoupled, microservices, or federated API architecture.

                           [ Edge CDN (Fastly / Cloudflare) ]
                                          |
                        [ BFF / API Gateway (Node.js / GraphQL) ]
                                          |
         +--------------------------------+-------------------------------+
         |                                |                               |
[ Editorial CMS ]                [ Content Delivery Service ]    [ Media & Transcoding ]
 (.NET / Java / Go)                   (Go / Node.js)               (AWS Elemental / S3)

The Backend Tier: TypeScript & Go/Java/ .NET

• The Winner for Delivery: TypeScript (Node.js) remains highly recommended, but specifically for the BFF (Backend-for-Frontend) or API Gateway layer. The BBC actually uses Node.js heavily for its web rendering tier because of its asynchronous I/O performance and the massive talent pool available in the UK and globally.
• The Winner for Core Services & Workflows: For the heavy-lifting core services (like user permission management, editorial workflows, and localization engines), .NET, Java, or Go become the standards. They offer robust typing, enterprise-grade stability, and seamless integration with legacy newsroom systems (like ENPS or AP ENPS).
• The Swift + Vapor Verdict: Ruled out. While technically brilliant, a major news organization cannot risk building core infrastructure on a niche server-side technology. The talent pool of server-side Swift developers is too small to sustain round-the-clock global engineering teams.

2. The Database & Storage Strategy

The simple PostgreSQL database and SQLite cache model must scale out to handle massive write distribution and global read replication.

• Primary Database: A globally distributed database cluster. Instead of standard PostgreSQL, you would use Amazon Aurora PostgreSQL (with multi-region read replicas) or a distributed SQL database like Google Cloud Spanner or CockroachDB. This ensures that if an entire AWS region goes dark, the CMS and public site remain online.
• Content Store (NoSQL): Article body content and historical archives (which can span decades and millions of posts) are often stored in document stores like MongoDB or DynamoDB because of their horizontal scaling capabilities and flexible schemas for different content types (live blogs, photo galleries, long-form articles).

3. Caching: The Real Savior (Edge Caching)

At this scale, 99.9% of the public-facing read traffic must never hit your origin servers.

• The Edge CDN: You would use enterprise-tier CDNs like Fastly or Cloudflare with instant purging capabilities.
• Surrogate Keys / Cache Tagging: When an editor updates a breaking news article, the CMS sends a purge request to the CDN using a unique surrogate key (e.g., article-12345). Within milliseconds, that specific page is invalidated globally across all edge nodes, while the rest of the site remains cached.
• Stale-While-Revalidate: The CDN is configured to serve stale content to users for a few seconds while fetching the freshly updated article in the background. This prevents “cache stampedes” (where thousands of simultaneous requests hit the database at the exact moment a cache expires).

4. Media, Video, and Podcasts

At BBC scale, you cannot host or transcode video files yourself on a standard server block.

• Transcoding Pipelines: Raw video and audio uploaded by journalists must be pushed to a dedicated pipeline like AWS Elemental MediaConvert. It automatically packages the video into multiple bitrates and formats (HLS/DASH) for seamless playback on everything from low-bandwidth mobile devices in rural areas to 4K smart TVs.
• Multi-CDN Strategy: To deliver video and podcast files globally without buffering during high-traffic events, you distribute the bandwidth load across multiple CDN providers (e.g., Akamai, Cloudflare, and Fastly) dynamically based on the user’s geographic performance.

5. Security & RBAC (Role-Based Access Control)

Security changes from a simple database table to a compliance-heavy identity provider.

• Identity & Access Management (IAM): Rather than handling passwords in-house, the CMS integrates with enterprise identity providers (like Okta or Ping Identity) via SAML/OIDC.
• Audit Trails: For a major news outlet, an unauthorized post can cause geopolitical or financial chaos. The system requires cryptographic audit logs tracking exactly who wrote, edited, approved, and published every single character.

Prompt: And how would the architecture change for a small publication with only about 1000-3000 views per day?

For a small publication pulling in 1,000 to 3,000 views per day, the architectural priorities flip completely. At this scale, you are no longer architecting for global redundancy or massive concurrent spikes. Instead, your primary design goals are:

1. Extreme cost efficiency (ideally keeping hosting under $10–$20/month, or even entirely free).
2. Minimal maintenance overhead (no complex Kubernetes clusters, microservices, or multi-node databases to monitor).
3. Simplicity and longevity (the system should be able to run for years without touching it).

Here is how the architecture collapses into a highly optimized, elegant, and low-cost setup.

1. The Technology Stack Shift

At 3,000 views a day, a single user is visiting the site roughly once every 30 seconds on average. Any modern CPU can handle this load in its sleep.

The Backend Tier: Swift + Vapor or PHP (Vanilla/Lightweight)

• The Winner for Performance & Fun: Swift + Vapor. Because Vapor compiles to a single, highly efficient native binary, it uses an incredibly small memory footprint (often under 30–50MB of RAM at idle). You can easily run the entire application, database, and cache on the cheapest $4–$5/month VPS (like a shared-CPU Hetzner or DigitalOcean droplet) with resources to spare.
• The Winner for Simplicity: Vanilla PHP or a micro-framework. It is virtually zero-maintenance, runs on any cheap hosting provider, and has zero compile steps.
• TypeScript & .NET Verdict: Node.js/TypeScript is still fine, but its memory footprint is higher than Swift. .NET is massive overkill and will require a larger, more expensive VPS just to keep the runtime comfortable.

2. The Storage & Database Strategy

You do not need dedicated, managed database instances.

• The Database: SQLite
  • Why: For 3,000 views a day, SQLite is the absolute king. Modern SQLite handles concurrent reads incredibly well (especially in WAL mode), requires zero server setup, and exists as a single file on disk. This makes backups as simple as copying the database file to an S3 bucket once a day.
  • You do not need PostgreSQL, MySQL, or Mongo. SQLite can easily handle millions of rows and a few thousand requests a day without breaking a sweat.

3. Caching & Frontend: Static Generation (SSG) or Edge-Cached SSR

The absolute best architecture for a small publication is to decouple the CMS from the frontend entirely.

[ Writer / Admin ] ---> [ CMS (Vapor or PHP + SQLite) ] 
                               |
                   (Generates static HTML / RSS)
                               |
                               v
               [ Cloudflare Pages / Vercel (Free) ] <---> [ Reader ]

Option A: Static Site Generation (SSG) — Highly Recommended

• Your CMS is just a private, password-protected backend.
• When you publish a post, the backend compiles the website into static HTML, CSS, and RSS files and pushes them to a free static hosting service like Cloudflare Pages, GitHub Pages, or Vercel.
• The Result: Your public site is virtually un-hackable, loads instantly worldwide, has zero server hosting costs, and can handle a sudden spike of 1,000,000 users without you paying a single extra penny.

Option B: Server-Side Rendering (SSR) with SQLite Cache

• If you want dynamic features like reader comments, you run your Swift/Vapor or PHP app on a cheap $4 VPS.
• The Cache: You use a simple in-memory cache (like Vapor’s built-in memory cache) or build a custom, ultra-fast read-cache using a secondary, memory-mapped SQLite database.
• The CDN: You put a free Cloudflare proxy in front of it. Cloudflare will cache your static pages and assets at the edge, meaning 90%+ of your 3,000 daily views never even hit your $4 VPS.

4. Media, Newsletters, and Podcasts

At this scale, you want to offload specialized tasks to free or low-cost tiers.

• Media Storage: Use Cloudflare R2 or Backblaze B2 for hosting images, podcast MP3s, and video. Both have incredibly generous free tiers (R2 gives you 10GB of storage and millions of class A/B operations per month for $0).
• Newsletters: Writing a custom bulk-email engine is painful and risks your server’s IP getting blacklisted. Instead, use your backend to collect subscriber emails in your SQLite database, and use a service like Mailgun or Brevo (which has a free tier of up to 300 emails/day) to send the newsletters via a simple API call.
• Social Auto-Posting: Instead of writing complex API integrations for every social media platform, your CMS can simply output a clean, standard RSS feed. You can then use a free automation tool (like Zapier, Make, or a simple custom cron job script) to watch that feed and post to Mastodon, Bluesky, or LinkedIn when a new item appears.

My Thoughts on the Conversation

Most of its advice made a lot of sense to me, even if I might implement some of it differently. Not much was new to me in terms of technologies or ideas which, I suppose, shouldn’t be that surprising. I’ve never worked on a platform that will see a sudden spike of 1,000,000 users, but I’ve certainly worked on enough platforms to be familiar with concepts such as edge caching that make such spikes possible without the system crashing.

I really do enjoy using AI for conversations like this one. I find it very inspirational and it motivates me to actually sit down and program something, even if I never actually finish it. In this case, I didn’t really do anything after having this discussion, but I nonetheless enjoy the thought experiment.

Nonetheless, I thought I’d jump on the bandwagon and create a few of them myself. Most of them I don’t really see a need to bother with, so I won’t, but I did create a few I thought would be interesting and/or helpful.

Here are the new pages I just created:

• /ai – How I use AI.
• /blogroll – A few of the blogs I’ve subscribed to.
• /changelog – Where I document changes made to this website.
• /colophon – The technologies that power this website.
• /sitemap – A directory of all the pages on this website.

I may or may not add more as I go, but that’s all I felt like doing tonight. The list above is an incomplete list of pages on this website, but you can see all of them on the Sitemap page which WordPress automatically generates and keep up to date.

Lately, I’ve been having a lot of very interesting conversations with LLMs about a wide range of topics. However, most of them have pertained to technical topics and I thought it would be interesting to post some of them on my blog. I figure there are probably plenty of other people who might be interested in the questions I ask and what AI has to say about it, so why not post them? If nothing else, then at least it’s a way of preserving them for my future self.

Most of my recent discussions have been about the pros and cons of various frameworks and programming languages for specific use cases. I’ve also asked about how best to architect specific scenarios such as the massively complex single-page frontend applications used by AWS, Google Cloud Platform and Microsoft Azure. I’ve thoroughly enjoyed the conversations as they’ve been extremely informative and thought-provoking, even if I wouldn’t always necessarily take its advice verbatim.

Most of these conversations I’ve had have been with Gemini as I’ve found it to give me the most thought-provoking answers. I’ve also had a few with GitHub Copilot using the Claude Sonnet and Codex models, but due to the recent extreme increase in price, I’ve started saving my tokens for actual programming tasks rather than casual conversations.

One of the aspects I enjoy most about these talks with AI is that I find the occasional gem that really helps me out. For example, a couple of days ago, I was discussing the longevity of PHP projects in a classic LAMP stack and mentioned that I was using Apache with mod_php — something I’ve done for nearly three decades. It suggested switching to php-fpm instead in order to boost my websites’ speed. Of course I’d heard of php-fpm, but had never actually used it personally. Changing my server config was a simple task that actually tangibly boosted the speed of all the websites I host on it, including this blog. It was a simple thing I wouldn’t have thought of that had a major impact.

In any case though, I’m going to go through some of my recent conversations and copy them into posts on this blog. I’ll start with an introduction to explain a little bit of the background of each conversation and conclude them with my thoughts about it and whether it led to any direct action on my part either at work or in my personal projects. I may edit out parts of the discussions that aren’t strictly relevant as I tend to go off on tangents before eventually telling AI to get back to the original question, but I’ll try to keep them as close to the original conversation as possible.

I hope you’ll enjoy them as much as I have and that maybe they’ll even prove inspirational.

Just a side note about my blogs: Other than some images (like the one above), I don’t post any AI-generated content that isn’t explicitly marked as such. Blogging is a passion of mine and I feel no need to fluff my post count with articles not written by me. You can read more about how I use AI on the AI page.

Before reading The Bride of Ashbyrn House, I had never read anything by Amy Cross. Not only did the novel impress me, but it quickly became one of my all-time favorites. That’s an impressive feat for a new-to-me author to achieve after only a single book. As such, I knew I had to write about it next.

The story had everything I love about ghost stories: an old haunted manor, a vengeful ghost, an intriguing story and a sense of thrill that kept the pages turning. This time though, they were digital pages as I read it on my Kindle rather than as a paperback. As of this writing, it isn’t available in paperback form.

Here is the description of the book from Goodreads:

“I have waited so long for your return.”

In the English countryside, miles from the nearest town, there stands an old stone house. Nobody has set foot in the house for years. Nobody has dared. For it is said that even though the lady of the house is long dead, a face can sometimes be seen at one of the windows. A pale, dead face that waits patiently behind a silk wedding veil.Seeking an escape from his life in London, Owen Stone purchases Ashbyrn House without waiting to find out about its history. As far as Owen is concerned, ghosts aren’t real and his only company in the house will be the thin-legged spiders that lurk on the walls. Even after he moves in, and after he starts hearing strange noises in the night, Owen insists that Ashbyrn House can’t possibly be haunted. But Owen knows nothing about the ghostly figure that is said to haunt the house. Or about the mysterious church bells that ring out across the lawn at night. Or about the terrible fate that befell the house’s previous inhabitants when they dared defy the bride. Even as Owen starts to understand the horrific truth about Ashbyrn House’s past, he might be too late to escape the clutches of the presence that watches his every move. The Bride of Ashbyrn House is a ghost story about a man who believes the past can’t hurt him, and about a woman whose search for a husband has survived even her own tragic death.

Goodreads

Since I’m going to freely discuss the story, there will be spoilers! Continue at your own risk!

Recently, it feels like there has been an onslaught of horror stories that have to do with dead brides. I seem to see books and movies about them all over the place, but of all of them I have read or seen, The Bride of Ashbyrn House stands out as the best. The story primarily takes place at Ashbyrn House in Cornwall, England. It alternates between the events of 1859 when an upperclass woman named Katinka Ashbyrn is due to marry her fiancé, and the present when a man named Owen buys the allegedly haunted property. The further the story moves along, the clearer the bridge between the two time periods becomes.

Katinka

The story begins from Katinka’s perspective. She is watching from the house as her husband comes up to the gates outside, sees her, then turns around and leaves, abandoning her. It immediately leaves the reader with a feeling of unease, a sense of sympathy for Katinka, and many questions. Fortunately, they are answered throughout the story, however, some of them not until the last few pages. The reader has no idea at this point that the opening scene takes place in the present.

Most of the story from Katinka’s perspective takes place in 1859, shortly before her planned wedding. She wants it to be absolutely perfect and nothing will stop her from getting what she wants. First and foremost, however, she is to be the picture-perfect centerpiece of it all. In her vanity, she commissions a portrait of herself which arrives shortly before the wedding. For the next several days, much of her time is occupied with sitting and admiring herself in the painting. Eventually, she convinces herself that she appears much more attractive in the picture than in real life which she won’t tolerate. Thus, she begins a strict regiment of self-mutilation to ensure she is skinnier and, in her mind, prettier — the perfect centerpiece for the wedding.

At this point in the story, it’s clear that she is a selfish, highly toxic person who doesn’t quite have all of her ducks in a row. Aside from what she does to herself, she practically worships her dead father while belittling and berating her mother and her younger sister, Pippa. Her fiancé is also subjected to torrents of verbal abuse which culminates in her catching him cheating on her in the pantry with Pippa. For that, Katinka murders her sister coldheartedly without so much as batting an eye.

Come the day of the wedding, all of the guests have assembled at Ashbyrn house. To make her grand entrance, Katinka has arranged to ride in a coach. However, as the coach rumbles down the rough driveway, tragedy strikes. Katinka, who has used a healthy dose of paraffin — a highly flammable substance — on her skin to make herself appear perfect, is jerked out of her seat and her face comes into contact with the candle lighting the interior of the coach. Instantly catching fire, she stumbles out of the coach screaming for help, but no one comes to her rescue. Instead, they just watch as she jumps into a pond where her weighted dress pulls her down to the bottom where she ultimately drowns. As she is dying, she can see the guests assembling around the pond watching her, but not bothering to help her. She dies unwed.

Owen

Fast forward to the present. A man named Owen buys the abandoned Ashbyrn House to escape the hustle of London and focus on his writing. He is told of the story of the ghost bride, but dismisses it as pure fancy. Naturally, he comes to regret that. The ghost of Katinka seems almost cautious at first, but the longer Owen occupies the house, the more confident she becomes and eventually starts playing the “perfect bride.” While he is concentrated on his writing, she brings him food and water and takes care of him in every way. However, it’s as though Owen is in a trance during that time and has no idea about what is actually happen. Not only does he stay blissfully unaware of Katinka’s existence, but he can quite literally sit and write for days without any clue as to how much time has passed.

Owen’s ex-fiancé, Vanessa, who is worried about him ignoring all correspondence, eventually travels from London to check on him. Owen still doesn’t realize what has been going on and refuses to leave the house or acknowledge that anything might be off.  The more Vanessa tries to convince him, though, the more aggressive Katinka becomes in defending Owen, who, for better or worse, she essentially considers her husband at this point.

Eventually, Owen snaps out of it and figures out what is actually happening. He tries to escape Ashbyrn House with Vanessa, but Katinka has other plans and refuses to let them leave the grounds. Owen and Vanessa come to the conclusion that if Owen officially marries Katinka in the ruins of the Ashbyrn’s private church where she was originally supposed to be married, that she might at least let Vanessa go. Katinka seems convinced by the idea and so Vanessa officiates the wedding between Owen and the ghost of Katinka.

Shortly thereafter, Vanessa escapes, but Owen stays. Vanessa, however, eventually comes back for Owen. This time, Katinka isn’t having it though and kills her. Owen then manages to escape with Vanessa’s body, never to set foot in Ashbyrn House again.

The story ends with a mirrored version of the opening scene. Owen is looking through the locked gate of Ashbyrn House decades later after having served a long prison sentence for the murder of Vanessa. He sees Katinka watching him from the house and decides to leave again without actually entering the property. Despite not unlocking the gate, Owen already had the key to it in his hand which leads the reader to wonder what exactly his intensions were since he very well knows what waits for him beyond the gate.

My Conclusion

Owen’s and Katinka’s perspectives alternate as both stories simultaneously lead to their individual, yet related, climaxes. It was an incredibly exciting journey that really kept me turning the digital pages wanting to see how it continued. As it progressed, it was hard to determine which character deserved my sympathy the most. In some ways, despite her somewhat evil nature, I couldn’t help but feel sorry for Katinka. In other ways, it was Vanessa who was the most innocent, yet arguably paid the highest price of them all. For some reason, I could never really feel much sympathy for Owen until the end when the reader finds out he had to spend decades in prison for a murder he didn’t commit.

I found the ending to be unnerving in that no one got their comeuppance or was vindicated. Instead, it was the most realistic outcome possible for such a wild, supernatural story. There was no satisfaction or relief for any of the characters whatsoever which made its realism all the more disturbing. What I found excellent about the ending, however, was how it tied in directly to the beginning, just from Owen’s perspective rather than Katinka’s. It also clarified who the anonymous husband actually was and why exactly he chose to just turn around and leave again after seeing her. It was one of the best wrap-ups I’ve seen in a story.

The Bride of Ashbyrn House instantly made me a fan of Amy Cross. I’ve since read two more of her books and I can say with certainty that she has firmly established herself as a staple in my personal library.

You can find more about Amy Cross on her website.

Recently, I’ve been experimenting a lot more with Swift as a language for web applications. I’ve primarily been focusing my efforts on the web framework Vapor which is the most complete and popular web framework for Swift and is used by the likes of some very large projects such as the Swift Package Index.

The framework is based on SwiftNIO which is Apple’s open-source “cross-platform asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.” I also recently read somewhere that Apple itself uses SwiftNIO to power its newer web services as it is low-level and low-latency — both critical aspects considering the sheer enormity of the number of requests that Apple’s web services have to process. Whether or not that is true is something I can’t confirm, but it sounds plausible considering it is an Apple-developed framework that does exactly what a high-performance web service would need.

So, naturally, I asked myself what it would take to make my own basic web app using SwiftNIO without any other dependencies beyond the three others that SwiftNIO itself relies on. As it turns out, it doesn’t actually take as much as I thought. Since I wanted to keep this experiment simple, I focused on basic functionality rather than implementing a fully featured web framework. If I wanted that, I would just go with Vapor.

Before we start, I want to mention that I pushed the entire experiment to GitHub with thoroughly commented code so that you can see what I did and/or play around with it yourself. There will be several links to various parts of the code on GitHub through the post.

Setting Up the Server

The first, and arguably most critical, feature any web application needs is a server. In this case, one that uses SwiftNIO for network communication. In order to accomplish that, I created two classes: HTTPServer and HTTPHandler. As the names might suggest, the first sets up the server and network infrastructure while the latter handles each individual connection.

The HTTPServer class includes a method called start() which uses SwiftNIO’s ServerBootstrap to bind a TCP port and configure how connections are handled:

public func start() async throws {
    let router = self.router

    let bootstrap = ServerBootstrap(group: group)
        // How many pending connections the OS kernel should queue before the
        // application has a chance to accept them.
        .serverChannelOption(ChannelOptions.backlog, value: 256)
        // Allow the port to be reused immediately after the process restarts,
        // without waiting for the OS TIME_WAIT period to expire.
        .serverChannelOption(ChannelOptions.socketOption(.so_reuseaddr), value: 1)
        // For each accepted connection, configure the NIO pipeline:
        //   1. Built-in HTTP/1.1 encoder + decoder
        //   2. Our custom HTTPHandler for routing
        .childChannelInitializer { channel in
            channel.pipeline.configureHTTPServerPipeline().flatMap {
                channel.pipeline.addHandler(HTTPHandler(router: router))
            }
        }

    let channel = try await bootstrap.bind(host: host, port: port).get()
    print("Server running on http://\(host):\(port)")

    // Suspend here until the channel is closed. In normal operation this never
    // returns — the server runs until the process is killed.
    try await channel.closeFuture.get()
}

That’s all that the HTTPServer class actually does. The rest happens in the HTTPHandler class which, as you may have noticed is added as a handler to the channel pipeline.

For each incoming request, a new HTTPHandler instance is created and is responsible for four different tasks:

1. Receiving request parts
2. Bridging to Swift concurrency via Task
3. Writing the response
4. Closing the connection

This is the lifecycle of a single request:

Client connects
        ↓
ServerBootstrap accepts → creates HTTPHandler
        ↓
SwiftNIO fires channelRead(.head)  → store head
SwiftNIO fires channelRead(.body)  → accumulate bytes  (0 or more times)
SwiftNIO fires channelRead(.end)   → dispatch to router via Task
        ↓
Router matches route → calls handler → returns HTTPResponse
        ↓
eventLoop.execute → write response head + body + end
        ↓
Connection closed

Receiving Request Parts

The HTTPHandler class implements SwiftNIO’s ChannelInboundHandler protocol which expects, among other things, the function channelRead(). This function is called multiple times per request and a value identifying which part of the request is currently being handled is passed via one of three different enums: .head, .body and .end. With these, we can determine our course of action and how to handle the data being sent.

One gotcha, however, is that SwiftNIO breaks down large bodies into chunks which means there is the potential for multiple .body parts. I go into more detail about that in the section below where I describe how I implemented the RESTful methods.

Bridging to Swift Concurrency via Task

SwiftNIO operates with event loops which, like when working with Node.js, should never be blocked. As such, we need to ensure that route handlers are executed asynchronously. I implemented that by stuffing them inside a Swift Task when SwiftNIO passes .end:

Task { [head = head] in
    let response = await router.handle(head: head, body: body)
    // ↑ runs on Swift's cooperative thread pool, not the NIO thread
    
    eventLoop.execute {
        self.write(response: response, context: context)
        // ↑ hop back onto the NIO event loop to write the response
    }
}

Writing The Response

The HTTPHandler class is also responsible for serializing the HTTPResponse object returned by the routes (more on that below) into SwiftNIO’s three-part format which includes:

• HTTPResponseHead (status & headers)
• ByteBuffer (body bytes)
• End marker (signals that the response is complete)

This logic takes place in the write() function (see on GitHub):

private func write(response: HTTPResponse, context: ChannelHandlerContext) {
    // Allocate a NIO `ByteBuffer` sized to the response body and copy the bytes in.
    var buffer = context.channel.allocator.buffer(capacity: response.bodyData.count)
    buffer.writeBytes(response.bodyData)

    var headers = HTTPHeaders()
    headers.add(name: "Content-Type", value: response.contentType)
    // Telling the client the exact byte count avoids chunked transfer encoding
    // and lets browsers display progress correctly.
    headers.add(name: "Content-Length", value: "\(buffer.readableBytes)")
    headers.add(name: "Connection", value: "close")

    let responseHead = HTTPResponseHead(version: .http1_1, status: response.status, headers: headers)

    // Write all three parts. The first two use `write` (buffered); the last uses
    // `writeAndFlush` to push everything to the network in one syscall.
    context.write(wrapOutboundOut(.head(responseHead)), promise: nil)
    context.write(wrapOutboundOut(.body(.byteBuffer(buffer))), promise: nil)

    let channel = context.channel
    context.writeAndFlush(wrapOutboundOut(.end(nil))).whenComplete { _ in
        // Close the TCP connection once all bytes have been sent.
        channel.close(promise: nil)
    }
}

HTTPResponse is a Sendable struct I created that contains the response HTTP status, the content type and the body data as a Swift Data object. You can view it on GitHub.

Closing The Connection

The write() function above also contains the code that closes the connection after every response. This is the bit of code responsible for doing that:

let channel = context.channel
context.writeAndFlush(wrapOutboundOut(.end(nil))).whenComplete { _ in
    // Close the TCP connection once all bytes have been sent.
    channel.close(promise: nil)
}

Starting the Server

Now that we have everything in place, all that is left is to instantiate the HTTPServer class and call the start() function at the end of the main.swift file to start the server:

let server = HTTPServer(host: "127.0.0.1", port: 8080, router: router)
try await server.start()

Now that we’ve looked at how the custom server works, let’s see what else the application can do using the server.

What This Basic Web App Can Do

I’ve mentioned several times already that the web app I made is basic and simple. It does, however, contain everything necessary for a basic API application or even a web application with light templating needs. Here is an overview:

• RESTful methods
• Routing
• Basic templating with XSS safety
• Static content
• HTTP/1.1 support

RESTful Methods

First off, the application includes support for routes with all RESTful methods (GET, POST, PUT, PATCH, DELETE) including body and header parsing. Initially, I wasn’t going to include support for anything but GET, but SwiftNIO made it surprisingly trivial to include all of them.

Supporting body parsing was a bit trickier, but also wasn’t all that difficult once I figured out how SwiftNIO actually handles requests. It doesn’t actually ever give you a complete HTTP request in one go. Instead, it streams it piece by piece. These can be identified via enums like this: .head  →  .body  →  .body  →  ...  →  .end. As you can see though, the .body case can arrive multiple times for large payloads since SwiftNIO breaks it down into chunks. That made it a bit trickier to solve, but also not terrible. I just had to accumulate the chunks and then put them together at the end of the request:

private var bodyBuffer: ByteBuffer?

// ...

case .body(var buffer):
    // Accumulate body chunks. For small bodies this will be a single call;
    // for larger bodies NIO may deliver multiple chunks.
    if bodyBuffer == nil {
        bodyBuffer = buffer
    } else {
        // Append the new chunk to the existing buffer.
        bodyBuffer!.writeBuffer(&buffer)
    }

case .end:
    if var buf = bodyBuffer, let bytes = buf.readBytes(length: buf.readableBytes) {
        body = Data(bytes)   // ByteBuffer → [UInt8] → Data
    } else {
        body = Data()        // no body (GET, HEAD, etc.)
    }

The code above is heavily cherry-picked. You can see the whole context on GitHub.

Routing

Of course, no web application would be worth anything if there wasn’t some form of routing. To accomplish this, I created a Router class that is responsible for registering all routes with their respective methods and handler functions, parsing the incoming URLs and calling said handler functions. The latter always return an HTTPResponse object as described above. I figured the best way to do this would be the regex-route (pun intended) which can be seen in the add() function of the Router class:

public func add(_ method: HTTPMethod, _ path: String, _ handler: @escaping Handler) {
    var paramNames: [String] = []

    // Replace each `:paramName` segment with a regex capture group `([^/]+)`,
    // and record the parameter name so we can map captures back to names later.
    let regexString = path.replacing(/:([a-zA-Z0-9_]+)/) { match in
        paramNames.append(String(match.output.1))
        return "([^/]+)"
    }

    guard let regex = try? Regex("^" + regexString + "$") else { return }
    lock.withLock { routes.append(Route(method: method, regex: regex, paramNames: paramNames, handler: handler)) }
} 

Then all you have to do is add your routes and handlers in the main.swift file:

router.add(.GET, "/") { head, _, _, _ in
    let pageHtml = layoutView(title: "Homepage", content: homeView())
    return HTTPResponse(status: .ok, contentType: "text/html", body: pageHtml.description)
}

router.add(.GET, "/hello/:name") { head, params, urlComponents, _ in
    let name = params["name"] ?? "unknown"

    // Extract the optional `?german=true` query parameter.
    let germanParam = urlComponents.queryItems?.first(where: { $0.name == "german" })?.value
    let isGerman = germanParam == "true"

    let title = isGerman ? "Hallo \(name)!" : "Hello \(name)!"
    let pageHtml = layoutView(title: title, content: helloView(name: name, isGerman: isGerman), name: name)

    return HTTPResponse(status: .ok, contentType: "text/html", body: pageHtml.description)
}

You might have noticed in the example that parameterization of URLs is also supported. This includes both inline parameters (i.e. /hello/:name) as well as query parameters (i.e. /hello/:name?german=true). Inline parameters are parsed using the regex above and query parameters are extracted from the urlComponents variable injected into the handler function.

You can find the entire Router class on GitHub.

Basic Templating with XSS Safety

There were a number of approaches I considered when it came to adding templating to the project. My first instinct was, of course, to reach for one of the off-the-shelf solutions such as Vapor’s Leaf, but I wanted to avoid extra dependencies and keep it as simple as possible. As such, I just decided on simple string interpolation where each template is a standard Swift function that returns a string of HTML. That may not be the best approach for a large web application with a complex frontend, but works perfectly well for this experiment.

Fortunately, that also means it’s fairly straightforward. There is a layout view that provides the structure for the site as well as a specific view for each route that should return HTML.

The layout view:

func layoutView(title: String, content: HTML, name: String = "") -> HTML {
    return """
    <!DOCTYPE html>
    <html>
        <head><title>\(title)</title></head>
        <link rel="stylesheet" href="/css/main.css">
        <script src="/js/scripts.js"></script>
        <body>
            <nav>
                <a href="/">Home</a>
            </nav>
            <main>\(content)</main>
            <p>Input your name: <input type="text" id="name" value="\(name)"></p>
            <div class="buttons">
                <button type="button" id="sayHelloButton">Say Hello!</button>
                <button type="button" id="sayHelloGermanButton">Say Hello in German!</button>
            </div>
        </body>
    </html>
    """
}

The /hello/:name route’s view:

func helloView(name: String, isGerman: Bool = false) -> HTML {
    let greeting = isGerman ? "Hallo \(name)!" : "Hello \(name)!"
    return "<h1>\(greeting)</h1>"
}

The layout and route-specific views get put together in each route’s handler. If you look back at the previous examples of adding routes, you’ll see the layoutView() function takes a content parameter. This is where the route-specific view is injected into the layout.

You might have also noticed the mysterious HTML type. This doesn’t come from SwiftNIO, but instead is a custom interpolation struct that provides XSS (cross-site scripting) safety. While a little excessive for this particular basic project, I happened to find out while making it that Swift supports such a thing and decided to give it a shot. I won’t go into detail about it here, but you can view the commented struct on GitHub.

Static Content

If you have templates, you have to have static content as well. What modern website doesn’t have CSS and JavaScript? Even my basic example does, but more as a proof of concept than anything else.

Static files are located in the Public folder at the root of the project. The application will automatically figure out the path to it relative to the executable and then return the requested file via a wildcard GET route added to the router after all of the user-defined routes have been added. If no file is found, a 404 “not found” error is returned.

This was surprisingly one of the trickier parts of the whole experiment to figure out, but once I had it, it wasn’t terrible to implement. Essentially, I had to read the static file as a Swift Data object and pass it along with the mimeType to the HTTPResponse to be handled in the same way it handles a standard string response:

guard let data = try? Data(contentsOf: URL(fileURLWithPath: fullPath)) else {
    return HTTPResponse(status: .notFound, body: "Not Found")
}

let ext = (fullPath as NSString).pathExtension
return HTTPResponse(status: .ok, contentType: mimeType(for: ext), data: data)

There is a little bit of magic that also happens in there in the form of path sanitization so that a user can’t use standard Unix/Linux paths like “/..” to reach other files in the OS:

let sanitized = filePath
    .components(separatedBy: "/")
    .filter { !$0.isEmpty && $0 != ".." }
    .joined(separator: "/")

guard !sanitized.isEmpty else {
    return HTTPResponse(status: .notFound, body: "Not Found")
}

You can see the wildcard route and how the files are read on GitHub.

Only HTTP/1.1 is Supported

One notable limitation of the web application in its current form is that it only supports HTTP/1.1. SwiftNIO also has additional Apple-developed libraries that extend it to support HTTP/2 (swift-nio-http2) and even an experimental library to allow it to support HTTP/3 (swift-nio-http3), but I figured sticking with HTTP/1.1 would be good enough for this small experiment.

What Else It Could Have Done

I enjoyed creating this project enough that it was hard to keep it simple. I could have just kept tacking on feature after feature until it did everything a standard web application can do, but I was (fairly) disciplined and kept it basic. These are some of the ways I thought it might be nice to expand it and, perhaps, I will fire up a new repo one day to do so.

As mentioned above, the server currently only supports HTTP/1.1. It would probably be fairly trivial to add at least support for HTTP/2 with swift-nio-http2, but I haven’t attempted that yet.

Also, a proper templating engine might be useful for a real application. I’ve worked with Vapor’s Leaf, but have also dabbled with Stencil which is another template language for Swift. Either one would be a good choice.

Then, of course, rare is the web app that doesn’t have a database behind it. The easiest solution would be to statically link to the operating system’s C SQLite library and call it using raw queries directly in your Swift code. For other databases such as MySQL and PostgreSQL, the makers of Vapor also provide NIO-libraries: MySQLNIO and PostgresNIO. If you would prefer a full-fledged ORM, then Vapor’s Fluent is probably the way to go.

However, if you’ve already got Leaf and Fluent, then you might as well save yourself the trouble of everything else and just use Vapor itself which, as mentioned above, is also based on SwiftNIO.

Conclusion

So, would I ever use this on an actual production system? Honestly, probably not. For the vast majority of projects, a complete web framework like Vapor makes a lot more sense because it makes development so much faster and easier with much less code to maintain yourself. The performance penalty is so negligible that you probably wouldn’t be able to measure the difference in anything but nanoseconds.

However, if you are serving requests at the same scale as Apple, then every nanosecond counts and you might want to consider going with raw SwiftNIO. The margin for error is wide, but the ability to finely tweak performance is vast. Since no project I have ever worked on — professionally or personally — has ever even come close to receiving the amount of requests an Apple service does, I honestly would always go with a framework like Vapor.

That said, I did enjoy the experiment and it was interesting to piece together how it works behind the scenes. I could have easily just kept bolting on more features until I had my own mini framework, but I decided to just keep it simple and focus on the core of the application. After all, the point of the experiment was to figure out how it worked and if I could even make it work at all. Fortunately, I was successful in both endeavors.

And just as a small aside: The README file in the GitHub repository has a few more technical details than I’ve included here. There are also instructions on how to get it to run and build on Mac (with and without Xcode) as well as Linux. It will only work on Windows with WSL since SwiftNIO relies on POSIX calls for its thread-pooling.

Links

• GitHub repository with my experiment
• SwiftNIO
• Vapor

Changes include:

• Added a new menu item to reset the selected text’s or an entire note’s formatting. You can find it under Format -> Reset Formatting
• Fixed a bug where using cmd+option+shift+v didn’t paste anything

You can download ScratchBook for free on the Mac App Store.

Two days ago, I relaunched a website that I first set up in 2021 called The Old West. It not only features a new design, but also a lot of new content. The purpose of the website is to consolidate Wikipedia articles about the old American west into one spot, making it easy to browse them. I import the articles into my database using Wikipedia’s API and display them under their Creative Commons Attribution-ShareAlike License. The articles are defined in config files and I wrote a script that imports and updates them. The script is run via a cronjob once a week to keep the articles up to date with the latest changes from Wikipedia.

A complete rewrite was long overdue as I could no longer build the old website. At the time, I was heavily into React and Next.js which is the technology I chose to power the website. Unfortunately, I also used the Material UI component library which became the main liability. Material UI released a major new update at some point and I really didn’t like their new approach to CSS handling. Not only did I dislike it, it would have basically required a major rewrite of the website and all of its CSS. Therefore, I decided not to update. Of course, as time went on, the old version became incompatible with newer versions of React and Next.js and I got stuck with Next.js 12 which is several versions behind.

That by itself isn’t as much of an issue, however, Node itself also continued to move on and eventually, Next.js 12 no longer supported the version of Node I had installed locally. I’m aware I could have used nvm combined with a specific Node version defined in a .nvmrc file at the root of the project, but that is more than I was willing to do to support the old, increasingly fragile technology powering the project. At that point, I had also become very disillusioned by React, Next.js and the general highly volatile Node ecosystem with its well-known dependency churn and increasing number of supply chain attacks.

So, when I decided to finally completely rewrite The Old West, I chose to go in a fully different direction with the technology. I chose vanilla PHP.

With so many shiny new programming languages and web frameworks on offer, why did I choose PHP? Well, I didn’t want dependencies. I wanted to write the code once, deploy it and be able to forget about it for years at a time even if it meant a little bit more work up front. My other requirement was that I still wanted to be able to update it at anytime without having to first spend hours trying to sort out dependency or runtime version incompatibilities just to get it to build again.

Vanilla PHP is not only perfect for that, but really the only feasible way to do it. Combined with Apache, Linux and MariaDB (the truly classic LAMP stack), it is practically bulletproof. No supply chain attacks, no version incompatibilities, no dependency update hell — nothing but stability and peace of mind.

PHP is incredibly backwards-compatible which means I can safely update the version on my server using my package manager and don’t have to worry about too many, if any updates to my code. The only “dependencies” I rely on are official PHP extensions such as PDO for database connectivity which I’m not concerned about because they are maintained and updated with PHP itself.

I wrote my own autoloader for namespaces, a tiny, fully custom router module, as well as a very lightweight ORM layer with an inheritable Model class, a QueryBuilder class, and a migration class that processes raw .sql files for migrations. Templating is handled with pure PHP. There is hardly any JavaScript on the website and I use pure CSS without anything like SCSS or Less. I do use the Bootstrap CSS classes for responsiveness, but I copied the CSS files into my project by hand which means they will work forever unless I feel like updating them.

That’s really all there is to it. The website is lightweight, lightning-fast, and entirely customized to my specific needs. It will run stably for as long as the server runs and even if the server craps out at some point, moving the project to another server requires minimal effort.

Vanilla PHP may not be glamorous, but it has been the stablest way to create a website for decades and, since it still powers the majority of the web, I think we can safely say it will remain that way for decades to come.

If you’d like to see the new design, you can find The Old West here: www.the-old-west.com.

But once I found out that cyberport.de had MacBooks on sale (I’m not sponsored), I decided that I couldn’t wait anymore and bought one. The basic specs are:

• M5 chip
• 32 GB of RAM
• 2 TB SSD
• 14″ display

I got that for €2500 which is about €500 less than directly from Apple and essentially made the 2 TB SSD upgrade free. I also could have gone with a 16″ instead, but I decided I’d prefer a larger SSD. Most of the time I use it plugged into an external monitor anyway and when I’m traveling with it, I like the smaller, lighter form factor.

I did play around with the idea of getting a 15″ MacBook Air instead since the specs I care most about are the same, but in the end I decided the fans might be nice to have even though I’ll probably only rarely, if ever, need them.

Here are a few pictures:

Changes include:

• Added support for macOS 14 (Sonoma) and macOS 15 (Sequoia)
• Fixed an issue with truncated text on the import sheet

You can download ScratchBook for free on the Mac App Store.

Ever since I experimented with the Swift server-side framework Vapor last year, I’ve been interested in actually seeing it in operation in the wild. I know there have been a number of companies, including Apple itself, that have started using it for their server-side applications, but it’s nice to see some concrete examples of it.

I’ve been following the official Swift blog for a while now, but I just recently discovered two posts about companies that are using Swift and Vapor at large scale to run their server-side applications.

The first of which is the syncing service for the very popular Mac/iOS productivity application, Things. I’ve played around with Things before in the past, but it’s too expensive for my basic needs, so I don’t use it. Nonetheless, it is still a very popular application and the fact that Swift and Vapor power its syncing backend is great news for those who are questioning the framework’s reliability or scalability.

You can read more about Things using Swift and Vapor here. The post also includes more information about their infrastructure in general.

The second usage I found recently was for the TelemetryDeck analytics service. Unlike Things, I had never heard of them, so I can’t say a whole lot about them, but they apparently have a massive amount of traffic that Swift and Vapor handle flawlessly.

You can read about it here.

Of course, something to keep in mind is that both of these posts are on the official Swift blog which is unlikely to report on any negative experiences that companies have had with server-side Swift. However, I still find it great that companies are having success with using Swift and Vapor in production environments with large traffic loads.

If you know of any other examples of server-side Swift in the wild, let me know. I’d love to read about it — good or bad!

A couple of months ago, I took my 11″ iPad Air M2 with me to the city of Regensburg to try working with it as a laptop replacement. Unfortunately, the tiny 11″ screen and the non-standard, smaller keyboard made it less than a stellar experience. However, I thought I could mitigate those problems while taking advantage of iPadOS 26’s new windowing feature by using a normal keyboard, mouse and a large external screen — essentially, turning it into a desktop replacement.

Equipment

My equipment list for this experiment isn’t as exciting as it was for the laptop replacement experiment because I just used my usual desktop accessories:

• Logitech MX Keys keyboard
• Apple mouse
• LG widescreen monitor that supports USB-C

Normally, I use a Logitech MX Master 3S mouse instead of the Apple mouse, but I’ve already used up all three device connections that it supports, so I had dig out my old Apple mouse. Otherwise, the most important part was the monitor with USB-C support. With that, I could just plug my iPad in and it not only activated external display mode, but importantly, it also charged.

My Experience

I know that the iPad is limited as to what it is capable of doing primarily due to the limitations of iPadOS. Development is nearly impossible on it which already means it’s not a viable desktop replacement for me full-time. However, I also write a lot, so I thought the best way to test it was to do some writing.

On my Mac, I use Pages anyway and most of it gets saved to iCloud Drive. As such, writing in Pages on the iPad means there isn’t really much of a change of workflow. I already knew that from when I tried using my iPad as a laptop replacement, but what I didn’t count on what the severe limitations I ran into when using the mouse and keyboard.

It turns out, unsurprisingly, that iPad apps are not optimized for them. That didn’t surprise me at all, but what did surprise me was just how limited it would be. Even first party-applications like Pages were severely restricted. For example, there is no way to correct a misspelled word with the mouse and keyboard. You have to use the touch screen to tap on the word that is underlined in red and then you get the popup menu with the spelling suggestions. There is absolutely not way to replicate that functionality with the mouse and keyboard which means I had to drag Pages from my big screen down to the iPad’s touch screen to use it — not a good experience at all.

Also, for some reason, forward delete doesn’t seem to work at all on the iPad. A full-size Mac keyboard has its own forward delete key and on the smaller Mac keyboards (such as on the MacBooks), you use fn+delete. Neither of those worked on the iPad at all which made trying to edit text much more tedious.

Even worse, though, were third-party apps. For example, I tried watching a YouTube video using the YouTube app. I could click on a video, but couldn’t exit it. There was literally no way to leave the video or access buttons like “Save” or “Like”. It just didn’t work at all. Again, I had to drag the app down to my iPad’s screen and use the touch interface.

The worst issue I kept encountering, though, was that the iPad would regularly crash entirely. As in, both screens would go black and there would be a loading spinner on the iPad’s screen that lasted for several seconds before I could use it again… except all of the apps I had open were closed. That happened with startling frequency even with only three of my most-used apps open: Mail, Safari and Pages. So much for windowed multitasking.

After this happened four times in a half an hour, I gave up on the experiment and went back to my Mac.

Conclusion

Needless to say, I won’t be using my iPad as a desktop or laptop replacement anytime soon. After the experiment with trying to use the iPad as a laptop replacement, I went into this one less than optimistic. Unfortunately, my pessimism was confirmed by the experience.

I find it really disappointing that, despite the improvements Apple made to desktop mode in iPadOS 26, it still doesn’t even come close to being a viable, reliable option. Frankly, my iPad with its M2 processor is several times more powerful than my old Intel MacBook Pro, but the software cripples it to the point of irrelevance.

The idea of having a truly all-in-one, portable device is extremely appealing to me. I love using my iPad to read my RSS feeds, eBooks, articles online, magazines, etc which is what I primarily use it for. While I have an Apple Pencil, I rarely use it to take notes or draw anything. Unfortunately, unless Apple makes some major changes to iPadOS, it’s just going to remain a glorified electronic reader for me.