Last update: 2025-06-04
Working since November
I got into an internship-then-hire program during autumn for a Flutter (mobile frontend) and PHP (backend + browser frontend) position in an accounting / invoicing software company. As the mobile project started reaching its milestones, the focus moved towards the company's PHP backend.
As is often for these programs, the training period was more work and less mentorship, but in this economic climate you take what you can. In my case it lead to actual salaried work and a first job in the industry. My work supported a much needed pivot the company was doing, which then secured further funding and work.
Summer vacation projects, Rust
The ESP32 bug bit me after my friend had played around with them. So, my current project ideas circle around Rust in embedded context with Slint as UI library on both platforms.
I'm still coming into grips with writing Rust, as it seems the correct way it pushes you to write code isn't explicit, but rather learning happens by bumping around the guidebars. Although much of it is that I moved from Rustlings straight to writing (mainly embedded) code, to then motivate further learning from theory.
This does bode well for AI-assisted coding once I get a good grip, as the compiler is (in)famously conservative about what code is correct. It also gives comprehensive advice to the AI on any issues.
Mechanizing S-1335 solar clock
I've been thinking about mechanizing my software solar clock since last year. Originally I wanted to keep it non-computerized and use a common clock mechanism. However, even if I find a mechanism that is silent, has enough torque, and has a non-circular axle to prevent slipping, the end user experience wouldn't be that good. Even if it could be made so, that it's enough to start it at solar high noon on a certain date, whenever the battery ran out, moving the clock forward manually with accuracy would mean a ton of work.
I've decided to lose the minimalist elegance and approach this issue with a microcontroller, to allow accurate control and automatic adjustment using a step motor. This also allows me to scale the design to different sizes with relative ease. Though the big issue with this is, that even the smallest design cannot really be battery-operated. With certain other motor designs it could be done. But running a power efficient non-step motor accurately would bring the complexity up another order of magnitude. The length of one second would vary on the load requiring periodical checking with e.g. hall sensors.
I'm using an open-ended printer to print the gears and casing, which has worked fine, but sets limits to materials. PETG has been the material of choice to most projects. In this project the bendiness combined with stiction has interesting dynamics. The PETG gathers joules to overcome stiction by bending, leading to some hopping. I haven't yet tested how the non-bendy PETG-CF would fare. I would expect it to be harder on the motor as the magnets have to do all the work on every step, rather than spreading the work between steps loading the PETG "spring". For end-user experience both acoustics- and visuals-wise I would prefer it not to hop every ten steps or so.
Org-agenda fridge magnet
I've always wanted to do something battery-powered as a realistic motivation for really optimizing something. In this case, I'm pairing an ESP32 with a basic 4" e-ink (SSD1683 controller) and a pressable knob for navigating items. I've previously repurposed an old jailbroken Kindle to show a screenshot of my daily agenda using the jailbreak tools, but I wasn't happy with the battery life, 1-2 weeks or so, or the userland interface.
The device would primarily be for presentation, so I would do a Markdown export of my daily agenda and it would then pick it up at midnight via WLAN. Then parse & itemize it for presentation. Ideally I could check items during the day as I go, but communicating this back to the Org ecosystem is non-trivial and I'll still have to build a new daily list. Wiping old entries doesn't really take that much time when building a new one.
And so, this project requires an embedded GUI. I've found Slint UI library pretty good as it's both native Rust and works both on desktop and embedded for any future Rust (or C++ etc) project I might have, and doing renderer shim for ESP32 seems fairly straightforward.