will

schema = pkgs.stdenvNoCC.mkDerivation {
  name = "schema";
  src = schemaSrc;
  nativeBuildInputs = [ postgres ];
  installPhase = ''
    mkdir $out
    export PGDATA="$out"
    export PGHOST="$out"
    export PGUSER=postgres
    export PGDATABASE=postgres

clupprich

%w(⠾ ⠷ ⠯ ⠟ ⠻ ⠽).cycle { |dot| print "\b#{dot}"; sleep 0.1 }

wojteklu

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

olivierlacan

This guide assumes that you recently run brew upgrade postgresql and discovered to your dismay that you accidentally bumped from one major version to another: say 9.3.x to 9.4.x. Yes, that is a major version bump in PG land.

First let's check something.

brew info postgresql

The top of what gets printed as a result is the most important:

Integralist

Lambda: standard

# Creating a lambda
l = lambda { |name| "Hi #{name}!" }

# Executing the lambda
l.call("foo") # => Hi foo!

henrik

html
  head
    title= title("My site")

henrik

# https://github.com/barsoom/attr_extras
require "attr_extras"

class UserSession
  pattr_initialize :controller, :session_key, :finder

  # NOTE: Not memoized yet.
  def user
    if id
      finder.find(id)

SzymonPobiega

If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:

In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):

1. Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
2. Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
3. Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
4. Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
5. Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
6. Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht

gus

For each Ruby module/class, we have Ruby methods on the left and the equivalent
Clojure functions and/or relevant notes are on the right.

For clojure functions, symbols indicate existing method definitions, in the 
clojure namespace if none is explicitly given.  clojure.contrib.*/* functions can
be obtained from http://github.com/kevinoneill/clojure-contrib/tree/master,
ruby-to-clojure.*/* functions can be obtained from the source files in this
gist.

If no method symbol is given, we use the following notation: