CruiseControl

CruiseControl es una herramienta de integración continua escrita en, y para, ruby. Su finalidad básica es la de alertar a los miembros de un proyecto software cuando un cambio en el repositorio de control del código fuente (como svn) rompe dicho proyecto. En el caso de RoR, lo que hará periódicamente será la ejecución de los test de la aplicación, informando del resultado.

Es muy fácil de usar. Basta con descargarlo (es un mini-proyecto RoR), añadirle nuestro proyecto (indicando el repositorio del código fuente), y arrancarlo. Por defecto arranca en el puerto 3333, y si accedemos nos encontraremos algo como esto. Además, podemos integrar rcov en cruisecontrol y obtener información del code coverage de nuestro proyecto.

Usando rcov desde cuisecontrol

Para que CruiseControl nos facilite información sobre el Code Coverage, necesitamos:

1. Gema rcov ('sudo gem install rcov'). Comprobamos ejecutando 'rcov' en el terminal.
2. Plugin rails_rcov ( './script/plugin install http://svn.codahale.com/rails_rcov' --> Doc: http://agilewebdevelopment.com/plugins/rails_rcov)
3. Añadir en lib/tasks/ el fichero cruise.rake con el siguiente contenido:

# Set the artifacts dir for development
ENV['CC_BUILD_ARTIFACTS'] ||= File.expand_path("#{RAILS_ROOT}/metrics")
ENV['RAILS_ENV'] = 'test'

# This hack is needed because db:test:purge implementation for MySQL drops the test database, invalidating
# the existing connection. A solution is to reconnect again.
def reconnect
require 'active_record' unless defined? ActiveRecord
configurations = ActiveRecord::Base.configurations
if configurations and configurations.has_key?("test") and configurations["test"]["adapter"] == 'mysql'
ActiveRecord::Base.establish_connection(:test)
end
end

desc 'Continuous build target'
task :cruise do
# Add local user gem path, in case rcov was installed with non-root access
#ENV['PATH'] = "#{ENV['PATH']}:#{File.join(Gem.user_dir, 'bin')}"

puts
puts "[CruiseControl] Build environment:"
puts "[CruiseControl] #{`cat /etc/issue`}"
puts "[CruiseControl] #{`uname -a`}"
puts "[CruiseControl] #{`ruby -v`}"
`gem env`.each_line {|line| print "[CruiseControl] #{line}"}
puts "[CruiseControl] Local gems:"
`gem list`.each_line {|line| print "[CruiseControl] #{line}"}
puts

out = ENV['CC_BUILD_ARTIFACTS']
mkdir_p out unless File.directory? out if out

if File.exists?(Dir.pwd + "/config/database.yml")
if Dir[Dir.pwd + "/db/migrate/*.rb"].empty?
raise "No migration scripts found in db/migrate/ but database.yml exists, " +
"CruiseControl won't be able to build the latest test database. Build aborted."
end

# perform standard Rails database cleanup/preparation tasks if they are defined in project
# this is necessary because there is no up-to-date development database on a continuous integration box
if Rake.application.lookup('db:test:purge')
Rake::Task['db:test:purge'].invoke
end
if Rake.application.lookup('db:migrate')
reconnect
Rake::Task['db:migrate'].invoke
end
end

if RUBY_VERSION == '1.8.7'
puts '!!!!!! Skipping rcov on Ruby 1.8.7'
Rake::Task["test:units"].invoke
Rake::Task["test:functionals"].invoke
else
ENV['SHOW_ONLY'] = 'models,lib,helpers'
Rake::Task["test:units:rcov"].invoke
mv 'coverage/units', "#{out}/unit test coverage" if out

ENV['SHOW_ONLY'] = 'controllers'
Rake::Task["test:functionals:rcov"].invoke
mv 'coverage/functionals', "#{out}/functional test coverage" if out
end
end

Para probar que funciona correctamente y que cruise-control no va a fallar, podemos probar a ejecutar:
rake cruise

Google libera Closure, la librería JavaScript detrás de Gmail y Gmaps

Me hago eco de la siguiente noticia, leída en javahispano.org:

Google ha liberado una librería y un conjunto de herramientas para trabajar con JavaScript: Closure. Closure es empleada por aplicaciones como Gmail y Gmaps. Está formado por un optimizador que permite comprimir el código JavaScript, y a la vez realiza un análisis sintáctico del código para encontrar errores comunes.

Por otro lado está una librería con utilidades para manipular el DOM, comunicarse con el servidor, crear animaciones, soporte para edición de texto... La librería es completamente "multi navegador", su diseño es modular y (obviamente, dada las aplicaciones en las que ha sido empleada) está muy bien testada.

Por último, tenemos un sistema de plantillas tanto para Java como para JavaScript cuyo propósito es simplificar la tarea de generar dinámicamente HTML. Las plantillas están implementadas tanto en Java como en JavaScript, lo que permite emplearlas tanto el servidor como en el cliente.

Testing con "redirect_to :back"

Si necesitas testear un controlador rails que contiene un "redirect_to :back" obtendrás un error al lanzar el test. Si vamos a la implementación, podemos encontrar:

• :back - Back to the page that issued the request. Useful for forms that are triggered from multiple places. Short-hand for redirect_to(request.env["HTTP_REFERER"])

Si estamos testeando no tendremos un request, por lo que fallará la redirección y por lo tanto el test.

SOLUCIÓN:

def test_should_get_new
   @request.env['HTTP_REFERER'] = 'http://whatever'
   get :new, :link_id => 1
   assert_redirected_to 'http://whatever'
end

¿Qué licencia Open Source elijo?

Me llega la hora (por fin :) ) de la entrega de mi proyecto fin de carrera. Lo he llamado GASWED, o Gestor de Actualizaciones Software Web en Entornos Distribuidos. Básicamente consiste en un gestor que, ayudándose de svn (subversion), controla revisión de los distintos ficheros de un proyecto software web en distintos servidores y, además, está orientado a paquetes. Es decir, no trabajamos con ficheros individuales como con svn, sino con paquetes de éstos tales que agrupen alguna funcionalidad (tablón, foros...). Además, cada paquete puede ser importado en distintos servidores o eliminado, llevando asociadas sentencias sql que serán ejecutadas en las bases de datos de cada uno de estos servidores. Sí, prometo una explicación más detallada cuando lo finalize y entregue ;) .

Si tú tambien eres programador y estás desarrollando una aplicación a la que le quieres aplicar una licencia Open Source, seguramente te hayas dado cuenta de que hay muchas opciones. ¿Cuál es la mejor elección a la hora de trabajar con Open Source? Es en lo que trata de ayudarnos un completo artículo en el que un desarrollador ha analizado cada una de las licencias Open Source que existen actualmente.

Shlomi Fish, un joven desarrollador especializado en desarrollos Open Source, ha elaborado un interesante artículo en el cual compara las distintas alternativas que los programadores de Software Libre y Open Source (Free and Open Source Software, FOSS) tienen cuando están trabajando en un nuevo proyecto.

Lo cierto es que este tipo de decisión cada vez es más compleja debido al creciente número de licencias que han ido apareciendo con el paso del tiempo. Aunque la GPL es la más conocida y extendida -sobre todo en su versión 2- en los últimos años distintas organizaciones han propuesto otro tipo de licencias que ofrecían ciertas ventajas con respecto a otras alternativas, de modo que básicamente cada programador disponía de una licencia que más o menos se ajustaba a sus necesidades.

Fish elabora un completo análisis dividiendo el actual segmento de las licencias FOSS en tres grandes grupos:

1. Licencias de Dominio Público: permiten hacer prácticamente cualquier cosa que te convenga con el software y su código fuente. Ejemplos de estas licencias: licencias BSD, MIT X11, Apache e ISC.
2. Licencias Copyleft "débiles": este tipo de licencias obligan que el código fuente derivado de estos desarrollos siga usando la misma licencia, aunque uno puede enlazar esa licencia débil e integrarla en un desarrollo global con otra licencia -incuyendo licencias que no son Open Source. Ejemplos: LGPL, Artistic Licence, o la MPL.
3. Licencias Copyleft "fuertes": parecidas a las anteriores, pero que obligan a que incluso desarrollos que incluyan a código fuente con esa licencia tengan que usar esas licencias, y no otras. Ejemplos: la famosa GPL (tanto en su versión 2 como en su versión 3), o la Sleepycat License.

A partir de ahí Fish realiza una serie de recomendaciones en las que por ejemplo indica que es mejor utilizar licencias compatibles con la GPL, pero que no es buena idea usar las licencias GPL o LGPL porque contienen demasiadas restricciones adicionales al concepto de copyleft. Según su opinión, la licencia MIT X11 es "corta, simple y fácil de comprender", y además es compatible con la GPL.

Personalmente, creo que me voy a decidir por una licencia GPL en su versión 3. Como gustos, colores.

EDITED:
Por fin está el proyecto acabado y entregado. Finalmente me decidí por AGPL v3.

¿Es seguro el DNI electrónico?

ElDNI electrónico es el nuevo carnet de identidad de los españoles. Una de las grandes novedades es la incorporación de un chip que permite realizar operaciones de firma electrónica e identificar a los ciudadanos a través de Internet. El DNI-e sitúa a España en la vanguardia mundial en cuanto a firma digital y permitirá agilizar enormemente muchos de los trámites administrativos que hasta hace bien poco solo podían ser realizados en persona o bien requerían de engorrosos trámites técnico-burocráticos -obtención de un certificado, etc-.

Pero... ¿Son totalmente seguras todas estas operaciones? ¿Están nuestros datos personales totalmente seguros? Un estudio llevado a cabo por PenTest nos demuestra que tenemos que andarnos con mucho ojo. Podemos ver este estudio aquí. No tiene desperdicio.

Empezando con Rails

Bueno, pues ya llevo tres días en el trabajo :) . La verdad es que se está muy agusto, hay un muy buen ambiente de trabajo. Estos tres días los he dedicado a entender la forma de programar que usa rails. Es un poco complejo al principio, pero una vez que empiezas a escribir algo de código esa complejidad se convierte en satisfacción.

Hasta ahora, estaba acostumbrado a programar aplicaciones web con PHP. Con Rails, se tiene una forma de desarrollar aplicaciones con una complejidad alta, seguridad alta, etc. y en no mucho tiempo (seguro menos que con PHP). Con PHP todo está a un nivel de abstracción más bajo. Quizá PHP me ha venido muy bien para aprender sobre el desarrollo web. Con Rails te tienes que subir un nivel más arriba y dar por hecho muchas cosas que Rails se encarga de hacer automáticamente, una vez tienes definido el modelo y controlador correctamente. Aparte de todo esto, Rails usa MVC (Modelo-Vista-Controlador) por lo que a pesar de ser aplicaciones mucho más complejas, son también más claras de leer y más fáciles de mantener. Por ahora, ¡con Rails todo son ventajas!

Cuando ya empieze de verdad con aplicaciones complejas, seguro que me van surgiendo muchas curiosidades para postear por aquí. Hasta entonces, o hasta que tenga otro motivo por el que escribir, bye bye.

Vuelta al blog

Tras algunos meses de parada, vuelvo de nuevo a escribir en mi blog. Estoy a punto de teminar la carrera de ingeniería informática en la Universidad de Granada. Acabo de encontrar un trabajo. Y ahora que espero tener algo más de tiempo para mí (la carrera es terrible, cuando no hay que estudiar un parcial, tienes que entregar prácticas, y cuando no...exámenes finales! Y cuando parece que tienes un respiro...septiembre!!). Espero no tragarme mis propias palabras, pues dicen que estudiar es mucho mejor que trabajar (lo dice quien trabaja...) pero yo creo que estudiamos para poder trabajar de lo que nos gusta, y bueno, no creo que sea tan terrible.

Voy a entrar a trabajar en una empresa dedicada al desarrollo de software. El 95% del trabajo de la misma es desarrollo de aplicaciones web, usando rails. La verdad que de ruby tengo poca idea... Pero bueno, ahora entraré para aprender el lenguaje y el framework a fondo. Rails es un framework para el desarrollo de aplicaciones web con bases de datos de acuerdo con la estructura modelo-vista-controlador. Supongo que se usará ajax en la vista...bueno, no adelanto acontecimientos que aún me queda mucho que aprender.

Aquí en el blog iré poniendo curiosidades, problemas que me surjan y resuelva, etc. sobre rails. Me parece una buena forma de compartir con vosotros algunos conocimientos que os pueden venir de perlas (si usáis rails...).

¡Espero que os guste e interese todo lo que vaya poniendo por aquí!

Comparativa de uso de memoria entre navegadores

El navegador Firefox de Mozilla Foundation siempre ha sido muy criticado por su enorme consumo de memoria, un problema que parece haber sido resuelto en las vesiones preliminares de Firefox 3.5, que sorprenden por su eficiencia. Me hago eco de una comparativa que analiza este apartado y enfrenta a Firefox 3.5 RC, Google Chrome 3.0 Dev, Safari 4.0 y Opera 10b. Pese a lo que tenía entendido sobre Chrome, parece ser que es el que sale peor parado al menos con respecto a su consumo de memoria.

¿Mejorarán posteriores versiones al igual que lo han hecho para Firefox? Seguro que sí.