assert_response :success

He publicat un petit plugin de rails que afegeix als logs els “explain” o “explain analyze” de les consultes sql. Solament funciona si estem utilitzant una base de dades postgresql.

Podeu consultar-ne els detalls aquí.

Un exemple de la sortida als logs:

1
2
3
4
5
6
7
8
9
10
11
12

Component Load (0.039698)   SELECT components.* FROM components INNER JOIN web_module_components ON components.id = web_module_components.component_id WHERE ((web_module_components.web_module_id = 5)) ORDER BY web_module_components.order ASC

  Explain Component Load
   
  Sort  (cost=42.37..42.38 rows=5 width=565)
    Sort Key: web_module_components."order"
    ->  Hash Join  (cost=30.48..42.31 rows=5 width=565)
          Hash Cond: (components.id = web_module_components.component_id)
          ->  Seq Scan on components  (cost=0.00..11.30 rows=130 width=561)
          ->  Hash  (cost=30.38..30.38 rows=8 width=8)
                ->  Seq Scan on web_module_components  (cost=0.00..30.38 rows=8 width=8)
                      Filter: (web_module_id = 5)

Per si voleu anar seguint les sessions de la Railsconf, aquest enllaç us pot resultar interessant.

Avui hi han hagut sessions molt interessants a veure si més tard tinc temps de donar-ne la meva opinió i fer-ne un breu resum.

Sempre m’han agradat les entrades de blocs o fils de discusió on la gent comparteix els seus profiles de bash, .vimrc, .muttrc i fitxers de configuració diversos, ja que normalment sempre s’aprèn alguna cosa que de vegades resulta bastant útil.

Aquest és el .profile que utilitzo en el meu macbook:

Fa un temps era pràctica habitual organitzar els controladors en namespaces, segurament almenys separar els controladors públics dels que eren utilitzats per a les àrees d’administració.

Per a refrescar la memòria:

script/generate controller admin/articles

Creem un controllers/admin_area_controller.rb:

1
2
3
4

class AdminAreaController < ApplicationController
  before_filter :require_login
  layout "admin"
end

I controllers/admin/articles_controller.rb hereda ara de l’AdminAreaController

1
2
3

class Admin::ArticlesController < AdminAreaController
  # El meu codi
end

Doncs bé, aquesta pràctica era bastant habitual i semblaria que es una bona pràctica si no fos pels problemes que pot arribar a comportar…

Ens podem trobar amb conflictes (no evidents d’entrada) amb les routes de rails, entre d’altres, si tenim un model amb el mateix nom que un dels mòduls (que hem utilitzat per a fer el namespace del controlador) ja que en Ruby una classe i un mòdul no podem tenir el mateix nom.

Ara per ara semblaria que no es una bona pràctica a utilitzar en general. Encara que crec que és bastant útil, a nivell d’organització de controladors, separar la part administrativa de la pública.

La veritat es que si fem aplicacions “RESTful” la utilització de namespaces comença a tenir menys sentit, malgrat això la idea de tenir tots els controladors en un sol namespace per a aplicacions molt grans no reconforta gaire.

Trobo que el tema de l’organització de controladors és molt interessant. Com ho organitzeu en els vostres projectes? personalment tot en el mateix namespace (o sigui tot a app/controllers) almenys fins que trobi una alternativa millor…

El gems plugin és un plugin molt útil desenvolupat pel Rick Olson. La idea és molt senzilla, es tracta de proveïr una funcionalitat similar a:

rake rails:freeze:gems

Però en el contexte de les gems “no rails” de que depen el nostre codi, això és molt útil si hem de fer deploys de les nostres aplicacions en entorns que no controlem i volem assegurar que l’aplicació funciona correctament.

Podem estudiar el codi del plugin per a entendre com funciona tot plegat a més baix nivell, primerament la sintaxi del plugin es molt senzilla:

rake gems:freeze GEM=tzinfo VERSION=0.1.2

Aquest comanda ens posaria el codi de la versió 0.1.2 de la gem tzinfo al directori vendor/tzinfo-0.1.2/. Però evidentment amb això no n’hi ha prou ja que al fer un require 'tzinfo' cal que sàpiga que ha de buscar primer a vendor/tzinfo-0.1.2/lib

De vegades necessitem especificar que un camp d’una taula que estem creant sigui únic, per a aconseguir-ho podem afegir un index amb la opció :unique => true.

Un exemple de migració per a veure-ho més clar:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class CreateFeeds < ActiveRecord::Migration
  def self.up
    create_table :feeds do |t|
      t.column "created_at", :datetime, :null => false
      t.column "updated_at", :datetime, :null => false
      t.column "title", :string
      t.column "home_url", :string
      t.column "rss_url", :string, :null => false
    end
    add_index :feeds,         # Nom de la taula 
              :rss_url,       # Nom del camp
              :unique => true # Opcions
  end

  def self.down
    drop_table :feeds
  end
end

La intenció es aconseguir que el camp :rss_url sigui únic.

Els generadors son una peça molt important de rails i una d’aquelles que es fan servir constantment.

Per exemple cada cop que executem una comanda com ara:

1
2

script/generate model User
script/generate controller user

Estem executant el que rails anomena generador, que el que fa es generar codi per nosaltres, això contribuix a accelerar el cicle de desenvolupament i a lliurar-nos de tasques tedioses i repetitives.

La generació de codi no es un tema nou, vull dir que tots els que ens dediquem al món del desenvolupament l’hem utilitzat en major o menor mesura, el que potser no era tan habitual era la seva utilització en frameworks de desenvolupament.

Podem crear els nostres propis generadors, per exemple podem veure com crear-ne un que ens ajudi amb les configuracions de mongrel, apache, deploy i rotació de logs.

Aquest script és per a generar parelles pel pair programming i enviar un correu amb les mateixes setmanalment via cron.

1
2
3
4
5
6
7
8
9
10
11

#!/usr/bin/ruby

programadors = %w( Ramon Carles Aleix Marc Oscar Jordi Guillem Francesc Miquel)
subject = "Programming pairs for the #{Time.now.strftime("%Uth week of %Y")}"
pairs = "Programing pairs:\n"

while programadors.size > 0 do
  pairs << programadors.delete_at(rand(programadors.size)) + " -- " + programadors.delete_at(rand(programadors.size)) + "\n"
end

`echo "#{pairs}" | iconv -f utf-8 -t iso-8859-1 | mail -s "#{subject}" programadors@company.com`

Maneres de millorar-lo, fer-lo més DRY, curt o més idiomàtic?

Existeixen almenys 2 solucions simples per a disposar d’integració contínua en els nostres projectes rails. Per una banda el plugin continuous builder i per l’altre cerberus

A continuació un script i un hook de subversion per a automatitzar les tasques d’inicialització de nous projectes al cerberus i el llançament dels builds dels projectes cada cop que es fa un commit al repo.

Quan treballem amb rails es habitual de fer moltes tasques a la terminal:

1. Fer un tail dels logs.
2. Utilitzar la consola de rails.
3. Iniciar, aturar el servidor web de desenvolupament.
4. Iniciar, aturar la base de dades.
5. Utilitzar la comanda svn.
6. Executar tasques de rake (generar documentació, tirar els tests, etc…)
7. grep, find, awk, etc.

Això fa que sigui molt senzill acabar amb un munt de terminals i pot arribar a ser una mica incòmode de gestionar.

Podem minitmitzar aquests inconvenients amb una mica de planificació, bash i screen. La idea es evitar aquelles tasques repetitives que hem de fer cada cop que volem treballar en un projecte.