JS Balrog

Helmet is a nifty node module—it provides some protection from several types of application attacks. Here’s a great post that explains why you should be using helmet in your node apps.

However, I was getting a couple of errors in my angular-based node app, and on top of that, my livereload stopped working, which I really depend on in my dev workflow. One of the errors had to do with angular itself, the other had to do with the injection of the livereload script into my index.html. Here are the two things I did to fix these errors.

When it comes to objects—and especially singleton objects or factory instances—angular offerings are multiple-choice. I want to spell out the differences between angular-specific providers, services, and factories, and give some guidelines to when you would use each.

In this post, let’s take a look at the power of directives, and in particular, the power of isolate scope-based directives.

Last time I mentioned I was going to focus on some OO-related javascript concerns. For this post, I want to talk about a programming pattern that I use quite often: the Decorator pattern.

For a few posts we’ll talk a bit about programming javascript in such a way as to take advantage of OO principles of reuse, including encapsulation, inheritance, and polymorphism. Javascript of course has no concept of such things as classes; therefore, we use common javascript principles in order to take advantage of such things–even for how we define a javascript “object”. This post in particular will focus on javascript object creation.

As an Open-Source advocate, DRM—Digital Rights Management, or a way to control access to material in digital format—has long been a sticking point for me. International Day Against DRM is Tuesday, May 6th. Several publishing houses are marking this day with great discounts. One such publisher that I really like, Packt (pronounced “packed”) Publishing, is offering anything in their catalog for $10 during May 6th. Pretty sweet, huh?

(For full example code, see my angular-fullstack-tokens repo.)

I have an angular-fullstack based app (angular, node, express, passport), and I’m using token-based authentication following this great blogpost, rather than cookie-based, using express-jwt and jsonwebtoken.

I started with daftmonk’s angular-fullstack, replaced its authentication system with tokens (easy enough), then set out to include social-based authentication for facebook, using passport- facebook. I kept running into CSRF-prevention issues, with the error No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

Without going too far off topic, this was due to the fact that I was attempting to make an $http call from the client to a node route that I had set up for facebook authentication, rather than simply using an anchor tag href call on the client. Ajax calls are particular tricky across domain origins. I had to set it up this way because I wanted my server to return user info of my making back to the client.

I tried solutions outlined here and here, each to no avail. Granted, both were under the “cookie-based auth” umbrella, but that shouldn’t matter, right?

After searching for nearly two days, I came up with the idea of making auth request client-side, rather than server-side. Using the ngFacebook angular module along with grunt-ng-constant gave me the answer I needed. Here’s how to do it.

In my other life I’m a musician—a guitarist who plays in a band. I used to tell my guitar students that it takes literally miles of practice—DAILY practice—up and down the guitar fretboard to feel comfortable improv-ing a solo on the guitar with a band. I could always tell the students that practiced a little every day versus the ones who thought they could practice for three hours once a week. The ones who practiced just minutes every day always improved more rapidly.

One of the hardest things for me to grok in JavaScript was promise-based style handling of the async nature of the language. I understood the async JavaScript just fine, and could wield callbacks like a banshee. However, promise-based structures provided a more elegant solution than callbacks—particularly when you were several calls deep. I will describe what I learned in the context of Angular, as it has a very simple yet elegant implementation of promises in its $q library.

Closures are a common point of confusion for the JavaScript-uninitiated. Recently, a came across a couple-years-old post on the topic. I think it covers the subject well: check out Angus Croll’s “Understanding JavaScript Closures”.