Anunciando Jobsket

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!!

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

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.

Las 5 cosas que más me gustan de grails

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

WebSphere: Para tiempos de crisis, informes afines.

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...

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

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.

Facebook viene a Dubiln

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

Transparencias de la JAOO 2008

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

Un clásico...



Via Oracle AppsLab blog.

Red Social: debug_mode=ON

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.

La guía definitiva de Terracotta

Frank Kelly publica en su blog una review del libro The Definitive Guide to Terracotta y se me ha ocurrido que debería comentarlo por aquí ya que Terracotta es un tema que ha salido eventualmente en algunos posts.

Para el que no lo conozca, Terracotta es un framework Java que permite compartir objetos entre máquinas virtuales situadas en diferentes computadoras, o como ellos lo definen:

Terracotta is Java infrastructure software that allows you to scale your application to as many computers as needed, without expensive custom code or databases.

Terracotta clusters Java Virtual Machines (JVMs) to create a shared memory pool for the application tier. This means high performance, reliable scale-out with fewer bottlenecks, with minimal code changes.

Terracotta proporciona una alternativa Open Source y barata a otras soluciones mucho más caras como Oracle Coherence o GigaSpaces.

Según la descripción de Frank el libro parece muy interesante, y entre otros temas interesantes explica como utilizar Terracotta para compartir la caché de segundo nivel de Hibernate o como replicar la sesión HTTP de un servidor entre varios servidores, así como como aprovechar la integración con Spring para hacer más sencilla la configuración.

¡Tiene muy buena pinta! La verdad es que me encantaría encontrar algún proyecto donde utilizar esta tecnología ya que parece realmente interesante.

Lo que me motiva

En Navegapolis, unos de los mejores blogs en lenguaje castellano sobre desarrollo de software Juan escribe unas cuantas citas en uno de sus posts sobre el libro el mito de la motivación sobre los resultados contraproducentes que pueden tener algunas técnicas de motivación.

Personalmente no hay nada que menos me motive que un bonus económico. Me hace sentir realmente mal. Es como si de principio entrases a trabajar con presunción de no-profesionalidad. Como si desde un principio te pusieran una zanahoria delante para que no se te olvide que a final o principios de años tendrás el premio que te mereces, por tu esfuerzo y dedicación. Y eso dejando a un lado la incertidumbre de si cobrarás ese tan ansiado "bonus" o no, ya se sabe, la crisis, la recesión, la falta de ventas, la competencia en el mercado, la dificultad del momento actual.



Claro que puede ser peor. A un buen amigo mio que está trabajando aquí en una cadena de supermercados al llegar la navidad le hicieron un regalito. Aquí en Irlanda, no se llevan las cestas de navidad, no os creáis, así que este era un detallazo que se le ocurrió a los jefes para motivar al personal. El regalo era un paquetito que si no recuerdo mal contenía unos Christmas Crackers, una corona de dorada de papel, dos manzanas gala con merry christmas grabado y una botella de pepsi de medio litro, de las doradas. Tan dorada que mi amigo al principio y de lejos se había pensado que era una botella. Imaginaros la motivación con la que salió :-) Aún nos reímos con ella hoy.

El caso es que los dos coincidíamos más o menos con lo que nos podía motivar. Y esto es lo que me motiva a mi:

• Una compañía que te deje trabajar tranquilo. Sin mucha burocracia, reuniones, control, timesheets, etc. Una compañía que confie en ti.


• Un proyecto con futuro; que presente retos para la compañía y todos los que forma; que te apetezca ir cada día a intentar solucionar nuevos problemas.


• Un conjunto de tecnologías actuales y pragmáticas. Que no se hayan escogido por escoger. Que permitan aprender y disfrutar de tu profesión al tiempo que te faciliten tu trabajo.


• Directivos, managers, responsables y arquitectos profesionales y con capacidad. Que impongan respeto y que de gusto trabajar con ellos por todo lo que se puede aprender.


• Tener un grupo diverso de trabajo. Tener compañeros de los que se pueda aprender y tener compañeros a los que les puedas ayudar a aprender lo que tú ya sabes.


• Tener un buen ambiente de trabajo.


• Estar en una empresa que te ayude a mejorar tus conocimientos; que te permita pasar tiempo leyendo artículos o videos de conferencias; que no tenga problemas en subvencionarte la asistencia a cursos o eventos.


• Un buen club social que no se limite a salir de pintas todos los jueves por la noche.


• y por supuesto... las partidas de poker a la hora de comer de los mártes y los jueves.

La verdad es que casi todas de estas condiciones se cumplen en mi empresa actual y es que las cosas menores como una simple partida de poker pueden tener un efecto mucho más motivador que cualquier bonus.

Imagen by Simon Clayson@Flickr .

Agile Spain

Agile Spain es una de las webs que están en los links de mi blog. Links que por otra parte son un desastre porque aunque están muchas de las páginas que leo, otras muchas no las he puesto y otras como ésta han desaparecido; y es que Agile Spain fue una excelente página de referencia, pero ya se sabe que mantener un portal de este tipo requiere mucho tiempo y dedicación, y muchas veces la ayuda, repercusión y reconocimiento que se obtiene es muy poca.

El caso es que José Manuel Beas me comenta que está intentando relanzar la iniciativa, esta vez en forma de grupo de Google y que pretende continuar la labor ejercida por la web. Por ahora la actividad es poca, pero seguro que si hay gente que lee el blog y está interesada en crear una comunidad de gente interesada en las metodologías ágiles pues tendrá mucha más actividad en poco tiempo. ¡El caso es ponerse! Y siempre es agradable compartir comentarios con gente que comparte intereses y profesión.

Así que aquí queda el enlace al grupo de Agile-Spain.

Spring cambia el modelo de mantenimiento, ¿y qué?

Desde luego, mira que egoistas somos. Tenemos un proyecto que probablemente hoy por hoy el 90% de los desarrolladores Java se está aprovechando de él, directa o indirectamente, y justo cuando el proyecto anuncia una nueva forma de ganar dinero nos lanzamos a criticarlo ferozmente por vendidos.

Claro, al fin de cuentas uno se acostumbra a tener unos cuantos esclavos de primera clase haciendo el trabajo que a nosotros nos llevaría años y sin cobrar ni un céntimo; y ojo con retrasarse en las releases que a nosotros nos gusta estar a la última; y apurando con esa actualización de la versión 1.1.0.2 de hace dos años que tengo un cliente un poco pesadito y necesito que me arregléis un bug que tenéis pendiente. Así que venga, que tenéis capital de riesgo y hay que ganarse el pan.

Estos dos párrafos derrochando ironia vienen a cuento de las reacciones en ese nido de trolls en el que se ha convertido lo que en su día fue una gran comunidad como TheServerSide y en el que no han tardado en despellejar a Spring por el anuncio de su nueva política de mantenimiento. Claro que tampoco es de extrañar ya que el portal ya se dedica sólo a noticias de lanzamientos de productos y rumores.

En InfoQ hacen un resumen mucho más pausado y tranquilo de el nuevo modelo de mantenimiento que básicamente viene a ser:

• Los usuarios normales (que no pagan) de Spring tendrán acceso a todas las builds de versiones mayores del producto.


• Los usuarios normales (que no pagan) tendrán acceso a las actualizaciones (bug fixes) de estas versiones durante los tres meses desde su lanzamiento.


• Los usuarios "enterprise" (de pago) tendrán acceso a todas las builds de todas las versiones incluso tras tres meses después de su lanzamiento.


• Todo sigue accesible en el repositorio de fuentes del proyecto, así que cualquier usuario puede descargarse un proyecto con los últimos parches y construirlo el mismo.

Teniendo en cuenta el último punto, en mi opinión no hay ninguna razón para protestar. A mi me parece una muy buena idea para monetizar el proyecto y estoy seguro de que muchos clientes decidirán subscribirse al mantenimiento para evitar el engorro de tener que descargarse los fuentes de una determinada versión y poder descargarse directamente una versión que puedan desplegar directamente.

Por lo demás, se supone que esto podría perjudicar a algún proyecto Open Source que necesita indirectamente los últimos parches, pero bueno realmente no creo que a los administradores de proyectos Open Sources les moleste demasiado descargarse Spring para tener los últimos parches; lo último es aplicable a cualquier persona que le guste estar a la última en cuestión de este framework.

Eso sí, ojo porque los chicos de SpringSource ya nos han sorprendido con un servidor de aplicaciones y con un nuevo modelo de mantenimiento más comercial. ¿Qué será lo siguiente?

Una historia sobre arquitectura

Juan Ignacio Sánchez Lara recoge en su blog la historia de dos años de mejora en la forma de desarrollar aplicaciones en una organización. En su organización. Los posts son muy interesantes sobre todo porque se trata de una experiencia real en una empresa real.

La serie está formada por cinco posts:

• Diseñando una arquitectura (I/IV): Estudio de la Situación Actual


• Diseñando una arquitectura (II/IV): Alternativas de solución


• Diseñando una arquitectura (III/IV): Implantación


• Diseñando una arquitectura (IV/IV): Conclusiones


• Diseñando una arquitectura (Apéndice): Trabajo futuro

Y me reitero en lo de que vale bastante la pena leerlo porque escasean los posts tan detallados sobre la historia de un desarrollo.

Me quedo sobre todo con los comentarios sobre personal y la dificultad de encontrar gente con ganas y aptitud. Sin ese ingrediente principal, sinceramente, no importa que tecnologías se utilicen, el proyecto se irá arrastrando. Una buena metodología, un buen ambiente de trabajo, la adecuada mezcla de gente de todos los niveles, y herramientas probadas y útiles es la clave para el éxito.

Y es que hoy en día es más sencillo sustituir un servidor de aplicaciones o una base de datos que una persona que posea una extraordinaria aptitud y actitud en su trabajo.

¿Lego como herramienta de gestión ágil?

Hoy, repasando lecturas pendientes me he topado con una entrada muy interesante en la que probablemente es hoy por hoy mi fuente favorita de información, InfoQ. Se trata del artículo Lego is not for kids anymore en el que comentan posts de otras personas que han encontrado en Lego una forma efectiva de gestionar su tiempo y proyectos.

Comienzan con un artículo de Michael Hunger en el que habla de como ha cambiado su forma de trabajar utilizando bloques de lego. Y de manera muy interesante. En la figura de abajo se ven cinco bloques de piezas, cada uno para los diferentes días de la semana. En cada bloque hay piezas de diferentes colores representando los diferentes proyectos y finalmente hacia arriba representaría el tiempo. ¡Realmente visual!



Por otra parte Takeshi Kakeda presentaba en la conferencia Agile 2008 una presentación acerca de como utilizar bloques de lego para la gestión de proyectos y que han subido a SlideShare.

La verdad es que no sé si estoy realmente pecando de iluso pero me ha parecido que presenta ideas muy refrescantes. La propuesta sería comenzar con una base, que prácticamente vendría a sustituir a una pizarra con postits pero añadiendo alguna dimensión más. Las siguientes son algunas de las reglas, bastante simples por cierto:

- Bloques más grandes representan bugs o issues más complicados.


- A más cerca del frente, más prioridad.


- Las fichas llevan notas con pequeña explicación o referencia a la herramienta de gestión de incidencias.

- Las dependencias se representan colocando piezas unas enfrente de otras.

Durante los últimos meses he tenido la oportunidad de disfrutar de la transparencia que te proporciona el trabajar utilizando metodologías ágiles, y personalmente creo que utilizar este sistema sería también beneficioso ya que parece muy sencillo de gestionar y mantener, añade un toque divertido a la organización, y sobretodo ofrece una visión muy sencilla de los proyectos que todo el mundo puede entender, desde el programador más junior hasta el jefe pelo-pincho.

Eso sí, supongo que habría que montar una base bien grande de piezas para cuidar un poco la imagen final del proyecto y que no esté todo apelotonado...



... y lo más importante, ¿cómo evitas que algún gamberrete se ponga a jugar con tu lego?


:-)

Los programadores de Linux y la obesidad

No me puedo resistir. Visto el drástico aumento del tamaño de las camisetas de los asistentes al Linux Symposium podríamos estar ante una epidemia de obesidad :)



Via TechCrunch.

Un pequeño problema informático de esos que valen millones

Hoy me voya desviar un poco de la temática habitual, aunque me mantendré de cierto modo dentro del mundo del software. Una de mis aficiones es la economía. Me encanta seguir los mercados, las noticias, las inversiones y todas estas cosas.

El Lunes fue uno de esos días emocionantes en las bolsas. Las empresas financieras americanas Freddie Mac y Fannie Mae se habían desplomado en la bolsa en la pasada sesión y el gobierno de los Estados Unidos había acudido a su salvación. El Lunes se esperaba una carrera de compras como no se había vivido en meses (o años). Aún así, no fue un día muy feliz en el London Stock Exchange ya que fueron incapaces de operar durante prácticamente toda la sesión.

En la prensa se comenta que la caida duró unas siete horas, y que muchos traders se vieron forzados a moverse a sistemas de la competencia para intentar operar. Wow, siete horas de inactividad en la bolsa valen miles de millones. Parece ser que todo se debió a un fallo informático dentro de un aplicativo llamado Infolect que es el sistema de envio de datos que utilizan.

En ZDNet tienen un artículo interesante que comenta más detalles sobre este sistema. Y en CIO comentan que es un sistema lanzado hace un par de años (no sé en donde leí que lo habían actualizado este verano) basado en .NET, SQL Server y desplegado en más de 100 servidores Proliant Intel 32 bits.

Parece que hace poco que LSE ha encontrado verdadera competencia en dos exchanges alternativos, Chi-X y Turquoise que se animaron a comentar el fallo y no dudaron en recomendar a todo el mundo migrar a sus redes más modernas y más baratas.

La verdad es que independientemente de si el fallo estaba en el software, en los servidores, en la red, en lo que sea, lo cierto es que este tipo de noticias son esas que leeremos en años en los libros ya que te demuestra como pequeños fallos, o sistemas no preparados para picos de carga enormes pueden generar perdidas millonarias al tiempo que impactan enormemente en la imagen de las compañías y proporcionan jugoas oportunidades a la competencia para captar a tus clientes.

A ver si algun publicación online nos desvela un poco más sobre este fallo.

El Arquitecto de Software en versión española.

En muchos países europeos, US, Japón y otros, la figura de Arquitecto de Software está realmente valorada. Ser arquitecto de software es el paso natural para muchos desarrolladores senior, y requiere sobre todo experiencia y buenas capacidades de análisis, raciocionio y abstracción. Coding de Architecture es uno de los mejores blogs existentes sobre el trabajo de Arquitecto de Software y tiene varias entradas donde se define el scope de un arquitecto o el perfil que debería tener un arquitecto.

Entre las tareas de un Arquitecto de Software destacarían:

• Definición de la arquitectura.


• Selección del software.


• Selección de la infraestructura.


• Requisitos no funcionales.


• Liderazgo.


• Mentoring.


• Metodología de los proyectos.


• Proceso de desarrollo.


• Prácticas y estándares.


• Análisis de las tendencias en desarrollo de software.


• Aporte de experiencia.


• Participar en el desarrollo.

Esta lista está recogida en este fichero PDF y es probablemente el último de los puntos que he puesto el que causa más polémica, aunque bueno más o menos está aceptado que es un bueno que un arquitecto participe de alguna forma en el desarrollo, aunque el dedicar más del 30% de su tiempo a dichas tareas indicaría que hay algo que está iendo mal.

Viendo como trabajan las empresas en el extranjero y sobre todo el reconocimiento que se le tiene a arquitectos y desarrolladores senior, a uno no le deja de sorprender el encontrarse ofertas en España buscando Arquitectos de Software con experiencia de al menos un año programando en J2EE. O mismamente la siguiente lista de requisitos para un Arquitecto J2EE en Valencia:

Descripción de la oferta
Buscamos un arquitecto en las tecnologías Java/J2EE, para proyectos de primer orden y pioneros en el ámbito de desarrollo de software. El candidato seleccionado se responsabilizará de:
-Captura y análisis de requisitos técnicos y de negocio
- Análisis y diseño funcional y técnico de proyectos de desarrollo de software
- Definición y ejecución de planes de pruebas
- Desarrollo Java/J2EE
- Realización de la documentación técnica asociada al proyecto
- Impartición de formación a usuarios y técnicos implicados en el ámbito del proyecto

Es decir en este caso Arquitecto = consultor, business analyst, tester, programador, documentador y formador. En fin, que cualquier parecido con la realidad del mundo exterior a nuestro peculiar país es mera coincidencia. Aunque está claro que en muchas empresas sí se reconocen los puestos de desarrollador senior y arquitectos, lo cierto es que todavía son la mayoría las que desconocen completamente lo que es el mundo del desarrollo de software, sus perfiles, el trabajo que se debe realizar, los roles y responsabilidades, etc. El arquitecto de software no deja ser "el que controla" o "el que nos saca las castañas del fuego".

Así nos va.

97 cosas que todo Arquitecto de Software debería conocer

Vuelta de vacaciones y tengo que reconocer que me ha costado volver a postear, y es que como leía hace poco un blogger constante necesita tener un ego suficientemente inflado para alimentar esa situación engañosa de creer que la gente necesita realmente leer lo que escribes y no podrá vivir sin ello, y al tiempo entrar en esa inercia de posteo que te permite postear frecuentemente pero que si la abandonas por un rato te será difícil recomenzar a postear.

En fin, que dicho esto voy a continuar inflando un poco más mi ego con una entrada más, que seguro que de todos modos alguno la encontrará interesante y que pasados unos meses siempre me sirven para repasar mis ideas sobre determinados temas.

El caso es que me he encontrado con una iniciativa verdaderamente interesante de O'Reilly, y que no sé si alguno la conocería ya pero que a mi me ha sorprendido gratamente. Se trata de la creación de un libro mediante un wiki comunitario en el que puede escribir cualquier persona siempre y cuando el moderador apruebe la entradas. El libro trata sobre un tema tan interesante como la arquitectura del software y se llama 39 things that every software architect should know.

El moderador que se encarga de seleccionar las entradas más valiosas es Richard Monson-Haefel. ¿Alguien se acuerda de él? Seguro que más de uno sí. Este hombre fue durante muchos años la cara de J2EE (cuando todavía se llamaba así) y escribió lo que claramente se pueden llamar biblias sobre los EJB. Que tiempos aquellos! Si hasta le había hecho una entrevista yo mismo en el 2004 (creo que el contenido no está accesible) y recuerdo bien que aunque fue amable en contestarme sólo me respondió la mitad de las preguntas dejándome bien claro que no tenía más tiempo que perder :-) Yo creo que esa entrevista le hizo replantearse las cosas y pocos meses después abandonó el mundo de Java para shock de la "comunidad".

Volviendo al tema, la idea de O'Reilly me parece realmente buena porque de esa manera muchos autores anónimos y no tan anónimos pueden compartir sus experiencias creando un libro que seguramente se convertirá en referencia de una u otra manera. En el foro que han preparado se puede ver como se pueden sugerir nuevos axiomas y también leer los comentarios sobre los existentes.

Las entradas que hay ahora mismo son realmente interesantes, y por comentar una, la más votada de todas (No pongas tu curriculum por encima de los requisitos) me ha recordado a un Arquitecto de Software con el que coincidí y que no dudaba recomendar el utilizar WebSphere MQ y Coherence para una determinada tarea porque le apetecía aprender esas tecnologías. No cabe lugar a duda de la validez de las tecnologías, pero en este caso estas tecnologías no se escogieron, para suerte para el bolsillo del cliente y para las personas que tendrían que lidiar con éstas y disgusto de esta persona en particular.

¿Algún axioma que echéis en falta en la lista?

Cerrado por vacaciones

Aprovecho el mismo título que los amigos de Linking Paths utilizaban hace unos días para un post sobre las vacaciones para comentar que este blog no va a ser menos.

Me marcho un par de semanas así que desafortunadamente tendré que dejar este rinconcito un poco descuidado. Será por poco porque espero llegar con las pilas muy cargadas. Mi destino no es muy paradisíaco, y además parece que está lloviendo (vaya cruz), pero ya lo echo de menos.



Hasta dentro de dos semanas.