CruiseControl.rb via twitter

Bueno, como me hizo gracia el comentario de Blat sobre publicar un plugin por semana aquí viene el de esta. Esta vez no es para RoR exactamente, sino para una aplicación hecha en RoR: CruiseControl.rb :)

El plugin este ya lo tenía hecho, pero como estoy de exámenes mejor recuperar algo ya hecho y hacer un post rápido que no postear ^_^

¿Qué es eso de CruiseControl.rb?

Traduciendo directamente de su página:

CruiseContro.rb es una herramienta de integración continua. Su básico propósito en la vida es alertar a los miembros de un proyecto de software cuando uno de ellos añade algo al sistema de control de versiones que rompe el build.

CC.rb es fácil de instalar, agradable de usar y simple de hackear. Está esrita en Ruby.

Básicamente, lo que hace es monitorizar subversion y cuando hay una nueva versión le pasa los test y alerta a los desarrolladores si los tests no pasan correctamente. Yo diría que es una herramienta obligatoria para cualquier proyecto en Rails (cocteleros de la ruby room, si no lo tenéis, ya estáis tardando ^_^)

twitter_notifier.rb

Por defecto CC.rb ya lleva (entre otros) plugins de notificación via: mail, jabber y Growl.

Yo hice uno para notificar via twitter cuando el build se rompe o arregla. Lo podéis encontrar en el bug tracker del proyecto ya que está pendiente de ver si lo incorporan de serie como plugin disponible.

Podéis encontrar otra versión posterior que notifica de todas las nuevas versiones en mi subversion. Con esto os enteraréis de todos los commits que se hagan y de si los tests pasan correctamente.

Instalación y configuración

Para instalarlo no tenéis más que copiar el plugin en la carpeta builder_plugins/installed/ de vuestra instalación de CC.rb

La configuración es algo tan sencillo como esto:

Project.configure do |project|
   ...
   project.twitter_notifier.email = 'your_email@twitter.com'
   project.twitter_notifier.password = 'twitter_password'
   ...
 end

servido por Ernesto 2 comentarios compártelo favorito

Plugins de mi propia cosecha

Para demostrar que sigo vivo, aquí va la presentación de dos plugins para Rails míos :)

Testea siempre tus fixtures

test_fixtures no es más que un plugin sacado a partir del post "Fernando Blat lo decía: TESTEA TUS FIXTURES! (y se DRY)". Instala el plugin, añade una línea a tu test/test_helpers.rb, y ya lo tendrás todo hecho

Ya no tienes excusa para no testear tus fixtures

Para usarlo son sólo dos pasos:

1. Instala el plugin:
   script/plugin install http://i.justcodeit.net/plugins/test_fixtures/

2. Ponlo en marcha editando el archivo test/test_helpers.rb

   class Test::Unit::TestCase
      include TestFixtures
      # The rest of your helpers
    end
    

Evita javascript chungo en tu base de datos

¿Controlas lo que los usuarios meten en tu base de datos? ¿Te aseguras de quitar javascript del contenido que envían? No son cosas que se hayan de descuidar ya que si no lo haces puedes comprometer la privacidad e incluso la seguridad de tus otros usuarios y tu web.

Siguiendo con mi obsesión por ser DRY y basándome en la idea del plugin acts_naked he creado acts_without_scripts. Este plugin te permite filtrar con el helper sanitize el texto que va a tu base de datos automáticamente. Por defecto filtrará todos los campos de texto del modelo que declaremos acts_without_scripts, pero dispone de opciones para especificar qué campos en concreto queremos filtrar y el callback que queremos emplear para filtrarlos.

Ya puedes asegurar un poco más tu aplicación!

Para usarlo son otros dos pasos:

1. Instala el plugin:
   script/plugin install http://i.justcodeit.net/plugins/acts_without_scripts/

2. Añade en los modelos que quieras el acts_without_scripts

   class Post < ActiveRecord::Base
      validates_presence_of :title
      acts_without_scripts
    end
    

Critícame o felicítame

Para esto te basta con dejarme un comentario o enviarme un mail ;)

Espero que algo de esto le sea útil a alguien ^_^

servido por Ernesto 2 comentarios compártelo favorito

Fernando Blat lo decía: TESTEA TUS FIXTURES! (y se DRY)

Fernando Blat (al que no tengo el placer de conocer :) lo decía: hay que testear las fixtures. Al ponerme con el TDD y encontrarme con algunas fixtures inválidas me acordé de su consejo.

Una vez tenía mi test_your_fixtures en el modelo que tenía fixtures inválidas me dije:

1. Fernando lo comenta como algo obligatorio
2. Yo estoy de acuerdo
3. Estar definiendo este método en todas las clases de tests unitarios no es DRY

Así que he aquí mi propuesta para testear tus fixtures de forma DRY y bastante transparente:

 $ cat test/test_your_fixtures.rb
 module TestYourFixtures
   def test_fixtures
     begin
       mod = Object.const_get(self.class.to_s.sub(/Test$/,''))
       if mod.public_methods.include? 'find'
         mod.find(:all).each do |fixture|
           assert fixture.valid?, "Invalid fixture #{mod}: #{fixture.to_param}\n#{fixture.to_yaml}"
         end
       end
     rescue NameError
     end
   end
 end
 Test::Unit::TestCase.send :include, TestYourFixtures
 

 $ cat test/test_helper.rb | grep your_fixtures
 require File.dirname(__FILE__) + '/test_your_fixtures'
 

Si seguimos la convención de nombres de rails, las clases de tests unitarios de nuestros modelos tendrán un nombre tal que ModeloTest. Si en cada una de estas clases hemos cargado las fixtures de ese modelo:

 class UserTest < AbstractModelTestCase
   fixtures :users
 [...]
 end
 

Al ejecutar los tests de UserTest se ejecutará también el test heredado text_fixtures, que cargará la clase del modelo User, comprobará que tiene un método find (para asegurarnos de que es una clase de modelo), y comprobará que todas las fixtures son válidas.

Para mi gusto esto es más DRY y transparente. No obstante, se admiten sugerencias :)

servido por Ernesto 2 comentarios compártelo favorito