jimweirich

    context "with an isolated decorator class" do
      let(:decorator_class) { Class.new(Decorator) }
      subject{ decorator_class.new(source) }

      context "when #hello_world is called again" do
        it "proxies method directly after first hit" do
          subject.methods.should_not include(:hello_world)
          subject.hello_world
          subject.methods.should include(:hello_world)
        end

jamesgolick

package org.objectify.adapters

import org.objectify.HttpMethod._
import org.objectify.Action
import org.objectify.Objectify
import org.scalatra.servlet.ServletBase

trait ScalatraAdapter extends Objectify with ServletBase {

    /**

jnunemaker

require 'pp'
require 'rubygems'
require 'mongo'

conn = Mongo::Connection.new
db = conn.db('test')
col = db['test']
col.remove

oid = BSON::ObjectId.new

tenderlove

(require-extension stty)

(define (muck-with-tty file)
  (stty file)
  (print (read-char file)))

(define file "client.scm")

(call-with-input-file file muck-with-tty)

practicingruby

require "sqlite3"

SQLite3::Database.new(":memory:") do |db|
  rows = db.execute <<-SQL
    create table numbers (
      name varchar(30),
      val int
    );
  SQL

practicingruby

Inheritance is a key concept in most object-oriented languages, but applying it skillfully can be challenging in practice. Back in 1989, M. Sakkinen wrote a paper called Disciplined inheritance that addresses these problems and offers some useful criteria for working around them. Despite being more than two decades old, this paper is extremely relevant to the modern Ruby programmer.

Sakkinen's central point seems to be that most traditional uses of inheritance lead to poor encapsulation, bloated object contracts, and accidental namespace collisions. He provides two patterns for disciplined inheritance and suggests that by normalizing the way that we model things, we can apply these two patterns to a very wide range of scenarios. He goes on to show that code that conforms to these design rules can easily be modeled as ordinary object composition, exposing a solid alternative to tradi

dchelimsky

describe Article do
  def article; Article.new :title => "Lorem ipsum"; end

  it "has a title" do
    article.title.should eq("Lorem ipsum")
  end
end

joshsusser

def collect(&block)
  inject([]) { |memo, obj| memo << block.call(obj) }
end

def detect(&block)
  inject(nil) { |memo, obj| memo ||= obj if block.call(obj) }
end

def reject(&block)
  inject([]) { |memo, obj| block.call(obj) ? memo : memo << obj }

joshsusser

if Rails.env.development?

  Rails.application.assets.logger = Logger.new('/dev/null')

  Rails::Rack::Logger.class_eval do
    def call_with_quiet_assets(env)
      previous_level = Rails.logger.level
      Rails.logger.level = Logger::ERROR if env['PATH_INFO'] =~ %r{^/assets/}
      call_without_quiet_assets(env)
    ensure

bokmann

# MOTIVATION:  As rails apps are growing, people are noticing the drawbacks
# of the ActiveRecord pattern.  Several apps I have seen, and several
# developers I have spoken to are looking towards other patterns for object
# persistence.  The major drawback with ActiveRecord is that the notion
# of the domain object is conflated with what it means to store/retrieve
# it in any given format (like sql, json, key/value, etc).
#
# This is an attempt to codify the Repository pattern in a way that would
# feel comfortable to beginner and seasoned Ruby developers alike.
#