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.

Cinco soluciones basadas en Lucene para Real Time Search

Hace unos días trascendió que Twitter había terminado su proyecto de migración para su backend de búsqueda en tiempo real (search.twitter.com). El proyecto había comenzado en la primavera del 2010 y terminó en Abril del 2011 así que tenemos, tal y como señala Javier Murillo en su análisis, un año para un proyecto desarrollado por un equipo de quince ingenieros.

Twitter tenía dos problemas para querer cambiar la arquitectura de su sistema de búsqueda y que hasta el momento estaba basado en el modelo clásico de base de datos relacional. Uno era el que describen en el post de este mes, y es la escalabilidad. Con Rails estaban atados a un thread por búsqueda y eso hacía que desperdicien CPU y recursos mientras se está realizando la búsqueda. Algo realmente importante cuando tienes 12.000 búsquedas por segundo y mil millones de búsquedas diarias. Para eso decidieron migrar a una arquitectura asíncrona basada en Netty tal y como explica el artículo.

Comparando protocolos de serialización en Java

Así por casualidad he llegado a una página que quizás ya muchos conoceríais, pero por si acaso la voy a dejar pora aquí.

Se trata de la página del proyecto thrift-protobuf-compare que comenzó como un proyecto para comparar el rendimiento de Protocol Buffers de Google y Thrift de Facebook (donado a Apache).

La persona que creó Tomcat y se hizo fotógrafo

Estoy leyendo un libro del que todavía no voy a decir el nombre ya que habrá review muy pronto y dentro del cual hay algunas personalidades del mundo del software que cuentan historias inspiradoras.

Sin duda la que más me ha inspirado es la de James Duncan Davidson. ¿Os suena el nombre? Seguramente no. ¿Y si os digo que es el creador de Apache Tomcat, de la especificación de Servlets y de Apache Ant? Pues el nombre seguramente os seguirá sin sonar pero ya nos vamos haciendo un contexto de quién es esta persona.

Consejos para gestionar 100K TPS con menos de 1ms. de latencia

Hace poco más de un mes publicaron en InfoQ una presentación muy interesante sobre como crear aplicaciones capaces de procesar un gran número de transacciones con una latencia muy pequeña.

Los autores de la presentación fueron Martin Thompson y Michael Barker y trabajan en LMAX. Esta copañía desarrolla lo que se llama un Trading Exchange. Este tipo de compañías ofrecen la posibilidad de comprar activos financieros al usuario final (i.e. nosotros) ofreciendo un pool de proveedores (agencias de trading, bancos, etc.) que compiten entre sí para ofrecerle al usuario el mejor precio. La idea es que si por ejemplo quiero comprar EUR/USD el sistema me va a ofrecer siempre la mejor oferta de entre los varios proveedores existentes en el trading exchange.

Elastic Beanstalk: Heroku para Java

Heroku es un servicio online englobado en lo que se conoce como PaaS (Platform as a Service), y que básicamente permite el desplegar aplicaciones Ruby en una nube de servidores que se escala automáticamente para satisfacer las necesidades de carga de las aplicaciones.

En Java (hasta donde yo sé) no había demasiados servicios similares. Está Stax que lo compró Cloudbees me imagino que con la intención de hacer algo similar a Heroku, y estaba por supuesto Google App Engine que es una plataforma que prometía mucho, pero que entre las limitaciones que impone y los problemas que sufrieron muchos desarrolladores por tratarse de una Beta que era una "verdadera Beta", pues no ha tenido toda la popularidad que se podría desear.

La historia de jRockit, como ganar un concurso en la universidad te puede cambiar la vida

Hace unos días recomendaba el libro Oracle JRockit: The Definitive Guide y comentaba que el prólogo contaba la historia de JRockit que publicaría en un nuevo post. Pues este es ese post :)

Para los no familiarizados con Java, jRockit es lo que se llama una máquina virtual. Es lo que ejecuta programas escritos en Java. Hoy en día muchísimos dispositivos vienen con una máquina virtual dentro, teléfonos móviles, coches, televisiones y por supuesto ordenadores. jRockit es una máquina virtual orientada a los ordenadores y principalmente a servidores.

El origen de jRockit es muy curioso a la vez que motivador para cualquier joven. En 1997, tres estudiantes universitarios llamados Joakim Dahlstedt, Mattias Joëlson y Fredrik Stridsman ganaron un concurso de programación para estudiantes organizado por Sun Microsystems y cuyo premio era un viaje a la JavaOne, la conferencia más importante de Java que se organiza en el mundo. Por diversión, volvieron a presentarse al año siguiente y volvieron a conseguir el premio.

Emprendiendo con Java y Open Source: La historia de JasperSoft

¿A quién le suena la imagen de la izquierda? Es prácticamente una de las imágenes más míticas del mundo Java. Se trata de "The First Jasper Report Ever" y era el primer ejemplo que te encontrabas al descargarte la librería Open Source de generación de informes JasperReports.

Teodor Danciu creó el proyecto Open Source JasperReports allá por el 2001 como repuesta a una carencia importante de Java. No había ninguna librería estándar para generar informes. El proyecto pronto se convirtió en una herramienta popular debido a la falta de herramientas similares y prácticamente era un estándar. Básicamente la opción era o usas JasperReports o te ibas a una solución de pago tipo Crystal Reports que además no soportaban demasiado bien Java.

A los malos les gusta Java

Los que llevamos ya algún tiempo en esto nos acordamos de la época en la que Java no existía en los ordenadores personales. Era la época en la que en los foros se comentaba: "Para que Java triunfe tiene que ir incluido en el sistema operativo", o "Para que java triunfe el JRE tiene que poder descargarse rápidamente".

En mi opinión Java nunca ha triunfado realmente en el escritorio. Son pocas las aplicaciones de usuario basadas en Java, aunque lo cierto es que ahora mismo son pocas las aplicaciones de escritorio basadas en cualquier lenguaje. Quizás la aplicación que más haya contribuido a la instalación de Java haya sido JDownloader, al menos en España segurísimo. Bueno, y de los Applets ya mejor ni hablamos, y eso que en 2008 parecía que podían volver, y en 2007 ThinkFree daba caña, pero nada amigos, kk de la vaca, como Java FX.

Lucene, Grids, Heaps y otras cosas del montón

En el penúltimo post explicaba la importancia en ciertos escenarios de que los objetos tengan una vida de corta duración. Only the good die young. Uno de esos escenarios es el caso en el que tengamos una Heap enorme, caso en el que la recolección de basura puede llevar mucho tiempo.

¿Y qué tamaño puede tener uno de esos Heaps tan enormes? Recuerdo hace años que tener un Heap de 512Mb ya era la caña. Después, cuando estabamos haciendo aplicaciones de trading hace ya casi cinco años, jugábamos con Heaps de 4gb, que no estaba mal pero ya resultaba bastante pequeño, pero era fruto sobre todo de las limitaciones de los sistemas operativos de 64 bits y en producción si que nos íbamos a 8, pero con la incertidumbre de no saber con exactitud que iba a pasar.

Más ofertas para Javeros

Últimamente ando un poco metido a job board. Algo que habrá que arreglar en los próximos meses. Por ahora ya tengo pensadas algunas cosas, falta materializar, y claro, tiempo.

Mientras tanto, quizás alguien esté buscando trabajo en Java. La empresa Biko nos acaba de publicar dos ofertas muy interesantes en Jobsket. Una es para un perfil Junior, y otra es para un perfil senior. Conociendo a Joserra desde hace muchos años en Internet seguro que es un buen sitio para trabajar y para familiarizarse con buenas prácticas, metodologías ágiles y TDD.

Os las dejo aquí por si a los que visitáis este blog os interesan:

http://www.jobsket.es/trabajo/biko2-2006-sl/desarrollador_senior_java


http://www.jobsket.es/trabajo/biko2-2006-sl/desarrollador_junior_java

Además por lo que publican en video, parece un buen sitio para trabajar jejeje

Estaré en la III Jornada de Tecnologías Java en la Universidad de Alicante

Dentro de dos semanitas, el 1 de Diciembre tendré el placer de participar en la III Jornada de Tecnologías Java en la Universidad de Alicante a las que muy amáblemente me invitó a participar Domingo Gallardo.

El título de la charla es "Desarrollo y pruebas de proyectos Java en un entorno ágil" y bueno hablaré un poco sobre lo que voy contando aquí en este blog. Meteré bastantes batallitas irlándesas que es donde más me he empapado de todo lo que implica el agilismo, pero sobre todo intentaré explicar lo que significa para mi el ser un profesional del software, que es lo que siempre he querido ser, y como conseguirlo aplicando técnicas ágiles.

La charla lleva la coletilla Java pero será simplemente para poner algunos ejemplos. El 95% por cien de la presentación se puede aplicar a cualquier lenguaje. Pues nada, que os animo a pasaros por allí.

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

¿Escala Java? Entrevista a Todd Hoff.

Ayer estuve escuchando un podcast de JavaWorld en el que entrevistan a Todd Hoff y en el que charlan alrededor de treinta minutos sobre Java y escalabilidad. Todd Hoff es la persona que está detrás del sitio web de referencia hoy en día en cuanto a escalabilidad, High Scalability. Os podéis descargar este podcast en formato MP3 desde este enlace

El podcast es ameno de escuchar, y se centra alrededor de la pregunta de sí Java es una plataforma escalable o no. Aquí va un resumen de algunos de los puntos tratados y con los que no puedo estar más de acuerdo:

• La escalabilidad no depende del lenguaje sino que depende de la arquitectura. Un sistema no escalará más por estar escrito en Ruby, C, Java o Scala sino que escalará dependiendo de la arquitectura del sistema, de si se puede hacer caching, sharding, si el procesado es síncrono o asíncrono, si se está o no compartiendo estado entre nodos, etc.


• El gran valor de Java está en la platforma, las herramientas y la comunidad, y eso inevitablemente ayuda a escalar. Si tengo algún problema, hay innumerables fuentes de información para solucionarlo. Si un framework no funciona, hay innumerables alternativas para sustituir ese framework.


• Java favorece demasiado al desarrollador. El sistema de bloqueos de alto nivel, el fomentar el compartir estado o el sugerir la arquitectura en capas o la recolección de basura no ayudan en cuanto a alta escalabilidad. Se favorece la escalabilidad vertical, es decir un servidor con 24Gb de RAM en lugar de 6 de 4Gb. Todo esto ha hecho que aparezcan soluciones "raras" como Azul que virtualiza en Hardware la JVM y que nunca deberían haber sido necesarios.


• Intentar moverse a un modelo de SaaS. ¿Es realmente necesario un servidor de aplicaciones? Linkedin por ejemplo basa su arquitectura simplemente en Jetty. Las capas tienden a estorbar cuando hablamos puramente de escalabilidad.

Se tratan otros temas pero eso es con lo que me quedo. Por cierto que en la propia High Scalability hacen también un resumen sobre esto mismo y otros temas que se han ido comentado últimamente sobre Java y su habilidad para escalar.

Cuando los premios son al trabajo bien hecho

El post de hoy no va sobre la Web 2.0, ni sobre lo último del Cloud Computing, ni sobre la última inversión de algún serial entrepeneur, ni de nada por el estilo. El post de hoy trata del trabajo. Del trabajo bien hecho.

En esto de la informática y el desarrollo de software es muy fácil acomodarse. Has estado trabajando con unas tecnologías durante muchos años, y eres ya un experto. Los problemas se resuelven rápidamente, y hay pocas cosas que no puedas solucionar. Es lo que comúnmente se denomina comfort zone.

Y así uno se puede echar años, ¿y por qué no? Estos días viene a la empresa un experto en DB2. Con sus 59 años tiene más de 20 de experiencia en DB2. Cientos de historias a sus espaldas y varios libros. Nadie le puede descubrir nada sobre este gestor de bases de datos. Lo sabe absolutamente todo, y con toda esta experiencia lo cierto es que uno puede llevar una muy buena y tranquila vida como consultor.

Es muy difícil salir de la zona de confort. En mi opinión personal, hacen falta dos cosas fundamentales: valentía y pasión por esta profesión. Valentía para apartarse de lo obvio, de lo que ya conocemos, para desviarse del camino sencillo y meterse por ese sendero oscuro y sombrío que nos lleva a lo inseperado; Y pasión. Pasión por aprender cosas nuevas, por descubrir nuevos modos de hacer las cosas, por reencontrarse con aquello que te hizo el profesional que eres hoy en día.

Si a esa valentía, y a esa pasión, le sumas esfuerzo, dedicación, y trabajo bien hecho, tanto da a lo que te dediques porque siempre obtendrás frutos. Y yo no me cansaré de decir que a los chicos de Linking Paths les sobran todas esas cualidades, y muchas más.

¿Cuántas personas conocéis, y no voy a decir en España si no que digo en el mundo, que hayan pasado, de ser referencia dentro del mundo de Java, a ser referencia de Ruby on Rails? Quizás vosotros conozcáis a alguien, pero yo sólo conozco a los chicos de Linking.



Me parece que aún fue ayer cuando estos chicos estaban organizando lo que en su momento fueron los eventos más importantes de Java en España, o ayudando a miles de personas a aprender, creando una comunidad que todavía persiste y que sigue siendo referencia. Y con ese recuerdo todavía fresco, la semana pasada me llevaba la alegría de ver que esta misma gente recogía el premio a Proyecto del año 2008 por Tog en la conferencia Rails.

No sé vosotros lo que pensáis, pero yo creo que este tipo de cosas no pasan por suerte. Alberto, Roberto y Aitor, para mi, este premio es mucho más que un préstamo, es un reconocimiento al trabajo. Un reconocimiento al trabajo bien hecho.

¡Enhorabuena!

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?

Sonar, gestión de calidad del código y Open Source

Un compañero de trabajo me enseñaba hace unos días una herramienta Open Source que no conocía y que me ha parecido realmente muy buena. Se trata de Sonar, una herramienta de gestión de la calidad del código fuente para Java.

La idea es muy simple. Sonar consiste en un servidor web y una base de datos donde se van almacenando métricas sobre nuestro código. La parte cliente está basada en Maven, e integra una serie de productos de sobra conocidos, como son Cobertura, PMD o Checkstyle, de forma que cuando hacemos una build Sonar envía todos estos datos al servidor donde se almacenan y agregan para mostrar información útil sobre el proyecto.



La instalación es muy simple y en su web tienen un tutorial que te muestra como usar Sonar en 2 minutos. Ahora bien, doy fe que para proyectos grandes puede dar algunos problemas. Yo lo he probado en el trabajo y me he encontrado con algunas dificultades:

• La base de datos por defecto (Derby) se queda pequeña fácilmente, así que tuve que utilizar un Oracle Express que tenía por ahí.


• Si usas Maven 2.0.9 hay que eliminar toda extensión cargo-webdav que tengamos en los poms ya que si no se producirá un error.

El proyecto tiene un servidor de demo con estadísticas de proyectos conocidos, pero para demostrar que no es truco me decidí a probarlo con jLibrary, y a mostrar estadísticas para verguenza personal :)

Lo único que hay que hacer es arrancar el servidor de sonar, irse al directorio del proyecto y en vez del típico mvn clean install ejecutar mvn org.codehaus.sonar:sonar-maven-plugin:1.4.2:sonar. Muy sencillo.

Así que vamos allá, lo primero sería la compatibilidad con reglas, buenas prácticas y convenciones de código. Ahí no hemos acabado demasiado mal:



Que por cierto, si navegas por los paquetes te lleva a nivel de clases y si pinchas en una clase te muestra el código fuente coloreado y con tooltips mostrándote cuales son los problemas. Muy útil y muy sencillo.




Entrando ya en temas escabrosos, podemos irnos a la pestaña de métricas que es mucho más interesante. Argh! 10% de cobertura y 12% de test success. Shame on me! La verdad es que ahí se muestra uno de los problemas del proyecto y es que los tests están diseñados para ejecutarse desde una única suite y no individualmente, por lo que la mayoría fallan y por lo tanto hay muy poca cobertura. La excusa para esto siempre fue el tiempo de ejecución de los tests (para que crear un documento en 100 tests si ya lo hago en uno), y acelerar un poco las pruebas. Pero bueno, es una muy mala práctica y no es algo que le pueda recomendar a nadie.



Y en las estadísticas Sonar te muestra también la evolución temporal de todas las métricas. En mi caso como sólo ejecuté Sonar una vez, no hay nada que ver, pero la siguiente imagen muestra la evolución de Wicket:



Más métricas por aquí...




Bueno, y ya quedaría la compatibilidad con reglas:



Y la complejidad de las clases:


Como veis esta herramienta muestra mucha información, y super sencilla de utilizar. Definitivamente pasa a mi caja de herramientas.