A very common convention I’ve seen over the last few years in utilizing python logging is to use the root logger:

import logging
logger = logging.getLogger()

This is wrong. Don’t do this. Instead of using the root logger — you should be using a specific logger, and leveraging logging “ancestry”.

Logging ancestry

In python’s logging module, ancestry is how loggers in functions, modules, and packages inherit configurations from a logger that’s higher up in the package hierarchy. Let’s look at the following package:

my-package/ ├── src/ │ └── my_package │ ├── sub_folder │ │ ├── __init__.py │ │ └── module_a.py │ ├──…

Ever wanted to set up an ELK stack and get python logging to get there with minimal fuss? Well this is the article for you. We’ll be using a dockerized ELK stack, so if you want to follow along, make sure you install docker and docker-compose. We’ll be using a jupyter notebook to do our logging testing. I assume you’re familiar with installing python virtual environments and using them, but if you’re not please feel free to brush up on the documentation!

Overview

1. Make sure docker and docker-compose are installed
2. Set up a virtual environment
3. Install the dependencies
4. Configure Logstash
5. Start…

Logging in python is something that won’t matter to you until it matters. If you’ve ever seen a message like one of these, I’m here to explain why it’s a bad idea to ignore them:

What is a virtual environment?

In both Windows and Linux environments, there’s nothing virtual about a python virtual environment. Since python is compiled, and then you run scripts that use the compiled python interpreter, it’s not conducive to compile it every time you need a new virtual environment. When creating a new virtual environment, you’re not getting a fresh python interpreter; you’re using the environment variables to point your compiled interpreter at a specific interpreter, libraries, and scripts.

With python, there are three primary environment variables for selecting the interpreter, libraries, and scripts that will be available: PYTHONHOME, PYTHONPATH, and PATH. …

Recently I’ve been learning a lot more frontend development, and I keep finding myself using the same pattern over and over for a lot of these personal projects — from a crypto coin logger and grapher to a standard chat site, I’m finding this pairing fairly useful:

• Angular frontend with routing
• FastAPI backend for quick swagger docs and async python APIs
• Some basic CI/CD for testing (With Github Actions!)

I hate doing the same thing over and over — so I finally took the dive and learned cookiecutter the way I should have months ago. Since I took the time…

I’m learning reactive forms right now, and it’s a quagmire of building and updating things that seemed more complicated than I’d ever want. I’m building an internal tool for project planning, and have a need for a reactive form that has a formGroup with two formArrays nested inside it, and formGroups for each of those formArrays. I need those formArrays to be able to add and remove items. I also need to be able to load partially completed forms, because I don’t expect these forms to be completed in a single go. This is where my problem came in. …

I’ve been in IT for longer than I’d care to admit — I started with front end IT support for credit card customers and worked my way up to senior python developer at a “startup” gone big out of Silicon Valley. In all the years I’ve been doing IT, one of the most frustrating things I ever see is someone teaching something with poor or incomplete instructions — and docker/swarm are one of the areas I see so much partial instruction it’s infuriating. …