James Read's Code, Containers & Cloud blog

I got a SUN E450 workstation for free back in the mid 2000s. I got it because it looked super cool, but I wish I had more skills back then to be able to use it! Back in the mid 2000s, I was helping my Dad move his offices from one site to another. While we were there, I had spotted another company that was moving out the offices at the same time, and in particular, saw what looked like a very cool computer.

I’m 37 today (2025), but I started coding for the web 26 years ago at around 11 (~1999). That’s “26 years of web developer experience,” but I’ve realised it also bred an unhelpful belief about how to write frontend code. I started with Windows Notepad at school, producing HTML pages for Internet Explorer 4. Early tools included Dreamweaver (pre-Macromedia) and Microsoft FrontPage. Without a FrontPage license at home, I used Microsoft Publisher (yes, the desktop publishing app).

Nearly every technologist knows about semantic versioning (semver), it’s familiar for developers and sysadmins alike. However, what’s really cool is implementing semantic commits and semantic releasing! I only really started to become familiar with the concept of semantic commits a couple of years ago. When you’re a hobbyiest writing lots of code, there isn’t much motivation or need to write a commit message - because nobody is going to read it.

A couple of years ago I switched from Gmail to Fastmail for my email, and I have to say I’ve been super impressed. The reason that I switched from Gmail was that I was becoming less and less willing to support big tech companies that were not respecting my privacy, and Google is one of the worst offenders. Fastmail was one the few candidates that a took a look at, and honestly I cannot remember now what other providers I looked at.

Over the years I’ve used both markdown and asciidoc for writing technical documentation. Many more people are familiar with Markdown because it’s used on GitHub. However, I think I probably found AsciiDoc first because it is the standard used by Red Hat technical documentation. Both have their pros and cons, but I’ve come to realize that one is not necessarily better than the other. It really depends on the use case.

This is just a quick article to describe how the GoConSPA stack implements the 15 Factor App principles. 1. One Codebase, Ont Application GitHub: All code for the application is stored in a single repository. 2. API First ConnectRPC: The api is defined in protobuf, and exposed via ConnectRPC. 3. Dependencies Go Modules: All dependencies are managed via Go modules, and vendored in the repository. 4. Configuration GitOps: Configuration is stored in Git, allowing for version control and easy collaboration.

I’m eager to write about a technology stack that I’ve stumbled into, which I believe is the nicest one I’ve ever worked with. The stack is called GoConnSPA, and it consists of the following technologies and tools; Overview flowchart TD A[Backend Service] <-->|websocket| B[Single Page App] Technologies Go: The Go programming language, which is known for its simplicity and efficiency. ConnectRPC: A gRPC framework for Go that simplifies the process of building and consuming gRPC services.

I’ve been using vim on a daily basis since about 2011, when I started my first job as a systems engineer. The reason that I picked up Vim in the first place was that I was using Linux on a day to day basis (CentOS 5, if you wanted to know), across many different servers - and I wanted to edit files over ssh on those servers. While Nano was fine, and I could use it, it was a colleague using Vim that encouraged me to give it a go.

I really like YouTube, and I first remember using it back in 2008 or so. It’s a fantastic platform for getting to new content, even though it’s run in a way that goes against a lot of my personal preferences (lots of tracking, lots of advertising, some questionable policies). For non-paying users, Free YouTube is absolutely invested with ads. It’s basically unusable. Unfortunately I was forced to switch to YouTube premium a while ago because there are several content creators I really like, where their content isn’t posted elsewhere.

This evening finally marks the completion of the migration of https://docs.olivetin.app to a new build system, called Antora. OliveTin’s documentation consists currently of 126 AsciiDoc files, 50 images, and many example config files, code examples, and similar. I would not say it is a very large documentation site, like OpenShift or any of the Red Hat documentation that I spend a lot of time reading (also written in AsciiDoc), but it’s a decent size that has been built up over the last 3 years.