Skip to content

Solutions

F3: flexible feature flags

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!

A simple notification pattern based on apprise

In 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.

A homemade replacement for mkdocstrings

In 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.

Best practices per AWS CDK L3 constructs

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.

How to display AWS CloudWatch logs in Streamlit

Let's dive in the following scenario:

  • we have some job/task running on AWS
  • we have already built a Streamlit frontend to launch jobs
  • we want to monitor AWS CloudWatch logs generated by the job execution
  • we don't want to neither switch from our Streamlit frontend to AWS Console, nor become crazy in following right log groups/streams to track our job

A possible custom solution is presented below.