found drama

get oblique

Standard Markdown

by !undefined

Mixed feelings about Standard Markdown. (Or Common Markdown, whatever.)

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”.

architecting CSS for a large scale project

by !undefined

Ben Frain (Enduring CSS: writing style sheets for rapidly changing, long-lived projects) 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.

review: If Hemingway Wrote JavaScript

by Rob Friesel

If Hemingway Wrote JavaScriptReading this book, I am reminded first of my friend Mike. Of an evening in Baltimore at a mutual friend’s home. Of vodka consumed and books given conversational chase and perhaps not a small amount of hero-worship on my part as he accelerated into his chosen field and I languished behind a copy machine at the worst-performing Kinko’s in the country. 1 House of Leaves may have been involved. 2

And I am reminded of my friends David and Jeffrey. Of our many lunches together and how they would veer wildly from one niche subject to another. Obsessive discussion of the high-precision clock in the Web Audio API lapses into puns cobbled together from pop songs which climb slowly into something about the Stoics.

And I am reminded, as I so often am, of that quote from Eric Miraglia in the foreword to Nicholas Zakas’ Professional JavaScript for Web Developers. The one that describes front-end development as being stocked with “many liberal arts majors drafted into web-developer service during the dotcom boom”. 3 And it’s with this intriguing lens that I focus as I step back from Angus Croll’s If Hemingway Wrote JavaScript. Continue reading →

  1. The actual performance ranking of that particular store is apocryphal.[↩]
  2. See also: in which we flash back about two years to when this thing first emerged: Danielewski.js[↩]
  3. And looking again at that quote, it maybe doesn’t say exactly what I remember it. But the gist is basically the same. And I know an awful lot of front-end developers that are formerly (and/or aspiring) musicians or physicists or novelists or farmers or what have you.[↩]

“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.

dream.20140811: stalled brew

by Rob Friesel

After being the first person to crowd-surf at a company meeting (and this after asking one of the all-time out-of-left-field questions), you retire to your home to start in on brewing your first ever batch of beer. You expected to be joined by at least one friend for help (and company) but upon opening the door you discover two things. First, that home has shrunk to the size of a college dorm room. And second, that your friend has divided into about a half-dozen people. You start collecting everything, but the room has become a moving target. You jury-rig a little shelf and start laying out the ingredients, but the moment your back is turned, one of these “friends” has tried rolling the hops into a joint. The carboy is suddenly full of pennies. The room shrinks. You’re elbow-to-elbow. It’s hard to breathe. The room fills with smoke. There’s a knock at the door.

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”.