Week 3 at Moz, Step-Up Your Game
I'm starting a new job at Moz and want to get off to a good start. I'm journaling live and making it more social, using open source text editor Vim and working on a project called Pipulate. I'm sharing my thoughts with my audience daily and have found Python to be the best fit for me. My goal is to get others to install JupyterLab under an invisible Linux VM, making the journey onto Linux an appealing adventure.
Making the Journey onto Linux an Appealing Adventure - Week 3 at Moz
By Michael Levin
Monday, March 13, 2023
Okay a new workweek is about to begin again tomorrow. It’s Sunday with my kid here so I probably shouldn’t be thinking about it. But it is a new job and I really want to get off on the right foot. And so what? What now?
Hmmm. Journaling live, sort of like the equivalent of live broadcasts and perhaps even interaction with the audience. I could make this very journaling process more social. Or at least part of it. Can’t share everything, but some can be fun.
Okay, hello people. This is the part I typed ahead in the bathing on my phone in SimpleNote because it’s simple and I can. The copy/paste is a breeze and it’s one of the few truly unencrypted highly popular and useful apps left on this planet. I’ve got to make a home cloud version soon!
And so here I am in vim live streaming. I’ve got to get back in this habit. I just do it from a plain old laptop from anywhere. Resolution and audio quality may go down, but my resolution to keep doing it goes up and the content quality audio goes up because it gets recorded in the first place.
The new job, the deluge of rising AI input, the helping my kid through preteen/teen years amidst this still pandemic lockdown era, well it all has me thinking. I write a lot and I write daily. And a lot of attention is going to be on these large language models for a short while before things go multi-modal, which will be a whole other blast, there might be some hunger for verifiably human-generated text content.
Okay, let us begin. This place I’m typing which may look unusual to you is vim. It’s a non-graphical but still full screen text editor that’s pretty much pre-installed or some version of it on every modern non-embedded general computer on the planet, minus Windows. But now sorta Windows too.
And so you’ve got a free and open source text editor for life that can’t be taken away from you and will never go obsolete on you. It, being “vi”, “vim”, “nvim” and variations thereof are in good company with another text editor called eMacs that has similar roots going back to the mid 1970s.
Software going back that long has something going for it. Each had been at war with the other for around 40 years, yet the text editor wars continue. Each has survived and indeed thrived in th face of modern click-and-drag graphical WYSIWYG word processors, IDEs (integrated developer environment) and even Jupyter Notebooks.
The sub-stories here are numerous and amazing, and if you like this geek talk I’ll try to get to each in turn, and actually tell you those sun-stories in the context of a new project I’m working on that builds upon that particular bit from the past. Here’s what I propose.
I’ve been an SEO and a tech advocate without a platform for awhile now, working quietly behind closed doors doing my thing to “make SEO deliverables”. Now, I’m going to do that with you. I’m going to share a little thought-work here with you, daily if I can.
I am quite opposed to editing. Now I know it’s necessary, and without it you limit your audience. But I’ve tended to seldom care because I prefer forging ahead in my growth my own way. If you can land a day-job where much of your product becomes proprietary in exchange for predictable exchange and a stage upon which to perform, so be it.
In this way, with much of my work likely to be Moz-side proprietary here and there, I would like to being your attention to Pipulate.com. I’ve done HitTail in the past. That’s gone. I’ve done a Ruby on Rails delightful framework based on VBScript from which much of my abilities arose. VBScript and the Microsoft Actice Server Page world it was based on is gone. Obsolescence sneaks up on you. How to not let this be the case is my public-facing FOSS SEO Software mission that predates my joining Moz and predates joining Ziff. Maybe not before 360i, but definitely after it.
Pipulate 1 was an app that could be run using your local Python as a web server and Google Sheets as the output and a “bookmarklet” for input. You’d click a bookmark in your browser and the site you’re looking at is crawled into a Google Sheet. Wow, that was a fun version. But everyone started doing stuff like that with AppScript.
Pipulate 2 was a pip installable Python package that dealt with the difficulties of Google OAuth2 login and manipulating tabular Pandas data in Google Sheets. I’m not long that got built into Pandas and the native GSheets API. Better to use native and massively popular APIs than a Pipulate 2 package dependency that I wasn’t thrilled to keep up to date, redundant as it was.
And so that brings us now to Pipulate 3. It took some very difficult realizations. They are these:
Frameworks themselves are fragile and redundant. You don’t want a framework if you can help it. You want the direct capability of the first and primary tool you choose to work in and practice often to actually be your framework. If it’s proprietary or tied to a platform that’s going away, you got screwed.
So your framework such as it were should really your primary language you expect to have with you for life. It’s hard to make such an important potentially lifetime decision choosing a computer programming language in the field of tech. You can’t go wrong with Standard C or LISP, except they require that same lifetime commitment in order to be productive with them in the first place.
This is where higher-level, meaning more pre-built components, languages like Python come into the picture. Each language has its own reason why it’s going to make your life so much better than if you choose that other language over there. Your choice of languages and even dialects of those languages very much defines your likely thought-patterns and tribal affiliations for a significant portion of your life to come.
I’ve been through a few. When your brain doesn’t fit a language, it’s developer environment and execution context, you feel cognitive dissonance. For example, I don’t like the compile step in most C-like languages in which you wait for an “executable” to be created. Having such exe’s tends to make programs run faster and more reliably, yet it’s not for me. I prefer the more loosy goosey flexibility of uncompiled source code fed into an “interpreter” that looks at the human-readable source code and runs it in real-time.
Truth is many things are a synthesis of both techniques these days, so the language you choose will have to have an approach (or “implementation”) that feels right to you. I know mine. Call it “just in time compiling” or pcode or whatever. It just makes the first time you run it after an edit will take a bit longer. What can be optimized and compiled is, and the rest stays loosey goosey.
Such real-life results oriented pragmatic trade-offs is what Python is about. Python is that framework you seek but don’t know it yet. Based on just Python’s datatypes (lists, dicts and tuples) and how they’re integrated throughout the language, you can see the “correct granularity” framework you can feel good about becoming part of your coding habits, automatic behavior and a little bit of who you actually are. It resonates.
Python alone would be a gift. You should read up on it and get a bit of its history and positioning as truly free and open source (FOSS) that had achieved critical escape velocity as too big and important (I.e. companies’ billion-dollar businesses run on it) to fail. Such a gift would be enough, but on the shoulders of an even more massively accomplished FOSS product, Linux, the duo is unstoppable.
Python on Linux sounds so intimidating and unachievable. The real-life life-long benefits are too abstract in most minds, especially in comparison to just yielding to the cozy embrace of the proprietary platform tools. My mission is to get you over this hump. It will not even much that’s asked of you. Just a token, really, a trifle. What I want for you is… install JupyterLab under an invisible Linux VM running in the background of your Windows or Mac. This starts a slippery slope. It is the rabbit hole to a Linux wonderland.
Step 1 is to make your audience visualize Linux as an obsolescence resistant interoperable code execution layer like the Java virtual machine (JRE, JVM) was trying to be, but the one that actually happened. Look everywhere from mobile to desktops to servers. If it’s not actually based on Linux (or sometimes Unix), then it’s desperately trying to allow you to run it, like Microsoft is doing now with WSL. Linux won. It’s what your work going forward should be based on if you want it to last. So step 1 is helping folks see this.
Step 2 is to make the path onto Linux an appealing adventure like a trip onto Oz or Wonderland. Wonderland is perhaps the stronger reference because of the rabbit hole metaphor, but Oz is full of true blue Dorothy friends as opposed to the of vaguely hostile strangers around Alice. And I’m working for Moz. Hmmm. Am I the Curmudgeonly Humbug of Moz? Haha! The actual books are about the Wizard’s journey of redemption.
Okay, ok. Pipulate 3 is clearly the process of getting an SEO server set up anywhere, anyhow. Start in a Notebook on your Windows or Mac laptop. Run genuine systemd Linux system daemons on whatever laptop. Understand and study the journey of code from a Jupyter Notebook to being a 24x7 Linux system service. Capture SERP snapshots, site changes, or whatever an SEO might need to do.
Ready to do it “for real”? Run it somewhere other than your laptop. Plenty of choices. Cloud. NAS. Raspberry api. Use git to move your code around. All instances have the entire project history of both the Notebook development work and experiments, plus the “extracted” and locked-down, pinnable Linux Python service files.
Each project has two sides to it. The first is a non-disruptive flexible Notebook version where you can keep playing or even deliver against as hoc one-off as hoc requests. The second side of the project (which we will now call “repo”) is the extracted stable Linux service version(s), usually a .py file. The Notebook versions are .ipynb files because they contain built-in Markdown documentation of the code, among other things.