When working with python applications there are many different contexts and use cases for managing the state of the application. This article covers one pattern that I've used with great success. In short, its based on a folder heiarchy convention, virtualenv, and some bash-isms. If you are not a bash user, you'll want to tailor the relevant shell script for your preferred shell's environment.
When I first started messing around with Python (around 2010), I learned about calls like exec() and __import__ and how they could be used to dynamically load other python files. This naturally felt like a path of least resistance for implementing any kind of plugin framework for python projects that I needed. Or is it?
When dealing with a lot of javascript, I noticed that there are a fair number of node_module packages that minify and obfuscate their packages. Minification makes sense for javascript you plan to deliver with a webpages and obfuscation makes sense to prevent scanners from easily being able to monkey patch, but I really don't know why this happens before the page is packaged up. In other words, IMHO, all javascript should exist in node_modules as some human readable peice of code (albiet TS/ES7 -> ES5), but human readable none-the-less.
Always tweaking and refining various configurations. Thinking I just need to leave them in a spot without fan fare. Here we go...
I've developed conventions to reuse partial Dockerfiles to construct complete Dockerfiles for creating Docker images. These Dockerfile fragments can be dynamically manipulated and aggregated to allow for building of diverse sets of Docker images that are nothing more than loosely coupled and highly cohesive partitions of system configuration.
When attempting to run through some exercises for a previous article I ran into an issue where I couldn't get dropbear to work until some undeterministic time in the future. At first glance, this was an extremely mysterious issue that had me digging in google results that were over at least 10 years old. (And with no apparent solution.)
In A More Simple Busybox System, I documented how to get started with building a plain old rootfs with Linux, musl, and busybox. While this setup is good enough for local applications, its more practical to fold in some foundational networking capabilities and tools that allow remote access and inspection of the environment.
When learning embedded development, its a good prerequisite to really understand how software is assembled and behaves during execution. I'm not talking about knowing the behavior of if, when, goto, and other high level constructs. When learning how software behaves you should understand the expectations of the instruction set you are using, such as:
For several reasons I have a need for a simple/minimal system that can be used in an existing userspace or as its own userspace. Usually I would jump to tools like buildroot or openwrt for such things. I've used buildroot several times in my other articles for building cross toolchains, rootfs environments, and kernels for several use cases. Instead of going with an end-all-be-all solution like buildroot, I'd like to take a more simple approach that leans more on the tools readily available by the Ubuntu/Debian distribution.
I recently ran into an issue where my Raspberry Pi file share server fell over because of hardware currosion due to some unfortunate moisture exposure. In response, I had planned to replace the file share server with a Mac Mini that was available until I could get a replacement RPi. The service is basically SFTP and the users are responsible for having SFTP clients that meet their needs.