Profile cover photo
Profile photo
James McKay
Web developer to the rich and famous
Web developer to the rich and famous

Post has attachment
Proposed new programming jargon: Brown M&Ms. Seemingly trivial, easily-missed acceptance criteria that bear little relationship to the rest of the user story but are actually much more important than you think.

From a standard contract rider that was inserted by the rock band Van Halen into their technical specifications. It specified a bowl of M&Ms in the dressing room with all the brown ones removed, on pain of cancellation of the entire concert with full compensation. They used it to check whether their hosts had read the specification correctly.
Add a comment...

How good is your JavaScript?

Version 2.0:

0. You avoid it altogether and insist on using Silverlight instead.

1. Your JavaScript skills are limited to searching the web for jQuery plugins and snippets of code to copy and paste.

2. You are able to do simple things with jQuery, such as effects, validation and possibly Ajax, but you have no idea how it works. For example, you don’t know exactly what data structure $('some-selector') returns. You talk about “writing jQuery code” rather than “writing JavaScript code.” Your scripts are either very short and simple or else contain a lot of duplication. You have a vague idea what setTimeout() does but you've never used it.

3. You understand the difference between jQuery and JavaScript and have a reasonable idea of how they relate to each other and the DOM. You are able to say what data structure $('some-selector') returns and what the var keyword does, though you may be a bit hazy about JavaScript’s exact scoping rules. You are able to write somewhat more complex scripts but they are all procedural in nature. You don’t understand the JavaScript object model or concepts such as closures and callbacks. You aren’t sure what the point of the (function() { ... })(); construct is. You believe that setTimeout() is supposed to take a string as its first argument.

4. You understand the JavaScript object model and more complex concepts such as closures, regular expressions, callbacks and exception handling, and are able to use them effectively, though you do not necessarily know how to implement class based inheritance. You know what the (function() { ... })(); construct is for and are aware of ECMAScript 5’s "use strict" directive. You are aware that setTimeout() can take a function instead of a string as its first argument.

5. You have used or investigated JavaScript frameworks such as backbone.js, knockout.js or ember.js; templating engines such as mustache.js; JavaScript unit testing frameworks such as Jasmine, Mocha or QUnit; and asset bundling and minification tools. You are able to implement class-based inheritance in JavaScript. You have a fairly wide-ranging understanding of the quirks of the language such as automatic semicolon insertion or the difference between == and ===. You know that passing a string as the first argument to setTimeout() is a bad practice.

6. You are able to optimise JavaScript for performance or security, and to identify and resolve memory leaks. You have incorporated JavaScript unit tests into your Continuous Integration process and use full-blown test-driven development for your client-side code. You are experienced with CoffeeScript and node.js.

7. You have built complex projects such as compilers, server-side applications or complete frameworks using JavaScript.
Add a comment...

Just how are you supposed to handle exceptions in a node.js web application???

If you don't do anything, it doesn't just return a 500 error page, it crashes your entire application. To stop it doing that, you need to add an uncaughtException event handler:

process.on('uncaughtException', function (err) {
console.log("Node NOT Exiting...");

But -- and it is a big but -- if you do this, you also need to call end() on your response object. Only one problem there: this event handler doesn't have access to the response object in which the exception was thrown.

The answers I've seen on Stack Overflow suggest that you should return errors as a status code from your event handlers, rather than throwing exceptions:

You're kidding me, right? Back to the bad old days of C++ error codes? Not to mention the abomination of having to put Pokemon exception handling in all your callback functions?

One and a half hours into attempting to learn node.js, this leaves me far from impressed. Or am I missing something?
Add a comment...

Still very quiet here.

Somebody let me know when it warms up. You'll find me on The Other Place. Or Twitter. Or Github.
Add a comment...

There's a simple solution to making Google+ more lively. Integration with Twitter.
Add a comment...

Proposal: Here on Google+, we start referring to Facebook as "The Other Place."
Add a comment...

Post has attachment
Add a comment...
Wait while more posts are being loaded