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 )

About Rob Friesel

Software engineer by day, science fiction writer by night. Author of The PhantomJS Cookbook and a short story in Please Do Not Remove. View all posts by Rob Friesel →

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*