CodeMade Blog

Experimenting with subagents: strict rules for token-minning

2026-08-25T00:00:00Z

For the past few weeks, I've adopted a new workflow for my AI assisted coding. I've settled on a very simple subagent based approach, where a main agent coordinates the work, and two subagents do the actual coding and reviewing.

The idea is simple but it hides a lot of depth: working with agents has a set of constraints for regular people with regular budgets:

Bigger and more capable models are more expensive
Smaller models are cheaper, and getting more capable as time goes on
Context is expensive, and the more context you have, the more expensive it gets
Token caching is a thing, but it does have limits: if you pick up an old session, you might have to reprocess all the context, which is expensive
Models tend to have a "dumb zone" where they get more unreliable as the context grows
Tool calls tend to generate a lot of text that has to be processed in each follow up message

This means that the old approach of "use opus for everything" tends to become impractical when working on larger projects.

Practically I wanted to migrate a fairly large, completely vibe coded codebase (a level editor for a game I'm working on) from vanilla JavaScript to React with TypeScript, and do so while improving the code quality and maintainability. The project is large enough that it would be impractical to do it all in one go.

Subagents to the rescue

If you're on tech twitter for any amount of time, "subagents" are already a thing of the past. The cool kids are now doing "loops" or even "graphs".

The cool kids also have infinite budgets and work for the token factories. I only have a "Pro" Claude subscription for personal use, meaning that each token needs to earn its keep. I need to token-minn, not token-maxx!

In my previous post on the matter, my experience with subagents was

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.

This time, I am coming at the sub-agent use case from a different angle: now it's all about optimizing for cost, by using cheaper models for routine tasks, and optimizing the context they need to do their job.

To keep things as simple as possible, but not simpler, my process looks like:

A Planning session, done with Opus 5, generates a markdown (e.g. docs/feature-x-plan.md) file containing the plan for the migration / big feature. The plan is split into several milestones.
During regular work, I interact with the main agent, which is pointed to a workflow file describing how it will manage the work.
The main agent is given the plan file, and asked to direct a "senior coder" (Opus or Sol, medium reasoning) subagent to break down the milestone into a set of small stories that "a junior engineer can pick up" and store the result in a markdown file (e.g. docs/feature-x-<milestone>.md).
For each story, the main agent will work through the workflow:
- A "coder" (Sonnet or Terra, medium reasoning) subagent is tasked with implementing the next story
- A "reviewer" (Opus or Sol, low reasoning) subagent reviews the change and gives it a thumbs up or down.
- The main agent sends the reviewer's feedback back to the coder and the cycle repeats until the change is approved.
- Once the change is approved, the main agent updates the milestone doc, commits everything to git and moves on to the next story.
We then update the plan file with the progress, and move on to the next milestone (or stop for the day).

%%{init: { "flowchart": { "curve": "stepAfter" } } }%%  
flowchart TD
    classDef default text-wrap:true,white-space:normal;
    Create_overall_spec__17e7846e[Create overall spec, split in milestones] --> Work_on_next_milesto_e97c058d[Work on next milestone]
    Work_on_next_milesto_e97c058d --> sc
    Senior_coder_Break_d_ebf70296[Break down next milestone]
    Senior_coder_Break_d_ebf70296 --> Select_next_task_f184a500[Select next task]
    Select_next_task_f184a500 --> Assign_coder_to_task_f44d0617[Assign coder to task]
    Assign_coder_to_task_f44d0617 --> c
    Write_code_78fe1ad5[Write code]
    Write_code_78fe1ad5 --> Run_tests_lint_a2bcfc51["Run tests / lint"]
    Coder_done_review_21d3941a[Coder done, review] --> r
    Reviewer_Review_chan_5375aae9["Review changes (read only)"]
    Run_tests_lint_a2bcfc51 --> Coder_done_review_21d3941a
    Reviewer_Review_chan_5375aae9 -->|Bugs found| Assign_fixes_to_code_f9ec18ac[Assign fixes to coder] --> c
    Reviewer_Review_chan_5375aae9 -->|Code is fine| Commit_changes_67cd3b29[Commit changes]
    Commit_changes_67cd3b29 --> More_tasks_c5e0d359[More tasks?]
    More_tasks_c5e0d359 -->|yes| Select_next_task_f184a500
    More_tasks_c5e0d359 -->|no| Milestone_done_Updat_358f3c5a[Milestone done. Update spec. & commit]
    Milestone_done_Updat_358f3c5a --> More_milestones_c9982668[More milestones?]
    More_milestones_c9982668 -->|yes| Work_on_next_milesto_e97c058d
    More_milestones_c9982668 -->|no| All_done_ced44dce[All done! 🎉]

    c -. optional: ask for help .-> hw



subgraph sc["Senior coder subagent"]
    Senior_coder_Break_d_ebf70296
    hw[Help coder agent]
end
subgraph c["Coder subagent"]
    Write_code_78fe1ad5
    Run_tests_lint_a2bcfc51
end
subgraph r["Reviewer subagent"]
    Reviewer_Review_chan_5375aae9
end
subgraph "Main agent"
    Work_on_next_milesto_e97c058d
    Select_next_task_f184a500
    Commit_changes_67cd3b29
    Milestone_done_Updat_358f3c5a
    More_milestones_c9982668
    All_done_ced44dce
    Assign_coder_to_task_f44d0617
    Coder_done_review_21d3941a
    Assign_fixes_to_code_f9ec18ac
end

classDef style0 stroke:#C3CFD9,fill:#ffffff,color:#293845
class All_done_ced44dce,Assign_coder_to_task_f44d0617,Assign_fixes_to_code_f9ec18ac,Coder_done_review_21d3941a,Commit_changes_67cd3b29,Create_overall_spec__17e7846e,Milestone_done_Updat_358f3c5a,More_milestones_c9982668,More_tasks_c5e0d359,Select_next_task_f184a500,Work_on_next_milesto_e97c058d style0
style Reviewer_Review_chan_5375aae9 stroke:#2C88D9,fill:#d5e7f7,color:#293845
style Senior_coder_Break_d_ebf70296 stroke:#E8833A,fill:#fae6d8,color:#293845
style hw stroke:#E8833A,fill:#fae6d8,color:#293845
style Write_code_78fe1ad5 stroke:#1AAE9F,fill:#d1efec,color:#293845
style Run_tests_lint_a2bcfc51 stroke:#1AAE9F,fill:#d1efec,color:#293845
linkStyle 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 stroke:#788896

The devil is in the details, and the details are mad expensive

Here are some of the things I learned while doing this:

Cached tokens have a relatively short shelf life. If your Claude session runs out of usage, it might be sitting idle for long enough that the context is no longer cached. In this case, better to start a new session than to reprocess all the past context.

This is where instructing the main agent to keep track of where the work is, in the plan file, pays dividends. Now it's possible to start a new session, or even change the model, and continue where you left off without paying through the nose for context reprocessing.
Have the main agent feed the subagents with exactly the context they need to do the job.

The subagent should not have to go read the plan files, or all of the codebase. It should have this information already distilled and passed to them in the prompt.
Do not let the reviewer run tests, linting, or any other automated checks. We don't want to waste tokens on tool calls and checks that the coder already ran while implementing the story. The reviewer is specifically instructed to only look at the code and do nothing else.
A weaker model is perfectly fine for coding if you plan things well. I settled on Sonnet/Terra at medium effort for the best combination of price, speed, and quality.
I want the reviewer to be a strong model, but I don't want it to go crazy. The best bang for the buck here is Opus or Sol at Low reasoning effort.
Especially for web software, Claude will want to do some semi-manual browser testing. This is a very expensive idea.

Automated testing is the way to go; the moment your agent has to look at screenshots or write custom throwaway test scripts, you are wasting tokens.
At the time of writing, Twitter is abuzz with Luna at Max effort for coding, because it's cheap and the benchmarks show it can do impressive things at extreme reasoning levels.

In my experience, it does write passable code, but it takes a REALLY, REALLY long time to do it. The reviewer keeps any issue in check, but the coder is so slow that it's only an option if you're token poor and time rich, and are extremely patient.
Matt Pocock has an excellent grill-me skill you can use to generate the initial plan for a new feature. It will go to excruciating levels of detail and ask you all sorts of questions about the feature, which is great for getting a solid spec and stopping the LLM from guessing.

The results are in

This played out over two weeks, each week completing about half of the migration. I'm happy to report that the refactoring was completed successfully!

The first week was mostly spent trying various models and settings, carefully eyeing the usage bar on the Claude dashboard, panicking when I reached the limit on the 3rd day, using a bunch of extra credits (they would disappear on sept 1st anyway 😇), and then buying a ChatGPT Plus subscription to keep going.

The second week, my token usage was much more efficient considering the amount of work that was done, thankfully leaving me at both subscriptions not maxed out, and no extra credits purchased.

I've now replicated the same workflow on a different greenfield project, and it has allowed me to get a lot of work done quickly, while keeping a decent handle on the code quality, both in terms of maintainability and correctness.

An unexpected advantage of this approach vs my usual "single agent" workflow has been letting the agents run on their own, while I do other things. The main agent's context never gets too big since it's only a coordinator, and the subagents are by nature ephemeral, so they don't accumulate context either. This means that I can let the system run for hours without worrying about it running out of context or entering the "dumb zone".

Want to give my workflow a go?

I've put together a starter repo with the workflow files, feel free to fork it and adapt it to your own needs. The workflow is simple enough that you can use it with any codebase, and the subagents can be swapped out for different models or reasoning levels as you see fit.

I'd love to hear about what you build with it!

Vibelets: tiny, useful and private web apps

2026-08-06T00:00:00Z

I've added a new section to the homepage - Vibelets!

These are tiny applications that I had an LLM (Usually Claude) build for very specific tasks. The main idea is that they are small, single-task web apps that run entirely in the browser, and that I can trust to not send my data anywhere.

The classic example is the JSON to YML converter. I don't want to send sensitive json configuration out to some random website, I don't want my data to be stored in a database, or logged, or even worse, sold to advertisers and scammers.

Of course, the irony is that I am now hosting these apps here and asking you to trust me!

But at least this website is completely open source, and you can verify that it doesn't in fact have any nasty surprises ☺️

Email-webhook gets two security upgrades

2026-07-11T00:00:00Z

Email-webhook lets you receive emails straight into your own application via a webhook.

I've been chipping away at two security things lately, and they landed around the same time, so here they both are: mail delivered to your address is now encrypted in transit, and you can now sign outgoing webhook requests so your endpoint can check they really came from email-webhook.

Encrypted inbound mail (STARTTLS)

Previously, mail from a sending server to email-webhook crossed the network in plaintext, which, honestly, is how most email still travels today. I've turned on STARTTLS on the inbound SMTP server, and made it required rather than optional: every message to your @email-webhook.com address now has to arrive over an encrypted connection.

Basically every real mail provider already speaks TLS: Gmail, Outlook, Yahoo, Apple Mail, SES, SendGrid, Mailgun, Postmark, all of it. So you shouldn't notice a thing.

If you're forwarding from some old self-hosted box that never got TLS set up, that delivery will now fail.

Verify your webhooks with HMAC signatures

Until now, the only way to lock down your webhook endpoint was a custom header: an API key or bearer token you'd check on every request.

That works, but it comes with limitations: if it ever leaks into a log or a proxy, anyone who has it can replay it forever, and it says nothing about whether the body of the request is actually genuine.

So I added a stronger option: HMAC-SHA256 request signing.

How it works

Open any webhook's settings and you'll find a new Signing secret field. New webhooks get one generated automatically; clear it any time to turn signing off.

When a secret is set, every non-GET delivery includes two extra headers:

X-Timestamp: Unix timestamp (seconds) when the request was sent
X-Signature-256: hex-encoded HMAC-SHA256 signature

The signature is computed over {timestamp}.{body} using your secret as the HMAC key. The secret itself never travels over the wire, only a signature derived from it does, so a leaked signature is useless for any other request. There's nothing for an attacker to steal by inspecting a single delivery.

Why the timestamp matters

Folding the timestamp into the signed data buys you replay protection for free. If your server rejects any request whose X-Timestamp is older than a few minutes, then even if someone captures a genuine, correctly-signed request, replaying it later will fail the freshness check.

This is much simpler than tracking the x-email-webhook-id of every request to avoid replay attacks and storing them in a database, and it works even if your endpoint is stateless.

Read the full guide, including Node and Python examples of checking the HMAC signature, in the docs.

Rolling out safely

Signing is entirely opt-in: existing webhooks are untouched until you add a secret, so nothing changes for current integrations unless you choose it. GET webhooks aren't signed, since they carry their payload in the query string and there's no body to sign.

Encrypted inbound mail, by contrast, is on for everyone.

Overall

There's still more to do, of course. But these two changes are a big step forward for email-webhook.

Email is a very private medium, and my goal is for email-webhook to be a safe and secure way to receive it in your own applications. These two changes make it safer than ever before.

Encrypted in transit, end to end, from your mailbox to your endpoint.

New in email-webhook: new design, logs and a status page!

2026-05-11T00:00:00Z

Email-webhook the service I built to let you receive emails in your own applications, has been running smoothly for a while now.

But, as with any service, there are always things that can be improved.

The first thing you'll notice if you load the website is that it has a new design! I wanted to make it look more modern and clean, and I think I've achieved that:

But a fresh coat of paint is only the beginning!

Introducing opt-in logs

Imagine this: you're using email-webhook to receive emails in your application, and something goes wrong. Maybe the emails aren't being delivered, or maybe they're being delivered but your application isn't processing them correctly.

In the past, you would have no way of knowing what was going on. You would have to guess, and maybe even contact support to get some answers.

Now, with the new opt-in logs feature, you can see exactly what's going on with your email-webhook account. You can see when emails are being received, when they're being processed, and if there are any errors along the way.

Note: logs are opt-in, so you have to enable them in your webhook settings to start seeing them.

This is because logs can contain sensitive information, such as the sender address, and the subject of the email (we never log the body of the email or store attachments).

By making them opt-in, you have full control over your data and your privacy.

A status page to keep you informed

It's now easier than ever to keep track of the health of the email-webhook service. The new status page shows you the current status of the service, as well as any incidents or maintenance that might be happening.

It's located at status.email-webhook.com.

More to come!

This is just the beginning of a new era for email-webhook. I have many more features and improvements planned for the future, so stay tuned!

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!