found drama

get oblique

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

Aaron Gustafson, A Fundamental Disconnect:

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.

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.

from 10 seconds to 3 seconds

by !undefined

Switching Ghost From Ruby Sass to Libsass by Paul Davis (Front-End Architect at Ghost) and the story of how they dropped the Ruby dependency from the project and moved Ghost’s SCSS compilation to Libsass.

At the end of the piece I’m still left wondering what (if any) changes they needed to make in the SCSS source itself to support the switch, but seeing the details about how they switched up their compilation was useful.

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

by !undefined

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

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

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.