James Read's Code, Containers & Cloud blog

I am so sick and tried of changing task management systems, I will just be using plain .txt files from now on.

In the last 10 years, I have tried so many different systems for organising my work and my personal life and yet I’ve not been able to keep using one of them after a few weeks or months. After all this time I think I’ve finally come to the realisation that they all suffer from the same inadequacies. Before anybody recommends me their favourite, here is a list of apps I’ve tried; RememberTheMilk (~2011), Trello, Google Keep (~2015), Google Tasks (~2022), Todoist (~2018 I think, but again in ~2023), and of course, because I am developer with a hammer (ie: the ability to write code), I had to write my own - wacky-tracky. I have probably had the most all around success with TaskWarrior (until recently).

It can be a real effort to bring yourself to write articles to maintain a healthy blog, and sometimes the simple articles are best. Therefore, I just want to take a quick few moments to talk about a tool that I just cannot live without now-a-days, when writing Go code, I am always live-reloading with Air in the background.

It’s really valuable for developers to be able to get fast feedback on the code that they are writing. Many of use will use one monitor for the code in web applications, for example, and another monitor for the web browser to quickly glance to the side, and refresh the page. However with non-web applications, it can be a little more tedious to compile, re-run tests, and run the application once again. Of course it isn’t difficult - most developers of microservices and similar will have a terminal window open on that second monitor, and they’ll hit Up on the keyboard to get the last command, make, ./myapp, etc.

I love Ansible, and I love doing certifications - so this was a no-brainer. In this blog I’ll talk about how I prepared, how the exam felt, was it worth it, and at the end I’ll even explain why I used a cow image as the cover for this blog post! ¹

The TURTLES model.

How many times have you seen projects abandoned on GitHub, or internal Wikis, with no explanation, no “next steps”, no follow-up or notes? How many hundreds of hours were lost to that project, and what was learned?

This article proposes a model (“TURTLES”), or more simply, a checklist, of how to properly archive a project.

Is now the right time to archive this project?

• T — Technologists: Do enough people contribute to maintaining this project? Developers, Architects, Security, Operations?

This helps you use Go to power the next generation of APIs+PWAs.

Prerequisites; This article assumes you know what protobuf and gRPC are, and have set up the grpc-gateway for REST already for your app.

The context

gRPC has become the default standard for modern Cloud Native RPC in Go. And gRPC is fine for backend service-to-service communication that can speak gRPC. To support older services, and the web, REST still reigns supreme.

Reading the source code is a pathway to many abilities that some consider… unnatural.

Luke’s original strategy was to attack the death star via SQL injection, but in the end he went for an X-Wing based buffer overflow.

I want to encourage you to actually read through the open source code for the software that you’re using. Doing so has many potential benefits, and skills like this can give you a real edge and advantage in your team. In the article I’m going to outline my top three benefits for doing so.

There are a lot of cool Linux commands and tools you COULD learn, but what’s the point in investing a bunch of time if you just use them once a week, or once a month? A good example I like to give is Vim — it takes a long time to learn and master, but I use it over 10 times a day so it’s worth it.

vim — the universal text editor

I remember thinking vim was stupid — so many keypresses and shortcuts to remember. Before that I was a nano user. What got me to switch? I started getting really annoyed that all the servers I was logging into didn’t have nano installed, didn’t have syntax highlighting, and similar. I consciously stuck with it and now I have a text editor that I love on every server.

My desktop after the story; i3, st, and some other stuff.

It was worth it, but I need to explain how I got here.

It’s about 2pm on a Friday afternoon, my week of meetings is finally drying up. I have a few hours in my calendar the rest of the day — and I’m not going to spend it catching up on more emails. I want to fill these last couple of hours with something a bit more fun, so I pick up the Ansible collection I was hacking code on and get to work.

This article is about how I often invest time in ambitious projects just for the joy of working on the project, often without the intention of finishing or publishing the project. By the end of this article I hope you can see why investing your time in such projects is interesting and useful, so you can understand why I spend so much time on this, and why you might consider doing the same too.

This article explains how I solved a couple of challenges of getting my initial environment and configs into Git — the first steps to GitOps.

I’ve been wanting to embrace GitOps for quite some time, but it’s always tricky to know where to start. Do I use Jenkins Jobs — I know Jenkins well? It’s a bit old school though, maybe I should be using Ansible Tower. I’ve heard things about ArgoCD, and lots of others. The truth is, I can’t do anything until I actually have my environment and configuration stored in Git.