La Coctelera

in web we trust Fernando Blat's blog, freelance web developer

Categoría: Snippets y Trucos

16 Enero 2008

Escrito el: 16 ene 2008 @ 12:02 AM

Categorías: Snippets y Trucos

Tags: unvlog, nginx

Comentarios:
1 comentario

compártelo

Sirviendo feeds cacheados con Nginx directamente

Reconozco que me ha constado dios y ayuda dar con la regla adecuada, así que por eso me he decidido a postearla.

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.

12 Agosto 2007

Testeando helpers

El otro día, buscando información sobre cómo testear helpers en Rails di con este post: Test your helpers, en el que el autor habla de un plugin desarrollado por él mismo que facilita sobremanera la labor.

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?

30 Julio 2007

Y antes fue la línea de comandos...

La línea de comandos (¿esa gran desconocida?), es una de las mejores herramientas que tenemos a mano los que desarrollamos en entorno UNIX/Linux. Por eso, posts como este, inspiran.

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.

9 Junio 2007

Cosas que hago al empezar un nuevo proyecto en Rails

A lo largo de todo este tiempo que llevo como desarrollador de Rails he cogido una serie de manías y hábitos, a la vez que he descubierto una serie de herramientas y plugins que me han parecido imprescindibles, y que incluso podrían venir incorporadas de serie en Rails.

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?

19 Mayo 2007

15 atajos de teclados para Firefox en Mac OS X

No los voy a traducir porque soy un vago, pero no dejéis de echárles un vistazo, que seguro que descubrís alguno nuevo:

15 Must know Firefox shortcuts

6 Abril 2007

Tests de unidad: testeando relaciones entre modelos

Los tests de unidad son tests sobre el modelo de datos, tanto atributos, como métodos del modelo, como relaciones (que al final todo son métodos, pero bueno).

Si lo que queremos testear es una relación con otro modelo, podemos utilizar combinaciones de asserts.

Si nuestros modelos son:


 class Foo < ActiveRecord::Base
   belongs_to :bar
 end

 class Bar < ActiveRecord::Base
   has_many :foos
 end
 

El test de unidad de Bar podría contener este test sobre la relación:


 def test_foos
   bar = Bar.find(1)
   # testeamos que responde al método :foos
   assert_respond_to bar, :foos
   # testeamos que :foos devuelve un Array
   assert bar.foos.is_a? Array
   # testeamos que :foos es un Array de Foo
   assert !bar.foos.empty?
   assert bar.foos.first.is_a? Foo
 end
 

Es sólo una propuesta, y es artesanal 100%, pues ya se sabe que para esto de los tests no hay reglas fijas, sino experiencias personales sobre qué resulta más efectivo.

Así que se proponen sugerencias.

6 Abril 2007

Testea tus tests

Testear tus tests, vaya redundancia, ¿no? ¡Pues no! Veamos en un ejemplo a qué me refiero:


 def test_foo
   ...
   foo = Foo.find_by_nicename('foo_bar')
   assert_not_nil foo
   # utiliza foo tranquilamente
   ...
 end
 

O también:


 def test_foos
   ...
   foos = Foo.find_all_by_parent_id(1)
   assert !foos.empty?
   # utiliza foos tranquilamente
   ...
 end
 

Y es que vais a evitar más de un disgusto comprobando que son válidos los datos que vais a utilizar en el test, un poco en la misma línea de testear tus fixtures.

18 Marzo 2007

Un bundle de TextMate para escribir fixtures de Rails

Lo acabo de postear en la lista de TextMate en español, fundada por el doctor naranja, pero también quiero comentarlo aquí: en este post cuentan cómo escribir un bundle de Textmate para crear fixtures en Rails, muy bien hecho, que te mapea los atributos de la base de datos y te los escribe, para que saltes a través de ellos con la tecla tab.

Mágico.