Sat, Dec 15, 2018 | maintainership, paramiko
Intro When it comes to software maintenance tradeoffs, most of what I laid out in “The why & when of software releases” remains accurate. An ‘iron triangle’ exists between speed, stability, and ease of maintenance – it’s impossible to prioritize all three. I historically prioritize stability, specifically via bugfix-oriented release branches – users can stick to a given minor version even after subsequent feature releases appear, with the implied contract that they can install updates from those branches without anything breaking. But as I’ve burnt out, I lean more towards ease of maintenance (at least when push comes to shove) though I still do my best to backport fixes anytime it’s easy enough. Today’s post is about a specific conflict between stability and ease of maintenace, as seen in my efforts to drop Python 2.6 and 3.3 support from Paramiko. That is not dead which can be eternally supported Paramiko 2.0 came out in spring 2016, heralding a switch of crypto backend from PyCrypto to Cryptography (though no API incompatibilities were introduced). At the time, my commitment to Python 2.6 was still firm, despite slowly decreasing support elsewhere. By late 2017, the combination of a vastly shrunken 2.6 user pool and similarly decreased ecosystem support (in Cryptography especially) finally prompted me to drop it too, in Paramiko 2.

Fri, Jun 29, 2018 | applications, documentation, personal, reviews
This is a quick review of Bear Writer, a popular note-taking application that I tried out a few weeks ago. A much larger and more detailed post about my overall quest for a note-taking solution (I have very picky, perhaps contradictory requirements) is forthcoming! The good Bear is a beautiful set of applications. Attractive without being ostentatious or getting in the way, pretty quick/slick to use, desktop and mobile apps clearly resemble each other, etc. It uses the relatively common “show raw Markdown text, styled accordingly” (e.g. text within asterisks still shows the asterisks, but is also bolded) approach which works quite well most of the time – with most exceptions being endemic to the approach itself and not Bear’s implementation. Checklist support is better than in some similar apps, including good keyboard shortcuts, an attractive strike-thru of checked list items, and optional ‘folding’/hiding; though see the next section for a bunch of pitfalls with this feature area. Organization is effected through tags (including nesting via forward-slashes in the tag names) and it feels simple yet powerful. Attention to detail is clear; for example, creating a new note while filtering by a given tag automatically tags the new note with that tag.

Wed, May 9, 2018 | announcements, fabric, invoke

It took (much) longer than anticipated, for a number of reasons, and like any good .0 release it’ll take a few minor releases to really get up to speed – but it’s here! Fabric 2.0.0 is now out on PyPI, along with the project that does much of the heavy lifting, Invoke 1.0.0.

Please see the upgrade documentation for the gory details, and if you like, read on for some non-instructive reflection on the occasion.


Sat, Jul 1, 2017 | personal

It’s been brought to my attention that I screwed up the RSS/Atom feed for this site during last year’s redesign - in a couple of ways! Thus, most feed readers haven’t picked up on new posts.


Mon, Apr 17, 2017 | announcements, fabric, invoke

Opening remarks

This has been a hard blog post to write; not in a technical sense (though blogging always is - it’s why I don’t do more of it!) but simply because Fabric 2 has been “coming soon” for what feels like ages, and putting it out in the open turns out to involve a lot of emotions.

But here we are: Fabric 2 is no longer private!


Mon, Apr 17, 2017 | personal, reviews

Along with some general site maintenance in preparation for another big announcement (!), I wanted to note that I’ve started a ‘reviews’ section of the site’s static content. Mostly to port over something that had lived in my private vimwiki and that I’d been exporting as a Github gist; content living in a gist always feels dirty to me, especially when I have an ostensibly easy to use website…


Tue, Jul 5, 2016 | announcements, career, fabric, personal
Being picky As mentioned in my 2015 round-up post, I’ve been trying to make ends meet, re: open source plus a paying job. In March, I parted ways with a bunch of great people to take time off1 and embark on a job hunt. My goal was to find a company that could dedicate time to upstream maintenance, used my projects heavily in production, or both: Without a clear split between “internal” and “external” development time, prioritization becomes a tug of war leaving both sides unhappy. (And verbal agreements can get lost when organizations reshuffle.) Only by using one’s own projects can a developer truly internalize use cases and encounter edge cases. Development in a vacuum isn’t great. A role lacking one of these is problematic; one with neither – regardless of how awesome it would normally be – can make OSS unsustainable. Work found Despite my tight focus, I’ve had many great conversations with amazing hiring managers – often, after grilling whichever friend or contact initially reached out. Thanks to all of you! After some difficult decision-making, I’m happy to say I’ve found a role filling both of my criteria! My new employer: uses Fabric to manage thousands of servers, giving me an excellent source of real-world problems to drive development; is giving me 1 day/week for pure upstream development; has plans for a new, interesting-to-an-ops-guy platform that I’ll help architect and develop.



Mon, Apr 18, 2016
As touched on in a recent post about redoing this site, I recently had the (mis)fortune of using a Golang project in anger for the first time. It’s not exactly a reasoned critique drawn from years of experience, but I wanted to share some of my gripes regardless. As a long-time Python-using dev & sysadmin, I found the following things frustrating when attempting to use, troubleshoot, understand and/or modify a Golang project (specifically Hugo, but most would apply to anything in the ecosystem): Adding a build step to the development process: even a fast build step feels like pulling teeth when one’s used to a simple edit-save-run cycle; and Hugo currently takes about 5-10 seconds (!) to build on my no-slouch workstation, even with all its dependencies cached. Complete lack of built-in dependency version metadata: simply inexcusable for a language developed in 2009. Third party solutions exist, but are far from widely used. This makes debugging specific versions enormously frustrating if anything in the dependency tree ever breaks backwards compatibility. (Surprise: that happens frequently!) Plan 9 CLI flags: also inexcusable for such a new language. Sure, let’s use obscure -os -nobody -uses -style instead of what --literally --everyone --else -d -o -es.