Skip to main content

If you've read any of this blog before June 2021, you'll notice something things have changed. This is because I've moved everything to a new blog engine, Docusaurus.

When I first started writing blog articles I felt like I was learning a lot of new topics every week and I had a lot of follow up thoughts and opinions on the subject. I felt this flood of information made for good material that had a good mix of something new and opinions on the subject. In contrast, more often through out my life I have an abundance of opinion or knowledge but not a mix of the two.

During the 2020 plague, when I finished my graduate degree, I decided that I was going to continue writing. I found writing to be a way for me to ramble without burdening my peers. I also get the added benefit of reflection and self documentation that I've frankly been lacking in my life.

Its been awhile since I've made a post due to a bunch of family related things and attempting to get over a feature hump in the current mobile application I've been working. The mobile app design and organization is beginning to gel into something I feel comfortable investing in. Therefore I spent the last weekend wiring up my continuous integration infrastructure for what I hope to be the rest of the application's life cycle.


In many situations, when writing statements or commands, I want to orient the command so that it presents well vertically. While we write statements and commands for readability we nearly always have to consider the horizontal constraints before the vertical constraints. The only time I hit a vertical constraint is really with run on functions or inline documentation.


In the past I have written Bare Metal on Raspberry Pi 4: Getting Started. This was my first experience with hooking up a raw FTDI Module To the Raspberry Pi 4 for JTAG. After getting this setup working, I quickly realized that it would be significantly more helpful to have a UART serial interface available for sending and receiving data at the application level while bit fiddling at the JTAG level.


As a docker user, I've written a bunch of helper scripts to simplify my most common use cases. The script is the most commonly used script that I write for all images. As I've evolved this script, I've learned a few patterns that are commonly useful across projects.


I was recently tasked at work with making some routine enhancements to an internal project. This project was a cross platform application that needed to be built for many different architectures. Some of the toolchains were so vendor specific that the toolchains were specially installed into Virtual Machines that I had to fire up to build the code for the target platform.


My excitement for using docker is something that not everyone can appreciate because not everyone has the same experiences. In many cases I just want to implement docker into a script to make a process more stable. The issue with this is that I often work in environments where all the developers checkout the entire code base and emulator the CI process on their own machines.


venvx is a sort of minimal combination of pipx and pew. It can be used in the development and testing of tools that exist in separate virtualenv virtual environments (similar to pew). It also has to ability to simply run console entrypoints that exist in other environments. Similar to pipx, venvx also has a run command that will build a new virtualenv just for the invocation of the command.