After an uncomfortable time having ended up having to interface and write
Modern
PHP, and other programming atrocities, I've had the luck of having a multitude of opportunities to work on a number of rather exceptional new technologies in a short time.
I had the opportunity to learn elixir recently, A functional language on Erlang's BEAM that commands a syntax approaching that of Ruby. It is a fascinating departure from anything I have ever interacted with before, and the OTP paradigm allows for some amazing systems that other languages struggle to implement. Having the ability to pass messages between processes on different nodes seamlessly and having those processes able to be killed and rebooted on a different node without missing a beat allows for some tremendously resilient systems. The fact that it's compiled down into a small release makes it that containers can download quickly.
A reimplemtation of Lambent Aether 4 using elixir to implement the multiprocess paradigm instead of the old crossbar.io router and autobahnPython clients implementation that I had finished previously.
This implementation can seek out multiple types of lights over both the local network and multiple mqtt brokers. It also implements a Phoenix UI that allows for dyanmic visualization and initialization of system components such as machines and links. The web interface also harbors a web hook receiver for machines that expect to receive external data.
Is the maybe - questionable name of a service that will eventually encompass a large number of the features contained by Google Now back units heyday, but with a more hyper-local bent.
It provides a web interface to configure and manage data sources relevant to the user, with the eventual goal of surfacing relevant data wherever in the world you might end up.
I'm hoping that the pinenote ends up being made with a relatively good window manager integration such that a small daemon can be written that passes up found wifi macs into a geo-location service, instead of relying on a power hungry gps to provide location data. Either that or a companion android daemon that submits rough gps locations every so often. This would enable a sort of traveling focal point that can be used to present hyperlocal transit, micromobility, and event data.
In the meantime, I'm writing other hardware and terminal clients to complement the web interface that talk over the rabbitmq-as-mqtt broker implementation and additionally following the development of liveview native closely to see if data can't be passed into an android widget.
My current employer at the time of this writing uses rust as a language on embedded Linux devices, it's given me an opportunity to learn the language in a professional context, with the ability to chat through questions I have with certain features.
I've enjoyed the package manager, the Trait system, the small binaries, and most especially that I've come onto the language at a time where apis and paradigms have gelled.
The borrow checker takes some getting used to but I don't think it's as big a deal as some people make it out to be.
Micropython is great, but I think that it cuts you in various ways that aren't great and the whole vm atop of the free rtos stack wasn't super performant. It's great for prototypes but debugging and development isn't as nice.
Rust on embedded devices has been pretty great so far, and lets you have compiled code for the target as well as having libraries from cargo at your disposal.
Immediate mode terminal rendering is an interesting tool for making interfaces and the rust command line packages are excellent at allowing expressive user interfaces to be made. I've been working on a few small tools using these libraries, including a client for Apollo's Crib
I picked up Eagle back in Uni initially for doing toner transfer pcbs for a class project, but hadn't touched it since. In the intervening time Autodesk purchased it and SaaSed it. At the same time, CERN put a lot of effort into making KiCad a usable product. In the past year I've gotten around to learning it finally.
I think the largest issue that I had to overcome was the split between schematic and board was not quite what I had worked with before but once I understood the intent, it mostly got out of my way. I was able to lay out a 2 layer PCB with modern components mostly installed via a package manager. The rest were installed via git repositories in the plugins folder. The resulting board implements a usb-pd powered esp32-c3, with two lighting channels
My eventual plan is to practice with increasingly more complex design work in order to roll a new main board for a Sony Vaio palmtop from 2009 that I purchased a few years back, who's combination of anemic-for-the-time intel atom processor and 1.8" pata hard drive make for an impressively bad experience in 2024. Even with a trimmed down openbox Debian install, the machine takes half an hour to boot. 🙃 The goal is to build a replacement motherboard leveraging the CM4-extending footprint from a Radxa CM5 RK3588 Module. This module sports up to 8GB of ram (2GB on the original) and up to 128GB of EMMC (20GB pata on the original), with the opportunity to break out either PCIe or SATA.
Docker inc acting like a mafioso in an attempt to become profitable made an already sour note from dealing with their product stack differentiation in the past (running more than one copy of a particular container in a compose stack is a different product for reasons 🤡, we don't want compose to be used as a python Library so we'll obfuscate the interfaces 🙃)
Podman and its' associated tooling came about as a hedge by red hat against docker's moves to dominate the container space. Changing over on my workmac was incredibly simple, install it, do the intitial setup and...
But on top of that podman let's you manage containers on remote machines, deploy compose style stacks and use systemd units to define more complex container configurations.
I've mostly managed to avoid doing much Single Page application application work, even if I've touched the big frameworks along thew way in service of various employers. I've often found the additional complexity of another entire stack alongside my backend just to shuffle different kinds of brackets.
I'd used alpine.js in the past for simple sites where I've needed a touch of interactivity and enjoyed the application of html attributes to drive behaviors. When the Django subreddit was posting about HTMX as an alternative library a few years back, I decided to try it out by converting this website to use it for page transitions. The implementation was very simple, leveraging hx-boost against existing routes and setting up template partials as needed.
For more complex applications I've added sprinkles of hyperscript to audgment htmx, This has been used to implement the behavior that the Django admin uses to implement inlines in the admin, for django forms on regular pages in a reusable manner. The same techniques are used to implement search drop-downs and chip fields.
CASABEZA for the longest time only had the phone UI to complement the django admin, but since the successful changeup to add htmx on this website, I have implemented a webui for the application with a far more complete and featureful version of what I wrote for the android application in a far shorter period. It also allowed for faster iteration on the inventory maintenance scheduling, logging, documentation, and other varied features that have been implemented after reaching parity with the android application.
I've also found that small programs that can leverage libraries similar to jinja that serve a webserver are also good candidates.