Web Development
Learning through development tools
Today, during a major debugging session with a Rails application, I wanted to condense what was in the logs between two consecutive requests to understand what was happening. It was too much to read through everything. I just needed to scan through all these requests and flag whether they were successful or not.
So today, rather than scribbling down another Ruby script, which would have been easy, I started a log analyser using Rust. It’s early days for the script, but it already compiles a list of endpoints, which is a good start.
It’s a reminder to myself that there are plenty of development tools and aids I can build using a variety of languages and frameworks. And if I only use that tool a few times, that’s okay, too. At least I will have learned something.
It’s a quiet morning with some code and coffee. I am working through an issue with a product of mine using forms, Rails, and Sidekiq. I’m happy to put the time into this over the weekend, as it’s a core part of the product and will be reused heavily in the future.
Zed, the free and open-source text editor, has announced the addition of a debugger to its text editor.
I forgot how great the chatbots are in Basecamp. They can respond to commads and can communicate from outside apps.
I see they also allow the ability to use different formatting in their message content. That’s the next thing I think I will try and do. Nicely formatted chatbot messages.
I found myself locked out of a recent GitLab free account I created for a specific purpose. Frustratingly, I have yet to be informed why my account was closed, and there has been no communication from GitLab. I’ve since recreated everything in GitHub. To be locked out without any communication is poor.
Web development like it's 2009
I am in favour of Simon Willison’s “no build frontend” web development approach.
If you’ve found web development frustrating over the past 5-10 years, here’s something that has worked great for me: give yourself permission to avoid any form of frontend build system (so no npm / React / TypeScript / JSX / Babel / Vite / Tailwind etc) and code in HTML and JavaScript like it’s 2009.
I’ve been building Writeabout in Sinatra, and I’ve reached the point where I need to add a bit of JavaScript to allow the changing of the light, dark, and system themes. I already have these implemented in the original Rails code as Stimulus controllers, but I’m sure it won’t be too much work to rewrite them as plain old JavaScript.
I don’t have a favourable opinion of frontend web development. I’ve always found it unnecessarily complicated and constantly changing, but rarely for the better. For the last few years, I’ve used TailwindCSS because its build step in Rails applications is minimal—the productivity gains outweigh the added complexity. Beyond small learning projects, I’ve resisted adopting anything like React or TypeScript.
That’s the 2nd time in a matter of weeks I’ve used a YAML file as a data source instead of going to straight to creating a table in the database.
The YAML file bridges that gap nicely of not needing the database quite yet, but we do need to store some structured data.
That’s pretty much most of my repositories moved from GitHub to sourcehut.
Writeabout is still on GitHub but is undergoing a Sinatra rewrite. Once that’s complete, I’ll mark the one on GitHub as archived and publicise the new one on Sourcehut.
More of my projects will gradually appear on sourcehut.
Finding the Right Git Platform for Personal Projects
I migrated one of my two GitHub accounts to GitLab a few weeks ago. The move itself had nothing to do with missing features or pricing. It was primarily to try out something else that wasn’t GitHub.
At my job, I spend most of my days on GitHub. When working on my little projects, stepping back into GitHub feels like I am back at work again. With the lines blurring between work and personal coding, I started to think that when I spent time coding on my projects, it still felt like “work”.
So, for one GitHub account, I migrated that account to GitLab. It’s been a great move, and despite being on GitLab’s free tier, I can still match feature for feature what I was paying GitHub for. And when it comes to working with that account, I don’t feel like I am back at my desk.
After the move, I considered moving my other private repositories to GitLab, but GitLab would be more than I needed. It has many great tools for maintaining code bases, but I don’t need them for smaller projects.
I needed something other than GitHub or GitLab.
Enter SourceHut, created by Drew DeVault. SourceHut is a collection of open-source development tools that are a good alternative to GitHub and GitLab.
I’ve been considering using SourceHut for a while, but I have only started seriously considering it in the last couple of weeks.
Today, I created my account and initialised a single repository to get me started. A much more straightforward and basic user interface is strange, but it works. I have become accustomed to the feature-rich user interfaces of GitHub and GitLab. While SourceHut lacks many of the features found in the two bigger platforms, the simplicity of the SourceHut user interface makes it refreshing to use, with just the essentials.
Over the next few weeks, I will migrate more repositories, and then I can demote my GitHub account to be used only for work.
Good GitLab features for devs building on the side
Over the weekend, I spent time getting my GitLab account, working with a single repository, and migrating the CI script from GitHub to GitLab.
The biggest issue was the CI script, and why shouldn’t it be? There’s rarely a “one script fits all” regarding CI scripts. When I started this project, I had issues getting the CI script working in GitHub. After a few pushes on the one branch, I eventually got there. Migrating this script to GitLab’s CI ways was more straightforward than I thought, but I still had a few issues I managed to resolve.
In addition to all the usual source code management goodies that GitLab offers, a few stood out.
Private repositories are available on GitLab’s free tier. Having used GitLab in the past, I already knew this, but it’s refreshing to see that GitLab is sticking with offering this feature on a free tier.
Feature flags are available on GitLab’s free tier. They are a means of configuring how your code behaves by using toggles and checks to ensure that it only carries out certain functionality. I have a number of feature flags in my application, but they are all based on a YML file in the source code. I will be migrating these to GitLab, though, so that I can toggle them without having to deploy any changes to the YML file that controls them.
Error tracking is available on GitLab’s free tier. Previously, I used Sentry for this, but GitLab also uses Sentry under the hood for their own error tracking feature. Yes, I can probably get more information by having a dedicated Sentry account, but at the moment, I am just checking to see if users raise any errors in the application.
For developers building on the side, these features on GitLab’s free tier are of great value and definitely swing my vote from GitHub to GitLab. Over the next few weeks, I hope to migrate the feature flags over, use more of GitLab’s platform, and see what it can help me with.
Last year, I relocated my office to the back of our home with a south-facing window. I now use light themes more frequently when the sun is bright during the day. The Noctis set of themes for VS Code is ideal if you’re looking for light and dark themes in a single extension. Recommended.
Trying to stop making daily trips between VS Code and GitHub and handle pull request work within VS Code when I can.
Walking the path with TypeScript
This week, I spent most of my free time adding an NPC character to my ThreeJS game and have them walk towards me each time I move my own character.

I’m using the A* algorithm. Each time I move my own character, the NPC finds the shortest path to my character using this algorithm and then moves one step to my character.
As I’m already using a two-dimensional array to represent the game’s board, using the algorithm on this array helped me get it working. What I wasn’t prepared for was the amount of code needed to implement the algorithm and move the NPC across the board. Still, I managed to learn a thing or two more about TypeScript.
What’s next for my game? I’m not sure yet. There are so many things that I could be doing, such as adding attributes for my characters, both PC and NPC characters, and adding more elements for the map, like ancient ruins. My youngest is also designing skins for the playing character and the NPC, so they’re more than just coloured rectangles on the board.
I had more fun with ThreeJS tonight. I increased the size of the board and added some trees and boulders to it. I am now at a point where I will focus more on building a representation of the board as an object to start moving my character around the board.

I continued to make some progress with ThreeJS and TypeScript tonight. I managed to draw a tiled board, move it around the screen with the mouse and be able to change my field of view with a slider.

A couple of web development projects for the winter
Now that the golf season is down to me and the boys only getting out at the weekend, I can start spending more time on a few side projects. There are so many things I would like to learn, but I figure just limiting myself to a couple won’t take up too much of my time.
So, from now to March, I’ll spend a few hours each week on the following.
- Learning more about Rails 8 and Kamal — Dailymuse and Writeabout will each get a bump to Rails 8. Only Writeabout, though, will get the Kamal) treatment to begin with. When I have gained enough knowledge about Kamal, I’ll also look to deploy Dailymuse with Kamal.
- Learn TypeScript and ThreeJS — A work colleague showed me a hobby project he is working on using ThreeJS. It’s the perfect excuse to learn TypeScript and build something for the web that isn’t just another web application.
Settling into Stimulus once again
Over the last few days, I’ve been writing more JavaScript than usual. The reason? I am using Stimulus a lot more in one of my Rails projects.
Enhancing the functionality of my Rails application with some HTML markup and a JavaScript controller is good, as Stimulus has a small learning curve and integrates well with Rails.
As I add more Stimulus to the application, though, I am learning some of its best practices the hard way. One criticism I have of my own controllers is that they are very page-specific. That’s fine for now, as the application is relatively small. Still, I plan to break these controllers into more generic behaviours that can be re-used more easily across the application in the future.
I’m using an old iPad I inherited as a secondary screen for my MacBook. I’m very impressed with the setup. I can see myself using this setup a lot.
GitHub Copilot is now available on github.com.
My first impressions are good. Summarising pull requests is a significant benefit. Unfortunately, Copilot could not diagnose the problem with a GitHub Actions workflow I was working on. It had issues accessing the correct action being run.
This week, I learned how to build my own reporter for Minitest and rolled my own feature flag manager. I love programming in Ruby!