found drama

get oblique

Linkdump for October 16th

by Rob Friesel
  • An interesting bit of hackery but Ryan Morr, although it smells a bit like a solution looking for a problem. (I'll stick with the original advice I got about using try-catch in JavaScript: "It's basically a measure of last resort. If you find yourself using it, you're almost certainly doing something wrong.") Even Morr himself points out the two biggest drawbacks to his proposed technique: (1) no stacktrace and (2) an immediate halt of the thread of execution.
  • Though he doesn't cite something like Gechev’s methods, Thomas describes using $provide.decorator() as the built-into-Angular solution for AOP. It’s a thorough example of how using the decorator function to modify services in Angular. That being said, I have mixed feelings about the slightly more complicated ($log.getInstance()?) version of $log that he ends up with.

    (As an aside: his use of RequireJS makes this not a "pure Angular" post and diminishes some of the value; although I can see why he went this route, I think it adds some unnecessary overhead w/r/t/ illustrating the specific points about decorator.)

  • Ryan Britt (at OMNI Reboot):

    Thinking about things outside of their regular context might be a lazy definition of sci-fi, but it isn’t wrong.

  • Rob Fletcher:

    Managing that kind of separation of concerns is the promise of Angular in a nutshell.

    A good case study in best practices with controllers and directives and how to think about separation of concerns in AngularJS. This is a particularly interesting post because there's a strong temptation when developing directives to "put it all in there" — that once you've gotten to the point of creating the directive, you're not really thinking about controllers anymore. But Fletcher puts it well:

    Remember controllers are for managing view state and directives are for managing the view implementation. If you find yourself mixing those concerns step back and think about how you can separate them.

  • Oscar Gordon:

    Everyone learns differently. There are absolutely people who use jQuery who don’t want to learn to program and just throw plugins at their problems. However, those are the same people who would be terrible programmers because they don’t want to solve programming problems, they want to solve design or client problems. So, instead of telling a new programmer playing with jQuery to stop and learn “real” JS first, offer them some book suggestions on vanilla JS or be there when they have those stupid questions. Even better, give them some project ideas with jQuery like making a plugin that involves those boring things like math such as a slideshow.

    Reminds me of the feeling I got after TA'ing that JS class for GDI.

    (tagged: learning JavaScript )

Linkdump for October 12th

by Rob Friesel
  • Steve Sanderson's popular KnockoutJS MVVM library has an RC out for version 3.0. I may not be its biggest fan, but there are more than a few times when it's exactly the right tool for the job and this looks like a nice improvement.
  • Craig McKeachie doing some side-by-side, feature-for-feature comparisons of a couple JavaScript MV* frameworks. His emphasis is mostly on AngularJS, Backbone.js, Ember, and Knockout, but a couple of other libraries make cameos as well. The title is a little misleading because he's talking less about the size of each framework and more about how "rich" each one is. He lays out some good points w/r/t/ things you should consider when choosing such a framework (and/or whether you should choose one at all).
  • Garann Means, How to rewrite your JS app (at least) 10 times For once, a presentation where you can get about… 75% of "the point" without needing to "be there". (And if it's anything less than 75% then she packed it in nice and dense.) What I like about this one here: acknowledging that even some of your good ideas come with their own perils, and/but some of those perils are inevitable and you just need to choose your battles carefully.

  • Sean Voisen's introduction to FRP with Bacon.js. I've mentioned both FRP and Bacon.js before, but I liked this intro article — Voisen presents some sensible, useful, and easily digestible examples.
  • Nicholas Zakas:

    To me, Node.js was never about replacing everything on the server with JavaScript. The fact that you can do such a thing is amazing and empowering, but that doesn’t make it the right choice in every situation. No, to me, I had a very different use in mind: liberating the back-end UI layer from the rest of the back-end.

    Node.js in the middle

  • Jan Dudulski, writing at the Codetunes blog. By and large, I think if you're dealing with $-prefixed properties directly, it's probably an AngularJS code smell, but this technique looks pretty smart, and I think we can trust $dirty and $invalid to be pretty stable features.

“Doing Nothing”

by Rob Friesel

This New Yorker piece by Nathan Heller (“Bay Watched”) came across my radar within the past couple of days. This is the sort of thing that would normally show up here as part of a “linkdump” but I had just a little bit more to say about it than that, so…

It took me a couple of attempts to get through it, partly because of the visceral reaction it kept causing. The knee-jerk pull-quote I yanked on my first time through:

…when Bahat reported on LinkedIn that he was leaving a job by changing his status to “Doing Nothing,” his New York friends fretted, and promised to let him know if they heard of any openings. His Bay Area friends, meanwhile, congratulated him on his exit.

As I mentioned elsewhere: maybe it’s the Type A East Coaster in me, but it made me feel ill. And maybe even a little bit angry — although maybe anxious is the more appropriate adjective. Continue reading →

sold my first piece of fiction

by Rob Friesel

In case you didn’t see it on any of my other social media venues: 1

I sold my first piece of fiction!

“Where the Air Is Sweet and the Clouds Are a Different Shape” will appear in Please Do Not Remove, 2 which is being edited by Angela Palm and should be coming out in Spring 2014.

More when there’s more to say.

Needless to say: pumped.

  1. A version of this particular announcement was first posted to Tumblr last night: notnonfiction.tumblr.com/post/63128312374; it was also mentioned in last night’s post 2013 Goals: Q3 check-in[]
  2. Original call for submissions was posted here: angelapalm.com/call-for-submissions/[]

search term haiku: September 2013

by Rob Friesel

germinate sweet peas
annotated JavaScript
Black Ops Latin patch

“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.

Linkdump for September 30th

by Rob Friesel
  • Alexander Zaitchik (Salon.com):

    You could fill an entire book with the Strangelovean rhetoric of the first two years of Reagan’s term.

    A still from the movie "The Day After"

  • Had this sent to me around the same time that this other (derived?) image was making the rounds. Russell's site is missing my personal favorites (the ships of the Wing Commander universe) but it's an impressive collection nontheless.
    (tagged: science fiction )
  • Jim Cowart:

    I've been using RequireJS for a couple of years, and while it's admittedly difficult to limit myself to only five, these five tips are things I really wished I'd known sooner rather than later.

  • Popular Science:

    A politically motivated, decades-long war on expertise has eroded the popular consensus on a wide variety of scientifically validated topics. Everything, from evolution to the origins of climate change, is mistakenly up for grabs again. Scientific certainty is just another thing for two people to "debate" on television. And because comments sections tend to be a grotesque reflection of the media culture surrounding them, the cynical work of undermining bedrock scientific doctrine is now being done beneath our own stories, within a website devoted to championing science.

    Sad in so many ways.

  • Andre Behrens (in NYTimes.com, of all places):

    Developers often think of programming as problem solving, but writing code is more like cooking. As with cooking, code is never perfect, only better and worse. You can try different spices. You can use turkey instead of chicken. You can apply more or less heat. But there is no complete, only done enough. Dinner is done when you eat it.

review: Jasmine JavaScript Testing

by Rob Friesel

518JeRoUfjLPackt Publishing recently released Jasmine JavaScript Testing by Paulo Ragonha (@pirelenito), and I just wrapped up reading it this morning. I’ve read a few books on JavaScript unit testing 1 and at least one other that was dedicated to Jasmine, 2 and this one is a strong entry.

If you’re unfamiliar with Jasmine, Ragonha will give you a solid foundation of the testing framework by the end of the second chapter. Less than 40 pages in and you’ll understand Jasmine’s approach to testing, as well as how to stand up a basic test suite. His coverage of the core functions and the collection of built-in matchers is concise and accurate. He builds on this foundation by demonstrating Jasmine’s abilities in testing everything from asynchronous code 3 to MVC components 4 to AMD modules. 5

Despite the title, Jasmine JavaScript Testing isn’t merely about the testing framework, or even just about testing. What Ragonha gives us is a book about how to write better code, using testability as the measurement of success. What is strongest about this book is how he uses a refactoring project as a frame-of-reference for telling the testability story. He’s not just talking about using Jasmine for writing tests; he’s talking about how to use it alongside the other tools and patterns that will make you a better front-end developer.

If you’re just getting started with testing JavaScript for the front-end, or if you want to see some good real-world examples, then I would definitely recommend this one.

Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.

  1. There was Mark Ethan Trostler’s Testable JavaScript; and then there’s Nicholas Zakas’ Maintainable JavaScript which, while not technically about testing, has at least the one chapter about it.[]
  2. Here I refer to Evan Hahn’s JavaScript Testing with Jasmine — not to confuse anyone over titles or anything.[]
  3. Sinon.js FTW here.[]
  4. He rather sensibly chose Backbone.js for these example.[]
  5. Require.js being the AMD library-of-choice here.[]