speric

Chapter 1 - Object Oriented Design

The purpose of design is to allow you to do design later, and it's primary goal is to reduce the cost of change.

SOLID Design:

• Single Responsibility Principle: a class should have only a single responsibility
• Open-Closed Principle: Software entities should be open for extension, but closed for modification (inherit instead of modifying existing classes).
• Liskov Substitution: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
• Interface Segregation: Many client-specific interfaces are better than one general-purpose interface.

dominictarr

(dominic: this list of papers was originally recommended to me by Brain Noguchi @bnoguchi, and was a great start to understanding distributed systems)

Here's a selection of papers that I think you would find helpful and interesting:

Time, Clocks, and the Ordering of Events in a Distributed System

The seminal paper about event ordering and concurrency. The important result is that events in a distributed system define a partially ordered set. The connection to what we're working on is fundamental, as this defines how to detect concurrent updates. Moreover, the chosen algorithm to turn the partially ordered set into a totally ordered set defines the conflict resolution algorithm.

http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf

dmichael

package httpclient

import (
    "net"
    "net/http"
    "time"
)

type Config struct {
    ConnectTimeout   time.Duration

garybernhardt

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

blairanderson

Dependency Injection in Ruby 07 Oct 04

Introduction

At the 2004 Ruby Conference, Jamis Buck had the unenviable task to explain Dependency Injection to a bunch of Ruby developers. First of all, Dependency Injection (DI) and Inversion of Control (IoC) is hard to explain, the benefits are subtle and the dynamic nature of Ruby make those benefits even more marginal. Furthermore examples using DI/IoC are either too simple (and don’t convey the usefulness) or too complex (and difficult to explain in the space of an article or presentation). I once attempted to explain DI/IoC to a room of Java programmers (see onestepback.org/articles/dependencyinjection/), so I can’t pass up trying to explain it to Ruby developers.

Thanks goes to Jamis Buck (the author of the Copland DI/IoC framework) who took the time to review this article and provide feedback.

What is Dependency Injection?

henrik

1. Your class can be no longer than 100 lines of code.
2. Your methods can be no longer than five lines of code.
3. You can pass no more than four parameters and you can’t just make it one big hash.
4. When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. And your view can only know about one instance variable.

You can break these rules if you can talk your pair into agreeing with you.

swlaschin

Functional Track talks from NDC London 2014

Wednesday 2014-12-3

• F-Words - Functional Programming Terms With More Than Four Letters - Calvin Bottoms
• Reactive Game Development For The Discerning Hipster - Bodil Stokke
• Erlang Patterns Matching Business Needs -- Torben Hoffman
• Equivalence Classes, xUnit.net, FsCheck, Property-Based Testing -- Mark Seemann
• Functional programming design patterns -- Scott Wlaschin
• Write Your Own Compiler in 24 Hours -- Phillip Trelford

croaky

module DelayedJob
  module Matchers
    def enqueue_delayed_job(handler)
      DelayedJobMatcher.new handler
    end

    class DelayedJobMatcher
      def initialize(handler)
        @handler = handler
        @attributes = {}

jkrems

In all the discussions about ES6 one thing is bugging me. I'm picking one random comment here from this io.js issue but it's something that comes up over and over again:

There's sentiment from one group that Node should have full support for Promises. While at the same time another group wants generator syntax support (e.g. var f = yield fs.stat(...)).

People keep putting generators, callbacks, co, thunks, control flow libraries, and promises into one bucket. If you read that list and you think "well, they are all kind of doing the same thing", then this is to you.

martindemello

class PurchaseApprover
  # Implements the chain of responsibility pattern. Does not know anything
  # about the approval process, merely whether the current handler can approve
  # the request, or must pass it to a successor.
  attr_reader :successor

  def initialize successor
    @successor = successor
  end