dfmonaco

require 'aws-sdk'

class Transfer
  def initialize(from_bucket, to_bucket)
    @s3 = AWS::S3.new

    @from_bucket = @s3.buckets[from_bucket]
    @to_bucket = @s3.buckets[to_bucket]

    raise "#{from_bucket} does not exist" unless @from_bucket.exists?

dfmonaco

Eric Elliott's "Composing Software" Series

A collection of links to the excellent"Composing Software" series of medium stories by Eric Elliott.

• The Rise and Fall and Rise of Functional Programming
• Why Learn Functional Programming in JavaScript?
• A Functional Programmer’s Introduction to JavaScript
• Higher Order Functions
• Reduce
• Functors & Categories
• [Composing

dfmonaco

Instrument Anything in Rails 3

With Rails 3.0 released a few weeks ago I've migrated a few apps and I'm constantly finding useful new improvements. One such improvement is the ability to log anything in the same way that Rails internally logs ActiveRecord and ActionView. By default Rails 3 logs look slightly spiffier than those produced by Rails 2.3: (notice the second line has been cleaned up)

Started GET "/" for 127.0.0.1 at Mon Sep 06 01:07:11 -0400 2010
  Processing by HomeController#index as HTML
  User Load (0.2ms)  SELECT `users`.* FROM `users` WHERE (`users`.`id` = 3) LIMIT 1
  CACHE (0.0ms)  SELECT `users`.* FROM `users` WHERE (`users`.`id` = 3) LIMIT 1

Rendered layouts/_nav.html.erb (363.4ms)

dfmonaco

# With thanks to https://github.com/optoro/activerecord-callback_notification for original inspiration
if Rails.env.development?
  module ActiveRecord
    module CallbackNotifications
      extend ActiveSupport::Concern

      module ClassMethods

        def notify_all_callbacks
          # Make sure all models are loaded before trying to enumerate

dfmonaco

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

dfmonaco

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

dfmonaco

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:

dfmonaco

$ rspec --format MacVimFormatter --color spec

dfmonaco

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


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

dfmonaco

Presenters in Rails

I have bemoaned the lack of a ViewModel in Rails many times, and I prefer using Presenters to simulate a ViewModel. But it turns out there is an object that does represent the state of the view in Rails apps. Its an instance of ActionView::Base that the controller calls view_context. We don't have much control of this object, but it seems like a logical place to put our view-specific behavior.

This code is an attempt at creating Presenters using modules. The module will be mixed into the view_context object. This is very similar to how a Decorator module will be mixed into a model object, only instead of being specific to the model is it specific to the view.

This means that testing your presenter is no different than testing any other module. So relying on dependencies such as other methods or instance variables can make testing difficult.