All Posts

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:

You don’t need to use full AI models to get some of the benefits that have come out of the Gen AI / large language model (LLM) wave, especially when it comes to search.

One of the interesting components that have come out is practical uses for embeddings, which represents a concept as a high-dimensional vector (series of decimal numbers). While the idea of embeddings predate LLMs (such as Word2vec in 2013), the embedding models we have access to now like OpenAI’s text-embedding-3-small have been enhanced to understand context, for example the word “ruler” can refer to a measuring device or to a king. The term used here is “attention” in the sense of paying attention to the rest of the context. Humans can easily differentiate the two different meanings of “ruler” in the phrases “I want to measure this wood, please give me the ruler” and “King George was a ruler of England”.

Every year since the dawn of time someone has declared “it will be the year of the Linux desktop!” I don’t know if that will be true in 2025 for everyone, but it is for me. I’m now using Kubuntu exclusively on my home desktop after initially leaving Windows on as a dual boot. Once I realized I went 4 months without even starting Windows once, I knew it was safe to drop it.

Now, I have been exposed to Linux for a long time. I first set up a system in 1999 with Mandrake Linux (most recently called Mandriva), and loved it. I set up a server for development at work with Ubuntu Server in 2006 and since have used Linux servers at work almost exclusively. For a few years in the late 2000s I had an Ubuntu Desktop as my work machine.

In this post I want to share why I switched now and some “risk free” things you can explore if you are interested in switching away from Windows on your PC.

Welcome to the newly redesigned gillius.org, built with Jekyll and CSS by hand, based on some CSS resets I found online.

This has been a long time coming – I last moved to Movable Type Open Source edition in 2011 and the last major CSS design I did in 2006. I’ve been working on this for some time and there’s still more updates I’d like to make, but it’s far past time to cutover at this point.

Some of my very old content has been removed such as C++ and Allegro tutorials and articles from the late 90s and early 2000s which is very out-of-date.

Keep reading for more details and my reasons in picking Jekyll.

Since 2011, the forums have been read-only since there was not much activity except for spammers. I am cleaning up all unnecessary old software after this site was compromised via a PHP exploit in the past few days. As the domain has been read only for 10 years, I have decided to shut down forums.gillius.org.

I developed a Pointing Poker backend and frontend web application (GitHub Page) that works well enough for an internal team to use. It requires nodejs on the backend. The front end was built with React.

I built it because I was frustrated with the performance and reliability of public servers, and because I wanted to learn more how to use React beyond a trivial tutorial. It’s based on websockets, and all data is immediately replicated between all clients. There’s no code to reconnect if the websocket fails or if websockets don’t work, but it’s worked without a single flaw within an internal network, which is how I’ve used it.

Thanks to Mischa Berlin for a submission allowing random name generation!

Read on for more details on the implementation.

I made a project ("lunchbus") to play with Spring Boot + websockets + AngularJS 1.5 + Groovy + Redis. This may be interesting to those who are interested to see how these are set up. The project also has the configuration to run on Heroku.

The lunchbus app keeps track of who owes lunches and to whom, a list of people and places that can be selected, a button to randomly select a place, a chat functionality, and a demonstration of high-speed log output from backend. Persistence is provided by Redis. Due to how it uses Redis, it's just almost ready for horizontal scaling with multiple servers, for that time that you have over 100,000 people going to lunch with you. All that's needed for that is to integrate Spring Boot to Redis pubsub.

My goal is to learn Spring Boot and websockets primarily, and also to see what does an application relying solely on websockets look like and its strengths/weaknesses.