chriseppstein

mymodule {
  @at-root {
    .#{&}-header { ... }
    .#{&}-footer { ... }
    .#{&}-body   {
      a          { ... } 
      span       { ... } 
      p          { ... } 
    }
  }

bf4

# use inverse_of to 'just work'
class User < ActiveRecord::Base
  has_many :contributions, inverse_of: :user
  has_many :posts, through: :contributions
end

class Post < ActiveRecord::Base
  has_many :contributions, inverse_of: :post
  has_many :contributors, through: :contributions,
    source: :user

gogogarrett

class ArtistsController < ApplicationController

  def create
    @form = create_new_form
    workflow = Workflows::ArtistWorkflow.new(@form, params[:artist])

    workflow.process do |obj|
      return respond_with obj
    end
    render :new

michaelfairley

Immutable Ruby

Libraries I talked about

• ice_nine: Deep freeze ruby objects
• Values: Simple immutable value objects for ruby
• immutable_attributes: specify attributes within an ActiveRecord model that can be set but not modified
• hamster: Efficient, Immutable, Thread-Safe Collection classes for Ruby

Next Steps

garybernhardt

# I don't really see any services here. What I see is:
#   - Normal HTTP boundary stuff (params flash, redirect).
#   - Model creation and retrieval.
#   - Warden manipulation, which is an odd done but smells like boundary.
#
# I left all of the HTTP boundary stuff in the controller (and only the
# controller). I moved the model creation/retrieval into simple class methods
# in the models. I moved the warden manipulation stuff into
# ApplicationController (with caveats that I'll discuss inline).
#

coldnebo

require 'singleton'

# outputs a colored call-trace graph to the Rails logger of the lines of ruby code
# invoked during a single request.
#
# Example:
#
# 1) Make sure this file is loaded in an initializer
#
# 2) Add the following to your application.rb in Rails3:

practicingruby

Models, Roles, Decorators, and Interactions

A modest alternative to DCI that might be worth further thought

One of the problems with advancing the discussion on DCI is that we lack a comparable alternative pattern that has the same goals, but favors a low ceremony approach. The closest thing we have to that is Rails concerns, but they are more like distant relatives of the DCI concepts rather than first cousins, and that makes comparisions between the two approaches not especially fruitful.

I am considering the idea of experimenting with my own paradigm that captures the intent and purity of DCI, but with the convenience of concerns. Please note that this is just the starting point of a conversation, it is NOT a promise of comercially available cold fusion or a cure for cancer. It's just a gist with an idea on it I'd like to hear your thoughts on.

What if we had a top-level topology that was split into Models, **Rol

concerning.rb

class Module
  # We often find ourselves with a medium-sized chunk of behavior that we'd
  # like to extract, but only mix in to a single class.
  #
  # We typically choose to leave the implementation directly in the class,
  # perhaps with a comment, because the mental and visual overhead of defining
  # a module, making it a Concern, and including it is just too great.
  #
  #
  # Using comments as lightweight modularity:

nicholasjhenry

# Source: https://gist.github.com/4172391#gistcomment-610165

class Order
  def complete_purchase(purchase)
    purchase.complete(credit_card, amount)
  end

  def purchase_completed(transaction_reference)
    update_attibutes(:transaction_reference => transaction_reference)
  end

xaviershay

class RegistrationsController < ApplicationController
  include Injector::ControllerMethods

  provided_by Controller::Registration
end