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.

As some of you may have noticed, my websites keep going down and are not reachable for hours at a time. I’ve been having some stability issues with my server and, of course, it always happens over night German time which is why it takes me hours to get to it. I only see it when I get up in the morning.

Ubuntu has been killing the Apache and MariaDB services due to out-of-memory issues despite my monitoring reporting RAM usage only reaching 20% of the server’s full capacity. However, I have discovered that there is a massive spike in traffic during that time and I suspect it’s due to bots. I still need to confirm my theory though.

In the meantime, I’ve reconfigured the Apache and MariaDB services to automatically restart when they die. That should at least solve the immediate problem of my websites being unreachable for hours at a time. I could have sworn that I’d already set them to automatically restart, but apparently not. Oh well.

I’m excited to announce that ScratchBook is now available as a free download on the Mac App Store!

If you are interested in downloading it, you can visit its page on the Mac App Store.

I’m especially excited about this release because it is the first time I’ve published anything on any app store and because it’s a much needed update to the original ScratchPad whose Objective C codebase dates back to Mac OS X Tiger.