We were trying to template google analytics and make it part of our requirejs setup. When we did what we thought was obvious to wrap it in a module and declare a dependency on it, it seemed to fail quite miserably.

The trick was that we missed that you needed to export a global variable. This means in the javascript file initialising google analytics we had to add the following code block

var registerGoogleAnalytics = function(accountId) {
  var _gaq = _gaq || [];
  if (window) {
    window._gaq = _gaq; // export as global
  }
  _gaq.push(['_setAccount', accountId]);
  _gaq.push(['_trackPageview']);

  // rest of google analytics initialiser script...
}

Some links that helped us working this out:

• https://productforums.google.com/forum/#!topic/analytics/-wzmrVpsOTo
• http://stackoverflow.com/questions/9738815/google-analytics-gif-request-not-sent
• http://productforums.google.com/forum/#!topic/analytics/MmT2237oOpA

One our frustrations using jade and icanhaz (a javascript front end mustache implementation) was that when we were trying things that were obvious to us, jade would simply fail to template and we weren’t sure what was causing it.

Fortunately small TDD cycles and experimentation made us realise that it was the combination of new line characters and mustache code made jade work/break.

We would try something like this:

script(type="text/html", id="my_checkbox", class="partial")
  li 
    label(for="{{code}}")
      {{name}} 
    input(id="{{code}}", checked="checked", name="{{code}}", type="checkbox")

The set of statements above would be valid mustache (once converted to HTML) but jade complains because the {{name}} is on its own line. The fix was to use the pipe (|) character to force jade to recognise a line break. It looks like this now

script(type="text/html", id="my_checkbox", class="partial")
  li 
    label(for="{{code}}")
      | {{name}} 
      input(id="{{code}}", checked="checked", name="{{code}}", type="checkbox")

Simple, but not particularly obvious from the examples in their documentation.

Building quality into the build often means ensuring that certain patterns don’t exist in the code (like console.log). This grunt plugin allows you to fail the build if a regular expression is found in the files you specify.

Feedback appreciated.

More details here: https://npmjs.org/package/grunt-regex-check

We’re using the builder pattern on our javascript project, as it useful for starting off with a set of defaults, but is clear when we want to override particular values. Although there are a few places on the net that describe who uses the builder pattern in javascript, they don’t really provide an implementation.

Here’s one that works for us:

var Builder = function() {
  var a = "defaultA";
  var b = "defaultB";
  
  return {
      withA : function(anotherA) {
        a = anotherA;
        return this;
      },
      withB : function(anotherB) {
        b = anotherB; 
        return this;
      },
      build : function() {
        return "A is: " + a +", B is: " + b;
      }
  };
};

var builder = new Builder();

console.log(builder.build());

var first = builder.withA("a different value for A").withB("a different value for B").build();

var second = builder.withB("second different value for B").build();

var third = builder.withA("now A is different again").build();

console.log(first);
console.log(second);
console.log(third);