I’ve been dedicating my spare time to three development projects lately, some of which are continuations of past work, while others are new ventures. Allow me to elaborate on them.

Firstly, there’s Tin (using the chemical symbol Sn), the software that powers this website. I’m quite pleased with Tin’s progress, as it now boasts numerous features I’ve long wanted to implement. In fact, it has made creating and posting new content significantly more effortless. I recently added pagination functionality, enabling users to navigate between pages and allowing Google to index all 3,000+ posts on the blog. Additionally, I re-enabled the search feature, which has been performing well. As I continue developing Tin, I plan to enhance the interactive front-end for post composition, streamlining the process of writing and publishing content directly on the site.

The second project I’m working on is Teambeat, a flexible software solution I designed to facilitate agile retrospectives without enforcing specific formats. Lately, I’ve been using Teambeat not only for standard agile retrospectives but also for lean coffee-style meetings. Participants can suggest discussion topics and use virtual dot voting to prioritize their preferences. The software then guides users through the chosen topics and generates notes based on their input.

While using the site, it dynamically changes as the facilitator makes updates, which is a great feature. The site is highly interactive, but I do have concerns about the performance of the underlying backend application, Pocket Base. This server software, written in Go, supports the frontend part of the application I developed using SvelteKit.

Recently, coworkers experienced difficulty maintaining a large number of users on the hosted version. I discovered that I had set the concurrency limit of my container to only 20 concurrent connections, causing issues for users. Since the site relies heavily on WebSocket-based connections for interactivity and live responsiveness, these connections can accumulate rapidly. I’ve increased the number of concurrent connections to 200 and am awaiting feedback to determine if this resolves the problem or if further backend improvements are needed.

Despite these issues, the software works well overall. Users have reported that after overcoming the learning curve for the highly configurable software, they’ve been able to successfully conduct retrospectives and extract value from it – which was my goal. As open-source software, you can run your own Docker container with the application without relying on my hosted version or paying me for support.

My third project is work-specific but could potentially be adapted for broader use. We’ve been discussing using ServiceNow as a database for our applications and asset management at work. Collaborating with our ServiceNow team, we’re exploring how to best capture essential information.

Making ServiceNow compatible with our microservice architecture has been challenging, as it seems ServiceNow doesn’t often encounter architectures like ours, which primarily consist of numerous microservices. I’ve also needed to illustrate our architecture at work, but we lack a comprehensive representation of how our hundred-plus applications connect and interact.

Initially, I used Plectica for creating diagrams, which employs the DSRP style system thinking diagrams discussed by Derek Cabrera. While it’s a useful tool, not everyone has access to Plectica, so I wanted a more accessible solution. Consequently, I developed a Svelte application that takes a JSON file describing applications, services, users, underlying technologies, and displays them as cards in a scrollable, zoomable diagram connected by lines (called edges).

This new application allows users to select an app, view its dependencies, and highlight all connected elements - something we couldn’t do before. Although tools like Datadog and our Consul admin interface offer some insight into connections between systems, they don’t provide a clear app-to-app dependency diagram or show interactions between multiple applications.

Ideally, I’d like to export Consul data and use it as source material for my new application to provide a more accurate and automated overview of our architecture. Additionally, incorporating metadata such as team assignment for each application would streamline contact in case of issues.

Incorporating information about each application’s GitHub repo, Confluence pages, maintenance window hours, and other essential details into the diagram would make it a central repository for such data. By continuing to use the JSON file mentioned earlier and committing it to Git, we can maintain a commit history that shows changes over time and identifies those responsible for these updates.

Working on these three applications has been rewarding in various ways. Although my day-to-day job no longer involves writing code, engaging in these projects outside of work helps keep my skills current. It’s been fascinating to observe the evolution of Svelte, JavaScript, CSS, and new frameworks for applications. Exploring libraries like Tailwind has allowed me to build things more quickly, focusing on features rather than rehashing prior work on styling.

Overall, these projects have been enjoyable and fulfilling. I look forward to continuing them and adding new features in the future.