As part of the Embedded Systems Analysis material development I was recently doing some work with a Raspberry Pi I had sitting on my desk. I noticed that the USB-C power connection had fallen out of the device. Naturally I got under my desk to fetch the squirrel-y cable and plug it back in. I got the cable all the way to the RaspberryPi before I realized that the connector that was supposed to be attached to the RPi was still on the cable. _The whole USB-C assembly had cleanly popped of the RPi4.

In my day to day I'm always working on several projects. While the contributions or time spent on the projects is small, the amount of resources they take up is immense. All to often these days, whenever you want to build a thing from source, you may as well budget at least 20GB for a single project. This of course includes toolchains, dependencies, build cache, and so forth. This causes me a good deal of hardship because I can easily find myself filling up my limited SSD space. Today I decided to take some time to consolidate with the expectation that I was going to buy a HDD for archival purposes. Turns out that wasn't needed for some very strange (new to me) reasons.

To go along with the Embedded Systems Analysis material I've been developing, I wanted to have slide decks for each section. I originally started writing the material in markdown as a way to enforce more accessibility. Using something like PPT would betray that notion and so I began to look at other options...

I wanted to install Windows 11 on my desktop today. In preparation for this I specifically ordered a new M.2 SSD to install Windows on. In the back of my head I thought about backing up my old M.2 SSD or buying some device that would allow me to read the SSD through some other adapter. Ultimately I didn't do anything because I had recalled I had a second M.2 slot on my board and in a pinch I may have to just switch back for a backup if there were files from the old install.

Went to go build an old dockerfile to look at the state of some files in an installation. I was suddenly getting all kinds of errors ... turns out my machine automatically updated docker where BuildKit is now the default. You can go look up BuildKit and all the wizbang gizmos it comes with. I just wanted to be able to build my legacy Dockerfiles the way I always had and now I can't?! You had one job Docker!

I've been down this road many times, but this time I became a little more determined to get through it. I'm talking about using ESM/ES6/ES7 with test frameworks in NodeJS to do some integration / functional testing of an app backend I've been writing.

The primary reason for my writing this blog post now is because I intend to post the Inform section incomplete. I'm tired of coming up with reasons to not post what I've already written and I'd rather have what little's been done available sooner than later. That said, this is a early access sort of thing and should evolve over the coming weeks into something more complete.

As an application developer, I wanted to get more of an appreciation (and independence) of functions as a service (faas) (i.e. serverless). There is a product called OpenFaaS that is a framework for setting up your own serverless provider. This is akin to setting up your own AWS Lambda, Azure Functions, or Firebase Functions. The trouble is that I felt I had already wasted enough time fiddling with Kubernetes and other related technologies that frankly were too much for my needs.

But out of nowhere I ran into faasd. faasd is a light weight version of OpenFaaS services that allows me to throw up functions on a VM or even a RaspberryPi. Of course I dived right in, thinking this would be as simple as a download, install, run kind of operation. Oh how I was wrong. Even with its light weighty-ness, it requires a pretty vast knowledge of systems and networking to get going correctly. Additionally, this is a very immature product that doesn't have the friendly and polished UX that I was hoping for. None the less, its what we've got and I was determined to get it going.

The Environment​

I was recently taking some training through work. In this training I was provided a VM that contained all of the course labs and tools. As an avid VSCode user I naturally pointed my Remote SSH extension at the VM to remotely connect via VSCode.

The moment I entered my credentials I got a message like:

VSCode is not supported on the target architecture.

The Environment​

Sometimes when you work in different environments there are different security policies that inevitably make my job very difficult if not damn near impossible. I can usually figure out something out that is incredible inefficient and just let the customer pay the additional cost. I ran into one of these environments the other day where I was given a VM to perform my development from. This VM was pretty locked down, but it did provide me sudo to docker. I thought, "Great, as long as we have docker, we should be good!" ... oh boy was I wrong.