xpepper

Names

The name that you use should reveal your intent

• comments are a smell of a badly chosen name!
• Only choose names that communicate your intent

Use pronounceable names

xpepper

# Original Rails controller and action
class EmployeesController < ApplicationController
  def create
    @employee = Employee.new(employee_params)
    
    if @employee.save
      redirect_to @employee, notice: "Employee #{@employee.name} created"
    else
      render :new
    end

xpepper

There's no general rule you can follow here, because it's always going to depend on context. In my experience the kind of feedback loops you create, and the kind of safety nets you need are defined entirely by the domain, the organization, and the team culture.

Here are a few examples:

1. I do a bit of work for a medium-sized dental clinic. The business manager there is really fun to work with, but has the tendency of changing his mind six times before he settles his ideas. So when he asks for a report, I don't put any effort at all into writing tests or worrying about minor bugs even, because my only goal is to flesh out in code something vaguely resembling what he asked for.

Often times, this means doing a handful of 30 minute prototypes until the requirements settle, each of which would have taken me 2 hours if I drove them via TDD. When things finally cool down, I evaluate the complexity and maintainability of the resulting code and either leave it untested, add some acceptance tests, backfill unit tes

xpepper

Description

This simple script will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.

The script is here:

#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"

Results

xpepper

Mac OS X

Mensch coding font

Apps

• Webkit
• Chrome
• Firefox
• Opera

xpepper

--colour
-I app

xpepper

require File.join(File.dirname(__FILE__), 'deploy/nginx')
require File.join(File.dirname(__FILE__), 'deploy/log')

default_run_options[:pty] = true
set :ssh_options, { :forward_agent => true }

set :application, "appname"
set :repository,  "git@giturl"

set :scm, :git

xpepper

desc "Backup the database"
namespace :db do
	task :backup do
		on roles(:db) do |host|
			backup_path = "#{fetch(:deploy_to)}/backups"
			execute :mkdir, "-p #{backup_path}"
			basename = 'database'
			
			username, password, database, host = get_remote_database_config(fetch(:stage))
			debug "#{username}, #{password}, #{database}"

xpepper

# Directly copied from eycap-0.5.2 (thanks!)
#
# With these tasks you can:
#   - dump your production database and save it in shared_path/db_backups
#   - dump your production into your local database (clone_to_local)
#
# Tested and fixed by fjguzman
Capistrano::Configuration.instance(:must_exist).load do

  namespace :db do

xpepper

install PostgreSQL 9 in Mac OSX via Homebrew


Mac OS X Snow Leopard
System Version: Mac OS X 10.6.5
Kernel Version: Darwin 10.5.0


Install notes for PostgreSQL 9.0.1 install using Homebrew:
	sh-3.2# brew install postgresql