Stories from an Italian Software Engineer
Version Control System
In the last blog post, we looked at our local development environment and how the complexity of modern stacks made it challenging to setup correctly.
In this post, we will look at the second step of path to production, the version control system, and the advantages and best practices around using tools like Git.
Development Environment
The first step of the Path to Production starts from our development environment, as the rest of the stages it changed quite a lot in the last ten years.
I clearly remember how I was coding during high school, from the Z80 suitcase where we would enter HEX instructions in the Numpad to Pascal, C and Borland Delphi.
Machines had a fraction of the power or memory or storage they have now, and yet the software I was able to build with Delphi was pretty impressive (for the 17 years old me), and I felt very productive.
Path to Production - Intro
You may have heard of Release Management, which refers to the process of managing, planning, scheduling, and controlling software builds through various stages and environments. This includes testing and deploying software releases.
In recent years, a new term has emerged called Path to Production.
Monitoring - Alerting Dashboards
This is the third and last blog post of the Monitoring series.
In the past two blog posts, I wrote about the following:
- Status Dashboards (https://lanziani.com/posts/2023/02/monitoring-status-dashboards/)
- T&T Dashboards (https://lanziani.com/posts/2023/02/monitoring-tandt-dashboards/)
This time around, we will look at Alert Dashboards.
Monitoring - T&T Dashboards
Last week we looked at Status Dashboards, how they show a snapshot in time of the system, using simple widgets like Stat Panel or Gauge and how they should be based on clear KPIs.
In this post, we will look at T&T Dashboards.
Monitoring - Status Dashboards
Let’s talk about dashboards, shall we?
It’s not uncommon in my work to work on Monitoring or Observability problems.
A team or multiple teams deploy their applications in one of the environments, we can assume production, and they want to know how the System behaves.
The evolution I’ve seen is:
My home setup
I’m a nerd; I’ll not deny it. I love to explore new things, run experiments and learn from them.
I want a stable system to backup my data, be it pictures, videos, documents etc. I want a place to install and run software that I want to test and possibly have it at hand reach when needed.
I want everything in my network to work over SSL, and I want to have the ability to serve different services on different subdomains of a well-known domain so that my family can reach them without having to know an IP address.
After a couple of years of experimenting, I finally found something that works.
Is Helm really a package manager?
Helm (helm.sh) defines itself as The package manager for Kubernetes, at first I thought that was a bold statement, but after thinking about it for a moment, I don’t think I know any other real package manager.
Let’s look together at the functionalities that make Helm a package manager.
English
It has been more than nine years since I moved to London in November 2013.
It was a couple of years after I got out of university and one of my biggest regrets was not knowing English as well as I wanted.
Automate thumbnails generation
In my latest post I told you I was starting a video series on Kubernetes and its ecosystem.
As part of the process, I uploaded all the streams on Youtube. I uploaded the first video without thinking it through. Still, for the second, I decided that it would be good to have a thumbnail for the video, and why would I do it manually if there is a way to automate it?