ryanflorence

import React, { Component } from 'react'
import logo from './logo.svg'
import './App.css'

import { Route, Link, Redirect } from './Zero'

const paths = [ 'one', 'two', 'three' ]

class App extends Component {
  render() {

ianstormtaylor

import React from 'react'
import Portal from 'react-portal'
import getOffsets from 'positions'
import { findDOMNode } from 'slate'

/**
 * No-op.
 *
 * @type {Function}

Dillion

https://docs.google.com/presentation/d/1KkbPBFu1GzHwV4nU4i10XBtp-YiYbE-4vty4okrmFDs/edit?usp=sharing https://gist.github.com/jboner/2841832

##References and links##

###SSD vs HDD### [1] SSDs replacing HDDs? that's not exactly the way it happened http://www.storagesearch.com/bitmicro-art3.html

[2] Server SSDs open up storage possibilities in data centers http://searchdatacenter.techtarget.com/feature/Server-SSDs-open-up-storage-possibilities-in-data-centers

andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

erica

/*

Erica Sadun, http://ericasadun.com
GameplayKit Available 10.11, iOS 9

*/

import Foundation
import GameplayKit // only available on OS X 10.11, iOS 9

JadenGeller

// DEPRECATED!!!
// NEW VERSION HERE: https://github.com/JadenGeller/Linky/

class NodeBacking<T> {
    var backing: T
    
    init(backing: T) {
        self.backing = backing
    }
}

gist:8a163db3f7f3d81d5296

Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right.
If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it.
If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately.
If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions.
If you remove possibilities (for example, Swift removes the possibility of things being nil unless 

andymatuschak

//
//  MultiDirectionAdjudicatingScrollView.swift
//  Khan Academy
//
//  Created by Andy Matuschak on 12/16/14.
//  Copyright (c) 2014 Khan Academy. All rights reserved.
//

import UIKit
import UIKit.UIGestureRecognizerSubclass

steipete

- (NSString *)tableView:(UITableView *)tableView titleForSwipeAccessoryButtonForRowAtIndexPath:(NSIndexPath *)indexPath {
    return @"More";
}

- (void)tableView:(UITableView *)tableView swipeAccessoryButtonPushedForRowAtIndexPath:(NSIndexPath *)indexPath {
   NSLog(@"I wanted to be a pretty public API, but then time ran out and they forgot me...");

  // Hide the More/Delete menu.
  [self setEditing:NO animated:YES];
}

dhh

# config/routes.rb
resources :documents do
  scope module: 'documents' do
    resources :versions do
      post :restore, on: :member
    end

    resource :lock
  end
end