Hace días que no escribo sobre mi proyecto del Google Summer of Code, y eso que ya había puesto disponibles un par de releases del Include Plugin de Grails. Sólo lo he ido anunciando en la lista de correo de Grails para ir recibiendo feedback y mejorarlo.

En este momento, que estamos ya en fase de evaluación y en teoría lo que hagamos los participantes del GSoC ya no vale, es una versión casi definitiva, ya que al menos la forma de usarlo en principio ya no va a cambiar.

En las versiones 0.1 y 0.2 se utilizaban dos tags, por cierto que al taglib hubo que añadirle un namespace(inc) por distribuirlo como un plugin, inc:includeUrl y inc:includeController que en esta versión están como deprecated y no se recomienda su uso.

Ahora únicamente es necesario el tag inc:include, que de inicio era mi idea pero chocaba con otro include fantasma que hay en Grails, por estar en el mismo namespace, y al añadirle el nuevo namespace simplemente se me olvidó .

En la lista me propusieron que hiciera esa modificación, lo que significaba sacar la versión 0.3. Mientras que al anunciar en la lista la última versión, ya que me han críticado el código para que mejore el rendimiento y haberme dado gran parte de la solución, tocará sacar al menos una nueva versión con esas mejoras. Las grandezas del open source, si alguien más se anima, las críticas son bienvenidas .

Hablando ya de la instalación y su uso, es sencillísimo:

Como está en el repositorio oficial de plugins, para instalarlo sólo debemos ejecutar:

grails install-plugin include.

Para hacer includes de otras acciones podemos llamar a una accion de un controlador con unos parámetros, por ejemplo insertar las últimas 5 noticias en una vista:

<inc:include controller="news" action="last" params="[number:5]"/>

Que también podríamos hacer usando la url que devuelve esa acción, con una mayor probabilidad de un cambio en el mapeo de la url:

<inc:include url="/news/last?number=5"/>

Otra de las cosas que pienso es interesante es el poder insertar contenido estático dentro del directorio web-app, de por ejemplo un html, a los que anteriormente no había una forma directa de acceder:

<inc:include url="/test.html"/>

En definitiva, es un plugin que facilita parte del trabajo en webs tipo portal, evita la necesidad de crear taglibs para simplemente mostrar datos o de repetir código en los controllers. En fin, espero aprobar la evaluación y así llevarme la camiseta!!

Hace unos días estuve charlando con un amigo que acaba de terminar los estudios, entre otras muchas cosas, sobre auto-formarse en algo novedoso y con posibilidad de futuro. Como él ya había trabajado bastante con Java, en principio quería aprender algún framework web para la plataforma y al explicarle que estaba trabajando en un plugin de Grails para el GSoC, le picó la curiosidad y me pidió unos links.

En fin, que como la recopilación ya está hecha la publico también aquí:

• La documentación oficial: Está bien para buscar cosas concretas y además es una buena guía para empezar desde 0
• Las listas de correo: Tanto para preguntar como para leer preguntas y respuestas a otros, que de vez en cuando se descubre alguna cosa
• groovyblogs.org: Es un planet donde acaba prácticamente todo lo que se publica sobre groovy y grails
• groovy.org.es: Noticias en español, además de el foro y de los tutoriales
• Un podcast de grails
• Los QuickCasts de G2one

También de algunos proyectos open source:

• El código de groovyblogs
• Gravl, un sencillo CMS para blogs
• goCMS, que es utilizado en groovy.org.es
• Los proyectos de ejemplo oficiales, entre los que se encuentra la aplicación de grails.org

Con esto y algún pet-project, es más que suficiente para empezar a aprender a usar el framework y estar al día de las novedades que puedan ir surgiendo.

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

Depués de que hace un año Martín me adoptara como committer de jLibrary, por fin está disponible la versión 1.2 para descarga.

Como cuenta el mismo Martín en su post sobre la historia de la release, tras haber acabado el curso que impartió Al de JSF, andaba buscando algo que hacer para aplicar lo que había aprendido y seguir aprendiendo más sobre esta especificación. De inicio la idea era crar una interfaz web que tuviera una parte pública con Servlets+Freemarker (reutilizando la exportación de repositorios a HTML que ya existía) y otra de administración con JSF. Con el tiempo tiramos todo lo que estuvimos haciendo con JSF porque en muchos casos acabábamos duplicando trabajo o haciendo integraciones “extrañas” entre administración y parte pública, y nos centramos en trabajar únicamente con Servlets y Freemarker.

En fin, que hacía algunos meses que estaba casi lista esta versión, ya cuando publicamos la demo web en beta las mejoras de la parte servidor estaban casi acabadas, tan sólo hicimos algún ajuste tras esto, pero otro proyecto que no tiene nada que ver se nos cruzó en el camino y no quedaba tiempo para darle el último empujón. Por esto, gran punto para la gente de Blandware por darle ese emujón, además de que con una empresa dentro del proyecto creo que es interesante desde un punto de vista comercial.

Como curiosidad en cuanto a las mejoras en la parte servidor, estos días después de haber salido la versión y la noticia en TheServerSide y javaHispano, cada vez que he entrado a monitorizar el número de usuarios concurrentes no lo he visto debajo de los 40/50 e incluso he llegado a ver poco más de 100(según google analytics, ayer más de 1800 visitas), que para las modestas características del servidor está realmente bien.

La semana pasada estuve varios días en Valencia para asistir a la Campus Party donde, un poco por casualidad, tenía que dar una charla sobre el Google Summer of Code con gimenete(tiene otro blog en el que escribe sobre su proyecto).

En el canal oficial de Google España en youtube y en la web de la campus de google, han subido los vídeos de todas la conferencias que se hicieron en su stand, entre los que se encuentra también nuestra conferencia. Habló primero Zachary Voase(un chico inglés de sólo 15 años que vive en Andalucía) sobre Google Highly Open Participation Contest. Tras él nosotros dos sobre el GSoC y nuestros proyectos(a partir del minuto 4): La feature de ver como un grafo del histórico de versiones de un fichero para subclipse de gimenete y el plugin para añadir el comportamiento de hacer includes para Grails.

Y los slides(a partir del slide 10):

No está mal estrenarse en esto de las charlas/conferencias en un stand de Google, que no hizo más que aumentar los nervios de novato, que se notaron muchísimo

Gracias a un post de Mamen Pradel, descubro el curioso Wordle, del que ya había visto resultados pero no sabía de dónde venían (lo sé, debería haber preguntado ).

Aquí el que he hecho hace un rato:

Como curiosidad, está hecho con un applet java, y ha sido desarrollado por Jonathan Feinberg, empleado de IBM Research

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!

Desde que empezó el Google Summer of Code no he explicado exáctamente qué es y el por qué de mi proyecto, ahora que veo cerca la primera versión (a falta de un problema con las urls que mapean a vistas) ya empieza a ser hora de hacerlo.

La cuestión es que Grails no tiene el comportamiento típico de include, tiene el tag render que es parecido(para el caso de un template estático sería igual) pero se orienta al principio Don’t Repeat Yourself en la vista, por lo que al render hay que pasarle los objetos o colecciones de objetos que se utilizarán para renderizar el template.

Esto puede llevar a un problema de repetición de código en los controllers, por lo que aquí rompemos el Don’t Repeat Yourself, siendo sensibles a futuros cambios. Ésto no quiere decir que el render no valga, en mi opinión para conseguir no repetir código dependiendo de los casos, lo mejor es combinar ambos comportamientos. Aunque el problema de la repetición de código se puede solucionar con nuestras propias librerías de tags, que con Grails son sencillas de crear, pero pienso que debería ser todavía más sencillo y limpio utilizando una acción de un controller que además podríamos reutilizar para por ejemplo peticiones XMLHttpRequest.

Metiéndonos ya en el uso del plugin, existen dos formas de hacer el include, la forma clásica con el tag includeURL:

<g:includeUrl url="/prueba/show?param=value"/>


Los posibles valores de url pueden ser tanto urls que mapean a controllers/acciones/vistas de nuestra aplicación grails, como a recursos estáticos como puede ser un html plano o un fichero de texto que se encuentren en el mismo contexto. Para el caso de las urls mapeadas, los parámetros se pueden pasar por los posibles valores de la url mapeada tipo REST como con parámetros de la request de los de siempre.

Y la segunda forma es para mi es la forma recomendada para los caso de hacer un include a acciones de nuestros controllers, includeController:

<g:includeController controller="prueba" action="show" params="[param:'value']"/>


Al que se le pasa el nombre del controller, acción y mapa de parámetros. Hay que decir que por la convención de nombres, en el caso de prueba buscará en controlador PruebaController. La recomendación es simplemente por la probabilidad mucho mayor de una cambio de mapeo de url que del nombre de un controller, cada uno verá de qué manera prefiere hacerlo .

Hablando ya sobre la experiencia desarrollando éste plugin, la verdad que me esperaba que fuera más sencillo de desarrollar, estaba claro que sería necesario un wrapper del response para hacer el include con el RequestDispatcher. Al final he tenido que escribir también un wrapper para el request y re-escribir parte del filtrado del mapeo de urls de grails, al ser la misma petición y no estar contemplado este comportamiento anteriormente, ha habido que hacer un poco de trabajo extra investigando el código del framework en cuanto a mapeo de urls y hacer mucho debug por no conocer el código (gracias IDEA + JetGroovy! ).

A ver si dejo una versión estable de éste plugin en las próximas semanas, y comienzo a colaborar con el plugin de Java Content Repository para poder trabajar con ésta especificación de una forma más o menos parecida a como se usa GORM con Hibernate por debajo.