El viernes escribí en el blog de flatee un post sobre testing funcional con RoR:

Actualmente nos encontramos en un punto en el que todavía no tenemos una primera maquetación de la interfaz de usuario de flatee, pero de todas formas estamos desarrollando.

¿Cómo lo hacemos?. Bien, estamos desarrollando con la ayuda de test funcionales para comprobar que todo lo que hacemos está correcto. Además estos tests nos servirán para comprobar que no se rompe nada con futuras modificaciones, y si se rompe ver que es lo que hemos tocado más de la cuenta.

Más en tests funcionales con Ruby on Rails.

En el momento empecé a trabajar con Ruby on Rails, elegí la opción de instalar uno de esos paquetes precocinados para instalar y listo, en este caso, sin duda, InstantRails. Como ya trae instalado PHP, desinstalé XAMPP por no andar matando procesos, además de que para qué quiero dos de estos paquetes casi equivalentes.

El problema es que instantrails viene con PHP4 y no con PHP5, como iba a estar un tiempo sin trabajar con PHP lo dejé así(aparte de un micro-proyecto que puede correr perfectamente con PHP4), hasta que un amigo me pasó un pequeño desarrollo usando el soporte OO de PHP5 para que le pegara una ojeada a un par de cositas, lo que me ha obligado a andar cambiando configuraciones.

En fin, los pasos para actualizar son estos:

• Para empezar debemos descargar el .zip de la última versión de php.
• Renombrar la carpeta de instantrails php a php4, por si acaso.
• Extraer el contenido del .zip a una carpeta php dentro de instantrails.
• En conf_files/httpd.conf, modificar LoadModule php4_module “${path}/php/php4apache.dll” por LoadModule php5_module “${path}/php/php5apache.dll” y AddModule mod_php4.c por AddModule mod_php5.c.
• En conf_files/php.ini, modificar extension_dir = “${path}\php\extensions\” a extension_dir = “${path}\php\ext\”
• Por último reiniciar apache

Y ya hemos actualizado a PHP5

Ayer estuve leyendo los posts de Matt Raible sobre la OSCON 2008, recomiendo darles una ojeada a todos.

También ha publicado su propia charla en el evento, sobre frameworks de futuro:

Bajo mi punto de vista, osea en España donde en una inmensa mayoría de empresas aún no se plantea dejar el incombustible Struts 1, pienso que sobre Rails y Flex se puede decir que ya están aquí, ya que tienen cierta cuota de mercado; mientras que de GWT y Grails conozco muy pocos casos donde se esté(estemos) utilizando.

Me gustaría conocer de los que os pasáis por aquí, además de qué framework/s web estáis usando, cuáles son los que llaman vuestra atención. Personalmente me interesa seguir aprendiendo más sobre Grails y Rails, pero además también me llaman la atención GAE, CodeIgniter y Wicket para los que espero sacar tiempo, algún día .

Ayer lunes se hicimos el anuncio oficial del inicio del desarrollo de flatee (la mejor manera de compartir piso ), que vamos a desarrollar entre Jesús Navarrete y un servidor.

El proyecto surge dentro del internship que estamos haciendo en Linking Paths y a raíz de una necesidad personal, los actuales portales de clasificados no cubren mis necesidades como deberían y por lo que he hablado con más gente, no soy el único.

Estoy convencido que será una experiencia muy enriquecedora, no va a ser desarrollar algo y ya está, tendremos que cubrir todos los aspectos para que resulte un proyecto exitoso, tanto técnicos como no técnicos.

Por lo que si te interesa el proyecto en sí, crees que pueden existir mejores formas que ayuden elegir con quién y dónde vas a convivir o simplemente tienes curiosidad por saber como evoluciona el proyecto, no dejes de seguir el blog de flatee donde compartiremos nuestras experiencias, ideas… ¡esperamos tus opiniones!

Ya comenté que, al empezar a trabajar con Linking Paths, empezaría a utilizar Ruby on Rails y que pretendía hacer un cara a cara entre Ruby on Rails y Grails. Como podría ser un post muy largo y tampoco quiero ir dejándome cosas, la intención es hacerlo en una serie de posts tal y como vaya teniendo las ideas claras, espero tener tiempo y ganas para ir completándola . El objetivo no es decir cuál es mejor, sino simplemente que se vean las características de cada uno. En este post se van a tratar características generales y algunos parecidos razonables entre los frameworks.

A primera vista:

Como mucha gente sabrá los dos son frameworks web full-stack que siguen el patrón MVC, siguen el principio DRY(Don’t repeat yourself) y CoC(Convention over configuration). Lo primero que hay que decir es que Grails se basó en las ideas de RoR, incluso a Grails en un principio se le llamó Groovy on Rails pero los creadores de RoR pidieron que se le cambiara el nombre.

RoR está enteramente construido con Ruby. Mientras que Grails lo está con la combinación Java+Groovy usando frameworks y librerías muy conocidas por debajo(destacan Spring, Hibernate y Sitemesh).

Para empezar hay que destacar que, ambos frameworks, nos traen de serie un servidor/contenedor web y un servidor de bases de datos embebidos: RoR trae WEBrick y SQLite mientras que Grails Jetty y HSQLDB. De esta forma podemos trabajar en desarrollo sin preocuparnos de tener acceso o tener que instalar nada más.

Para la automatización de tareas repetitivas con RoR se usa Rake y con Grails Gant(basado en Apache Ant).

Como librería javascript, por defecto, las dos traen Prototype.

Manos a la obra:

Donde más parecido he encontrado ha sido en la capa más web. Con los dos se usan layouts para la decoración base de la página, para las vistas Grails usa GSP y RoR ERB, mientras que lo que en un sitio se llaman Taglibs en otro son Helpers. Existen diferencias de sintaxis y de cómo se hacen las cosas, pero las capacidades son muy parecidas.

Para el acceso a datos, en los dos se utiliza el patrón ActiveRecord a través de ORM’s, RoR utiliza uno del mismo nombre que el patrón y Grails GORM(basado en Hibernate y vitaminado con el dinamismo de Groovy). De inicio puede dar la impresión de que son casi equivalentes, pero este tema creo que tiene miga para tratarlo en otro capítulo.

Herramientas/IDE’s:

En este apartado, gana RoR sin discusión con el plugin de NetBeans o RadRails que tienen un soporte realmente bueno. Mientras que para Grails Jet Groovy de IDEA es el único con un soporte decente, el plugin de Eclipse todavía está lejos de ser bueno, y el de NetBeans está en desarrollo.

Aparte de esto, hay muchos editores que soportan sintaxis ruby, mientras que soporte a groovy todavía es muy difícil encontrar

Algunas conclusiones:

A nivel de madurez, se le nota mucho más maduro a RoR. Empiezan a verse bastantes aplicaciones en producción, tiene más documentación, más plugins y una comunidad mayor. Aunque hay algo donde creo que destaca Grails, es en cómo está organizada la documentación de referencia, tanto para empezar de cero como para buscar algo en concreto.

Para un programador acostumbrado a Java, la curva de aprendizaje de Grails es más baja, puedes empezar a trabajar de una forma más javera e ir introduciendo/aprendiendo la forma más ¿grooviera?, además de poder utilizar cualquier librería java.

Cuando hablé de mi independencia, ya comenté que había algo más pero que otros tenían que ser quienes lo anunciaran y ya lo hizo Aitor, estuve unos días en Madrid para acelerar mi puesta a punto y empezar a trabajar con Linking Paths durante unos meses, en lo que han bautizado como Linking Internship 2008.

En estos días con Alberto, he empezado a aprender Ruby on Rails(tarde o temprano seguro que habrá una comparativa cara a cara con Grails ) y a ver Tog.

Pero sobre todo he comprobado lo que sospechaba, que es una empresa que se sale de lo habitual, con una especie de caos controlado, con personas muy interesantes e ideas muy interesantes.