found drama

get oblique

Zakas: no accidental standards

by !undefined

In The Bunny Theory of Code, Nicholas Zakas underscores the reasons to emphasize only checking in code that you understand:

In my current role at Box, I’m famous for repeating the phrase, “no accidental standards.” We don’t accept that things are “the way” just because they pop up in a couple of places. When we see this happening, we stop, discuss it, and either codify it as “the way” or disallow it. We then update code appropriately before it gets too far. Through automation, code reviews, and code workshops, we are able to keep an eye on the code and make sure we’re all on the same page.

“I’m just listening and conserving energy”

by !undefined

On Conferencing While Introverted by @beerops:

Introverts often listen more than they talk in conversations, and the less energy they have, the more quiet they’re likely to get.

Talks specifically about how conferences (though enjoyable) can really wring out an introvert. True stories that translate right back to the rest of our daily lives. (Where “our” is the rest of us introverts.)

Sharp’s 3 Phases of a Code Review

by !undefined

Recently recommended to me by a friend, The Gentle Art of Patch Review by Sarah Sharp posits that effective code reviews have three phases. First: is the proposed idea even “good”? (Is it consistent with the project’s aims? Does the feature add value?) Second: is the architecture correct? (Stay out of the weeds; keep the feedback high-level.) Lastly: is the patch polished? (Now is the time to unleash your inner pedant and invoke the iron fist of the style guide.)

Sharp argues that this style of code review benefits the maintainers, the contributor, and the community around the software project. It allows for the right level of feedback to happen at the right time, and because of that, it avoids problems with people getting (for example) over-invested in a patch that isn’t appropriate to the project, or else getting discouraged because of nit-picky feedback right off the bat.

search term haiku: May 2015

by Rob Friesel

Domo-kun on phone
Ginger Snap Saison F.G.
germinating peas

“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.

personal milestone: first 5k

by Rob Friesel

Craft Brew Race - Stowe

Yesterday I hit a personal milestone, and cajoled myself into running 1 my first 5k. It was the Craft Brew Race in Stowe, VT. I enlisted two friends to run the race with me and though they beat me by several minutes, I was grateful for the support. My official time was 33:50.

Craft Brew Race (Stowe) - official time

Full disclosure: I was primarily motivated by the beer garden at the finish line… Wherein I used my little plastic cup to sample 10 fine beers:

  1. Another VT IPA
  2. Burlington Common
  3. Gold Rush HPA
  4. 14th Star Golden Wheat
  5. Kind of the Yahd
  6. Light in the Window
  7. Pond Skimmer Pale Ale
  8. Crop Bavarian Weizen
  9. Bent Hill Blood Orange Imperial IPA
  10. Paine Mountain Fubar

And so, to my friends Dave and Michael: Thanks for joining me — a good time, and gives me a benchmark for the next 5k.

  1. Mostly running.[]

“a good thing being able to configure a framework”

by !undefined

The Future of the JavaScript front-end framework, by Robert Greyling:

It’s a good thing being able to configure a framework, and even better when those configurations fall back on conventions, but being able to swap out parts of a framework, or better yet, leave them out entirely is crucial when it comes to building web apps today†Š–†Šespecially with the explosion of mobile devices.

More/less the same drum getting beaten by so many right now (see also: the Joreteg’s announcement about Ampersand, although this opinion piece is probably a better illustration of the theme) – and by that I mean: “Go ahead and provide an all-inclusive framework, but be modular so I can swap out the parts I need.” Which is great, but I would say misses a big point: discoverability of those modules. Say what you will about Spring’s role in the Java eco-system, but its worthwhile to align with a single trustworthy starting point. Part of what’s missing from the “framework fatigue” discussion is just that – that our “big frameworks” only provide a relatively thin slice of what our whole app needs and we’re in “contrib” (and/or plugin, and/or mixin, etc.) hell for everything else. This glosses over the BIG-Big frameworks of a few years ago (e.g., dojo, ExtJS, YUI), but the point stands.

(A version of this previously appeared as my comment on Prismatic.)

dream.20150527: pit of despair

by Rob Friesel

Interviewing Rob Zombie, moments before a concert. The backstage room is oddly well-lit and sparkling clean. (You expected gloom and filth?) There isn’t much time for questions. You jump right into it. What’s your greatest fear? your personal hell? He explains: Being cast into pit of writhing tormented bodies, and each one is a clone of a “Saved by the Bell” cast-member. The description is so vivid. And you are there.

Nash on Joint Cognitive Systems

by !undefined

Courtney Nash, Ghosts in the machines:

It feels intuitively right: computers are better at plugging through repetitive information very quickly, humans are better at context-specific, qualitative judgments about that information. But the problem with this approach is that day-to-day tasks in the world we all operate are not so neatly composable in this way – we are constantly moving between a variety of tasks that could be more easily done by either machines or humans.

Hits on a lot of good points. Implicit here (viz., not called out) is the fact that if DevOps is about increasing the humanity of designing, implementing, and managing big systems (and make no mistake: that is what it’s about) then the notion of Joint Cognitive Systems becomes very important. “Divide and compensate”, MABA-MABA approaches arguably just turn the operators into slaves of the automators automation, and potentially make things even more chaotic.