rlemon

Fork it, use it, break it, fix it,
Comm it, push it, pull - request it,
Fetch it, branch it, patch it, fake it, 
Merge it, git: it, never - https: it.

Write it, cut it, paste it, save it,
Build it, check it, quick - rewrite it,
Clone it, crack it, crop it, comp it,
Drag and drop it, gzlib - gzip it.

bkutil

after "deploy:symlink", "deploy:restart_workers"
after "deploy:restart_workers", "deploy:restart_scheduler"

##
# Rake helper task.
# http://pastie.org/255489
# http://geminstallthat.wordpress.com/2008/01/27/rake-tasks-through-capistrano/
# http://ananelson.com/said/on/2007/12/30/remote-rake-tasks-with-capistrano/
def run_remote_rake(rake_cmd)
  rake_args = ENV['RAKE_ARGS'].to_s.split(',')

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

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.

croaky

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

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

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

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.

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?

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.

dmichael

package httpclient

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

type Config struct {
    ConnectTimeout   time.Duration