DEV Community: Jan David

DEV x BOTS

Jan David — Mon, 08 Aug 2022 16:00:03 +0000

When I look back on the side projects that I started and abandoned over the past few years, and the notes and drawings that I added to my notebook, a clear pattern emerges. Some ideas got way more attention than others, and a handful actually came up again and again. I would spend a few weeks thinking about them, eventually putting them away, but a few months later they always returned.

In one way or another, these ideas were all focused on my experience as a software developer. As I was working on other projects, I always noticed things that could be easier or better. More efficient CI workflows, better local development environments, automation to help manage open source projects. Eventually, I would always get so fed up that I wanted to build a tool that would solve that problem for me.

A few times, I did start working on such a tool. But I never made a plan, set boundaries, or defined a goal. And as I got deeper into the problem space, I realized what else was possible. How this tool could be so much more than I initially thought. But as I enjoyed jumping from idea to idea, the scope of the projects grew in so many different directions that it would ultimately cause them to fail. I was more interested in intellectual stimulation than delivering something of value.

I don't know why and when, but this has changed recently. I feel like I did enough experimentation, and the next big thing for me to learn is to deliver and then operate a product. To talk with other developers and teams, and help them improve their workflows. This is the fundamental idea behind my new project, DEV x BOTS.

https://github.com/devxbots

Automatons – Automation for Developers

The focus of DEV x BOTS is the development of an automation platform for software developers called automatons. Looking back at my failed ideas and projects, they were all trying to automate various parts of the software development process. But building bespoke automation is time consuming work, and it really shouldn't be.

Learning from past mistakes, the project is set up to deliver small, concrete results that build on top of each other. While the ultimate goal is to deliver an automation platform, the first step is to create a library. Then I want to create a few custom GitHub Apps, finally building some of the ideas that have been floating around my notes for years. Any feature that the apps need will find its way back into the library, slowly growing its scope and usability. And the apps need to run somewhere, which means another deliverable is a runtime for them. The combination of library and runtime will be the minimum viable product.

I expect to learn a lot during this process, which will influence the future direction of the project. But in a nutshell, I want to broaden the feature set of the framework and move away from bespoke apps. Developers should be able to automate workflows that go beyond just GitHub, for example integrate their project management in Linear. And creating an automation shouldn't involve a custom GitHub App, but maybe just a configuration file in a repository. Which would be cool to create using a visual flow-based builder, similar to Blueprints in Unreal Engine.

All of this will take time to build, which is why there is a focus on small steps and iteration. Slowly working towards the minimum viable product, and then figuring out the necessary features for a simple, lovable & complete product.

Committed to Open Source

The automatons framework is developed as open source, and the goal is to (eventually) offer self-hosted runtimes so that teams can run the full stack themselves. Check out DEV x BOTS's GitHub profile and the project:

https://github.com/devxbots

Besides just being a fan of open source myself, I am doing this for three reasons:

Developers should be able to trust the tool. This means that they can inspect the source code and ensure that it is safe to run.
Developers should be able to rely on the tool. With open source, they will always be able to run the tool themselves, no matter what happens with me. There is no vendor lock-in, and less of a bus factor.
Developers should be able to contribute and solve their own problems. My priorities might not be your priorities. But with everything being open source, you can solve your problem and contribute the solution back to the community.

The commitment to open source also covers the usage of the platform. I will run an instance of the service that open source projects can use for free. But contributions to cover the development and server costs are greatly appreciated:

https://github.com/sponsors/jdno

Next Up

The next blog post will introduce the automatons framework itself, and the considerations that went into its design. We will look at its core library, and the prototype for an GitHub App that uses it. Until then, take care and have fun!

Auto Traffic Control – Version 0.2.0

Jan David — Sun, 17 Apr 2022 16:00:00 +0000

Revisiting 0.1.0

The previous version of the game, 0.1.0, was also its first release. This version was never released to the public, and only used internally for testing. It featured the first playable prototype of the game, but it was still missing many important features.

Version 0.1.0 had a single airport at the center of the map (green square), a routing grid, and planes (red squares) that spawned at random locations on the edge of the routing grid. The location of the airport was hard-coded, and my bot used simple Euclidean geometry to calculate a flight plan to the center of the map.

What's Changed

The most obvious change between version 0.1.0 and 0.2.0 are the graphics. The second release features simple sprites for the background, the airport, and the airplanes.

The game also introduced two different colors for airplanes and airports. Players have to route airplanes to the airport that matches their color to score a point. This made it easier to have more airplanes on the map, while avoiding congestion issues around the airport. And more airplanes make the game more dynamic and lively, which I believe will lead to more fun playing the game.

The introduction of two airports in different colors also required changes to the API. The map API in particular was extended significantly to allow players to query the map with the different airports and the routing grid.

Lastly, the release of the game is accompanied by a new website for the game. The website contains documentation on installing the game, its rules, and on its API with the different message types and services. A Quickstart guide is designed to help getting started with the game, although it is admittedly still very rough around the edges.

https://auto-traffic-control.com

Check out the full release notes for a comprehensive list of changes in this release: https://github.com/jdno/auto-traffic-control/releases/tag/v0.2.0

Plans for 0.3.0+

The focus for the next release of the game is the addition of a Node.js client library. This will make it easy to play the game in either JavaScript or TypeScript, or any other language with support for npm packages.

I also plan to improve the documentation with a tutorial for TypeScript. The tutorial will walk through the first steps in playing the game, from installation to first playthrough. This is a great test for the game's npm package, and it will make it easier for new players to get started.

After that the plans are a bit fuzzy. There are a few game mechanics that I'd like to implement, for example priority airplanes that have a fixed flight plan and that cannot be controlled by the player. I'd also like to experiment with different map features, e.g. cities over which airplanes are not allowed to fly. And the game needs a better UI, but how to build that is still a very big question mark. We'll see what to do after 0.3.0 is released...

Follow the Project

Check out Auto Traffic Control on itch.io:

https://jdno.itch.io/auto-traffic-control

If you're interesting in my game Auto Traffic Control or programming games in general, make sure to follow along. I am not sure where the road will take us, but I am very excited for the journey!

Subscribe to my blog to receive weekly updates about the progress on the project.

jdno.dev

I also stream some if not all of the development of this game on Twitch, so follow me there as well.

jdno_dev - Twitch

Automate Building and Publishing a Game on itch.io

Jan David — Sun, 10 Apr 2022 16:00:00 +0000

I really like automation in software development (and elsewhere). And since my personal projects are hosted on GitHub, I have fully adopted GitHub Actions as my continuous integration platform. When I push code, a handful of actions is started that lint the code, check its style, and run automated tests. When they all pass, it gives me confidence in the quality of my work.

For my upcoming game Auto Traffic Control, I wanted to use GitHub Actions again to create reproducible builds of the game with a predictable and consistent quality. The goal was to avoid human error by fully automating the process, from build to release on itch.io.

Create a New Action

I recommend creating a new action for this workflow. Especially if you want to build your game for multiple operating systems, the file will get pretty long as is. Go ahead and create a new YAML file in .github/workflows/itch.yml, and add the following content:

---
name: itch.io

env:
  itch_project: jdno/auto-traffic-control

Change the itch_project string to match your username on itch.io and the name of your project. If you like, you can also change the name of the action.

Trigger a Release

The setup that I have developed over the years for my GitHub Actions has one important feature: It has different actions for different workflows.

When I push code to GitHub, actions are started that check the quality of the code. These checks have to pass before I can merge the code into the main branch. Their purpose is to ensure a consistent code quality, not to create a release.

When I want to create a new release, I actually use the release feature on GitHub. I like writing a short summary of what's changed, and include a changelog in the release notes. It makes the release feel more "official", and like an actual achievement. When I create a release, another action is kicked off that builds the game in release mode, and then pushes the game to itch.io.

The following snippet is what I use to trigger my release workflow. It runs the action whenever a pre-release or release is published on GitHub:

"on":
  release:
    types:
      - prereleased
      - released

You can also build and publish the game every time code is merged into the default branch with a snippet like below. The choice is ultimately yours, and depends on what makes sense for your development workflow.

"on":
  push:

Build the Game

The build step depends on your game, and I cannot give you advice on it. The steps will look different based on the programming language or game engine that you use. On a high level, though, you want to do the following:

Check out the code
Set up a build environment
Compile the game

The following examples assume that you also copy the binary and any resources/assets that the game needs into a dist folder. This is the folder that will be pushed to itch.io. What needs to go into this folder again depends on the game engine that you are using.

I create builds of my game for Linux, macOS, and Windows. Each operating system requires slightly different dependencies, so I decided to split the build into three different jobs: one for each operating system. Below is the Linux build as an example. The job installs the dependencies, checks out the code, sets up the Rust toolchain, and then builds the game.

jobs:
  linux:
    name: Publish Linux build
    runs-on: ubuntu-latest

    steps:
      - name: Install system dependencies
        run: |
          sudo apt-get update && sudo apt-get install -y \
          libx11-dev \
          libasound2-dev \
          libudev-dev

      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Rust toolchain
        uses: actions-rs/toolchain@v1

      - name: Build release artifact
        uses: actions-rs/cargo@v1
        with:
          command: build
          args: --release

After these steps, the release artifact will be copied into the dist folder along with the assets that my game use. Theoretically, I can now run my game from this folder and it would work.

Publish to itch.io

The final step is publishing the game to itch.io. We will be using itch's butler, a tool that makes it easy to upload games to itch. This is the command to publish a new version of a game:

butler push directory user/game:channel --userversion version

The command takes a directory as its argument, and uploads the contents of this directory to itch.io. This will be our dist directory. The next argument is the project, which we've set at the beginning in the itch_project variable, followed by the channel.

Channels are an important concept on itch.io, and the channel name can be used to automatically tag the game on the platform. For example, pushing to the linux channel will tag the game as a Linux executable.

Lastly, we pass the optional userversion argument. The goal is to use the same version number on GitHub and on itch.io.

I am getting these variables from the release that I created on GitHub. When a release is published and the action is started, GitHub will add the release to the action's context. This makes it possible, for example, to access the title of the release with github.event.release.name (which is 0.1.0 for this release). If you want to run the action on every commit (i.e. on: [push] above), you need to either hard-code them or find another way to provide them dynamically.

      - name: Set version
        run: echo "version=${{ github.event.release.name }}" >> $GITHUB_ENV

      - name: Set beta channel
        if: github.event.action == 'prereleased'
        run: echo "itch_channel=linux-beta" >> $GITHUB_ENV

      - name: Set release channel
        if: github.event.action == 'released'
        run: echo "itch_channel=linux-stable" >> $GITHUB_ENV

I am particularly proud of finding a way to support pre-releases. When a release is tagged as a pre-release on GitHub, the game will be pushed to the beta channel. This makes it easy for me to test a new version of the game, before making it generally available.

Now that we have set the variables that are required to run butler, we can first add the tool to our workflow and then run it. Pushing a build to itch.io requires an API key, which you can find here.

      - name: Set up butler
        uses: jdno/setup-butler@v1

      - name: Publish game to itch.io
        run: |
          butler push dist ${{ env.itch_project }}:${{ env.itch_channel }} --userversion ${{ env.version }}
        env:
          BUTLER_API_KEY: ${{ secrets.ITCHIO_API_KEY }}

A new version of your game is now available on itch.io.

Profit

This is admittedly an advanced action with some pretty complex steps. Getting it to work correctly for your project might require a few iterations. It took me many builds to get this right. But the results are great, and totally worth the effort!

Most importantly, you now have a reproducible build. Getting your game ready for release is not a dark art anymore, nor does it require finding the note with the instructions somewhere on your desk. You can just look at the action to see which steps are required to build and then push the game.

Because the build is automated, it is also guaranteed to produce consistent results. Your local development environment cannot break the build or the game in mysterious ways, because the build environment is always clean.

And you know that everything that is required to build the game is backed up on GitHub. All code and all assets are safely stored in a second place, with a version history.

Follow me

If you're interesting in my game Auto Traffic Control or programming games in general, make sure to follow along. I am not sure where the road will take us, but I am very excited for the journey!

Subscribe to my blog to receive weekly updates about the progress on the project.

jdno.dev

I also stream some if not all of the development of this game on Twitch, so follow me there as well.

jdno_dev - Twitch

Designing an API for a Video Game

Jan David — Sun, 13 Mar 2022 17:00:00 +0000

I am working on a video game for programmers. The game is played by writing code that interacts with the game through an API. This post explores the design of the API that connects the player's code, the API layer, and the game simulation.

A Video Game for Programmers

I have been thinking about a video game for programmers for a while now. What differentiates such a game from others is that it is played by writing code. The player cannot interact with the game world themselves but only through an API. Essentially, they create a program that plays the game for them.

The time has come to make this dream a reality and build a working game. I am working on Auto Traffic Control (ATC), a game in which players have to safely route airplanes to an airport.

ATC as a Distributed System

Over the past two years, I experimented with different ideas for the API and the architecture of the game. One prototype had a REST interface, another tried to wire RPC calls into the core loop inside the game engine, and there were a few that explored various asynchronous interfaces such as message queues. But all of them eventually ran into problems, with a root cause that in hindsight is totally obvious:

At its core, the game that I want to build is a distributed system.

There are three components that are independent of each other: the player's code, the API layer, and the game simulation. The player's code runs in its own process and is totally decoupled from the game. But even the API layer and the game simulation are only loosely coupled, and run in parallel in different threads. The result is a system in which all components run concurrently, and any attempt to introduce tight coupling between them is bound to fail.

Event Sourcing and CQRS

The architecture for the game takes a lot of inspiration from Event Sourcing and CQRS. The player sends a command to the API, which validates it and then puts it into a queue. The different systems that power the simulation inside the game take commands from the queue, and make the corresponding change to the simulation. The change in turn triggers an event, which is send back to the API via another queue. The API receives the event, and sends it over a stream to the player.

The diagram above visualizes this architecture inside the game. The API on the left has different services that each manage a single resource. The event source streams events to the player, while the airplane service allows players to interact with the airplanes in the game. The API is coupled with the simulation on the right through two queues: the event bus and the command bus. The game is built with the game engine Bevy, which runs many systems in parallel to simulate the game. All systems are connected to the event bus so that they can publish any change they make to the game world. And systems that can be influenced by the player are connected to the command bus as well.

This architecture has worked really well in experiments, and I can't wait to see how well it'll work for a full game. Stay tuned to learn more about that in the future!

Follow the Project

If you're interesting in this game or programming games in general, make sure to follow along. I am not sure where the road will take us, but I am very excited for the journey!

Subscribe to my blog to receive weekly updates about the progress on the project.

jdno.dev

I also stream some if not all of the development of this game on Twitch, so follow me there as well.

jdno_dev - Twitch

Auto Traffic Control – A Video Game for Programmers

Jan David — Sun, 06 Mar 2022 17:00:00 +0000

Auto Traffic Control, fittingly abbreviated ATC, is my next project and a video game for programmers about safely routing planes to an airport. It takes inspiration from the old school hit Flight Control, and adapts its game mechanics for programming.

A Video Game for Programmers

I have thought, talked, and written about programming and video games a lot over the past two years. The intersection of the two is still super interesting to me, and I truly believe that we can make software development as a field more accessible by making it more fun. The following piece captures a lot of my thoughts on the topic:

Why I Want to Build a Video Game for Programmers

After quite some exploration and experimentation, I think that I have learned enough to make a serious attempt at developing a small video game for programmers. The next four weeks are all about going from idea to prototype, and testing the hypothesis that video games for programmers can be fun!

Inspired by Flight Control

One inspiration for the game is the old school hit Flight Control, which was one of my favorite games on mobile. I still have a lot of very fond memories of spending hours playing the game on an iPad, back in 2012.

In Flight Control, the player is in control of an airport and its surrounding area. Airplanes enter the map from the side and fly around randomly. The player has to create a path for each plane that brings it safely to the airport. When two planes collide, the game ends. When a plane reaches the airport, it lands and disappears, and the player gets a point.

Flight Control had a few more features that made the games more fun and/or challenging. Most maps features three different kinds of aircraft: small planes, bigger planes, and helicopters. They had different speeds, and had to be routed to different runways. There was changing wind that determined which runways were open, requiring the player to ever so often redraw all routes. And there were high priority planes, which followed a fixed route that the player couldn't change. Instead, players had to move their own aircraft out of the way in time.

Inspired by Sector 33

Another game that I played on the iPad back in the days was Sector 33. It featured a similar setting, but with different game mechanics. Players controlled airplanes approaching the San Francisco airport, and had to change their routes and speed to get them safely in a queue and then to the ground.

I don't have as many memories of playing Sector 33 as I have of Flight Control. What I do remember is doing a lot of quick math in my head to perfectly queue up the aircraft. It was very rewarding to get the timing right and have planes slot in perfectly after each other on their approach to SFO.

Plus, it was just cool to play a video game developed by NASA.

Made for Programmers

Auto Traffic Control takes inspiration from Flight Control and Sector 33, and remixes these games for programming. Instead of drawing on a screen, players create flight plans through an API. And algorithms replace mental arithmetics, hopefully leading to less mid-air collisions than what my 18-year-old me was responsible for.

The core game loop is similar to Flight Control. The map features one or more airports, and planes fly onto the map from the sides. The player has to provide a flight plan for each plane that lands it safely at the right airport. Landing a plane yields a point, while collisions end the game.

The difference to Flight Control and Sector 33 is in how the player interacts with the game. Instead of drawing on the screen or pressing a button, they will call an API to update the flight plan of a plane.

The above wireframe shows an early concept for the game's routing grid. Three planes are approaching the airport at the center of the map. Their flight plans, the black dotted lines, follow the routing grid from node to node. The API to update a flight plan might end up looking like this:

const flight_number = "AT-3245";
const flight_plan = [
    [-2, 0],
    [-1, 0],
    [0, 0]
];

game.update_flight_plan(flight_number, flight_plan);

Based on previous experiments, the API will be built around event sourcing and CQRS patterns. The game will publish events about anything that changes in the simulation, e.g. a new plane entering the map. And players can control the game through commands, which themselves lead to changes that will trigger events. This creates an asynchronous coupling between the game's simulation, the API, and the player's code.

Roadmap

The goal is to have a working prototype ready by the end of March. The first two weeks will be focused on technical implementation:

Develop a simulation that spawns, flies, and lands planes
Interact with the game through a bi-directional API

Once these two tasks are done, players can observe the game and change its state through the API. This makes it possible to focus on the core game loop, and experiment with different ideas to make it engaging.

At the end of the month, I want to know if a game like this is feasible and fun. If so, I might want to turn the prototype into a polished game next. If not, time to go back to the drawing board and figure out where things went wrong.

Follow the Project

If you're interesting in this game or programming games in general, make sure to follow along. I am not sure where the road will take us, but I am very excited for the journey!

Subscribe to my blog to receive weekly updates about the progress on the project.

jdno.dev

I am also planning to stream some if not all of the development of this game on Twitch, so follow me there as well.

jdno_dev - Twitch

And I'm on Twitter.

@jdno_dev

Four Weeks of Experiments

Jan David — Fri, 28 Jan 2022 14:00:00 +0000

At the beginning of 2022, I set the goal to experiment with different project ideas and technologies. I want to learn new things and build something, and after four weeks it is time to pause and reflect on the progress.

A Kind of New Year's Resolution

Around the beginning of the new year, I reflected on what I had done in the past year and what I wanted to do next. I felt like my growth as a software engineer had stagnated a bit. I was experimenting with Rust, either building small open source tools or trying to learn game development. At work, I was using a mix of Java, TypeScript, and mostly Bash scripts. But neither in my personal time nor at work did I feel like I was making much progress.

As a result, a goal for 2022 became to dedicate more time and focus to software development. Instead of only messing around with ideas, I want to push myself to actually "complete" one (assuming I can control the inevitable scope creep). I expect to learn from the process. Both in terms of "boring" work that I would typically try to avoid in my experiments, as well as in having something "in production" that I am solely responsible for.

But I started the year without a good idea what to do. There are a handful of projects that I have started, stopped, and restarted more often than I can count. My idea for a video game for programmers is one of those. But there are reasons why I eventually stopped working on them. Scope, feasibility, time and money. And I wasn't sure what kind of tech stack I wanted to explore. Stay with Rust, go back to backend development, or finally dive deep into React?

So I decided to just jump in and see where the road would lead me.

Building a GitHub App with Rust

Developer tools have always excited me. Maybe that is because I like solving my own problems. One idea that I have been coming back to many times is figuring out a better way to keep template files in sync on GitHub. A lot of configuration files in my projects are identical, and I tend to improve them as I learn more. Maybe most notably, my GitHub Actions are constantly evolving as the platform matures. When I make changes in repository A, I want those changes to also be applied to repository B that uses the same tech stack. This is a problem that can be solved with a GitHub App.

So I started the year working on this idea. I was set on using Rust for the project. It only requires a simple web server to interface with GitHub, and then a bunch of business logic to run through the actual workflow of syncing the files. I had just bought the book Zero to Production, and this was a great opportunity to implement its lessons. It was easy to get started, and the first few days were a lot of fun. I learned a ton by following the book, especially about areas like tracing and instrumentation that I wasn't yet familiar with.

But towards the end of the week, doubts started to creep up. For one, I was implementing a very narrow workflow. But it still required a lot of code just to get started. Interfacing with GitHub's webhook, GitHub's API, and the Git object model all introduced unforeseen complexities. Because I had to do all this work anyways, I started thinking of broadening the scope. In the end, I had a grandious idea of an automation engine that provides a flow-based, no-code environment to automate arbitrary workflows. Think Zapier but for developers. I really like the idea, but it is too ambitious for the time I have. And I didn't like the idea of investing that much time to build something that fully depends on someone else's platform, in this case GitHub.

You can read more about the first week in these devlogs:

Reflecting on this first week, I really liked the routine of journaling about the progress on the blog. Getting swept away by ever bigger dreams about an automation engine was fun as well. As was working with Rust. But the nagging feeling of building something that could become obsolete any day by a new feature of GitHub was frustrating.

Building a Desktop App with Rust

The second week is a logical consequence of the first, as it took what I liked about week 1 and does the opposite for the rest. Instead of aiming to build an overly complex and ambitious enterprise, it started with the goal to create a desktop app. A well-defined scope, no operational responsibility, and privacy-focused by keeping data on the user's device. Since it was still the beginning of the year, my goal was to build an app that helps users set goals. I wanted to solve my own problem again.

What I liked about week 1 was using Rust. And building a desktop app with Rust was a great excuse to check out two projects that I had been interested in for a long time:

Tauri is an alternative to Electron and creates desktop apps from web frontends
Yew is a framework to build web apps with Rust

The first two days were great and a lot of run again. I started with Yew, and really enjoyed playing with the framework. It takes a lot of inspiration from React, which feels quite intuitive. And it is still Rust, so you get all the benefits of the language. A strong type system, helpful compiler errors, and great developer tooling.

use yew::prelude::*;

use crate::components::page::{PageContent, PageHeader};

pub struct Dashboard {}

impl Component for Dashboard {
    type Message = ();
    type Properties = ();

    fn create(_ctx: &Context<Self>) -> Self {
        Self {}
    }

    fn view(&self, _ctx: &Context<Self>) -> Html {
        html! {
            <div id="dashboard">
                <PageHeader text="Dashboard" />
                <PageContent>
                    { "This is the dashboard's content." }
                </PageContent>
            </div>
        }
    }
}

But figuring out how to adept Yew for a desktop app and make it work well with Tauri was a bit too much for me. Tauri does not have a Rust SDK, and officially only supports Node apps. And Yew is designed for the browser, not a Node runtime. So I got stuck trying to figure out a way to access the local file system so that I could save the user's data.

I tried to work around this by embedding a web server in the Tauri app. The idea was to run a local web server that the web frontend could interact with, thus avoiding the need to access the file system from Yew. This approach also allowed me to go back to Zero to Production and build a web server. But it made things way too complicated. It also didn't help that I wanted to use GraphQL. In the end, I had thousands of lines of boilerplate code just to get a simple form saved.

Building a desktop app with Tauri and Yew just didn't feel feasible at this point in time. At least not with the knowledge that I had about both projects. And going back to my goals for 2022, I didn't feel that the experimentation I was doing was aligned with the goal of shipping something to production.

Ironically, a week later a blog post about building desktop apps with Tauri and Yew got published. It answered the questions that I had, and showed how to get past the problems that I was experiencing. But at that point I had already moved on.

Building a (Deskop|Web) App with Next.js

The next iteration was an attempt to replace Yew with Next.js. Next.js is a framework that I always wanted to try out, and it seemed logical at first to switch from Rust to Node. I would still be using a component-based framework, but with better support for Tauri.

I quickly remembered why I didn't like working with the Node ecosystem. Getting started with Next.js was easy, but soon enough I ran into the first problems. The testing framework didn't play nicely with the way that assets got imported. Tauri's NPM package wasn't compatible with the default Webpack setup (due to the use of ES modules). I probably spent more time debugging these issues than writing code.

More fundamentally, however, I realized that Next.js is not the right framework for desktop apps. It is designed for web applications, offering features such as server-side rendering and a way to build APIs. I am truly impressed by the framework, but it simply wasn't the right tool for the job.

I switched to React next, and spend a day or two experimenting with that approach. But when it came to saving data, I still ran into the build issues with Tauri and the question how to interact with the file system. I was ready to abandon the idea of building a desktop app. If I were to build a web app, I could use Next.js again. But how would I store data? Privacy is important to me, and I didn't want to just throw everything into Firebase or any other backend-as-a-service.

So I not only abandoned the idea of building a desktop app, I also abandoned the idea of using a frontend framework for the job.

In hindsight, this was probably the most frustrating experience of the month. I always have high hopes when I start working with TypeScript. But every time there are issues. Compared to the developer experience that I have with Rust or before that Ruby, I simply feel unproductive and mostly fighting the tools. Maybe that would change after a while, but I never get to the point because it's just too annoying.

Building a Web App with Rails

In a past life, I worked as a Ruby on Rails developer. I love the framework and the productivity it enables. And in December 2021, Rails 7 was released with a bunch of exciting new features. Hotwire is now the default solution for frontend development, combining the responsiveness of single-page applications with the benefits of server-side rendering. And Active Record Encryption makes it easy to protect sensitive data in an application. It checked all the requirements that I had after experimenting with React and TypeScript.

So in week 4–this week–I spun up a new development environment for a Rails app. The goal was still to build a tool for personal goal setting. But a web app enabled a few exciting features that would've been very difficult to add to a desktop app. The app can send notifications much easier, for example when a user hasn't updated their progress in a while. It is also possible to access the app from different devices, allowing users to check in whenever they want.

Progress during the week was slow, though. Other things required my attention, and I wasn't able to focus much on the project. I was also reminded of why I wanted to build a desktop app in the first place. Storing the user's data on the central server requires so much thought about security, privacy, and current regulations. I am not yet convinced that this is the direction that I want to take.

Reflecting on Four Experiments

In four weeks, I tried four different approaches of building a product. It started with a web service, radically pivoted to a desktop app, and from there evolved to the point where it became a web app again.

More than anything else, I am frustrated with my progress. At the beginning of the month, I thought that I would be working on one idea the whole time. And I expected to have a prototype in production after four weeks. But I feel very far away from that goal right now.

I am happy with the experimentation, though. The automation engine wasn't a good idea to pursue. It was too complex, too ambitious, and it would've taken months to get even a prototype out of the door. But I like the idea of the personal goal setting app, because I am passionate about the topic and it is very well scoped. Without experimentation, I wouldn't have ended up here.

I also have to acknowledge that I didn't know enough about building desktop apps at the beginning of the month. Only by trying and failing did I start to dig deeper into the topic. After I finish this post, I will spend the rest of the day reading the paper Local-first software about "a set of principles for software that enables both collaboration and ownership for users". Maybe that will change my goals for next month again, but I will have learned about an interesting new idea no matter what happens.

So I shouldn't feel frustrated with the progress. I did learn a lot and got to try a a bunch of frameworks that were on my to-do-list.

Process Over Outcome

I actually start to think that I am not frustrated with the outcome, but with my process during the month.

A goal of mine was to establish a routine, and I definitely failed to do that. As mentioned in the beginning for example, I really liked writing short(er) blog posts that reflected on the day. But I stopped doing that after the first week. I also wanted to relaunch my podcast, which I haven't done yet. And I wanted to try live-coding on Twitch, which also didn't happen. I set out with an idea for how I want to work, and I failed to follow through on that.

So looking forward to the next months, I want to focus on the process more than on the outcomes.

One aspect of that is certainly to set intentions again. I want to set a goal for the week and then for each day, and check that I am on track towards those goals. Writing a short blog post at the beginning in the morning was definitely helpful in establishing a goal for that day. But it is also a lot of overhead, so I'll have to experiment and see what formats works. Maybe setting the goal is better done by creating tasks in OmniFocus, and then reflecting on the week in a blog post just like this one. I am also considering adopting the Shape Up methodology to plan a week ahead and then focus on execution during the week. I will have to experiment with this and see what works best for me.

This blog post is now a reflection of the whole month, and I feel that time is too long. A weekly or bi-weekly interval would be better suited to spot trends and react in time. There were multiple moments where I could've stopped and reflected on how things were going during the past month. That would've allowed me to react earlier, and possible avoid the feeling of frustration that I feel now.

A week as a unit for planning and reflection, and then days with a certain routine feel like the most promising approach. I do have to be mindful of my other responsibilities, though. I can make plans for my side project, but there will be days were I just won't have the time to work on it.

So let's try to enjoy the process and focus less on outcomes.

Day 4 – Adding Tech Debt

Jan David — Thu, 06 Jan 2022 22:00:00 +0000

Yesterday, I was following along with the book Zero to Production to set up a web server in Rust. Today, I went rogue and added a background job system. All code quality metrics have dropped as a result. 😅

Queuing Work for Later

When I was working as a Ruby on Rails developer a few years ago, it was common practice to queue jobs for later. The motivation for this was simple: Keep the HTTP request cycle as short as possible. Complex tasks and work that could be done asynchronously was pushed into a job queue. One reasons for this was that it improved the user experience. Another that Sidekiq, the background job system, was just so good and reliable. And when a job failed due to a bug, it was possible to fix the bug and try again.

Maybe it is a premature optimization, but I am approaching my current project in the same way. Incoming webhooks get serialized and pushed into a queue for later processing. A background worker dequeues the events and checks if more work needs to be done. If so, it can either create more jobs in the queue or perform the work itself.

The reason that I like this design is that it creates flexibility and resiliency. First of all, the background worker does not have any time constraints. If the web server were to perform the work, the HTTP request might time out while it was busy. This makes it possible to choose less performant, but more maintainable algorithms. For example, work can be done in sequence instead of in parallel. This avoid a while group of concurrency issues that can occur when parallelizing data access. Second, if something fails it can easily be retried. This is particularly useful if the work requires interfacing with third-party systems. These systems might be unavailable, in which case the job can simply be retried at a later time. And sometimes we make mistakes. When a job fails due to a bug, it is still in the queue. A developer can fix the bug, deploy a new version of the application, and the job can succeed.

The downside of this approach is of course that it requires a background job system and a worker. Thus more moving pieces and more orchestration. But I have had great experiences with Sidekiq, and I am sure that its polyglot brother Faktory will work just as well.

Decreasing Code Quality

When I was working on the web server yesterday, I had the advantage of following along with the book Zero to Production by Luca Palmieri. The book provided a reference implementation for many common patterns, for example integration tests and obversability. As someone who is building their first web application in Rust, I appreciate the guidance.

Today, I went off the beaten path to set up the background job system. This had two particular challenges:

Finding the right abstraction for the background jobs
Mocking the job system in integration tests

I probably spent most of my time dabbling with the interface between the web server and the background worker. The simplest solution would have been to throw the whole webhook into the queue. The benefit of this approach would have been that it kept the web server very simple. But it would have forced the background worker to know implementation details about GitHub's webhooks. This felt like tech debt to me.

So instead, the web server deserializes the incoming webhook and extracts the necessary information from it. It creates an Event object and pushes it into the queue. This keeps the implementation details of GitHub's webhook events in a single place. And it makes it easier to support other platforms in the future, since the core library does not need to be changed for that. Instead, it is enough to add a new endpoint that can deserialize–for example–GitLab's webhooks.

The code is still a mess. There is considerable overlap between the core library and the web server. A quick search reveals that there are roughly 8-12 types that deal with pull request events. There is the PullRequestWebhook from GitHub, and then the PullRequestEvent that is used internally. Both have similar, but still different fields. While I don't like the duplication, changing the internal types to work with GitHub's data structures felt even more wrong.

My hope is that this will improve over time and as I become more proficient with Rust and GitHub's API. Right now, I have only implemented a single event type. Once there are more, patterns might start to emerge that make it obvious how to clean up the code. But the code works, and that is the most important thing for today.

Next Steps

The next step is obviously to create the background worker. But this will have to wait until next week. The routine that I am trying in January is to work four days on the code itself. The fifth day will be spent on shaping the next week. I also want to start recording my personal podcast again, and leave time to write technical blog posts. My hypothesis is that a day of reflecting and planning will make the other four days much more productive and valuable.

If you are interested, here is the first episode from my podcast, recorded last year. You can subscribe to it on iTunes, Spotify, Overcast, and pretty much everywhere else.

Day 3 – Productive Procrastination

Jan David — Wed, 05 Jan 2022 21:00:00 +0000

After two days of mostly theoretical work, I felt like writing some code today. So I got my copy of the book Zero to Production and worked on the app's web server. As a result, the project is built with Rust now...

Subscribing to Events from GitHub

I wrote about what a minimum viable product for this project would look like in yesterday's post. One of the features that it needs is the ability to receive events from code hosting providers like GitHub. This feature has a simple and a complicated part.

The simple part is how platforms like GitHub deliver these events. Whenever something happens on GitHub, a webhook event is sent to any app that is subscribed to it. In the case of GitHub, this is done for (almost) literally everything. The webhook is sent to a pre-configured URL, which means the app needs a web server that can receive them.

The complicated part is figuring out what to do with the event. For this project, it means figuring out if any workflows need to run. This requires reading the user's configuration, which has been a topic of yesterday's post as well. Not much has changed since then, and how the configuration will look has yet to be decided.

So I decided to focus on the simple part that is clearly scoped for today.

Zero to Production

Last year, I bought a copy of the book Zero to Production by Luca Palmieri. It describes how to build a production-grade backend server with Rust. Back then I was working on a similar–albeit more limited–idea, and read through the first chapter as I was experimenting with the idea. I learned a lot from it, and always wanted to finish the book. As luck would have it, an update just dropped and I picked up the latest version and got started...

The book uses an iterative approach to introduce new topics. You start by setting up the web framework. Then you add integration tests, and after that a database. Each chapter builds on the previous one, and there is a strong focus on having something working after each step.

+2,532 −1

After working through the first four chapters of the book, I reached a good stopping point for today. I have a web server now that can receive webhooks from GitHub. The server verifies the authenticity of the webhooks by checking their cryptographic signature. Everything is tested with integration tests. And instrumentation is in place to monitor the server once it gets deployed. A lot of code was added today.

The next step is putting the events in a queue so that they can be processed in the background. This requires figuring out what data is later needed to process the events. And it needs setting up a background job system.

When I worked as a Ruby on Rails developer in the past, I always had great experiences with Sidekiq. It was so good that it became second nature to throw everything that didn't need to be synchronous into a queue and process it in the background. Luckily, Faktory exists as a "polyglot version of Sidekiq" (don't @ me).

My goal for tomorrow is to integrate Faktory into the app, and throw incoming webhooks into a queue. A background worker can then pick them up and figure out what to do for the event. This last step will require figuring out how to store configuration, but that's a problem for another day...

Day 3 was fun, let's continue tomorrow!

Day 2 – Exploring an Idea

Jan David — Tue, 04 Jan 2022 14:00:00 +0000

Yesterday, I brainstormed ideas for a project that I can build in a few weeks. Today, I am exploring one of those ideas in more depth. The goal is to develop a better understanding of the product and its constraints.

Automation for Git Repositories

When I look at my own (open source) work, how I use Git repositories has changed dramatically over the past two years.

In the past, a repository was simply a place for source code. It was one of many tools used to organize a project. But with GitHub, more and more functionality moved into a central place. Now a repository is also the home of issues, discussions, and even the project's website.

Additionally, configuration-as-code has been a growing trend. And these configurations have moved into the repository as well. Pipelines for continuous integration. Deployment configurations for Heroku or other platforms. Configuration for a wide variety of bots that automate development tasks.

What I find myself with is thus a growing number of repositories, each with more and more configuration files. As someone who values consistency and a great developer experience, I want these to be up-to-date. When I learn how to improve my CI in one project, I want to update every other project as well.

I started to think about this problem as templates that I want to keep up-to-date. But while toying with the idea, I noticed that this is actually just a concrete implementation of a generic algorithm. What I really want is to take an action based on a trigger. So when a file is updated in one repository (the trigger), I want to copy it to another (the action). Some actions I only want to perform sometimes, which I can control through a condition. For example, only perform the action when the default branch is updated.

What I want to build over the next few weeks is a service that can do that.

Features of a Prototype

Given that time is limited, I want to be strategic in the design and implementation of the product. There are a lot of things that I can do, but what is it that I need to do?

For a functional product, at least the following features must work:

Allow users to configure workflows
Subscribe to events from platforms like GitHub
Execute workflows when their conditions are met

Each of these have varying levels of complexity based on the implementation. For example, it would be great to have a graphical user interface to configure the workflow. But then again, it is also possible to define the workflow in a configuration file. The latter can be build in much less time, and is thus probably a better solution for this stage.

Besides these functional requirements, there are also non-functional requirements. One category of those are restrictions and recommendations imposed by the platforms. GitHub, for example, provides a few best practices with its Probot framework. One of them is to keep the configuration as code in the repository whenever possible. These also need to be considered when designing the features.

Features of a Future Product

While I am limited in what I can build now, I still want to consider what the product could look like in the far future. I have to be careful not to fall into the trap of premature optimization, though. I want the vision to guide my design, without forcing me into a product that is too complex for the current moment.

In yesterday's post, I mentioned that I see two long-term futures for this project. The first is open sourcing the project once I am done or running out of time. The second is offering the product as a service so that I can learn more about business as well. While there are some differences, they share a lot of common features.

Self-hosting

Allowing the users to run the software themselves is an important feature for both an open source or a commercial product. Given the nature of the tool, it requires far-reaching access to source code. This might be an acceptable risk for open source or side projects. But others might want to run the software themselves to ensure only they have access to their code.

Self-hosting limits how the application can be built. A monolith is better than a complex microservice architecture. A widely available database like PostgreSQL better than vendor-dependent solutions like DynamoDB. Both make it easier for someone else to pick up the product and deploy it to their own infrastructure.

Graphical User Interface

A graphical user interface can greatly improve the configuration of the software. It shortens the feedback loop, and can highlight information when it is relevant to the user. For example, validations can catch mistakes in real-time. The user no longer has to wait for the software to run and report an issue. And the UI can surface features that the user might not even know existed.

A UI also makes it possible to manage workflows across repositories. Instead of having to copy configuration files, a user can simply click a button to add or remove a workflow from a repository. When viewing a workflow, a user can quickly see where it is being used. This is especially valuable for larger organizations with many repositories.

Custom Scripts

Triggers, conditions, and actions will probably be hard-coded in the first version of the product. Users can combine them in workflows, but they cannot define their own. This should be fine for most projects, but power users will run into limitations. Since this is a product for developers, it is only logical to allow them to create their own actions.

How to execute custom code in a safe and responsible way, I don't know. This makes this a feature for later.

Conclusion

Most of the requirements and constraints don't matter for the technical architecture. The idea is generic enough that it can be implemented with any web framework, be it in Ruby, Rust, or Node. Some things will be easier in one tool compared to the others, but overall it balances out.

To me, the biggest challenge is building a secure product that follows the platform guidelines.

On GitHub, for example, it is convention to have the configuration as code in the repository. This works well for workflows that only touch a single repository. But what about organization-wide automation? Where does their configuration go?

Another concern is honoring access controls. A company might use code reviews to enforce the four-eyes principle. What does this mean for workflows that are created outside of GitHub or GitLab? Do they need to be reviewed as well? Does every execution of a workflow need to be reviewed?

These are far more challenging questions than the technical implementation. These kinds of questions are probably the reason we have so much configuration-as-code now. Adding a workflow to the configuration file automatically follows the same process as any other code change.

Goals for Today

I will be spending the rest of the day thinking about the questions above. Configuration-as-code seems like absolutely the right path for a variety of reasons. But the whole project was started because managing files across repositories is painful. So how would a good user experience look like?

There are two ideas specifically that I want to explore. The first is centralizing the configuration somewhere, for example in a dedicated repository. The other using the automation I am building to also manage the configuration.

Day 2 will be a tough one.

Day 1 – An Empty Source File

Jan David — Mon, 03 Jan 2022 12:00:00 +0000

The new year is here and I have some time to experiment. It has been a while since I had the opportunity to explore new technologies and build something. I have a few ideas what to do and what to learn, but I still need to figure out the details.

Criteria for a New Project

I have been thinking a lot about the problems that excite me while brainstorming what I want to build. As a software developer, I like building products for other developers. It's a space I know well, and I enjoy designing good developer experiences.

A topic that has interested me for years, but which I haven't pursued in a while, is entrepreneurship. As I am thinking about problems, I want to make sure that any solution has the potential to be monetized. This would allow me to learn some totally new skills, and help me maintain the project for a longer time. Maybe even full-time. 🤞

On a technical level, I am excited about Rust and I want to learn React. I have worked mostly as a backend and DevOps developer, and am interested in practicing frontend development. As a former Rails developer, I am also very curious about the changes that landed in Rails 6 and 7.

The biggest challenge for me is keeping the scope small. The ideas I have tend to grow into very ambitious projects that would need months of not years to fully realize. I often lose interest in the projects before they are finished, because it takes too long to see any value. I have zero doubts that I will make the same mistake again, though.

Three Project Ideas

In the past years, I have been exploring three different ideas with varying degrees of success. But I have been coming back to all of them, because there is something about them that intrigues me.

Automation for Git Repositories

An idea that I have been working on one-and-off for a while now is automating certain tasks in a Git repository. Specifically, I want an easy way to maintain templates for configuration files, CI workflows, and other developer tooling. Whenever I update one of them, I want the file to be updated in all repositories automatically.

There is some prior art that implements this on GitHub using Actions, but copying files between repositories with Actions feels awkward for various reasons. A GitHub App would provide a much better user experience.

I am doubtful that this feature alone would be enough for a convincing value proposition. But while playing with the idea, I noticed that it is possible to abstract it into a more general concept. What I want to do is catch a trigger (a file has been updated), check one or more conditions (on the default branch?), and then perform an action (copy the file to another repository). This loop of trigger, condition, and action can be used for other workflows as well. For example, auto-merging pull requests or closing issues when certain conditions are met.

Desktop App for File Management

Every year I have to file taxes, and every year I am missing some documents that I need to do so. And I have some anxiety that I am not archiving important documents for the future. Who knows what I need to have ready in 60 years to get my pension?

The second idea is thus an app that helps organize files on the local machine. The idea is quite simple: A directory is a library with many indicies. When a document is added to the library, it is copied into an archive and then linked into every index. Each index has rules that organize the documents in it. For example, one index might sort files by year and another by file type. This might look like this:

library
├── .archive
│   └── day-1.md
├── by type
│   └── md
│       └── day-1.md
└── by year
    └── 2022
        └── day-1.md

This is a project that is ideally suited for a CLI in Rust, maybe with a React-based desktop app that calls either the CLI or a shared library.

There are also some interesting features that could help users manage their files. For example, identifying documents that are added on a regular cadence such as payslips, and warning the user if any are missing. But even with such features, I am again very doubtful about the value proposition and the ability to monetizate the app.

Videogame for Programmers

I have been writing about this idea a bunch last year, but none of my experiments came to fruition yet. Either the scope was too big, the architecture too complex, or probably both.

It is again a simple idea: I like programming, but miss more engaging ways to learn new concepts or programming languages. I don't like doing courses, because they are often aimed at beginners (I don't need yet another introduction to variables and functions). At the same time, I also enjoy videogames and admire the feedback loops they have. Putting both together, I think it could be great fun to have sandbox-style games with which players can practice programming.

What has been challenging in the past is creating a nice API for players that integrates well with the engine running the game. As a novice to game development, there are just too many unknowns to hit the nail on the head on the first try. I would have to build a few small games to learn, but those cannot be monetized. Even worse, the market is very saturated and monetizing games is difficult enough as it is.

Others

There are more ideas that I thought about or for which I registered domains and created repositories. But many of them are related to one of the three projects above, and can only be great if they are extracted from them.

For example, a GitHub Action that can easily be customized to validate configuration files. I want to have this functionality every time that I think about creating either a GitHub Action or a GitHub App. But without having something in production to validate the value proposition, it is way too easy to build something that doesn't solve an actual issue.

Conclusion

I am leaning towards working on the Git automation idea. I know the problem from first-hand experience, and am fairly confident in the proposed solution. And judging by the amount of GitHub Actions in the marketplace that automate workflows, I am confident that this is a valuable problem to solve.

The runner-up is the video game for programmers. It is a passion project of mine, and I would love for it to exist. But I am afraid that my ambition far exceeds my skills, and that is is not possible for me to make meaningful progress in the time that I have.

Goals for Today

The task for the rest of the day is to scope the automation project. The goal is to develop a rough plan for both the technical implementation and the project milestones, and look for any red flags or unknowns that could stop the project. I also want to think about the long-term vision for the project, since it will impact some of the technology decisions.

At the end of the day, I want to have an initial draft for the architecture of the app and a rough outline of the milestones for the coming days.

Day 1, let's go! See you again on day 2.

godot-logger – A Rust Logger for Godot

Jan David — Wed, 20 Oct 2021 19:30:00 +0000

godot-logger is a crate that complements the godot-rust bindings for Godot, and prints logs to Godot's output console using the godot_print! and godot_warn! macros. It is available as open source on GitHub.

Introduction

Godot is an open source game engine with a powerful editor, tools to debug and profile the game, and support for many different programming langauges. Building games with Rust is possible thanks to the godot-rust library, which provides bindings to Godot's API as well as a few convenience methods.

One of the debugging tools inside Godot is the output console. It prints information about the execution of the game, as well as log messages that have been placed in the code.

godot-rust provides two macros to write to the output console: godot_print! and godot_warn!. These can be called anywhere in the code, and will print the given message to the console.

The problem that I encountered while working on my game was that these macros do not capture logs from third-party Rust libraries. It is very common for libraries in Rust to use the log crate and its logging facade to define log statements in their code. These messages can then be printing by initializing a logger such as env_logger or log4rs. I wanted to see what the libraries in my project were doing, and I wanted to see the logs inside Godot's editor where I was running the game. After searching for an existing library and coming up empty, I decided to implement a logger myself that would print to Godot's output console.

Usage

godot-logger is very similar to popular logging frameworks such as env_logger or log4rs. It integrates with the logging facade of the log crate, and prints log statements to Godot's output console.

The simplest way to use godot-logger is to add it and the log crate as dependencies to your project's Cargo.toml:

[dependencies]
godot-logger = "1.0"
log = "0.4

Then configure and initialize the logger in the same method that is passed to godot_init!.

use gdnative::prelude::*;
use godot_logger::GodotLogger;
use log::{Level, LevelFilter};

fn init(handle: InitHandle) {
    GodotLogger::builder()
        .default_log_level(Level::Info)
        .add_filter("godot_logger", LevelFilter::Debug)
        .init();
    log::debug!("Initialized the logger");
}

godot_init!(init);

The example shows the configuration options that godot-logger provides:

The default log level of GodotLogger is Level::Warn, but this can be changed with default_log_level.
Module-specific log levels that take precedence over the default log level can be set by adding filters to the logger. A filter combines a module path and a level filter, which makes it possible to very granularly control what gets logged.

The example above will print the following line to the console:

2021-10-20 20:00:00 DEBUG godot_logger Initialized the logger

Below is a screenshot from my own project, which runs an embedded server built with Bevy and has its code split across a few different crates ( aomos namespace). As you can see, log statements in these libraries are picked up and printed inside Godot.

Contributing

godot-logger is published as an open source project on GitHub, and bug reports are always welcome.

Hacktoberfest '21

Jan David — Sat, 02 Oct 2021 14:26:23 +0000

Hacktoberfest is an annual event in October that celebrates open source and encourages participation in the open source community. For me, it is the third time participating and I have some big plans for this year.

The Theme

I have spent a lot of time over the last year or so thinking about the intersection of learning, programming, and gaming. More than a year ago I wrote the following piece on the topic, and my thinking has not changed much since:

Why I Want to Build a Video Game for Programmers

In the year that followed, I experimented with technologies and interfaces to test a few hypotheses. I hacked around with Bevy, a new game engine written entirely in Rust. I took my first steps with Godot, and embedded a simulation written in Rust inside it. But the experiments have not yet led to an actual game, and I am not closer to original goal...

The Goal

So the goal for October is to take what I learned in my experiments and start working on an actual videogame for programmers. This is not a project that will be finished in a month, but in four weeks I want to have something that can at least be called playable.

Concretely, I want to create the foundation for the videogame and implement a first game mechanic to prove the concept. It sounds simple, but requires me to shift from a prototyping to a product mindset and actually deliver something.

The foundation that I refer to is everything that is required to work on the game. Code bases for the game's logic and the API layer, repositories on GitHub, continuous integration, and automation for common tasks to save myself time. I have written in the past about how I set up certain parts of my tooling (e.g. Fully Automated Dependency Upgrades with Dependabot and GitHub Actions), and I want to write one or two more articles in October about this topic.

The game itself is something that will not fit into a single month. Truth be told, the vision that I hold in my head will require years of dedicated effort to implement a universe full of possibilities. But leaning into agile development practices, every cycle of work should produce a runnable product. And so should October...

The Plan

A month sounds like a lot of time, but between my work and social life there is only so much time left to work on open source. So a plan is needed to use the time that I have in the most effective way possible. Roughly said, this is how I want the next four weeks to look.

Week 1 – Foundation

Building the foundation is the first step. I can cut some corners here and leverage work that I have previously done in my experiments. But I do need to think about a few questions without apparent right-or-wrong-answers. What architecture should the game have? What game engine best supports this architecture?

Answering these questions is a daunting task, because they have the potential to set and restrict the long-term strategy for the game's development. But given my previous attempts, chances are high that this project will not live long enough for these decisions to be a problem. So let's just make them and move on...

Week 2 – Game Mechanic

The second week is dedicated to the development of the first game mechanic. I already have an idea in mind, and pages upon pages of notes and drawings in my notebook. So the challenge will be translating the idea into code.

Week 3 – Developer Experience

An hypothesis concerning the success of the game is that developer experience matters: If programmers can get started easily and find the resources they need to be successful in the game, they will like the game and play it. To test this, the third week is all about creating a good developer experience. A starter template for Node.js, good documentation, and a place to connect with the community.

Week 4 – Validation

The last week is less about coding, and more about exploring the mid-term future of the project. With a very rough but playable proof-of-concept in hand, what does the community think about the project? Is there interest to see this project continue? And if so, can I validate that it would be commercially viable for me to dedicate more time to it?

The Deliverables

At the end of October, I want to have achieved the following:

Take the videogame for programmers from idea to prototype. Release a small, playable version that demonstrates what can be possible...
Validate the idea and answer the question whether it makes sense to invest more time into this project.
Write more. So many ideas are only partially developed in my head and notebook, and I want to take time to put them into a coherent form and explore them on this blog.

I hope that putting these on paper creates the accountability I need to really follow through with them. The first day of October is already gone, 29 more days to go. Let's get started...