Flame
If you self-host service(s) you likely have some way to catalog and gain access to them, especially if they're web-based services. This can be done in a legacy bookmarks fashion, or via custom spaces in the nascent/modern Arc browser (which we feature a bit in the third section).
I've generally used a lightweight HTML file on the “central” server in my config. Being a tinkerer, this setup changes once or twice a year whenever a new CSS framework catches my eye. While this isn’t necessary, it does help keep some muscle memory in HTML+CSS+JS (and provides an opportunity to learn a new framework).
As time continues to compress for me, I've been compelled to “outsource” more things on my “tinker TODO” list, and one of them has been my “start page” for all my self-hosted services. Gone (for now) are the days of the aforementioned HTML tweaking. Enter the days of gadfly switching between start page frameworks/setups/containers (so I'm probably going to end up spending more time in an effort to save time. smh
).
I, somewhat arbitrarily, chose to start with Flame as my new “application hub”, since it has some pretty sweet features:
📝 Create, update, delete your applications and bookmarks directly from the app using built-in GUI editors
📌 Pin your favourite items to the homescreen for quick and easy access
🔍 Integrated search bar with local filtering, 11 web search providers and ability to add your own
🔑 Authentication system to protect your settings, apps and bookmarks
🔨 Dozens of options to customize Flame interface to your needs, including support for custom CSS, 15 built-in color themes and custom theme builder
☀️ Weather widget with current temperature, cloud coverage and animated weather status
🐳 Docker integration to automatically pick and add apps based on their labels
The screencap in the section header gives you a feel for the UX/UI, and the project wiki was helpful in getting started with Flame (keep an eye out for updates on my Flame use in future editions)
Plain Old Python Functions
Today's midsection is more of a random bridge than smooth transition between topics (yes, I’m still playing catch up on my December stack of unreads in Inoreader (which had some downtime this morning, so “YAY ☁️!”).
A December post on the Stitchfix data science blog started off with a statement that was short and forthright:
“The role of the full-stack-data-scientist is not what it once was.”
The Stitchfix team have been pioneers in data science-enabled business practices, and usually dig into technology minutiae. This time around, they're more pensive and discuss a simplified function-first approach that I think any DS team could benefit from.
Here's their setup:
Rather than constructing custom model-deployment mechanisms, building microservices from the ground up, and managing highly interdependent chains of data transformations, data scientists at Stitch Fix can leverage powerful infrastructure by constructing plain old Python functions to represent their needs.
In this blog post we’re going to take a different approach than usual. Rather than digging into a specific piece of technology, we’ll present our philosophy of functions for data science APIs and back it up with some motivating examples. We’ll explain the power of functions as a DSL, share some successes we’ve had using functional interfaces to build our MLOps stack, and connect our approach with external, open-source frameworks that the industry is beginning to adopt. Our goal is to convince you that a function-first approach will enable data practitioners to do more while doing less. The functional approach allows them to plug into the business in a scalable manner while avoiding the complexity of managing infrastructure and architectural decisions.
If you're looking to both scale and simplify your data science workflows and API deployments, this one's worth a read.
Arc Boosts
It's no secret that I'm a big fan of the [relatively] new Arc browser.
If you're new to these Drops (and Arc), the TL;DR on Arc is that it is a reimagining of the browser UX+UI, with Chromium under the skin. I introduced it last year, and it has been my daily browser replacement ever since.
One of Arc's more recent features are “boosts”, which is a new Arc-specific term for userscripts, which are “mini-programs, usually written in JavaScript, for modifying web pages to augment browsing. Uses include adding shortcut buttons and keyboard shortcuts, controlling playback speeds, adding features to sites, and enhancing the browsing history”.
Userscripts were and are a fairly niche tool, and generally require an extension in legacy browsers. Extensions are inherently evil, so it's nice having this feature baked-in.
An Arc user, Neo [GH] built a site where other Arc users can share general purpose Boosts. It's akin to other userscript sharing sites, just Arc-specific.
It only has a handful of boosts, but that's likely due to Arc still being invite-only. (Which reminds me: here's a new invite link to the first 5 folks to click on it and d/l it).
Tis definitely something to keep an eye on as Arc eats the browserverse (Arc for mobile appears to be set for a 2023Q1 debut — which will be interesting, given that you still can't run Chromium on iOS).
FIN
Year Progress: ░░░░░░░░░░░░░░░ 2%
☮