monkinetic the blog

What with Twitter (aka birdsite, hellsite, muskosite) flailing in the clammy hands of Dr. No, and interest in the federated web re-emerging, I figured it was time to review my own web presence and see what was the situation.

Dear reader, it was Not Good.

Warning one was hitting this site from my work network and getting a BitDefender screen of doom saying the site was serving a keylogger. NOT GOOD.

Then the site - which was hosted on Linode and runs my own homegrown blog software, Goldfrog - went completely down. After some “where did those ssh keys get to, where is this thing anyway” I got logged in and figured out that my server had been hacked in some way, TLS and letsencrypt removed. I haven’t had time to troll the logs for evidence as to how the server was accessed, but I downloaded them and have them set aside to look later.

We Can Rebuild It

Thus entered a week of figuring out once again how the heck Monkinetic is built and deployed, migrating the code from Github to Gitlab (which I’m more familiar with due to $dayjob), and refactoring the Ansible code that builds the server and deploys the blog/content.

Finally today I got it 85% done, which is pretty good for a full migration between hosting providers (I also moved from Linode to Digital Ocean where I already have some other services).

Masto-tootly-don

With the insanity on Twitter, I logged back into my Mastodon account on toot.cafe and enjoyed the huge stream of new folks migrating from Twitter to federated platforms (mostly to mastodon.social since that’s the first/largest instance, but folks are making their way from there to smaller instances as they get more comfortable).

Apparently Mastodon 4.0 is out (release candidate) and they’ve changed the annoying-until-it-was-gone “Toot” to “Publish”. I’d have preferred “Post” myself, but 🤷‍♀️.

Maybe servers should just change it to suit their audience?

I’ve started messing around a bit with javascript-enhanced UIs for #goldfrog. Rather than use all of JQuery, I decided on a small subset of Jquery’s functionality as implemented by Sprint.JS.

1. I only load the JS for me, since I’m logged in.
2. It’s only used on the home page to power the new switchable post form, and
3. It powers a character-counter for the note UI.

Here’s the new posting UI:

I’m trying to implement some basic progressive enhancement - the forms work as is without javascript, but the switcher and the counter are niceties for me, the author.

Jacky Alciné is an active member of the #indieweb and #activitypub communities, and a web developer working out of Oakland.

Imma make this clear: I’m not building software for developers.

I’m working to building tools for people.

You shouldn’t have to know to maintain and secure a server to have your own independent identity online. You shouldn’t need to know what libsodium or similar library to be secure online.

That’s my objective.

https://playvicious.social/@jalcine/101366378320531511

I really like a good #codeascraft comparison. From DeployHQ, via Zeldman:

Woodworkers and web developers have this in common:

Visit a professional woodshop and ask a master carpenter what her favourite tool is. You may find it’s not a tool in the traditional sense, but a “jig” she built. In woodworking, jigs are patterns or templates built to make repeatable tasks more efficient and outcomes more consistent. Building a one-off bookcase may not warrant building a jig. But, if you’re building three or four of the same bookcase, it’s likely worth building a jig first, then using that jig to build the bookcases.

Our jig consists of a small command line application which integrates publicly accessible API’s from these service providers

Taking the time to make the tools to help do the work is the best thing to do, and knowing when to take that time is an important part of an engineer’s maturing process (see #yakshaving, Code As Craft)

Chris Krycho wrote a thoughtful post about the state of browser development and web standards, and as developers, the tendency sometimes to see Chrome as the standard for what features browsers should be supporting. Chrome is not the Standard:

> Over the past few years, I’ve increasingly seen articles with headlines that run something like, “New Feature Coming To the Web”— followed by content which described how Chrome had implemented an experimental new feature. “You’ll be able to use this soon!” has been the promise.

> These are tradeoffs, plain and simple. Chrome ships new features fast, but they’re not always stable and they often have performance costs. Safari ships new features on a much slower cadence, but they’re usually solid and always perform incredibly well.

> That’s what makes the web so great, even when it makes things move more slowly. Sometimes — often, even! — moving more slowly not in the experimental phase but in the finalizing phase makes for a much better outcome overall.

Fellow #webnerds, it’s a good read.