gaearon

// ------------
// counterStore.js
// ------------

import {
  INCREMENT_COUNTER,
  DECREMENT_COUNTER
} from '../constants/ActionTypes';

const initialState = { counter: 0 };

nhunzaker

(function() {

    var color = Mocha.reporters.Base.color;

    function log() {

        var args = Array.apply(null, arguments);

        if (window.callPhantom) {
            window.callPhantom({ message: args.join(" ") });

sent-hil

This is my current Gemfile for River.

source 'http://rubygems.org'

gem 'god' # monitoring of Goliath & Sinatra apps

group :default do
  gem 'yajl-ruby', :require => 'yajl' # fast JSON dumping/parsing
end

ordinaryzelig

I'm a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: "matchers" in MiniTest::Spec refer to something completely different than "matchers" in RSpec. I won't get into it, but from now on, let's use the proper term: "expectations").

Understanding MiniTest::Expectations

Let's take a look in the code (I'm specifically referring to the gem, not the standard library that's built into Ruby 1.9):

# minitest/spec.rb

module MiniTest::Expectations

cowboy

// Also see http://michaux.ca/articles/class-based-inheritance-in-javascript
function extend(Super, Sub) {
  // By using a dummy constructor, initialization side-effects are eliminated.
  function Dummy() {}
  // Set dummy prototype to Super prototype.
  Dummy.prototype = Super.prototype;
  // Create Sub prototype as a new instance of dummy.
  Sub.prototype = new Dummy();
  // The .constructor propery is really the Super constructor.
  Sub.baseConstructor = Sub.prototype.constructor;

lzcabrera

<Main>
<Level>
<Category id="a">
<SubCategory>one</SubCategory>
<SubCategory>two</SubCategory>
<SubCategory>three</SubCategory>
</Category>
<Category id="b">
<SubCategory>one</SubCategory>

andyhd

function maybe(value) {
  var obj = null;
  function isEmpty() { return value === undefined || value === null }
  function nonEmpty() { return !isEmpty() }
  obj = {
    map: function (f) { return isEmpty() ? obj : maybe(f(value)) },
    getOrElse: function (n) { return isEmpty() ? n : value },
    isEmpty: isEmpty,
    nonEmpty: nonEmpty
  }

addyosmani

#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.

Atinux

/*
** Client side - /public/src/app.js
*/

var myApp = {
// Collections
	Collections: {
		list: Backbone.Collection.extend()
	},
// Views

jamiehodge

module App
  class Users < App::Base
    
    use Rack::Parser
    
    helpers do
      def cycle
        @cycle ||= %w{odd even}.cycle
      end
    end