WLED
Today I learned about the amazing WLED project: https://github.com/Aircoookie/WLED
All you need to do is flash their binary to an ESP32 and it will bring up a WIFI access point that allows you to control the LEDs through an app or web page.

Today I learned about the amazing WLED project: https://github.com/Aircoookie/WLED
All you need to do is flash their binary to an ESP32 and it will bring up a WIFI access point that allows you to control the LEDs through an app or web page.

I really liked this talk by Martin Fowler about Event Driven Architecture: https://youtu.be/STKCRSUsyP0
It’s interesting to think about Git as an example of event sourcing.
I’ve been learning more about async communication between microservices and came across this article that talks about some of the trade-offs between sync and async communication: https://dzone.com/articles/patterns-for-microservices-sync-vs-async
My new job has me working on a larger codebase than previous jobs, and it’s also my first time using mypy.
I’m starting to understand why Guido’s work on mypy had a lot to do with Dropbox’s Python 3 migration. Dropbox wrote an article with details on how they used mypy on their “4 million lines of Python”. With that much code, I can understand why they needed to treat code like “cattle, not pets”.
Python 3 disallows some comparisons with None types, makes huge changes to strings/bytes, and has many other changes involving types. When your codebase is massive, you have to reach for automated tooling to consistently find and prevent those bugs. With the same tooling you can also prevent entire categories of other bugs from reaching production. The type hints can also be helpful documentation. For those reasons and more, I think implementing type hints on a large codebase like Dropbox’s will definitely be worth it in the long run.
It has me wondering if I should have been taking the extra time to use type hints and checking (or a statically typed language) this whole time. Was going without type hints one less distraction? Or will be the price be paid in maintenance difficulties and bug fixes later?
At this point, not much of the Python ecosystem has type hints (not even Python 2 compatible comment-style type hints). I’m starting to think it would be a good use of time to work on changing that.
I migrated this blog from blogger/blogspot to a static site generated with Jekyll and hosted with Netlify.
This blog post describes the process: http://joshualande.com/jekyll-github-pages-poole
Initially, I started using Python’s Pelican, but pelican-import (pelican’s tool for migrating from blogger) doesn’t work as well as jekyll-import. It turned comments into posts and threw exceptions while processing draft posts without content. Also, the first docs that show up on google for Pelican aren’t the latest docs. This causing issues when I followed the old docs that said to use Python 2.7, but Pelican only supports Python 3.6+ now.
Parts:
Code: https://gist.github.com/pawl/73a1ccfbf2b2be6f934e651b39c51082
Found a massive faillog/lastlog file recently and thought it was responsible for using up all my disk space. Turns out it's actually a sparse file and doesn't take up that much physical space: https://unix.stackexchange.com/a/530157
Parts:
Code: https://gist.github.com/pawl/5ed1f61e0b0b27aa839fc2b4499a92c2
Recently I worked on a bug that was causing duplicate unformatted log messages to appear in a Django app's logs. I made a repository that demonstrates the issue: https://github.com/pawl/django_duplicate_unformatted_logs_example
The problem was caused by an accidental call to logging.info (without using logging.getLogger to get a specific logger) while the root logger isn't already configured.
The solution ended up being to get rid of the accidental calls to logging.info and configuring the root logger to prevent it from accidentally happening again. I go into more details in that repo.