La verdad es que me costó mucho dar una explicación sobre qué es Grails y qué voy a hacer en el Summer of Code para un periódico, para que quien lo leyera al menos se hiciera una mínima idea (no se si lo he conseguido).

Por otro lado, parece que al final me han descubierto el porqué de que este blog se llame arragonán , quien quiera saber más en la wikipedia hay bastante información sobre el dialecto ribagorzano.

PD: Sí, lo sé, esto es autobombo

Interesante iniciativa, sobre todo por la poca cantidad de contenido en español que hay sobre este framework.

Si te interesa Spring, también en los podcast de javaHispano hay algunos en los que se habla de spring.

Para quien no lo conozca, el libro es una novela autobiográfica en clave de humor de un ingeniero informático. El libro cuenta multitud de situaciones que pueden parecer surrealistas, pero que son bastante comunes dentro del sector TIC(aunque seguramente puedan serlo también en otros secotres), con un toque de humor simplemente genial.

Un complemento perfecto a la tira cómica de Dilbert y a la película Trabajo Basura.

Que no conozco muchos programadores que lean libros técnicos y en qué tipos de libros resultan más útiles.

Principalmente encuentro dos tipos de libros, los de lenguajes/frameworks específicos y los de hablan sobre lo menos técnologico del desarrollo.

Aunque parece que Jeff Atwood no acaba de ver futuro a los libros sobre lenguajes/frameworks, a mi sí que me resultan realmente útiles y les veo un largo futuro. En mi opinión si quieres conocer ya sea un lenguaje, herramienta o framework una de las mejores formas de hacerlo es cogiendo un libro sobre el tema.

Sin ir más lejos hace un tiempo que estoy leyendo el libro POJOS in Action - Developing Enterprise Applications with Lightweight Frameworks, que toca diferentes frameworks Java de los que llaman(¿o llamaban?) ligeros y cómo utilizarlos en una aplicación empresarial. Que me está ayudando a refrescar la memoria sobre algún framework, profundizar un poco en algunos otros y conocer otros tantos; y, sobre todo, en cómo y cuándo utilizarlos.

Anteriormente me leí The Pragmatic Programmer, enfocado más hacia buenas prácticas de programación generales. Dentro del tipo de libros menos técnicos podrían entrar además temas de diseño de software, usabilidad, trabajo en equipo…

Para mi cada tipo de libro resulta útil en su contexto:
Unos para cuando quiero conocer algo concreto a nivel técnico, que leeré una vez y luego lo dejaré como referencia para dudas concretas.
Y los otros cuando quiero aprender temas más orientados a buenas prácticas, a diseño de software o a posibles formas de manejar situaciones fuera de lo puramente técnico; que podré leer varias veces con el tiempo para refrescarlo, y que también puede quedar como referencia para algo en concreto.

Por cierto, ¿alguien me recomienda algún buen libro sobre HTML+CSS para añadirlo a mi lista en amazon?

Para describirlo de forma rápida, la idea es parecida a esas competiciones entre equipos de robots-futbolistas que vemos de vez en cuando en algunas noticias. En este caso la forma de crear un equipo es con una clase Java que implementa una interfaz dada por el framework del juego, esta clase sólo se tiene que preocupar de la estrategia y el framework se encarga de toda la parte gráfica.

Los premios son 1500€, 1000€, 500€ y 250€ para los cuatro primeros además de una suscripción anual a Sólo Programadores; los ganadores se anunciarán en el OpenJavaDay a finales del mes de Junio en Madrid.

El año pasado estuve trasteando con el framework creando un equipo, me pareció bastante sencillo hacer algo, lo que no quiere decir que fuera competitivo y (como me pasa este año) por no tener tiempo no participé.

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 ), 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í.

Cuelgo aquí la presentación para su primera clase:

Una gran oportunidad para conocer este framework para los desarrolladores asturianos.

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.

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.

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.