found drama

get oblique

Category Archives: tech

Reviews, speculation, and other idle thoughts on hardware, software, firmware…

Anne Lu: Testing with Casper-Phantom-Mocha-Chai

by !undefined

Testing with Casper-Phantom-Mocha-Chai – Anne Writes Code:

A good introductory blog post by Anne Lu about using Mocha (with Chai) in combination with CasperJS. It hits the essential points about using CasperJS, and also shows how simple it is to plug in a third-party test apparatus like Mocha. (Oddly though, her post lacks links to Mocha and Chai and I feel like some readers might get caught off-guard by the “language chains” feature of the casper-chai library.)

the programming equivalent of staring at the abject

by !undefined

“But it has always seemed to me that confronting unfathomable code is the programming equivalent of staring at the abject, of slowing down to peer into the carnage of a car wreck.”

– “The Beauty of Code”, an excerpt from Geek Sublime, by Vikram Chandra, as it appears in Paris Review.

Standard Markdown

by !undefined

Standard Markdown:

(Or Common Markdown, whatever.)

Mixed feelings about this.

As I always understood it, “the point” of Markdown was to have a (very) simple “plain text” format that you could scan/read easily without putting it through a parser. Because it was plain text. Right?

A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. [source]

And in that respect, there should be no need to standardize.

On the other hand, Markdown is so widely used that it’d be nice if there were some consensus around how to “do” certain things with/in it. That being said, aren’t most of the “problems” just a result of trying to do complicated things?

Romantic Versioning

by !undefined

Why Semantic Versioning Isn’t:

Jeremy Ashkenas on SemVer. Lots of good points in here.

SemVer is a great idea, but I’ve always been a bit skeptical about how useful it really is. It’s nice to distill down the versioning to the {major}.{minor}.{patch} but ultimately you (the developer/project maintainer) are making an arbitrary best-guess decision about which number is getting incremented.

So yeah: “Romantic Versioning”.

RIP YUI

by !undefined

Important Announcement Regarding YUI:

I was never a big fan of YUI, but it was an interesting framework, and an example of how to approach the design and assembly of a large, comprehensive project. The list of contributors is long and distinguished. I’m a bit sad to see them torpedo the project, but not all together surprised either.

architecting CSS for a large scale project

by !undefined

Enduring CSS: writing style sheets for rapidly changing, long-lived projects:

Ben Frain on “architecting CSS for a large scale project”. My initial reaction: “Another one of those CSS best-practice articles…” And in many ways this is ground we’ve covered before. FUN, SMCSS, OOCSS, BEM — a CSS system by any name is just a bunch of design/organization patterns that the new member of your team isn’t going to understand. But for all the effort that Frain puts into trying to frame his “FUN” technique, it may be easy to lose sight of one of the most important points he makes:

As a concrete example; being able to delete an entire Sass partial (say 9KB) in six months time with impunity (in that I know what will and won’t be affected by the removal) is far more valuable to me than a 1KB saving enjoyed because I re-used or extended some vague abstracted styles.

And that is the key lesson.

“my fallible conclusion”

by !undefined

Opinionated Rundown of JS Frameworks:

Henrik Joreteg, writing at the &yet blog. He does a brief teardown of 5 front end MVC(ish) frameworks (their pros and cons) and while you’re busy coming up with counter-arguments against his inevitable thrust about using “no framework”, he goes on to make almost exactly all of those same points.

Only to wrap it up with what winds up feeling a bit like a sales pitch for his Ampersand framework.

This is not necessarily bad, and he does acknowledge that each team needs to decide for itself what it wants/needs in order to make it effective. At the end of the day, this isn’t a competition to find out what framework is the best (spoiler alert: none of them) — it’s a struggle to find effective work strategies so that we can build great software that solves real problems for people.

Manufacturing the Talent Shortage

by !undefined

Manufacturing the Talent Shortage:

By Dimas Guardado, writing for Model View Culture. (Which, if you’re not making it a regular habit of reading the posts at Model View Culture, then you should get into that habit.)

This piece, combined with Carlos Bueno’s Refactoring the Mirrortocracy (which Guardado cites) should be required reading for anyone doing recruiting, interviewing, and/or hiring these days.

These two posts have been sitting as pinned tabs in my Chrome for a couple weeks while I figured out what to do or say about them. Ultimately I decided that there was no single pull-quote to lean on. But they’ve both got a good underlying thesis about the misuse of privilege among people (yes, mostly men) in engineering organizations and especially in start-ups. For what it’s worth, the conclusion that it led me to? That phrases like “we value passion and aptitude” are code for “we have no idea how to mentor people”.

The Root Cause Fallacy

by !undefined

“That’s why the search for a root cause is usually a witch-hunt in disguise, trying to find someone or something to blame. If you think there is really a single cause, you eventually must identify a single person. If you stop short of that, everyone knows the process was a farce. But blaming a person is also a farce. Everyone knows that someone’s being thrown under the bus and that wasn’t the real problem.”

–

Baron Schwartz, The Root Cause Fallacy

“Fallacy” might be a little strong, but yes, a dysfunctional post-mortem will descend into a witch-hunt and someone can wind up on the horns without any real solutions being proposed. Not that no one ever deserves to get strummed out, but it can’t be your first reaction.