assert_response :success

Hem trobo que de tant en tant he d’instal·lar tot l’entorn de desenvolupament rails per a un amic que m’ho demana per provar-ho. De fet a força de fer-ho vàries vegades al final vaig automatitzar-ho amb una tasca de capistrano per alleugerir el procés.

Per a que hem serveixi de referència per al pròxim cop (cas que no tingui el meu macbook a mà) els passos a seguir són:

1. Instal·lar les “Xcode tools” (que es troben el els CD’s de sistema), pel compilador.

2. Instal·lar darwinports i actualitzar-lo:

1
2

sudo port selfupdate
sudo port sync

3. Instal·lar programari necessari (ruby, ruby-gems, postgres, etc):

sudo port install screen subversion postgresql81 ruby rb-rubygems

4. Instal·lar les gems que ens interessin, per exemple:

sudo gem install rails rcov gettext mongrel gettext zentest postgres --include-dependencies

5. Preparar la gem del postgres(requereix de fer un petit “hack” per a que trobi les llibreries al compilar) i inicialitzar la base de dades:

1
2
3
4
5
6
7

cd /opt/local/lib/ruby/gems/1.8/gems/postgres-0.7.1
sudo ruby extconf.rb --with-pgsql-include=/opt/local/include/pgsql8 --with-pgsql-lib=/opt/local/lib/pgsql8
sudo make && sudo make install
# Per si de cas
sudo gem install postgres
# Inicialitzem la base de dades (al directori que ens sembli adient)
/opt/local/lib/postgresql81/bin/initdb -D development/pgdata

6. Inicialitzar la base de dades i comprovar que tot funciona amb un projecte de test:

1
2
3
4
5

# Iniciar postgres
pg_ctl -D /development/pgdata -l ~/development/pgdata/psql.log start
# Per aturar-lo pg_ctl -D ~/development/pgdata stop
# Crear un projecte rails per a testejar que tot funciona correctament
rails -d postgresql testproject

7. Opcionalment, continuar la configuració segons aquest post.

De vegades ens trobem que necessitem especificar una versió o versions concretes d’una gem en el nostre codi.

Per exemple, normalment per a utilitzar el gettext faríem:

require 'gettext'

Aquest comanda requeriría la darrera versió de la gem instal·lada al sistema, si volem ser més específics podriem fer:

require_gem 'gettext', '= 1.8.0'

Això requeriría una versió de gettext 1.8.0 específicament, també podríem fer:

require_gem 'gettext', '~> 1.9.0'

Això requeriría una versió de gettext de la serie 1.9.x

Això és una bona pràctica ja que ens permet reduir els problemes d’implementació de la nostra aplicació ja que podem especificar les versions o versions que sabem del cert que funcionaran correctament amb la nostra aplicació.

l’irb és una eina molt útil a l’hora de desenvolupar, ja que ens permet tant debugar com provar en temps real el codi.

Ara és possible també d’obtenir acoloriment de sintàxi, per a fer-ho primer haurem d’instalar una gem:

sudo gem install -y wirble

I després actualitzar el nostre .irbrc, que podría quedar així per exemple:

1
2
3
4
5
6

require 'irb/completion'
require 'rubygems'
require 'wirble'

ARGV.concat [ "--readline", "--prompt-mode", "simple" ]
Wirble.init

Aquest tipus de “trucos” són des meus preferits, petits detalls que faciliten la rutina diària enormement.

Font: ruby inside

De vegades ens pot resultar útil canviar el directori per defecte a utilitzar per a la memòria cau a nivell de pàgina.

Hauríem d’afegir quelcom similar al environment de producció:

config.action_controller.page_cache_directory = RAILS_ROOT+"/cami/al/meu/directori/"

Un efecte secundari de fer quelcom així es que llavors podem purgar tota la memòria cau simplement esborrant tots els continguts del directori en qüestió:

rm -rf /cami/al/meu/directori/*

Això ho podem fer també desde el propi codi de l’aplicació o des d’una tasca de capistrano, per tal de purgar la memòria cau cada cop que fem un deploy.

Coincidint amb la recent sortida de la versió 1.2 de rails, vam estar discutint amb els companys els avantatges i inconvenients de les named routes respecte a les alternatives ja existents:

1
2

# Named route example
map.blog_post 'bloc/:user/post/:post', :controller=>'blog', :action=>"post"

1
2

# Default implicit route
map.connect ':controller/:action/:id'

Els inconvenients mencionats de les named routes en la discussió van ser:

• Requereixen de ser més explicits i per tant hi ha més feina de definició.
• En general emprar el sistema de routes de rails té un impacte considerable en rendiment.

La veritat es que ambdués consideracions són certes, però l’avantatge principal que aporten les named routes és el “decoupling” de les routes dels controladors i les accions, això fa que sigui molt més senzill de canviar tant les propies routes com el mapeig amb els controladors i accions a que fan referencia sense haver de modificar el nostre codi. Per exemple a l’hora de generar un enllaç podem fer:

<%=link_to comments_text,  blog_post_url(:user=>post.author.alias, :post=>post.urlname, :anchor=>"comments ") %>

Pel que fa als inconvenients mencionats:

• Hi ha un post molt interessant d’en Jamis Buck al respecte, bàsicament podem estalviar-nos una mica de feina amb la opció with_options.
• Pel que fa al rendiment, com sempre és millor deixar les optimitzacions pel final i aplicar-les a on i quan ens facin realment falta. La solució passaria per no utilitzar els mètodes link_to i similars en les vistes i utilitzar les url a pèl.