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
// ------------ | |
// counterStore.js | |
// ------------ | |
import { | |
INCREMENT_COUNTER, | |
DECREMENT_COUNTER | |
} from '../constants/ActionTypes'; | |
const initialState = { counter: 0 }; |
(function() { | |
var color = Mocha.reporters.Base.color; | |
function log() { | |
var args = Array.apply(null, arguments); | |
if (window.callPhantom) { | |
window.callPhantom({ message: args.join(" ") }); |
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
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").
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
// 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; |
<Main> | |
<Level> | |
<Category id="a"> | |
<SubCategory>one</SubCategory> | |
<SubCategory>two</SubCategory> | |
<SubCategory>three</SubCategory> | |
</Category> | |
<Category id="b"> | |
<SubCategory>one</SubCategory> |
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 | |
} |
#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.
/* | |
** Client side - /public/src/app.js | |
*/ | |
var myApp = { | |
// Collections | |
Collections: { | |
list: Backbone.Collection.extend() | |
}, | |
// Views |
module App | |
class Users < App::Base | |
use Rack::Parser | |
helpers do | |
def cycle | |
@cycle ||= %w{odd even}.cycle | |
end | |
end |