xpepper

A Capistrano Rails Guide

by Jonathan Rochkind, http://bibwild.wordpress.com

why cap?

Capistrano automates pushing out a new version of your application to a deployment location.

I've been writing and deploying Rails apps for a while, but I avoided using Capistrano until recently. I've got a pretty simple one-host deployment, and even though everyone said Capistrano was great, every time I tried to get started I just got snowed under not being able to figure out exactly what I wanted to do, and figured I wasn't having that much trouble doing it "manually".

xpepper

Continued from I'm learning vim. Here's how I'm doing it, by Chris Geihsler

I've committed to learning vim to become more productive without the crutch of an expensive tool and to decouple myself from a specific OS.

Here's what I've done so far:

• Installed [MacVim] (http://code.google.com/p/macvim/)
• Learned [Command-T] (https://github.com/wincent/Command-T)
• Watched [this] (https://www.destroyallsoftware.com/screencasts/catalog/file-navigation-in-vim) and [that] (https://www.destroyallsoftware.com/screencasts/catalog/some-vim-tips) DAS episode
• Worked through vimtutor

xpepper

class Object
  def is_a_class?
    respond_to? :superclass
  end
end


class MyClass
end

xpepper

class Parent
  class << self
    def who_am_i
      puts "I'm #{self}"
    end
    
    def singleton
      class << self; self; end
    end
  end

xpepper

class Document
  def self.reload
    instance_methods(false).each { |m| remove_method(m) }
    class << self
      Document.methods(false).reject {|m| m == "reload" }.each do |m|
        remove_method(m)
      end
    end

    load(__FILE__)

xpepper

My issues with Modules

In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.

A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval.

You can find instance_eval used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.

class Article < ActiveRecord::Base

xpepper

  def search(search_options)
    name_regexp = search_options[:name_regexp] || ""
    starting_date = search_options[:starting_date] || Date.today
    ending_date = search_options[:ending_date] || Date.today
    where(:name => /#{name_regexp}/, "efforts.date" => {'$gte' => Date.parse(starting_date)}, "efforts.date" => {'$lte' => Date.parse(ending_date)})
  end

xpepper

# Ho creato una app rails semplice, con un modello User e uno Order. 

# User:
class User < ActiveRecord::Base
  attr_accessible :name, :surname
  has_many :orders
end

#Order:
class Order < ActiveRecord::Base

xpepper

#!/usr/bin/env ruby

require 'benchmark'

REGEXPS = [
  /^no such file to load -- (.+)$/i,
  /^Missing \w+ (?:file\s*)?([^\s]+.rb)$/i,
  /^Missing API definition file in (.+)$/i,
  /^cannot load such file -- (.+)$/i,
]

xpepper

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: