zires

set :application, "hermes"
set :repository,  "git@your_repository:hermes.git"
set :user, 'root'
set :use_sudo, false

set :deploy_via, :remote_cache
set :scm, :git
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none`

role :web, "xxx.com"                          # Your HTTP server, Apache/etc

WizardOfOgz

class Avatar < ActiveRecord::Base

  attr_accessor :content_type, :original_filename, :image_data
  before_save :decode_base64_image

  has_attached_file :image,
    PAPERCLIP_CONFIG.merge(
    :styles => {
      :thumb => '32x32#',
      :medium => '64x64#',

RiANOl

require "openssl"
require "digest"

def aes128_cbc_encrypt(key, data, iv)
  key = Digest::MD5.digest(key) if(key.kind_of?(String) && 16 != key.bytesize)
  iv = Digest::MD5.digest(iv) if(iv.kind_of?(String) && 16 != iv.bytesize)
  aes = OpenSSL::Cipher.new('AES-128-CBC')
  aes.encrypt
  aes.key = key
  aes.iv = iv

cdmwebs

Friendly URLs

By default, Rails applications build URLs based on the primary key -- the id column from the database. Imagine we have a Person model and associated controller. We have a person record for Bob Martin that has id number 6. The URL for his show page would be:

/people/6

But, for aesthetic or SEO purposes, we want Bob's name in the URL. The last segment, the 6 here, is called the "slug". Let's look at a few ways to implement better slugs.

jcasimir

Render and Redirect

The normal controller/view flow is to display a view template corresponding to the current controller action, but sometimes we want to change that. We use render in a controller when we want to respond within the current request, and redirect_to when we want to spawn a new request.

Render

The render method is very overloaded in Rails. Most developers encounter it within the view template, using render :partial => 'form' or render @post.comments, but here we'll focus on usage within the controller.

:action

jcasimir

Exposing an API

APIs are becoming an essential feature of modern web applications. Rails does a good job of helping your application provide an API using the same MVC structure you're accustomed to.

In the Controller

Let's work with the following example controller:

class ArticlesController < ApplicationController

nkpart

#!/usr/bin/env ruby
# 2011-10-10 20:57:53 +1000

def merge_sort(a)
    return a if a.size <= 1
    l, r = split_array(a)
    result = combine(merge_sort(l), merge_sort(r))
end

rstacruz

Rails Models

Generating models

$ rails g model User

Associations

belongs_to

has_one

josevalim

This is an experiment for possible faster boot time (and consequently faster feedback) when running tests. I ask your help to try this in your apps (any Rails 3.x app) and let me know how well it works.

How to

Add the following lines inside the configuration block in config/environments/test.rb:

config.cache_classes = true
def eager_load!; end

porcelli

Intro

Vou iniciar este post com uma breve visão do que EU entendo sobre os principais XDD para em seguida discutir o motivo pelo qual não os acho relevante. Gostaria também de ressaltar que posso SIM ter uma visão limitada ou equivocada destes XDD’s, porém não vamos minimizar esta discussão com argumentos simplórios como “falta de conhecimento”, “falta de prática” ou coisas do gênero... pois o que será discutido aqui é um pouco mais conceitual e filosófico do que as técnicas/processos em si.

Com isso dito, vamos lá:

TDD (Test-driven development)

Esta técnica (ou processo) que visa obter uma maior qualidade na arquitetura/código, pois guindo o desenvolvimento por testes além de se ter um resultado mais assertivo, você também obtém uma arquitetura desacoplada. Geralmente se aplica este processo (NovoTeste->Falha->Implantação->Sucesso->NovoTeste...) em pequenos ciclos.

Meu ponto de vista: