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.

Mon, Apr 18, 2016 | personal

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.





Sun, Sep 29, 2013 | documentation, maintainership, sphinx

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.