Pues eso que me toca tener un verano de código. Me ha llegado la confirmación de que me han aceptado en el Google Summer of Code 2008, el programa de google para promover que estudiantes desarrollen código para proyectos open source durante el verano.
Como estudiante de la UOC (sé que debería dedicarle algo más de tiempo :P), tenía la opción de mandar mis propuestas a las organizaciones mentoras que google había aceptado, la cuestión es que depués de haber empezado a usar Grails y encontrarme con alguna necesidad o posibilidad de mejora, mandé un par de propuestas a codehaus (la organización bajo la que está Grails).
Finalmente me han aceptado el Include Plugin, aunque es muy probable que acabe colaborando de alguna forma también en el plugin de JCR, que era la otra propuesta que había enviado.
Vamos, una gran oportunidad para entrar a colaborar en un proyecto que, en mi opinión, tiene muchas posibilidades de conventirse en uno de los frameworks web java más utilizados. Además de tener como mentor a Graeme Rocher (líder de Grails) y tener contacto directo con Guillaume Laforge (líder de Groovy), de los que espero aprender mucho.
Por cierto, que no se me olvide felicitar a Alberto: Show file history as revision graph (Subclipse), a Juan Luis: Configurable PAM and NSS modules from the Debian Installer y a Néstor: Applying Gendarme to Mono (que aunque no lo conozca en persona me han comentado que también le han aceptado). Y también agradecer su "soporte" a Ignacio por resolverme las dudas respecto a la organización del GSoC y a Martín por hacerlo con varias sobre JCR.
Bueno, ahora sólo falta empezar a prepararse para el pistoletazo de salida del día 26 de Mayo, y por descontado que las cosas que vaya haciendo y que puedan resultar interesantes las iré contando por aquí.
Como ya comenté, una de las cosas interesantes que veía en groovy era ExpandoMetaClass.
Este sería un ejemplo de uso, añadiendo a la clase StringBuilder un método en tiempo de ejecución. Es un método para que se hiciera el append sólo si el parámetro pasado no es nulo, de esta forma nos podríamos ahorrar una buena cantidad de if si necesitaramos hacer esta comprobación antes de cada append.
StringBuilder.metaClass.appendNotNull={ str ->
if(str){
append(str)
}
}
//Lo usaríamos como cualquier otro método
StringBuilder builder = new StringBuilder()
builder.appendNotNull("hola")
builder.appendNotNull(null)
builder.appendNotNull("mundo")
Este ejemplo es un poco trivial, ya que se podría hacer esto simplemente creando una clase que extendiera de StringBuilder e implementando el método. Aunque por otro lado, si sólo necesitamos hacerlo en un punto de nuestro código, esta podría ser una solución.
Ya se ha escrito mucho sobre Google App Engine, parece mentira que lo anunciaran ayer, pero la verdad que es realmente interesante el poder disponer de los mismos sistemas de google para escalar un proyecto web.
En español, unas revisiones que me han gustado mucho han sido las de Aitor García y de Ricardo Galli, por eso simplemente voy a dar algunas impresiones acerca de GAE.
Estoy convencido que supondrá un buen empujón a python como lenguaje, por ser hasta el momento el único lenguaje soportado. Imagino que no todos de esos 10000 desarrolladores que se han registrado a la preview release conocerían python, aparte de los que habrán empezado o empezarán en breve a estudiar la SDK.
La facilidad que les puede suponer para las startups contar con un sistema que saben que va a escalar perfectamente, empezando además con un hosting gratuito de 500MB de espacio en disco y poder servir 5 millones de páginas al mes.
Habrá que ver cómo responde Amazon, al ser GAE un servicio más orientado al desarrollador, teniendo "simplemente" que subir la aplicación, mientras que en Amazon parece que la combinación EC2+S3+SimpleDB no es tan sencilla. Y aunque ahora GAE sólo pueda usarse con aplicaciones en python, parece que google irá dando soporte a más lenguajes.
Por otro lado, también habrá que esperar a ver que movimientos hacen empresas como IBM, Microsoft, SUN o HP.
El mercado del cloud computing parece que se está poniendo competitivo y muy interesante.
Joseph Ottinger ha escrito en TheServerSide un post sobre la duplicación de esfuerzos en la industria del desarrollo de software.
El post se centra en diferentes librerías del mundo open source, con la misma finalidad o con finalidades muy parecidas y la "duplicación" de esfuerzo al desarrollar estas librerías. Algunas razones que da son:
- Falta de conocimiento de alguna librería existente.
- Falta de amplitud de percepción.
- Diferencia de opinión de cómo debería trabajar la librería.
- El antiguo proyecto puede no estar mantenido.
Otras razones que he visto por las que se han desarrollado librerías y frameworks dentro de empresas han sido: no encontrar una librería que cubriera unas necesidades determinadas, que las librerías existentes no se consideraran lo suficiente maduras, o que no hubiera una empresa detrás que diera confianza en su mantenimiento. Por otro lado, también conozco a algún "raro" que crea sus propias librerías en casa por pura diversión :).
Personalmente, me encanta poder tener múltiples opciones a elegir y probar varias de ellas, tratando de encontrar sus puntos fuertes y débiles. Aunque hay casos como el de los frameworks web, con la gran cantidad que hay (tanto Java como Php), que siempre queda la duda de haber hecho la mejor elección para desarrollar un proyecto.
