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. Numerous times I’ve done git commit -m "fix", or probably more often, just git commit -m ".". Of course that is bad practice, but it’s just easy to do when you’re the only person who will ever 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.
• ** Environment Variables**: Configuration is stored in environment variables, and loaded via viper.
• ** YAML Configuration**: Configuration is stored in YAML files, and loaded via viper.

5. Backing Services

• Docker: All backing services are run in Docker containers, and managed via docker-compose.

6. Build, Release, Run

• GitHub Actions: All builds are done via GitHub Actions, and released to a container registry.

7. Processes (Statelessness)

• Stateless Services: All services are stateless, and can be scaled horizontally.

8. Port Binding

• HTTP/2: All services are exposed via HTTP/2, and can be accessed via a load balancer.

9. Concurrency

• Docker: All services are run in Docker containers - no PID files, daemons, or init systems.

10. Disposability

• Docker: All services are run in Docker containers, and can be started and stopped quickly.

11. Log (streamiing)

• Docker: All logs are written to stdout and stderr, and can be collected via a log collector.

12. Admin Processes

• Docker: All admin processes are run in Docker containers - which mirror the production environment.

13. APi First

• ConnectRPC: The api is defined in protobuf, and exposed via ConnectRPC.

14. Telemetry

• Prometheus: All services expose metrics in a standard format, and can be scraped by Prometheus.

15. Authentication

• OAuth2: All services use OAuth2 for authentication, and can be accessed via a token.

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.
• SPA (+CSR): Single Page Application with client side rendering - not reliant on the server.

Tools

• Air: A live reloading tool for Go applications, which automatically reloads the application when code changes are detected.
• Vite: A build tool that provides a fast development environment and optimizes the build process for production.
• Goreleaser: A tool for building and releasing Go applications, making it easy to create binaries and publish them to various platforms.
• precommit: A framework for managing and maintaining multi-language pre-commit hooks, ensuring code quality and consistency.
  • conventional-pre-commit: A pre-commit hook that enforces conventional commit messages, helping to maintain a clean and understandable commit history.
• GitHub Actions: A CI/CD tool that allows you to automate your software development workflows directly in your GitHub repository.
  • goreleaser-action: A GitHub Action that integrates with Goreleaser, automating the process of building and releasing Go applications.
  • semantic-release-action: A GitHub Action that automates the release process based on semantic versioning, ensuring that releases are consistent and predictable.
• Docker: Just release containers

I’m just throwing this blog post out there to get it started, and because otherwise I’ll never find the time to finish the perfect blog post. However, I’ve ported the majority of projects I maintain to use this stack now.

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’ve been using it ever since.

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.

So many interactions with friends, family and coworkers now happen via our chat apps, and so many of the best bits of these chats just scroll by and are forgotten. Faridoon is a simple app that lets you save and publish your favourite chat quotes for you to save, for your community, or for the world to see.

I was inspired to write Faridoon a long time ago, when I was chatting with friends mostly on Mumble chat. We really liked the awesome simple interface of bash.org (now long since gone), but wanted to save our own quotes.

The bluey-grey color that you see in nearly all of my projects has the HTML color code #dee3e7. It came from the very first “real” web project I worked on when I was about 16 years old, and I knew nothing! That website has had so many versions over the years, but it’s first version was built with PHP4.3, XHTML 1.0/HTML4.01 and CSS2.1 - and it was a mess! But I loved it, it taught me so much about web development, and it was my gateway into the world of web programming.

In my very first job interview out of University, I was asked a question that I have never forgotten. The interviewer asked me “What skills do you think you have, that other people don’t?”. Context is important, I was 21, I’d never had a professional job in IT before, and I was applying for a job as a Systems Engineer. What came to mind quite quickly, was that I’ve been programming since I was about 11 or 12 years old, and it’s given me an appreciation for why software fails.

Sometimes you need to write a HTML webpage that is based on some sort of data file, like YAML files. Rather than having a server-side script generate the HTML, you can generate the HTML page statically, making it easier to host and cache.

I thought about writing a tool myself to do this, but thankfully, I found Gomplate. It is a powerful Go-based template renderer that allows you to generate dynamic content from various data sources, including YAML files. With Gomplate, you can easily transform your YAML data into HTML pages, making it a great tool for generating pretty HTML from YAML.