Dan Couper DanCouper

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Drop in replace functions for setTimeout and setInterval that make use of requestAnimationFrame.

See overview article and Paul Irish's earlier post.

Courtesty of Joe Lambert

Copyright 2011, Joe Lambert.
Free to use under the MIT license.
http://www.opensource.org/licenses/mit-license.php

The Ultimate Git Alias Setup

If you use git on the command-line, you'll eventually find yourself wanting aliases for your most commonly-used commands. It's incredibly useful to be able to explore your repos with only a few keystrokes that eventually get hardcoded into muscle memory.

Some people don't add aliases because they don't want to have to adjust to not having them on a remote server. Personally, I find that having aliases doesn't mean I that forget the underlying commands, and aliases provide such a massive improvement to my workflow that it would be crazy not to have them.

The simplest way to add an alias for a specific git command is to use a standard bash alias.

# .bashrc

In Rails 3

NOTE: This post now lives (and kept up to date) on my blog: http://hakunin.com/rails3-load-paths

If you add a dir directly under app/

Do nothing. All files in this dir are eager loaded in production and lazy loaded in development by default.

	# Original Rails controller and action
	class EmployeesController < ApplicationController
	def create
	@employee = Employee.new(employee_params)

	if @employee.save
	redirect_to @employee, notice: "Employee #{@employee.name} created"
	else
	render :new
	end

	// It's pretty straightforward to wrap callback-based functions in ones that
	// use and return promises.
	function readOne (url) {
	var deferred = when.defer();
	httpRequest(url, function(response){
	deferred.resolve(response.length);
	});
	// This promise represents the end result of the operation, and will
	// be resolved when `httpRequest` calls `deferred.resolve` above.
	// Once resolved, anything waiting for its result can continue.

	// Load plugins
	var gulp = require('gulp'),
	sass = require('gulp-ruby-sass'),
	autoprefixer = require('gulp-autoprefixer'),
	minifycss = require('gulp-minify-css'),
	jshint = require('gulp-jshint'),
	uglify = require('gulp-uglify'),
	imagemin = require('gulp-imagemin'),
	rename = require('gulp-rename'),
	clean = require('gulp-clean'),

	var extend = function(a, b) {
	for (var i in b)
	a[i] = b[i];
	return a;
	};

	var fluent = function(f) {
	return function() {
	var clone = extend(Object.create(null), this);
	f.apply(clone, arguments);

	module.exports = function(grunt) {

	// Project configuration.
	grunt.initConfig({
	pkg: grunt.file.readJSON('package.json'),
	connect: {
	server: {
	options: {},
	}
	},