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”.
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.
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.
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 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”.
Improve Your Tests by Breaking the Rules: Mike Pennisi, writing for the Bocoup blog.
Intentionally provocative? Simple pragmatism? The insane ramblings of a desperate developer? Regardless of your read of this read, we should all aspire to put this ki…
“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.
“I suspect that even the designers of Unix shells are often surprised at the inventive uses developers have wrought with their simple but powerfully composable abstractions.”
–
Neal Ford, Why Everyone (Eventually) Hates (or Leaves) Maven
A post on composable systems (vs. contextual ones). It’s a thoughtful post, and worth a slow and careful read.
Reminder and/or public service announcement. (via How GitHub Uses GitHub to Build GitHub)
By Nicholas Zakas, at NCZOnline.
I especially like this bit:
An alternate proposal mentioned in his twiki is to create a
element that logically groups script files together:Â Â
  Â
  Â
  Â
 Â
Though I think personally would prefer