Y aquí con Fabian Nuñez, el creador del framework de la JavaCup!

 Por cierto, hablando de reuniones presenciales, guardaros un día en Febrero, ya que vamos a hacer un evento presencial en Madrid! Más información próximamente....Stay tuned!

Desde hace muchos años conocia el uso de bootclasspath, para que se podia utilizar y la potencia que daba.

Siempre habia podido realizar las aplicaciones sin utilizarlo, hasta ahora.

bootclasspath permite poner tu propia implementacion de classes de la maquina virtual, esto es muy util cuando una clase tiene un bug o quieres modificar la implementacion de un objeto basico.

Lo importante es que aunque sea muy potente solo hay que utilizarla cuando haga falta.

pues si, si queremos que algo cambie, si creemos que algo huele a podrido en la industria de las IT, si creemos que hay otro camino mejor, entonces no podemos quedarnos sentados a esperar que alguien lo arregle, nosotros somos los que tenemos en nuestras manos las herramientas y los conocimientos para propiciar este cambio, necesitamos un cambio de actitud que consise basicamente en llorar menos y arriesgarnos más por lo que creemos.

Esta es la idea principal que me ronda por la cabeza despues del agile open 2009, un evento que ha superado con creces cualquier expectactiva, un evento vivo lleno de gente apasionada por su trabajo con ganas de aprender y de compartir. Toda una experiencia, era exceptico con el formato "open" ahora soy fan incondiconal. Resumo un poco el evento desde mi perspectiva, que no es la única porque cada cual vivio el open a su manera en función de las charlas/discusiones a las que fue acudiendo durante el día, otra cosa fantastica de este formato.

El primer día se hizo la presentación del evento, agustin yague, jose manuel beas, xavi albadalejo y xavier quesada fuerón los maestros de ceremonias que presentarón el evento y la asociación agile-spain y sus objetivos. Posteriormente los asistentes iban proponiendo charlas y más tarde había que votar las charlas para llenar los 30 slots disponibles (6 aulas y 5 sesiones).

Lo primero que me sorprendio es la cantidad de gente que propuso charlas, se monto una cola que no veas y se propusierón más de 50 charlas creo recordar. Algunas charlas se juntarón en un slot por ser de tematica muy similar y algunas pocas quedarón fuera, la verdad es que yo pensaba que iba a ser un caos total pero la autogarnización funciono realmente bien y entre más de 100 personas se pudo confeccionar el programa de charlas, sin duda el primer exito del open!

La variedad de las charlas hizo que cada uno se hiciera su hoja de ruta en función de sus gustos, y creo que todos encontramos en el open "nuestra conferencia", mi elección fue mayoritariamente hacia los temas más tecnicos, ultimamente me preocupa mucho que se esten perdiendo las practicas tecnicas que están en el corazón de agile (XP fundamentalmente) con la popularización de Scrum y me encontre rodeado de mucha gente con la misma preocupación y con la idea clara de que estas practicas son fundamentales, y diciendolo bien alto no con la boca pequeña.

Fue la primera toma de contacto con Xavier Gost, sin duda la persona que más me ha impresionado en este open. Más que una charla fue una discusión donde se debatio sobre la belleza en el código y sobre el concepto del desarrollo del software como una artesania muy alejado de los procesos industriales y de la idea de ingenieria, algo con lo que resulta obvio que estoy de acuerdo para cualquiera que lea el titulo de este blog jeje. Discutimos sobre la idea del maestro y el aprendiz como metodo para formar a nuevos artesanos, y se pusierón sobre la mesa ideas realmente importantes que nuestra industria parece ignorar completamente:

• Un buen artesano del software se forma en 10 años o más, esto de aprenda java en 2 días o el cursillo por fasciculos "programar es facil" es una soberana estupidez. Y nuestra industria insiste en que quien lleva 10 años y sigue siendo programador es un "fracasado" y en forzar a la gente a abandonar las tareas tecnicas por otras de gestión justo cuando empieza a alcanzar un cierto nivel de artesania aceptable.
• Escribir código es como escribir un ensayo, lo escribimos para que lo lean otros no para que lo lea la máquina. Aplicando esta metafora en lugar de la metafora industrial de cadena de montaje quizas logremos que alguien entienda de una vez que 3 becarios mal pagados y peor formados no pueden hacer el trabajo de un verdadero artesano.

Charla impartida por rodrigo corral, magnifico ponente y magnifica charla, rodrigo fue conduciendo a través de lanzar preguntas de modo que de forma deductiva todo el mundo terminará convencido de las conclusiones. Las conclusiones más destables fuerón:

• Dividir en pequeñas historias y reestimarlas de forma atomica: esta terminada o no, no nos interesa nada más.
• Estimaciones con la colaboración de TODO el equipo.
• Visibilidad del estado del proyecto con indicadores objetivos y simples (los podría entender mi abuela), es decir, la grafica de burndown.

Charla genial!, la presentación de xavi gost de la charla el primer día fue algo como "como introducir el agilismo sin permiso". Xavi nos hablo de como introducir el agilismo desde las bases, en las areas más tecnicas, sin permiso si quiera de tus compañeros, algunas ideas:

• Haz pruebas unitarias, aunque los demás no las hagan tu hazlas y demuestra que son utiles. Alguien pregunto que si tu te pones ha hacer pruebas vas a ir más lento que el resto, la respuesta fue magnifica "no se conoce el caso de nadie que le hayan echado por programar lento y hacer test!, y si te echan por hacer test es que son unos mamones". El agilismo de guerrilla implica mojarse y correr riesgos, si vas más lento pues vas más lento, pero haces un buen trabajo como profesional y muestras el camino a otros para hacerlo bien. Y desde luego, si te echan por esforzarte en hacer las cosas bien esa empresa no se merece tu tiempo.
• micro-commits, esta es muy buena, consiste en bajarse el código "de otros" del scm y cambiarlo, para mejorarlo obviamente, cuando se lo bajen y les empieze a dar conflictos empieza la diversión jeje. De esta forma por un lado verán la forma de hacer mejor las cosas y por otro se hará patente la necesidad de una politica de scm como dios manda, decia xavi "en algunos sitios en los que trabaje pregunte: habrá que hacer un mergue no?, y me respondierón: un que?".
• haz integración continua, por tu cuenta y sin permiso, en tu equipo donde sea, y da el coñazo cuando se rompa el build, o mejor aún, configura la herramienta de IC para que mande correos a los que rompan el build. Cuando vean la utilidad del cacharro no podrán vivir sin integración continua.
• Pair programming forzoso, de vez en cuando te sientas al lado algún compañero ha hacer pair, a lo mejor alguno te manda a la mierda, pero son los riesgos que debe asumir un guerrillero!

Brutal, vaya crack. Lo mejor es no me queda la menor duda de que no esto lo ha echo más de una vez, no es de boquilla.

Se puede estar más o menos deacuerdo con los metodos de guerrilla y con lo radical de la propuesta, pero lo que desde luego es una verdad como un templo es el fondo y el titulo de esta entrada, el cambio esta en nostros mismos y si queremos el cambio hay que llorar menos y mojarse más. ¿Somos agentes de cambio o nenazas lloronas?

O más resumidamente, la charla del queso jeje. charla propuesta por Luismi Cavallé, que de nuevo era otro crack, un tio con las ideas muy claras y que supo trasmitir muy bien las ideas detras del ARxSA.

Yo no conocia este "movimiento", me sonaba pero no le había prestado mucha atención, y acabo de descubrir que si encajo en algún lugar dentro del agilismo es justo aqui!. Algunas de las premisas de esta idea son:

• La tecnología es importante, hay tecnologías con las que hacer agilismo es más facil que con otras y esto no lo podemos obviar y sacarlo de la ecuación. El paso hacia el agilismo puede suponer también un cambio tecnologico. Cosas como rails, grails o REST en contraposición a SOAP son algunos ejemplos. La metodología no es "neutra" y da igual con que tecnología la apliques, la tecnologia usada y la forma de usarla es parte del agilismo también. Podriamos ser agiles sin hudson?, sin las herramientas de testing de las que disponemos? etc,etc.
• Vuelta a los valores core del agilismo, lo resumia el ponente con un twit de Ron Jeffries, "si no haces TDD ni intentes hacer scrum". Es decir, si no engrasas la maquinaria primero, si no dispones de buenos artesanos, ¿donde vas con tu pizarra llena de post-it de colores?, hay que ser muy inocente para pensar que algo así va a solucionar tus problemas.

Esta charla fue muy divertida, se comentarón entre todos ventajas/desventajas del pair programming y cuando aplicarlo y por otro lado jmb y xg hicierón un ejercicio de ping-pong programming, basicamente esto consiste en que uno escribe el test y el otro luego escribe el código necesario para pasar ese test y un nuevo test y así sucesivamente.

Aunque era la ultima del día y ya no estaba el cuerpo para muchas maravillas en la programación lo mejor fue la cantidad de discusiones interesantes cuando pones a unos cuantos artesanos del software delante de un trozo de código jeje, muy divertido. A xavi casi le da un ataque cuando alguien puso un nombre de propiedad comenzando con guion bajo! xd.

Al final del evento se hizo una restrospectiva con todos los asistentes (si con todos, 160!) donde se cerro la conferencia y se hizo una lista con lo bueno y con lo malo del evento. Lo mejor fue que practicamente todo el mundo se quedo a la retro, que se veia en las caras de la gente que lo habían pasado realmente bien, el buen rollo era evidente en el ambiente, lo nunca visto en una conferencia!, sin palabras!.

Ya termino que me queda mu largo esto (como siempre xd), espero haberos dado un poco de envidia a los que no estubisteis, envidia sana para que os animeis a venir a los proximos eventos y para que os apunteis/formeis grupos locales, en el grupo de madrid somos unos cuantos pero hay sitio para todos los que vengan!.

Vamos con los ultimos temas teoricos de clean code:

Como me gusta este capitulo!, un libro sobre buenas practicas tiene que hablar sobre buenas practicas de código de test, y casi ninguno lo hace. Hace algo menos de dos años que comenzamos a trabajar usando seriamente unit testing, primero haciendo test depues de escribir el código, y ultimamente vamos consiguiendo escribirlos primero y hacer TDD, cuesta mucho el cambio de mentalidad pero esta es la practica que, con mucha diferencia, más a contribuido a que mejore como programador. Si quieres hacer algo para mejorar como profesional mi recomendación es que pongas al unit testing y al TDD los primeros en tu lista, por delante incluso de aprender nuevos lenguajes y muy por delante de aprender el nuevo framework pepito que piden en las ofertas de trabajo.

La recomendación más importante que se ofrece sobre los test es tomarse el código de test en serio, es decir, el código de test no es un código de segunda categoria, si aplicas X practicas en tu código de producción aplicalas también en el código de test!, no caigas en el error de "como es un test vale todo". Y lo digo desde la experiencia de caer en este mismo error cuando empezamos a escribir pruebas, pruebas que a los dos meses no hay quien entienda ni quien mantenga y que lo que hacen más que mejorar la calidad de desarrollo es ralentizarlo por el costo de mantenerlos.

El tio bob también habla de TDD y ofrece su receta para hacer TDD, son tres pasos:

• No puedes escribir código de producción antes de tener un test que falle.
• No puedes seguir escribiendo código de un test si ya has escrito lo suficiente para que falle, y los errores de compilación son fallos (recordar que con TDD escribes el test incluso antes de que las funciones a probar existan!).
• No puedes escribir más código de producción que el estrictamente necesario para que pase el test que actualmente esta fallando.

Tela eh?, parece facil pero cuando te pones ha hacerlo en la practica es muy dificil lograr la displina y la habilidad escribiendo test (y escribiendo código testable, que es lo más dificil!) para cumplir con estas 3 reglas, a mi me ha costado como os digo casi dos años y todavía no siempre soy capaz de seguir estos 3 principos a simple vista simples. Pero cuando lo logras, cuando construyes de esta forma una funcionalidad, poco a poco pasando pequeños test y añadiendo pequeños trozos de código a un sistema que siempre se mantiene estable, la sensación que te queda de estar haciendo realmente un buen trabajo es fantastica.

Posteriormente se explica el principio FIRST, que son 5 cualidades que debe tener un buen test:

• Fast: Los test deben ejecutarse rapido. Si no al final el equipo terminará por no pasarlos. Yo añadiria que esto es cierto para los test unitarios, para los funcionales no me importa tanto la velocidad sino hacer el test con un sistema real (base de datos, sistema de fichero etc,etc incluidos)
• Independant:Un test nunca debe depender de otros para pasar. Los puedes ejecutar en cualquier orden y deben funcinar igual.
• Repeteable:El test se debe ejecutar encualquier entorno. En el equipo de desarrollo, en el servidor de IC. Lo ideal es bajarselo del sistema de control de versiones ejecutar un comando (mvn clean install by example) y que toda la aplicación compile y los test pasen.
• Self-validating:Un test debe devolver: "correcto" o "fallo" y no debe requerir ningún tipo de intervención manual posterior (mirando un log por ejemplo) que determine si el test paso o no.
• Timely:Con esto se refiere a que los test deben ser escritos en el momento adecuado, es decir, antes que el código que prueban.

En resumen, un gran capitulo sobre test unitarios que si hubiera leido hace dos años me hubiera ahorrado varios dolores de cabeza. Por ponerle alguna pega, no se entra en suficiente detalle en como escribir código testable (aunque si se trata en otros capitulos del libro), que en mi experiencia es lo más dificil de conseguir y de hacer entender a quienes empiezan con el unit testing, para esto os recomiendo el blog de misko hevery, que tiene articulos fantasticos sobre el tema y una guia de como escribir código testable.

La recomendación más importante en este capitulo coincide con la del capitulo sobre funciones, hacer clases pequeñas!. Tio bob habla sobre mantener el principio de cohesión y el SRP (Single Responsability principle o principio de responsabilidad única) en las clases y como consecuencia de estos terminamos con sistemas formados por muchas clases pequeñas con responsabilidades bien definidas. No podría estar más de acuerdo, no sabría dar un número de lineas maximo porque además me parece un poco arbitrario y dependiente de cada sistema, digamos que personalmente más de 500 lineas debería hacer que saltasen las alarmas y pararse a mirar si podemos subdividir esa funcionalidad en varias clases.

Otra recomendación importante es la de depender de interfaces o bien clases abstractas en lugar de implementaciones concretas. Esto es importante por dos motivos: mejorar la flexibilidad del diseño y mejorar la testabilidad del código. Esto puede ser un poco más discutible porque en ocasiones da lugar a sistemas donde tenemos 1 clase por cada interfaz, y a ojos de muchos resulta excesivo. Yo personalmente si soy partidario de depender siempre de interfaces aún que tenga que escribir un poco más, me parecen más interesantes los beneficios (sobre todo el testing) que lo que me cuesta escribirlos. Aunque para esto se me hace casi indispensable utilizar inyección de dependencias, de esto habla el tio bob en el siguiente capitulo precisamente.

En este capitulo se habla de algunos elementos importantes para la arquitectura general de un sistema orientado a objetos. En primer lugar se habla de algo que me parece realmente interesante, un sistema orientado a objetos tiene dos partes fundamentales que conviene separar:

• Construcción de objetos: Al inicio del sistema cuando se crean los objetos necesarios para su posterior funcionamiento
• Uso de estos objetos: Cuando el sistema esta en marcha y los objetos se usan para proporcionar la funcionalidad requerida

Esta separación sirve para justificar el uso de la inyección de dependencias, que será la encargada de la construcción de los objetos. De modo que nosotros declarativamente indicamos al sistema de inyección de dependencias que objetos queremos que coja para construir nuestro sistema y posteriormente usamos esos objetos cuando el sistema esta en marcha. Esta forma de ver la arquitectura de un sistema OO me parece realmente interesante y es una buena forma de mantener el desacoplamiento entre clases, es el sistema de DI el encargado de saber que implementaciones tiene que instanciar y a que objetos colocarselas como dependencias. Esto da lugar a sistemas más flexibles y cuyas partes (que además son simples y cohesivas) podemos probar facilmente mediante pruebas unitarias y dobles de pruebas (stubs o mocks). Nosotros actualmente seguimos este enfoque utilizando google guice como motor de DI, y estamos muy contentos con la aproximación, tenemos clases más cohesivas, menos acopladas, más facilmente testables y un sistema más flexible donde se puede cambiar una implementación por otra en cada parte del sistema.

Por ultimo el tio bob también habla en este capitulo sobre los "cross-cutting concerns" en castellano sería algo como "funcionalidades transversales", es decir aquellas funcionalidades tipo logging, seguridad, transacciones etc, que están dispersas por todas las clases del sistema. Lo que propone aqui esta claro, usar programación orientada a aspectos. Para esto podemos usar un framework AOP completo como AspectJ o aproximaciones más modestas como el soporte para AOP de spring o el mismo guice. Nostros actualmente usamos interceptores de guice para controlar algunas cosas como transacciones o tratamiento de excepciones.

Este capitulo es basicamente una apuesta por el diseño incremental frente el diseño up-front. Muy en la linea del desarrollo ágil y de lo propuesto en XP por Kent Beck. Se trata de no tratar de diseñar mucho antes de tiempo, diseñar sólo lo necesario para la funcionalidad a implementar hoy sin pensar en la de mañana. Cuando llegue la funcionalidad de mañana ya pensaremos en ella, y como además hemos seguido todos los principios anteriores (clases pequeñas, metodos pequeños, cohesión, SRP etc) nuestro sistema será lo suficientemente flexible para aceptar nuevos cambios y además mantenerse limpio (que es el objetivo de este libro ¿no?: clean code). Algo que también esta muy en la linea de unos de los principios de LEAN, no decidir hasta el ultimo momento responsable para hacerlo.

Para lograr que un sistema emergente no se convierta en un caos se mencionan los 4 principios del diseño simple (estos son de kent beck), en orden de importancia:

1. Todos los test pasan
2. No existe duplicación de código
3. El sistema expresa la intención del programador
4. Minimizar el número de métodos y clases

Estos principios basicamente son la base del Red-Green-Refactor-Green de TDD, del 2 al 4 corresponderían a la fase de refactorización.

De nuevo coincido plenamente con todo lo que se dice en este capitulo, he metido la pata muchas veces por anticipar diseños antes de tiempo y he complicado muchos sistemas por incluir cosas que luego no se han usado jamas. En mi opinión el diseño simple, los test y la refactorización, son la mejor aproximación que conozco para el desarrollo de software y la que trato de aplicar todos los días, unos días mejor y otros peor eso si :P

Este capitulo es el que menos me gusta y sinceramente me parece algo fuera de lugar en este libro. Supongo que lo habrá incluido por el interes creciente en la programción multihilo. Sin ser un experto ni de lejos en este tema las recomendaciones que se dan me parecen muy basicas y no me a aportado gran cosa, hay libros dedicados a estas cuestiones mucho más completos.

Como os decia además de los capitulos que he comentado teneis los capitulos puramente practicos, donde se coje un trozo de código de proyectos reales y se destripa para mejorarlo con los principios contados, estos son altamente recomendables pero no tiene mucho sentido que los resuma.

Las practicas y las ideas que defiende el tio bob en este libro están muy en linea con las practicas de desarrollo ágil (unit testing, diseño simple etc,etc) y también están muy en linea con mi forma de hacer las cosas, quizas por eso mi opinión pueda ser un poco sesgada jeje, pero para mi es un libro fundamental que devuelve la importancia y el foco de un desarrollo de software al sitio del que nunca tenia que haber salido: el código por supuesto. Un libro de diseño OO que no dibuja UML's, coje el código de un proyecto Open Source real y lo modifica aplicando las buenas practicas descritas, un libro que habla de profesionalidad a la hora de escribir código en estos días de carnicas y programadores licenciados en filologia hispanica a 100 pesetas unidad. Quien se quiera seguir engañando (o engañando a otros) que siga, pero el buen software lo construyen los buenos programadores que escriben CLEAN CODE, da igual que pongas un jefe de proyecto con un MBA y con un PMP otorgado por el PMI experto en el uso del project, o que hayas pasado las evaluaciones SCAMPI para el CMMI nivel 3 y 1/3. Si quieres desarrollar buen software preocupate de tener buenos PROGRAMADORES (en mayusculas) profesionales y con talento, el resto es papel mojado.

Un libro fundamental para gente con poca experiencia, sobre todo si va a participar en algún proyecto ágil, y un libro que puede hacer a gente con más experiencia replantearse la forma de hacer muchas cosas. Eso si, como consejo para los que tengais experiencia, leer el libro con mente abierta y dispuestos a replantearos vuestra forma de ver las cosas en muchos aspectos, si lo leeis pensando que lo sabeis todo antes de abrir el libro no vais a sacar mucho beneficio, y además, ¿si ya lo sabeis todo para que leeis libros?, escribirlos! :P.

Despues de unas pequeñas vacaciones en paris, que ya me hacia falta irme de vacaciones, vamos a seguir con la segunda parte del resumencillo al excelente Clean Code del tio bob. Como comente el libro se dividia en capitulos teoricos y tecnicos, voy a seguir con el resumen de los capitulos teoricos por donde lo deje en la anterior entrada.

Capitulo 5: Formatting

Este capitulo bastante más "ligerito" que otros da algunos buenos consejos sobre formateo de código. Se divide en dos partes: formateo vertical y formateo horizontal.

Me ha gustado sobre todo lo del formateo vertical, en general cuando se habla de formateo es más habitual encontrar recomendaciones sobre formateo horizontal, la eterna batalla de la indentación con espacios o tabuladores por ejemplo. El formateo vertical me parece más interesante, la recomendación que más me gusta es lo que llama "The newspapper methapor" que basicamente consiste en escribir las clases de arriba hacia abajo siempre intentado colocar los métodos llamados inmediatamente despues del llamador, de forma que la clase se pueda leer sin tener que andar constatemente con el scroll para arriba y para abajo. Esto es algo que personalmente siempre he intentado hacer, pero sin pararme mucho a pensarlo, simplemente por sentido común, y me ha echo gracia verlo escrito y bien argumentado.

El resto del capitulo son recomendaciones sencillas para tener un código bien formateado, como por ejemplo usar espacios para resaltar la precedencia de operadores en las operaciones aritmeticas. Otra que me toca directamente es cuando desaconseja organizar el código en columnas, por ejemplo cuando se hacen varias asignaciones seguidas digamos en un constructor, yo personalmente quizas por que vengo de C++ tengo la tendencia a hacer que los iguales estén en la misma columna para que el código quede "cuadrado", y la verdad es que además de no servir para mucho es un poco engorroso sobre todo con el autoformateo de algunos IDE's que se empeñan en no dejarme hacerlo tranquilamente jeje, en esto creo que si me ha convencido el tio bob y poco a poco lo voy dejando.

En este capitulo se plantea fundamentalmente la diferencia entre objetos y estructuras de datos. Objetos son los elementos que ocultan su implementación interna y ofrecen métodos frente a las estructuras de datos que por definición exponen sus interioridades y no ofrecen ningún método.

El este capitulo el tio bob critica una practica muy común en el desarrollo java, la de los famosos getter&setter, basicamente considera a los beans estructuras de datos disfrazadas de objetos que no aportan gran cosa, en resumidas cuentas si vas a tener una clase con N propiedades privadas y un getter y un setter para cada propiedad no lo llames clase, llamalo estructura de datos y pon todas las propiedades publicas. Me gusta especialmente una frase sobre este tema: "The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit". El problema en java quiza sea que esta tan extendido el concepto de "bean" que muchos frameworks te obligan a utilizarlos, normalmente para usar introspección sobre estos objetos y hacer su "magia", pero si no estas obligado por ningún framework... ¿realmente necesitas todos esos get&set?

Otra cosa que puede llamar la atención es cuando afirma que la creencia de que todo es un objeto no es más que un mito, y que un programador maduro debe saber distinguir cuando necesita un objeto y cuando necesita simplemente una estructura de datos. La recomendación general que se da es que cuando los datos no varien y se quieran añadir funciones que operen sobre estos datos un enfoque con estructuras de datos, procedural vamos, es más adecuado, mientras que cuando lo que se quiere es tener la flexibilidad de trabajar con distintos tipos (aka polimorfismo) el enfoque OO es superior.

Dificil de aceptar algunas cosas de este capitulo para un taliban de la OO como yo :P, aunque es cierto que cuando generas un monton de getters&setters mecanicamente, aunque sea con un IDE, te queda el regusto de que estas haciendo algo totalmente innecesario y que algo anda mal...

capitulo que me ha parecido muy interesante porque cuestiona cosas que parecen asumidas como "normales" en el mundo java y en el mundo OO, en ocasiones conviene replantearse algunas que uno hace casi mecanicamente y probar otros enfoques, este me lo tengo que releer un par de veces más a ver si me convence del todo que yo sigo viendo objetos por todas partes jeje, pero al menos me ha echo replantearme algunas cosillas, que en definitiva es lo que espero cuando me leo un libro de estilo.

Otro tema habitualmente "polemico", empieza recomendando el uso de excepciones sobre códigos de retorno de las funciones, esto puede parecer hasta evidente para cualquier programador OO con un poco de experiencia, pero se encuentra uno cada cosa por ahí... he trabajado bastante con código en C construido con uso constante de códigos de error y se me ocurren pocas formas mejores para hacer el código cuasi ilegible.

Otra recomendación, en la que ultimamente parece que hay cierto consenso, es no utilizar checked exceptions. En esto es bastante tajante y empieza de una forma que lo deja claro "the debate is over". Afirma que si se puede construir código robusto sin checked exceptions en otros lenguajes como C#, python, ruby etc,etc en java también se puede construir código robusto sin checked exceptions. El principal problema que plantea sobre las checked es la violación del principio "open-close" derivada de las dependencias que generan las excepciones checked, ya que no queda más remedio que capturarlas y relanzarlas o colocar un throws haciendo que el código de las capas más altas tenga que conocer excepciones de bajo nivel varias capas más abajo. Personalmente coincido al 100% con esto, nunca uso excepciones checked y API's como JDBC me parecen un ejemplo perfecto de porque no hay que usarlas, es un martirio para el usuario de estos API's.

Otra recomendación importante que realiza en este capitulo es la de evitar tanto devolver como pasar "null", en lugar de devolver null lanzar una excepción o bien devolver un objeto que cumpla el interfaz esperado pero no haga nada.

En este capitulo se refiere a como tratar con los limites del sistema, es decir, cuando nuestro código interactua con librerías de terceros. Hoy en día nadie se imagina hacer una aplicación sin usar alguna que otra librería: log4j, hibernate, quartz, lucene... cada uno seguro que podría hacer una lista cuasi interminable con todas las librerías que ha tenido que utilizar.

La recomendación inicial para usar código de terceros en encapsularlo en lugar de tratar con el directamente integrado por varias partes de nuestra aplicación. La idea es sencilla, una librería por lo general ofrece gran cantidad de funciones para uso general de las que nosotros normalmente sólo queremos un subconjunto, de modo que la idea es crear nuestro propio interfaz que sólo ofrezca la funcionalidad que necesitamos e implementarlo utilizando la librería en cuestión. Esto ofrece varias ventajas:

• Nuestra aplicación sólo interactua con un interfaz que ofrece justo lo que nos hace falta, ni más ni menos. Esto simplifica nuestra aplicación que no tiene que tratar con los detalles de la librería en cuestión.
• Llegado el caso podriamos cambiar esta librería por otra de funcionalidades similares sin mucho esfuerzo. Esto no siempre es tan facil logicamente, pero si la librería de terceros la utilizamos diseminandola por todas partes de nuestro código nos estamos casando con ella, ya sabeis "hasta que la muerte nos separe", y hombre ¿tampoco nos vamos a casar con cualquiera no?
• Encapsulamos toda la funcionalidad que necesitamos de la librería en una clase (o varias claro, dependiendo de la complejidad del tema), lo que hace que sea mucho más facil hacer pruebas unitarias, que por ejemplo nos permitiran descargarnos una nueva versión de la librería y saber que no se ha roto nada de lo que nos hacia falta.

Nosotros esto lo hacemos habitualmente con librerias, cuando hablamos de frameworks tan habituales en java con spring, struts, jsf etc,etc este enfoque no funciona, estos frameworks condicionan fuertemente la arquitectura de tu aplicación, vamos que si quieres meterle mano a alguno de estos te tienes que casar primero, son menos liberales :P.

Otra recomendación que me gusta de este capitulo es la de aprender a usar liberías de terceros mediante test unitarios. Todos en alguna ocasión hemos creado un "proyecto de prueba" con nuestro metodo main para probar esta o aquella librería, luego cuando hemos evaluado la librería y aprendido como usarla este proyecto suele acabar en la basura o olvidado en algún recondito lugar. La propuesta es hacer esta evaluación mediante test unitarios, de forma que hacemos un test por cada funcionalidad de la librería que queramos incorporar a nuestro programa. Estos test luego se incorporán a la base de código y sirven como una fantastica documentación del uso de la librería y para comprobar que nuevas versiones siguen funcionando como se esperaba. Un enfoque que me gusta bastante.

Y con esto termino la segunda parte, creia que con dos entradas llegaría pero me va ha hacer falta una tercera para los temas sobre clases, unit testing o diseño emergente, que me enrollo cosa mala :P

Este fin de semana hemos vuelto a reanudar los seminarios gratuitos que estamos celebrando entre javaHispano y la Escuela de Groovy. Por tercera vez, impartimos el seminario de introducción a Groovy, y como podéis ver en las fotos, la asistencia fue bastante alta. Incluso tuvimos que cerrar la inscripción... probablemente vuelva a haber un cuarto seminario.

Por cierto, esta vez, por fin, lo grabamos en video. En breve lo publicaremos.

Como comente en un post anterior estoy echando un vistazo a Joomla.

Es como Java hace diez años, con una comunidad dispuesta a ayudar, sin prepotencia, donde la gente hace sugerencias pero no impone sus ideas.

Hace mucho que en java no pasa esto, cuando alguien pregunta por JDBC se le presiona para que utilize Hibernate, cuando alguien quiere hacer alguna cosilla se le intenta hacer una labor de consultoria cuando lo que quiere es simplemente aprender.

Por otra parte el concepto de joomla es muy claro. Solo sirve para lo que sirve y con tres tipos de extensiones puedes montar web impresionantes. Teneis que ver la web que he hecho parecida a javahispano en cuatro tardes.

Lo malo es el rendimiento, tengo una maquina dual core con dos cpus que en java me da un rendimiento impresionante y en php no llega, pero bueno es una maquina de hace tres años y no la tengo montada en linux.

Juntos podemos, es el eslogan de joomla y juntos podriamos pero no lo hacemos es el de java.

• "Debian es para hombres",
  
• "la gente educada usa Suse",
  
• "Suse es para niñas, Debian para antisociales, nada como Slackware"
• "Los hackers de verdad usan RedHat"
• etc
• etc
  

• Sistemas operativos:
• Linux vs Windows
• Lenguajes:
• Java vs .Net
• Frameworks:
• Struts vs JSPs a pelo
  

• buenas,
• bonitas,
• efectivas en combate.
• Y que puedan ser fáciles de intercambiar.
  

• Antes de decidir adoptar una nueva tecnología preguntate cómo se beneficiará el negocio con esa decisión, si en el mejor de los casos nadie(de nivel gerencial) se percatará del cambio, reconsidera tu decisión
• Es importante reconocer los costos asociados a las deficiencias (que pueda tener) la nueva tecnología (seleccionada)
• Las grandes tecnologías no siempre ganan. Tratar de predecir prematuramente en una apuesta tecnológica es algo que no produce grandes ganancias.
• No pongas en riesgo tu proyecto con tecnologías que no tienen futuro.
  

• Venkman:
• Elegir un lenguaje o plataforma depende de lo que se vaya a hacer, como punto de partida[...]valoro que haya estabilidad, buena documentación disponible, una comunidad activa [...] y que la gente hable bien y hable mal de la "herramienta/arma"
  
• gimenete:
• Creo que lo que más valoro últimamente es la agilidad.Para elegir el lenguaje de programación también suele pesar mucho la agilidad. Un lenguaje que conozca me da más agilidad. A veces me creo herramientas propias cuando creo que las que hay no solucionan mis necesidades[..]
  
• danilat
• Para mi tiene bastante peso el dominio de un arma, por que te hace sentirte más seguro[...]También creo que en muchos casos de creación de estas herramientas(herramientas propias) se peca de NIH.
  
• amuino
• Lo principal es la familiaridad con la tecnología[...]A la hora de elegir entre varias opciones, no te comento nada nuevo... el criterio para Open Source sería el de actividad  y velocidad de respuesta a dudas/errores.
  
• GreenEyed
• Depende un poco del proyecto a realizar y sus circunstancias. Si el proyecto es importante y el tiempo no sobra, los experimentos con gaseosa y en casa.Si el proyecto no corre tanta prisa o no es tan crítico, entonces si que me gusta introducir cosas nuevas[]
  

Ultimamente he estado leyendo Clean Code, el ultimo libro del para mi gusto genial Robert Martin. El libro, como el titulo indica :P, esta orientado a proporcionar un conjunto de buenas practicas y recomendaciones para escribir mejor código, código más limpio y más legible.

El libro no se queda sólo en decir "hazlo así que si no esta mal" sino que presenta ejemplos bastante exahustivos de refactorización de código existente (por ejemplo refactorizado una clase del framework JUnit), digamos que el libro esta dividido en 3 partes:

• Capitulos teoricos, donde se exponen y justifican las buenas practicas recomendadas
• Capitulos practicos, donde se coje un código existente y se intenta mejorar aplicando las buenas practicas expuestas en los capitulos teoricos
• Un resumen de las buenas practicas en forma de "smells" y heuristicas simples. No esta mal como pequeña guia en plan recordatorio, siempre y cuando te hayas leido el resto del libro claro, por si solo no es demasiado útil.

Los capitulos teoricos van del 1 al 13, os cuento que es lo que más me ha gustado/llamado la atención en estos capitulos, el resto simplemente hay que leerselos, no tiene mucho sentido hacer un resumen de las partes practicas.

Es un capitulo introductorio para justificar la intención del libro, recoje las opiniones de personalidades importantes de esto del desarrollo de software resaltando la importancia de escribir buen código, gente como Bjarne Stroustrup, Michael Feathers, Ron Jeffries o Grady Booch.

La idea principal del capitulo es que no hay nada más importante que escribir código de calidad para el exito de un proyecto, el autor utiliza muy a menudo la palabra "profesionalidad", hace mucho enfasis en dejar claro que un profesional responsable debe escribir siempre buen código, sean cuales sean las circunstancias, tiempos ajustados por ejemplo, ya que no hay nada que retrase más un proyecto que precisamente el mal código, tenemos que ser profesionales de verdad y hacer lo mejor que sepamos para garantizar la calidad de nuestro trabajo, en resumen, no ser chapuceros, que cada vez que hacemos una chapuza muere un gatito! :P

Me encanta de este capitulo que se de al código la importancia que tiene, algo obvio para cualquier desarrollador responsable, pero parece que no tan obvio para la gran mayoría del espectro de empresas que desarrollan software en esta nuestra querida españa :P (es el ambito que conozco, pero no creo que sea muy diferente en otras partes). Basta ya de adjetivos peyorativos como "picateclas", basta ya de menosprecioar la actividad más importante en el desarrollo de software: PROGRAMAR. Cuando esto se entienda, cuando las cosas se pongan en su lugar y se valore a los buenos profesionales que saben escribir clean code, entonces lo mismo empieza a cambiar un poquito esta industria.

Pues si, un capitulo enterito para decir que escribamos nombres significativos para variables, funciones, clases etc,etc. Pero es que hay pocas cosas más determinantes para que un código sea legible como que tenga nombres en condiciones, pocas cosas más horribles que encontrase con variables tipo "aux1, aux2" o paquetes nombrados como "GUSU" en lugar de "my.company.servicios.gestion.usuarios" (ejemplo real :P )

Algunas recomendaciones que se ofrecen en el libro: usar verbos para nombrar los metodos y sustantivos para las clases, utilizar nombres pronunciables (esta me encanta, el código se LEE, si no puedo pronunciarlo me cuesta más esfuerzo leerlo), no usar notaciones tipo "los enteros empiezan por i, las cadenas por s" y chorradas similares (luego alguien cambia el tipo y se olvida de refactorizar el nombre... también tengo casos reales de esto :P ), no ahorrar caracteres poniendo abreviaturas, por ejemplo escribir "valEdadCli(...)" en lugar de "validarEdadDeCliente(...)".

El capitulo trata de como escribir buenas funciones/metodos, la recomendación más importante del autor en este punto es sencilla: escribe funciones pequeñas. Si luego mirais las refactorizaciones de ejemplo en los capitulos practicos no encontrareis funciones de más de 10 o 20 lineas como muchisimo, totalmente de acuerdo con esta afirmación, sobre todo con lo facil que es refactorizar con cualquier IDE actual, no tiene disculpa escribir funciones de 100 o 200 lineas como se ven por ahí, no es muy profesional que digamos...

Otra recomendación importante es sobre el número de parametros que recibe una función, para el autor 3 parametros es el limite antes de empezar a pensar que algo estamos haciendo mal.

Este capitulo personalmente me encanta, porque en el pasado me ha tocado discutir bastante por defender algunas de las cosas que precisamente defiende el tio bob en este libro, y ahora cuanto me toque discutir otra vez por lo menos tengo una buena referencia jeje.

Particularmente lo que más me gusta es una idea que creo que no todo el mundo tiene clara respecto a los comentarios, la gente considera a los comentarios como algo bueno, al código comentado como algo bueno: "mira que bien, esta todo comentado". El tio bob lo enfoca de otro modo, dice algo como "cada vez que escribes un comentario estas fallando como programador, tienes que escribir un comentario para clarificar algo porque no has sabido utilizar las herramientas que tienes (el lenguaje de programación) para dejar claras tus intenciones". Es decir, poner un comentario es el el ultimo recurso cuando despues de darle muchas vueltas no se te ocurre como clarificar una parte del código, en lugar de dedicar tiempo a escribir comentarios, dedicalo a arreglar tu código para que se entienda sin la necesidad de estos. No te olvides que estas usando un lenguaje de programación, aprende a usarlo correctamente y no ocultes tus carencias con este lenguaje añadiendo notitas al lado en otro lenguaje que dominas mejor y en el que si puedes expresarte (aunque bueno... esto no siempre es así tampoco que se ve cada comentario xd)

Otras recomendaciones son no escribir comentarios redundantes (tipica función "getEdad()" que tiene como comentario "devuelve la edad" ¿en serio?, que sorpresa!), otra que me gusta mucho: "el código comentado es una abominación, borralo!", odio y lo digo muy en serio, odio, el código comentado, si no lo vas a usar borralo que para volver atras tienes el sistema de control de versiones (y si no sabes usarlo, aprende, pero no enguarrines el código!). Una variante de esto ultimo en C/C++ muy divertida con la que me he encontrado alguna vez es usar bloques tipo "#ifdef 1/0", es muy divertido porque el editor como es lógico no muestra el contenido de un bloque "ifdef" que nunca se va a ejecutar de una forma especial, con lo que te puede llevar un buen rato descubrir que llevas media hora tratando de entender un trozo de código que jamas se ejecuta...

Con esto termino de momento que me esta quedando muy largo, en un proximo post termino de contar el resto de capitulos del libro.

Pues eso XD.

Esta disponible el podcast no 55. de JavaHispano. Dudas del Foro; Rubén Egiluz y , como decimos aqui en MX, su servilleta respondemos a algunas preguntas de los foros de javaHispano.

Espero les sea de utilidad.

• Dudas:
  • ¿QUE PASARA CON LAS CERTIFICACIONES JAVA?
  • como forzar el garbage collector
  • Desarrollo Aplicación Web por Módulos
  • Elección FrameWork y Herramientas para Desarrollo Aplicacion
  • CALCULO INTEGRAL EN JAVA !!!

Saludos!!!!

RuGI
Isaac Ruiz Guerra.

Todavia le estoy dando vueltas a la herramienta que utilizar, me encuentro con dos libros editados por anaya en castellano, uno de drupal que tiene una pinta excelente y otro de joomla.

Busco comparativas en google drupal versus joomla y veo que es de versiones anteriores por lo que es posible que con la version 1.5 de joomla este superada.

Me decido por joomla! esa j me pierde y tras leer tres capitulo saco en conclusion de que todo se puede hacer en java y que seguramente los portlet superan ampliamente lo que hace la personalizacion de joomla!

Porque se utiliza tanto pues seguramente cuando todos estabamos trabajando en JSF, en Struct en Spring, ... y en otras herramientas similares la gente de php se dedico a unirse y hacer un CMS que fuera trivial para un diseñador con lo que ganaron de mano la batalla.

Cuando reaccionamos OpenCMS, liferay y otros eran bastante mas complejos y total para una web con pocas visitas y hay hablo de uans 10000 o mas al dia las maquinas podian y mucho mas ahora.

Drupal seguramente tambien me compare el libro, pero no he visto ninguno de opencms.

Hace tiempo que estamos detras de migrarnos de nuestro sistema de build actual: Ant a Maven. Para poneros un poco en situación se trata de un proyecto medio (54.000 lineas de código aprox) subdividido en varios modulos, unos 5 .jar con la logica y los API's del sistema y un par de aplicaciones web. Como se trata de un framework sobre el que desarrollar otras app's también tenemos varios proyectos a modo de ejemplos de uso de los distintos API's.

Esto nos suponia un cambio bastante gordo, tampoco se trata de tirarse a la piscina simplemente porque maven "mola más" o esta más de moda. Varios motivos han motivado este cambio:

• Mantenimiento de los scripts de Ant: Cada vez nos costaba más y más mantener estos scripts. Cuando empezo el proyecto y eran pequeñitos todo perfecto, pero a medida que ha credido el proyectos los scripts también y con algún hack que otro que dificultaba cada vez su mantenimiento.
• Mejorar la distribución de las librerías: Hasta ahora entregabamos nuestras librerías simplemente en un zip y a correr. Queriamos facilitar el trabajo de los usuarios de nuestra librería dejando las versiones liberadas en un repositorio, miramos Ivy también, pero maven nos parecia una solución más completa, y ya puestos a cambiar...
• Facilitar la integración con otras herramientas: Usamos hudson como servidor de CI, y recietemente sonar para control de calidad. Estas herramientas se integran con ant pero su integración con maven es mucho más estrecha.
• Soporte Multi-proyecto: Ant no tiene ningún tipo de soporte multi-proyecto, si tienes varios proyectos con ant y quieres tener una compilación autoamtica de todos en conjunto te lo tienes que montar "by hand" mediante ant-call o similares. En mi opinión cualquier sistema de build moderno debería tener soporte multi-proyecto con varios niveles (jerarquico) de forma nativa, que no todo son proyectos "hola mundo".

Es crucial que el sistema de build se integre en condiciones con el resto de herramientas de tu ecosistema, para nosotros era importante que se integrase bien con:

• Netbeans: El soporte para maven en netbeans 6.7 ha sido un impulso grande para este cambio, el soporte es fantastico y nos permite seguir trabajando con nuestro IDE favorito y utilizar maven. Y aunque sea "ironico" el soporte de maven de netbeans también nos aporta la libertad de migrar a cualquier otro IDE que soporte maven (eclipse, JIdea) si fuera necesario, o que cada desarrollador use el que le de la gana.
• Hudson: Nuestro amado hudson se integra con maven que da gusto. Si subes un proyecto multi-modulo con varios niveles de jerarquia te muestra una vista en árbol (bueno tabula un poco na más) de todos tus sub-modulos, indicando porque modulo va la compilación cuando esta activa. La verdad es que funciona increible hudson con maven, una pasada.
• Sonar: Nos encanta sonar!, y aunque se puede usar en proyectos no-maven con maven todo es mucho más sencillo.
• Subversion: Aunque en principio parezca que poco tiene quer ver con tu sistema de build, maven nos ha permitido no tener que guardar en svn todas las librerías de terceros que usamos (ahora están en el repositorio de maven, nexus en nuestro caso). Esto es importante si tienes 20 proyectos en tu empresa, cada uno con su propio svn, y en cada uno de ellos tienes que almacenar de nuevo todas las librerías de teceros y las compartidas entre los distintos proyectos de tu empresa.
• Nexus: Junto con el uso de maven me parece imprescendible tener en la empresa montado un repositorio maven. Esto te permite no depender de los repositorios remotos, que no están bajo tu control y ¿quien te asegura que no casquen justo el día que te hacen más falta?. También te permite subir a el todas aquellas librerías que no están en los repositorios oficiles, tanto las de terceros que no se distribuyen via maven como las propias librerías que se generan en tu empresa y se comparten entre proyectos. De momento muy bien con nexus, instalación y configuración muy sencillas y 0 problemas, ya veremos claro, que llevamos una semana con el jeje.

Existe una gran cantidad de plugins disponibles para maven, para casi cualquier cosa que te puedas imaginar que necesites en un sistema de build java tienes un plugin de maven que te facilita la tarea, esto ahorra mucho trabajo y sobre todo facilita luego el mantenimiento de los scripts si lo comparamos con Ant, algunos que nos han resultado muy utiles de momento:

• Maven GWT plugin: Necesitabamos un plugin que nos ayudara con nuestros proyectos GWT, me ha sorprendido lo bien que funciona este plugin, en media mañana tenia los proyectos migrados de netbeans con GWT4nb a maven con el plugin de gwt. El único pequeño incoveniente es que a la hora de hacer debug con el hosted browser te ves obligado a ejecutar mvn gwt:debug y luego hacer attach a mano con el depurador de netbeans, pero creo que podre sobrevivir con esto :P.
• Maven assembly plugin: Facilita muchisimo la tarea de crear distribuciones de tu proyecto. De momento hemos creado una distribución con jetty integrado, para que con doble click tengas un servidor de aplicaciones arrancado con tus app's montadas y una distribución de nuestras librerías empaquetada en un simple zip (junto con las dependencias de terceros, documentación y código con ejemplos de uso del API), para los usuarios que no usen maven sigue siendo necesario este modo de distribución, a nosotros nos gusta maven pero no podemos obligar a todo el mundo a trabajar como a nosotros nos guste :P
• Maven ant-run: Quizas ant no sea lo mejor para montar un build muy complejo, pero para pequeñas tareas de copiar ficheros de un lado para otro y cosas de este estilo sigue siendo una herramienta util. Algo que a muchos no les gusta de maven es su rigidez, sin embargo con este plugin tienes la facilidad de la "convención sobre configuración" que ofrece maven y la flexibilidad de ant cuando sea necesaria. En pequeñas dosis puede ser un plugin muy util.
• maven sonar plugin: El solito te hace un analisis de tu proyecto utilizando findbugs, checkstyle, pmd, cobertura... y inserta los resultados en la bd de sonar para luego poder consultarlos desde la UI web. Esto mismo con ant lo haciamos con un buen puñado de scripts, y con maven es un simple comando. De todos modos ni siquiera lo usamos directamente, hudson cuenta con un plugin para sonar que te permite activar el analisis sonar despues de cada compilación, más facil y mejor integrado imposible.

Además de estos hemos usado algún otro como el plugin javadoc y el plugin sources para incluir los fuentes y el javadoc al lado de los .jar que distribuimos via repositorio maven, el plugin maven dependency para copiar dependencias en la distribución y se me estará olvidando alguna más seguro...

En un proyecto complejo, con varios modulos, al final lo que acabas teniendo es una jerarquia de sub-modulos, esto es algo que me encanta de maven, que soporta este tipo de proyectos de forma muy sencilla, la nuestra es más o menos así:

• Proyecto Principal
• • Api's
  • • API 1
    • API 2
    • API 3
    • API 4
    • API 5
  • Ejemplos Api's
  • • Ejemplo 1
    • Ejemplo 2
    • Ejemplo 3
  • Aplicaciones
  • • App Web 1
    • App Web 2
  • Distribuciones
  • • Distribución Con Jetty integrado
    • Distribución de API's con librerías de terceros incluidas
    • Distribución en formato EAR

Es complicadillo, lo bueno es que con maven resulta muy natural motar algo así, y utilizando la herencia en los POM's puedes poner cada cosa en su sitio sin tener que duplicar las dependencias en cada pom. Por ejemplo, las aplicaciones dependen los los API's, con lo que las dependencias no están definidas en cada aplicación sino en el pom de "Aplicaciones", esto es utilisimo para mantener el build manejable y las cosas en un solo sitio. O por ejemplo puedes cambiar en el super-pom la versión del jdbc de mysql, ejecutar el build desde arriba, y si todos tus test pasan sabes en 5 minutos que tu aplicación funciona con la nueva versión, espectacular!.

Pues de momento muy buenas, pensaba que iba a ser un cambio mucho más complejo y en menos de una semana hemos montado todo el tinglao sin mucho problema. Quitando algún tema con el encoding, alguna chorradilla con los classpath de ejecución y poco más, y más bien por nuestro desconocimiento que por culpa de la herramienta. Cuando llevemos unos meses así ya os contaré a ver si mi opinión sobre maven sigue siendo tan positiva como hasta ahora jeje.

El único problema "serio" que tenemos hasta ahora es con los analisis de cobertura, tenemos un proyecto de test funcionales donde metemos pruebas de aceptación y sistema, es decir, pruebas que afectan a código que esta en otros modulos. El problema es que el plugin de cobertura no computa esta cobertura junto con la del resto (la de las pruebas unitarias de cada proyecto) con lo que en el informe final de cobertura perdemos el porcentaje correspondiente a los test funcionales. Con lo que pasamos de un casi 70% de cobertura en los api's a algo menos de 50%. Ya os contare cuando encontremos una solución para esto. Pero vamos, si este es nuestro mayor problema... es que la cosa no va mal jeje

Cuando hace 8 años vi funcionando un gestor de contenidos me di cuenta que revolucionaria nuestra vision de la web.

Realmente las paginas personales han pasado a blogs y las web se actualizan agilmente como los periodicos.

A los informaticos nos gusta la complejidad el "juanpalomo" , si nos dejasen montariamos un sistema operativo propio o una base de datos.

Hay muchisimos proyctos del mundo java montados con sistemas "juanpalomo" en los que un gestor de contenidos, un framework de persistencia, un workflow aumentarian exponencialmente el time2market y reducirian el numero de errores.

Cuando "juanpalomo" entra en un proyecto el sistema empieza a ser inviable y a final, un buen comercial explica las excelencias de un conjunto de herramientas estandares de facto y la reimplementacion mejora el producto inicial.

Como me dijo un informatico amigo mio cuando le enseñe por primera vez el ymail de yahoo, para que queremos eso si ya esta el eudora o para que servian los foros si estaban las news ... casos parecidos me pasaron con los entornos graficos de linux ...

Los informaticos no somos usuarios y a menudo nos cuesta utilizar o ver herramientas solo para usuarios.

Incluso hay informaticos que se plantean los workflows como herramientas utiles.

El que no exista un IDE web, estilo netbeans o eclipse o que no utilizemos mas a menudo gestores de contenidos para hacer nuestras chorradas y prefiramos montar una cojoaplicacion con un framework con persistencia etc indica las razones por las que los informaticos siempre somos los ultimos en llegar a los cambios.

Decidme algo que no se pueda hacer por web y te dire un gran negocio, existe alguna version de eclipse o netbeans que corra solo en web, si tu respuesta es no hay tienes un negocio.

Pero para que nos vale si ya tenemos la version instalable.

Cuando hace 8 años vi funcionando un gestor de contenidos me di cuenta que revolucionaria nuestra vision de la web.

Realmente las paginas personales han pasado a blogs y las web se actualizan agilmente como los periodicos.

A los informaticos nos gusta la complejidad el "juanpalomo" , si nos dejasen montariamos un sistema operativo propio o una base de datos.

Hay muchisimos proyctos del mundo java montados con sistemas "juanpalomo" en los que un gestor de contenidos, un framework de persistencia, un workflow aumentarian exponencialmente el time2market y reducirian el numero de errores.

Cuando "juanpalomo" entra en un proyecto el sistema empieza a ser inviable y a final, un buen comercial explica las excelencias de un conjunto de herramientas estandares de facto y la reimplementacion mejora el producto inicial.

Como me dijo un informatico amigo mio cuando le enseñe por primera vez el ymail de yahoo, para que queremos eso si ya esta el eudora o para que servian los foros si estaban las news ... casos parecidos me pasaron con los entornos graficos de linux ...

Los informaticos no somos usuarios y a menudo nos cuesta utilizar o ver herramientas solo para usuarios.

Incluso hay informaticos que se plantean los workflows como herramientas utiles.

El que no exista un IDE web, estilo netbeans o eclipse o que no utilizemos mas a menudo gestores de contenidos para hacer nuestras chorradas y prefiramos montar una cojoaplicacion con un framework con persistencia etc indica las razones por las que los informaticos siempre somos los ultimos en llegar a los cambios.

Decidme algo que no se pueda hacer por web y te dire un gran negocio, existe alguna version de eclipse o netbeans que corra solo en web, si tu respuesta es no hay tienes un negocio.

Pero para que nos vale si ya tenemos la version instalable.

Despues de siglos sin escribir nada ya toca seguir con la serie de entradas sobre Scrum y XP, ultimamente he tenido mucho trabajo y poco tiempo para escribir, a partir de ahora espero volver a tener un ritmo más regular publicando entradas en el blog, bueno, al menos eso espero...

En la entrada anterior hablamos sobre la reunión de planificación de sprint, abordamos los requisitos previos que debian cumplirse antes de la reunión y la primera parte de la reunión, en esta entrada intentaré explicar la segunda parte de la reunión, en la que se lleva a cabo el trabajo realmente duro: planificar las historias

Las historias son funcionalidades definidas desde el punto de vista del product owner, en otras palabras, una historia debe ser algo que aporte valor al cliente, cosas como por ejemplo "permitir que los usuarios se validen a través de un servidor LDAP". Lo primero que hace el equipo con cada historia es dividirla en tareas ya desde el punto de vista tecnico para poder estimar mejor la historia. Por ejemplo el equipo podría dividir la historia anterior en cosas como:

• Crear una nueva implementación de la interfaz de validación que utilize LDAP
• Crear una nueva opción de configuración que permita elegir entre validación LDAP u otras
• Sincronizar los usuarios del LDAP con los de nuestra base de datos

Una vez que la historia queda divida en tareas técnicas el siguiente paso consiste en estimar lo que nos costará realizar la historia. Aqui hay dos posibilidades:

• Dividir N historias en tareas y luego estimarlas todas
• Estimar una historia justo despues de dividirla en tareas

En nuestro caso preferimos dividir primero en tareas todas las historias que más o menos sabemos que entrarán en el sprint y luego estimarlas, si despues de la estimación vemos que cabe alguna historia más pues cojemos la siguiente del PB y la dividimos en tareas.

Ahora pasamos a estimar en puntos cada tarea, la estimación de la historia completa es simplemente la suma de puntos de las tareas definidas para esta por el equipo. Para la planificación nosotros utilizamos la conocida tecnica de la planificación poquer (lo escribo así, porque si lo escribo bien el blog no me deja publicar la entrada..., y llevo toda la tarde pegandome con esto :P, supongo que será cosa del anti-spam o algo similar que no le gusta la palabra po.. ya sabeis...)

Esta tecnica es muy simple, cada miembro del equipo cuenta con un baraja con varias cartas como las de la imagen, el Scrum Master inicia la ronda de estimación para una tarea, cada miembro del equipo pone una carta sobre la mesa (boca abajo claro :P ) y cuando todos han decidido se levantan las cartas y se decide la estimación como el valor más aproximado a la media de lo que todos han dicho.

Mucho más importante que elegir el valor medio es la discusión que se produce entre los miembros del equipo cuando se ponen valores muy dispares, si por ejemplo alguien estima la tarea en un día y otro la estima en 5 esta claro que algo raro esta pasando, o bien el que estima en 1 día conoce alguna forma de terminar la tarea muy rapido (por ejemplo alguna librería que solventa el problema que el resto no conoce), o bien el que estima en 5 ha visto algún problema que del que el resto no es consciente (de integración con otros modulos, de viabilidad tecnologica o lo que sea).

Esto de la planificación poquer a algunes les parece "algo poco serio", sin embargo yo creo que es todo lo contrario, mucho menos serio me parece cualquier estimación kilometrica tipo condena de las de 6 meses y un día... aunque le dejes al desarrollador una semana para que estime en detalle, da igual, no va a acertar, probablemente ni se acerque, y cualquier empresa tiene un historico de estimaciones desviadas que lo demuestra, así que despues de llevar años y años fallando en todas y cada una de las estimaciones que se hacen... ¿porque no intentarlon otros enfoques?

Nuestra experiencia despues de mas de un año usando este tecnica es muy positiva, si bien al principio nos equivocamos bastante hemos ido aprendiendo de los errores y ahora nuestras planificaciones son mucho más precisas. Que no quiere decir esto que acertemos siempre, no somos nostradamus, pero si ajustamos bastante bien y como mucho se nos puede quedar una historia fuera del sprint, evidentemente ayuda que las historias sean cortas y los sprints también sean cortos, de modo que si algo se queda fuera pues tampoco es ningún drama, será la historia menos prioritaria y estará lista para el siguiente sprint en dos semanas.

Definición de terminado de una historia

Otro punto critico es definir los criterios para dar una historia por terminada, en las tarjetas de cada historia dejamos un hueco para rellenar donde pone: "¿Como probarlo?", si se cumplen las condiciones que que se indiquen en el "¿Como probarlo?" más lo que hemos definido que tiene que cumplir cualquier historia damos esa historia por cerrada.

Esto que parece facil cuando uno lo piensa en la practica es bastante complejo, en definitiva cuando defines como probar una historia estas definiendo el alcance de la misma, y no simpere es facil, es importante ponerse a definir esto junto con el product owner porque pensando en como probar la historia surjen muchos detalles que ayudan a que se entienda mejor el alcance de la historia tanto por parte del product owner como por parte del equipo.

Por ejemplo para la historia del LDAP podría ser algo tan simple como "entrar a la aplicación y cuando se nos pida usuario y password introducir los de un usuario creado en el LDAP, deberiamos poder entrar a la aplicación y en nuestra base de datos se crearía el nuevo usuario sincronizandolo con la información del LDAP".

Fijaros que simplemente con la definición anterior pueden surjir varias dudas: ¿Que información debemos sincronizar?, ¿Cuando el usuario entre por segunda vez volvemos a sincronizar la información?, ¿Si ya tenemos un usuario en nuestra base de datos con el mismo nombre que otro de LDAP que hacemos?

Estas dudas las tendrá que resolver el equipo junto al product owner y decidir que hacer en cada caso completando y haciendo lo más precisa posible la definición de terminado. En muchas ocasiones nos ha pasado que creiamos haber entendido perfectamente una historia y al ponernos a definir esta parte nos hemos dado cuenta de que no teniamos la misma visión sobre la historia que el product owner. Una de las mejores cosas de esta reunión de planificación es precisamente hablar "cara a cara" con el dueño del producto y no que todo se reduzca a un documento de especificaciones, por supuesto ambiguo.. siempre son ambiguos, que el equipo entiende como buenamente puede...

Además de el "¿Como probarlo?" de cada historia tenemos una serie de condiciones que tienen que cumplirse para dar cualquier historia por terminada, estas son generales a cualquier historia y deben cumplirse siempre:

• Aceptación: El criterio de cómo probarlo está acordado, escrito, y el programa supera la prueba. Ultimamente hemos empezado a escribir primero las pruebas funcionales de aceptación antes de tirar uno sóla linea de código de la aplicación. Tenemos pendiente revisar herramientas como fitnesse o concordion para mejorar en este apartado
• Pruebas: El código desarrollado supera las pruebas unitarias y la cobertura de pruebas ha sido revisada y considerada aceptable por el equipo.
• Calidad del código: revisar que el código cumple con las normas de estilo definidas. Por lo menos verificar que añadido el nuevo código para la historia no se disparan las graficas de incumplimiento de normas de manera alarmarte. Para mejorar esta gestión estamos introduciendo el uso de sonar, magnifica herramienta por cierto.
• i18n: El código desarrollado está internacionalizado. Es una caracteristica que se debe cumplir en toda nuestra aplicación, no tiene sentido definirla historia por historia como un criterio de aceptación.
• Trazable: El código desarrollado tiene integrado el log.
• Documentado: Existe una documentación de desarrollo sobre la historia.
• Integrado: el código esta integrado con la rama principal de desarrollo y es posible descargarlo de algún lugar y ejecutarlo para probar la historia. Vamos que no vale con "works on my machine", la historia debe estar integrada con el resto de la aplicación y funcionando.

Estas son las normas que nosotros mismo nos hemos impuesto cumplir para dar una historia por terminada, depediendo del contexto cada equipo debera definir las suyas. Esto que puede parecer mucha cosa para cada historia es fundamental si no queremos estar generando constantemente deuda tecnica, no se trata solo de terminar las historias, hay que terminarlas bien. Y es importante hacer entender esto al PO, que no son caprichos de desarrolladores quisquillosos, es que si no hacemos estas cosas luego lo vamos a pagar con un proyecto inmantenible donde añadir o modificar algo empieze a costar cada vez más y más. Me gusto una frase que lei el otro día no recuerdo donde "El factor que más influye en la productividad de hoy es la calidad del código que escribiste ayer"

Durante el año que llevamos aplicando estas tenicas hemos detectado algunos problemas que pueden echar al traste estas reuniones o convertirlas en totalmente improductivas:

• El Product Owner no tiene claras la historias. Este es el mayor problema en estas reuniones, que el product owner no tenga claro que es exactamente lo que quiera, que solo tenga "ideas vagas" y en cuanto el equipo empieza a preguntarle detalles no sepa responder adecuadamente. Cuando ocurre esto al final las reuniones se eternizan porque se dedica más tiempo a discutir el alcance de las historias (que el PO debería tener claro antes de acudir a esta reunión) que realmente en planificar las historias. Cuando ocurre esto el SM tiene que ponerle las pilas al PO para que haga su trabajo, y esto no siempre es facil porque es habitual que el PO sea alguien con más peso en la jerarquia de la empresa. Esto es habitual en organizaciones clasicas que se pasan al agilismo, pero bueno aqui el SM tiene que hacer uso de unos de los valores que exigia XP: "el coraje" :P
• Los miembros del equipo son de nivel muy diferente, esto nos es que sea un problema en si mismo, pero un desarrollador senior puede estimar algo en un punto y un junior en 5. Lo importante aqui es que el junior no se deje influir por las estimaciones del senior, si hacemos esto al final saldremos de la reunión con un sprint que podrían asumir 5 seniors, pero nosotros tenemos 1 senior y 4 junior!!. Cada cual debe tratar de ser sincero con lo que EL tardaria en terminar la historia.
• Estimaciones para cubrirse las espaldas, la gente que viene de otros modelos tiende a sobrestimar (y a veces mucho) para cubrirse las espaldas, es importante dejar claro que en Scrum lo que importa es ser realista y si luego no se puede cumplir algo tampoco se viene el mundo abajo, estamos haciendo entregas parciales cada 2 o 3 semanas, si en una entrega parcial en lugar de 3 historias van 2 y se deja la otra para el siguiente sprint NO PASA NADA. Lo importante es que la gente no estime siempre 3 puntos más "por si acaso" hay que evitar la cultura del castigo si no llegas a la estimación y fomentar una cultura de sinceridad y colaboración entre el equipo y el PO. Si hay confianza la gente dejara de usar las estimaciones como armas arrojadizas y dedicarse a dar cada uno su mejor esfuerzo por sacar las cosas adelante. Ya se que esto suena muy bonito pero en ciertas organizaciones es más utopico que otra cosa, pero bueno, hay que intentarlo!!.

Cuando ya hemos estimado todas las historias que podemos acometer dentro del sprint (a veces estimamos una más por si luego tenemos tiempo) damos por finalizada la reunión, nos llevamos nuestras cartulinas a la sala de trabajo las pegamos en la pared y empieza un nuevo sprint!.

En las siguientes entradas trataré como llevamos el tema de las demos y la retrospectiva, una vez visto esto ya entraré en materia con la parte que más me gusta, las practicas puramente tecnicas como pruebas unitarias, integración continua y todas estas cosas.

• Planificación de sprint I
• Los roles en un equipo Scrum
• El proceso de scrum
• Scrum y XP: ¿realmente lo que necesito?

En la documentacion de 2.0, http://ws.apache.org/axis2/ , viene que es mas rapido y utiliza menos memoria.

Supongo que una de las razones ademas es por la reimplementacion y por utilizar StAX (Streaming API for XML) y por utilizar lo nuevo de la MVJ 1.5.

Pero realmente cuanto es mejor, no he hecho pruebas de velocidad por que el backend suele ser lo mas lento, solo he realizado pruebas de memoria.

Para ello he utilizado el profiler que viene con la ultima version de netbeans.

He hecho una bateria de pruebas con 1.4 y con JAWS 2.1 sobre axis 2.0, he pensado que era mas sencillo y seria a la postre lo que pondria en produccion.

El resultado no ha sido espectacular solo hay una diferencia de un 18 % pero se incrementa un poco cuantos mas WebServices llamemos.

Ambos codigos los he corrido sobre MVJ 1.5 para que no haya ni ninguna ventaja.

Hace mucho tiempo que no leia noticias de javahispano y he buscado si habia algo relacionado con joomla!.
Si eso que esta en PHP pero que como soy mas de java me inclinaba por opencms que por joomla!. Pues si existe, y se puede hacer utilizando quercus y hay una opcion para que en caso de que necesites mas velocidad pagando, puedes mejorarla. Justo lo ideal para pequeños proyectos que igual se hacen medianos o grandes, pero al principio todo es pequeño.

Ahora solo tengo que buscar algo open que haga lo mismo un php4j o jphp, o seguir buscando el mercado CMS wordpress, jroller etc

Si logro arrancar joomla! en un servidor tomcat, o Oracle Weblogic que es el que mas uso os contare, sobre todo si puedo utilizar alguna base de datos que no sea mysql.

Llora como mujer lo que no defendiste como un hombre.

Esta es la frase que debemos aplicarnos los informaticos cuando en una epoca de vacas gordas no defendimos nuestros derechos y dejamos que el bodyshopping, la subcontratacion, externalizacion etc mermaran nuestros derechos.

Ahora hay un peligro mayor, se llaman programadores funcionales o de negocio, vamos unos tira lineas que utilizaran programas de ultima generacion capaces de generar 300 lineas por cada linea.

Estos programas seran poco optimos pero al igual que paso en sus inicios con el asm y con el C, cobol, etc las maquinas daran la eficiencia que no ponen las personas.

El negocio son esas herramientas y como siempre Oracle, IBM, RedHAT y toda una gran cantidad de empresas americanas dan el soporte.

Sastres y cosedoras van a llegar las maquinas de coser. Buscad vuestro queso.

Me ha surgido una aplicacion chorra, pero que se adapta perfectamente a lo que da joomla! el problema fundamental que me encuentro es que no es java y que quiza la formacion que necesito para ponerla en marcha haga que se complique, he visto alternativas java drupal , opencms porque javahispano no utiliza una de estas alternativas y si lo hace porque no lo publicita para que podamos tomarlo de referencia.

OpenCms parece mas fiable pero no tiene pagina en la wikipedia, ademas joomla tiene bastantes libros publicados de hecho he encotrado libros traducidos al español.

El reto apunta a joomla! , una salida por si java no me da de comer, pero la cabra tira al monte y si veo un ejemplo de lo que se puede hacer y hace lo que quiero ire a opencms.

Drupal, espero vuestros comentarios.