found drama

get oblique

Category Archives: Code

Shell scripts, JavaScript pedantry, CSS fixations, Java debugging, and the rest of the polyglotism.

initial thoughts on Aurelia

by !undefined

Introducing Aurelia:

My first reaction is (of course) that this is why a lot of developers look at JavaScript and the web front-end see only thrash, and feel only fatigue. And in this case in particular (given Eisenberg’s previous project involvements), it smells a bit of icarian hubris.

And in that respect, you won’t find me among the early-adopters. (Taking a page from “sometimes better isn’t better if it’s different” here.)

That being said, this isn’t to suggest that there is nothing interesting happening in the Aurelia project. Count me with Tom Dale (here, and a couple of the tweets that immediately follow) in that the pluggable data-binding seems like a huge takeaway here and that we are going to see that in every framework, that you can’t have a compelling inter-op story without that. But much of the rest of what’s being pitched here (e.g., modularized code, no external dependencies, “just vanilla JavaScript”) — that’s all stuff that we’ve heard before.

(As a brief aside re: the icarian hubris remark above: let’s not lose sight of the easy-to-see flip side of that: that if anyone is going to propose a new framework, who better than someone like Eisenberg? who better than someone has been deep into other projects like this? And/but that’s also where the disappointment comes from — that it just winds up feeling like yet another technical leader decides to zig instead of zag, to go off and create a new thing instead of doing the hard work of taking something and making it better.)

Elhage re: simple software engineering lab notebooks

by !undefined

Lab Notebooking for the Software Engineer:

Oldie but goodie by Nelson Elhage at the “Made of Bugs” blog. I mostly agree with most of these points, and consistently break the rule about only keeping a chronological journal, as opposed to trying to bucket them under application-specific or domain-specific journals. (That’s a flavor of Premature Optimization and don’t try to let anyone tell you otherwise. [And right here you can expect me to insert all of the exceptions to that rule that I’ve cooked up over the years.])

One thing that should go without saying, and is a bit of advice I’ve given over and over again that dovetails well with Elhage’s post here: feel free to slow down on your “lab notebook” at any time, but the moment that you feel yourself getting scattered, go right back to a disciplined notebook. Nothing makes you slow down and focus on The Right Things quite like keeping a record — no matter how informal that record it.

A Framework for Modern User Stories

by !undefined

A framework for modern User Stories:

My inner Scrum Master got a little bit excited about this.

What I liked about it is the attention it gives to the language of a User Story — right down to the specific words that are used to make the statements. Granted, the other thing that I liked about this piece was how it both embraces the traditional User Story format, while updating/expanding it a bit to allow for more information to get “built in”.

You could argue that what’s added should have been encompassed by Acceptance Criteria anyway, but using BDD statements here seems more constructive. (…because they easily convert into acceptance tests.)

re: Peter Bell on “Innovation Debt”

by !undefined

“Just as technical debt can kill a code base by turning a green field project into a big ball of mud, innovation debt can kill an engineering team – moving them from a cutting edge crew to a group that’s barely competent to maintain a legacy app.”

–

Peter Bell, Innovation debt

There’s the argument that “innovation debt” is just another form of technical debt — that the latter isn’t just the tests you didn’t right, but the opportunity costs of not exploring alternatives.

What I like about this post is that, assuming you take a measured approach here, you can use a combination of these techniques to keep engineers interested and happy. You can give people the room to explore some new technologies and maybe, if those technologies actually are good choices, then by all means bring them into the stack.

That being said, it’s almost too easy to read Bell’s post and use it as a justification for your own Magpie Syndrome. A “culture of learning” is great — but recognize that your exploration can also lead to another, equally valuable bit of knowledge — the knowledge that after exploring some new piece of technology, that it’s actually not a good idea to move forward with it. Trying new things is fine — and you should explore alternatives — but sometimes your innovation is “add Java 8 streams” and not “rewrite everything in Scala”.

I also feel like it’s worth calling out (for the tech leads in the audience) that not everyone wants to do shiny new stuff all the time. (See also: Matt Asay’s thing re: “developers calling it quits on polyglot programming”.) “Innovation debt” as Bell describes it sounds like it goes a couple ways: the “explore innovative shiny new things” way, and the “double-down on what you have and make sure your engineers know their shit” way. Ignore both at your peril.

“Code that has been merged and not deployed is a loaded gun.”

by !undefined

“Code that has been merged and not deployed is a loaded gun. If I merge in my changes and don’t deploy them, and you then merge and deploy yours, you’ve just deployed mine too. This was more than you bargained for. It’s now more likely that your deployment will break something, and harder for you to fix if it does.”

–

Baron Schwartz, Why Deployment Freezes Don’t Prevent Outages

I prefer to think of these more as “environment freezes” than code freezes, but that’s just the name on top of the same thing. There’s a lot of smart things being said in here, and I can’t think of any points with which I disagree. A freeze lasting longer than the duration of a demo (e.g., a few hours, max) is damaging.

That being said, this extends pretty easily to any code that isn’t merged to master and deployed to at least some environment. Even without a code freeze, the longer you wait before you build and deploy, the more likely you are to experience some pain and suffering. (Hence my choice of pull quote here.)

Remy Sharp: My five promise patterns

by !undefined

My five promise patterns:

Remy Sharp’s write-up of several patterns that have emerged from his usage of promises. By itself I feel like this one winds up reading a lot like a few other Promise-related posts that I’ve seen (and/or like an inverse of this anti-patterns post) — but his discussion around throw vs. reject is worth the price of admission.

“more than just picking a few JavaScript solutions”

by !undefined

Planning A Front-end JavaScript Application:

Thoughtful piece by Cody Lindley over on the Telerik Developer Network. Even if you don’t agree with all of his points, he definitely sketches out a good framework for how to approach the problem of getting your application off the ground.

A couple of additional points here:

  1. Don’t get caught up in the specific technologies that Lindley is using in this article. They’re just there as examples, and he doesn’t appear to be strongly advocating for any of them — just that you consider something to fill in that blank on your project.
  2. There’s a bit of YMMV going on here depending on the specifics of your situation. That being said, most of the key lessons here should be easy to adapt — give or take a couple of questions on the checklist.

Again: look past any knee-jerk disagreements you might have (e.g., API first development; e.g., no RWD for “web apps”) and draw out the larger questions.

Abraham Polishchuk on AngularJS Performance

by !undefined

AngularJS Performance in Large Applications:

Abraham Polishchuk presents us with a fairly comprehensive break-down of some performance do’s-and-don’t’s for large AngularJS applications. (Although there’s nothing in here specifically about the sizes of the applications themselves.) He covers some basic JavaScript performance techniques at the beginning before diving into the AngularJS specific items. The key takeaways seem to be (1) to limit the number and contents of scopes and (2) to avoid the AngularJS event system. Some of it reads like FUD (“Don’t use filters!”) but there’s also good advice here, especially w/r/t/ limiting scope and in particular his points about limiting the use of `$watch`.

That being said: this seems to align with my recent criticism — that it isn’t so much that AngularJS itself isn’t performant, but that it’s (arguably) too easy (using the “by default” features) to get youself into a poor performance situation.