Modules that require instantiation through a class function have the first letter in their name capitalised, in the same fashion as the class function name itself.
This tells the user that they should use the new keyword when calling the module, before gaining access to its methods.
MyModule.js
function MyClassFunction(param) {
var self = this;
// do stuff
}
module.exports = MyClassFunction;
usage:
var myObject = new (require('MyModule'))(param);
This naming convention focuses on usage rather than direct implementation. As such
Modules that have private class functions, called by static methods or wrapper functions, should begin with a lower case letter in their name.
myModule.js
function MyClassFunction(message) {
var self = this;
console.log('Instantiated private obj.');
};
MyClassFunction.staticMethod = function() {
var message = 'Called from static method';
return new MyClassFunction(message);
};
module.exports = {
myMethod: MyClassFunction.staticMethod
};
usage:
require('./myModule').myMethod();
Me Learn You Good Teknolojy
Mainly stuff about tech... like there isn't enough on the web already..
Search This Blog
Wednesday, August 3, 2011
Monday, August 1, 2011
Re-estimating stories during play - cone of uncertainty
Cone of uncertainty:
At time zero, we are at our maximum uncertainty about how a feature will be delivered. As we progress toward delivery, we learn more about the problem and hopefully its solution. As such, we are better equipped to provide increasingly accurate estimates as we approach delivery.
With this in mind, cases arise when stories need to be re-estimated after they're in play. I lean toward keeping the old estimate and recording the new estimate at the time it becomes obvious that the story is bigger/smaller than originally thought.
One of the questions often asked is whether we can defer re-estimation until after the story is delivered? This should be avoided for a few reasons:
At time zero, we are at our maximum uncertainty about how a feature will be delivered. As we progress toward delivery, we learn more about the problem and hopefully its solution. As such, we are better equipped to provide increasingly accurate estimates as we approach delivery.
With this in mind, cases arise when stories need to be re-estimated after they're in play. I lean toward keeping the old estimate and recording the new estimate at the time it becomes obvious that the story is bigger/smaller than originally thought.
One of the questions often asked is whether we can defer re-estimation until after the story is delivered? This should be avoided for a few reasons:
- We need to capture the number of times a story was re-estimated and why.
- Stories that have been re-estimated several times draw attention to themselves and should promote discussion about estimation, way the story has been broken down and other processes that support an iteration and velocity.
- Its important to encourage good estimation - avoiding re-estimation at the time it becomes obvious is counter productive to this goal. Further, several re-estimation attempts during a story is usually something a developer will try to avoid - it's a pride thing - as we inherently know this is bad.
During iteration planning and estimation, previous iteration stories, that underwent re-estimated, should be discussed before the team estimates new stories in an attempt to improve the estimation process.
Thursday, July 21, 2011
Self executing code in nodejs
Given that brackets against a function represent execute function:
var value = function blah(){return 'blah'}(); // evaluate value when called;
A nice way to start a web application with minimal start-up code is to wrap the execution of the start function in brackets - meaning execute this();
myWebApp.js:
var myWebApp = require('http');
(function start() {
function onRequest(req, res) {
res.writeHead(200, {"Content-Type": "text/plain"});
res.write("Congratulations! my web app is running.");
res.end();
}
myWebApp.createServer(onRequest).listen(8099);
console.log("Started MyWebApp ...");
}());
var value = function blah(){return 'blah'}(); // evaluate value when called;
A nice way to start a web application with minimal start-up code is to wrap the execution of the start function in brackets - meaning execute this();
myWebApp.js:
var myWebApp = require('http');
(function start() {
function onRequest(req, res) {
res.writeHead(200, {"Content-Type": "text/plain"});
res.write("Congratulations! my web app is running.");
res.end();
}
myWebApp.createServer(onRequest).listen(8099);
console.log("Started MyWebApp ...");
}());
Subscribe to:
Posts (Atom)