Mashup: Buscador de restaurantes con 11870 y Tropo en menos de 100 líneas

Como ya os anuncié hace unos días, soy miembro del equipo de Tropo. Aunque mi foco es la siguiente generación del producto, lo cierto es que de vez en cuando me gusta ir probando cosillas. Lo malo es que casi todo está en inglés. Así que decidí hacer un ejemplo rápido de aplicación en castellano que mostrase un poco como funciona el TTS y el reconocimiento de voz en Español.

Greach

Creo que todavía no lo había comentado. El 4 de Noviembre tendré el honor de participar en Greach, la primera conferencia específica sobre Groovy y Grails que se va a celebrar en España.

Se trata de un esfuerzo conjunto entre el super-crack Alberto Vilches y javaHispano y que promete ser refrencia no sólo en España sino también en Europa ya que vienen refrencias como Guillaume Laforge, el project manager y principal promotor de Groovy; Graeme Rocher, el creador de Grails; Andres Almiray, creador de Griffon, json-lib, EZMorph, committer de Groovy y mucho más; Hamlet D'Arcy y otros muchos nombres que os sonarán como Arturo Herrero, Dani Latorre, Fatima Casaú, Marcin Gryzsko, Enrique Medina o Jorge Uriarte.

Así que desde este modesto lugar, no me queda más que darle la enhorabuena a Alberto y a javaHispano por organizar este evento y comentaros que el registro ya está abierto a un precio tan espectacular como son 10 euros. Vamos, que si estáis en el mundo de Groovy/Grails o queréis aprender más sobre estos lenguajes, yo diría que no hay excusa :)

Meses de cambios. Voxeo / Tropo

Los que seguís el blog, tan desactualizado en Agosto, recordáis ese momento de gloria Internetil que te convierte en portada de Meneame y trae tantos miles de visitas en un día casi como los que tiene el blog en todo el año y que fue el post sobre como había creado una empresa en 24 horas por 100 euros.

Los que me conocen rapidamente me preguntaron, ¿Qué tramas? Porque evidentemente alguna razón habría. Pero todavía no era el momento de comentarlo. Pero bueno, ahora sí que ya va siendo hora.

Transparencias Spring2GX Madrid 2010

El pasado Viernes tuve la oportunidad de estar en Grails 2GX con Jordi y Dani presentando nuestra experiencia con Jobsket y Grails. El evento estuvo para mi gusto muy bien, sobre todo con una excepcional asistencia (sobre 450 inscritos y el salón de actos casi lleno) lo cual crea un entorno perfecto de networking, muy de agradecer ya que hay muy pocos eventos técnicos en España. Allí pude poner cara a gente de Agile Spain, otros conocidos de Internet, y curiosamente gente de mi anterior empresa a los que nunca había conocido personalmente.

Alberto Vilches ha publicado un resumen muy completo en su blog y lo mismo ha hecho Tomas Lin en su blog, aunque este último en inglés.

Hemos publicado en Slideshare las slides de nuestra presentación para los que no hayan podido estar ahí:

Jobsket Spring 2GX Madrid

View more presentations from Jobsket.

En la presentación hacíamos una demo del producto que podéis encontrar en YouTube:



Un saludo.

Presentando en Spring 2GX Madrid

Todavía no lo había comentado en el blog pero este Viernes estaremos en Madrid presentando nuestra experiencia con Jobsket en el que va a ser casi con toda seguridad uno de los eventos de programación más importantes del año en España, Spring 2GX Madrid donde presentaremos "Productividad máxima con Grails y Java".

Se trata de un evento totalmente gratuito, y que debe todo el mérito a organizador a Sergi Almar y javaHispano y también escuela de groovy que es uno de los principales promotores de Grails en España. No os lo deberíais perder, no porque vayamos nosotros la verdad, sino porque cuando todo el mundo está cobrando por los eventos, este no cuesta ni un euro.

Creo que hay ya varios cientos de personas registradas (creo que rondando los 300 o más), así que el evento promete bastante como oportunidad de networking. Si os pasáis por allí, no dejéis de saludar.

Test funcionales para todos: Canoo WebTest + Grails.

Hace ya unos meses comentaba que Grails tenía sus cosas buenas y también sus cosas malas.

Pues bueno, el plugin de tests funcionales pasa a engrosar la lista de cosas que me gustan. Se trata de un plugin que integra Canoo WebTest, una fenomenal herramienta de testeo de la capa web.

Lo más importante que quiero destacar del artículo que estoy escribiendo es que no se limita a Grail. Este plugin simplemente se encarga de simular el acceso a páginas web y ejecutar un número de aserciones sobre las páginas. Los tests se escriben en Groovy y se necesita Grails para ejecutar, pero eso es todo. Es decir, podemos utilizar este sistema para testear cualquier aplicación web, ya esté hecha en Grails, en Java o en .NET. Y ya veréis que por lo sencillo que es, vale la pena.

Lo primero de todo es seguir las instrucciones del wiki, e instalar el plugin. Asumiendo que tenemos instalado Grails, tendríamos que:

• Crear el proyecto: grails create-app tests
• Instalar el plugin: grails install-plugin webtest
• Crear la carpeta de tests: grails create-webtest

Una vez hecho esto tendremos una estructura de directorios con la configuración de los tests, los reports y una carpeta "tests" donde se irán colocando los tests funcionales. Crear un tests es insultántemente sencillo, y treméndamente intuitivo. Tan sólo es cuestión de saber como trasladar el conjunto de tareas de WebTest a Groovy. Pero entre los ejemplos, y lo sencillo que es, pues no debería haber ningún problema.

Fijaros en el siguiente ejemplo de un test funcional que tenemos en Jobsket para comprobar que los perfiles de Linkedin se importan correctamente:

def testLinkedinUpload() {

invoke      '/login'
verifyText  'Entra en Jobsket'
setInputField(name:'login',value:"${user}")
setInputField(name:'password',value:"${password}")
clickButton 'Entra'

invoke '/upload/linkedin'

setInputField(name:'profile',value:'http://www.linkedin.com/in/mpermar')
setCheckbox(name:'legalAccepted')
clickButton '!Sube tu CV desde Linkedin!'

verifyText 'Tu CV'
}

¿Es necesario que explique algo del test? Nada de código Java, nada de XML, nada de scripting raro. No os exagero, hacer tests funcionales con Grails y WebTest es una gozada. El código es muy sencillo de leer, y además al ser Groovy sigues teniendo la potencia que te ofrece un lenguaje orientado a objetos y puedes agrupar funcionalidad común a los tests en otras clases. Pues por ejemplo agrupar la parte de login de ahí arriba en un método login que pondríamos en una clase padre. Es un ejemplo.

Quedaría simplemente ejecutar el test:

• grails run-webtest MiTest

Una vez se ejecutan los tests, los informes se pueden ver desde la web:



Y nada más. Simplemente resaltar lo comentado. Si estás haciendo un proyecto web, y buscas una herramienta para ejecutar tests funcionales, entonces Grails + Canoo WebTest es una opción muy recomendable. Además se integra muy bien con Hudson, pero eso lo dejo ya para otra entrada :)

Spring Roo, ¿competencia para Grails?

Interesante lo de Spring Roo. No lo conocía pero he llegado a él a través de la lista de Grails.

El link de arriba, el oficial, la verdad es que no deja nada claro que es Roo (el nombre parece que está todavía abierto). Según la descripción de esa página, pues casi que podría ser cualquier cosa. Pero bueno, básicamente Spring Roo viene a ser la alternativa Spring a Ruby on Rails o Grails. Es decir, un framework creado bajo los principios de convención frente a configuración y que aprovecha al máximo Java y Spring.

Hace un par de días, uno de sus autores publicó esta entrada en su blog donde muestra como construir una aplicación web Java totalmente funcional en solo 11 comandos. Vamos, muy en la línea de cualquier tutorial de grails o rails pero siendo todo Java, sin nada dinámico. En la misma entrada hay un link a la primera versión descargable de Roo por si lo queréis probar.

Ni que decir tiene que el framework está totalmente centrado en torno a Spring, Maven, JPA, muchas anotaciones, el soporte de REST de Spring 3.0 y AspectJ, siendo este último lo que se utiliza para introducir el llamemos "dinamismo" en la aplicación. La verdad es que de buenas a primeras a mi esta propuesta se me antoja muy pero que muy interesante. Especialmente por las ventajas de ser estático en cuanto al soporte del entorno de desarrollo, que es lo que a mi más me atrae. ¡Pero dónde estabas hace un año por favor!

En esta otra entrada de blog comentan algunas impresiones sobre Roo extraidas del keynote de Rod Johnson en la SpringOne.

Bueno y ahora la pregunta, ¿y por qué Spring Roo si SpringSource acaba de comprar G2One y por consiguiente tiene Grails entre sus proyectos? Graeme Rocher contesta en la lista de Grails.

We're working on a formal FAQ to help answer some of these questions, but fundamentally SpringSource is about enhancing developer productivity and those who cannot move to Grails (due to corporate policy mandating Java for example) shouldn't suffer from an unproductive environment hence the existence of Roo. Ultimately whether you use Grails or Roo you're going to be using Spring so we don't necessarily see them competing.

Now Roo can only achieve so much within the limitations of a statically typed language and in fact does most of its tricks through AspectJ and code generation. We hope that it is a gateway drug so that users eventually move to Grails and experience the full productivity benefits of both the Groovy language and the Grails framework. Until then people sticking with only Java at least have Roo as an option.

La explicación tiene todo el sentido del mundo. El único problema es que no evita que se trate de dos frameworks muy parecidos. ¡Y ambos hechos en Java! Con la única diferencia de que Grails soporta y requiere groovy. No sé yo si mantener los dos tiene demasiado sentido, por lo que esto siembra algunas dudas. ¿Podrian converger en el futuro? Dejo abierta la pregunta por si alguien quiere opinar.

SpringSource compra Groovy y Grails (i.e. G2One)

Ayer me quejaba de que en Grails se deberían centrar más en la integración con Spring y Grails. Pues justamente hoy apuntaban en la lista a esta noticia en TheRegister donde comentan que SpringSource ha comprado a G2One, la empresa detrás de Groovy y Grails.

Enhorabuena a los premiados! Y a ver si así el proyecto sigue tirando hacia adelante.

Las cinco cosas que menos me gustan de Grails

Hace unos días comentaba las cinco cosas que más me gustaban de Grails y avisaba de que habría un post de continuación con las cinco cosas que menos me gustaban. Pues aquí está ese post. Creo que coincidí bastante con otros en las cosas que me gustaban (salvo GORM) pero me imagino que no coincidiré tanto en las que no me gustan. Es más difícil coincidir en lo que no te gusta, en parte porque quizás esté equivocado en algunas cosas y existan soluciones. Lo mejor de esto último es que espero comentarios que me hagan ver la luz :) Pero bueno, al grano:

• La falta de herramientas serias para soportar el trabajo de creación de aplicaciones: Esto es de largo lo que menos me gusta, y sinceramente una de las razones por las que quizás no volviese a empezar un proyecto con Grails. Porque seamos sinceros, Grails apenas tiene soporte de herramientas serias para desarrollo.
  
  Es cierto que existe la posibilidad de instalar un plugin para Eclipse, y soporte nativo en IDEA y en NetBeans. Pero la cruda realidad es que hoy por hoy estas herramientas no son más que un conjunto de scripts para ejecutar los comandos de grails, más reglas de coloreado, síntaxis, autocompletado y todas estas cosas. Poco más.
  
  Quizás aquí la frustración venga a raiz de usar Eclipse. También lo intenté con IDEA pero la verdad es que es bastante frustrante ver como comienzas a utilizar una tecnología y ves que desde hace casi un año apenas ha habido progresos en cuanto a herramientas de soporte. Uno se esperaría algo más de atención hacia esos aspectos. Aquí no se trata ya de trivialidades como coloreado o autocompletado, sino de hacer fáciles las cosas que son realmente más complicadas como son la integración con Java, la integración con builds existentes, el facilitar la depuración de aplicaciones tanto local como remota, el facilitar integración con JUnit y/o Spring o la ejecución de tests unitarios y de integración en el IDE, el detectar errores difíciles (ver último punto) de encontrar o el ofrecer refactorizaciones. Y en todo esto, Grails (aunque me atrevería a añadir "y compañía") hace agua.



• La obsesión por "pluginizar" y "grailsificar" Java: Grails está lleno de plug-ins. A fecha de escribir este post hay más de 100 plug-ins diferentes. Los hay de todos los tipos y colores: testing, gráficas, scheduling, búsquedas, etc. Todos estos plug-ins básicamente le dan a librerías existentes en Java un aspecto mucho más 'grails-friendly'. A parte de estos plug-ins, si echamos un vistazo al roadmap de Grails podemos ver que prácticamente todo el esfuerzo planeado se centra en acercar tecnologías ya existentes en Java a Grails, como por ejemplo el soporte de JCR, de JPA, de Portlets, JSP tags, etc.
  
  En todo esto, según mi opinión, hay una contradicción bastante importante. Veamos, el principal punto a favor y argumento utilizado desde siempre a favor de Grails frente a otras alternativas es que nos permite utilizar Java, se integra bien con Spring y Hibernate, y podemos reusar lo que ya hemos creado estos años atrás. Pues bien, partiendo de estas premisas y teniendo en cuenta que la mayor parte de las tecnologías ya se integran con Spring. ¿Por qué no investir en mejorar la integración Java/Grails y Java/Spring en lugar de perder el tiempo reinventando la rueda en forma de plugin o sopporte nativo en Grails?
  
  Por poneros un ejemplo, ¿de qué me sirve un plug-in de Quartz que no funciona bien y que tiene muchos conflictos con el modo en que Grails gestiona las sesiones de Hibernate si símplemente ya lo tengo y lo puedo utilizar desde Spring? Me contesto: me sirve de nada, para perder tiempo en bugs y más bugs de 'grailsificación' de la librería. Lo mismo pasa con por ejemplo Searchable, que a algunos les funciona y a algunos no (como nos pasó a nosotros), pero que sería mucho más fácil simplemente aprovechar Spring y su integración con Compass.
  
  Y ese es el gran problema. La mayoría de plug-ins que hay en el repositorio o bien funcionan para unos casos concretos o triviales, o bien se han quedado obsoletos y nadie los mantiene, o bien tienen conflictos con proyectos híbridos (java+groovy). Los menos, es decir los tres o cuatro más usados (como JSecurity, Searchable, ...), sí que van evolucionando y mejorando, pero al mismo tiempo van apareciendo plugins como Background Thread que nacen para solucionar problemas de otros plugins. El plug-in del plug-in :) Sea como sea, todos estos plug-ins comparten una característica: ya estaban implementados en Spring y funcionaban perfectamente.
  
  Yo aprecio realmente el esfuerzo de toda esta gente. Pero en mi opinión es una estrategia insostenible, y sería muchísimo más razonable el mejorar la integración con Spring y Hibernate y el centrar sus esfuerzos en la parte del cliente. Yo mantendría los plugins, pero sólo los relacionados con la parte del interfaz+controladores (como GrailsUI que sí es realmente útil) y me centraría mucho más en dicha parte y en facilitar la creación de RIAs. Eso sí que realmente iba a mover Grails hacia adelante.



• Los servicios: Al hilo del punto anterior, no le acabo de coger demasiado el punto a los Services en Grails. Nuestra aplicación Grails empezó con pocos servicios, que fueron aumentando a unos 10 o 15, y ahora se han vuelto otra vez 3 o 4. ¿A dónde se han ido? Pues de vuelta a Java. Los hemos tenido que migrar debido a las razones expuestas en los puntos anteriores, y sinceramente ahora al menos yo me siento muchísimo más productivo ya que no hay más bugs debidos a la integración con Grails y podemos usar nuestros IDEs productivamente. Personalmente creo que a fecha de hoy en cuanto a Grails, y en el caso de los servicios, es mucho más simple hacer el backend en Java, ya que hoy por hoy todo está prácticamente hecho y el soporte de los IDEs es sobresaliente y hay montones de herramientas y frameworks que reutilizar. ¿Hacer el backend en grails utilizando plug-ins en estado más que dudoso? No, gracias.
  



• El sistema de build y su falta de integración con Maven: Grails se construye con scripts escritos con Gant, que es como Ant pero para Groovy. A fecha de hoy la integración con Maven es prácticamente inexistente (aunque sí que hay un plugin para ejecutar tareas de grails desde Maven), y eso convierte en algo bastante engorroso el modularizar tu proyecto aprovechando todas las ventajas que Maven ofrece para esto. Para mi (y esto es una opinión muy personal), utilizar Ant, y por consiguiente Gant, es un atraso importante.
  
  Aunque eso sí, parece que hay buenas noticias en este frente, ya que justamente la semana pasada publicaban en la lista de Grails algunos avances respecto a "Mavenizar" Grails, y la verdad es que tiene mucha mejor pinta que lo que tenemos ahora. Han creado un nuevo arquetipo para crear aplicaciones Grails, lo que supongo que significará que podemos importar dependencias desde nuestro proyecto Grails, o utilizar nuestro proyecto como dependencias lo que ayudaría muchísimo en cuanto a la modularización e integración con otros proyectos.



• Todas esas cosas que no están escritas y que al final te acabas encontrando: Esto más que un problema exclusivo de Grails, es más un problema de cualquier tecnología nueva. Grails, como framework novedoso, está lleno de cosillas y particularidades (y sólo hay que echarle un vistazo a la lista de correo para darse cuenta) que te pueden dejar atascado durante un buen rato. A esto también contribuye que el lenguaje sea dinámico y que ofrezca ciertos "adelantos" para incrementar la productividad lo que inevitablemente establece determinadas restricciones en como se hacen ciertas cosas.
  
  Por poner un ejemplo, uno de los problemas con los que me encontré un día es que tenía una excepción rarísima al desplegar la aplicación, y en realidad no había hecho apenas ningún cambio. Lo poco que había cambiado era realmente inocente. ¿O no es inocente el añadir un atributo llamado lastUpdated a tu clase Java e intentar persistir eso en Hibernate con su correspondiente columnilla en base de datos? Pues sí, seguramente es muy inocente, pero en Grails no se puede porque dateCreated y lastUpdated son dos propiedades que se utilizan para hacer automatic timestamping. Este es el típico ejemplo de problemilla que te puede dejar atascado unas cuantas horas, o días, intentando descubrir que diablos pasa. Pero, no todo es malo, por suerte la lista de correo es muy activa, y es fácil recibir respuestas bastante rápidas.
  
  Otro ejemplo más. Las aplicaciones de Grails se pueden desplegar en ficheros .WAR que más tarde se pueden soltar en cualquier servidor de aplicaciones, como por ejemplo Tomcat. Al mismo tiempo, las vistas en aplicaciones Grails se crean mediante ficheros .GSP que son como ficheros .JSP pero en Grails. Lo natural para un desarrollador Java sería pensar que una vez desplegada tu apliación en Tomcat podrás editar tranquilamente los ficheros .GSP en tiempo real y ver los cambios sin reiniciar el servidor. Pues.... NO. Sorpresa, sorpresa. Por defecto no funciona así, y a no ser que reinicies el servidor no verás tus cambios actualizados, algo que nuevamente te tendrá ocupado un buen rato imaginando que puede estar pasando.
  
  Por cierto, que existe la posibilidad de habilitar la recarga de clases en tiempo real, pero curiosamente no la recomiendan demasiado porque degrada el rendimiento. Parece que la gente comenta en la lista de correo que esta degradación de rendimiento no es realmente demasiado terrible, pero a mi todo esto me suena un poco a letra pequeña, especialmente cuando es algo que no se comenta en la documentación. Claro, porque a fin de cuentas, ¿a quién le va a interesar eso de que se puedan modificar las clases sin reiniciar el servidor? Si total, todo el mundo puede reiniciar el servidor...

Bueno y estas serían las cinco cosas que más me molestan. La verdad es que, aunque no todo es malo, lo cierto es que me parecen problemas importantes. ¿Me arrepiento de haber utilizado Grails? No, porque es un concepto diferente que está muy bien para aprender nuevas formas de hacer aplicaciones. ¿Lo utilizaría de nuevo? Depende de la aplicación. Sigo creyendo que es muy productivo para un determinado tipo de aplicaciones, para prototipado rápido, y realmente muy bueno si nos centramos en vista+controlador. Pero lo cierto es que después de haber trabajado bastante con el, se me antoja como un framework algo limitado para proyectos más importantes que necesiten de todo los puntos que he comentado arriba.

¿Opiniones?

Configurando Hudson para proyectos Grails

Como parte del desarrollo de Jobsket, una de las cosas que hemos hecho es el preparar un servidor de integración continua para intentar mantener nuestras builds lo más estable que sea posible.

Grails, no tiene ningún plug-in ni soporte específico para ningún sistema de integración continua así que decidimos descargarnos e instalar Hudson. La principal razón para instalar este sistema de integración continua es que es muy sencillo de instalar y administrar, ya que toda la configuración se realiza desde el UI de la propia aplicación, con sus bonitos componentes AJAX, sin necesidad de andar tocando ficheros de configuración.

Hudson está por defecto preparado para trabajar con Java, pero configurarlo con otros lenguajes o frameworks no debería dar ningún problema. Aquí no os voy a aburrir con los pasos para instalar y configurar Hudson, sino que comento simplemente los cambios necesarios para integrar un proyecto de Grails son tan sólo dos y son realmente muy simples:

Primeramente configuramos nuestra build para ejecutar un shell script. Este script contendría los pasos necesarios para la ejecutar nuestros tests o la build o lo que queráis. En nuestro caso el script es realmente sencillo ya que simplemente estamos interesados en ejecutar los tests, pero si tenéis otros requisitos podéis ejecutar directamente cualquier script de Ant o Gant, lanzar Maven, o lo que sea.



Lo segundo es simplemente hacer que Hudson lea nuestros informes de test. Por defecto Grails los coloca en el directorio test/reports, así que simplemente le decimos a Hudson que los busque ahí:



Una última cosa importante que no he comentado es que no os debéis olvidar de ajustar todos los settings necesarios para ejecutar grails, como por ejemplo:

export PATH=$PATH:/opt/grails-1.0.1/bin
export JAVA_HOME=/opt/java/jdk1.6.0_03
export GRAILS_HOME=/opt/grails-1.0.1

Hudson te permite configurar desde el UI la JAVA_HOME pero el resto lo tendréis (creo) que añadir vosotros en alguna otra parte. Yo por ejemplo tengo todo esto en el script que se arranca al loggearse el usuario, pero vosotros lo podéis poner donde queráis, como por ejemplo en el script que vimos antes que ejecuta los tests.

Pues eso es todo, no debería llevar más de 10 minutillos. Rápido y sencillo.

Las 5 cosas que más me gustan de grails

Que desastre, este post llevaba 10 días como draft, pero bueno, que al final he sacado un rato para que vea la luz.

Durante los últimos meses he estado trabajando con Grails para un proyecto personal con unos amigos. La tecnología la elegimos poco después de empezar este año con el principal objetivo de aprender sobre algo de lo que se estaba hablando mucho y bien.

Empezamos nuestra andadura con algo que no estaba todavía en la versión 1.0 y estamos casi terminando a alturas de 1.0.4 y cerca de la 1.1, por lo que bueno, a pesar de que no me considero un experto en el tema ni mucho menos sí que creo que puedo expresar mi opinión personal con autoridad. Así que este post se lo dedicaré a las cinco cosas que más me gustan de Grails y un post futuro estará dedicado, por supuesto, a las cinco que menos me gustan.

• Es muy fácil crear aplicaciones: Yo creo que esto es probablemente lo más pragmático de grails y se gana el primer puesto por ello. El ponerte en la línea de comandos y ejecutar grails create-app MiApp y tener rápidamente una aplicación web completa funcionando. El ejecutar otro par de comandos y tener tu modelo, vistas, controladores y servicios listos para utilizar hacen de Grails una herramienta muy poderosa, quizás la más poderosa en Java en estos momentos para la creación de prototipos y pruebas de concepto rápidas ya que sin exagerar nada en 30 segundos tendrás tu aplicación ejecutándose en Jetty con Hibernate y Spring. QuickStart



• Por fin crear tests de integración es sencillo: Esta es la funcionalidad que más me ha gustado, y es que con Grails ejecutar tests de integración es realmente sencillo. Tan sencillo como ejecutar grails create-integration-test y grails se encargará el solito de inyectar todos los servicios que utilicemos en el test así como la conexión a la base de datos. Por defecto grails utiliza una base de datos HSQLDB en memoria para ejecutar los tests y borra su contenido entre test. Más sobre testing aquí.



• Integración con Spring: Para los que siempre hemos sido más javeros que otra cosa la integración con Spring es sin lugar a dudas el factor más decisivo a la hora de decantarse con grails. Grails permite acceso desde servicios y controladores a cualquier bean de Spring y lo contrario también se cumple, es decir, se puede acceder a cualquier servicio de grails desde Spring, aunque cierto es que es necesaria alguna triquiñuela como hacer que dichos servicios implementen una interfaz Java para salvar el gap entre el mundo estático y el dinámico. Aquí más sobre Spring y Grails.



• La comunidad es muy activa:
Este Domingo por la mañana estaba echándole un vistazo al correo y me di cuenta que había bastantes correos sin leer en la carpeta de Grails. Le fui a echar un vistazo y me fijé que en la última hora habían llegado como unos 10 o 15 correos nuevos. No creo que exista esta métrica para medir lo activas que son las comunidades, pero desde luego que el número de mensajes un domingo por la mañana llegue a los treinta o bien indica que la comunidad es activa o que los usuarios están o bien borrachos o bien muy aburridos. En el caso de Grails creo que es lo primero. Hay montones de mensajes cada día y es fácil el ver tus dudas resueltas en unas horas. En este enlace están los enlaces a las listas de correo.


• Vistas y controladores: Las vistas y controladores son probablemente la parte que más me gusta de Grails. Nada nuevo por aquí ya que todos los conceptos vienen de Rails que ya ha demostrado de sobra su éxito como framework para desarrollo web. Lo sencillo y rápido que es crear y mapear todos estos componentes junto con los diferentes constructores que están disponibles para gestionar la request, hacer binding de parámetros, controlar la response, etc. etc. hacen que sea muy sencillo el crear páginas web, que al final es lo que interesa. El enlace correspondiente
  
  Los que conozcáis Grails os habréis dado cuenta de que he excluido los servicios, y es que personalmente yo hubiera preferido aquí una estrategia mucho más a lo Appcelerator en la que simplemente se invocasen endpoints proporcionados por Spring. Personalmente, prefiero mis servicios echos en Java que en Spring, así que para mi hubiese tenido más sentido una aproximación más de ese estilo, y a parte creo que sería más útil para el framework que sus desarrolladores se concentrasen en la pare de vistas, controladores, javascript, etc. que es donde hace un poco más agua Java y dejasen de lado los servicios, que ahí hay material de sobra que reutilizar.

Pues nada, en breve (espero) una lista con las cinco cosas que menos me gustan de Grails. O quizás sean más, que yo soy muy protestón ;)

¿Está grails listo para el 'prime time'?

Llevo (llevamos) ya unas semanas trabajando con Grails así que no os extrañéis si de vez en cuando sale por este blog algún post como éste sobre este framework. Una de los problemas que se le achaca a frameworks como Grails (o uncluso Ruby on Rails) es su incapacidad para afrontar proyectos grandes.

Aún así, poco a poco van apareciendo casos de uso de empresas importantes adoptando estas tecnologías. Es el caso de Sky que ha lanzado un nuevo sitio de "cotilleos" basado en grails y cuyos desarrolladores han relatado su experiencia recientemente en este hilo de la lista de correo de grails. Muchas de las lecciones son aplicables también a otros frameworks como JRuby on Rails o Ruby on Rails por lo que puede ser interesante echarle un vistazo.

El sitio web fue desarrollado por 18 desarrolladores, aunque no comentan cuanto tiempo les ha llevado. Durante el primer día recibieron 1 millón de peticiones (que creen que son muy pocas para lo que esperan), aunque realmente sólo un porcentaje de ellas llegaron hasta la capa web. Para hacer frente a la carga contrataron un CDN y colocaron los correspondientes balanceadores de carga.

Estas son algunas de las conclusiones a las que han llegado:

• Desarrollar una aplicación web en grails es más divertido y sencillo que hacerlo en puro Java.


• El soporte de herramientas es bastante pobre y es algo que debe mejorarse. De esto no puedo más que dar fe.


• Utilizaron ocho diferentes entornos y tuvieron problemas en cuanto a la configuración. No les quedó más remedio que crear su propio plugin para manejar su entorno.


• La documentación en cuanto a como arrancar con grails es insuficiente. No hay una receta clara sobre como empezar a utilizar el framework ni recomendaciones/buenas prácticas para entornos de preducción.


• El framework de testing que expone grails ahorra muchísimo trabajo, especialmente a la hora de testear la interacción con la base de datos.


• Fue muy común el encontrarse con plug-ins que no satisfacían todos sus requisitos, es decir que muchos plug-ins no están pensados para 'usos extremos', y tuvieron que tocar su código y modificarlos más veces de las que hubiesen deseado.


• Los problemas de compatibilidades entre plug-ins fueron también bastante comunes, aunque reconocen que el estado general del ecosistema de plug-ins es aceptable.

En las próximas semanas probablemente comente algunas de mis/nuestras experiencias con este framework. Aunque por ahora, lo que puedo decir es que subscribo todos y cada uno de los puntos de la experiencia de los desarrolladores de Sky.

¿Está Ruby en decadencia?

Hoy he podido ver como en algún blog citan el informe de TIOBE para el mes de Mayo en el que parece que el uso de Ruby no ha crecido durante los dos últimos meses e incluso ha decrecido. Citando al informe:

Although, Ruby is the rising star if you look back 1 year, it is not growing more the last couple of months. Even worse, since April it is slightly declining. If this appears to be the new trend, then also Ruby does not become the "next big programming language.



Una vez dicho esto, la verdad es que me parece un análisis bastante sensacionalista. Tanto como el título de este tópico :-) Simplemente no se puede pronosticar la tendencia de un lenguaje a partir de sus resultados en los dos últimos meses, especialmente cuando el lenguaje es tan joven, y es totalmente normal que esté sujeto a altibajos. No siempre va a mantener la espectacular subida del último año.

Incluso en el caso de que Ruby mantuviese la tendencia y se quedase estancado, sería algo absolutamente normal. Hay que pensar que a corto plazo el objetivo de Ruby es llegar a la línea marcada por PHP, no a la línea marcada por Java. Ruby no tiene todavía calado empresarial como para plantearse siquiera ese objetivo. Ruby ha estado subiendo a costa de restar desarrolladores especialmente a lenguajes de programación como Java, pero realmente lo que le debe hacer subir es el restarle programadores a su competidor directo.

A todo esto, hay que sumar que determinados proyectos en Java deben haber contribuido a frenar el avance de Ruby. Mucha gente seguro que prefiere utilizar JRuby o Grails ahora que el soporte de el modelo Ruby on Rails es mucho mejor y más estable, simplemente porque pueden seguir aprovechando todo lo que ya existe sobre Java.

Eventualmente, y en el hipotético caso de que esta tendencia se mantuviese, entonces estaríamos ante la definitiva prueba de madurez de la comunidad Ruby. Significaría que ha alcanzado su base de usuarios estable, y obligaría a toda la comunidad a crear nuevos productos bandera que como Ruby on Rails permitan dar un nuevo salto hacia arriba, y eventualmente acercarse más al mundo de la empresa.

Así que resumiendo mi opinión, estoy seguro de que Ruby todavía tiene cosas que decir.