I am still working on a legacy codebase, so even the smallest change feels slippery and made me fearful. When I was about to implement a not-so-small change in a data processing procedure taking place as one of the first steps of a bigger pipeline, as a painkiller I decided to ask a feature flag to come to the rescue!
appriseIn my current role I try to learn and experiment with side projects whenever I can. One of these regards the need to notify a developer as soon as an update has been made to internal tools (e.g. the latest release of a private Python library, a new page in the team's knowledge base, etc.).
After some research I came up with a simple solution based on a pub-sub architecture, Microsoft Teams webhook and the awesome Apprise.
After having accidentally deleted every browser bookmark saved in more than 5 years of work, I decided to write down a simple backup script to prevent such a disaster from happening again.
mkdocstringsIn these days I am tidying up the documentation of a legacy codebase, where "legacy" stands for something in between spaghetti code and "things I wish I've done differently". Since I wish the output of the work to be as much complete as possible, I decided to include also the source code in the new docs built with mkdocs-material.
The go-to choice could have been mkdocstrings, but I wanted to avoid some setup complexity1 so I wrote down a custom source code collector.
Nell'utilizzo avanzato di AWS CDK, si realizza prima o poi l'esigenza di centralizzare alcune logiche e risorse in maniera da poterle riutilizzare in maniera rapida, riducendo il codice boilerplate. Anche se una prima analisi potrebbe suggerire che la soluzione sia l'implementazione di una "casalinga" factory - pythonica sì, ma non conforme alle best practices di CDK - la risposta probabilmente più corretta potrebbe riguardare l'implementazione di un costrutto L3, descritto come:
designed to help you complete common tasks in AWS, often involving multiple kinds of resources.
Let's dive in the following scenario:
A possible custom solution is presented below.
The AWS Serverless Application Model (AWS SAM) is an open-source framework that you can use to build serverless applications on AWS. A useful tutorial can be found here.