2020-02-29 | Subject | Homebrew Paperclips
There is only one way past this, from what I can figure, in my area of work, at least. There is only one way to address this. (Well, besides SOP, which is 8 billion people running around in small, oblivious circles, watched over by machines of loving grace.): efficient, real-time models that focus on easily understood relationships rather than object-oriented style frameworks and abstractions. No, what we are doing is not tweaking a UI in a week. I mean: how do our efforts fit into X broader system. I don't think I understood how well this meshed between actual supply chains and software tool/app chains until recently. This is the battle, the front lines. I'll tell ya, though, nobody wants the full deal. They'll say "full stack", but what they really mean is reuse of abstracted efforts. And, true, all is abstracted in the end. You can't continue to program a homebrew with paperclips. The point is just that you understand the system balls to bone, and where your place is in it, rather than hand everything off to some big cloud company to handle the details. Ugh.
This is not just the same-old response. I have spent much of the last few months trying to understand a small piece of software ecosystem, answering a relatively simple question. What, exactly, is involved with getting a Python-controlled web browser using Webkit with GUI (GTK) bindings? When you have this, you can build applications directly from data and, conversely, manage the system in the opposite direction. A web browser truly is fabulous, and CSS and Webkit are amazing pieces of UI/dev. GTK comes from the GIMP. GIMP is the GNU Image Manipulation Program. GTK is the GIMP toolkit. Well... again, I could go on. The thing about a UI toolkit like GTK is that it has OS implications. There is a very extensive list of dependencies as well as multiple package managers (pip, apt). Here is the other big part of it: just like in real supply chains, large players insert themselves to make money and gain control. That is fine and all, but if you want to do something a particular way and ensure you can continue to do it, you need something different (open source, and free). This is Stallman's freedom. The QT side of the UI family (a similar, and often prettier UI) has some blocks, particularly with Webkit, that I've run into. Likewise, there is only one truly free graph database that doesn't need Java (which, although free in some ways is challenged by the level of abstraction). OK... forgive the tech ramble, but this is all I live right now for work effort.
(Usually the answer is to run this all web-based, but there are reasons related to supply-chain stuff that make this unacceptable to me. Regardless, webkit is great tech. I need a web browser... just not cloud.) This is how modern containerization works.
From my perspective this vid creates more questions than answers, but it might be good for you.
To be clear, I am doing the opposite as far as principles and philosophy. Likely what I have to do is replicate everything I am doing on kubernetes or somesuch (there are others) and compare/contrast the supply chains, etc. My main issue, is that this all works great if you want to rely on Azure or AWS or Google Kubernetes engine, but building something like this out to own is expensive and fragile (my current thesis, anyway). By pulling out the UI local (GTK/Webkit) and focusing on models and data (Machine learning/Graphviz), I believe I can get the 10x efficiency. And, my-o-my, in a very recursive way, we need that for our supply chains for resilience.
Just gotta put this in as a period to the above sentence
Seriously great vid by Eric Cline. I triple-dog dare software developer/infrastructure readers to watch that vid and give some thought to how current software/devops ecosystems work.bootstrap