atmos

@holman got a request about our deployment system, heaven

I know it's not a high priority, but has there been any activity on open-sourcing the core Heaven gem?

There is. I've been working on extracting the non-GitHub specific parts into two gems. This first is a CLI portion called hades. The second is an HTTP API portion called heaven.

When you open source something previously used as in internal tool like Heaven, Hubot, Boxen, etc., how do you manage and hook in the parts that need to stay internal?

Normally I focus around four questions:

maxim

In Rails 3

NOTE: This post now lives (and kept up to date) on my blog: http://hakunin.com/rails3-load-paths

If you add a dir directly under app/

Do nothing. All files in this dir are eager loaded in production and lazy loaded in development by default.

If you add a dir under app/something/

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).
#

pmarreck

# Ruby fizzbuzz, functional style, no conditionals whatsoever

one_if_divisible_by = lambda{|num, x| (1-((x.to_f / num) % 1).ceil)}.curry
fizz1 = one_if_divisible_by.(3)
buzz1 = one_if_divisible_by.(5)
one_to_word = lambda{|func, word, n| word * func.(n)}.curry
one_to_n_to_s = lambda{|func, n| n.to_s * func.(n)}.curry
fizz = one_to_word.(fizz1,'Fizz')
buzz = one_to_word.(buzz1,'Buzz')

jcoglan

$VERBOSE = nil
require File.expand_path('../rooby', __FILE__)


Person = Rooby::Class.new 'Person' do
  define :initialize do |name|
    @name = name
  end
  
  define :name do

brianstorti

#Practical Object Oriented Design in Ruby

Design that anticipate specific future requirements almost always end badly.
Practical design does not anticipate what will happen to your application, it merely accepts that something
will and that, in the present, you cannot know what. It does not guess the future; it preserves your options for accommodating the future.
It doesn't choose; it leaves you room to move.
The purpose of design it to allow you to do it later and its primary goal is to reduce the cost of change.

Design is more the art of preserving changeability than it is the act of achieving perfection.

jasonrudolph

About

This gist is a collection of my rough notes from Strange Loop 2012.

@jasonrudolph on Twitter | @jasonrudolph on GitHub

Did I Mention That They're Rough?

alandotcom

Originally posted as a private gist

Inspiration: What's that & doing?

Before I get started, the inspiration behind this was a piece of code written to solve a Ruby exercise: Write a method reverse_words which takes a sentence as a string and reverse each word in it.

The solution that set me on a journey of diving deeper into closures was this one, by Daniela Grossman:

	def reverse_words(str)
 str.split(' ').map(&:reverse).join(' ')

mattetti

::Redis::Client.class_eval do

  # Support older versions of Redis::Client that used the method
  # +raw_call_command+.
  call_method = ::Redis::Client.new.respond_to?(:call) ? :call : :raw_call_command

  def call_with_stats_trace(*args, &blk)
    method_name = args[0].is_a?(Array) ? args[0][0] : args[0]
    start = Time.now
    begin

andkerosine

$stack, $draws = [], {}

def method_missing *args
  return if args[0][/^to_/]
  $stack << args.map { |a| a or $stack.pop }
  $draws[$stack.pop(2)[0][0]] = args[1] if args[0] == :<
end

class Array
  def +@