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.

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.

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.

This post is written simply for myself to mark the date when I fully decided to ditch Ansible’s containers.podman.podman_containers, and Podman’s nasty port of docker-compose, in favour of Quadlet. Hopefully this page can serve as a useful reference for others considering the same move.

Problems with containers.podman.podman_containers

Ansible is great, but it’s a pain if you ssh on to a server, to find a container is down. You then have to jump on to another server to run the playbook to start the container.