For a requirement like this, you don’t really want to be performing such a long-running task as part of the standard Django request -> response cycle since 1) the Django server is single-threaded, and 2) even if you’re using WSGI to run your Django app behind Apache or a similar server you’re not really going to want one of your Apache worker processes being tied up with a single client request for long periods of time as this would adversely impact other incoming client requests. Thus, any such long-running task should be performed in a process which then informs the main Django app once it’s done. Celery is a readily-available such system (a task-queue to be precise) which enables this and it is easy to integrate into Django using django-celery.

Setting up Django Celery

Setting up Django Celery has already been documented elsewhere so I’ll simply list the settings I used to get things working (Note: I’m assuming that you’re running a Debian-based Linux system). First of all I installed RabbitMQ to use the message queue system:

$ sudo apt-get install rabbitmq-server

Then I added a vhost and username and password for my Django app to RabbitMQ:

$ sudo rabbitmqctl add_user myapp myapp
$ sudo rabbitmqctl add_vhost myapp
$ sudo rabbitmqctl set_permissions -p myapp myapp ".*" ".*" ".*"

Then in my celeryconfig.py I set the following:

BROKER_HOST = "127.0.0.1"
BROKER_PORT = 5672   # default RabbitMQ listening port
BROKER_USER = "myapp"
BROKER_PASSWORD = "myapp"
BROKER_VHOST = "myapp"
CELERY_BACKEND = "amqp"  # telling Celery to report the results back to RabbitMQ
CELERY_RESULT_DBURI = ""

To test that my setup was correct I ran:

$ ./manage.py celeryd -l INFO

[2012-01-27 12:29:01,344: WARNING/MainProcess]  
/home/ram/dev/myapp/virtualenv/lib/python2.7/site-packages/djcelery/loaders.py:86: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments!
  warnings.warn("Using settings.DEBUG leads to a memory leak, never "
[2012-01-27 12:29:01,344: WARNING/MainProcess]  

 -------------- celery@RamLaptop2 v2.4.6
---- **** -----
--- * ***  * -- [Configuration]
-- * - **** ---   . broker:      amqp://guest@localhost:5672//
- ** ----------   . loader:      djcelery.loaders.DjangoLoader
- ** ----------   . logfile:     [stderr]@INFO
- ** ----------   . concurrency: 8
- ** ----------   . events:      OFF
- *** --- * ---   . beat:        OFF
-- ******* ----
--- ***** ----- [Queues]
 --------------   . celery:      exchange:celery (direct) binding:celery
                  
[Tasks]
  . REPORT_CREATE

[2012-01-27 12:29:01,399: INFO/PoolWorker-1] child process calling self.run()
[2012-01-27 12:29:01,401: INFO/PoolWorker-2] child process calling self.run()
[2012-01-27 12:29:01,403: INFO/PoolWorker-3] child process calling self.run()
[2012-01-27 12:29:01,405: INFO/PoolWorker-4] child process calling self.run()
[2012-01-27 12:29:01,406: INFO/PoolWorker-5] child process calling self.run()
[2012-01-27 12:29:01,408: INFO/PoolWorker-6] child process calling self.run()
[2012-01-27 12:29:01,409: INFO/PoolWorker-7] child process calling self.run()
[2012-01-27 12:29:01,410: INFO/PoolWorker-8] child process calling self.run()
[2012-01-27 12:29:01,411: WARNING/MainProcess] celery@RamLaptop2 has started.

At this point if you’re not familiar with writing Celery tasks then check out their tutorial on how to write Celery tasks for use by Celery daemon workers started above.

Deploying to production using Supervisord

In the production environment we need a reliable way of running the Celery daemon processes. Enter Supervisord. Essentially it’s a processes which in turn launches other processes you tell it to launch, and then monitors those child processes, restarting them if they die, etc. Here is what I did to set it up:

$ sudo easy_install supervisor

I created /etc/supervisord to hold all the configuration info:

$ sudo mkdir /etc/supervisord
[/code lang="bash"]

I then edited `/etc/supervisord/supervisord.conf`:

1
[unix_http_server]
file=/tmp/supervisor.sock   ; (the path to the socket file)

[supervisord]
logfile=/var/log/supervisord/main.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB        ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10           ; (num of main logfile rotation backups;default 10)
loglevel=info                ; (log level;default info; others: debug,warn,trace)
pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false               ; (start in foreground if true;default false)
minfds=1024                  ; (min. avail startup file descriptors;default 1024)
minprocs=200                 ; (min. avail process descriptors;default 200)
childlogdir=/var/log/supervisord            ; ('AUTO' child log dir, default $TEMP)

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; use a unix:// URL  for a unix socket

[include]
files = /etc/supervisord/conf.d/*.conf

I created a folder called conf.d inside /etc/supervisord and created a file called myapp-celery.conf inside that:

[program:myapp-celery]
command=/home/ram/dev/myapp/virtualenv/bin/python /home/ram/dev/myapp/manage.py celeryd --loglevel=INFO
environment=PYTHONPATH=/home/ram/dev/myapp
directory=/home/ram/dev/myapp
user=www-data
numprocs=1
stdout_logfile=/var/log/celeryd/myapp.log
stderr_logfile=/var/log/celeryd/myapp.log
autostart=true
autorestart=true
startsecs=10
stopwaitsecs = 600
priority=998

Note: I'm running my Django app inside a virtual environment, which is why I specify the path to the Python interpreter in the above file.

I created the /var/log/supervisord and /var/log/celeryd log folders and setup the appropriate permissions on them to enable logging.

To run Supervisord I did the following:

$ supervisord -c /etc/supervisord/supervisord.conf

I checked that my Celery workers were active:

$ ps aux | grep celeryd
...
www-data  26655  0.5  0.3 210000 36248 ?        Sl   12:49   0:02 /home/ram/dev/myapp/virtualenv/bin/python /home/ram/dev/myapp/manage.py celeryd --loglevel=INFO
www-data  26656  0.5  0.3 210012 36232 ?        Sl   12:49   0:02 /home/ram/dev/myapp/virtualenv/bin/python /home/ram/dev/myapp/manage.py celeryd --loglevel=INFO
www-data  26671  0.0  0.2 103364 33012 ?        S    12:49   0:00 /home/ram/dev/myapp/virtualenv/bin/python /home/ram/dev/myapp/manage.py celeryd --loglevel=INFO
...

To shut it down I did:

$ supervisorctl -c /etc/supervisord/supervisord.conf shutdown

Monitoring Supervisord

Supervisord will monitor our Celery workers and ensure they stay alive, but how will we ensure that Supervisord itself stays alive? Enter Monit. Monit does essentially the same thing as Supervisord except that it monitors child processes through pid files and other checks (e.g. checking that a web page loads in order to verify that Apache is running) and doesn't directly own them (unlike Supervisord). Monit also installs itself as an init.d script which gets launched at server boot time. It comes with a web interface (with optional authentication) which lets you easily start, stop and restart any services it is monitoring along with providing memory and CPU usage statistics.

I installed Monit:

$ sudo apt-get install monit

I edited /etc/monit/monitrc and uncommented the lines relating to the web interface:

set httpd port 2812 and
#     use address localhost  # only accept connection from localhost
#     allow localhost        # allow localhost to connect to the server and
#     allow admin:monit      # require user 'admin' with password 'monit'
     allow @monit           # allow users of group 'monit' to connect (rw)
#     allow @users readonly  # allow users of group 'users' to connect readonly

Note: I configured it above such that it accepts authenticated connections from anywhere, whereby only local Linux users who belongs to the monit group can gain access..

Then I created /etc/monit/conf.d/supervisord.monit:

 check process supervisord with pidfile /tmp/supervisord.pid
   group supervisord
   start program = "/usr/local/bin/supervisord -c /etc/supervisord/supervisord.conf"
   stop  program = "/usr/local/bin/supervisorctl -c /etc/supervisord/supervisord.conf shutdown"
   if 5 restarts within 5 cycles then timeout

Restart Monit:

$ sudo /etc/init.d/monit restart

All done! I then created a monit Linux group and added myself to it. From then on I was able to visit http://localhost:2812 to see the status of the supervisord process and control it.

Full documentation along with in-browser examples are available at squeljs.org. To get started with using Squel in your node.js program use npm install squel.

Enjoy

I came up with this little snippet to ensure that cake exited abnormally (with error code 1) if any of the tests failed:

run_tests = (callback) ->
    options = [
        'test/expression.coffee'
        'test/select.coffee'
        'test/update.coffee'
        'test/delete.coffee'
        'test/insert.coffee'
        '--spec'
    ]
    vows = spawn "#{binpath}/vows", options
    output = ""
    data_handler = (data) ->
        output =+ data if data
        stream_data_handler data
    vows.stdout.on 'data', data_handler
    vows.stderr.on 'data', data_handler
    vows.on 'exit', (status) ->
        if 0 isnt status or (output and -1 isnt output.indexOf("✗ Broken"))
            return process.exit(1)
        callback?()

Essentially it looks for the ✗ Broken string in the vows output – this string only gets output if one or more vows were ‘broken’. Now Travis also picks up on test failures. There might be a more elegant way to do the above – if you know give me a shout. Otherwise I hope somebody else finds this useful.

Although the Django test server is single-threaded (and thus all requests execute in the same thread) it does not maintain a global application state which is accessible to each request, as far as I’m aware. However, because it is single-threaded we can simulate a globally accessible application state through the use of static class member variables.

My snippet below does just this. It uses request-response middleware which kicks in during the response phase to add all SQL queries executed as part of the current request to a static class member list variable. Accessing the data requires calling a separate URL (/profiling) which will then output all the SQL queries so far ‘collected’.

Further improvements to this may include establishing a persistent socket connection to the server through which SQL query strings are received as and when they get executed. And instead of displaying the list of queries on their own page we could inject them into the Debug toolbar, if it’s enabled. In fact, enhancing the Debug toolbar itself to pick up queries executed as part of AJAX requests would be the best implementation yet.

The snippet (see http://djangosnippets.org/snippets/2632/):

# file: settings.py

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'yourapp.middleware.SqlProfilingMiddleware',
    ...
)



# file: yourapp/midddlware.py

from django.db import connection
import time

class SqlProfilingMiddleware(object):
    Queries = []

    def process_request(self, request):
        return None
    def process_view(self, request, view_func, view_args, view_kwargs):
        return None
    def process_template_response(self, request, response):
        self._add_sql_queries(request)
        return response
    def process_response(self, request, response):
        self._add_sql_queries(request)
        return response
    def process_exception(self, request, exception):
        return None

    def _add_sql_queries(self, request):
        for q in connection.queries:
            q["time"] = time.time() + float(q["time"])
            SqlProfilingMiddleware.Queries.insert(0, q)
            # add request info as a separator
        SqlProfilingMiddleware.Queries.insert(0, {"time": time.time(), "path" : request.path})



# file: yourapp/views.py

from yourapp.middleware import SqlProfilingMiddleware

def profiling(request):
    return render_to_response("profiling.html", {"queries": SqlProfilingMiddleware.Queries})



# file: urls.py

urlpatterns = patterns('',
  (r'^profiling/$', 'yourapp.views.profiling'),
)

var User = sequelize.define('user', {
  name: Sequelize.STRING
},{
  underscored : true
})

var Profile = sequelize.define('profile', {
  user_id: {
    type: Sequelize.INTEGER,
    primaryKey: true
  },
  dob: Sequelize.DATE
},{
  underscored : true
})

var Profile2 = sequelize.define('profile2', {
  dob: Sequelize.DATE
},{
  underscored : true
})

User.hasOne(Profile)
User.hasOne(Profile2)

/* 
At this point Profile.user_id will act as both primary and foreign key, whereas Profile2.user_id and Profile.id will have been auto-added by Sequelize and will act as foreign key and primary key respectively.
*/

Date.js alternatives

Date.js has been causing me a number of problems due to its nature of extending/modifying the built-in Date object. It really messed up my use of cookie sessions in Express, specifically to do with setting the cookie expiry dates. I still haven’t figured out exactly why cookies weren’t getting set properly but I suspect that it’s some internal change to Date made by date.js which was causing the problem. I then also had problems with it on the browser side of things.

Looking for an alternative I’m happy to have found XDate, a more light-weight and better-designed date library than date.js. It wraps the default Date object whilst still exposing an identical API as well as providing its own. The nice thing about XDate is that its custom API methods are almost identical to those provided by date.js so switching one out for the other didn’t require any massive code changes.

XDate was very recently created and it’s on Github too so I expect it will only get better with time. There isn’t a node module for it yet, as far as I’m aware. Then again, I’ve just had a look and found Moment, another nice-looking date library available through NPM. I might give that a whirl for my server side.

I’ve raised a pull request for my work These changes are now in Sequelize trunk. But I’ll explain the changes here. To validate your models first define the validation for each field. For example:

var User = sequelize.define 'User', {
    id: {
            type: Sequelize.INTEGER,
            autoIncrement: true,
            primaryKey: true,
    },
        name: {
            type: Sequelize.STRING,
            allowNull: false,
            unique: true,
            validate: {
                len: {
                    args: 3,
                    msg: "Name must be atleast 3 characters in length"
            }
        }
    },
        email: {
            type: Sequelize.STRING,
            allowNull: false,
            unique: true,
            validate: {
                len: {
                    args: [6, 128],
                    msg: "Email address must be between 6 and 128 characters in length"
            },
                isEmail: {
                    msg: "Email address must be valid"
            }
        }
    },
        password: {
            type: Sequelize.STRING,
            allowNull: false,
            validate: {
                len: {
                    args: 3
            }
        }
    }
}

The isEmail and len methods are just two of the many methods available (for the full list see the node-validator page). The msg key specifies the error message to return for a given validation if it fails. If this isn’t provided then a default generic error message will be returned by the validation library for that particular validation failure.

To actually perform the validation, call the validate() method on your model instance once your model has been built. For example:

# build user
var user = User.build({
    name : "test"
    email : "test"
    password : "test"
});

# validate
errors = user.validate();
if (errors)
    # errors is an object with the entries structured as follows:
    # { field name : [list of validation failure messages] }
    #
    for (var prop in errors) {
        if (errors.hasOwnProperty(prop))
        console.log("Errors for field " + prop + ": ");
        for (var i=0; i<errors[prop].length; ++i) {
            console.log("\t" + errors[prop][i]);
        }
    }
else
    # errors is null, which means validation succeeded

As a further improvement it would probably be good to enable custom validation methods, though this would be something we add to Sequelize rather than node-validator. Custom methods might be declared and used as follows:

name: {
    type: Sequelize.STRING,
    allowNull: false,
    unique: true,
    validate: {
        len: {
            args: 3,
            msg: "Name must be atleast 3 characters in length"
        },
        fn: function(val) {
            if (val !== "mustbethis") throw new Error("Custom validation failed");
        }
}

If Sascha accepts the existing validation stuff then I’ll push to include custom methods too.

Spine = require("spine")
class MyModel extends Spine.Model
    id : 1
    output: () =>
        console.log @id

The output() method is always executed within the context of the instance of MyModel on which it gets called. Now let’s see what happens when we clone it:

foo = new MyModel()
foo.id = 2
foo.output()     # outputs: 2

bar = m.clone()
bar.id = 3
bar.output()     # outputs: 2

We expect bar.output() to return 3 yet it returns 2. Why is this? It’s because the output() method is bound to the instance (this) within MyModel‘s constructor, as can be seen from the generated Javascript:

(function() {
  var MyModel, Spine, cp, m;
  var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; }, __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
    for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; }
    function ctor() { this.constructor = child; }
    ctor.prototype = parent.prototype;
    child.prototype = new ctor;
    child.__super__ = parent.prototype;
    return child;
  };
  Spine = require("spine");
  MyModel = (function() {
    __extends(MyModel, Spine.Model);
    function MyModel() {
      this.output = __bind(this.output, this);
      MyModel.__super__.constructor.apply(this, arguments);
    }
    MyModel.prototype.id = 1;
    MyModel.prototype.output = function() {
      return console.log(this.id);
    };
    return MyModel;
  })();
}).call(this);

Thus, even when calling output() on a cloned object its function context will still point to the original instance it was cloned from. The solution – if you’re going to need to clone your model instance – is to not use CoffeeScript’s function binding. Using the non-binding syntax we get the results we want:

Spine = require("spine")
class MyModel extends Spine.Model
    id : 1
    output: () ->
        console.log @id

foo = new MyModel()
foo.id = 2
foo.output()     # outputs: 2

bar = m.clone()
bar.id = 3
bar.output()     # outputs: 3

Ideally place all your widget code into its own file. Here is the basic code structure:

(function($){
  $.widget("mobile.mywidget", $.mobile.widget, {
    /** Available options for the widget are specified here, along with default values. */
    options: {
      inline: false,
      mode: "default",
      height: 200
    },
    /** Mandatory method - automatically called by jQuery Mobile to initialise the widget. */
    _create: function() {
      var inputElement = this.element;
      var opts = $.extend(this.options, inputElement.data("options"));
      $(document).trigger("mywidgetcreate");
      ...
      inputElement.after("<button>" + inputElement.val() + "</button>");
      ...
    },
    /** Custom method to handle updates. */
    _update: function() {
      var inputElement = this.element;
      var opts = $.extend(this.options, inputElement.data("options"));
      $(document).trigger("mywidgetupdate");
      ...
      inputElement.siblings("button").text(inputElement.val());
      ...
    },
    /* Externally callable method to force a refresh of the widget. */
    refresh: function() {
      return this._update();
    }
  });
  /* Handler which initialises all widget instances during page creation. */
  $(document).bind("pagecreate", function(e) {
    $(document).trigger("mywidgetbeforecreate");
    return $(":jqmData(role='mywidget')", e.target).mywidget();
  });
})(jQuery);

In the HTML we can trigger use of the widget as follows:

  <input type="text" val="test" data-role="mywidget" data-height="100" data-inline="true" />

In the example above our widget is known as a mywidget. We first define the widget and then follow it with a handler for the pagecreate event. This handler ensures that all HTML elements with the attribute data-role=”mywidget” are processed. Note that you should use the jqmData filter in case you’re not using the standard data- prefix for widget attributes.

Any number of options can be provided to your widget with no restrictions on option type. Per-widget-instance options can be specified as HTML attributes or as dictionary keys if initializing a widget directly in Javascript. Default values for options are provided within the widget itself (as you can see above).

The _create() method gets automatically called by jQuery Mobile when we call mywidget() from the pagecreate handler. This method is responsible for setting up the initial widget display. In the example above we simply add a button after the input element with its label set to the value within the text field.

There is also a refresh() method available for the widget which can be invoked through Javascript as follows:

$(":jqmData(role='mywidget')").mywidget("refresh");

This in turn calls the _update() method which in turn refreshes the button label with the current value of the text input field. You can add as many such methods as you like to the widget. For example, most of the standard jQuery Mobile widgets also come with enable() and disable() methods.

You’ll also notice that we trigger widget-specific events within the functions, e.g. mywidgetcreate. These aren’t strictly necessary but are useful to include, especially if you want the rest of your application to know when these events take place within the widget.

Recently I started using the Spine Javascript framework to base my app on a simple MVC architecture. Even more recently I found out that Spine’s creator Alex McCaw had written a tool called Hem which pretty much does whatever RequireJS except that it’s optimised for use with Spine. I gave it a go and having now used both it and RequireJS I am better placed to comment on the differences and relative advantaged of the two tools.

RequireJS is a standalone Javascript library (~5 KB) with no other dependencies.It introduces new syntax for packaging your Javascript code as different modules. It’s module format is based on the CommonJS spec though its implementation reserved words and their usage differs slightly from the standard spec. RequireJS’s optimization step is yet another script which can be executed from the command-line once you’ve installed node. This step will concatenate and minify your Javascript and (optionally) CSS files.

Hem is a command-line tool. It is an npm module and has a few npm-loaded dependencies, notably UglifyJS (the same as is used by RequireJS). Thus, node and npm are pre-requisites for using Hem at all. Hem integrates well with Spine in that it will package up your views (.eco or .jeco templates) along with your Javascript code into a single, minified script file. It also minifies and packages a CSS file you point it to into a single CSS files alongside the single script file which gets output.

Like RequireJS, Hem also allows code to be written in CoffeeScript, automatically running the CoffeeScript compiler before packaging things up. It’s module format closes adheres to the CommonJS spec.

Hem comes with two distinct options:

• server – launch a simple node.js server (port 9294 by default) which concatenates all your Javascript and template files into a single Javascript file on every page request.
• build – Concatenate all your Javascript and template files into a single, minified Javascript file, ready for deployment to production.

Thus, with Hem your HTML file can expect there to be available a single script file containing all of your app’s script code. This is great because it means that switching from development to production mode for your Javascript does not require any changes to the code in your HTML which references the script file. This makes it easy to test both cases, unlike for RequireJS which may require your HTML file to work slightly differently when switching to production mode.

RequireJS is able to produce multiple minified output files as well as being able to concatenate multiple script files into one file based on its static analysis of define() and require() calls made within the script files. Hem supposedly analyses dependencies dynamically but in truth I think it just assumes that all script files will be needed and thus concatenates them all (including view templates) into one file to avoid errors due to missing code. The downside of putting everything into one file is that the initial download size for your web app might end up being larger (and thus more time consuming) than it would be if you were to load defer loading of some of your scripts.

For me it was initially weird to have to install node and npm even just for a project that only includes client-side scripting. However this comes with the benefit that it’s easy to update to the latest versions of Hem and any of the other node-based packages you may be using thanks to npm’s versioning system. As far as I’m aware the npm registry is currently the only Javascript package repository widely used by developers. What’s more, if you’re developing your server-side using node then using npm is an easy way of sharing the same packages among client and server.

After having used npm for a bit now I’m convinced that all future Javascript development (and specifically the inclusion of third-party libraries into your project) will be done using npm (or a future packaging manager) as a way of managing external dependencies. For instance jQuery is already available as an npm module. The one big downside of using npm is that its Windows support isn’t quite as good as the other platforms. So if you want to use it with windows you may have some trouble getting it running and working properly.

I’ve decided that I’m going to be using Hem for all my minification needs from now on since it provides everything RequireJS provides and then some (e.g. template minification). Plus it’s source code is written in CoffeeScript (unlike RequireJS), which makes it a pleasure to contribute to.

I’ve contributed some improvements to Hem, visible on Hem’s pull requests page. You can now ask it to skip CSS minification and have more control over where it should output things.

Update (Nov 9): found an interesting post comparing the CommonJS way of defining modules to the AMD (RequireJS) way. I agree with the general sentiment expressed, in that RequireJS makes it easy to test your scripts when developing your app since it can load in dependencies on the fly from the server. Yet Hem works around this by rebuilding the entire optimised script file on every request, and thus doesn’t hinder development in any way. Moreover you get to test the final output script file that you’d get in a production build during development, which is something you can’t really do as nicely with RequireJS.

I started off by getting Spine to to work with the RequireJS CoffeeScript adapter. In development mode everything worked fine but when I tested using the RequireJS-optimized output some of my Spine code didn’t seem to work. Here is my HTML file:

<!DOCTYPE html>
<html>
<head>
    <title>CoffeeScript Loader Plugin Demo</title>
    <script data-main="lib/main" src="lib/require-jquery.js"></script>
</head>
<body>
<p>
  <a class="test" href="#">Test</a>
</p>
</body>
</html>

The main.js script:

require({
    paths: {
        cs: '../../demo/lib/cs'
    }
}, ['spine','cs!csmain']);

And the csmain.coffee script:

define () ->
    Tasks = Spine.Controller.create
        tag: "body"

        events:
            "click .test" : "clicked"

        init: ->
            alert "loaded"

        clicked: (event) ->
            alert "clicked"

    Tasks.init
        el: document.body

I built on top of the RequreJS CoffeeScript demo files to save time.

On page load I should see an alert containing the text “loaded”. When I click the link I should get an alert containing the text “clicked”. In the RequireJS-optimized version (where all the scripts were compressed and inlined into main.js) I got the initial page load alert but no alert when I clicked on the link. Thinking that the use of coffeescript might have jinxed it I decided to code the Spine stuff in plain old Javascript instead, to no avail. I then replaced Spine with Backbone and coded the equivalent as such:

    View = Backbone.View.extend
        el: $("body")

        events:
            "click .test" : "clicked"

        initialize: ->
            alert "loaded"

        clicked: ->
            alert "clicked"

    new View()

CoffeeScript is beautiful, no!?

This failed in the same exact way that Spine did. So it wasn’t an issue with either of these libraries. Eventually, I took a chance and decided to not to use the combined RequireJS + jQuery script and instead opted to include them separately. This is not the most recommended way of using RequireJS with jQuery, as is clearly stated in the RequireJS docs. Yet this combination worked for me – when I ran the optimized version I got the click-triggered alert box showing too. I can only guess that the RequireJS + jQuery combo file breaks either jQuery or the assumptions Spine and Backbone make about jQuery.

So here is how I now initialize the scripts in the HTML:

    <script src="lib/require.js"></script>
    <script>
      require({
        baseUrl: 'lib',
        priority: ['jquery']
      }, ['main']);
    </script>

The RequireJS docs recommend additional configuration steps for the optimizer to work properly but I didn’t need to do that. My existing configuration worked fine:

({
    appDir: '.',
    baseUrl: 'lib',
    //Uncomment to turn off uglify minification.
    //optimize: 'none',
    dir: '../demo-build',
    paths: {
        cs: '../../demo/lib/cs'
    },
    // Exclude CoffeeScript compiler code
    pragmasOnSave: {
        excludeCoffeeScript: true
    },
    modules: [
        {
            name: "main"
        }
    ]
})