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?