Test Talks #24
¶ by !undefinedTest Talks #24: Rob Friesel re: The PhantomJS Cookbook: [PODCAST] Wherein Joe Colantonio interviews me about PhantomJS, JavaScript/front-end testing, and my book.
Shell scripts, JavaScript pedantry, CSS fixations, Java debugging, and the rest of the polyglotism.
Test Talks #24: Rob Friesel re: The PhantomJS Cookbook: [PODCAST] Wherein Joe Colantonio interviews me about PhantomJS, JavaScript/front-end testing, and my book.
Ian Darwin’s Java Cookbook is out and it’s a great resource for developers working in Java that are out there and scratching their heads asking “How would I go about…?” The thing that makes Java Cookbook stand out is its comprehensive scope. Darwin has done an excellent job of gathering a wide array of common […]
Rambles around computer science:
Thought-provoking piece by Stephen Kell on type systems, type-safety, and what a lot of people mean when they talk about it. My main takeaway from Kell’s piece was that type systems, like everything else in programming/computer science, comes with trade-offs and though there are many advantages to using a language with good type-safety, it’s also not a panacea and to believe so is dangerous and naïve. Part of what’s interesting here, is that he claims that many people are simply semantically wrong when talking about “types” when what they are discussing is actually compile-time checking, use of predicates, or other abstractions.
Why I Don’t Want Your JavaScript Framework but I Love You:
A very worthwhile read from Keith Rosenberg.
If there’s a tl;dr then it’s this: choose when to use a framework, not which framework — if you choose any framework at all, and/but/so when you do: take the time to get to know the source code, not just the docs.
Rosenberg has lots of good points in here, and while no single pithy quote jumped out as pull-worthy, it’s worth noting that he doesn’t simply dump on frameworks (as some do) but rather tries to ask the more interesting meta-question re: why are you even choosing to use one at all?
Obviously there are plenty of reasons to use a framework. There’s that old adage about either spending your time learning the framework or spending your time building all the home-brew infrastructure that turns in to your own personal framework. What Rosenberg points out though is that if you’re not digging deep into the source, then you’re not really learning, and you wind up in a bad place anyway — surrounded by all the framework magic that’s undocumented and you don’t understand, can’t debug, and spend days trying to work around, over, under, or through.
(Having been guilty of the above, and having been there myself, I cannot stress that enough.)
As he says: take the time to think about your problems and spend some time designing your application and discovering what you really need, instead of just diving in with your AngularJS life-jacket because that worked out so well on that last thing your build.
(Previously/related: RE: Developers are calling it quits on polyglot programming.)
“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.
Ben Hughes, JSON and the Arguments: tl;dr: General argument is that JSON is hard to read and the format spec explicitly disallows comments. The former point I disagree with completely; 1 the latter point is fair and/but that’s also why I think something like a Gruntfile is good because it uses functions for configuration (but […]
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.)
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.
“The truth of the matter is this: you are woefully unprepared for a career in management, and you are unaware of how badly unprepared you are.”
– Lindsay Holmwood, It’s not a promotion – it’s a career change
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.