grunt-codekit now supports js concatenation

9. juni 2014

A final missing piece was added to the plugin for Grunt I made a few months ago: javascript concatenation using CodeKit’s prepend and append directives. Now you might think that this is a useless feature, as we have had the grunt-contrib-concat plugin for ages, but to use that you would have to change your existing project for it to work. Adding support for handling inline build comments like these

// @codekit-prepend "some-file.js"
// @codekit-append "some-other-file.js"

makes it possible to keep using CodeKit&tm; and Grunt at the same time. That means non-Mac developers can still contribute to you project, you don’t have to change any code, and you can keep the nitty-gritty of various builds in Grunt, and just use CodeKit like you normally do. Which was kinda the point for me, since CodeKit < 2 sucked at sharing config between team members (build file changed all the time). Les resten av dette innlegget »

Running Karma tests on BrowserStack

27. mai 2014

Browserstack is a great setup and Karma is a great test runner for javascript, so the two should be a pretty good fit right? In practice it took me quite a lot of time to get the settings right, including discussions on the karma users group and some help from the good folks at BrowserStack. What follows are some brief notes on how I set this up to run with Grunt and on the Jenkins build server. Les resten av dette innlegget »

Lessons learned in JavaScript, Part 1: Cross domain JSON and Firebug logging

19. november 2010

Firebug has a little utility feature where you can log messages in your Javascript code to Firebugs console. This works a lot better than using a heap of alert() calls, but only works if you have Firebug running. Of course I found out the hard way when showing my work with Firebug turned off, at which time the code broke due to this undefined (actually undeclared) «console» variable.

Lesson learned: if you want to produce logs to see in Firebug, check to see if the console variable is declared. Now of course, you could check this before every call like this

if( typeof(console) != "undefined" )
  {console.log("graphBuilder(): success");}

The stupid with this approach is that you cannot move this bit into a function since the undeclared variable would throw a runtime error the moment you tried to pass it as an argument. What does work (for me), is that I define my own log() method and do the check within this. If console is not defined (e.g. Firebug is not loaded), I define both the console and the log function so they don’t throw a runtime error. The code looks like this:

function log(log_message) {
  /* check to see if Firebug is loaded. */
  if( typeof(console) == "undefined" ) {
    /* Avoid runtime errors by defining 
        the console object and its associated functions 
    console = {}
    console.log = function(arg){;}
  else console.log(log_message);

BTW, to those new to Javascript, variables have function scope, not block scope, so declaring a variable in the if statement works 😉

The other tidbit of knowledge I recently learned concerns JSON and the same origin policy. In theory, most modern browsers should not allow a script to call a service residing on a domain different from the page. So why does the following call work?

service = ''
parameters = {
$.getJSON(service, parameters, function(data) {

After posting the question on StackOverflow I found about a new header that is supported by newer browsers (for instance Firefox 3.5+) called  «Access-Control-Allow-Origin». If this header is set to allow * (meaning all domains), the request is let through by the browser to the calling script. You can also use this to whitelist specific domains. AFAI can tell, this could be a way of avoiding JSONP if your site has public, non-sensitive information.