I present an alternate theory as to the cause of the Icelandic financial crisis. Specifically, the negation and diversion of sub-zeros from database aggregate product calculations.

Just kidding. But, every once in a while there is a hack so circuitous it keeps one up at night. Literally. This is one of them. This hack has found itself in production code in banks around the world with no problems for several years. Until now.

When calculating sliding averages, adjusted duration, volatility, and other performance graphs, it is often necessary to multiply huge sets of values from a database. For example, the product of the daily change in the closing price of a stock over the past ten years. This is known as an aggregate product.

So, you would think that the leading database, Oracle, would handle an aggregate product. Some common aggregate functions include SUM, AVG, COUNT, MAX, MIN, etc. Oracle allows us to add, average, count, even calculate logarithms, but we can not simply multiply the rows in a table. Here’s a simplified solution at one bank, now going the way of the polar bear:

   select
      exp(sum(ln(abs(decode(COLUMN,0,1,COLUMN)))))*
      decode(mod(count(decode(sign(COLUMN),-1,1,null)),2),1,-1,1)*
      nvl(max(decode(COLUMN,0,0,null)),1)

Let’s reconstruct this. Put simply, we add up all the natural logs of each value and reapplying the exponential to the sum. The first line, exp(sum(ln(…))) relies on the fact that:

   e^(ln(x1) + ln(x2) + ... + ln(xn))
      == x1 * x2 * ... * xn, for all x >= 0

But this is only true for positive non-zero numbers. The abs(decode(…)) of the first line, reverses all negatives and ignores all zeros. The next two lines, handle negatives and zeros respectively.

   select
      e^(sum(ln(abs( [ ignore zeros ] ))))*
      ( count( negative numbers ) == even ? 1 : -1 )*
      ( have any zero at all ? 0 : 1 )

The second line multiplies the entire result by negative one if there are an odd number of negative numbers. The third and final line multiplies the entire result by zero if there is any zero.

I often find myself reinventing the wheel and get lost around closures, prototypes, unscoped variables, and other OOP-like features of Javascript. So I created a Javascript ‘class cheat-sheet‘ with the several ways of instantiating and referencing objects therein. I’ve eliminated redundant styles and what I found useless (unscoped globals). Without further ado:

function Class() {
  //
  // PUBLIC INSTANCE
  // instance public variable and methods
  //
  this.instance_public = 2;

  this.instance_public_func = function() {
    return private_var +
      this.instance_public +
      this.prototype_public;
  }

  //
  // PRIVATE
  // private variable and methods
  //
  var  that = this;
  var  private_var = 1;

  function private_func() {
    return private_var +
      that.instance_public +
      that.prototype_public;
  }

}
//
// PROTOTYPE PUBLIC
// prototype public variable and methods
//
Class.prototype.prototype_public = 4;

Class.prototype.prototype_public_func = function() {
    // private_var (hidden from prototype)
    return this.instance_public +
      this.prototype_public;
}

What does it mean? Well, I am aware of three ways to declare a field (basic variable) within a constructor (class definition) and one in the prototype. These are:

function Class() {
  var private;
  this.public1;
  global;
}
Class.prototype.public2;

The var scopes a object within its surrounding { } block. Such objects are accessible (through closure) to any function within the same block, but invisible outside of the block.

In the example above, public1 and public2 have the same visibility. However, the latter is memory efficient. public2 acts somewhat like a static class variable except that it can be overridden by any instance. Explicitly referencing prototype.public2 is akin to a static member in other languages such as Java. The . (dot) before the variable name that binds it to an object and makes it public, whether that object is this, that or var hash = {}; hash.key = "value";.

Any unbound object (via dot (.) or var) is global. There are very few (perhaps no) good reasons to do this.

Caveats

Note that function x is shorthand for var x = function. The following two methods are equivalent.

  function private_method1() {
    return that;
  };

  var private_method2 = function() {
    return that;
  };

Private and global functions defined within a constructor do not have access to the implied new object reference this, but can access another reference such as var that = this;. Perhaps this is a ‘bug’ in the ECMA standard.

Private (var) and instance public (this.) members, may access all other members of a class, including prototype variables and functions. However, prototype members may not access private members defined within the constructor. The following will fail:

   function X() { var priv = 6; };
   X.prototype.proto = function() { return priv; };
   var x = new X();
   alert(x.proto());

Private and prototype functions may be called within the constructor before they have been defined. But instance public are only available (at runtime) after they’ve been instantiated. For example, “priv and proto” will be alerted, but an error will be thrown on line 3 because this.pub has not yet been defined.

 1    function X() {
 2      alert(priv() +" and "+ this.proto());
 3      alert(this.pub());
 4      function priv() { return "priv"; }
 5      this.pub = function() { return "pub"; }
 6    }
 7    X.prototype.proto = function() { return "proto"; };
 8    new X();

Variations

A singleton object has only one instance and there are thus no advantages of the prototype.

var s = new function S() {
  this.pub_var = 1;
  this.pub = function() {};
  var that = this;
  function priv() {};
}();

Slightly more exotic, is a singleton whose members are all public:

var h = {
  field : "public",
  method : function() { return this.field; }
};

Returning the singleton from a constructor, gives us access to private variables. Consider the “Module Pattern”:

var Namespace = {
  C : function() {
    var priv = "priv";
    return {
      field : "pub",
      method : function() { return priv +" and "+ this.field; }
    }
  }
};
var c = new Namespace.C();

Sin duda hoy es un día muy triste para mí. Voy a echarlos de menos y voy a llorar mucho. Será la culpa de todas ustedes. Pero ha sido un corto tiempo muy sagrado. En realidad he ganada muchos amigos nuevos, conocimientos sobre español, experiencias culturales, especialmente bailando salsa, y yo he tenido cuatro profesores inspiradores.

Para terminar mi discurso yo les regalaré un secreto. Es muy simple. No se ve bien más que con el corazón. Lo esencial es invisible para los ojos.

Muchos gracias. Hasta pronto.

I’ve found myself using Git for nearly everything from organising my mp3, photo, and video collections, snapshot backups, synchronising devices, managing my love life, and walking my dog (just kidding about the videos). It’s fast, reliable, out of the way, and so damn useful, I wanted to find a way to create and publish a repository nearly instantly.

As I see it, there are only three use cases, all of which have only one user (namely me) with write permission. Those who insist on three additional use cases, and don’t mind the stench of centralised version control, might consider granting write permissions to multiple users via WebDAV. Though I argue in my upcoming rant entitled, Tyranny of the proletariat: Beyond authoritarianism and democracy, that multiple writers is symptomatic of an inefficient development model. The useful cases are: paranoia, syndication, and transparency.

In all cases, we create a repository remotely and clone it locally. In the paranoid case, the remote location is accessible only with encrypted transmission via SSH. The syndicate is publicly readable via Git over HTTP. The transparent case is web accessible and is also (in theory) publicly readable via Git.

Surprisingly enough, I’ve published the recipe for your coding pleasure (rgit from my home repo). First, you’ll need to configure four variables. I source them from startup rc (.bash_profile), but you may find it more convenient to add them directly to the recipe:

export SSH_DOMAIN=user@domain.web
export WEB_DOMAIN=sub.domain.web
export PATH_TO_WEB='~/path/to/public/web'
export PATH_TO_PRIV='~/priv/git'

Then decide if you want a paranoid (bare, SSH only), syndicate (bare, Git readable over HTTP), or transparent remote repository (work tree, web browsable). The paranoid user must add the -p flag. A transparent repository is created with the -w flag. A syndicate repository, which is readable by anyone with Git, is the default.

$ rgit HelloWorld

Generating public Git bare repository accessible via:
   http://sub.domain.web/HelloWorld.git
   ssh://user@domain.web/~/path/to/public/web/HelloWorld.git
Password:
Initialized empty Git repository in ~/path/to/public/web/HelloWorld.git/
Initialized empty Git repository in /home/user/local/HelloWorld/.git/
Created initial commit 5edcd54: Init with empty gitignore
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
Pushing commit to remote repository via ssh
Password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 228 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://user@domain.web/~/path/to/public/web/HelloWorld.git
 * [new branch]      master -> master
Completed

There are a few things to note. First, any web directory can limit access with htaccess/htpasswd files as well as similar mechanisms within git. Second, you’ll probably want to figure out how to share your SSH key with the remote server, else you’ll be typing your password frequently. Third, both -wp flags are possible, though it doesn’t make a lot of sense to create a remote work tree to an otherwise inaccessible repository. Even if you intend to do work on the remote server, it is recommended (by those in the know) to work in a clone of a bare repository. Finally, the transparent case does not work as intended. While all repositories can be cloned over SSH and bare repositories over HTTP, I’ve run into some problems cloning a work repository over HTTP:

local$ git clone http://sub.domain.web/home home.http
Initialized empty Git repository in ~/home.http/.git/
warning: remote HEAD refers to nonexistent ref, unable to checkout.

The primary motivation for syndicating the recipe is to find a solution to the above problem. The fully transparent workaround is to syndicate a bare repository and clone a work tree, such as home.git and home/. Perhaps this is just the case of publishing a web site. Transparency might be better handled by something like Trac, Git Web, or Cgit. Thoughts? Patches?

Inspiration:

• Casper Fabricius
• Ben Lynn’s Git Magic