A thread on Lobsters got me thinking…what would I want out of an ideal emplyoment situation?
Since I am cheerfully funemployed as of August, I figure I have the time to delve into this a bit. This is all dreaming big; I am under no illusion that any place like this actually exists. It’s naive, but after a decade in industry I think it might be nice to take a break from pragmatism. And yeah, some of these are not the way I live my life currently for one reason or another.
I’ve been looking more and more at the ideas behind building comfynets–small self-hosted collections of tools and pages for communities. I’ll probably do a writeup on the sort of stuff I’d like to see in one.
Anyways, one of the bits of fallout from a backchannel I sysadmin involves the custody of data. We’ve got a chat instance setup which supports persistent messaging and so forth, but it’s backed by a database. I am currently the only one who has access to said database and I’m eventually going to be handing the whole mess off to somebody else in the community to deal with since I don’t want the responsibility anymore. Anyways, that’s a second tangent and writeup.
Today I finished reading George Orwell’s Homage to Catalonia, which is a first-person recounting of his experiences fighting Fascism during the Spanish civil war. Scattered thoughts follow.
The author
I want to point out that George Orwell was a true mensch–and that his wife was amazingly competent and patient, both for putting up with his adventurism and then saving his ass when the secret police came knocking. In the author’s own words, he set out to Spain to shoot himself a Fascist, and participated in the most direct of action until he was shot in the throat.
This post was originally going to be about how I provisioned a 20TB NAS using ZFS and NixOS. At lunch today I got word that my old boss and friend Michael (Mike) had passed a bit over a week ago, so instead I’m going to write about a few good memories of him by way of celebrating his life and my privilege of having been part of it for a few years.
Once upon a time I worked on a web-hosted research platform for human-robot interaction. My colleague and I partnered to make a nice series of games which could phone home, log results, and show data.
It was built on JS, jQuery, Rails on the backend, and hosted on Heroku. I’d later rewrite the backend to be a much smaller node-based one. I think we may have been the first group to get ruby on Rails into an ICRA paper!
This is a quick little ramble about the scope of minimum viable products (MVPs), their schedule for creation and delivery, and finally the interplay of those things on developers.
What’s in an MVP
The entire purpose of an MVP is to create the simplest, cheapest expression of a business idea possible to test if the market wants the thing you’re making.
Ways to succeed:
Your MVP should contain be clear, incremental step towards a business feature or idea–ideally testing only one thing.
Your MVP should be instrumented/monitored to figure out if it is actually creating results for the money funnel.
Your MVP should be cheap enough you don’t care if you need to replace it or throw it away. There’s no point in running an experiment if you’re not gonna try new things when if it doesn’t pan out.
I’ve been assembling furniture and rearranging my office into a semblance of a standing-desk, so I’m gonna be pick a quick topic for today.
This morning around 0930 I was awakened by a text from a friend who was distressed that a community I sysadmin seemed to have no server active. I immediately sat up in bed, stretched a little, and sprung shuffled, yawning, into action.
I did what I’d consider a bare-minimum outage response and report, and I figure I’ll share that today.
Software testing philosophy is softball subject for blog posts, and after a month of fighting with a NAS build I’m in the mood for an easy write-up.
This is an adaptation of a work thread where I reflected a bit on testing practices, why we test things, and mostly importantly which things we as professional developers should emphasize and put in the extra effort for.
Fuckhueg disclaimer: The following all assumes that the software being worked on is not library code, being produced to serve as a fundamental reusable component for other folks. It similarly assumes the software isn’t being done in a regulatory regime (say, United States DoD or FDA) where testing values and procedures are spelled out. Either of those domains likely requires a different mindset about testing.