CodeMade Blog

It's getting hard to justify app stores

2026-04-02T00:00:00Z

Google's announcement of the new developer verification process for android developers and especially the incredibly cumbersome "advanced flow" required to sideload unverified apps left a bad taste in my mouth.

Here's why.

App stores are yucky

When was the last time you thought you'd like to open the app store and see what's new? Me neither! The only reason to do so is because you already know what you're looking for, and even then you'll spend some quality time trying to find it among the sea of adware and sketchy knockoffs: because of the economics of developing apps, most apps are filled with ads, trackers, and upsells.

It's a race to the bottom, and the only way to win is to enshittify your app as much as possible.

And then AI coding came along

I built two small apps during the past weekend that made me reconsider the whole idea of needing app stores.

Hacker news reader

My favourite hacker news reader app, Materialistic hasn't been updated in ~ 3 years. It's so old that the Play Store doesn't even have it anymore.

I read HN in a specific way: I want to see the top posts of the day, sorted by number of comments, and I want to read the comments. Sometimes I'll navigate to the actual article. That's it.

I asked Claude to build me a very simple HN reader that does just that, and in a few minutes it materialized on my screen.

It's a PWA so it doesn't even need to be sideloaded, I just have to open the URL and add it to my home screen. It has no ads, no trackers, and it does exactly what I want it to do. It caches requests so it works offline, and it's blazing fast on cellular networks.

It's hosted at https://hnws.app if you want to check it out.

(I won't know, because I didn't add any analytics to it!)

Background switcher

There's another app that I've been using for years, Muzei. It's by far the best wallpaper switcher app. The killer feature is that it will blur and dim the wallpaper so you can see the icons clearly, and you can reveal the unblurred version with a double tap.

The only problem I have with it is that most of my wallpapers are landscape, and so they are always centered and cropped, which means that the most interesting part of the image is sometimes cut off.

Again, my use for it is very specific: I only use local images, and I want the app to automatically switch to the next image in the folder every day. That's it.

Claude Code built me LocalZei, a full fat Android app that does just that, and again, it has no ads, no trackers, and it does exactly what I want it to do.

It took an evening.

An evening!! While I was watching TV and eating dinner!! Yes it only does a subset of what Muzei does, but it's my subset. And it can crop to the most interesting part of the image 😄

The age of personal apps is here

The friction of building personal apps has always been so high that as users we accepted the ads, the trackers, the dark patterns, and the constant upsells.

The friction is just not there anymore. You can build a personal app that has the exact subset of features you want, that is clean, fast, and respects your privacy, in a matter of hours.

But the enshittifiers are fighting back

And this is exactly what Google's new verification process is designed to prevent: they are desperately trying to protect their cash cow, in the name of "security" and "user experience".

Just as we're so close to our phones being the personal computing devices we always wanted.

Rumors of the death of SaaS have been greatly exaggerated

2026-02-18T00:00:00Z

There's a meme going around in tech and finance circles that goes something like this:

Woah I just got Claude Code to build me a custom (insert niche use case here) that works exactly the way I want it! I won't need to pay for (insert SaaS product here)'s monthly fees ever again! The end of SaaS is near!

Here's why I think this is an extrapolation that makes no sense, especially when thinking of B2B SaaS.

I'm going to take the weakest position possible here: vibe coding is not going to replace tasking and planning software like Jira, Asana, Linear etc. I'm choosing this specific niche because on paper it's the most AI-disruptable: it's software that's conceptually simple, there are a million TODO list implementations freely sitting on github that have been used as training, and they often need to be customized to a crazy degree to fit the needs of different teams and projects.

I am confident the points below can apply even more strongly to more complex and specific SaaS products (especially in highly regulated industries like finance, healthcare, legal etc).

Nobody wants to maintain your crappy version of Trello

You vibe coded a replacement for Trello so that your company can drop the $10/user/month subscription. Congrats! Let's say you have 100 users (I like round numbers). That's a saving of $1000/month, or $12,000/year. Seems great, right?

Except that... how much are you paid? Let's say that you're a software engineer making between $60k and $120k a year. Even if you only spend 10% of your time maintaining this thing, that's between $6,000 and $12,000 a year of your time spent on it. And remember, that's time that you're not spending making money for the company. I won't even go into the token costs of running an AI agent, as they can range from insignificant to very expensive depending on the complexity of the software you're building.

There's also the "lottery" factor: let's say you're offered an exciting position at a new company. Who's going to maintain the Trello replacement? Your company now has to find someone else to do it, or contract an external agency, or... switch back to Trello and pay the subscription fees again.

Free alternatives already exist

If your company wanted to replace Trello with a self-hosted alternative, there are already plenty of free and open source options available. These products are already maintained by a community of volunteers, and you can even contribute to them if you want to add features or fix bugs.

So then why don't all companies just switch to these free alternatives? Because they don't want to. They don't want to spend time and resources on maintaining software that is not core to their business. Any time you spend configuring the EC2 instance that runs your self-hosted Trello is time that you're not spending on the actual product you're selling to customers. And of course, if something breaks, you're on the hook for fixing it.

Software is a liability

We're assuming that your version of Trello is actually working and doesn't have any security issues. The worst case scenario would be that your Firebase database is actually freely available to anyone on the Internet, and all your company's data is leaked. And now you're on the hook for that too. Hope you like HR meetings!

Had this been a SaaS product, your company could have done one or all of the following:

Sued the vendor for negligence
Asked for compensation
Switched to a different vendor
Ask for a detailed post-mortem and action plan to prevent this from happening again

Having a "throat to choke" is something that companies really like.

SaaS developers can use AI too

This should be obvious, but there's nothing stopping developers at SaaS companies from using AI tools to improve their services. In fact, they're likely encouraged to do so!

Whether AI is a net positive or a net negative for working within large, established codebases is still up for debate, but all successful software becomes "legacy" given enough time - even the shiny new vibecoded competitor.

Some think that the SaaS space will become incredibly crowded with options now that building software is easier than ever. But I expect this will translate into higher expectations for what software should be able to do. In essence, if creating a TODO list app is a one-shot with an LLM, then the expectation for what a task management software should be able to do will be much higher than it is now, and the bar for entry will be raised.

AI coding raises the floor for what is considered a "viable" software as a service

I also expect that some newer, nimbler companies will eventually compete with the established players, but that's long been the story of software: a great example is Linear coming in and disrupting the Jira monolith by focussing on a better user experience, with what I assume is a tiny fraction of the team at Atlassian.

Counterpoint: SaaS companies are overvalued on the stock market

This is where the real crux of the issue lies: the stock market has been overvaluing software companies for years now. Given a rational market, the price of a stock should reflect the expected future cash flows of the company. But with software companies, the bet is often that they'll become unicorns, take over a whole market category, put the competition out of business, and raise prices (AKA the enshittification playbook).

The recent hype about AI being the "next big thing" means that funds are being reallocated away from regular SaaS and into AI companies. This also means that investors need to push the message that "AI is going to kill SaaS" in order to justify their increasingly outsized bets.

In that sense yes, AI is going to kill SaaS. Unprofitable companies that rely on a constant stream of funding are going to have a bad time, and some of them will go out of business. But for companies that are providing actual value to their customers, while staying profitable, I don't see any reason why they wouldn't be able to continue doing so, and even thrive in the new AI-powered world.

TL;DR

AI isn't going to kill SaaS just yet. But it is going to make bad SaaS harder to justify.

Building for an audience of one: starting and finishing side projects with AI

2026-02-16T00:00:00Z

⚡️ FastTab solves a very specific problem: the "Gallery" view of the built-in task switcher in the Plasma desktop environment is slightly too slow for my liking on X11. Sometimes it will take up to a second to open, which is way too long for a feature that I use constantly.

FastTab is a custom task switcher that is built in Zig, uses OpenGL for rendering, and is designed to run as a daemon so that it can respond to keyboard shortcuts instantly.

I would have never built this without AI

It's very likely that this is a problem with an audience of one: users who are still on X11, like the gallery switcher, have many windows open, and care about performance.

In the past I would have probably just accepted the performance tradeoff and moved on, but we're living in the future now! Why not just ask Claude to build it for me? As long as the vision is good, and the code doesn't suck, it should be good enough, right?

And so I did: with zero experience with Zig or X11 internals, I got a working prototype in a few days, and then iterated on it until I was happy with the results.

AI tools enable you to build things that you would have never built otherwise. When you just want "the thing" rather than the process of building the thing, coding agents can be a game changer.

It all starts with a conversation

I was just irritated enough by the slight delay of the task switcher that I asked Claude for tips on how to make it faster. Sadly, there was no quick fix, I had already zeroed out all the animations and delays in the configuration, and the only alternative would have been to switch to the "list" or "icons-only" view, which I just don't like (looking at a window preview is much more efficient than reading titles for my brain).

Then I just asked: "How difficult would it be to build a task switcher that is specifically for X11 and KDE?" and the conversation pivoted into planning. We went through a few iterations where I steered Claude towards a design that seemed promising.

The result was a very detailed specification of the application, with a clear vision of how it should work and look like, and a plan for how to implement it, split in several milestones so that I could start with a simple prototype and then evolve it into a full-fledged application.

Start with a conversation, and explore the problem space with the LLM. The idea here is to gather options and ideas. Once you have a clear vision of what you want to build, ask for a detailed specification. Iterate on the spec until you understand it fully and are happy with it.

Then break down the spec in a set of milestones.

A note on writing good specs: Claude especially will try to shove as many code snippets as possible into the spec. This is not only a waste of tokens, but it will also make it harder for you (and the coding agent!) to implement the spec. Pseudocode is fine, and at this stage is actually preferable, since it allows you to focus on the overall architecture and design of the application, without getting bogged down in the details of the implementation.

Mermaid diagrams are also your friend here, they not only look nicer, but fit in fewer tokens than ASCII diagrams.

With a solid spec in hand, I was ready to start building. The next question was how to let an AI agent loose on my filesystem without risking my machine.

The perfect balance between safe and YOLO

Every developer should know that git is your friend. You can build incrementally, commit when you have something working, and if the LLM messes up, you can always revert to the last working state.

I use the staging area a lot when I have something that is kinda working but not quite there yet, so I can decide whether the next iteration is good enough to make it into a commit, it's an improvement that gets staged, or it's garbage to be reverted.

Checking the git diff before committing is also a great way to understand what the LLM is doing, and to catch any potential mistakes before they become a problem.

Running Claude Code and approving... each... individual... command... is... exhausting. But at the same time, running claude --dangerously-skip-permissions is gambling with your filesystem.

The solution is 🐋 containers! I used a heavily customized version of contai, which is a handy wrapper around Docker that allows you to easily spin up a locked down container that has access to your code folder only. This way if the LLM accidentally runs rm -rf / or something like that, it will only delete the container's filesystem, which is ephemeral, and not your actual files. (should it delete the code, you are using git, remember?)

I had to tell the LLM that it's running inside a container, and it doesn't have an X11 display or the ability to install system packages, otherwise it would spend a lot of tokens trying to do the impossible

It worked so well that all my new projects are now developed in a dev container that borrows heavily from the contai configuration.

Trying different tools, and running out of tokens

I initially started working on FastTab with OpenCode and oh-my-opencode. I really enjoyed OpenCode in other projects and, while skeptical, I hoped that oh-my-opencode would be the powerup that would make the whole experience 100 times better.

In practice, I found that the multi-agent system was exceptional at consuming tokens, while producing the same results that I could have achieved with a single agent. At around the same time, Anthropic decided that using the Pro plan on OpenCode was a breach of their TOS, so I had to switch back to Claude Code.

The token limit however remained a real problem: I assume that writing Zig is more taxing to LLMs than writing Python or JavaScript, probably because of the lower level nature of the language and the fact that less training data is available for it. I routinely ran out of juice, and had to either wait for the reset, or switch to the Gemini CLI. Alternating between the two was a bit of a hassle, but overall both Opus 4.5 and Gemini 3 were able to get the job done.

Sidenote: I wonder what's going to happen when the crazy money runs out and Anthropic, OpenAI & co have to start charging for more than it costs them to run the models. Hopefully by then the open source models will have caught up?

But regardless of which model or tool I was using, the pattern was always the same: the LLM could get me 80% of the way there, and the last 20% was on me.

You still need to know how to code

In the case of FastTab, the first version that I got from the multi-agent system was actually working, which was way better than what I could have built in a couple of hours in a language I didn't know, using libraries I wasn't familiar with.

It was also a single 1700 lines long file with most of the code in the main function, no tests, lots of code duplication, and a lot of extra comments and logging. Refactoring it into a more modular and maintainable state was necessary not only so I could understand it, but so that the LLM could iterate on it without introducing new bugs or breaking existing functionality.

There's a reason why many developers call AI assisted coding "a slot machine". You write your prompt, pull the lever, and get a surprise. Sometimes it's a fully working thing, sometimes it's 50% there, and sometimes it's completely off the mark. Better prompts will increase the chances of getting a good result, but there's always an element of randomness that you have to be comfortable with.

Asking the right questions also requires coding knowledge. For example, in an early iteration we were shuffling image bytes from BGRA to RGBA. The code worked, but the performance was not great. I asked Claude to use SIMD instructions and the speedup was significant, enough so that we could capture the content of a youtube window playing a video at ~10fps without incinerating my CPU. But I had to know that SIMD was a thing, and that it could be used in this context.

In the end we ended up scrapping much of that code in favour of "borrowing" the actual texture data from X11, which is much faster, but the point stands: you need to know what questions to ask in order to get the best results.

The age of finishing side projects is here?

I think I'm finally turning the corner from the doom and gloom of "AI will take our jobs." AI-assisted coding is still coding: without the taste and knowledge that come with experience, you'll invariably end up with a half working prototype that breaks in new and exciting ways every time you ask to "pls fix".

For my day job, where the codebase dwarfs any LLM's context window and the stakes are high, getting a coding agent to generate all or even most of the code for a feature is still not something I would subject my users to.

But side projects have different goals: scratch an itch, maybe learn a thing or two, and get something working before I get bored or realize it's too much effort.

I can spitball with Claude about my problem, get a spec, and have a working prototype in a few hours. If I like it enough, I can spend some time polishing it until it's something I'm happy to share.

The whole process is short enough that I might actually finish the thing, for a change!

How to use Deno's own SQLite module on Alpine Linux

2026-01-18T00:00:00Z

Deno's built-in SQLite module is a fantastic way to integrate a lightweight database into your Deno applications. However, to work its magic, it relies on a native SQLite library that needs to be present in your environment.

If you're running one of Ubuntu, MacOS, or Windows, you're in luck: Deno has you covered with precompiled binaries for these platforms. But if you're using Alpine Linux, things get a bit trickier since Deno doesn't provide a precompiled SQLite library for this distribution.

Try to run a Deno application that uses SQLite on Alpine Linux without any additional setup, and you'll get an error like this:

3.013 Downloading https://github.com/denodrivers/sqlite3/releases/download/0.13.0/libsqlite3.so
4.094 error: Uncaught (in promise) Error: Failed to load SQLite3 Dynamic Library
4.094   throw new Error("Failed to load SQLite3 Dynamic Library", { cause: e });
4.094         ^
4.094     at https://jsr.io/@db/sqlite/0.13.0/src/ffi.ts:642:9
4.094 Caused by: Error: Could not open library: Could not open library: /usr/local/lib/libm.so.6: version `GLIBC_2.38' not found (required by /deno-dir/plug/https/github.com/2d624d1cb94dc52a04dcb942d98592ad72012273e34867346f5dde5d01035183.so)
4.094     at new DynamicLibrary (ext:deno_ffi/00_ffi.js:457:42)
4.094     at Object.dlopen (ext:deno_ffi/00_ffi.js:563:10)
4.094     at dlopen (https://jsr.io/@denosaurs/plug/1.1.0/mod.ts:158:15)
4.094     at eventLoopTick (ext:core/01_core.js:187:7)
4.094     at async https://jsr.io/@db/sqlite/0.13.0/src/ffi.ts:625:7

What this tells us is that Deno attempted to download a precompiled SQLite library that depends on glibc, the GNU C Library. However, Alpine Linux uses musl as its standard C library, which is not compatible with the prebuilt sqlite binary.

Luckily, Deno can use any precompiled SQLite library that matches its expected version. For Alpine Linux, you can leverage the libsqlite3 package available in the Alpine repositories.

You can install it using the apk command:

apk add libsqlite3

This command installs the necessary SQLite library on your Alpine system, however in order for Deno to find and use it, you will need to set the DENO_SQLITE_PATH environment variable to point to the location of the installed library.

You can find the library at /usr/lib/libsqlite3.so.0 after installation. Set the environment variable like this:

export DENO_SQLITE_PATH=/usr/lib/libsqlite3.so.0

That's nice and all but I use Docker?

Easy peasy! Here's a simple Dockerfile that sets up a Deno environment on Alpine Linux with SQLite support:

# Use the official Deno Alpine image as the base
FROM denoland/deno:alpine-2.6.5

# Expose port 8000 for the application
EXPOSE 8000

# Install system SQLite library
RUN apk add --no-cache sqlite-libs

# Set working directory and permissions
WORKDIR /app
RUN mkdir /app/data && chown -R deno:deno /app
USER deno

# Copy deno.json and deno.lock files
COPY deno.* .

# Set the DENO_SQLITE_PATH environment variable to point to the installed SQLite library
ENV DENO_SQLITE_PATH=/usr/lib/libsqlite3.so.0

# Pre-install app dependencies
RUN deno install --frozen=true
# Force Deno to load the SQLite module and download any necessary files, ensuring everything is set up correctly
RUN deno eval "import 'jsr:@db/sqlite';"

# Copy application source code
COPY src/ ./src/
# Install any other dependencies
RUN deno install --entrypoint src/main.ts

# Command to run the application (assumes you have a `prod` task in your deno.json)
CMD ["deno", "run", "prod"]

Wrapping Up

Hope this was helpful to you, random internet stranger! It certainly took me a bit of digging to figure this out, so hopefully this saves you some time! 🙃

Announcing email-webhook

2025-03-22T00:00:00Z

📨

TLDR: I'm excited to announce the launch of email-webhook, a service that transforms emails into API calls. Use it to write email automations, process incoming emails, and build email-based workflows.

What is email-webhook?

As the name suggests, email-webhook is a service for developers that transforms emails into REST requests to your API. It makes integrating an email based workflow into your applications and services a breeze.

As opposed to traditional email polling techniques, email-webhook sends a request to your endpoint as soon as an email is received. This way, you can process emails in real-time, without the need for complex polling logic.

Here's how it works:

Once you're signed up, you'll receive a special web address like you@email-webhook.com. Any time an email is sent there, email-webhook will send a request to your endpoint.

You can specify the request method, custom headers, and even sender-based rules. This way, you can easily integrate email processing into your existing systems.

Why email-webhook?

This started a while ago as I was looking for a way to improve the efficiency of my lovely partner's business, using AI to automate her most time consuming tasks.

One such task was improving her response time to various requests coming from her clients. She was receiving a lot of emails and she was spending a lot of time reading and responding to them. Her biggest issue was the "blank screen" problem: she would open an email, read it, and then spend a lot of time thinking about what to do with it.

I thought that I could help her by building a system that would intelligently propose a draft response based on the content of the email plus some external data sources such as her calendar and her CRM.

One of the first steps was to find a way to process emails as they arrived. As a web developer, I'm used to working with APIs, so I thought: "Why not build an API that receives emails as input?"

Of course, the next step was to find a way to get emails into the API! I wanted to avoid polling, so I thought about using webhooks. I started looking for a service that would allow me to receive emails as webhooks, but I couldn't find anything that suited my needs. Every other option was either too complex, too expensive, or too limited.

So I decided to build my own service: email-webhook.

Looking for feedback

Email-webhook is still in its early stages: it's sleek and functional (IMO), but there's still room for improvement.

This is why I'm offering it for the low low price of FREE while I gather feedback and improve the service.

I don't ever plan for email-webhook to be an expensive service, but I would like to offer a paid tier in the future with some advanced features to help me cover the costs of running it.

On a personal note

I had a lot of fun building email-webhook. After so many years of having random ideas and never acting on them, it feels great to finally have something concrete to show for it.

It was a great chance to learn more about the SMTP protocol, and if you've been following my blog, you will probably guess that I used Deno to build the service 😄.

I'm excited to see how people will use email-webhook. I've already received some great feedback from early users, and I can't wait to see what they'll build with it.

How I deploy my web apps in 2025

2025-03-15T00:00:00Z

The beauty of simplicity has become my north star for hosting web applications. Despite working with complex cloud architectures professionally, I've chosen a straightforward Docker stack for my personal projects. As a solo maintainer, I need something manageable without breaking the bank.

Docker hits that sweet spot between complexity and simplicity, providing enough structure without the overhead of enterprise cloud solutions. My personal projects don't need Kubernetes clusters or managed databases - just reliable, affordable infrastructure.

The Old Ways: Docker Compose for the Basics

flowchart LR
web(Web Request)
subgraph **VPS**
  subgraph docker_compose.yml
    rp[Reverse Proxy]
    codemade_app[codemade.net]
    service_x[Wordpress 1]
    service_y[Postgres]
    service_z[Email forwarder]
  end
end
web -- web --> rp --> codemade_app
rp -->service_x --> service_y 
web -- email --> service_z

Initially, my hosting needs were modest - a mail forwarder and a couple of WordPress sites. For this small collection, a simple docker compose setup was adequate. I'd SSH into my server, run commands, and everything would be up and running with minimal fuss.

This hands-on approach worked perfectly - make a change, connect to the server, pull the latest version, and restart containers. Since updates were infrequent and downtime wasn't critical, this manual method suited my needs. My docker compose file was straightforward, defining just the necessary services with basic volume mounts and simple network configurations.

The only "fancy" element was this website, which I've since moved to 11ty and GitHub Pages.

And then I built a web app

flowchart LR
web(Web Request)
web --> caddy[/Reverse Proxy/]
app
redis
subgraph **VPS**
  caddy
  subgraph Stats Stack
    app[Stats App]
    redis[(Stats DB)]
  end
end
caddy -.-> app
app <-.-> redis

Recently, I built a web application that required a more robust solution. It was time to graduate from docker compose to something more sophisticated.

Docker Swarm was the perfect choice as a step up from docker compose without going full Kubernetes-level complexity.

I first heard about this approach from the DreamsOfCode YouTube channel, where they called it docker stack. It's technically Docker Swarm with one node, offering a pragmatic middle ground between my simple setup and complex orchestration tools.

The stack deployment files look almost identical to docker compose files, with just a few additional orchestration-specific options. I took my existing compose file, added deployment constraints and update policies, and it was ready - no steep learning curve required.

I host it on a single but capable VPS on DigitalOcean, which is more than enough for my needs.

The Automated Pipeline

Here is my current workflow:

Push code changes to GitHub
GitHub Actions builds a container image and publishes it to GitHub Container Registry
A deployment action (shockhs/docker-stack-deploy@v1.2) automatically updates my Swarm stack
The new version rolls out with zero downtime

You can take a look at a simplified version of my GitHub Actions workflow if you're curious.

Handling SSL with Caddy

For SSL and routing, I use the excellent Caddy as a reverse proxy. It automatically handles certificate generation and renewal from Let's Encrypt, which is a huge time-saver.

Caddy runs as a separate standalone container outside the Swarm cluster. This was a deliberate architectural decision - running the reverse proxy inside the Swarm would mean losing the originating IP addresses of incoming requests due to how networking works in Swarm mode.

By keeping Caddy separate, I maintain visibility of client IPs for proper logging and security monitoring. It also means my reverse proxy isn't tied to the lifecycle of my applications. It gets its own repo, and its own deployment pipeline.

The Results

This setup strikes the perfect balance:

Automated: No manual SSH sessions for routine deployments
Reliable: Rolling updates ensure zero-downtime deployments
Maintainable: Everything is defined in code and version controlled
Affordable: More cost-effective than equivalent managed cloud services

And then there were more

flowchart LR
web(Web Request)
web --> caddy[/Reverse Proxy/]
app
redis
subgraph **VPS**
  caddy
  subgraph Stats Stack
    app[Stats App]
    redis[(Stats DB)]
  end
  subgraph Games Stack
    gapp[Games App]
    gdb[(Games DB)]
  end
end
caddy -.-> app
app <-.-> redis
caddy -.-> gapp
gapp <-.-> gdb

Docker Swarm excels at scaling to multiple applications. Adding a new web app was straightforward - I created a new stack definition file and deployed it to the same swarm.

This provides independent deployment lifecycles for each application. I can update, restart, or delete one app without affecting others. Each stack gets its own isolated network by default, though they can communicate with each other if needed through overlay networks.

Looking forward

flowchart LR
web(Web Request)
web --> caddy[/Reverse Proxy/]
subgraph VPS4
  subgraph Stats Node / 3
    app4[Stats App]
    redis4[(Stats DB)]
  end
end
subgraph VPS3
  subgraph Stats Node / 2
    app3[Stats App]
    redis3[(Stats DB)]
  end
end
subgraph VPS2
  subgraph Stats Node / 1
    app2[Stats App]
    app21[Stats App]
    app22[Stats App]
    redis2[(Stats DB)]
  end
end
subgraph **VPS 1**
  caddy --> other[other serivces]
end
caddy -.-> app2
app2 -.-> redis2
app21 -.-> redis2
app22 -.-> redis2
caddy -.-> app3
app3 -.-> redis3
caddy -.-> app4
app4 -.-> redis4
style other stroke-dasharray: 5, 5;
style VPS2 fill:#fff4,stroke-dasharray: 5, 5;
style VPS3 fill:#fff4,stroke-dasharray: 5, 5;
style VPS4 fill:#fff4,stroke-dasharray: 5, 5;

Should one of my services become a runaway success, I can move it to its own VPS and scale independently, either by increasing VPS size or adding replicas to the swarm stack. For further growth, adding more VPSs to the same swarm would be the next step.

But that's a problem for another day! 😎

Running parameterized tests in Deno

2025-03-09T00:00:00Z

When writing tests, it's common to want to run the same test with different inputs. This is called parameterized testing, and it's a great way to ensure that your code behaves correctly under different conditions.

This is usually done by writing a single test function that takes parameters, and then calling that function with different inputs. Here is an example in C# using NUnit:

[TestCase(1, 2, 3)]
[TestCase(2, 3, 5)]
[TestCase(3, 4, 7)]
public void TestAdd(int a, int b, int expected)
{
    var result = a + b;
    Assert.AreEqual(expected, result);
}

Testing in Deno

In Deno, we can take advantage of the integrated testing library by using Deno.test() to define our tests. We can further split our tests into separate steps, like so:

Deno.test("When activating the flux capacitor", (t) => {
  const capacitor = activateFluxCapacitor();
  
  t.step("It should generate 1.21 gigawatts of power", () => {
    const power = capacitor.generatePower();
    t.assertEquals(power, 1.21);
  });

  t.step("It should travel through time", () => {
    const time = capacitor.travelThroughTime();
    t.assertEquals(time, "1985");
  });
});

Sometimes however we want to test a function with multiple inputs. An easy way to do so would be to iterate over an array of inputs and call the test function for each input. This can be a bit cumbersome, especially if we have a lot of inputs:

Deno.test("TestAdd", () => {
  const testCases = [
    { a: 1, b: 2, expected: 3 },
    { a: 2, b: 3, expected: 5 },
    { a: 3, b: 4, expected: 7 },
  ];

  for (const input of testCases) {
    const { a, b, expected } = input;
    const result = a + b;
    assertEquals(result, expected);
  }
});

A disadvantage of this approach is that if any of the test cases fail, the test will stop running and we won't know the results of the remaining test cases. The test runner will also simply mark the whole test as failed, without providing any information about which test case failed!

How to run parameterized tests in Deno

After searching online for a bit and finding nothing helpful, I decided to take a look at how Deno's developers write tests. A quick github search took me to the tests for Deno's serve function. Here we can see that they use a helper function to generate multiple test cases.

The trick is that they call Deno.test() inside the helper function!

We can adapt this trick in our tests like so:

function testAdd(a, b, expected) {
  Deno.test(`TestAdd(${a}, ${b})`, () => {
    const result = a + b;
    assertEquals(result, expected);
  });
}

testAdd(1, 2, 3);
testAdd(2, 3, 5);
testAdd(3, 4, 7);

Another approach is to use an array and a for loop:

const testCases = [
  { a: 1, b: 2, expected: 3 },
  { a: 2, b: 3, expected: 5 },
  { a: 3, b: 4, expected: 7 },
];

for(const {a, b, expected} of testCases) {
  Deno.test(`TestAdd(${a}, ${b})`, () => {
    const result = a + b;
    assertEquals(result, expected);
  });
}

This way, if any of the test cases fail, the test runner will still run the remaining test cases and provide information about which test case failed.

Additionally, by specifying unique test names in each Deno.test() call, we can easily identify which test case failed!

A note on the Visual Studio Code Deno extension

At the time of writing, you won't be able to run individual tests in Visual Studio Code from the test file itself (ie you won't see a "Run Test" button next to each test).

You can still run the whole test file by right-clicking on the file and selecting "Run Test" from the context menu.

Once you've done that, the tests will also be visible in the "Testing" tab, where you can see the results of each test case.

Conclusion

Test files in Deno are just regular TypeScript files, so you can use any TypeScript feature you like to write your tests. This includes using helper functions to generate multiple test cases, as we've seen in this article.

The key takeaway is that you can use Deno.test() inside a helper function or a for loop to generate multiple test cases. This allows you to run parameterized tests in Deno, and get detailed information about which test cases failed.

A journey through Server Side Rendering in Deno

2025-02-11T00:00:00Z

As a longtime .net developer, I've always preferred languages with strong typing. I find that I can reason about the code much better if I understand what data structures are required by a function call, and what it will return.

Naturally, this means that when doing any frontend work, I tend to reach for TypeScript. I find it's a welcome improvement over vanilla JavaScript, especially when using typed third-party libraries.

There is only one catch: setting up typescript, esm modules, and bundling can be really painful when you're just trying to get a simple project off the ground. Soon you're 2 hours in, and you're still trying to figure out why your imports aren't working.

This is where Deno comes in! Built by the creators of Node.js, deno sets out to undo the mistakes of their previous project. It has built-in support for TypeScript, esm modules, and even has a built-in bundler. This means that I can write all my code in TypeScript, and run it without any additional setup. It also does away with the node_modules folder, which makes my hard drive very happy.

So, when starting a new project recently, I decided to give Deno a try. The project is a simple server-side rendered web application, with a bit of interactivity sprinkled in.

It's now been a few weeks, and I've been through several iterations. Here is my journey through server-side rendering in Deno.

Deno has a built-in web server??

Yes, yes it does. Using the builtin Deno.Serve() function, you can create a simple web server in just a few lines of code.

The only downside of this approach is that you'll have to handle absolutely everything yourself. This means parsing the request, handling the response, and even serving static files. This is easy enough for a simple project, but it can quickly become unwieldy as your project grows.

Shopping for a framework

After deciding that I didn't want to write my own web server, I started looking for a lightweight framework that would handle the heavy lifting for me. I quickly found Oak, a simple framework for Deno that is very similar to Express.js.

Oak has built-in support for things like middleware and routing. It seemed like a great choice for a simple project, and it's easy to get started with.

The next step was to figure out a way to go beyond serving API endpoints and start rendering HTML on the server. This is where things started to get interesting.

Shopping for a templating engine

Handlebars

When thinking of templating engines, my first idea was to use good old Handlebars. I had never used it before, but I remember it being all the rage a few years ago, so I figured it must be good. Right? Right??

It was... below my expectations. And by "below my expectations" I mean "It makes me want to stab myself". The syntax, oh the syntax!! I have nothing but compassion for anyone who has to coexist with it.

The last straw was when I had to declare a helper function to compare two values. I had to write a helper function to compare two values. In a templating engine.

ejs

After a good old web search for "handlebars alternatives", I stumbled upon ejs.

As a .net developer, I was immediately reminded of Razor Pages / MVC. Simple, clean, and easy to use. I was sold.

...it did however come with its own set of quirks. For example, it doesn't have the equivalent of "Layouts" in Razor. This means that you have to manually include the header and footer in every page. It also has even weirder syntax than Razor, with various combinations of percent signs and angle brackets.

But mainly, the thing I was really missing until now was being able to unit test my UI. Not knowing if my partials were rendering correctly until I manually tested them in the browser was a pain.

In the end, I found that while the syntax was cozy and familiar, the web has moved on. I wanted something more modern, more... reactive. I wanted, in fact, React.

Detour to the promised land of Deno Fresh

Before I could start using React, I had to figure out how to get it to work with Deno. This is where I found 🍋 Deno Fresh. Fresh is Deno’s answer to Next.js. With built-in support for JSX and an "islands" architecture that prioritizes minimal client-side JavaScript, it looked very promising.

I quickly cloned the example repo on my machine to try it out. It worked great. Sure, it's extremely opinionated, but I can live with that.

I decided to try converting one of my ejs partials into a jsx component right inside the example project. Easy. Done. I was sold. Writing JSX instead of ejs felt natural, the way it was supposed to be all along.

At some point, however, things started to fall apart.

Testing components, for example, is not really supported out of the box. There's an open issue on github and the consensus seems to be... let's wait for Fresh 2.0.

As far as I understand it, the wind behind Fresh's sails is now more like a gentle breeze. It seems that the team has been busy working on Deno itself, and Fresh has been left behind.

I notice as I write this that the last official blog about it dates December 1, 2023, which is about 10 years in trendy javascript framework time.

But I like react! Maybe I can salvage this?

So it turns out that Deno Fresh uses preact-render-to-string under the hood to transform JSX components into HTML.

With some clever refactoring, I'm sure I can just replace my ejs Oak middleware with a React one!

-famous last words

So I did! I created a new middleware that would render my React components server-side, and it worked like a charm. If you're curious to see what it looks like, here is a github gist with the code 🙂

I now had a working server-side rendered web app in Deno under my belt. I was happy with the result, even if it felt a bit of a Frankenstein's monster.

And then I built a second project

Some time later, I wanted to start a new project. Similar requirements, so I figured I could just copy-paste the code from the first project and be done with it.

But then I thought,

If I need this, maybe others do too? Maybe I should make a library out of it? Maybe I should make my own framework? One framework to rule them all! 😈

Yeah, no. No thanks Satan. I'm good.

An important requirement of my second project was user management, authentication, and authorization.

Better-Auth looked exactly like the kind of thing I needed. Fully featured, popular, good documentation. I had absolutely no intention of trying to bend my own little framework to work with it. I just wanted to get my project done.

I also had the nagging feeling in the back of my head that I was just writing too much code for something that should be simple.

Enter Hono

The first backend framework that is mentioned in Better-Auth's documentation is Hono. I decided to take a look.

Hono does everything I was trying to build manually—but better. It has built-in JSX support, a router, and great documentation. The best thing is that I don't have to support any of it myself!

It also looks almost exactly like Oak, so that was already a plus.

Unsurprisingly, building my second project was a much smoother experience.

Conclusion

This was a long journey, but a rewarding one. The nice thing was that at every point during my first project I ended up having something that was working, and that I could build upon.

Refactoring my code to use the next thing was luckily always pretty easy, and I was able to learn a lot along the way.

One thing I learned is that it's easy to fall into the trap of doing everything "the Deno way", and assuming that a library or framework that's written for Deno is the best choice.

In reality, it's important to evaluate each library or framework on its own merits, and choose the one that best fits your needs.

Frameworks like Hono that are built for multiple runtimes are obviously going to be more popular and better maintained than something that's built for Deno only.

The great thing about Deno is that you can reference npm modules directly (without worrying about terabytes of node_modules), so you really have the whole JavaScript ecosystem at your disposal.

🔑🥡 Key Takeaways:

Don’t assume that a library made for Deno is always the best choice—evaluate based on actual needs.
Multi-runtime frameworks like Hono tend to be better maintained and more flexible.
Deno’s ability to use npm modules expands its ecosystem significantly.
Don’t be afraid to refactor and try new things — each iteration can teach you something new!

Running Docker in Windows without virtualization

2025-01-21T00:00:00Z

Docker is an essential tool for developers. It allows you to run applications in isolated containers, making it easy to manage dependencies and run the same code in different environments.

However, on Windows Docker requires virtualization support, which may not always be enabled or available. Even when using WSL2 as an alternative to Hyper-V, your machine must still support and enable Hyper-V.

Recently I needed to run docker on a Windows virtual machine, running inside VirtualBox on a Linux host.

Contrary to KVM/QEMU, VirtualBox does not support nested virtualization, unless you're using VirtualBox inside the VM too.

What VirtualBox offers, however, is much better (read: acceptable) video hardware acceleration compared to QEMU - and for someone like me who spends more time attending remote meetings than running containers, this is a good tradeoff.

I do however need to run containers from time to time, and having to switch to a different machine just for that is a bit of a hassle.

⚠️

Important! We're going to install Docker Desktop in this guide — however, without Hyper-V you won't be able to run the docker engine or do anything in the GUI.

Instead, we're relying on Docker desktop to provide the docker command line tool, which we'll be using to connect to a Linux server.

Step 1: Install Docker Desktop

Most online resources will point you to Docker Toolbox, which as of 2025 is a legacy solution that is no longer maintained. While you can still download it and install it, it's stuck on a very old version of Docker and is missing some crucial components like buildx.

Here is the link to the Docker Desktop download page.

Docker Desktop should install just fine, but of course it will complain if you try to run it.

Step 2: Install Docker on the remote server

If you haven't already done so, you'll need to install Docker on the remote server. There are plenty of resources online on how to do this, so I won't go into details here. The official docker docs have plenty of information on how to install Docker on different platforms.

Here's the link to the instructions for Ubuntu.

Be sure to add your user to the docker group so you can run docker commands without sudo.

Step 2: Enable ssh on the remote server

You'll need to be able to connect to the remote server via ssh. If you're using a cloud provider, you'll likely already have this set up. If you're using a local server, or Desktop Ubuntu, you'll need to install an ssh server.

This is simply done by running:

sudo apt install openssh-server

You'll likely also need to open the ssh port on your firewall.

sudo ufw allow ssh

Step 3: Configure Docker Desktop

Easy peasy. You just need to set an environment variable to tell Docker Desktop to connect to the remote server.

Try it out in a terminal window. First, set the variable:

$env:DOCKER_HOST="ssh://your-username@your-server:22"

Then run a docker command:

docker ps

You should get a prompt asking you to accept the server's fingerprint, then another prompt asking for your password. If everything goes well, you should see the list of containers running on the remote server. (none if you just installed Docker)

Step 4: Configure a Persistent Environment Variable

You don't want to have to set the environment variable every time you open a terminal window. Instead, we can set the environment variable for all of Windows.

Right-click on the start button and select "System". Then click on "Advanced system settings" and then "Environment Variables".

Add a new system variable with the name DOCKER_HOST and the value ssh://your-username@your-server.

Any new terminal window you open will now be using the environment variable, and docker commands will connected to the remote server.

Step 5: Usability improvements

As it is, Docker will ask for your password every time you run a command. This can be a very annoying, especially if you're running a lot of commands. Some commands, like docker buildx build implicitly run multiple docker commands, so you'll be asked for your password multiple times.

Instead, we can use ssh keys to authenticate.

On your Windows machine, generate a new ssh key pair:

ssh-keygen

You'll be asked where to store the key. Be sure to enter this path: C:\Users\your-username\.ssh\id_rsa. This is the default path where Docker will look for the key. (Some guides will tell you to just accept the default path, but doing so made the ssh-keygen command hang indefinitely in my case.)

You'll be then asked for a passphrase. I recommend leaving this empty so you don't have to enter it every time you run a docker command.

The next step is to copy the public key to the remote server. You can do this with the ssh-copy-id command, but this command is not available on Windows.

Instead, we can copy the key manually.

First, print the public key:

cat ~\.ssh\id_rsa.pub

Copy the whole line that is printed. Next, connect to the remote server and add the key at the end of the authorized_keys file, using your favorite text editor (nano in this case):

ssh your-username@your-server
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

This is it! You should now be able to run docker commands without being asked for your password. Try by running docker ps again in a new terminal window.

Conclusion

While this article focussed on connecting docker to a local server, you can also follow the same steps to connect to a server in the cloud.

This can be useful if you want to run docker commands on a more powerful machine, or if you want to run docker commands on a machine that is serving web traffic to the internet!

Announcing CodeMade Games!

2025-01-07T00:00:00Z

🕹️

TLDR I'm excited to announce the launch of CodeMade Games, a new website dedicated to fun, casual games that you can play in your browser 🎉

My game development journey

Since I started playing videogames in my childhood, I've always been fascinated by the idea of creating my own games. Building games takes a lot of time and effort, but it's also incredibly rewarding.

I had somewhat of a failed start many, many years ago when I tried to build a platformer game in C++. While I did get some traction initially, with a nice prototype and some basic game mechanics, I eventually lost interest and moved on to other projects. One of the main reasons for this was that I have no artistic skills whatsoever, and the little art I could produce would take many long hours to create.

A new beginning

Fast forward to a few weeks ago, when I wanted a break from my usual backend development work and decided to play around with the :has CSS selector. I ended up building a simple minesweeper clone - and had a lot of fun doing it!

After comprehensively testing the game on my couch, on my way to work, and during my lunch breaks, I decided that it was time to release it to the world. And so, CodeMade Games was born!

My core game development principles

It's been almost 15 years since I last worked on a game, and I've learned a lot since then. Here are some of the core principles that I'm following with CodeMade Games:

Do less: Like, way less. No fancy graphics, no complex mechanics. Art was always my biggest blocker, so I'm focusing on simple, available assets. Emojis are a great way to add some personality to the games without spending hours on art! 🔥
Build for the web: I want my games to be accessible to everyone, so I'm building them to be played in the browser. Mobile is also a priority, mostly because I want to be able to play them on my phone!
Respect the user: Games should be fun, not annoying. With most game companies trying to manipulate their users into spending more time and money, I want to take a different approach. No ads, no invasive tracking, no dark patterns. Have your 10 minutes of fun and then go back to your life!
Learn something: Writing games is my way to relax and have fun, but I also want to learn new things. Whether it's a new CSS trick, a new JavaScript feature, or a new game design pattern, I want to keep pushing myself to learn and improve.

What's next?

I'm working on a few new games that I'm excited to share with you soon.

I'm also planning to write more about my game development journey, the tools I'm using, and the lessons I'm learning along the way.

Be sure to subscribe to the RSS feed or follow me on BlueSky to stay updated!

And of course, see you on CodeMade Games 🎮

Modern CSS is awesome!

2024-11-25T00:00:00Z

The last time I seriously worked with CSS was back when Firefox was still a relevant browser (😢), and Internet Explorer 11 was just on its way out.

Flexbox had just become a popular way to create layouts, and CSS Grid was new and exciting, but not yet widely supported. Not that I could use either, since IE's implementation of flexbox was so riddled with bugs that it was practically unusable.

But now. We're in 2024, and things have changed. A lot.

Here are a few of my favourite features of modern CSS, in no particular order:

CSS Variables

CSS variables were once only possible with a preprocessor like SASS or LESS, but now they're a native feature of CSS.

Here is how to define a variable:

:root {
  --primary-color: #ff0000;
}

Specifying the variable at the root level makes it available to the entire document.

The variable can then be used with the var() function:

div {
  color: var(--primary-color);
}

The neat thing is that variables follow the cascading logic of CSS, so you can update their value at any level of the document, and all elements that use that variable will automatically update.

See the Pen CSS Variables by Loris Bognanni (@codemade) on CodePen.

Nesting in CSS

This is again one of those things that you would have needed a CSS preprocessor for in the past, but is now a native feature of CSS. Useful for keeping your code concise and readable.

.parent {
  color: red;
  .child {
    color: blue;
  }
}

I especially find this useful when styling pseudo-elements and states:

button {
  background-color: blue;
  &:hover {
    background-color: red;
  }
  &:after {
    content: '🚀';
  }
}

Centering a `div` is now very easy

Centerig a div has long been a recurring joke amongst web developers, but thanks to CSS Grid, it's now a two-liner:

div.parent {
  display: grid;
  place-items: center;
}

Viewport units

Viewport units are a way to size elements based on the size of the viewport. They are particularly useful for creating responsive designs.

Viewport units include vw (viewport width), vh (viewport height), vmin (the smaller of the two), and vmax (the larger of the two). So for example, if you want an element to be half as wide as the viewport, you can do this:

.my-element {
  width: 50vw;
}

Here is an example that combines viewport units and CSS Grid to center a div in the middle of the screen:

See the Pen centering by Loris Bognanni (@codemade) on CodePen.

Math in CSS

CSS has a calc() function that allows you to perform calculations right in your stylesheets. This can be useful for things like calculating widths, margins, and padding.

The exciting thing about calc() is that it can combine different units of measurement, so you can do things like this:

.my-element {
  width: calc(50% - 20px);
}

You can of course use calc() with variables as well:

:root {
  --margin: 20px;
}
article {
  margin: calc(var(--margin) * 2);
}

CSS Containers, container queries, and container measurements

By telling CSS that a certain element is a container, you can now do things like size its children based on the container's size, or apply styles based on the container's size.

Similar to viewport units, container units are based on the size of the container element. They include cqw, cqh, cqmin, and cqmax.

See the Pen Untitled by Loris Bognanni (@codemade) on CodePen.

Container queries take this a step further by allowing you to apply styles based on the size of the container. This is particularly useful for creating responsive designs where the layout changes based on the size of the container, rather than the viewport.

`aspect-ratio` property

If you ever wanted to embed a video in your responsive page in the old days, you probably had to use some javascript to calculate the correct height based on the width of the video.

But now, you can use the aspect-ratio property:

.video {
  width: 100%;
  aspect-ratio: 16 / 9;
}

`:has()` selector

The :has() selector allows you to select an element based on its descendants. This can be useful for styling elements based on their content, or for selecting elements that contain a specific child element.

While before :has you would have to use javascript or some sort of preprocessing to achieve the same effect, now you can do it with a single line of CSS.

For example, here is a simple way to style a <label> element when its child <input> is checked:

See the Pen :has demo by Loris Bognanni (@codemade) on CodePen.

The case of the unhappy CloudFront distribution

2024-06-29T00:00:00Z

For fun, and as a learning experience, I'm building a very simple comment system for this blog.

Currently codemade.net is a simple static website built by Jekyll everytime I push to the main branch on its GitHub repo. This is a relatively common setup for smaller websites, and it has the benefit of being extremely fast and cheap to host.

There are a number of third party comment systems floating around the internet, but they all have some drawbacks. Some are just too expensive for a small website like mine, others are advertising platforms in disguise, and others still are just too complicated to set up. Perhaps this is why a lot of people rely on social media for comments.

I wanted to build something that was simple, cheap and cheeful. I also wanted to get hands on with tools I rarely use, like ASP.net Core on Lambda, HTMX, terraform, CloudFront, etc.

It follows a relatively common pattern: all the static content is stored in S3, while the dynamic APIs are served by Lambda functions. An HTTP API gateway is used to route requests to the correct Lambda function, and CloudFront sits in front of everything to provide caching, routing, and SSL.

I built and deployed this in pieces, starting with the main Lambda function. I set it up to serve both the frontend (a simple HTML page), and the backend: a GET endpoint to return the comments for a post, a PUT endpoint to post a new comment. I tested it locally, and it worked fine.

I deployed it to AWS, behind an API Gateway, and surprisingly, it worked!

I then decided to add CloudFront in front of the API Gateway, and store the static content in an S3 bucket.

When configuring CloudFront, one must set up one or more "Origins" (the places where CloudFront will fetch the content from). I set up two origins: the default one being S3 where index.html is stored, and the API Gateway, only for the /comments/* path.

Deploy the distribution, and yes! The index page loads, and navigating to a comments page brings up a list of comments.

Try posting a comment however, and... this happens:

Soo, somehow GETting the comments works, but PUTing a comment doesn't.

I started debugging by looking at each piece of the puzzle:

Does the lambda work? Yes, testing the lambda in isolation yields the expected result (a comment is posted)
Does the API Gateway work? Yes, invoking the API gateway URL directly calls the lambda and posts a comment
Did I set up the CloudFront distribution correctly? I think so, but let's check the settings. I double-checked the origins, and they look fine. I also checked the behaviors, and indeed requests to /comments/* are routed to the API Gateway (of course they are! GET requests work!)
Maybe it's a caching issue? I tried invalidating the cache, but it didn't help.
Maybe it's a CORS issue? I tested by directly invoking the PUT endpoint via Postman, and it worked. So probably it's not that.

Hmm. Perhaps the CloudFront logs could help me? I enabled logging, and tried to post a comment. I then waited for a few minutes, and checked the logs:

(shoutout to the Rainbow CSV Vs Code extension for making this somewhat readable!)

It's a bit hard to follow, but we can see 3 requests: the first two are GET requests to the favicon.ico resource (presumably served from S3), and to the a comments page (served by the API Gateway). The third request is a PUT request to the same comments page, and it returns a 403 status code.

The x-edge-result-type field simply says Miss for the GET requests (ie they were not in CloudFront's cache) and Error for the PUT request. Not very helpful.

The x-edge-detailed-result-type field looks interesting. It says InvalidRequestMethod for the PUT request.

Could it be that I didn't allow PUT requests on the Api Gateway origin?

I checked my terraform code, and nope, all HTTP methods are allowed for that origin 🤔

So I started googling (well duckduckgoing) for every combination of "CloudFront", "InvalidRequestMethod", "403", "PUT", "API Gateway" I could think of.

I found some StackOverflow posts where folks were having similar issues, but they were all related to not having configured one of the three components (CloudFront, API Gateway, S3) correctly. I double, triple, quadruple checked my configuration, and it all looked fine.

Out of desperation, I tried mixing things up a bit. I changed the CloudFront distribution to have only one origin: the API Gateway. I then tried posting a comment, and... it worked! But why?

I was really tempted to just leave it at that, but the nagging voice at the back of my head, complaining that I would have to invoke the lambda for each. single. static. asset. was too loud.

Obviously the moral imperative is to have the static content served from S3 (it's cheaper, faster, and more reliable). So I re-enabled the S3 origin, and tried posting a comment again. And... back to not working, of course.

Okay. Time to take a step back. Go for a walk. Clear my head.

It's the next day, and I'm back at it. Time to try and simplify things a bit.

Perhaps my terraform code was too complex, or it was missing something? I decided to try and set up the CloudFront distribution manually, using the AWS console. Manually add both origin, set up the behaviors, and deploy.

Nope, same issue.

There must be a reason.

Maybe I can look at the CloudFront logs again? There are so many fields. Maybe I missed something? Maybe if I cross my eyes just right it will dawn on me?

And oh yes, dawn on me it did. The stupid, obvious little thing that I missed. Let me highlight it for you:

Do you see it? The GET request is being sent to /comments/foo/bar, but the PUT request is being sent to /Comments/foo/bar. Capital C. FML 😩

So CloudFront was directing our PUT request to the S3 origin, which of course didn't have the PUT method enabled, and returned a 403.

Fun fact, because my API gateway was set to proxy all traffic to my lambda, it didn't care about the capitalization. But CloudFront does.

AWS explicitly call this out in their documentation:

And the best part? Not only I knew about this, I must have read that page at least 15 times while debugging this.

Conclusion

Anyway, to make a long story short, I fixed my frontend code to PUT to the right path, everything started working as expected 🎉

I hope you enjoyed this little story. I certainly learned a lot about CloudFront, API Gateway, and Lambda while debugging this. My desk has a fresh head-shaped indentation, but c'est la vie.

Oh, and the comment system is not ready yet 😅, so feel free to discuss this on HN, or Reddit 😅

The case of the mysteriously disappearing window

2023-12-16T00:00:00Z

One small annoyance I contend with everyday is links opening in the "wrong" browser. See, I use different browsers for different purposes.

Chrome is the browser I use for all my work stuff, partially because I prefer its Dev tools and also because most SaaS apps I use for work tend to work better with it. Firefox however is my preferred browser and has the advantage of not being built by an advertisement company, so I tend to do all my personal browsing there. I also use Edge for Netflix because why not.

So I spent a few hours hacking together Roundabout, a simple app that registers itself as a web browser and allows you to pick the browser you'd like to open your link in.

Upon testing, everything looked good: I could click a link in a non-browser application like Telegram Desktop or WhatsApp desktop, and Roundabout would pop up asking me if I'd prefer Chrome or Firefox.

...except for Slack

As it turned out, clicking a link from Slack would... do nothing?

I started with the usual debugging techniques: add some logs, test again. Build fails. Wait, why? A quick glance at Process Explorer revealed the issue: Roundabout was starting, but somehow it got stuck and wasn't showing the main window. After terminating all the stuck instances, I was able to test again, this time with logs.

The logs looked OK, but just stopped after showing the main form 🤔

Next it was time to investigate how exactly Slack starts a web browser. A few minutes of sleuthing with Process Monitor got me my answer: when opening links Slack runs a new command, in the form of RunDll32.exe URL.dll,FileProtocolHandler {the URL}; interesting 🤔.

If you never crossed paths with it, RunDll32 is perhaps one of the most interesting applications in Windows. It allows one to invoke functions that are defined in Dll files, simply by calling rundll32 {the dll},{the function} {any parameters}. In this case, we're executing the FileProtocolHandler function that is defined in URL.dll, and passing our URL to it.

So what happens if I just run that command from a command prompt?

Hmmm, it works as expected...

I began to suspect that there was some sort of problem actually showing the form, when starting from Slack. What would happen if I added a MessageBox just before showing the form? Interestingly, the message box showed just fine, and then the main form also showed up fine 🤔

Perhaps the issue is just that Roundabout shows up too quickly? I added a 1 second pause just before starting and... nothing, the main window wouldn't show again. I'm kinda relieved because I really didn't want to add a huge pause before something happens for the user 😌

Okay, so it looks like Slack "swallows" the first proper window we create. I wonder what happens if we temporarily create an empty window and immediately close it before showing the main window?

🎉It works!

At this point, it's been a few hours debugging this on and off, and a hacky workaround sounds like the perfect solution...

🧹 Time to clean up the code a bit, and hide this monstrosity behind a helper function.

It would be also good to only do this when starting from Slack, otherwise users would see an empty window flash on screen. Unfortunately there's no good way to find out what is your "parent" program, but the user likely clicked on the link with their mouse, so finding the right window based on the pointer coordinates should suffice.

Here is the admittedly horrible code that does this!

Fin.

In unraveling the mystery of Slack links not cooperating with Roundabout, we've delved into unexpected corners of Windows application development. With the code tweaks and insights gained, Roundabout now seamlessly handles links from various applications, including Slack.

As with any solution, there's always room for improvement. Considerations for future versions include refining the code further, and perhaps adpoting this workaround for other apps I missed this time.

If you do find one such case of an app "swallowing" Roundabout, please do open an issue on Github!

How to draw a conic gradient with System.Drawing in gdiPlus

2021-05-24T00:00:00Z

Recently, I have been working on adding support for conic gradient (or conical gradients, as some say) to Clock. Now, Clock uses GdiPlus, or the System.Drawing namespace in C# to do all of its drawing. My aim was to replicate the conic-gradient() CSS function.

Imagine my surprise when searching online for "gdiplus conic gradient" yielded few and very old results. Ok, maybe you're not very surprised because all the cool kids are now writing Electron apps and mid-2000s System.Drawing has been relegated to history 😄

Like any other methods of filling a shape, we're going to need a type of Brush to do it. The one we're going to use for conic gradients is the PathGradientBrush.

What's interesting about PathGradientBrush is that it can be used in many ways. This article from C# Corner goes over a few, but crucially the one that's missing is a proper conic gradient. After a lot of searching, I finally stumbled on this article(the original website is now offline!) and noticed this image and code snippet:

  GraphicsPath pth=new GraphicsPath();
  pth.AddEllipse(this.ClientRectangle);
  
  PathGradientBrush pgb=new PathGradientBrush(pth);
  pgb.SurroundColors=new Color[]{
                    Color.Red,
                    Color.Orange,
                    Color.Yellow,
                    Color.Green,
                    Color.Blue,
                    Color.Indigo,
                    Color.Violet };

  pgb.CenterColor=Color.Gray;

  e.Graphics.FillRectangle(pgb,this.ClientRectangle);

It's not a "real" conic gradient, but close. What's interesting in that example is that it's setting a SurroundColors property, but, because a circle in gdi+ has many vertices, only a tiny portion of the whole is occupied by a gradient. Of course the next step to try was using a polygon with the same number of vertices as the number of colors and check the result:

using var pth = new GraphicsPath();
var colors = new Color[]{
  Color.Red,
  Color.Orange,
  Color.Yellow,
  Color.Green,
  Color.Blue,
  Color.Indigo,
  Color.Violet }

var rect = new Rectangle(0,0, sz, sz);

var polyPoints = new List<Point>();
for (double i = 0; i <= colors.Length; i++)
{
  polyPoints.Add(new Point(
    (sz / 2) + (int)(Math.Cos((Math.PI * 2) * (i / (double)pts)) * (double)(sz/2)), 
    (sz / 2) + (int)(Math.Sin((Math.PI * 2) * (i / (double)pts)) * (double)(sz/2))
  ));
}
pth.AddPolygon(polyPoints.ToArray());

PathGradientBrush pgb = new PathGradientBrush(pth);

pgb.SurroundColors = colors;

g.FillRectangle(pgb, rect);

It's close, but where does the white come from? Well if you look closely at the circle example from the article above, there's a CenterColor property that is set to Gray there. When you don't specify it, instead of there being no center color, a white shade is used instead. Setting CenterColor to transparent renders the filling itself transparent so that's no good either.

But! PathGradientBrush has a Blend property that allows us to control the CenterColor's opacity from the center to the border of the shape. We can just set it to fully opaque at both ends to get our gradient:

pgb.Blend = new Blend {
  Factors = new float[] { 1, 1 },
  Positions = new float[] { 0, 1f }
};

Isn't that something! Now to make it really look like the kind of conic gradient we get in css, we have to make it so the last and the first color don't blend into each other. We can do this by creating a polygon that has one less vertex, where the last Point is repeated. We also need to specify the CenterPoint property, otherwise Gdi+ will auto-calculate it as being slightly off-center:

One last thing! You might have noticed that, while we're using FillRectangle to paint our gradient, we're not really filling all of it, but we're drawing a polygon. This is easily fixed by using a suitably large radius for our polygon.

If you're interested to see what I ended up with, the full source code is open source as part of Clock 😊

Fix Windows restarting after sleep or hybernate: the complete 2020 guide

2020-10-25T00:00:00Z

So your computer starts on its own after you put it to sleep or even after you turn it off. Maybe it does so immediately or maybe it waits for a few minutes or hours. But you feel like you can't trust it anymore: there's few things more unsettling than being woken up by the bright light of your screen in the middle of the night. Well here is my comprehensive list of things to check (and to turn off!) to prevent this from happening again.

First off, open an admin Powershell terminal. You can do so by right-clicking the start menu button and selecting Windows PowerShell (Admin)

1: Check why the system restarted

The first thing to do when diagnosing the problem is to use the powercfg /lastwake command to find out what prompted the system to restart. If a hardware device was responsible for restarting windows, you should see it here.

Sometimes, however, things are more nebulous and you get something like:

❯ powercfg /lastwake
Wake History Count - 1
Wake History [0]
  Wake Source Count - 0

In this case, follow the next steps to make double sure that nothing can wake up your pc.

2: Disable wake timers

This is fairly straightforward and should really be all you need.

Open the Start menu and type Edit power plan
Choose Change advanced power settings
Navigate to Sleep -> Allow wake timers and select Disable
Press OK and close

In theory, the above steps should be enough to stop any device from waking up your computer. In practice, you'll probably have to explicitly disable more stuff:

3: Disable any peripherals that can wake up your computer

The main peripherals to take into account here are keyboards, mice and network adapters. The network adapter can be set to wake up your computer whenever it receives any data (a very bad idea!) or when it receives a special "wake up" packet.

You can check which devices can wake up your pc with the command: powercfg /devicequery wake_armed. You'll see something like:

❯ powercfg /devicequery wake_armed
HID-compliant mouse (006)
HID Keyboard Device (006)

Now comes the fun part. Open the Device manager by right-clicking the Windows button and selecting Device Manager and, one by one, open the property pages for the devices listed above. In the Power management tab, you'll find a flag that you want to disable: Allow this device to wake the computer. Do so for each device. For your network card, you can optionally set it so that only a "magic packet" can wake up the computer. If you don't know what a magic packet is, it's safe to disable it 😅

4: Find out if any scheduled tasks are waking up your computer

If the above steps didn't work, it's time to bring out the big guns. And by big guns I mean this powershell command: Get-ScheduledTask | where {$_.settings.waketorun}. It will list all the scheduled tasks that are allowed to wake up your computer in order to perform some maintenance, or more likely to install updates:

❯ Get-ScheduledTask | where {$_.settings.waketorun}

TaskPath                                       TaskName                          State
--------                                       --------                          -----
\Microsoft\Windows\.NET Framework\             .NET Framework NGEN v4.0.30319... Disabled
\Microsoft\Windows\.NET Framework\             .NET Framework NGEN v4.0.30319... Disabled
\Microsoft\Windows\InstallService\             WakeUpAndContinueUpdates          Disabled
\Microsoft\Windows\InstallService\             WakeUpAndScanForUpdates           Disabled
\Microsoft\Windows\SharedPC\                   Account Cleanup                   Disabled
\Microsoft\Windows\UpdateAssistant\            UpdateAssistantWakeupRun          Disabled
\Microsoft\Windows\UpdateOrchestrator\         Backup Scan                       Ready
\Microsoft\Windows\UpdateOrchestrator\         Reboot                            Ready
\Microsoft\Windows\UpdateOrchestrator\         Reboot_AC                         Disabled
\Microsoft\Windows\UpdateOrchestrator\         Universal Orchestrator Start      Ready

In my case, the "Backup Scan" task above was the culprit, so I disabled it. You could disable it by opening the Windows task scheduler, but sometimes the UI won't allow you to disable one of the "system" scheduled tasks like the ones related to Windows Update. But a simple powershell command can take care of it:

❯ Disable-ScheduledTask  "\Microsoft\Windows\UpdateOrchestrator\Backup Scan"

Check again with the previous command, and it will be disabled:

❯ Get-ScheduledTask | where {$_.settings.waketorun}

TaskPath                                       TaskName                          State
--------                                       --------                          -----
\Microsoft\Windows\.NET Framework\             .NET Framework NGEN v4.0.30319... Disabled
\Microsoft\Windows\.NET Framework\             .NET Framework NGEN v4.0.30319... Disabled
\Microsoft\Windows\InstallService\             WakeUpAndContinueUpdates          Disabled
\Microsoft\Windows\InstallService\             WakeUpAndScanForUpdates           Disabled
\Microsoft\Windows\SharedPC\                   Account Cleanup                   Disabled
\Microsoft\Windows\UpdateAssistant\            UpdateAssistantWakeupRun          Disabled
\Microsoft\Windows\UpdateOrchestrator\         Backup Scan                       Disabled
\Microsoft\Windows\UpdateOrchestrator\         Reboot                            Ready
\Microsoft\Windows\UpdateOrchestrator\         Reboot_AC                         Disabled
\Microsoft\Windows\UpdateOrchestrator\         Universal Orchestrator Start      Ready

Now hopefully you can set your device to sleep mode and have some well deserved, uninterrupted sleep yourself! 😁

The feature image above was taken by Clint Patterson

How to combine Docker and VSCode to reach development nirvana

2020-10-10T00:00:00Z

One of the best features in VS Code, and my personal favourite is called Remote Containers. What it does is open the folder you're working on inside a container and then connect to it, so that you can, for example, run your jekyll site on windows without having to install ruby system-wide. Because all the development is done inside the container, you don't have to worry about having multiple versions of node or python cluttering your machine.

This is especially useful if your main OS is Windows, as getting set up with some languages is notoriously tougher there.

Working in a devcontainer has also the advantage that all the settings can be committed into source control, so you can share the exact same development environment with the rest of your team. No more 15-step procedure to follow to set up the local dev environment!

Getting started is really simple:

Install the Remote - Containers extension
Press F1 to open the command palette
Run "Open folder in container" command
Select "From a predefined container definition"
Select the most appropriate container image.

This will create:

A .devcontainer folder in your project, containing:
A dockerfile for the development container
A file named devcontainer.json that is mostly used to define any ports that should be forwarded to the host

You can now open the integrated terminal and type commands directly in your container!

An example: this website

I love the simplicity that comes with static site generators, and jekyll is by far the most popular choice. Using a development container setup allows me to edit and test any change on all my computers, without having to install ruby, bundler or any of jekyll's dependencies.

This is the dockerfile I use for my jekyll devcontainer. It's a slightly modified version based on the official Microsoft one from some time ago; I had to add a line to install zlib1g-dev otherwise it wouldn't work 😅.

See the dockerfile on github

Now, when I open the repository in Visual studio code, I just have to run bundle exec jekyll serve in the integrated terminal to run it. The container exposes port 4000 so I can just open http://localhost:4000 in my browser and preview the changes. What's more, if port 4000 is already used by another program, when clicking on the localhost link in the terminal, VS Code will transparently open the site on a different port!

Found this useful? Want to add something? Reach out on twitter!

CodeMade Blog

It's getting hard to justify app stores

App stores are yucky

And then AI coding came along

Hacker news reader

Background switcher

The age of personal apps is here

But the enshittifiers are fighting back

Rumors of the death of SaaS have been greatly exaggerated

Nobody wants to maintain your crappy version of Trello

Free alternatives already exist

Software is a liability

SaaS developers can use AI too

Counterpoint: SaaS companies are overvalued on the stock market

TL;DR

Building for an audience of one: starting and finishing side projects with AI

I would have never built this without AI

It all starts with a conversation

The perfect balance between safe and YOLO

Trying different tools, and running out of tokens

You still need to know how to code

The age of finishing side projects is here?

How to use Deno's own SQLite module on Alpine Linux

That's nice and all but I use Docker?

Wrapping Up

Announcing email-webhook

What is email-webhook?

Here's how it works:

Why email-webhook?

Looking for feedback

On a personal note

How I deploy my web apps in 2025

The Old Ways: Docker Compose for the Basics

And then I built a web app

The Automated Pipeline

Handling SSL with Caddy

The Results

And then there were more

Looking forward

Running parameterized tests in Deno

Testing in Deno

How to run parameterized tests in Deno

A note on the Visual Studio Code Deno extension

Conclusion

A journey through Server Side Rendering in Deno

Deno has a built-in web server??

Shopping for a framework

Shopping for a templating engine

Handlebars

ejs

Detour to the promised land of Deno Fresh

But I like react! Maybe I can salvage this?

And then I built a second project

Enter Hono

Conclusion

🔑🥡 Key Takeaways:

Running Docker in Windows without virtualization

Step 1: Install Docker Desktop

Step 2: Install Docker on the remote server

Step 2: Enable ssh on the remote server

Step 3: Configure Docker Desktop

Step 4: Configure a Persistent Environment Variable

Step 5: Usability improvements

Conclusion

Announcing CodeMade Games!

My game development journey

A new beginning

My core game development principles

What's next?

And of course, see you on CodeMade Games 🎮

Modern CSS is awesome!

CSS Variables

Nesting in CSS

Centering a div is now very easy

Viewport units

Math in CSS

CSS Containers, container queries, and container measurements

aspect-ratio property

:has() selector

The case of the unhappy CloudFront distribution

Centering a `div` is now very easy

`aspect-ratio` property

`:has()` selector