Entrevista con Marc Palmer

jueves 04/10/2007

Refactr, una compañía norteamericana de consultoría, ha publicado en su blog esta magnífica entrevista a Marc Palmer, colaborador en el equipo de desarrollo de Grails. A continuación reproducimos la entrevista traducida al castellano, agradeciendo a los autores que nos hayan dado su autorización para hacerlo.

REFACTR: Dejaste la escuela bastante joven (a los 16 años) para dedicarte a programar. ¿De qué forma crees que esto te ha convertido en un mejor profesional? ¿Cómo crees que te ha limitado (si es que lo ha hecho)?

MARC PALMER: Lo dejé a los 16 porque estaba desesperado por salir de la escuela. Lo encontraba muy aburrido, y estaba impaciente por empezar a trabajar (con ordenadores) ya que había estado programando desde los 11 años, y me escribía demos para el ensamblador del 68000 del ATARI ST y manejando interrupciones de hardware etc por las noches mientras en la escuela me enseñaban BASIC.

En cuanto a "ser mejor profesional", creo que la ventaja es simplemente tener 5 años más de experiencia comercial que otra gente de mi edad que fué a la universidad. Eso me permitió convertirme en freelance con apenas 20 años.

Quizá la limitación vino ocasionalmente en que algunas compañías utilizan el "Tiene que ser licenciado en informática" como un filtro estúpido para los candidatos a un puesto, pero he estado muy poco tiempo sin trabajo en los últimos más de 10 años. Siempre he sido autodidacta y siempre he tratado de hacer mejor las cosas. Se puede decir que soy muy perfeccionista.

R: ¿Cómo te involucraste en el desarrollo de Grails, y por qué?

MP: A principios de 2006 comencé a desarrollar algunos de los sites para la marca Pepsico UK, usando mi propio framework basado en Spring y Groovy. Era rápido y sencillo, pero cuando un poco después tuve la oportunidad de probar Grails en condiciones, caí rendido inmediatamente, sobre todo por GORM. Sin embargo en aquél momento aún le faltaban algunas cosas que podrían hacer el desarrollo aún más sencillo, así que decidí hacer algunas pequeñas contribuciones para aumentar mi compresión sobre el framework, de forma que pudiera utilizarlo para construir sites en algún momento, lo que ocurrió en Enero de 2007.

R: En el Grails eXchange 2007 darás una charla titulada "Grails en el Mundo Real". ¿Puedes darnos un avance de lo que incluirá la charla?

MP: La charla será de bastante alto nivel, hablando de algunos de los 5 sites para marcas de alto nivel que he desarrollado con Grails este año. Cubrirá algunos de los aspectos básicos de Grails así como algunos trucos prácticos y decisiones de diseño sencillas que se emplearon al construir algunas de las funcionalidades de los sites. No se trata de un "vamos a escribir esta aplicación delante de vosotros", estoy seguro de que va a haber muchas charlas de ese tipo, y creo que lo que la gente quiere oír de mi en este momento tiene más que ver con implantar comercialmente aplicaciones Grails.

R: ¿Hay algo que todos los chicos de Groovy/Grails de este lado del charco [NT: Refactr es una compañía de EEUU] ignoren sobre lo que está ocurriendo en UK y otras partes de Europa?

MP: Bueno, para ser honesto, vivo bastante recluído. Con el trabajo, el desarrollo de Grails, el trabajo en nuestra casa y el jardín, y estar con mi mujer y mis dos hijas, no tengo mucho tiempo para formar parte de "la escena". Parece que Groovy está recibiendo bastante buena covertura en Alemania, sin duda gracias al gran trabajo de Dierk Koenig y Sven Haiges. Por aquí en UK generalmente pienso que la gente es bastante lenta para subirse a la la ola. Las empresas son generalmente muy conservadoras. Lo más importante de lo que la gente quizá no se dé cuenta es la cantidad de trabajo que Graeme (Rocher) pone en Grails y Groovy. El chaval es un demonio programando [NT: "a coding demon"]


R: ¿Qué nuevas características te gustaría ver en Groovy?

MP: En este momento nada especial en cuanto a funcionalidades. Estaría bien tener evaluación perezosa real de las GStrings, para poder hacer que el logging fuera más elegante (no haría falta el "if (log.traceEnabled)")

Lo que quiero de Groovy es una alta covertura de código en los test de regresión, y una documentación estelar. Hay demasiados detalles de Groovy atrapados en la mente de los desarrolladores. Quiero una referencia definitiva del lenguaje, no un puñado de páginas wiki juntas. En los días en los que estaba aprendiendo Pascal por mi cuenta, "Oh! Pascal" era un poco como el "Groovy in Action" de Pascal, pero fueron los manuales de Borland Turbo/Object Pascal con sus detallados diagramas de gramática y su excelente estilo los que me permitieron utilizar cada característica del lenguaje y entender cada caso particular.

Me encanta Groovy, pero en ocasiones siento que es una catacumba tenebrosa de "casos particulares", y a veces el principio de mínima sorpresa se viola, y un monstruo salta y te hace cagarte encima! Las cosas están mejorando, pero Groovy dispone de menos recursos de los necesarios. Alguien debería invertir en el sueldo de un autor con experiencia que coordinase y escribiese documentación definitiva para el lenguaje. Los wikis están bien, pero son lo que haces cuando no se te puede molestar, o no tienes tiempo para escribir la documentación tú mismo.


R: ¿Qué lecciones has aprendido de tus experiencias con grandes sistemas Grails como PepsiCo y Tropicana, en cuanto a los éxitos y las dificultadas de utilizar esta tecnología en proyectos a gran escala?

MP: Dificultades... bueno, estuvimos "en la cresta de la ola" una temporada en tiempos de Grails 0.4, y hubo algunos momentos dolorosos, fundamentalmente por la dificultad de convencer al "Sr. Jefe" de que estábamos haciendo lo correcto. El rendimiento de las GSPs supuso un problema durante un tiempo, pero Graeme y yo hicimos algo de "profiling" e introdujimos algunas optimizaciones, aunque hay más que mejorar en el futuro. Los formularios multipágina fueron un pequeño dolor en aquel momento, porque Grails Flows no estaba implementado aún.

En cuanto a los éxitos... bueno, tuvimos 2 sites lanzados a principios de febrero después de empezar de cero, y estábamos únicamente un programador HTML y yo para trabajar en el código. En Junio teníamos 5 sites desplegados, todos migrados gradualmente de 0.4 a 0.5 y a 0.6 suavemente. Fuimos capaces de incorporar nuevas funcionalidades fácilmente, incluyendo un blog, feed de tiempo atmosférico, un CMS "no frills" para elementos de contenido específicos, informes de gestión sobre los datos almacenados por los sites (¡el criteria builder es la caña!), gráficas de gandadores de sorteos, seguimiento de puntiaciones, e-cards y más. A veces tuvimos días duros de trabajo, en los que una funcionalidad tiene que ponerse en producción coordinada con la promoción de lanzamiento de un nuevo producto, y nunca fallamos.

A Seb (nuestro programador HTML/PHP) le encanta Grails y los layouts GSP. Ahora podemos prototipar rápidamente, localmente y reproduciblemente gracias al servidor web incorporado de Grails, podemos hacer un checkout de cualquier aplicación desde el SVN en un servidor nuevo para el departamento de pruebas/QA y "simplemente funciona". Ciertamente ha ayudado a mejorar nuestros métodos de trabajo.

R: En los últimos años, algunos programadores Java se han pasado a Ruby on Rails. ¿Crees que a medida que Grails madura, muchos de esos programadores se pasarán a Grails? O dicho de otra manera, ¿qué necesita Grails para atraer de vuelta a esa gente?
 
MP: Grails está ganando inercia. Pasarse a Rails más un "acto de fe" que pasarse a Grails, así que yo pienso que a medida que aumente el conocimiento de Grails disminuirá la hemorragia de gente Java hacia Rails. En términos de recuperar a la gente, creo que volverán en cuanto se dén cuenta de que sus APIs favoritas están accesibles instantáneamente, y que pueden tener las herramientas y la escalabilidad a las que estaban acostumbrados en JAva, pero sin ninguno de los dolores de cabeza.

Simplemente necesitamos seguir puliendo Grails.

R: Con Grails 1.0 a la vuelta de la esquina, hay una espectación de que la adopción de Grails aumente rápidamente por la percepción de madurez de la tecnología. ¿Qué opinas de esto? ¿Qué es lo que más te gusta de Grails actualmente?


MP: Sí, estoy de acuerdo en que la 1.0  es crucial. Es fundamentalmente sicológico, pero "0.6" suena muy... pobre comparado con "1.0". También es nuestra garantía de que no romperemos nada más en el futuro. Eso es lo principal para mucha gente: con nuestros 5 sites no me gustaba migrar cada uno con cada nueva versión, aunque fuese un gran avance. Eso está bien para tus proyectos de juguete, pero cuando tienes un cliente que paga por tu tiempo y tienes una fecha de entrega, actualizar a una nueva versión del framework es una idea poco atractiva en el mejor de los casos.
 
Lo que más me gusta de Grails actualmente es que todo va a venir a la vez. Todas las piezas fundamentales que quería ver: flows, configuración razonable, control sobre el cacheo y mapeo en el ORM, plugins, mejor documentación... Vamos a limpiarlo todo y pulir las aristas para que no solo sea un aumento de productividad, sino que tenga un aspecto coherente y diseñado. La misma diferencia que hay entre un PC clónico y un iMac.

Ah!, y también están los planes de futuro que tenemos, para algunos plugins geniales y otros temas...

R: Dar el salto para intentar ayudar con el proyecto Grails puede parecer una tarea abrumadora para algunos. ¿Cuál es la mejor manera de involucrarse para la gente que quiera ayudar?

MP: Si, yo estuve abrumado al principio. La mejor manera de involucrarse, creo yo, es revisar los documentos para desarrolladores que hay en su web, que te darán una primera impresión, y después elegir alguna incidencia sencilla en el Jira y navegar por el código hasta donde tú creas que esté el problema (y preguntar en la lista de desarrollo por el punto de partida). A mí me costó mucho al principio porque, aunque la IoC está muy bien, encuentro que puede hacer las aplicaciones muy difíciles de entender, porque en ocasiones no está claro cual es el punto de entrada, en qué orden ocurren las cosas, y eso. Para ser honesto, aún hay algunas cosas que hacen que me rasque la cabeza, y no tengo tiempo para investigarlas a fondo (el flujo de ejecución durante la compilación y renderizado de las GSPs, por ejemplo).

Lo bueno de Grails es qeu la mayor parte de la funcionalidad principal tiene muy buena covertura de código para pruebas. Así que siempre que ejecutes todas las pruebas con éxito antes de hacer commit, puedes estar bastante seguro de que no has roto nada. Esto es pruebas unitarias en su mejor expresión, porque puedes meterte a trabajar sin preocuparte demasiado de romper otras cosas.¡ No hay nada más embarazoso que provocar un "Build Failed" en la integración contínua que cite tu aportación! Lo sé porque lo he hecho algunas veces
 
Si todos los test han pasado correctamente y aún así se rompió algo, ¡asegúrate de escribir las pruebas para probar el fallo ANTES de resolverlo! Nos encantan las pruebas unitarias. Cuantas más mejor. Un proyecto tan complejo como éste fracasaría rápidamente sin ellas.

R: Tienes alguna expectación/esperanza/predicción para el desarrollo con Grails en 2008 aparte de lo que está específicamente en el plan de trabajo (nuevas funcionalidades, etc)?

MP: Creo que 2008 verá una rápida adopción, y de ahí vendrán correcciones de fallos y correcciones de compatibilidad y rendimiento de la versión 1.0, y probablemente una o dos versiones 1.X con nuevas funcionalidades.

Por otro lado, espero que ocurra una explosión en el desarrollo de plugins de gran calidad. Una vez que puedes integrar un blog, un foro, un sistema de autorización en una aplicación, y simplemente colgarla y que funcione, para muchos usuarios esto va a ser decisivo. También lo hará más accesible para el mundo no-empresarial. Yo soy un firme creyente, y mi postura actual es que Grails es brillante para consturir "sitios web", no simplemente "aplicaciones web"