Hey I’m Aaron & I write about software and tech 👋

If you are writing your express js API, you might get in a situation where your number of routes is growing, and it’s getting harder to communicate your routes and their inputs and outputs within your team or outside your team, be that publicly or privately. One of the common options for addressing this is to document your API with a standard like swagger or open API docs. Although this does work to produce nice standardised docs, your team will have to manage, and there is a chance that the documentation can drift from the actual API you are deploying.

I’ve recently been developing and operating a lot more on the Airflow platform. While doing this development, there was always the challenge of communicating the parts of your DAG effectively without the developer or operator having to open the DAG code to understand how it functions. Whilst trying to find a way to address this problem, I found the Airflow DAG and task documentation feature available in Airflow already. I’ll cover how you can start using this and document your DAGs in Airflow like the example below in an easy and frictionless way for those end-users of the Airflow DAGs to understand what your DAG does quickly.

If you are looking to start a homelab a Raspberry Pi computer is a great option as it is low noise, low power and is easily expanded with further modules if you need new storage or other features out of your Raspberry Pi like connecting cameras or displays. As a homelab device, it is a great way to start building out a lab, learning and starting to work on your first homelab or home server projects in a cheaper and smaller form factor. Or if you want the challenge you can try and run as much as possible to get the most out of this small device and the small amount of resources available to it.

Description This article will cover how you can easily set up a local or externally accessible Docker registry for hosting your own built Docker images. I have recently gone from running the most minimal HTTP version of the registry on my machine to support my local docker image development workflows to running my own private docker registry available to private and public hosts with access control. I’ll run you through all the steps and gotchas so you can set up whatever kind of registry you need as it’s become a key part of my Dev Ops infrastructure and probably will be for you as well when you see how easy it is.

I have been developing the Airflow platform for some time now, using it for scheduling and orchestrating data engineering workloads. For this work, I’ve invested a lot of time to ensure it had an excellent developer toolchain to allow engineers to build DAGs and plugins quickly and to test work locally before deploying a package into a production environment. In this post, I’m going to talk about how you can set up an Airflow repo to allow you to build and test your DAGs and operators faster through a proper repo structure and the use of Docker to define and orchestrate our Airflow runtime more easily so you can keep writing code rather than running ops on a local Airflow stack to test your changes.

VS code is one of the top code editors out there due to its ability to easily extend its functionality through the inbuilt extension marketplace to find and install them in your editor easily. If you are working as a Data engineer, for example, you can install some extensions to make it perfect for your needs. In this post, ill go over some of these extensions you can use to improve your development experience as a data engineer when using VS code to make the editor work for you and help you do more in your day.

I have been running Home Assistant for quite a few years now and have many automation I rely on daily. I want to keep a better eye on this automation to make sure they are error-free and I can address issues early. This post will explore how I achieved a notification integration between Home Assistant and Slack in a scalable way, allowing me to quickly filter messages I don’t need or expand my notification channels if required in the future.

I’ve been using proxmox for a while now in my homelab as an open-source alternative for a virtualization platform like ESXi. One useful feature in proxmox is the templates which allows us to create a LXC or VM templates that can then be cloned as a starting off point for new proxmox resources. Now with these templates we are able to have a standard starting point to install our applications on top of, pre install packages for authentication, security, logging and etc without anyone else needing to think about it as we bake these best practices right into these template resources.

Containers have become a leading technology for defining and consistently running our software, helping reduce the dreaded “, but it works on my system” problem when trying to debug an issue or run an application. So by wrapping our software and its runtime dependencies into a container image, we create an artefact that you can test to guarantee it works as expected through the different stages of the testing lifecycle. Since we put these testing expectations onto the software we are creating, why do we not do the same level of testing to the container runtime it is using?