Naming convention for modules with constructors in Nodejs

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();

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:

1. We need to capture the number of times a story was re-estimated and why. 
2. 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.
3. 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.

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 ...");
}());

Efficient recursion with Erlang

One of the stand-out sessions for me, at YOW_OZ 2010 Melbourne (Dec 2-3) was the talk Erlang warps your mind.

I'm using Scheme to explain recursion due to its predicate first syntax, which better lends itself to AST evaluation.

During the session, the presenter listed three hurdles to becoming an Erlang developer:

• Pattern Matching
• Recursion (Tail Recursion) and
• Concurrency

After looking around at a few Erlang tutorials, I found myself returning to sicp site to review its section on recursion optimisations. Basically, it all comes down to a rudimentary understanding of how execution processes utilise the humble stack to perform tasks.

The stack keeps tabs on the sequence in which instructions should be processed. When a function is called, the current instruction pointer is pushed onto the stack and a new stack for the called function is created, ready to sequence instructions to the process. Once the function returns a value, the stack is cleared an the previous instruction pointer is restored to continue execution. Imagine this as a tree of stacks, representing execution blocks, which point to child blocks when computational delegation is required to achieve the the blocks goal. These blocks wink in and out of existence, dependent upon execution completion and dependency counts.

Apply this knowledge to a recursive function:

(define linear-factorial-recursion n)

(if (= n 1) 1
(* n (linear-factorial-recursion (- n 1))))

The multiplier on the last line, requires n and a recursive call to linear-factorial-recursion to evaluate and so the stack is retained until the entire function achieves its goal. We can imagine this evaluation like so:

(linear-factorial-recursion 3)
(* 3 (linear-factorial-recursion 2))
(* 3 (* 2 (linear-factorial-recursion 1)))
(* 3 (* 2 1))
(* 3 2)
= 6

As you can see, retaining a reference to achieve a full evaluation goal at the highest level, requires an expanding/Collapsible stack scenario, where the rate of expanse is proportional to the number of iterations - linear recursion - Imagine factorial 10000 - that's allot of stack space!!

To break the recursive dependency on the last line of the above function, one simply has to supply all state into the recursive function so that the calling function evaluates immediately, clearing the functions stack.

(define (iterative-factorial n) (tail-recursive-factorial 1 n))
(define (tail-recursive-factorial p n)
(if (= n 1) p
(tail-recursive-factorial (* p n) (- n 1))))

Notice that the last line is not assigned to a multiplier function, eliminating a reference to the calling function stack; Instead all state is evaluated as its passed into the recursive call to the function. We could imagine this evaluation like so:



(iterative-factorial 3)
(tail-recursive-factorial 1 3)
(tail-recursive-factorial 3 2)
(tail-recursive-factorial 6 1)

=6
Notice how the stack size remains constant, due to the fact that the previous function call passes all evaluated state to the new function call in an iterative linear fashion.

So some nice things about iterative linear recursion - or tail recursion:

• The function can recurse indefinitely since stack resources are constant.
• Increase in performance as a result of less push pops for stacks
• parallelism due to orthogonal nature of recursive function calls. Stacks do not create child stack dependencies to achieve goals.

Tail recursive factorial function in Erlang:

-module(basic).
-compile(export_all).

factorial2(P, C) ->
 if 
    C < 1 -> P;
    true -> factorial2( P*C, C-1)
 end.

factorial(N) -> basic:factorial2(1, N).