I love Python. Sure it’s not the fastest language in the world, and the package management can sometimes be painful, but I still love it.

I often reach for Python when developing the scripts that wrap systems together. Read a configuration file, process that data and do something with it.

I find myself reaching for a Pydantic BaseModel but I don’t want to create a virtualenv just for the script (uv script mode nonwithstanding), and so I just make it a dataclass and spend the next 20 minutes fighting type errors in my data.

What if there was a better way? What if I could re-implement just enough of a BaseModel in little enough code that I can just paste it into the script?

You don’t need a Makefile. Whatever your use-case, there is a better tool.

Makefiles are archaic technology, living on by force of inertia and notalgia. The syntax is opaque and the error messages are unhelpful. It’s time to move on.

We spend 8 hours a day working. For software engineers, currently in the enviable position to pick their workplace, instead of needing to accept whatever job offer that comes their way, the question is: what makes a job worthwhile?

What makes a job something worth dedicating half of our waking hours (and a larger portion of our productive hours) to?

Given the amount of time and energy we expend in our workplaces, it makes sense to look for some kind of meaning in the work we do. We cannot all be Jonas Salk (inventor of the Inactivated Polio Vaccine), or Frederick Banting (first to isolate insulin, and origin of the Miracle at the Toronto General Hospital), but we can at least hope that our work is making the world a slightly better place.

However, if I were to judge the output of my career so far, I’m not sure that any of it has contributed in a meaningful way …

Every new job comes with some amount of trepidation: how dysfunctional will this one be? Yet, I was excited about this one. I was moving back into aerospace: the land of exacting standards, and attention to detail. Having seen the chaos of New Space, I wanted the calm competency of Old Space.

You’ve checked out a new repository, try to build it, and are confronted with a wall of errors.

The CI is green and your colleagues have assured you that all the dependencies are included in the repository. Why is the build failing?

You scratch your head — why is your environment different?

You look through the CMakeLists.txt, do some grepping, but you can’t find those missing dependencies. Puzzled you look at the README, and there you see it, you forgot to clone the submodules, …

Facepalm …

After making this mistake when cloning a new project too many times, I resolved to find a solution.

I started a new job in January, and left in February. It wasn’t making me happy.

It started like any other interview process: a video interview, followed, a few weeks later, by a site visit. They showed me their hardware, talked about the challenges they were facing, how they were trying to improve precision, trying to extend their system to do new things, reacting to market needs. I was impressed.

You really should be making Meringue. It’s bloody easy, and will make you popular with whomever you share them with (friends, family, colleagues, …). I’d show you a picture, but I ate them all already.

Here’s a common problem: your cmake build is failing with linker errors, and now your’re looking through your CMake logs and reading the compilation database to see what libraries were actually included.

What if I told you that there was a better way? Enter Feature Summary.

Each new project I start ends up needing a dedicated container for CI. Some then accumulate additional containers for other CI jobs.

Remembering the commands to build and publish these containers usually became a game of grepping the shell history in search of the correct commands. After doing this too many times, I now have a Justfile to store these commands.

I recently bought a new laptop, and since I have some time on my hands, I decided to explore the landscape of tiling window managers again. I’ve been using Regolith Linux for the past 5 years, and I’ve developed a fair bit of muscle memory for it’s shortcuts.

Regolith combines Gnome with i3 (or Sway on Wayland). You get a good tiling window manager, but also the collection of tools that make a desktop environment (lock screen, monitor configuration, desktop backgrounds, notifications, …). Instead of needing to assemble all of these components yourself, Regolith gives you a working system out-of-the-box.

The common workflow when working with Pyside is to build the UI with PySide Designer which outputs an xml file (.ui`). This file is then fed into pyside6-uic` to generate the python code that actually the window.

Resource files work in a similar manner. A resource file describes resources (e.g. fonts and images) that should be included into the application. These are described in an xml file (.qrc`) and compiled into Python by pyside6-rcc.

Keeping the xml and compiled files synced by hand is tedious. A common option is to use a makefile to automatically re-generate the python files when the xml files are updated.

The deceptively name OpenCV cv::waitKey in OpenCV is the centre of any use of the highgui module. This module makes it easy to create simple user interfaces and the waitKey function, in addition to waiting for keyboard events, is responsible for updating the message pump for all the windows.

It is too easy to forget to update documentation when refactoring code. I often change the parameters of a function and forget to update the doc doc comment which lives on, wrong and misguiding. In c++-land doxygen is the standard documentation generator and it can be configured to warn when a parameter of a function is not documented. This helps but documenting every single parameter of every single function is hard, especially when developing new features which leads to a high false positive rate.

A finer grained approach that only warns if the documentation comment and the function disagree …

This error is caused by the fact that ROS does not know about the nodelet. To be sure we can check what nodelets ROS knows about by running:

$ rosrun nodelet declared_nodelets

If the nodelet you are trying to run is not listed in the output then we have confirmed that ROS does not know about it. If you are trying to run a nodelet from another package this usually means that the package itself is not in your ROS_PACKAGE_PATH. This can happen if, for example, the package is not correctly installed.

If you are seeing this error for a nodelet …

When creating a CMakeLists.txt file we would like to only list the .cpp files in the add_executable and add_library commands. Whilst this is sufficient to compile the code (and should be enough for any IDE) most IDE’s today will exhibit limited functionality unless the header files are also included in the add_executable and add_library commands.

A simple workaround that preserves the best of both worlds is to create a dummy rule that includes all the headers but doesn’t actually do anything. better yet, we can make the rule locate all the headers with a simple GLOB expression …

If you have an encrypted home directory on a linux system chances are that you are using ecryptfs. This is the simplest way of encrypting the sensitive parts of your computer. You may also have noticed that the locate command does not find files in your home directory any more.

This behaviour is intentional. locate does not search the disk directly, instead it queries a database file generally called mlocate.db generated by the updatedb tool. This file is updated by the updatedb tool which is usually run with cron and it contains information about every file and folder on …

Last week I was in London and, true to habit, I went to visit the London Science Museum. I spent a lot of time in the Information Gallery, specifically the exhibits dedicated to the development of the telegraph.

The telegraph, for the first time, made it possible to communicate almost instantly over long distances. In addition to speeding up the distribution of information it created a host of other problems. Things that we take for granted today like time zones can be traced directly to the telegraph.

When debugging a CMake build file it is often useful to print out all the directories included by a target. The following snippet does just that. Simply replace ${target_name} and run cmake to see the list of included files.

get_property(includes
        TARGET ${target_name}
        PROPERTY INCLUDE_DIRECTORIES
        )

message(STATUS "Included directories for target ${target_name}")
for (dir in ${includes})
    message(STATUS "  - ${dir}")
endfor()

The ROS package format 2 is the new recommended package format for ROS projects. It supersedes the previous package format with a handful of improvements. Let’s take a look at how to structure the new file.

Lobster is a template engine for MATLAB with a syntax quite similar to Jinja, a template engine implemented in python. A template engine is useful if you need to create documents with a repetitive syntax. I use them for example to

• generate C++ to convert enumeration fields to and from strings,

• generate HTML content

• generate latex contents from MATLAB variables.

MATLAB on linux follows Ubuntu LTS releases and as such can be quite behind on more recent changes in the linux ecosystem. One recent-ish change that MATLAB still struggles with is the new naming convention for USB-Serial ports. In previous versions of Ubuntu these emulated serial ports were named /dev/ttyUSBX where X is an integer. In newer Ubuntu versions however, these ports are named /dev/ttyACMX, a change that MATLAB has not caught on to yet.

This seemingly small change means that, out-of-the-box, USB-Serial ports will not work at all in MATLAB. The instrhwinfo(‘serial’) command will never see the serial port. Fortunately the fix is quite simple if obscure.

CLion is a great C++ IDE. It also has the advantage of being cross platform and working on Linux. It has become my IDE of choice on that platform. In this post I’ll be sharing a couple of tips to use more productively with ROS.

Setting up CMake to build your documentation with Doxygen is really quite simple. All you really need is

find_package(Doxygen)
if(${DOXYGEN_FOUND})

        add_custom_target(doc ALL
            COMMAND ${DOXYGEN_EXECUTABLE} Doxyfile.h
            WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
            COMMENT "Generating API documentation with Doxygen"
            VERBATIM)

endif() # Doxygen Found