James Read's Code, Containers & Cloud blog

This article started life in October 2024 as a “Initial reaction to using Cursor.AI for a few hours” - as the provisional title suggests, I was trying out Cursor.AI for the first time - and it was not love at first sight! As an eager user of vim (and now, neovim more recently) I was curious to see how well this AI-powered code completion tool would integrate into my existing workflow.

Many people are familiar with the concept of using markup languages to develop diagrams, like GraphViz’s dot Language, or PlantUML. These languages allow users to define diagrams in a text-based format, which can then be rendered into images. If you are not familiar with these tools, check them out - they’re seriously faster for diagram editing and updates than manually drawing boxes in diagramming tools, like some sort of neandertal!

I hate writing documents about myself - CVs, promotion applications, or even just long documents in general - like my dissertation. However, I do love coding, so I can trick myself into writing these documents by using using a markup language. What better language to use than LaTeX? LaTeX (pronounced “Lay-tech” or “Lah-tech”) is a document preparation system and markup language, widely used in academia for writing papers, theses, and books.

I didn’t start with Nginx, but it’s become my standard for open source load balancing now-a-days. I started with HAProxy - I remember first hearing about it in my first job, in 2008, when our CTO at the time was raving about it - “HAProxy rocks”, he would say. I didn’t get a chance to use it until several years later. It was when I first started load balancing services properly - somewhat of an improvement than having many services listen publicly on various ports.

I fondly remember this quote when I first heard it - and it made me chuckle. However this is such a good reminder of “GIGO” (Garbage In, Garbage Out) that is so relevant in today’s world of AI and especially Vibe Coding. ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ Charles Babbage Garbage In, Garbage Out is a principle of systems design, and also common sense, that simply means that if you feed in the wrong questions, clearly you will get the wrong answers.

It is often said that there are two hard problems in computer science; cache invalidation, naming things, and off-by-one errors. This post is about the approach I’ve taken over the years to name things - how I’ve named my projects. The very first project that I ever really created is also one that I released - called technowax. It’s actually still online today, in a fashion; http://technowax.net/ . I’m ashamed so say now, after all these years that the name was not original - and it was actually a distant family friend who had a web design company, I think it was, called TechnoWax.

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.

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.