Blog Archives

A more detailed Meteor and Derby overview for NoVa Node.js

I gave a lightning talk last May for the Node.js DC meetup on Derby and Meteor. It led to a good discussion, which isn’t surprising since both frameworks are great demonstrations that Node is functionally capable of much more than just cloning Ruby libraries.

The guys running the Northern Virginia Node meetup felt there was more to cover and asked me to do a longer overview at the July Nova Node meetup. Apparently the subject is popular since we had a “sold out” room last night.

Overview of Derby.js and Meteor.js

Full slide deck below…

I was a little worried about taking the whole hour, but got a lot positive feedback afterwards. Free pizza, beer and sodas from the meetup host probably didn’t hurt either :). is running on Node now, and handling tons of customers successfully at much lower loads than they were seeing with their previous environment. Several folks (including me) asked for an overview of the production lessons they’ve learned for the next NoVa Node event.

Here is the deck I presented on Derby and Meteor. My goal was to get the core concepts across for discussion, not to teach them. That said, if you do have questions feel free to tweet me or leave a comment. If its guts stuff though, I suggest you go to experts in the relevant Google groups or hit StackOverflow.

Related articles


Meteor and Derby Lighting Talk for Node.js DC

I gave a lightning talk last night at the Node DC meetup on Derby.js and Meteor.js, or at least that was the plan. I was given permission to “go over” a little bit, and my five minute talk stretched out to twenty.

A Quick Overview of Derby and Meteor

Full slide deck below…

I got plenty of compliments afterwards, so  hope that means the extra time was worthwhile, but I suspect sharing my Sweet Potato Tater Tots had at least as much to do with people’s good attitudes as anything I said. If you couldn’t make it but you want to get the gist of what I was talking about, the slides are available on slideshare.

I was asked by NoVa Node Meetup to do a more lengthy overview on Derby and Meteor. More info and the updated slide deck at  A More Detailed Overview of Derby.js and Meteor.js.

A new variable for Knockout.js bindings – the DOM element

When writing knockout bindings it can sometimes be handy to reference the DOM element you are writing the element for. As an example, you may want information on a DOM property or for development reasons simply want to show the id.

I tweaked Knockout to support using an $element special variable last year, but hadn’t decided to submit it yet.  Based on the discussion in knockout issue 176 I decided to clean it up and submit it as knockout pull request 474. Mbest also updated it to work with the latest knockout changes.

Usage is simple:

<div data-bind='text: $element.tagName'></div>


As an aside, I’m going to be presenting on Derby and Meteor at the NodeDC Meetup on 5/16. If you are interested in Node or just want to connect with some cool DC coders stop by!

Two new QUnit Test Types – Skipped and Interactive

I love unit testing, and the confident feeling I get from my code being “all green”. But sometimes there are tests that need to be skipped for a bit, perhaps due to a failing backend service or an in-progress refactoring. The easiest solution is to comment them out, but then it’s easy to forget they are being skipped. Instead, I simply added a new test type – testSkip – to QUnit using the following code. Now when the test is skipped we see it marked as SKIPPED in the QUnit results.

QUnit.testSkip = function() {
   q.test(arguments[0] + &quot; (SKIPPED)&quot;, function() {});

I use a similar approach for QUnit tests that involve user interaction. I run lots of tests when coding, but the interactive ones get in the way of my flow. So I have added the test type testManual which allows me to run them explicitly by simply adding testmanual to the URL parameters. A similar approach can be used for other test categories or to target tests to a particular browser.

QUnit.testManual = function() {
   if(/(\?|&amp;)testmanual($|&amp;|=)/.test(window.location.href)) {
      q.test.apply(q, arguments);
   } else {
      q.testSkip.apply(q, arguments);

A bindOnce event listener for Backbone.js

I’m going to guess you are familiar with Backbone, the MVC framework of choice for many web developers. I use Backbone a fair amount for its Model and Event aspects both because it works and it’s often what others expect.

But there is one feature I miss with Backbone event handling – the ability to listen for an event once (like jQuery’s once). You can write your own code to simply ignore later events, but the event handling code is still there.  It would be better to unbind, but with Backbone that means holding on to the callback function so you can unbind it on the first callback, and to do that you have to assign your callback to a variable which can clutter up simple event handling code.

Or you can just write a bindOnce function that does that for you which is what I did. I feel like this should be a standard feature, so I’ve packaged it up with some tests and submitted it to the Backbone folks in pull request 663. Usage is simple and looks like this:

obj.bindOnce('event', function(){
   obj.counterA += 1;

Update 10/29/11

Wow, that was quick. My bindOnce is now part of Backbone with the updated name of once (which makes sense since it matches jQuery). It always speeds things up when you include the tests :)

Enabling Knockout.js to work across iframes

If you haven’t checked out Knockout yet, I highly recommend it.

Knockout allows you to create declarative bindings in your HTML that map to your underlying model’s properties. The nice thing about the bindings being in HTML is that you and your designer team can work in real HTML.

But Knockout’s real magic comes from its dependency tracking. When bound model properties change, Knockout magically updates the bound parts of the HTML that need it. It’s an approach I have used many times that gives you the real benefits of MVC by allowing the view to bind to the model rather than the other way around.

We wrote something similar in Digitalk Smalltalk back in the 90s, and then VisualWorks Smalltalk introduced Aspect Adaptors baked right in. In Knockout these model property trackers are called Observers. It also has something called a Dependency Observer that tracks any model properties accessed during a function call (for example getting the list of users), it then automatically creates observers on those properties. Very cool.

One problem with the current version of Knockout is that there are still a few hurdles preventing it from working across frames or windows: it uses a global state to do its Dependency Observer magic, it does identify class checking (which fails across frames), and it does some things relative to the window the code was loaded into rather than the current element’s window. I have written a couple of patches that cover most of these cases and have submitted a pull request to Steve Sanderson.

Update 3/21/12

After many tweaks and discussions my cross-frame changes have been accepted into Knockout 2.10. See issue 405 for details.

Using IntelliJ IDEA to debug Firefox Extensions

I have been a fan of JetBrains’ IntelliJ IDEA as an IDE for many years, and with WebStorm/PhpStorm (or IntelliJ with the JavaScript plugin) JetBrain really is on their way to having a great JavaScript IDE. What is particularly impressive is how WebStorm/PhpStorm is able to parse out meaning from untyped JS and have knowledge of many of the core JS libraries.

But one problem is that they don’t debug Firefox extensions. I often use ChromeBug for this, but sometimes it’s nice to debug right in the IDE. With a little bit of hacking I found a way to update their debugger so that it can also debug Firefox extensions.

You can get the code on GitHub at WebStorm-Firefox-Connector. I plan to update it with each update of the WebStorm Firefox extension until JetBrains adds this functionality themselves. I’ve submitted the changes to JetBrains as an issue in the hope that they will incorporate my changes into the main product.

To debug extensions with WebStorm/IntelliJ, do the following:

  • Install WebStorm and let it install the Firefox debugger extension
  • Determine what version of the Firefox debugger extension you are using (look in the Add-Ons tab)
  • Download the correct branch from GitHub for your version to replace the contents of the directory.
  • Edit the file extensions\\chrome\chromeFiles\content\scripts.js to add your chrome URL root to the variable enabledChromeComponents. For example, this allows me to debug an extension named myext:
    • ·         enabledChromeComponents: ["myext"]


Most folks won’t care, but it’s worth pointing out that you can’t use WebStorm to debug Firebug itself since they both use JSD, which only supports one debugger client at a time. JSD2 is supposed to fix this, but sometimes I wonder if JSD2 will ever really happen.

I do some work on Firebug, and I have looked a bit into creating a multi-layer-client wrapper for JSD, but haven’t had the time to get it actually working. Besides, the JSD layer is a bit tricky. Let’s just say I’ve gotten used to wishing JSD2 were on the horizon and knowing that it probably isn’t.


Update 2/14/11

They have updated the debugger extension (0.4.3) with a good chunk of my changes, but unfortunately not all of them. Looks like I’ll be updating the patched version of the debug extensions for at least a while longer. You can still find the any updates at GitHub.

I was awarded a Firefox Security Bug Bounty Award!

I just received an email from the head of the Mozilla security team that I have been awarded a Security Bug Bounty Award for an sg:critical bug I found in Firefox. For those that don’t know, sg:critical is the highest level of severity and indicates the bug is an “exploitable vulnerability which can lead to the widespread compromise of many users.” That sounds pretty scary, but on the bright side sg:critical means I get the maximum bounty of $3000 (and a t-shirt :). Very cool :).

I don’t want to share more since the vulnerability hasn’t been fixed yet, but as soon as it is I’ll give a full explanation.

Update 9/27/11

The bug is (finally) fixed and has been announced as Mozilla Foundation Security Advisory 2011-43 (CVE-2011-3004), which means I can finally talk about it. The bug deals with the guts of how Firefox wraps unsecure JavaScript objects so the details are a bit complicated. People who are interested in the gritty details should follow the above link. Since the full explanation is a bit much for a blog post I’m just going to summarize it here.

In Firefox the loadSubScript function loads code into the current security context, and since it’s called from an extension the code is loaded in the secure security context. In Firefox 3.6 (and now again in Firefox 11+) any unsecure objects passed in the loadSubScript context are correctly wrapped in a XrayWrapper (XPCNWrapper in Firefox 3.6).

Wrapper ensures that secure code can’t accidently pass an unsecure object to a secure object that can be used as a privilege upgrade attack. There are surprising number ways of doing this in JavaScript without this wrapper protection.

In Firefox 4 a bug was introduced that missed adding these wrappers for loadSubScript. So the secure loaded code was handed unsecure, unwrapped objects.  If a target window (any web page) anticipated this bug they could check for the vulnerability in each user’s browser, and if they found it they could use it to do anything a Firefox extension could do (essentially gaining full access to the user’s system, files … practically everything).

See [post: Inserting JavaScript/CSS…] for one possible use case for loadSubScript (now that it is no longer a security hole).

Inserting JavaScript/CSS in a target page from a Firefox Extension

When you’re working with Firefox extensions you often want to act on the target page, accessing elements or even changing HTML, but JavaScript libraries and jQuery plugins assume that they are always working on the current scope’s global objects.

So every time you find yourself wanting to act on variables like window, document and jQuery you run into a problem.  You could insert the module into the target window using a script tag, but that may conflict with the target window’s JS.

A better solution is to load another instance of these libraries in your own scope tied to the target window’s global variables. One approach is to eval the window inside a context that has remapped the window and document element.

The following code demonstrates this given a passed target window.

createTargetScripts: function(targetWindow) {
   // Create the scripts we will use on the target window, we create them in a closure so they will
   // have the target window and document (but our privilege, and the target objects they use will actually be wrappers).

   (function() {
      var window = targetWindow;
      var document = targetWindow.document;
      var jQuery = targetWindow.jQuery;          // Add jQuery to local scope for jQuery plugins


   // Even though the jQuery is on the wrapper, that wrapper may be used by other extensions
   targetWindow.targetJQ = targetWindow.jQuery.noConflict(true);

   } ,
   readURLSync: function(url) {
      var data = myExtensionJQ.ajax({
         url: url,
         async: false,
         dataType: "text",
         mimeType: 'text/plain; charset=x-user-defined'
      return data;

   // Add sourceURL so debuggers will know what source file to use
   evalStringForURL: function(url) {
      var evalStr = this.readURLSync(url);
      var sourceURLStr = "//@ sourceURL=" + url;
      return evalStr + sourceURLStr;

For CSS you can do even better. Instead of inserting the CSS into the target page you can load it as a “user sheet,” making it available in all pages. If you want to override existing styles in the target page you just use a “!” in your style. Here is the code:

var sss = Components.classes[";1"]
var ios = Components.classes[";1"]
var uri = ios.newURI(url, null, null);
   sss.loadAndRegisterSheet(uri, sss.USER_SHEET);

FYI, Another Firefox-specific approach for loading the JS libraries with a different context is to use loadSubScript, but a bug in Firefox 4 broke this. I’ve documented the bug at Unfortunately, you can’t actually view the bug report – it was restricted because it exposes a potential Firefox security vulnerability.

Update 6/15/11

Apparently the bug I mentioned above exposes a severe security vulnerability since I was awarded a Firefox Security Bug Bounty Award. See [post: Firefox Security Bug Bounty…].

Logging QUnit results

I’ve mentioned QUnit in other posts [POST: CUSTOM QUNIT TEST TYPES] and how much stock I put into unit testing in general, so I thought I’d share some more tips for people who don’t have much experience with QUnit. This will probably be a recurring theme on this blog.

One of the advantages of QUnit is that it has built-in hooks for testing automation tools. I use these hooks to do basic console logging so I can see what test is running next to my own log messages. I also log the amount of time each test takes.

The code to add these hooks is straightforward:

var startTime = null;
var currentTest = null;
QUnit.testStart = function(details) {
   currentTest =;
   startTime = new Date().getTime();
   console.warn("QUnit starting " + currentTest);

QUnit.testDone = function(details) {
   cm.console.warn("QUnit finished " + currentTest + " (" + (new Date().getTime() - startTime).toString() + " ms)");
   currentTest = null;

QUnit.begin = function(details) {
   cm.console.log("QUnit starting");

QUnit.done = function(details) {
   cm.console.log("QUnit finished");

If you use modules then there are hooks at that level also:

QUnit.moduleStart = function(details) {
QUnit.moduleDone = function(details) {

The same approach can be used to do other things like send notifications (email/tweet) or generate a timing summary. You can read more about the QUnit integration hooks at:

%d bloggers like this: