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…

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 off¹ 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.

I start at mLab – the world’s leading MongoDB hosting company – tomorrow.

The next round of Paramiko releases is now out on PyPI, including – as previewed here – 2.0!

For some time now, plans to switch Paramiko’s crypto backend from PyCrypto to PyCA’s Cryptography have been in motion. (Sometimes, slow-motion. Sorry.) These efforts are drawing to a close, and because they represent a nontrivial change in install dependencies – even though there aren’t any public API changes – we’re going to call the result Paramiko 2.0.

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. For a language well suited for runtime-agnostic CLI tool distribution. I can’t wait to play “is tool -ca a single ca flag or two c and a flags together?” all the time.
• General syntactical disagreement: solely opinion, but I’m not a fan of the (much-ballyhooed) error handling, nor the total lack of quality-of-life shortcuts such as “if x in y”. (Pythonistas appreciate low mental overhead, but that’s going too far IMO.)
• Poor extensibility: mostly theoretical, but AFAIK due to being compiled, Golang apps cannot execute user code at runtime, as interpreted languages often do. This makes tools like static site generators more limited: they can’t build extension points for users to jump off. Either it does what you want, or it doesn’t.

Until this experience, I didn’t realize how much I took Python and Ruby’s hack-friendliness for granted. Poking a Python codebase to figure out if given behavior is a bug or not, for example, is incredibly easy. I hadn’t foreseen that similar actions in a Golang project would be far more painful than simply muddling through a new-to-me syntax - but it was.

I’ve rebuilt my website! This post isn’t likely to be interesting unless you’re into static site generators or navel-gazing. It’s also not too long, as I’m omitting almost all the gory details.

I’ve been horrid about blogging lately, but didn’t want 2015 to pass with exactly zero posts. First is an open source review/update (the good & the bad), with some more personal topics afterwards. If you’re the skimming type, I bolded the important bits.

Some quick thoughts based on recent Twitter conversations about Python version support in OSS projects, presented in (ironically, given the topic) lazy bullet list format.

A bunch of notes about Paramiko, Fabric and Invoke, such as their websites, their Python 3 support, and more! With copious exclamation points!

Most open source projects store documentation in the source repo itself. This is easy to do, allows the doc builder to reference in-code documentation (like Python docstrings), makes contributions from others simpler, etc.

However, it doesn’t always play nice with “meta” information such as how to contribute, project roadmap, and so forth.