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 :)

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.

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?

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.

El año de Groby

Un compañero de trabajo, que alguna vez hablaré sobre él porque es un verdadero genio, me comentaba que en el mundo de los mercados financieros, tradicionalmente se reproduce un patrón temporal, que es muy similar a lo que sucede en la informática: tras un determinado intervalo de tiempo, siempre surge una determinada tendencia de mercado que inicialmente atrae a los cerebros más importantes, que pasa a convertirse en tendencia de moda atrayendo a masas, y que finalmente se convierte en estándar.

Quizás las muestras más recientes de este efecto dentro del mundo de la programación han sido Java, y el concepto de metodologías ágiles. Ambos siguen el mismo patrón comentado anteriormente, y comenzaron como pequeños embriones atrayendo a gente que buscaba algo nuevo y que veía cosas interesantes en estas tendencias; posteriormente se convertieron en lenguajes y metodologías cool, atrayendo masas; y finalmente se han convertido en estándares de facto en el desarrollo empresarial.

¿Cuál será la próxima tendencia? Todo apunta a que tanto Groovy como Ruby tienen mucho que decir este año. El primero ha entrado muy fuerte en el 2007 con el lanzamiento de Groovy 1.0, su estandarización en Java 6, y la productividad ofrecida por grails. El segundo se podría decir que ha ya ha ganado el título de lenguaje cool en el año 2006, gracias sobre todo a Rails.

Personalmente creo que es difícil apostar por el ganador. Ruby tiene ya una masa grande de usuarios, pero parece claro que Groovy incrementará su popularidad este año. Sea como sea, hay muchos inidicios que indican que es posible estos lenguajes sean lo que nos espera en los próximos años, así que más que nunca vale la pena aprender algo que no sea Java y .NET. Yo por mi parte ya he empezado, y no soy el único. Algún plan hay por ahí. Ya veremos si cristaliza.