LIAM JOHN DAVISON

Technology Woes

Liam Davison
link cantilever bascule pi

It's not been a good week, technology wise.

The SD card on my Raspberry Pi crashed, possibly because of the heat of the Scottish summer (!). The SD card can't even be reformatted. I haven't lost anything of value, but I had recently set up a Gitea server, accessible on the web through a Cloudflare tunnel. The goal was to have a backup of my GitHub repositories and also to have a repository for proof-of-concept projects that don't need to clutter up my public GitHub account. I've got a spare SD card, but I'm tempted to upgrade to a Raspberry Pi 5, get an SSD card, and build a small home server.

I've also had some problems with Bascule. I wanted to add some new functionality, but before then I was keen to improve the unit test coverage in the project. Some of the changes had mind could be significant, and I didn't want to make them without the support of tests. But I've quickly realised that bascule is not testable.

With that setback, I decided to revisit Cantilevers - I know that project had good unit test coverage. So this weekend I've been reviewing the design, updating some libraries, and preparing for a new DynamoDB based metadata model. I've asked an AI agent to vibe-code a draft of that, though I don't intend to leave it all in the hands of AI. However, there's a weird bug in the web editor that I can't replicate in local dev. I decided that I needed to properly separate dev and prod environments, by creating new cloud stacks in CDK. That is not going well. I'm having trouble unlinking some Cognito and Cloudfront resources, and have broken Cognito entirely. I may delete everything and start again.

Other technology failures:

  • The Wifi adaptor in my Lenovo laptop keeps crashing, disconnecting me from the network. The finger print reader doesn't work any more either.
  • My big clock in the living room stopped working; replacing the battery has not helped.
  • There's a bug in my Amber phone application which seems to have got worse with the latest Android release. I must investigate that.
  • One of the keys on my piano doesn't work (it's the lowest note in Für Elise)

Testing Bascule

Liam Davison
link software development bascule

After the failure of the Cantilvers project, I've returned to Bascule with the intent of making it useable again. I'm upgrading libraries, moving to newer versions of Kotlin, and identifying possible improvements to the project. But before I make any major changes to the application, I am keen to fix the lack of unit testing in the project.

When I started Bascule, I wrote a few unit tests, but not many. Unfortunately, the testing framework I was using at the time, Spek, has been shut down. About a year ago, I felt I had no choice but to delete all the unit tests from the project to even compile Bascule.

I've started writing a few happy path unit tests, but am very quickly finding that Bascule is not easy to test. Although I am using some dependency injection (via the koin library), I have not been consistent in its use. More complicated is the way I am using reflection to build the processing pipeline. As various generator classes like the IndexPageGenerator are loaded through runtime reflection, I can't use koin to inject features such as my file handling classes. This is making it very difficult, perhaps impossible, to unit test.

I was quite proud of this dynamic loading of generator classes - it allowed me to define an interface and load classes at runtime, rather than building all possible generators into the core project. For instance, the search box on this website uses a Javascript library called Lunr and is fed by a JSON file created by a LunrJSIndexGenerator class from the separate bascule extras project.

I keep feeling the urge to start again. Create Bascule 2.0 with all that I have learned from Bascule and Cantilevers. Or Cantilevers 2.0, now with a proper NoSQL database? But is that really good use of my time? Just how many website generator projects do I need?