I use Home Assistant on a Raspberry Pi 400 (same as 4 hardware but with a keyboard case). When upgrading Home Assistant OS to version 17.2, I lost access to my Zigbee devices because I have a USB Connbee ii adapter. Per this GitHub issue, there is an incompatibility with old firmware that prevents USB from working at all. Since this is a bit of a specific issue, I thought I’d post this issue with a fix for visibility.

I found the ESP32-based ThingPulse Color Kit Grande and thought it would be a good way for my son (who is getting into robotics) and I to learn how to solder and put something like this together. It comes with a cool example project written in C using VSCode and PlatformIO. However, I’ve been teaching my son Python instead as his first programming language (after Scratch) and I don’t want to add C to the mix right now, so I thought to use CircuitPython as it supports ESP32. Unfortunately, there is not a out-of-the-box image for the ThingPulse, so in this post I explain how to get it working.

One note about CircuitPython support for this board: because it uses an ESP32 variant without have native USB support, you can only use the web-based environment over WiFi to work with it. Normally, CircuitPython boards export a CIRCUITPY folder where you can just copy code and libraries to the device. This also means the serial console (via USB) must be used to configure the wifi settings. Another caveat here is I used a board image with very similar hardware and I don’t know if there will be any potential issues with that (although I’ve found none so far).

I’ll first go over the steps I used to get it working then after provide some discussion on how I figured this out.

In this post I explore performance of a few ways to run services that can scale to zero in Azure. This can be useful to reduce costs in services with very low utilization such as a personal cloud learning environment or idle dev/test environments of an enterprise application. My previous post about Java startup performance focused on improving cold start times in the hopes to make scale-to-zero possible on a service like Azure Container Apps. Unfortunately, I was quite disappointed in container apps’ cold start performance and quite surprised with Azure Functions Flex Consumption. In this post I will detail my experience and compare to Azure Functions and Azure App Service.

The release of Java 25 (including GraalVM) and recent years of Java startup performance improvements inspired me to re-evaluate choices in Java web frameworks in low-usage scenarios such as scale-to-zero apps, where Java’s slow startup is a problem. The “industry standard” Spring Boot has improved considerably since I first started using it while alternative frameworks like Quarkus and Micronaut have also matured greatly. I want to check how fast these can start and how much memory they need as a baseline.

In this post I compare the startup time and memory usage for these 3 frameworks in a simple application using JDBC, Flyway, and Postgres. The database has a single table and the application serves both a JSON API and a server-side rendered HTML via a templating engine. I used what I felt are “typical” libraries for each framework based on its common tutorials and project generation tool defaults, aiming to capture “typical” usage rather than what is possible with targeted optimizing. For example, Spring Boot is usually lighter with Undertow instead of the Tomcat default, while Micronaut and Quarkus already default to lighter-weight engines (Netty and Vert.x). In Micronaut, I used Micronaut Data JDBC versus Hibernate in Spring Boot and Quarkus.

Full details are provided later in the post, but as it’s long I’ll start with the results as run on an M2 Pro Macbook with 16GB of memory and GraalVM 25:

A common mistake I’ve seen is developers over-engineering new applications. While it can be partially caused by “ resume-driven design”, I feel it mostly comes from the assumption that the latest techniques seen online from large tech companies apply to everyone. Sure, the Googles and Facebooks of the world can be a great technical role model, but not every application has to be built like Netflix. I would even argue that a “next Netflix” shouldn’t be built initially like Netflix.

A city of 1,000 wouldn’t start with building airports, trains and highways even if it will become a city of 1 million. The same applies to software. Sure, consider the future of maximum scale, but new requirements and technologies will foil even the best plans. You just need to leave a way to evolve to the next stage.

A design pattern I see commonly abused in new projects is picking microservices over modular monolith. It’s hard to imagine a new application that should start its life as microservices. Even with a skilled team, the pressure to deliver the minimum viable product is strong enough such that there is a high risk of getting the worst of both worlds: a distributed monolith, or at best an over-designed and complex to debug system requiring dedicated DevOps engineers before you need them. In the beginning you should focus more on business requirements and value. I’ve seen this push to over-engineer many times – once, I was presented with a proposal to create a Kubernetes cluster for an application that otherwise ran with very little utilization on a single server with 1 vCPU and 4 GB memory.

Some rules of thumb that I have: