found drama

get oblique

Monthly Archives: September 2014

trifleJS

by !undefined

trifleJS:

“Headless automation for Internet Explorer”

Which looks like a port of (part of) the PhantomJS API to an environment that wraps IE by way of some .NET controls. (Also: V8 is in the mix somehow and/but/so not sure how that changes the equation w/r/t/ if the IE runtime is using that as the underlying JS interpreter or if it’s just some kind of bridge.) See also: SlimerJS : Gecko :: PhantomJS : WebKit

And speaking of SlimerJS: its API is also “PhantomJS-compatible” which raises the question of whether we need to be doing some work to create a “headless browser scripting” standard that we can reliably lean on, or if we’re just going to accept that PhantomJS came first and everyone is going to ape its API.

the boring designer

by !undefined

“The boring designer chases the right idea over their idea every time. They respect their team and will try almost any idea (whether on a whiteboard or in Sketch or in code) that gets thrown their way. Instead of arguing about whose idea should win, the boring designer tries all the ideas and even elevates others’ ideas in the process. The boring designer abhors groupthink and being told “yes.” They consistently request feedback and new ideas. And as a result when they feel super passionately about their own idea, the team listens.”

Cap Watkins, The Boring Designer

So many of these points translate (or apply directly) to lots of other leadership roles, technical or otherwise.

HELP WANTED: User Experience Researcher/Designer

by Rob Friesel

Job Type: Full-Time/Regular Job Level: Mid-Career (2+ years) Years of Experience: 10+ Years Level of Education: BA/BS/MA/PhD/MFA/DDS Job Description Metavaprwaresoft.ly, a fast-growing VC-backed lean start-up, is seeking experienced, skilled, and passionate innovative interactive interface interaction designers who dive in head-first and seize challenging applications by the horns. We are looking for developers that blur the […]

re: “Why Scrum Should Basically Just Die In A Fire”

by !undefined

Why Scrum Should Basically Just Die In A Fire:

By Giles Bowkett.

I was resisting the urge to post anything beyond my remarks on Prismatic, but this made enough of the rounds among my circle that I felt compelled to chime in with a couple of follow-up thoughts.

First: we know that Bowkett is smart; we also know that has a tendency toward writing in a deliberately inflammatory or provocative fashion. Given the latter point, I would just chalk this post up to being another “conversation starter” (at best) or else (at worst) the tech-worker equivalent of clickbait.

Unfortunately, what we have here is “Agile” (in general) and Scrum (in particular) playing scapegoat for the bad behavior and cascading ill effects of what is usually just a handful of unfortunately influential but highly poisonous people within a given organization. Scrum, much like democracy, is just a system that can be used, misused, abused, well- or poorly understood, applied genuinely or cynically, etc.

That is a long-winded way of saying that, to the extent that Bowkett is saying that Scrum is flawed… Well, Scrum has problems that make it corruptible. And in that respect, he’s right.

But there’s something that seems a bit self-aggrandizing and disingenuous in his post. The gist: he has an apparently never-ending parade of examples of how Scrum is broken, and how every organization screws it up, and how some poisonous person (usually a manager) is responsible for screwing it up for everyone. But then he has this anecdote about how he got some poisonous CTO fired.

Wow. Now imagine if that situation had played out for all those other poisonous directors, project managers, etc. that he cited. And I pause to ask: why didn’t that happen? Lack of influence? Lack of courage? Inability to recruit allies? Simple lack of effort? It’s a mystery to me because clearly you don’t take on a CTO without those elements at play.

To blame Scrum rings hollow to me. Every one of the scenarios he describes just sounds like someone poisoning the well and the people around him (or her) failing to deal with it for one reason or another.

Which is not to suggest that Scrum is going to save those organizations. Some places are too dysfunctional to survive. But blaming Scrum is like blaming the building or your desk. Move down the block and switch to a standing desk if you want, but you’re still the same people with the same dynamic. Scrum might help your team change its frame of reference; Scrum practices might promote better transparency between you and the rest of your business; but chances are you’re just going to spend the first couple of iteration learning how broken things are and if the business isn’t prepared to deal with that then guess what? Scrum wasn’t going to help you anyway.

His post has plenty of good points. But “Scrum should basically just die in a fire”? Sorry; you’re optimizing the wrong problem.

(And then there’s that wink-wink-nudge-nudge suggestion about how engineers are somehow the superior breed and let’s not go into that tired notion.)

on polyglot programming

by !undefined

Developers are calling it quits on polyglot programming:

Matt Asay, writing for TechRepublic.

Yes, but… (and this is a big but)

I don’t think it’s that developers are “calling it quits on polyglot programming”. I think what we’re seeing (and he touches on this toward the end) is that ultimately developers just want to be productive. Developers will dump Java for something like Groovy because it makes them more productive. (Ditto Scala; ditto Clojure; ditto Ruby; &c.) The Tim Bray quote is a big tell here to that point. It’s exciting to get the opportunity to learn new things; but it’s anxiety-provoking to walk around feeling like you’re expected to have deep knowledge of a hundred unrelated things.

This is what underpins the discussions around “back-end vs. front-end” developer and/or someone who is a “Java developer” vs. a “full-stack developer”. There’s a certain amount of breadth that you need, and ultimately you should stay curious and get out there and learn some new things, but you’ll also suffer if you never settle down for a second and go for depth on a chosen subject.

basically asset-pipeline for SpringMVC

by !undefined

Cool stuff presented by Brian Clozel and Rossen Stoyanchev at SpringOne last week. The tl;dr version would be “Rails-style asset-pipeline stuff for SpringMVC” — but it looks like it goes a bit beyond that. Should provide some nice solutions to static asset and resource management for Spring-based applications, and timely as Spring Boot gains traction.

the illusion of control

by !undefined

“The fundamental problem with viewing JavaScript as the new VM is that it creates the illusion of control. Sure, if we are building an internal Web app, we might be able to dictate the OS/browser combination for all of our users and lock down their machines to prevent them from modifying those settings, but that’s not the reality on the open Web.”

Aaron Gustafson, A Fundamental Disconnect.

This isn’t (just?) FUD around JavaScript and web apps, it’s the reality. And this is the timbre of so many posts over the years: that you have no control over the ultimate runtime of your application’s interface and therefore [fill in the blank].

And so we’re left in this weird never-never land where we can’t really spend all the resources that we need to ensure that we’re reaching (literally) everyone, but neither can we justify rubber-stamping a “best in WebKit (on top of modern hardware)” banner as a way of coming in under-budget. There’s the notion that you can just follow a couple of best practices and be just fine but this doesn’t really acknowledge that not everyone doing front-end development is a Front-End Developer.

To Gustafson’s point about Hanselman’s point about JavaScript deployment basically being a VM… I wouldn’t say that he’s being unfair. After all, Hanselman is a smart guy and I must imagine that he’s making these statements in a sort of Inspired Visionary way. But at the same time… yes, calling the browser a VM is over-selling it a bit. And for all the reasons that Gustafson spells out.