viernes, diciembre 19, 2008

Hadoop@Facebook

viernes, diciembre 19, 2008 por Martín


Los que trabajan en el mundillo de Hadoop seguro que ya conocen que Facebook hacía bastante uso de esta herramienta. Yo, por mi parte, me encontré la semana pasada con un conjunto de notas en las que se comenta el uso que Facebook esta haciendo de esta herramientas. Las notas son ya de Junio de este año, asi que como comento, alguno ya las tendrá más que vistas.

La verdad es que las notas son bastante impresionantes. Aquí va un pequeño resumen:

  • Facebook tiene una enorme cantidad de datos históricos, fruto de las decenas de millones de usuarios y el mas de un billón(americano) de páginas vistas por día, que necesita almacenar y procesar.

  • Comenzaron a utilizarlo en el 2007 con cierto escepticismo, pero parece que pronto se probó útil tras realizar algunas aplicaciones internas de proceso de datos. Alguna como Facebook Lexicon, una herramienta para contar la ocurrencia de palabras en los muros de los usuarios, ha visto la luz externamente.

  • Facebook tiene ahora mismo desplegados múltiples clusters de Hadoop, constando el más grande de 250 núcleos y 1 Petabyte de espacio en disco.

  • Cada día cargan sobre 250Gb de datos comprimidos (2 Terabytes descomprimidos) en Hadoop, y hay cientos de trabajos que se encargan de explotar estos datos.

  • Las aplicaciones realizadas han ido evolucionando de aplicaciones estadísticas hacia aplicaciones más interesantes como la detección de spam o el determinar la calidad de las aplicaciones de terceros.

  • Hadoop se ha mostrado como simple de utilizar y de aprender. En Facebook, los desarrolladores son libres de elegir el lenguaje que quieran para sus aplicaciones con Hadoop. El acceso a datos lo realizan utilizando un subconjunto del lenguaje SQL, lo que hace mas sencillo su manejo.

  • Con el tiempo han ido añadiendo algunas funcionalidades propias de un sistema de data warehousing que han desembocado en un framework llamado Hive desarrollado por Facebook pero que ahora es un subproyecto de Hadoop.



Otras notas mias sobre Hadoop.

lunes, diciembre 15, 2008

Jobsket gana la Beca Alzado 2008

lunes, diciembre 15, 2008 por Martín


Que alegría hoy al ver que Jobsket ha ganado la Beca Alzado 2008.

En Octubre anunciamos públicamente Jobsket e iniciamos el proceso de registro. Desde entonces hemos estado trabajando sin parar (en nuestros ratos libres). Hace unos meses cuando anunciaron la Beca Alzado, que por cierto es una iniciativa fenomenal, no le dimos demasiada importancia porque el producto todavía estaba muy, pero que muy verde. Pero poco a poco fue mejorando y llegó un momento en que necesitábamos, sí o sí, el evaluar nuestra idea.

Por eso nos presentamos a Jobsket, para que no sean sólo nuestros amigos y conocidos los que nos digan que lo que estamos haciendo es muy interesante. Y parece ser que alzado.org y la gente que está detrás (Luis Villa, César Martín y Eduardo Manchón) han considerado que sí, que puede funcionar. Por eso estamos enormemente agradecidos y creo que este premio puede ser un empujón mediático y de moral realmente importante.

Seguro que los que leéis esto ya estáis suscritos a la beta, pero si no lo estáis no se a que estáis esperando :-)

Por cierto que hemos creado el blog de Jobsket donde tambien hablamos un poquillo del premio. No se os olvide añadirlo a vuestros RSS :)

domingo, diciembre 14, 2008

Un context ad de Domingo perfecto

domingo, diciembre 14, 2008 por Martín

Repasando mis lecturas domingueras me he encontrado con un chiste de Domingo (via otra vez ReadWriteWeb). Trata sobre Facebook y como hoy por hoy es posible que te enteres antes por Facebook de lo que pasa en tu vida que por la gente con la que vives.



El chiste tiene su gracia, pero para mi lo realmente bueno es el anuncio de PlentyOfFish. ¡La asociación entre el anuncio y el post es brillante! De hecho me ha hecho mirar en el contenido del feed a ver como diablos lo han hecho, y lo único que encuentro serían las referencias a FriendFeed o Facebook en el texto del post, o el propio texto en la imagen. No sé si es casualidad o no, pero si no lo es entonces está claro que en el equipo de FeedBurner hacen los deberes.

Google publica un libro para desarrolladores sobre seguridad en navegadores web

domingo, diciembre 14, 2008 por Martín



Últimamente Google ha estado cogiendo algo de mala fama por reusar contenido libre, atacar todos los frentes posibles, pero no devolver nada a la comunidad. Pues bueno me entero via ReadWriteWeb de que acaban de publicar un libro titulado Browser Security Handbook bajo licencia Creative Commons 3.0.

El autor del libro es Michael Zalewski y su contenido está principalmente orientado hacia desarrolladores web. El libro consta de tres partes, la primera comenta los fundamentos de los navegadores web en cuanto a gestión de URLs, soporte de JavaScript, CSS, ett. La segunda parte trata sobre la seguridad en los navegadores web y procede a comentar diferentes mecanismos y los compara para diferentes navegadores; por último, la tercera parte comenta algunos sistemas experimentales de seguridad y características especificas de algunos navegadores web como Internet Explorer o Mozilla.

Parece un libro a tener en cuenta. Si os interesa el tema, y no lo habéis hecho ya, pasaros también por mis posts sobre OWASP que contienen entradas con información similar.

martes, diciembre 09, 2008

¿Escala Java? Entrevista a Todd Hoff.

martes, diciembre 09, 2008 por Martín

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.

lunes, diciembre 08, 2008

Cuenta gratuita en ExternalTest.com para los lectores de Pensamientos Agiles

lunes, diciembre 08, 2008 por Martín


Este es un post que me hace mucha ilusión ya que es absolutamente la primera vez en la que alguien se pone en contacto conmigo para regalar algo a través de este blog. Todo viene a raiz de este post y este comentario.

El autor del comentario es Enrique Dominguez y muy amablemente me ha ofrecido una cuenta grauita para su producto ExternalTest y, lo que es mejor, una cuenta grauita para todo lector de este blog al que le interese. Lo único que tenéis que hacer para reclamarla es registraros en ExternalTest y enviar un email al usuario Enrique en su dominio externaltest.com (supongo que entendéis esto, el que no lo entienda es que no merece la cuenta :P) simplemente mencionando en el subject "BRIGOMP".

Atención, es importante que enviéis el email con el mismo email que uséis para registraros. El tipo de cuenta es "gratuita ilimitada", por lo que no os caducará jamás y podéis configurar hasta tres tests diferentes. Si tenéis requisitos más complejos podéis contactar con Enrique.

ExternalTest es un producto muy interesante. La funcionalidad es la que se podría esperar en este tipo de productos, y sirve para monitorizar servicios, no sólo HTTP sino que muchos otros protocolos como FTP, POP3, DNS, etc. Además tiene un modo de análisis de rendimiento que te viene a ofrecer los mismos datos que explicaba en el post sobre webpagetest. Repitiéndome en lo comentado en dicho post, el mayor atractivo es la ejecución de tests desde diferentes localizaciones lo que nos permite evaluar el impacto de la latencia sobre nuestras páginas web.



ExternalTest es un servicio muy orientado al mundo empresarial pero cualquiera que tenga una página web le puede sacar partido. Yo mismo se lo he sacado hoy mismo cuando mi servidor se ha caido y he recibido el email de alerta. Hay otros servicios como Pingdom que vienen a hacer lo mismo pero por lo que me comenta Enrique, los servicios adicionales que ofrecen son bastante más limitados:

"Pingdom es un servicio similar en lo básico, nosotros tenemos productos más avanzados para empresas como XTbox o XTvirtuabox que permite a nuestros clientes contar con todas las capacidades de monitorización en entornos locales (esto lo usa por ejemplo Prisacom en España para probar las latencias existentes entre sus accesos locales y los realizados desde sudamérica, por ejemplo) o XTsec, que permite realizar de manera automatizada pruebas de vulnerabilidades conocidas sobre tu paltaforma..."


Muchas gracias Enrique por el detalle.

sábado, diciembre 06, 2008

Lets pull a "sickie"

sábado, diciembre 06, 2008 por Martín

Es Domingo, así que toca chiste. Rompo por un momento la temática habitual de este blog para comentar algo que, por lo que he visto, nos choca a todos los españoles trabajando en irlanda. Se trata de los "Sick Days", o como diríamos nosotros "estoy enfermo, no puedo ir a trabajar".

Aquí en Irlanda, tomarse un día libre por enfermedad es realmente sencillo. Cada empresa se comporta de manera diferente frente a los sick days, aunque por lo general se pagan. Cada empleado, tiene derecho a cogerse dos días sick consecutivos sin que la empresa pueda pedirle ningún justificante, cosa que sería considerada como acoso. En la práctica, muchas empresas ni se preocuparían de comprobar nada incluso si un empleado se coge muchos más días, aunque quizás ahora con la crisis económica les interese un poco más.

Pues bueno, con todo este background informativo os podréis imaginar que los irlandeses tienen una extraña tendencia a caer enfermos. Especialmente en Viernes y en Lunes, mira tú que casualidad. Y es más, mira que esta extraña enfermedad suele afectar sólo a los que están fijos en las empresas, porque jamás he visto enfermar a alguien que cobre por días :)

Hablando con amigos irlandeses, todos coinciden en lo mismo, y es que, y a mi esto es lo que me parece más increible, ven estos sick days como un derecho que ellos tienen para que si un día les duele la cabeza, están resacosos, o no se encuentran bien para trabajar, o simplemente sus niveles de desidia se han disparado, pues puedan tomárselo libre. El argumento principal es que no van a ser productivos porque se sienten como enfermos. ¡Vaya cara vamos! :)

Pero bueno, aquí lo más importante es tener sentido del humor, y saber reirse de uno mismo. Y yo cuando veo este anuncio de Meteor en la tele es que me hace muchísima gracia. No sé que tal será de entendible ya que uno ya se ha acostumbrado al acento irlandés, de hecho sólo ver unos tipos vestidos de reno con acento irlandés barriobajero ya tiene su cierta gracia. Ahí os lo dejo a ver si os gusta.



Ay, my heads ringing :)

viernes, diciembre 05, 2008

Mapa de Startups: España vs. Irlanda

viernes, diciembre 05, 2008 por Martín

Los de Crunchbase han creado una aplicación de Google Maps muy chula, CrunchVision, que muestra un mapa de Google donde se ven las startups que están registradas en su base de datos.



En el mapa del mundo se puede apreciar claramente cuales son los hervideros de startups. La zona de California con 2109 compañías registradas mientras que la costa Este se va a las 1815. En Europa, la zona central acumula 965 startups de las cuales 485 se concentran en el área Londres/Paris. España se posiciona bastante en la cola con un total de 58 startups registradas. Esto no quiere decir que sólo existan 58 startups, ni mucho menos, significa únicamente que tan sólo esa cifra se ha registrado.

Echando un vistaza al mapa de España se puede ver lo que todos nos esperamos, y es que la mayoria se concentra en torno a Madrid y Barcelona. 27 compañías en la ciudad Condal.



Por curiosidad y para los más vagos, un par de capturas de la localización de algunas de las startups en Barcelona y Madrid.







Si nos vamos a Irlanda, un país con alrededor de la novena (contando irlanda del norte) parte de habitantes, pues resulta que está muy, pero muy cerca en número de startups registradas. Un total de 49 compañías, que son tan sólo 9 menos. O sea que tenemos una compañía menos por cada 9 millones de habitantes. Vaya estadísticas que me saco :-)



Haciendo un poco de zoom, pues lo esperado, la mayoría se concentra en el centro Dublín donde hay unas 28 compañías registradas.



Esto no es ningún tipo de estudio ni nada por el estilo ni se deben sacar conclusiones precipitadas, pero ¿por qué no tenemos más compañías registradas? Mi opinión personal es que es un tema de falta de nivel de inglés y concentración exclusiva en el mercado local. Dos factores que limitan enormemente las exportaciones de software. Pero esta es simplemente mi opinión. ¿Cuál es la vuestra?

jueves, diciembre 04, 2008

Latencia, monitorización de redes y microbursts.

jueves, diciembre 04, 2008 por Martín


El software para operar en mercados de valores es realmente apasionante. Desde fuera puede parecer muy aburrido pero una vez que estás dentro descubres que se trata de una lucha constante por la optimización. Minimizar la latencia es fundamental. En ese mundo, el que consigue que sus operaciones lleguen antes al mercado es el ganador. Y ahí cualquier cosa, ya sean switches, routers, servidores de aplicaciones o esa clase Java que está al final de toda la cadena y que envía el mensaje a la cola de MQ son importantes.

Todas estas cosas se multiplican por 1000 cuando estamos en una época de incertidumbre, y que en cualquier momento el mercado puede bajar un 5% o una moneda puede desplomarse frente a otra en cuestión de minutos. Muchas empresas emplean herramientas de monitorización para tratar de descubrir patrones de operación en el mercado. Estas herramientas pueden ser internas, como Wily Introscope con la uqe he trabajado y que no puedo más que recomendar, o externas.

Las herramientas internas tienen la ventaja de integrarse muy bien con el stack de la aplicación y de ofrecer información bastante específica, como tiempos que tardan en procesarse mensajes en colas, o el tiempo que tarda en ejecutarse un método determinado, etc. Sin embargo el inconveniente es que añaden una carga extra de proceso que irremediablemente impacta en la latencia, por lo que al final te ves obligado a desplegar una versión con monitorización mínima en producción; aunque son fenomenales para desarrollo, ya que ahí puedes permitirte monitorizar muchos más datos.

Por otra parte hay herramientas externas que funcionan ajenas a las aplicaciones y servidores y que se basan simplemente en capturar el tráfico de las redes y en analizar sus patrones para proporcionar información, generar gráficos y lanzar eventos a partir de ésta. Dentro de este sector se encuentra Endace. Por cierto que si os interesa el tema, Corvil es una empresa irlandesa que está teniendo también bastante éxito en este mundillo.

En Low Latency han publicado un pequeño podcast/entrevista de siete minutillos que explica algunas de estas cosillas y que es bastante ameno de escuchar. Es un poco publicitario, porque el entrevistado es Paul Doyce, Technical Manager de Endace, pero se lleva bastante bien.

También os lo podéis descargar directamente desde este link.

Photo via travel_aficionado@Flickr.

miércoles, diciembre 03, 2008

Probando el rendimiento de páginas web con webpagetest

miércoles, diciembre 03, 2008 por Martín

El otro día por una lista de correo a la que estoy suscrito descubrí
webpagetest
(dos post seguidos de descubrimientos, esto ya parece el blog de "Martín el Descubridor"). Lo he estado probando y la verdad es que es una herramienta espectacular. Fundamental para el análisis de rendimiento de páginas web.

Por una parte, nos permite evaluar el impacto de la latencia en nuestra aplicación web, ya que podemos probar como se cargarían las páginas desde Estados Unidos y Nueva Zelanda. Una pena por cierto que no tengan ningún host en Europa.

Por otra parte, los informes que te muestra son realmente completos. Por defecto, webpagetest carga la página que le mandas dos veces. Una para evaluar la carga inicial, y dos para evaluar como funcionan las cachés. Lo que esperaríamos normalmente es que la segunda ejecución sea mucho más rápida que la primera. Veamos el resultado si cargamos por ejemplo la página de Twitter:



Ok, si hacéis clic en la imagen lo veréis mejor. Han sido 4.5 segundos. Algo lentillo diría yo, aunque cierto es que es un servidor con carga y que muestra bastantes cosillas en la página principal. Aún así, una de las cosas que me llama la atención es la cantidad de bloques naranjas que se ven. Los bloques naranjas son establecimiento de conexión, y no deberían suceder tan a menudo si tu servidor permite el establecimiento de conexiones persistentes, algo por otra parte bastante común en la mayoría de servidores. Patrick Meenan, el creador de webpagetest, lo explica muy bien en este post.



Esta segunda imagen nos da una mejor idea de como funciona twitter. Bastante caché, uso de ETags, librerías javascript comprimidas, imagenes comprimidas y no CDN. Interesante.



En la imagen superior se observa que la recarga de la página ha dado unos mejores resultados, aunque todavía se aprecia que se ha empleado un segundo entero en descargarse la librería de lightbox. Seguro que hay mucho que mejorar por ahí. Se sigue también apreciendo que el servidor no mantiene conexiones persistentes.

Y bueno, a parte de todo esto webpagetest te ofrece un informe en formato texto con todo lo que se debe arreglar.


Mmm, por cierto, que se me olvidaba una cosa. ¿Es importante la latencia? Probemos a cargar Twitter desde Nueva Zelanda:



7.2 segundos. 3 segundos más que desde los Estados Unidos. Pobres amigos de las antípodas que tienen que soportar estas cosas :)

Lo que no acabo de ver es por que aquí sí que se utilizan conexiones persistentes. O será que quizás el servidor no lo muestra... ¿álguien que me ayude con esto?

El servidor de Nueva Zelanda nos ofrece bastante detalle sobre las diferentes peticiones, y como veis todos los recursos están en Estados Unidos, así que se tendrá que notar el efecto del límite en la velocidad de la luz:



Bueno, no sé lo que os parece a vosotros pero a mi me parece una herramienta super útil.

martes, diciembre 02, 2008

Utilidad para crear imágenes de progreso para tu aplicación web

martes, diciembre 02, 2008 por Martín

Estaba necesitando un gif animado para mostrar una página de progreso y me he encontrado con esta pequeña utilidad para crear las típicas imágenes de progreso que se pueden encontrar por todas partes.

Por si a a alguno le resulta útil.



miércoles, noviembre 26, 2008

La build y la botella

miércoles, noviembre 26, 2008 por Martín



En nuestro trabajo tenemos una botella como la de la foto. Bueno, en realidad es muuuuucho más grande. De un metro más o menos. Es de publicidad de Heineken, de esas de plástico. Tenemos implantado un Cruise Control bastante básico, pero que cumple su cometido. Cuando alguien rompe la build porque ha hecho commits de funcionalidad inacabada, o funcionalidad que rompe los tests existentes, o se ha olvidado de configurar dependencias, pues tiene que poner un euro en la botella.

La verdad es que esta medida tan simple tiene unos efectos muy curiosos. El más obvio y evidente es que nadie quiere romper la build, ya que aunque sólo sea un euro, nadie quiere regalarlo. Así que los desarrolladores somos mucho más cuidadosos con lo que subimos y con no romper nada de lo que hay ya hecho.

Otro efecto muy beneficioso es la cura de modestia. A nadie le gusta ser el que rompe la build. Hoy, un chico nuevo ha roto la build por primera vez, y le tocó poner el euro correspondiente. El hombre fue cabizbajo a depositar el euro ante la guasa general que se suele montar. No es que este hombre sea inmodesto, ni mucho menos, pero es que la sensación que tuve yo la primera vez que rompí esta build es de cura de modestia. Los desarrolladores tendemos a que se nos suba el ego muy rápidamente. Y siempre viene bien que alguien nos baje los humos, aunque sea el Cruise Control, y que tengamos que darnos un paseito ante la guasa general del resto del equipo mofándose (amistosamente) de que te toca apoquinar.

Además la gente es muy legal y hoy otro chico dejaba un euro por la build que había roto ayer. Y es que a uno tampoco le gusta quedar debiendo nada, aunque sea a la botella.

La verdad es que para la cantidad de gente que estamos trabajando en el equipo, y siendo diferentes equipos trabajando en diferentes componentes interconectados, yo personalmente tengo clarísimo que la salud de la build se debe en gran medida a los efectos de esa botella.

¿Estáis usando integración continua en vuestro equipo? Mi consejo, usar una botella. Hará de la build algo más estable y además añade un toque de diversión al día a día. Ah, y a final de año, pues siempre se puede hacer una cena con el dinero de la botella. ¡Faltaría más!

Foto by ^Vanessa^@Flickr

martes, noviembre 18, 2008

Cuando los premios son al trabajo bien hecho

martes, noviembre 18, 2008 por Martín


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!

jueves, noviembre 13, 2008

FOWA 2009 @ Dublin

jueves, noviembre 13, 2008 por Martín


Vaya sorpresa me llevé ayer al leer este post de Fergus Burns en el que anunciaban que este 6 de Marzo se celebrará una edición de FOWA 2009 (Future of Web Applications) en Dublin.

Por lo que veo en la lista de Speakers viene gente como Mike Butcher de TechCrunch, Blaine Cook ex-Twitter, David Heinemeier de 37 Signals/RoR, Simon Willison co-creador de Django, Matthew Ogle de Last.fm, y los chicos de Contrast, una empresa local que tiene muy buena pinta. No está nada mal.

Todo esto por el módico precio de 115 euros. ¿Por qué diablos tienen que pasar estas cosas cuando uno está pensando en volver a casa?

martes, noviembre 11, 2008

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

martes, noviembre 11, 2008 por Martín


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.

lunes, noviembre 10, 2008

Las cinco cosas que menos me gustan de Grails

lunes, noviembre 10, 2008 por Martín



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?

viernes, noviembre 07, 2008

Configurando Hudson para proyectos Grails

viernes, noviembre 07, 2008 por Martín

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.

domingo, noviembre 02, 2008

Scrum: Me encantan las Sprint demos

domingo, noviembre 02, 2008 por Martín


La verdad es que cuanto más trabajo con Scrum, más me gustan las Sprint demos. Como la mayoría sabéis, Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde se va implementando funcionalidad que se ha decidido al comienzo de cada una de esas iteraciones. Durante los diferentes Sprints se pueden ir lanzando releases, y una vez finalizados todos los Sprints hemos terminado el desarrollo.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminado una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.

Una de las cosas más curiosas de la demo de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. La gente pasa a centrarse durante una semana completa en sacar la demo adelante, y durante este tiempo pasan muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar a los desarrolladores durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que después habrá que recodificar. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demo:


  • Se realiza un esfuerzo por integrar toda la funcionalidad creada durante las últimas semanas en un formato compacto y demostrable al cliente final lo cual revela numerosos bugs y problemas imprevistos. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras fases de desarrollo, mientras que en una metodología de software tradicional estos errores se detectarían al final y serían mucho más complejos de resolver.

    Los desarrolladores somos muy vagos en cuanto a end-to-end testing se refiere. A menudo diferentes equipos trabajan en diferentes componentes y funcionan como islas independientes unas de la otras. Descuidar la interación entre componentes puede traer problemas a largo plazo, y las demos ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.

  • Irremediablemente se crearán soluciones temporales, o hablando más claro: parches. Estos parches estarán ahí en la demo, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.

  • Las demos obligan al pragmatismo y a la creación de artefactos distribuibles. Otro aspecto que yo considero importante es que los desarrolladores no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El desarrollador se debe centrar en implementar funcionalidad de manera pragmática y siempre pensando en tener algo que entregar, algo que distribuir, algo que se pueda demostrar.

    Esto abre otro debate sobre como integrar en un Sprint funcionalidades no tan fácilmente demostrables como puedan ser cambios internos en la arquitectura, refactorizaciones, etc. Pero eso ya es un tema diferente.

  • Involucración por parte de los desarrolladores. Personalmente creo que la demo no debe ser realizada por única persona, sino que aquí el Scrum Master debe actuar como simple maestro de ceremonias. Obligar a los desarrolladores a participar en la demo les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.

  • El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demo para toda la compañía. Vosotros ya sabéis como es el desarrollo de software. A menudo la mayoría de equipos trabajan de manera independiente, y prácticamente sólo tienen contacto para conocer los problemas que unos tienen con el trabajo del otro. "¿Oye, qué tenía que pasar en este escenario?", "¡Este caso de uso está mal, estamos perdidos.", "¡Change Request", ...

    Me atrevería a decir que es común que la sensación cross-team de las personas ajenas al desarrollo de una aplicación al terminar cada iteración sea más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido estos equpos han sido problemas. El presentar una demo y mostrar que los objetivos marcados a principio de Sprint se han cumplido, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo de desarrollo.


  • Visibilidad para el cliente. Teóricamente las demos deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demos internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demo el cliente puede comprobar que se está progresando, lo cual en el mundo del software no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.



Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demo, al menos en nuestro caso. ¿Cómo son vuestras demos? ¿Las hacéis? ¿Se diferencian mucho sobre esto?

Dos blogs sobre escalabilidad en español

domingo, noviembre 02, 2008 por Martín

Desde hace semanas vengo siguiendo un par de blogs muy interesantes que se centran en el tema de la escalabilidad de una manera directa o indirecta.

Por una parte está Nubeblog, que viene posteando bastante frecuentemente sobre el tema de cloud computing y todo lo relacionado. Por otra parte tenemos el blog de Diego Mariño, CEO de abiquo, Externalidades que mezcla temas de emprendedores y Grid Computing, lo que lo hace doblemente interesante.

Este blog es muy modesto como para que vaya a crear un "efecto pensamientos ágiles", pero personalmente no conozco muchos más blogs en castellano dedicados a este tipo de temas, así que merece la pena mencionarlos. Yo estoy enganchado a sus posts así que si los desconocíais, quizás alguno los encuentre también interesantes.

Por cierto, ¿alguna otra recomendación en castellano sobre estos temas?

sábado, noviembre 01, 2008

La importancia de decir NO a tiempo.

sábado, noviembre 01, 2008 por Martín

Ayer mantenía una conversación muy interesante con algunos amigos y uno de los temas que salió, como casi siempre, es el tema laboral en España. Las diferentes historias que se iban contando estaban siempre relacionadas con equipos de desarrollo con estrés, jefes incompetentes, jefes competentes que no tenían poder y que estresaban todavía más, etc.

Todas estas historias tenían algo en común. En ningún momento nadie decía NO.

lunes, octubre 27, 2008

Anunciando Jobsket

lunes, octubre 27, 2008 por Martín



Hoy es un día especial porque por fin puedo anunciar el proyecto en el que he estado trabajando con Dani, Jordi y Mamen.

Se trata de Jobsket y por ahora no puedo dar mucha información :) Simplemente os puedo decir que es una aplicación web orientada al mercado laboral y de búsqueda de empleo, y que pretende hacer que sea mucho más sencillo el hacer esto último, buscar trabajo.

Hasta el momento, el feedback que tenemos de amigos es bueno, y todos coinciden en lo mismo, el enfoque muy innovador que planteamos. Os puedo asegurar que la web es totalmente diferente a los que estáis acostumbrados en el mundillo. Así que no puedo recomendaros más que os paséis por la web y os registréis.

El siguiente reto para Jobsket será el lanzamiento de la beta privada. No me atrevo a daros ninguna fecha ahora mismo, pero somos optimistas ya que lo que nos queda realmente es trabajar en el diseño de la web e ir encajando todos los componentes. Una vez que esté todo listo iremos avisando, por orden de registro, a las personas que se hayan apuntado en la web. ¡¡Y estamos realmente ansiosos de que esto sea muy pronto!!

viernes, octubre 24, 2008

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

viernes, octubre 24, 2008 por Martín



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.

lunes, octubre 20, 2008

Las 5 cosas que más me gustan de grails

lunes, octubre 20, 2008 por Martín



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

lunes, octubre 13, 2008

WebSphere: Para tiempos de crisis, informes afines.

lunes, octubre 13, 2008 por Martín

Yo ya no me sorprendo demasiado con este tipo de informes:



WebSphere v7 parece realmente potente. Tampoco me extrañaría que estuviese realmente en el primer lugar, a fin de cuentas es un buen software, aunque nunca haya conocido a nadie que hable bien de él salvo administradores de sistemas que estén ya acostumbrados al mismo y hayan hecho sus cursos y por lo tanto sean totalmente contrarios a un cambio.

Pero... ¿Geronimo en segundo lugar? No conozco a nadie ni he visto ningún proyecto en Internet que lo utilice. ¿Alguien lo usa realmente? ¿ColdFusion encima de JBoss, Glassfish, WebLogic? ¿WebLogic es el séptimo?....

Como han cambiado las cosas :-)

Visto en TheServerSide. A Rich Sharples de JBoss no le ha parecido bien. A mi me ha parecido gracioso. Pero bueno, ya se sabe que a nadie lo despiden por elegir IBM...

jueves, octubre 09, 2008

Knight News Challenge: 5 millones de dólares para proyectos sociales Open Source

jueves, octubre 09, 2008 por Martín


Estamos en época de crisis. La bolsa se hunde y los bancos apenas disponen de liquidez. Aún así, todo el mundo comenta que emprender en Europa es muy complicado, y los emprendedores sufren para encontrar capital de riesgo. Con este panorama iniciativas como el Knights News Challenge toman mucho atractivo.

Se trata de un concurso en el que se reparten 5 millones de dólares en premios para proyectos y aplicaciones basadas en Software Libre y centradas en el desarrollo comunitario. Redes sociales, blogs sobre temas que afecten a la sociedad, herramientas para acercar las tecnologías a comunidades de ciudadanos, etc. Cualquier proyecto es válido con tal que cumpla los siguientes tres requisitos:

  1. Ha de liberarse como software libre.

  2. Ha de servir al interés público.

  3. Ha de beneficiar a una o más comunidades geográficas.



Y para probar que la gente gana, se puede echar un vistazo a los ganadores del 2008 y 2007, que como veréis son proyectos normales y corrientes.

¿Alguien se anima? Se me ocurre que los chicos de Linking Paths podrían tener mucho que decir con su flamante Tog.

martes, octubre 07, 2008

Facebook viene a Dubiln

martes, octubre 07, 2008 por Martín


La comidilla de la semana pasada por aquí era que Facebook se viene a Dublín. Han decidido establecer sus cuarteles generales internacionales en Irlanda, como no debido a las ventajas fiscales que, a pesar de la recesión, la isla sigue ofreciendo.

La verdad es que todavía no se sabe nada sobre la localización de las oficinas, aunque como ya comentaba lo que se sabe es que estarán en Dublín. No me extrañaría que saliesen apuestas en Paddy Power, porque la verdad es que puede caer en cualquier parte. Tenemos a eBay, IBM y Amazon al norte, Oracle en el este, Intel en el oeste, Google en el centro y Microsoft al sur, entre muchas otras.

La compañía ya está anunciando unos 20 trabajos en su web con destino Dublín, todos relacionados con mantenimiento operativo y lenguajes, lo que incluye por supuesto roles de atención al cliente en español. Así que a más de uno quizás le interese si está pensando pasarse por Dublín. En teoría la idea es crear unos 70 trabajos. Por aquí con lo que les gusta Facebook creo que va a haber una marea de candidaturas, estoy seguro que los recruiters de la compañía van a estar muy ocupados, y es que parece que al final habrá en Dublín una compañía más cool para trabajar que Google :)

Os dejo algunos enlaces a notas de prensa:

http://www.rte.ie/news/2008/1002/facebook.html
http://www.entemp.ie/press/2008/20081002.htm
http://news.slashdot.org/article.pl?sid=08/10/03/149219&from=rss
http://www.insideview.ie/irisheyes/2008/10/three-reasons-f.html

miércoles, octubre 01, 2008

Transparencias de la JAOO 2008

miércoles, octubre 01, 2008 por Martín


Esta semana se celebra la JAOO 2008 y conforme han ido pasando los días han ido poniendo las diferentes transparencias en la web. Ahora mismo hay un buen montón sobre temas muy defentes, pero vaya que las hay que realmente prometen.

La verdad es que había empezado a hacer una lista con los títulos de todas las que me interesaban pero he parado porque la lista me estaba quedando enorme. Escalabilidad, Arquitectura, Metodologías Ágiles, Ruby, REST, Java, Cloud Computing, ...

En especial, la serie de charlas del Martes que parece que estaban dedicadas a Arquitectura parece super-super-super interesante. En fin, una envidia el no poder estar ahí pero habrá que aprovechar para empaparse del conocimiento que emanan estas jugosas transparencias :-)

miércoles, octubre 01, 2008 por Martín

Un clásico...



Via Oracle AppsLab blog.

domingo, septiembre 28, 2008

Red Social: debug_mode=ON

domingo, septiembre 28, 2008 por Martín


Tenía pendiente otra entrada de publicidad merecida. La había estado retrasando por los problemas que tuvieron en su lanzamiento. A estas alturas seguro que muchos ya habréis oido hablar y os habréis pasado por este sitio web pero no puedo más que mencionarlo de nuevo porque seguro que todavía habrá algún despistado.

Se trata de la comunidad de desarrolladores debug_mode=ON creada por Alberto Gimeno y Juan Luis Belmonte, Ignacio Andreu y Néstor Salceda. Alberto presenta la web en su blog y habla también de la buena acogida en el Google Developer Day 2008 que ha tenido la aplicación.

Y no es para menos que los chicos de Google les hayan hecho un guiño después de la jugarreta que le hicieron las cuotas de Google App Engine, motor sobre el que se despliega debug_mode=ON, ya que a juzgar por los comentarios en los grupos de google este sistema de cuotas no se lleva muy bien con aplicaciones que necesiten picos de CPU. Por cierto, al menos resulta curiosa la cuota de "High Amount CPU" en un sistema de Cloud Computing.

El principal aporte de debug_mode=ON a parte del inherente a la red social es que cualquiera puede obtener dinero publicando artículos en la web ya que en los artículos se publican anuncios de AdSense con los identificadores de las personas que publiquen los artículos. Es decir que como autor, cada vez que alguien lea tu artículo o cliquee en el anuncio obtendrás algo de dinero.

Salvados los problemas iniciales, la web está funcionando desde hace días y parece que crece a buen ritmo. Bastantes artículos, grupos y personas registradas, se ve buena actividad y parece que promete. Está muy bien ver este tipo de iniciativas en España ya que no destacamos demasiado por comunidades de desarrolladores así que, desde este modesto lugar que es este blog, no puedo más que desearles mucha suerte a Alberto, Juan Luis, Ignacio y Néstor.