Un claro ejemplo lo encontramos cuando tenemos una relación :has_many y queremos comprobar si un elemento está incluída en dicha relación.

Por ejemplo:

class Place < ActiveRecord::Base
  has_many :items
end

class Item < ActiveRecord::Base
  belongs_to :place
end

Seguro que más de una vez, para comprobar que un place contiene un ítem hemos utilizado el "rubysta" include?:

place.items.include?(item)

Pensándolo fríamente 0.2 segundos nos damos cuenta de que estamos cargando un array con todos los elementos de una relación, que pueden ser 10 o pueden ser 1.000.000. Y ya sabemos lo generoso que es Ruby con la memoria que toma y que nunca deja ir.

Un truco para evitar que esto suceda sin dejar de utilizar include? es definir dicho método dentro de la relación tal que así:

class Place < ActiveRecord::Base
  has_many :items do 
    def include?(item)
      count(:conditions => ["item_id = ?", item.id]) > 0
    end
  end
end

Es decir, resolvemos el problema con un simple COUNT de Mysql.

¿Alguien se anima a hacer un plugin? Creo que sería bastante inmediato para cuando se cumplen las convenciones y sabemos que la clave foránea de la relación es singular del nombre de la relación_id. O quizá ni eso, si encontramos la forma de preguntarle a ActiveRecord cuál es la clave foránea de una relación.

Sin embargo muchas veces con el log de Rails no es suficiente, y hay que alcanzar un mayor nivel de detalle.

El log en modo debug nos da todo el detalle que necesitamos, pero mostrando demasiada información (¿de qué nos sirve saber que un SELECT sencillo tarda 0.001 segundos?).

Pero si en ese log pudiéramos filtrar las consultas SQL más lentas sí que tendríamos información de consultas lentas asociadas a cada petición al servidor.

Gracias al plugin query trace y a una pequeña modificación podemos mostrar qué consultas tardan más de 1 segundo:

module ActiveRecord
  module ConnectionAdapters
    class AbstractAdapter

      def log_info(sql, name, runtime)
        return unless @logger
        @logger.info(
          format_log_entry(
            "#{name.nil? ? "SQL" : name} (#{sprintf("%f", runtime)})",
            sql.gsub(/ +/, " ")
          )
        ) if (RAILS_ENV == 'production' && runtime > 1.0) || RAILS_ENV != 'production'
      end
    end
  end
end

Este código lo he probado en Rails 1.2.x, no sé si funcionará en otras versiones.

Sin embargo yo utilizo un script que creo que me pasó porras para que me muestre en colores las modificaciones.

El script es este:

#!/usr/bin/env ruby

`svn diff #{ARGV.join(' ')}`.each do |line|
  puts( if line =~ /^\+(.*)$/
        "\e[32m#{$&}\e[0m"
        elsif line =~ /^-(.*)$/
          "\e[31m#{$&}\e[0m"
        else
          line
        end
      )
end

Con darle permisos de ejecución ya podéis tener un svndiff por ejemplo.

No pongo el equivalente en git porque es bastante inmediato.

• claves: máximo de 250 caracteres
• valores alojados: máximo 1 Megabyte

Es muy difícil que una aplicación Rails las claves generadas a partir de las URL's tengan tanto tamaño, pero puede darse el caso y hay que tenerlo presente.

En el grupo de discusión acts_as_cached esta semana han propuesto hashear (con MD5, por ejemplo) las claves antes de guardarlas para curarnos en salud.

El problema es el siguiente: en unvlog.com (sí, ese proyecto del que no he hablado) somos muy Rails y tenemos para todos los recursos que tiene sentido una ruta que responde a un formato u otro según se le solicite pero con esta forma:

En concreto, esta URL corresponde al feed de un blog, feed que está cacheado en disco gracias a la caché de página de Rails. Pues bien, la idea es que el servidor web sirva directamente esta caché, así que una regla podría ser:

  if (-f /cache/$request_filename) {
          rewrite (.*) /cache/$1 break;
  }

(Esto, asumiendo que tenemos la caché en public/cache)

El problema es que esta regla no funciona, y creo que se debe a que blat.atom lleva un '.' y no es capaz de asignar la URL a la variable $request_filename.

Al final ha sido tan fácil como utilizar otra variable que he encontrado en la parte rusa del wiki, $request_uri:

  if (-f $document_root/cache/$request_uri) {
          rewrite ^/(.*).atom$ /cache/$1.atom break;
  }

Con esto ha funcionado perfectamente y ya tenemos cacheados y servidos por Nginx los feeds en unvlog.com.

Para acceder a él a través del cliente de Ruby, por ejemplo, basta con cargar una consola en el entorno deseado e invocar al método stats del objeto de caché.

Por ejemplo, si nuestra configuración es la siguiente:

  CACHE = MemCache.new 'localhost:11211', :namespace => 'wadus_fragments'

Podemos utilizar el objeto CACHE de la siguiente manera:

  pp CACHE.stats
  {"bytes"=>746532339,
   "pid"=>10303,
   "connection_structures"=>19,
   "time"=>1200349556,
   "limit_maxbytes"=>1073741824,
   "cmd_get"=>689486,
   "version"=>"1.1.12",
   "bytes_written"=>3296488315,
   "cmd_set"=>265986,
   "get_misses"=>265168,
   "total_connections"=>1238,
   "curr_connections"=>17,
   "curr_items"=>66977,
   "uptime"=>56490,
   "get_hits"=>424318,
   "total_items"=>265986,
   "rusage_system"=>95.012555,
   "rusage_user"=>17.16339,
   "bytes_read"=>3226552602}

La interpretación de todos estos valores se puede encontrar en la definición del protocolo:

  Name              Type     Meaning
  ----------------------------------
  pid               32u      Process id of this server process
  uptime            32u      Number of seconds this server has been running
  time              32u      current UNIX time according to the server
  version           string   Version string of this server
  pointer_size      32       Default size of pointers on the host OS
                             (generally 32 or 64)
  rusage_user       32u:32u  Accumulated user time for this process 
                             (seconds:microseconds)
  rusage_system     32u:32u  Accumulated system time for this process 
                             (seconds:microseconds)
  curr_items        32u      Current number of items stored by the server
  total_items       32u      Total number of items stored by this server 
                             ever since it started
  bytes             64u      Current number of bytes used by this server 
                             to store items
  curr_connections  32u      Number of open connections
  total_connections 32u      Total number of connections opened since 
                             the server started running
  connection_structures 32u  Number of connection structures allocated 
                             by the server
  cmd_get           64u      Cumulative number of retrieval requests
  cmd_set           64u      Cumulative number of storage requests
  get_hits          64u      Number of keys that have been requested and 
                             found present
  get_misses        64u      Number of items that have been requested 
                             and not found
  evictions         64u      Number of valid items removed from cache                                                                           
                             to free memory for new items                                                                                       
  bytes_read        64u      Total number of bytes read by this server 
                             from network
  bytes_written     64u      Total number of bytes sent by this server to 
                             network
  limit_maxbytes    32u      Number of bytes this server is allowed to
                             use for storage. 
  threads           32u      Number of worker threads requested.
                             (see doc/threads.txt)

En concreto cuatro parámetros me han parecido interesantes de observar:

• el parámetro bytes junto con el de limit_maxbytes: el primero representa el total de bytes ocupados actualmente, frente el máximo.
• el número de fallos de caché que refleja el valor del parámetro get_misses junto con el número de aciertos get_hits

Los primeros nos permiten saber si hemos llegado al límite el almacenamiento que necesita nuestra aplicación y el segundo nos permite saber si nuestra política de caché es adecuada: diviendo hits entre misses obtenemos la proporción de fragmentos encontrados frente a fragmentos que ya no existían. Un valor de 1 indica que por cada dos búsquedas, una tiene éxito y otra no.

Por supuesto un valor inferior a uno muestra que la caché no sirve de nada (indicaría por ejemplo que necesitaríamos ampliar el Memcache o que tenemos una política de borrado "exagerada").

Caché en Rails

Pronto, todas las demás, colgadas en la web de la Conferencia,

Además, en el post utilizan Nginx como servidor web y Ruby on Rails y Merb, como frameworks de desarrollo, así como Memcached para almacenar sesiones.

Los resultados, muy interesantes:

• Merb es mucho más rápido que Rails, a costa de perder parte de la magia
• Nginx es una gran alternativa a Apache, sobretodo cuando la memoria es un recurso escaso (en mi nuevo Slicehost, por ejemplo)
• y, el más importante, el evented Mongrel funciona bastante mejor que el Mongrel en situaciones de alta concurrencia

Así que si te gusta "jugar" y quieres probarlo, lo recomiendo: la instalación es muy sencilla y los resultados saltan a la vista.

La situación es la siguiente: es una cuenta Slicehost de 256Mb de memoria, en el que tú instalas lo que quieres. El problema es que debes de instalar un servidor web, los servidores de aplicaciones y la base de datos, y todos ellos han de luchar por esos 256Mb. Así que al final me he decidido por instalar esto:

• servidor web: Nginx, que tenía ganas de probarlo tras leer a uno de los sysadmins decir que Nginx era lo más estable que había visto nunca, y que recomendaba usar Apache sólo en el caso de querer que un mismo servidor web compartiera diferentes aplicaciones y en distintos lenguajes (PHP y Rails, por ejemplo). Además, su uso de memoria es ridículo.
• servidor de aplicaciones: Mongrel. Considerando los 60Mb que viene a consumir un Mongrel de memoria, el número de Mongrels en el clúster lo he establecido a 3.
• servidor de base de datos: MySQL. No había otra opción.

Además de todo esto, hay un servidor Memcached de 32Mb para guardar las sesiones.

Y claro, quería hacer pruebas de carga contra el stack completo para ver de rendimiento qué tal.

Las pruebas se han realizado contra una página sin caché y con bastantes consultas a la base de datos, cuyo tiempo de respuesta medio es de 0.005 segundos o lo que es lo mismo, unas 20 req/s.

El screencast

El screencast se queda algo corto en cuanto a uso de la herramienta httperf, ya que el autor pierde mucho tiempo explicando conceptos teóricos y muy básicos de Estadística: media y desviación estándar, así como cómo mostrar luego los resultados a través de gráficas (unas muy bonitas generadas con gruff).

Posteriormente las pruebas las realiza contra un único Mongrel, explicando con todo detalle:

• la importancia de utilizar datos reales: la muestra debe de ser representativa para que los resultados lo sean
• la importancia de obtener muchas muestras: cuantas más muestras, la media y la varianza son más significativas también
• la importancia de anotar todos los resultados
• la importancia de la interpretación de los mismos en función de los resultados obtenidos y entender qué significan

Las pruebas las realiza para comparar el rendimiento de su aplicación sin usar caché, utilizando caché de acción y utilizando caché de página. Así que establece el baseline en los resultados obtenidos sin utilizar caché y a partir de los obtenidos utilizando caché establece porcentajes de mejora.

Otros aspectos a tener en cuenta

Hay otras muchas situaciones en las que es recomendable hacer pruebas de rendimiento contra tu propia aplicación:

• calcular el número de Mongrels a lanzar en el servidor de aplicaciones. Una buena explicación (aunque breve también), la da Zed en la página de Mongrel: How many Mongrels
• comparar el rendimiento entre distintos sistemas de almacenamiento de sesiones
• comparar distintos algoritmos de balanceo en el módulo de proxy
• determinar el tope máximo de ficheros servidos a través de una unidad NFS
• ...

En estos casos es posible que nos interese conocer algún parámetro más de httperf que los que se han explicado en el vídeo:

• --rate: determinar el número de peticiones concurrentes lanzadas en un segundo
• --wsess: determina cada cuántas peticiones se inicia una nueva sesión

Y además, si vais a hacer pruebas de carga, hay que tener en cuenta estas perogrulladas, que a veces no lo son tanto:

1. el número de Mongrels en el clúster
2. la conexión: ¡no hagas las pruebas con un ADSL! En mi caso he pasado de 30 req/s a más de 50 req/s sólo por lanzar las pruebas desde una máquina con una conexión decente
3. testea el stack entero: sobre todo porque es interesante ver si hay problemas de conectividad entre una capa (web) y la otra (aplicación), o si el proxy que reparte la carga está mal configurado, etcétera

La verdad es que era un completo desconocido para mí hasta que encontré la presentación de Sergio Espeja en la conferencia de Rails: Tareas en background con RoR y BackgrounDRb.

En este año que ha pasado, hay una nueva versión que corrige algunos fallos y deja otros abiertos, pero que es, dicen, bastante estable. Y la verdad es que con la anterior tuve muchos problemas para crear mis workers pero con esta estoy encantado.

Pero este post no era para hablar de las bondades del proyecto, que son muchas, sino para contar cómo hacer que en los tests no necesitemos tener lanzado un servidor BackgroundDRB para que estos funcionen, sino que podemos utilizar un mock.

He encontrado uno entre los tickets del proyecto, y que se ve que aún no está incluído en la última versión.

Basta con descargarlo en test/mocks/test e incluir la siguiente línea en el test_helper.rb:

require File.dirname(__FILE__) + '/mocks/test/backgroundrb_mock.rb'

Y voilá, tests funcionando de nuevo.

El plugin se llama helper_test y es muy sencillo de utilizar:

1. descargar
2. editar tests/test_helper.rb e incluír la línea: require File.expand_path(File.dirname(__FILE__) + '/helper_testcase')
3. utilizar el generador que incluye: ./script/generate helper_test Foo

El test generado tendrá este aspecto:

  require File.dirname(__FILE__) + '/../../test_helper'

  class FooHelperTest < HelperTestCase

    include FooHelper

    #fixtures :users, :articles

    def setup
      super
    end

  end

A destacar que podemos utilizar fixtures.

Y la forma de proceder también es muy sencilla: creamos un test y en su interior podemos invocar al helper como si de un método más se tratara y comparar el resultado obtenido con los valores esperados. Si el helper tiene argumentos, ampliaremos el abanico de pruebas.

Una pequeña reflexión

La verdad es que no he podido pensar mucho sobre la efectividad de este plugin ni tampoco tengo experiencia utilizándolo (de hecho los desarrolladores de The-Shaker estábamos algo preocupados sobre el vacío que teníamos en los helpers de la aplicación, pues no tienen tests). En principio y echando un pequeño vistazo a los helpers que tenemos, parece que sí que se van a poder testear todos utilizando este plugin.

Sin embargo, hay que notar dos cosas:

La primera es que si en tu helper has utilizado una variable de instancia (confiando en que en la vista donde vas a utilizar dicho helper, la variable ya esté instanciada y con valor), debes de asignar una variable de igual nombre antes de invocar al helper en el test. Por ejemplo:

def available_tabs
  tabs =  "<ul>\n"
  tabs << " <li id=\"tab_blog\">" + link_to(_("Blog"), :controller => 'posts',
           :action => 'index', :blog_nicetitle => @blog.nicetitle) + "</li>\n"
  tabs << "</ul>\n"
end

Y el test:

def test_avaible_tabs
  @blog = blogs(:el_blog_de_quentin)
  tabs = available_tabs
  assert_equal tabs, '....'
end

Y la segunda es más bien una sugerencia: muchas veces los helpers generan HTML, y todos sabemos lo coñazo que puede ser comprobar la estructura del mismo, y las bondades del assert_select. Pues bien, se puede hacer un hack no muy elegante, pero bastante práctico para poder utilizar assert_select con el valor obtenido por un helper. Basta con editar el fichero helper_testcase.rb e incluír la línea:

  @response   = ActionController::TestResponse.new

dentro de la función setup. Y ahora, con que asignemos el helper a @response.body ya lo tenemos. Veamos un ejemplo:

def test_avaible_tabs
  @blog = blogs(:el_blog_de_quentin)
  @response.body = available_tabs
  assert_select 'ul'
end

Es sucio, poco semántico, y muy DRY, porque lo tienes que asignar tras cada invocación al helper, pero parece que de momento no hay otra forma. ¿Alguien se atreve a redefinir?

Su uso es bastante sencillo y cumple su labor perfectamente, a excepción de pequeños detalles que parece que falten por pulir.

Uno de esos "detalles insignificantes" es, para mi humilde opinión, el testing, que, aunque se puede realizar sin problemas, y con una cobertura muy buena de la funcionalidad, no queda tan limpio como queda en otras partes del framework.

De hecho, una de las cosas que más se echa en falta es algo de documentación. Por suerte, en los Manuales de Rails (qué mal suena, ¿no?), encontramos un "libro" sobre testing en Rails, y uno de sus capítulos es testing your Mailers, que es justo lo que queremos hacer.

Ahí proponen un esquema o esqueleto para los tests de unidad tal que así:

require File.dirname(__FILE__) + '/../test_helper'
require 'my_mailer'


class MyMailerTest < Test::Unit::TestCase
  fixtures :users
  FIXTURES_PATH = File.dirname(__FILE__) + '/../fixtures'
  CHARSET = "utf-8" 

  include ActionMailer::Quoting

  def setup
    ActionMailer::Base.delivery_method = :test
    ActionMailer::Base.perform_deliveries = true
    ActionMailer::Base.deliveries = []

    @expected = TMail::Mail.new
    @expected.set_content_type "text", "plain", { "charset" => CHARSET }
  end

  def test_reset_password
    user = User.find(:first)
    newpass = 'newpass'
    response = MyMailer.create_reset_password(user,newpass)
    assert_equal 'Your New Password', response.subject
    assert_match /Dear #{user.full_name},/, response.body
    assert_match /New Password: #{newpass}/, response.body
    assert_equal user.email, response.to[0]
  end

  private
    def read_fixture(action)
      IO.readlines("#{FIXTURES_PATH}/community_mailer/#{action}")
    end

    def encode(subject)
      quoted_printable(subject, CHARSET)
    end
end

Así un poco por encima, además de los requires pertinentes y de establecer unas cuantas constantes debemos de incluír include ActionMailer::Quoting para poder utilizarlo en los tests con aquellos emails que tengan acentos, eñes o cualquier otro carácter no estándar en el subject.

En el método setup configuramos el ActionMailer y además creamos un objeto TMail llamado @expected, y que utilizaremos en todos los tests para compararlo con el que genera nuestro modelo:

  def setup
    ActionMailer::Base.delivery_method = :test
    ActionMailer::Base.perform_deliveries = true
    ActionMailer::Base.deliveries = []

    @expected = TMail::Mail.new
    @expected.set_content_type "text", "plain", { "charset" => CHARSET }
  end

Y respecto a las fixturas, básicamente no tenemos, así que nos proponen utilizar ficheros de texto plano cuyo contenido será el contenido del email. Esos ficheros se sitúan en RAIlS_ROOT/test/fixtures/community_mailer/ como se puede ver en la función read_fixture:

  def read_fixture(action)
    IO.readlines("#{FIXTURES_PATH}/community_mailer/#{action}")
  end

Nuestro propio test

Con el esquema ya creado podemos empezar a escribir nuestros propios tests sobre nuestros modelos de Mailer.

Por ejemplo, veamos una acción muy simple de La Coctelera, que te envía un email cada vez que alguien te añade como amigo:

	def new_friend(user,friend)
    @headers['reply-to'] = user.email
    @from = 'admin@domain.com'
    @recipients = friend.email
    @subject = "[La Coctelera] #{user.shortname} te ha añadido como amigo"
    @body = {
      'user_name' => user.name,
      'friend_name' => friend.name,
      'profile_link' => profile_url(user.username),
      'profile_link_friends' => friends_url(friend.username)
    }
  end

Y esta es la vista asociada:

Hola <%= @friend_name %>!

<%= @user_name %> te ha añadido como amig@. Puedes visitar su página en la siguiente
dirección: <%= @profile_link %>

Puedes ver a todos tus amigos en:

<%= @profile_link_friends %>

Hasta otra!

--
La Coctelera
http://www.lacoctelera.com

El test podría ser algo tal que así:

def test_new_friend
  user = User.find_by_username('lucas')
  friend = User.find_by_username('blat')
  @expected.from = APP['adminmaster']
  @expected.subject = encode("[La Coctelera] #{user.shortname} te ha añadido como amigo")
  @expected.body = read_fixture('new_friend')
  @expected.to = friend.email
  @expected.reply_to = user.email
  assert_equal @expected.encoded, Notifier.create_new_friend(user, friend).encoded
end

El procedimiento es muy sencillo:

• cargamos a los dos usuarios implicados en la acción
• vamos rellenando los atributos de @expected con los valores que esperamos que tenga el email resultante: remitente, asunto, contenido, destinatario...
• finalmente, comparamos el email "esperado", con el que genera la acción create_new_friend

Hemos necesitado crear una fixtura new_friend con el siguiente contenido:

Hola Fernando!

Lucas Nicolás te ha añadido como amig@. Puedes visitar su página en la siguiente dirección: http://test.host/lucas/perfil
Puedes ver a todos tus amigos en:
http://test.host/blat/amigos
Hasta otra!
--
La Coctelera
http://test.host

Como veis, esta fixtura tiene una limitación más que evidente: no es dinámica, y su contenido depende de los valores (en este caso de los usuarios), que estamos utilizando en el test.

También quiero destacar esta línea:

  @expected.subject = encode("[La Coctelera] #{user.shortname} te ha añadido como amigo")

Cuando el subject del email vaya a incluir algún caracter acentuado, o con eñe, como es el caso, hay que forzar la recodificación de la cadena, pues ActionMailer también la recodificará cuando cree el email.

En un post posterior propondremos un par de mejoras para solventar alguna de las deficiencias que hemos visto.

Supongo que todo es acostumbrarse a utilizar uno u otro.

Y es que seguro que no todo lo que cuenta lo desconoces, pero tiene dos o tres perlas muy buenas.

Aquí van las que más me han gustado:

Repetir un comando con sudo:

	$ vim /etc/hosts
	$ sudo !!
	sudo vim /etc/hosts
	Password:

Utilizar el history para lanzar comandos:

$ history | head
    6  vim config/deploy.rb 
    7  vim config/deploy
    8  vim config/deploy.rb 
    9  cap club_deploy
   10  ssh bellini
   11  cd Proyectos/new-shaker-club/
   12  vim appserver/etc/logrotate.d/the-shaker
$ !10 # lanza un ssh a bellini

Alias de irb:

	alias irb='irb --readline -r irb/completion -rubygems' # use readline, completion and require rubygems by default for irb

Hay muchísimos más en el post que vale la pena repasar.

Y aquí algunos de mi cosecha:

Alias para resetear caché de resolución de nombres (ideal para cuando modificas el /etc/hosts):

	alias dns='sudo lookupd -flushcache'

Alias para ver los cambios en Subversion del directorio actual:

	alias stm='svn st | grep ^M'

Seguro que tú también utilizas alguno que otro, ¡así que ahí tienes los comentarios para compartirlo con los demás!

Actualización: y como remate a este post os dejo mi .irbrc en este pastie.

Podéis leer la oferta entera en nuestra página de empleo.

Sin embargo hoy me ha sorprendido encontrar esto:

Interesante forma de integrar servicios, sobre todo el de mapas.

Así que tras el clásico rails vaporware_project hago lo siguiente:

Instalar el plugin annotate_models

Se trata de un plugin que te copia un listado de atributos de la clase como comentarios en los ficheros del modelo y de las fixturas mediante un simple rake annotate_models.

El resultado es algo como esto:

# == Schema Information
# Schema version: 4
#
# Table name: sources
#
#  id          :integer(11)   not null, primary key
#  url         :string(255)   default(), not null
#  feed_type   :string(255)   default(), not null
#  title       :string(255)   default(), not null
#  description :text          
#  created_at  :datetime      not null
#  updated_at  :datetime      not null
#
class Source < ActiveRecord::Base

Más información: http://agilewebdevelopment.com/plugins/annotate_models

Instalar el plugin test_fixtures

Este plugin, desarrollado por Ernesto Jiménez, añade dinámicamente un test de las fixturas de cada uno de los modelos.

Más información: http://www.lacoctelera.com/ernesto-jimenez/post/2007/04/19/plugins-mi-propia-cosecha

Instalar el plugin memory_test_fix

Se trata de un plugin que permite que los tests se ejecuten contra una base de datos cargada en memoria, lo cuál hace que vayan infinitamente más rápidos, algo muy recomendable si su número crece y crece.

Más información: http://agilewebdevelopment.com/plugins/memory_test_fix

Tanto este plugin como el anterior son ideales si vas a empezar un proyecto siguiendo la metodología TDD

Limpiar los ficheros database.yml y environment.rb

Esto es más una manía que otra cosa, pero ambos ficheros vienen llenos de comentarios (muy instructivos y útiles, la verdad), pero que hace que ocupen infinitamente más de lo que deberían de ocupar.

Por ejemplo, mi database.yml es así:

development:
  adapter: mysql
  database: vapor_development
  username: user
  password: pass
  host: localhost
test:
  adapter: sqlite3
  database: ":memory:"

Y mi environment.rb es así:

RAILS_GEM_VERSION = '1.2.3' unless defined? RAILS_GEM_VERSION
require File.join(File.dirname(__FILE__), 'boot')
Rails::Initializer.run do |config|
end

Utilizar los generadores de Rails

Los generadores de Rails son realmente útiles para crear las plantillas de los ficheros que vamos a utilizar: son mucho más limpios que el scaffold porque crean los ficheros vacíos, pero ya crean fixturas, controladores, tests, etcétera.

Especialmente recomendable el nuevo script/generate resource item, que nos creará nuestro modelo y nuestro controlador como un recursos, creando también las rutas asociadas.

Copio el script rsql en mi carpeta de scripts

El script rsql nos lo enseñó Juan Lupión, y si le dieran un céntimo por cada vez que lo utilizamos ya sería rico.

Se trata de un script de consola que toma como argumento el entorno (cogiendo por defecto development si no indicamos nada) y abre un cliente de SQL con los datos que lee del fichero config/database.yml, con lo cuál en lugar de un mysql -u user -p password -h host databasename, basta con hacer un script/rsql production para entrar en la base de datos de producción, por ejemplo.

El script no sé de donde es ni que licencia tiene, pero podéis descargar de aquí una versión mejorada por el mismo Juan.

The end

Y eso es todo, hay cosas más personales y hay cosas que son un must do, pero seguro que os resultan útiles.

¿Y tú tienes algún consejo?

Si le echáis un vistazo por encima, así a bote pronto destacar la variedad: 2 presentaciones sobre testing, otro para sobre ActiionView, una de Joyent sobre el escalado de aplicaciones web (a la que le he echado un ojo y venía a echar un cable a los chicos de Twitter), REST, routing, y mucho más.

La verdad es que parecen bastante interesantes.

Y como anécdota, una pequeña broma sobre la presentación de David, un bingo con las buzzwords de su keynote:

A destacar bastards de entre todas ellas.

15 Must know Firefox shortcuts

En el siguiente gráfico, extraído del Agile Web Development ed. 2, se puede ver la jerarquía de callbacks y el orden en el que se ejecutan:

Su uso es muy recomendable si queremos escribir un código limpio en los modelos de nuestra aplicación.

Sin embargo, hace unas semanas nos ha surgido la necesidad de ir un poco más allá en los callbacks. Os cuento la situación:

Imaginad un modelo Post y un modelo Blog. En el modelo Blog, tengo un atributo que me dice cuántos posts publicados tiene ese blog (un atributo desnormalizado). Pues bien, con un sencillo after_save en el modelo Post puedo conseguir mantener actualizado dicho campo sin mucho esfuerzo:

class Post < ActiveRecord::Base
  ...
  def after_save
    blog.posts_count = Post.count(:conditions => ["blog_id = ? and status = ?", id, STATUS_PUBLISH])
    blog.save
  end
  ...
end

Este callback se ejecutará, efectivamente, cada vez que publique un post. Sin embargo, también lo hará cada vez que modifique un post que ya existe, para editar el contenido del mismo, o su título, atributos que no están relacionados con el blog al que pertenece el post.

Es decir, en realidad yo sólo quiero que se ejecute mi método after_save en un caso concreto: cuando se publica un post. O mejor dicho: cuando un post cambia de estado. El estado, o status, de un post simplemente indica si es un borrador o está publicado: si está en borrador, no aparece en los listados públicos y si está publicado sí. Por eso, el contador de posts del blog sólo se refiere a posts publicados.

Resumiendo: sólo quiero actualizar el blog asociado a un post cuando cambie el atributo status del mismo.

Y esto, amigos míos, ActiveRecord no lo permite, o por lo menos no de forma nativa. Pero con un poco de imaginación se puede llegar a saber dentro de un callback qué atributos se han modificado en el objeto.

Para ello, utilizaremos una variable de instancia (un atributo, vaya) al que llamaremos before_update_attributes y que va a hacer referencia a los atributos del objeto antes de la actualización. Lo declararemos y lo utilizaremos así:

  attr_reader :before_update_attributes
  ...
  def before_validation
    ...
    @before_update_attributes = Post.find(id).attributes if id
  end

Es decir, en el callback before_validation, el primer callback de los que se ejecutan al modificar un objeto, vamos a guardar los valores de los atributos del objeto en nuestra variable para, posteriormente cuando nos haga falta, comparar los valores actuales con los que había previamente, antes de modificarlo.

Así, nuestro after_save podría quedar así:

  def after_save
    # comprobamos que exista el before_update_attributes y que contenga el status
    return if before_update_attributes and not attributes.diff(before_update_attributes).keys.include?("status")
    # si no existe es que el objeto es nuevo
    # si no contiene el status, es que este atributo no se ha modificado
    blog.posts_count = Post.count(:conditions => ["blog_id = ? and status = ?", id, STATUS_PUBLISH])
    blog.save
  end

Y con este código, realizar los tests es realmente sencillo y no requiere realizar ninguna comprobación extraña, simplemente actualizar o no el status y verificar que se actualiza o no el atributo posts_count del blog.

Reconozco que no es la forma más elegante y que se podría mejorar e incluso generalizar de alguna manera (¿alguien se anima a hacer un plugin?), pero como primera aproximación parida en el tren camino a Valencia no está mal.

Así que animáos a opinar y, sobretodo, me interesa saber si conocéis alguna manera de abordar este problema de otra forma diferente.