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.
Before I being, I want to clarify that this is by no means a how to article. This is merely a cautionary tale about what you have to look forward to if you decide to implement security code that interfaces with corporations like Google and Facebook. Its not bad, its just not easy and something that you aren't likely to be able to stumble through like so many other technologies on the internet these days.
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.)