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)

Hem publicat una nova versió del plugin d’internacionalització de rails gettext_localize (que és una de les opcions que podeu utilizar si voleu desenvolupar aplicacions rails en català).

Els canvis en aquesta versió:

1
2
3
4
5
6

Version 0.4 28/11/2007
----

- Included french translation (thanks to Michel Loiseleur)
- Relaxed gettext gem requirements to include 1.10
- Fixed bug to make it work with ruby 1.8.6 (thanks to Luis E. Guardiola)

Per a més informació podeu consultar-ne la documentació.

Per a depurar les rutes mitjançant la consola de Rails:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$ script/console
Loading development environment.
# Carreguem la definició de les rutes
>> rs = ActionController::Routing::Routes
=> #<actioncontroller::routing::routeset:0x61d76c>> puts rs.routes
ANY    /feed/suggest/                           {:action=>"suggest", :controller=>"public"}
ANY    /feed/thanks/                            {:action=>"thanks", :controller=>"public"}
ANY    /:page/                                  {:action=>"index", :controller=>"public"}
ANY    /:controller/:action/:id.:format/        {}
ANY    /:controller/:action/:id/                {}
=> nil
# Reconeixement de rutes
>> rs.recognize_path "/feed"
=> {:action=>"index", :page=>"feed", :controller=>"public"}
>> rs.recognize_path "/feed/thanks"
=> {:action=>"thanks", :controller=>"public"}
>> rs.generate :controller => :public, :page => 2
=> "/2"
# Per a testejar rutes de controladors inexistents
>> ActionController::Routing.use_controllers! [ "undefined", "test" ]
=> ["undefined", "test"]
>> load "config/routes.rb"
=> []
>> rs.recognize_path "/undefined/show/1"
=> {:action=>"show", :id=>"1", :controller=>"undefined"}

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.

Aquest “tutorial” estava a càrrec d’en Jason Hoffman de Joyent . La veritat es que d’entrada prometia bastant ja que ells porten alguns dels “deployments” d’aplicacions Rails de més gran escala en l’actualitat com ara twitter per exemple.

La sessió ha tractat desde la selecció de servidors, consideracions de consum d’energia, costos d’ample de banda a alguns temes més específics d’aplicacions Rails.

Personalment pensava que tractaria més a fons temes específics sobre les bones pràctiques a l’hora d’escalar aplicacions Rails però les 2 primeres hores s’han centrat en temes de caire general, malgrat això la darrera hora ha estat prou interessant.

Algunes coses que he trobat especialment interessants:

1. Varnish balancejador de càrrega, aquest tema es important ja que sembla ser que a partir d’un cert nombre de req/s la combinació d’apache amb el mod_proxy_balancer no escala per més mongrels que afegim per tant no és una solució viable per a grans deployments.
2. Un truquet interessant que no havia pensat mai, es que podem utilitzar backtics (per a executar comandes de sistema) en els fitxers de configuració yml del mongrel_cluster per exemple de manera que els podem fer més genèrics. En el seu cas concret ho utilitzaven per determinar la ip i el hostname.
3. Utilitzar múltiples hosts per a distribuir els continguts estàtics. Això accelera les nostres pàgines ja que els navegadors sols obren 2 conexions per host. Això vol dir que si utilitzem 4 hosts (que es el que han recomanat) per distribuir el contingut estàtic això vol dir que s’obriran 8 conexions simultanies enlloc de les 2 si ho fessim amb un de sol. Més informació sobre el tema aquí
4. Powerdns un servidor de noms interessant que pot llegir les dades d’una base de dades mysql entre d’altre opcions. (O sigui que afegint un registre a una taula de la base de dades podem donar d’alta un subdomini, molt interessant per segons quin tipus d’aplicacions).
5. Mongrels més ràpids i estables aka event driven mongrels

Evidentment s’han tractat molts d’altres temes: com escalar la base de dades, Jruby o la separació dels controladors de la nostra aplicació amb mongrels específics.

En resum molt interessant però he trobat a faltar certa manca de profunditat a l’hora de tractar temes més específics de Rails.

D’aquí una estona sortim cap a la Railsconf 2007 , que aquest any es fa a Portland.

Miraré d’anar donant la meva opinió de les sessions a les que finalment assisteixi, de moment podeu fer un cop d’ull al que tinc planificat d’assistir aquí (per cert bona idea la de l’aplicació aquesta), però segurament faré canvis de darrera hora sobre el que tenia previst (s’han afegit noves sessions des que ho vaig mirar).

Si teniu comentaris o preguntes a fer, ja ho sabeu no us talleu…

A gnuine, l’empresa on treballo, estem buscant certs perfils que per la relació amb Ruby on Rails he pensat que potser podien interessar a algú de vosaltres.

Adjunto un extracte:

Programador

Treballaràs amb Ruby on Rails, però no es necessària experiència prèvia amb el framework, pero si en altres llenguatges com PHP, Python, Perl o Java.

1. Coneixements sòlids i experiència en programació. Busquem programadors de qualitat (interès per Ruby i Rails indispensable).
2. Familiaritat i interès pels mètodes de desenvolupament àgils, TDD, BDD, etc …
3. Domini: XHTML, CSS, Javascript, AJAX
4. Domini del món GNU/Linux. (en especial CentOS).
5. Coneixement de: MySQL, PostgreSQL, Subversion, Apache, Memcached …

Valorarem especialment:

1. Interès vital pel desenvolupament web i la web 2.0 (busquem gent apassionada que disfruti amb la seva feina).
2. Contribucions a projectes de programari lliure.
3. Experiència en Ruby i/o Ruby on Rails.
4. Experiència en PHP.

Administrador de sistemes

Treballaràs amb GNU/Linux de forma exclusiva, administrant sistemes en producció (clusters de servidors, replicació de base de dades, etc …) i participant activament en la implementació de noves plataformes i solucions tecnològiques.

1. Coneixements sòlids i experiència demostrable en l’administració de sistemes GNU/Linux.
2. Coneixements sòlids de xarxes IP i seguretat informàtica.
3. Coneixements sòlids i experiència amb almenys algun llenguatge de programació: c, c++, python, php, ruby, bash, etc …
4. Experiència en l’administració de: named, postfix, qmail, apache, mysql, postgresql, squid, lvs, memcached, nfs, iptables, nagios, etc …
5. Familiaritat amb les distribucions més habituals i en especial CentOS.

Valorarem especialment:

1. Interès vital per l’administració de sistemes GNU/Linux, capacitat d’investigar, proposar i implementar solucions tecnològiques.
2. Coneixements i interès per l’escalabilitat i l’alta disponibilitat.
3. Capacitat d’anàlisi i resolució d’incidències.
4. Interès pel desenvolupament web.

Per a més informació, podeu visitar la web de gnuine

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…

Ha aparegut una nou site anomenat Railscasts que proveeix de screencasts gratuïts sobre ruby on rails.

La diferència respecte a Peepcode (site que també proveeix screencasts però de pagament) es que els screenscasts tenen una duració molt inferior, de 3 a 10 minuts aproximadament i estan molt més focalitzats a temes molt específics.

Una bona iniciativa.

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.