Leyendo el post Programmers Don't Read Books -- But You Should en Coding Horror. Me ha hecho pensar dos cosas:
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? :)
La comunidad javaHispano, la revista Sólo Programadores y SUN Microsystems Ibérica son los organizadores, de la recién anunciada, JavaCup 2008.
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 :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.
