jdrew1303

/* Cranium MVC
 * A minimalist MVC implementation written for
 * demonstration purposes at my workshops
 * http://addyosmani.com
 * Copyright (c) 2012 Addy Osmani; Licensed MIT */


var Cranium = Cranium || {};

// Set DOM selection utility

jdrew1303

var timeUntil = {
    
    inHours: function(d1, d2) {
        return parseInt((d2.getTime()-d1.getTime())/(24*3600), 10);
    },
 
    inDays: function(d1, d2) {
        return parseInt((d2.getTime()-d1.getTime())/(24*3600*1000), 10);
    },
 

jdrew1303

// Flyweight.js - Copyright Addy Osmani, 2012.
// Consider public domain
// My implementation in JS of this:
// http://en.wikipedia.org/wiki/Flyweight_pattern

// Simulate pure virtual inheritance/'implement' keyword for JS
Function.prototype.implementsFor = function (parentClassOrObject) {
    if (parentClassOrObject.constructor == Function) {
        // Normal Inheritance 
        this.prototype = new parentClassOrObject;

jdrew1303

//trimmed down version of jack lawsons mediator

(function (root) {

    // We'll generate guids for class instances for easy referencing later on.
    // Subscriber instances will have an id that can be refernced for quick
    // lookups.
    function guidGenerator() {
        var S4 = function () {
                return (((1 + Math.random()) * 0x10000) | 0).toString(16).substring(1);

jdrew1303

#gitback 0.1
#usage: sudo ruby gitback.rb
#credits: walter white, minor changes: addy osmani
#!/usr/bin/env ruby

# dependencies
require "yaml"
require "open-uri"

time = Time.new

jdrew1303

#MVP

Model-view-presenter (MVP) is a derivative of the MVC design pattern which focuses on improving presentation logic. Whilst both MVC and MVP target the separation of concerns across multiple components, there are some fundamental differences between them. For the purposes of this summary we will focus on the version of MVP most suitable for web-based architectures.

##Summary

The P in MVP stands for presenter. It's a component which contains the user-interface business logic for the view. Unlike MVC, invocations from the view are delegated to the presenter, which are decoupled from the view and instead talk to it through an interface. This allows for all kinds of useful things such as being able to mock views in unit tests.

The most common implementation of MVP is one where the view is passive (dumb), containing little to no logic. MVP models are almost identical to MVC models and handle application data. The presenter acts as a mediator which talks to both the view and model, however both of these ar

jdrew1303

#Understanding MVC And MVP (For JavaScript & Backbone Developers)

Before exploring any JavaScript frameworks that assist in structuring applications, it can be useful to gain a basic understanding of architectural design patterns. Design patterns are proven solutions to common development problems and can suggest structural paradigms to help guide us in adding some organization to our application.

I think patterns are exciting as they're effectively a grass roots effort that build upon the collective experience of skilled developers who have previously faced similar problems as we do now. Although developers 10 or 20 years ago may not have been using the same programming languages for implementing patterns, there are many lessons we can learn from their efforts.

In this section, we're going to review two popular patterns - MVC and MVP. The context of our exploration will be how these patterns are related to the popular JavaScript framework Backbone.js, which will be explored in greater detail later on.

jdrew1303

##Introduction

One definition of unit testing is the process of taking the smallest piece of testable code in an application, isolating it from the remainder of your codebase and determining if it behaves exactly as expected. In this section, we'll be taking a look at how to unit test Backbone applications using a popular JavaScript testing framework called Jasmine.

For an application to be considered 'well'-tested, distinct functionality should ideally have its own separate unit tests where it's tested against the different conditions you expect it to work under. All tests must pass before functionality is considered 'complete'. This allows developers to both modify a unit of code and it's dependencies with a level of confidence about whether these changes have caused any breakage.

As a basic example of unit testing is where a developer may wish to assert whether passing specific values through to a sum function results in the correct output being returned. For an example more relevant to this book,

jdrew1303

Modernizr.addTest('mathml', function(){
  var hasMathML = false;
  if ( document.createElementNS ) {
    var ns = "http://www.w3.org/1998/Math/MathML",
        div = document.createElement("div");
        div.style.position = "absolute"; 
    var mfrac = div.appendChild(document.createElementNS(_namespace,"math"))
                   .appendChild(document.createElementNS(_namespace,"mfrac"));
    mfrac.appendChild(document.createElementNS(_namespace,"mi"))
         .appendChild(document.createTextNode("xx"));

jdrew1303

MAKEFLAGS = --no-print-directory --always-make
MAKE = make $(MAKEFLAGS)

BUILDDIR = ./.build

UGLIFYJS = $(BUILDDIR)/uglify.js --extra
CLOSUREURL = http://closure-compiler.googlecode.com/files/compiler-latest.zip
CLOSUREDIR = $(BUILDDIR)/closure
CLOSUREFILE = $(CLOSUREDIR)/compiler.jar
YUIURL = http://yui.zenfs.com/releases/yuicompressor/yuicompressor-2.4.6.zip