Bienvenido a la Jungla!!

9:47 git 1 Comments

Nota: creo que es recomendable escuchar esta música mientras leéis el post.

Y ahora... Welcome to the GitJungle!!

Acabamos de lanzar GitJungle, un pequeño explorador de repositorios de Git que utiliza nuestra tecnología de visualización de ramas de Plastic SCM (BranchExplorer, BrEx) y básicamente permite ver los repositorios de Git desde un ángulo diferente... :P

Cómo descargarlo

Muy fácil, hay que ir a nuestra nueva página de labs, leer un poco más sobre GitJungle y después descargar los binarios (recordad que para Mac y Linux necesitaréis tener Mono instalado).

Cómo usarlo

Bueno, supongo que no tengo que explicarle a nadie interesado en GitJungle cómo clonar un repositorio de Git pero para que la entrada quede lo más completa posible:

$ git clone https://github.com/jquery/jquery.git
$ cd jquery.git
$ gitjungle .

Y entonces tendremos los siguientes gráficos!!

Action not words!

Un vídeo de GitJungle en acción aquí:

Peligro - zona de experimentos!

Acabamos de lanzar la beta de GitJungle!. Es un experimento, creemos que tiene muy buena pinta y todo eso, pero no deja de ser una beta, así que no está libre de posibles problemas. Si encuentras alguno, ya sabes, ¡dínoslo!

Lo bueno es que hemos usado el mismo núcleo de código del Branch Explorer de Plastic, lo que nos permite mostrar la historia de forma horizontal en lugar de vertical como hacen GitK y otras herramientas de Git. Así que bienvenidas sean las sugerencias, los aplausos o las críticas más mordaces!

¿Por qué nos ha dado por sacar una herramienta para Git?

Como todos sabéis lo que hacemos es desarrollar y vender Plastic SCM, el DVCS comercial más potente jamás creado, el que tiene mejores visualizaciones, soporta diferentes "backends" de base de datos, seguridad integrada con soporte de ACLs, el mejor sistema de branching y merging.... vale, vale, paro ya con el rollo de marketing! ;)

Bueno, al tema, que sí, que nos centramos en Plastic, sin embargo desarrollar GitJungle nos ha llevado muy poco tiempo así que... ¿por qué no compartirlo?

Pero, respondiendo a la pregunta: estamos trabajando a tope en la próxima versión de Plastic SCM y nuestro objetivo es que sea más interoperable que nunca y que tenga sincronización bidireccional con Git!

También, Plastic SCM es un DVCS para empresas mientras que Git (aunque puede usarse en empresas) está muy enfocado a proyectos Open Source así que, ¿por qué no colaborar? La verdad es que Git está enseñando los conceptos de branching y merging a todo el mundo y educando a los desarrolladores en "desarrollo distribuido". Todo eso es muy bueno para Plastic porque así los usuarios aprecian mucho mejor qué es lo que ofrecemos. (Nota: NO, Plastic NO está basado en Git, hemos tenido que trabajar duro para desarrollar nuestro propio sistema, capa de base de datos, algoritmos de merge, seguridad y... bueno, y todas las cosas divertidas!! :P)

Linus habla sobre ramas...

22:21 0 Comments

Hace unos meses Linus Torvalds escribía sobre algunos problemas que tenían en el desarrollo del Kernel con Git debido al uso de ciertos patrones de merge.

Como aprender de Linus es siempre interesante :P me gustaría entrar en detalle en los puntos que menciona y ver cómo aplicarlo para mejorar en desarrollos del día a día (no hace falta ser un kernel-hacker para sacar partido de esas técnicas). De hecho encaja con el patrón que nosotros recomendamos con Plastic aunque lógicamente él lo aplica a Git y sería también válido con cualquier otro SCM con buen soporte de ramas.

Las palabras de Linus

Esto es lo que escribió Linus, sólo he sacado un fragmento así que para tener la visión completa lo mejor es leer el link original.

The real problem is that maintainers often pick random - and not at all stable - points for their development to begin with. They just pick some random "this is where Linus -git tree is today", and do their development on top of that. THAT is the problem - they are unaware that there's some nasty bug in that version.

Y ahora intentaré traducir lo mejor posible:

El verdadero problema es que los “maintainers” a menudo cogen puntos aleatorios – y para nada estables – como partida de sus desarrollos. Simplemente cogen un “aquí es donde está el árbol de Git de Linus hoy” y hacen sus cambios sobre eso. Y ESE es el problema – no son conscientes de que hay un fallo muy feo en esa versión.

Disparando a un objetivo móvil

¿De qué está hablando Torvalds? Realmente de un problema muy bien conocido cuando se trabaja en “trunk o mainline” (vamos, sin ramas) como describía aquí hace ya algún tiempo en la sección titulada “don’t shoot a moving target!” (no dispares a un objetivo móvil).

El problema afecta duramente a todos los seguidores de la doctrina “mainline/trunk” (ya sabéis, SVN, CVS, VSS…) ya que se están actualizando constantemente a “lo más nuevo” quizá por miedo a hacer merges. Algunos intentarán solucionarlo con integración continua (CI) pero simplemente retrasarán el problema. Lo “malo” es que también afectará a quienes usen “ramas de característica” (feature branches) a menos que sigan todas las reglas (lo que nosotros solemos definir en el patrón de “rama por tarea”).

El problema con el que se encuentran en el desarrollo del kernel se ve en esta imagen:




El equipo del kernel usa ramas y todo pero ¿qué pasa si usan “master” como rama de integración (muy común, y correcto) y crean ramas desde “commits” que no están etiquetados (tagged)? (Como muestra el dibujo).

El problema es que al usarse la rama principal como punto de integración habrá “commits” intermedios (changesets) que no serán estables (especialmente si se usan los “fast-forward” merges de Git, que no me gustan un pelo, pero que supongo que no serán el problema de Torvalds ya que seguro que sabe usar Git muy bien, ¿no???). Entonces los programadores empiezan desde un punto inestable y… comienza la fiesta.

La clave son las líneas base

Nosotros hemos tenido exactamente el mismo problema con equipos usando Plastic pero que no entendieron bien al principio la importancia de tener líneas base (baselines, releases estables o como queráis llamarlas). Una vez que el código es estable: ¡etiquetadlo! Y cread las ramas de tarea SÓLO desde puntos estables!

Esa es la regla básica: cread líneas base con frecuencia (mínimo una a la semana en equipos de menos de 10 personas y más si el equipo crece) que por supuesto deben estar totalmente probadas (juego de test automático y cualquier tipo de prueba accesoria o manual que hagáis, de hecho esta es la parte larga de hacer integraciones, los merges, hoy por hoy, tienen que ser muy rápidos) y CREAD LAS RAMAS SÓLO DESDE BASELINES ESTABLES como muestra la siguiente figura:



De esta forma si algo falla en tu rama de tarea (o feature branch) sabes que… ¡es por tu culpa!, porque todos los tests estaban bien en la línea base (no sólo el juego rápido que puedes pasar en CI, también los que tardan horas).

Una regla muy, muy sencilla y con enorme ahorro en tiempo y dolores de cabeza!

Anunciando Plastic SCM Community Edition

22:51 noticias 1 Comments

Ha pasado casi 1 mes desde que hicimos el anuncio oficial de Plastic SCM Community Edition en nuestro blog en inglés.

Aunque somos una empresa española nuestra audiencia y nuestros usuarios son la mayoría de fuera y de ahí que siempre publiquemos primero en inglés.

Pero me parece que no viene mal incluir, aunque sea con un poco de retraso, la noticia del lanzamiento aquí.

El objetivo de Plastic SCM Community Edition es llegar a un número elevado de equipos de desarrollo pequeños y medianos (de ahí lo de hasta 15 usuarios de la licencia gratuita). Plastic es un sistema SCM de última generación (distribuido, con muy buen soporte de ramas, etc, etc) y nuestro objetivo con esta iniciativa es llegar a muchos equipos pequeños (que son mayoría en todo el mundo) dentro de empresas. ¿Por qué esto de "dentro de empresas"? Pues porque para proyectos open source, a pesar de que Plastic es ilimitado y gratis para ellos, ya hay alternativas excelentes como Git y Mercurial que han nacido en el entorno OSS y que están pensados para ese tipo de proyectos. Sin embargo Plastic ha sido diseñado y desarrollado para empresas. ¿Cuál es la diferencia? Pues (generalizando) que características como la seguridad basada en ACLs, integraciones nativas con los IDEs, almacenar los datos en bases de datos relacionales estándar (a elegir: Firebird, MySQL, SQL Server, Oracle e incluso SQLite) y por supuesto nuestra cuidada interfaz gráfica han sido una prioridad para nosotros y algo que sabemos que los desarrolladores valoran cuando buscan un sistema para su trabajo. La propia gestión de ramas (inmutables y persistentes en Plastic contra mutables y un potencialmente volátiles en Git, por ejemplo) está más orientada al uso en empresas.

Normalmente las empresas buscan herramientas que sean fáciles de poner en marcha, que tengan soporte comercial de primer nivel, que no les den muchos quebraderos de cabeza... y eso es lo que ofrecemos con Plastic para todo tipo de empresas y con CE para las más pequeñas.

Además consideramos que la situación económica actual fuerza a muchos equipos a no gastar dinero en software, de ahí también la iniciativa: facilitar y universalizar las mejores prácticas de SCM.

Plastic evoluciona muy rápido y podéis estar al día de todo lo que hacemos a través de twitter (@plasticscm).

Espero que nos ayudéis a extender el mensaje!

La historia del control de versiones

12:01 noticias 18 Comments

La Gestión de Configuración de Software (Software Configuration Management, SCM, o Source Code Management para los hackers de verdad) existe ya desde hace una buena temporada y ha ido evolucionando lentamente desde los lejanos días casi prehistóricos en los que era casi una labor manual hasta la brillante actualidad de los sistemas DVCS (Distributed Version Control System).

Todos habéis usado al menos uno de los SCMs de la lista siguiente pero, ¿eres consciente de lo viejo que es el sistema que usas? ¿Conoces los grandes nombres? Vale, pues voy a intentar hacer una breve recopilación.

A grandes rasgos…

En el diagrama he colocado la mayoría de los principales nombres de la historia de los SCM. Sí, sí, ya sé que falta StarTeam, falta el nuevo sistema de IBM, ¿cómo se llama? RTC? Pero es que no me caben todos así que he dejado a los más feos fuera de la foto :P. En cualquier caso, escribe un comentario para hablar de tu sistema favorito (o el que más odias, o el que más has sufrido) tanto si me lo he dejado como si me he acordado de él...



Por si todavía te sientes bien usando uno de los “old irons” (hierracos :P), he añadido unas fotos debajo de cómo eran los teléfonos móviles de la época… para que no te quede más remedio que sentirte viejo y totalmente desactualizado :P.

Vamos, que si todavía estás usando CVS y piensas que “vale, está bien”, echa un vistazo justo debajo de “CVS” en el gráfico … ¿No te sientes como el protagonista de Wall Street, el dinero nunca duerme (Gordon Gecko/Michael Douglas) cogiendo el teléfono-ladrillo antes de salir de la cárcel? Pues eso. ;)

Nota: en los comentarios de mi post original en inglés algunos empezaron a protestar diciendo “eh, qué pasa, que porque un software haya empezado hace 20 años quiere decir que ya no sirve?”. Evidentemente no me refiero a eso. (Hay un comentario muy gracioso de un tío que usa el “grep” y protesta amargamente… para troncharse). El tema es que cuando el sistema evoluciona, pues no hay problema, pero hay sistemas en este dibujo de arriba que llevan muertos, sin evolución, con diseños anticuados, desde hace muchísimos años, y deformando la forma en la que los desarrolladores ven lo que es un control de versiones… A eso me refiero…

La prehistoria

Hubo un tiempo en el que las versiones se guardaban a mano. Vale, para muchos de vosotros ese tiempo no eran los 80 sino hace mucho menos, cuando en la universidad guardabais las prácticas con nombres como practica.zip, practica-version2.zip, practica-buena.zip, practica-buena-de-verdad.zip… Bueno, pues lo creáis o no, había un tiempo en el que la gente trabajaba sin SCM… era un tiempo sombrío y los programadores vivían en cuevas…

SCCS

Nota: añadido por petición de los lectores más nostálgicos!

En 1972 cuatro de los mejores hombres del ejército de los Estados Unidos que formaban un comando.... Espera! Para! Que me he equivocado de película...

En 1972 apareció SCCS y se quedó con el mejor nombre "Source Code Control System" así que a partir de ahí los demás han tenido que inventarse otros nombres porque ese ya estaba cogido... ;) Lo más interesante, además de ser uno de los primeros de verdad, es que su formato interno sigue usándose por TeamWare y BitKeeper. Más allá de eso... SCCS está ya fuera de combate, pero la historia no estaría completa sin él. (Gracias a los lectores por las notas!).

RCS

Y entonces llegó 1982 y RCS vio la luz (bueno, y naranjito, pero esa es otra historia). RCS no es un gran avance tecnológico pero todavía lo puedes encontrar en diferentes distribuciones de Unix. Es sencillo y va directo al grano.
Una buena característica era que los cambios de texto se almacenaban como deltas (muy importante teniendo en cuenta que los discos de la época no eran muy grandes). Los deltas todavía se usan actualmente en la mayoría de los SCMs.

Algunos inconvenientes y carencias que merece la pena mencionar:

Sólo soporta texto

No hay repositorio central. Cada fichero controlado tiene su propio repositorio en el formato de un fichero RCS, guardado cerca del propio fichero. Por ejemplo, el fichero RCS para /usr/project/foo.c será /usr/project/foo.c,v.

Para crear un workspace (espacio de trabajo) los programadores creaban links simbólicos a los directorios RCS. Ejemplo: symlink de /usr/home/John/RCS a /usr/project/RCS.

La nomenclatura de versiones y ramas es… hostil. Una versión podría llamarse 1.3 y una rama 1.3.1 y una versión en la rama 1.3.1.7.

La época clásica

En el mundo de los SCM, la época clásica fueron los 90.

CVS

Todo empezó con CVS (Concurrent Version System) en 1990. Era capaz de gestionar múltiples versiones desarrolladas de forma concurrente en diferentes máquinas y almacenadas en un servidor central. La era cliente-servidor estaba naciendo y los desarrolladores sacaron partido de ello.

CVS era capaz de gestionar versiones de forma decente. Incluso soportaba ramas y merges (branching and merging) aunque no era muy bueno haciéndolo. Y esa es una de las razones por las que hay tantos programadores a los que les da miedo la letra “B” y la letra “M”… :P

CVS no trazaba cambios en directorios o en nombres de ficheros (¡olvidad los refactors!) y necesitaba hacer bloqueos de todo el repositorio para muchas operaciones. CVS está totalmente desactualizado ahora pero… ¡funcionaba en los 90! Regla de oro: si estás usando CVS… no le des muchas vueltas… ¡¡cambia a otro sistema moderno!! Cualquiera (repito, cualquiera) será mejor. (Esto va dedicado a los equipos que evalúan 3 SCMs, encuentran pegas a todos y … ¡¡siguen usando un CVS o un VSS!!. En fin.).

PVCS

Polytron Version Control System (PVCS) vio la luz en 1985 y después fue cambiando de mano en mano a través de compras de empresas y fusiones: Polytron, Sage, Merant y finalmente Serena.
Es un sistema viejo y desactualizado, inicialmente diseñado para evitar desarrollo concurrente usando bloqueos de ficheros, pero todavía mantenido por Serena Software.

Clearcase

En 1992 nació una de las mayores bestias de la historia del SCM. Clearcase estaba claramente adelantado a su tiempo y para muchos es todavía el SCM más potente jamás construido.
Sin evolución clara, demasiado caro y demasiado complejo de administrar (en los viejos tiempos tenías que compilar un nuevo kernel de Unix para que funcionase la bestia!), el bueno de CC ya no es el tío guay de la ciudad, de hecho casi ya no se puede leer nada sobre él en la red. Pero, es todavía muy bueno con ramas y merges y tiene algunas características únicas, como las legendarias “vistas dinánicas”. Aunque potente, CC viene de una época en la que el espacio en disco era muy escaso y las redes eran LANs, sin preocupaciones por cosas como la latencia o trabajar tras un firewall.

Atria, el desarrollador original de Clearcase, se fusionó con Pure (cuando lo dirigía Reed Hastings, ahora el jefe de Netflix), luego fue adquirido por Rational y finalmente por IBM. Y entonces el poderoso Clearcase dejó de evolucionar. Bueno, evolucionó hacia UCM a principios de 2000, que básicamente sirvió para quitarle todas las características buenas y dejar sólo las malas, junto con un precio demasiado caro. No fue muy buena idea.

A pesar de todo Clearcase sigue siendo uno de los SCMs más usados por grandes empresas en todo el mundo, y según los analistas, uno de los líderes en cuanto a facturación.

VSS

Todos los sistemas de mi lista han tenido su momento y ventajas claras respecto a sus predecesores. Todos menos Visual Source Safe. VSS ha sido un sistema flojo desde el primer día, forzando a los desarrolladores a coordinar su trabajo mediante bloqueos, prohibiendo el desarrollo paralelo y creando una cultura de “miedo al merge”. Nota: vale, ya sé que se puede llegar a hacer un poco de desarrollo paralelo con VSS configurándolo para trabajar sin el modo de bloqueo… pero vamos, que creo que es menos doloroso dormir en una cama de clavos.

Lento, lleno de fallos, limitado por todos los lados, VSS ha sido uno de los sistemas más utilizados por los desarrolladores en Windows en todo el mundo (¡ojo! Por los desarrolladores EN Windows, no los desarrolladores DE Windows, que en Microsoft la gente de los equipos punteros jamás utilizó esta aberración). VSS todavía está en uso, extendiendo el dolor y el miedo entre ingenuos programadores de buen corazón.
Pero sí que hay una cosa en la que VSS estaba por delante de su tiempo: debería pertenecer a la categoría de “la oscura edad media del SCM” (ver debajo) en lugar de a la era clásica.
VSS, eso sí, es totalmente gráfico y esa ha sido una de las principales razones de que se haya usado tanto (eso y que venía con Visual Studio ;) ).

Perforce

Perforce (P4) es una de las empresas de software independientes que están totalmente centradas en SCM y que luchan por llevarse el oro del mercado SCM contra los grandes gigantes del sector. Es todavía uno de los líderes del mercado en el rango de empresas medianas con equipos grandes, y tiene una presencia muy fuerte en ciertos nichos de mercado, como por ejemplo el sector de los video-juegos.
Cuando salió a mediados de los 90, Perforce era uno de los sistemas más potentes y asequibles hasta la fecha. Estaba infinitamente por delante de VSS y de SVN aunque nunca llegó al nivel de Clearcase (ni en funcionalidad, y me refiero a branching y merging, ni en precio y complejidad), pero podía machacarlo en precio, rendimiento y facilidad de uso.

Al ser un sistema centralizado y no demasiado bueno con ramas y merges (las ramas se implementan como subdirectorios) Perforce no parece ser la mejor opción de futuro, pero es innegable que es muy sólido, muy maduro y muy bien establecido en el mercado. Eso le ayudará a seguir creciendo. Ahora mismo, Perforce es todavía el sistema que gestiona todos los grandes repositorios dentro de Google. No está mal, ¿no?

Y llegó la edad media

Un tiempo de oscuridad en la que la mayor parte de los avances previos se perdieron y sistemas claramente menguados florecieron…

Subversion

Subversion fue concebido como un “CVS mejorado” y sus desarrolladores lo lograron: es mejor que CVS. Punto.

Mientras que sistemas como Clearcase eran ya perfectamente capaces de gestionar el desarrollo paralelo mediante branching y merging, Subversion (SVN) es el responsable de que una generación entera de desarrolladores se formase con la idea de que hay que evitr las ramas y los merges a toda costa. Esto creó un daño global que todavía persiste y sólo está empezando a curarse gracias al auge de los DVCS.
SVN estaba cerca de P4 en características y se extendió como una enfermedad contagiosa: más de 5 millones de desarrolladores usan SVN cada día en todo el mundo. ¡¡Tremendo!!

Subversion es muy sencillo y evangelizó a todo el mundo en el “desarrollo en línea principal” (mainline development model). Una técnica propensa a errores en proyectos que no sean de juguete, ayudó a crear técnicas como “integración continua” como forma de “evitar merges”. Aunque la idea es buena, muchos de los conceptos en las que se basa surgen únicamente de las limitaciones de SVN.

El mismísimo Linus Torvalds cargó contra Subversion cuando presentó Git en 2006.
La realidad es que Subversion ya no está de moda y la mayor parte de los proyectos open source importantes en todo el mundo se han ido de Subversion durante 2009 y 2010. Un buen síntoma de lo equivocado que Subversion estaba. Pero todavía está muy extendido y no será extirpado en décadas.

AccuRev

Aunque nació en una época de oscuridad marcada por SVN, AccuRev fue diseñado como una forma nueva de hacer control de versiones. Su forma original de hacer las cosas todavía es novedosa parra muchos desarrolladores.
AccuRev tiene un soporte muy bueno de ramas (“streams” en su jerga) y de merges. Ha jugado un papel esencial ayudando a empresas a moverse fuera de Clearcase y de sistemas más antiguos como CVS.

El Renacimiento

Tras una época de oscuridad una nueva generación de sistemas SCM rompieron el “status quo”. “El mercado de SCM es muy maduro y estable” repiten todavía algunos analistas como loros, pero la nueva generación ha entrado en escena rompiendo con todo lo establecido.

Capaces de romper las cadenas de Internet y de trabajar desconectados (unplugged, como las estrellas de rock más “cool”), la nueva generación es también excelente haciendo branching y merging, lo que se conoció como “la madre de todos los males” durante la anterior edad oscura. Estos sistemas han podido romper con el pasado y proclamar “las ramas y los merges son buenos” marcando una nueva dirección.

BitKeeper

BitKeeper fue uno de los innovadores en el área de los DVCS. Diseñado por Larry McVoy (que antes trabajó en TeamWare, el sistema interno de control de versiones de la mismísima Sun Microsystems, construido usando SCCS como base y con una larga historia de evolución por detrás) saltó a la fama en 2002 cuando los desarrolladores del kernel de Linux comenzaron a usarlo. Entonces comenzó una guerra de email con algunos programadores protestando por usar un sistema comercial para gestionar el desarrollo del proyecto open source más conocido del mundo. Las cosas se pusieron todavía peor en 2005 cuando las luchas entre los programadores principales del kernel fueron a más. BitMover, la empresa detrás del producto, se comenzó a preocupar por que hicieran ingeniería inversa a su código, cortó el soporte a los proyectos open source e irónicamente desencadenó la creación de Git para cerrar el hueco creado.
Para más información echa un vistazo a http://en.wikipedia.org/wiki/Bitkeeper.

Git

Linus Torvalds, el mismísimo creador de Linux, diseñó e implementó la primera versión de Git (prácticamente durante un fin de semana, al puro estilo hacker) para dar a sus programadores del kernel una alternativa a BitKeeper. Linus no sólo hizo el diseño original (simple, sencillo… ¡¡genial!!) sino que fue vital para promover el proyecto con su estilo único (mira See http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html). Durante su famosa presentación criticó duramente (vale, insultó abiertamente) a CVS, Subversion e incluso Perforce. Dijo perlas como “Subversion ha sido el proyecto con menos sentido que jamás se ha empezado”, “si te gusta usar CVS es que deberías estar en un centro mental o algo así” y “Deja de usar Perforce, es triste, pero es cierto”. Puedes odiarlo o adorarlo pero está claro que Linus dejó algo muy claro: la edad media de los controles de versiones ha pasado y ahora los DVCS dominarán el mundo, erradicando el miedo ancestral al branching y merging, un concepto vital en todos los sistemas de control de versiones distribuidos.

Durante los siguientes años, y especialmente desde 2009, todos los proyectos open source importantes del mundo migraron de Subversion a Git (y aquí www.github.com ha sido clave mediante un fantástico sistema de hosting) convirtiéndolo en uno de los SCM más guays y potentes del mundo.

Git se basa en una estructura de grafo acíclico dirigido (DAG, directed acyclic graph) en el que la principal unidad de cambio es el changeset (o commit en su jerga). Git implementa merge tracking completo pero a nivel de “commit” en lugar de a nivel de revisión (como, por ejemplo, hace Clearcase). Es muy rápido y las únicas pegas son el manejo de ficheros grandes y la restricción de tener que replicar los repositorios completos.

Git está claramente influenciado por sus raíces como herramienta de desarrollo del kernel de Linux y obviamente no es el sistema más fácil de usar del mundo. Pero definitivamente será el SCM de la próxima década. Recomiendo leer el siguiente libro, que me parece buenísimo: http://peepcode.com/products/git-internals-pdf.

Mercurial

Mercurial (Hg) fue anunciado en Abril de 2005, también a toda prisa tras la decisión de BitMover de eliminar el soporte de su versión gratuita. Hg es el otro DVCS open source junto con Git. Incluso pueden conectarse bastante bien: Scott Chacon, el “evangelista de Git” y uno de los mejores escritores sobre SCM que he visto, preparó una integración bastante buena: http://mercurial.selenic.com/wiki/HgGit.

Pero Hg es bastante diferente de Git en cuanto a su diseño interno. Ambos comparten el concepto de commit/changeset como unidad de cambio. Git implementa sus commits basándose en árboles, cada árbol apunta a un árbol más antiguo y así sucesivamente (de ahí lo del grafo acíclico). Con Hg cada changeset es una lista completa de todos los ficheros y directorios, y se le llama revlog (internamente la implementación del propio revlog está basado en deltas por lo que el almacenamiento es eficiente).

Para más información sobre Hg, incluyendo cómo funciona internamente, merece la pena ver http://mercurial.selenic.com/wiki/Design y http://mercurial.selenic.com/wiki/DeveloperInfo.

Mercurial también proporciona un merge muy potente pero su sistema de ramas es un poco diferente a los otros controles de versiones. Tiene “ramas con nombre” pero la preferencia es crear un nuevo repositorio como rama separada en lugar de tener varias “cabezas” (heads) dentro de uno sólo.

Joel Spolsky (el de joelonsoftware.com, un blog buenísimo) ha escrito un tutorial muy bueno sobre Hg (hginit.com). La empresa de Spolsky, Fog Creez Software, acaba de lanzar Kiln, un SCM comercial aprovechando el esfuerzo open source hecho con Hg… No es listo ni nada el tío, y nosotros desarrollando un SCM completo… :P

Darcs

Darcs (Darcs Advanced Revision Control System) es otro intento de quitarse del medio a SVN y a CVS. Empezó en 2002 y ha continuado evolucionando desde entonces, llegando a la versión 2.5 en Noviembre de 2010.
Las mayores limitaciones de Darcs han sido siempre el rendimiento y su forma un poco diferente de manejar la historia: en lugar de hacer “snapshots” (commits o changesets capturando un estado completo del proyecto en un instante dado) maneja “patches” pero de un modo que hace que recorrer la historia sea difícil de entender (un estado concreto puede no haber sido nunca una situación real del desarrollo).

Bazaar

Bazaar (bzr) es otro DVCS open source que intenta traer un poco de aire fresco al mundo del SCM. A pesar de ser menos usado que Git y que Mercurial, Bazaar introduce características interesantes como la posibilidad de trabajar también de forma centralizada (de hecho los DVCS puros no consideraban tener servidores centrales en su diseño original).
Bazaar ha sido desarrollado por Canonical (sí, la empresa de Ubuntu!) y se pasó a licencia GNU al principio de 2008.

Plastic SCM

Plastic es un DVCS diseñado para ser usado en empresas en lugar de en proyectos open source a diferencia de Git y Mercurial. La primera versión de Plastic salió a finales de 2006 centrándose en branching y merging, con trazabilidad de merge completa (merge tracking) y soporte de renombrados en los merges. Proporciona un entorno de trabajo fundamentalmente gráfico, con muchas visualizaciones como por ejemplo el árbol de historia en 3D o el “explorador de ramas”. Esto es uno de los puntos que lo diferencian de los DVCS open source que están orientados a usuarios que usan más la línea de comandos.

El objetivo de los desarrolladores de Plastic (recordad que soy uno de ellos) es llegar a equipos pequeños y medianos y cerrar el hueco que había entre los grandes sistemas como Clearcase y los de menor nivel como SVN, con un producto tan potente como los primeros, más fácil de usar, rápido, pero asequible (de hecho hemos lanzado una Community Edition gratuita en Noviembre de 2010).

Plastic se centra en el concepto de desarrollo paralelo y recomienda el uso del patrón de “rama por tarea” (feature branches). Puede gestionar miles y miles de ramas sin problema. Plastic también es distribuido, soportando desarrollo desconectado, haciendo “push” y “pull” de ramas y gestionando posibles conflictos.

Team Foundation Server

Microsoft también ha querido meterse en el mercado de SCM/ALM y lanzó Team Foundation Server (TFS). Un esfuerzo para curar el dolor creado por su propio demonio: Source Safe.

A pesar de que TFS no es muy bueno como sistema de control de versiones (es el chico nuevo en el barrio SCM pero usando tecnología de la década pasada) viene con un montón de herramientas accesorias como gestión de tareas, sistema de test integrado, etc, al más puro estilo “paquete corporativo con todo en uno”.

No harás muchas ramas ni muchos merges ni desarrollo distribuido si vas a TFS, pero quizá tu empresa ya lo tiene junto a su subscripción de MSDN.

Agile Retrospectives (III): Actividades (I)

18:42 0 Comments

Actividades para preparar el escenario.

Check-in

Haz una pregunta y que cada miembro la vaya respondiendo, por turnos, en una o dos palabras. Ejemplo: ¿Cuál es tu impresión del último sprint?

Focus on / Focus off

Prepara pares de palabras o conceptos interesantes, forma grupos en los cuales cada grupo discuta un par diferente.

ESVP

Cada miembro anota, anónimamente, sus impresiones sobre hacer el retrospective según su opinión o estado de ánimo: Explorer (interés alto), Shopper (interesado pero que sea rápido que tengo que volver a mi trabajo), Vacationer (estoy aquí por perder tiempo), Prisoner (estoy aquí por obligación; preferiría estar trabajando).

Working agreements

Hacer grupos. Cada grupo propone una serie de ideas para comportamientos efectivos y mejorar la productividad. Al final se exponen y se eligen de 3 a 7 propuestas. El equipo al completo se hace responsable de que todos lo cumplan.

Actividades para recopilar datos.

Timeline

En grupos, decidir eventos, actividades, etc. importantes durante la iteración que acaba de terminar. Momentos clave, momentos buenos, malos, etc. Recopilar los datos y elaborar una línea temporal común.

Triple Nickels

Formar gurpos. Cada miembro tiene cinco minutos para anotar acciones de mejora en un papel. Transcurrido ese tiempo, se lo pasa el miembro de su derecha. Al final, se recopilan las notas y se ponen en común. El objetivo es tener la mayor cantidad de ideas posible. Si el equipo es menor de 7 u 8 miembros, hazlo en un sólo grupo. Se escriben sentimientos, eventos, reacciones importantes que hayan ocurrido durante el sprint.

Color code dots

Usar junto con Timeline. Una vez tenemos el timeline, cada miembro pinta un círculo rojo o verde según la impresión que le ha causado cada evento del Timeline. Al final, analizar qué actividades han dejado una mejor / peor impresión y discutir el porqué.

Mad Sad Glad

Identificar con colores en el timeline qué períodos hicieron sentir a cada miembro estresado, triste o contento. Extraer conclusiones y analizar períodos mejores y peores.

Locate Strenghts

Preguntar, por parejas, los puntos fuertes del sprint. No se trata de dialogar ni discutir, sino de entrevistar.

Satisfaction Histogram

Hacer un historgrama con las impresiones recogidas en cada sprint de cada miembro. Acota el grado de satisfacción y que anónmamente, cada miembro escriba su número. Variación: en lugar de impresión personal, valoración como equipo. Analizar resultados al final y evolución del historgrama.

Team radar

Se establece una serie de factores u objetivos a analizar y cada miembro puntúa desde el punto de vista del equipo: ¿cómo de bien hace el equipo el factor …? Discutir los resultados.

Like to Like

Cada miembro destaca los eventos que han ido especialmente bien en su opinión. Es importante analizar la opinión de cada uno: cada miembro elabora una lista con 3 cosas que hay que dejar de hacer; 3 cosas que hay que seguir haciendo y 3 cosas que habría que empezar a hacer. Se van destapando uno a uno estos factores y los demás destapan “cartas de calidad” que manifiestan su valoración. Para agilizar, la última carta en ser destapada queda eliminada. Dar tiempo a pensar antes del destape.

Y en la siguiente entrega…

Actividades para generar reflexiones, para decidir qué hacer y para cerrar el retrospective.

---

Referencias:

Agile Retrospectives – Making good teams great

Esther Derby, Diana Larsen

Recortes, el arma secreta de la gestión de proyectos

11:50 scrum 0 Comments

Una nueva entrada en el blog de agile-cyl que creo que es interesante! :)

http://agilecyl.org/2010/08/26/recortes-el-arma-secreta-de-la-gestion-de-proyectos

Nuevo "view switcher" y vídeos en Mac

11:59 noticias 0 Comments

En 3.0 hemos introducido en la GUI una característica que muchos usuarios estaban esperando: poder cambiar de vista activa usando teclas. Algo básico, pero que todavía no teníamos.

Así que hemos desarrollado un "view switcher" (cambia-vistas): pulsando CTRL-TAB se muestra una ventana que te permite ir saltando de una vista a otra.

He grabado un vídeo corto, esta vez en Mac OS X en lugar de en Windows, para que se vea un poco de cómo queda Plastic en Mac.

Por cierto, que es interesante, para los desarrolladores de Mono, ver como su MWF queda con un poco de diseño ;)



Queda bien, no?

Tengo algún vídeo más en Mac, mostrando el branch explorer (de nuestro repositorio, así que montones de ramas), que subiré en los próximos días.

Pero, primero, un vídeo más en Mac, esta vez mostrando la nueva "code review", una de las características importantes en 3.0. (Recordad que el vídeo se puede poner a pantalla completa y en HD)



Lo bueno de esta característica es que todos los usuarios de Plastic tendrán ahora code review integrada, y además es, que sepamos, la primera code review distribuida...

Xmerge para integrar código refactorizado

16:51 merge 2 Comments

Llevamos unos días con bastante movimiento. Primero lanzamos 3.0, luego anunciamos el nuevo Xdiff, después hicimos una comparativa entre varios controles de versiones bajo escenarios de carga, y machacamos a Perforce y a Subversion, así que ahora voy a ver si puedo explicar, de la forma más simple posible, cómo funciona el nuevo Xmerge.

Mezclando código que se ha movido

Si no te aclaras muy bien con lo que estoy explicando sobre diff y merge, creo que sería mejor que empezases con el post que escribí la semana pasada sobre Xdiff. Hay un vídeo corto y todo por si no te apetece mucho leer :-P.

Básicamente Xmerge aplica la tecnología que hemos desarrollado para Xdiff dentro del proceso de merge (mezcla o integración). El escenario es muy sencillo:

Tenemos un fichero con algo de código

Tu vas y mueves un método de sitio, desde la parte de arriba hasta abajo, por ejemplo (porque prefieres los privados al final, o símplemente porque sí).

Mientras tú haces eso, en mi propia rama de tara, yo voy y cambio el método en su posición "original".

Y ahora te toca hacer el merge... ¿Resultado? Pues un rollo a menos que tengas Xmerge :-P

Código original

Vamos a empezar con un código muy sencillo como el de la siguiente imagen:

Alguien mueve el método "multiply" hasta abajo

El método "multiply" es privado así que vamos a ponerlo al final.

Una vez movido comprobamos las diferencias en Plastic:

Y mientras tanto alguien 'refactoriza' el método original

El método "multiply" no es precísamente una maravilla... :). Vamos a cambiar alguna cosa:

Estructura de ramas antes de integrar

Aquí está la estructura de ramas tal y como la dibuja Plastic justo antes de hacer el merge (recuerda que he usado una rama diferente para cada cambio, rama por tarea... lo de siempre!).

Ejecutando xmerge

Cuando hagamos el merge de las dos ramas hacia /main (bueno, la primera no va a protestar porque es un cambio directo) obtendremos un conflicto como el siguiente:

Lo bueno de Xmerge es que lo detecta y te muestra un botón 'xmerge' para avisarte de que te puede echar una mano para resolver este lío. (Haz clic en la imagen de debajo para hacerla más grande).



Vale, de qué va esto?

Xmerge detecta que el bloque de código que estás intentando mezclar ha sido movido. Así que detectará también a dónde se ha movido y lanzará un "submerge" sólo de los fragmentos involucrados. Así puedes resolver el conflicto de manera más simple y una vez que lo tengas, el resultado se "pegará" en la herramienta de merge original.



No sé si queda claro porque es un caso avanzado, pero ninguna herramienta es capaz de hacer algo como esto... Es la tecnología de merge más avanzada del mercado! :)

Resultado del cross-merged

Allá va:

Y la peli...

Bueno, para los que prefieran "ver la peli en lugar de leer el libro"... :)

Ponedlo a pantalla completa porque lo he grabado a 1024x768 así que debería verse muy bien.

Conclusión

Bueno, no es la funcionalidad más sencilla de explicar de todas las que hemos desarrollado así que... preguntad!

Esta es nuestra segunda versión de Xmerge. La primera (en Plastic 2.8) era ya capaz de hacer todo lo del "submerge" pero el usuario tenía que localizar el código movido a mano. Ahora es el propio Xmerge el que es capaz de localizar el código movido (de eso va toda la tecnología, claro).

Estamos preparando más cosas en esta línea, así que atentos al blog :)

Xdiff para ver diferencias de código movido

13:27 noticias 1 Comments

Una de las características más importantes que acabamos de sacar para 3.0 es el nuevo Xdiff. Lo llamamos "cross-diff" porque localiza código movido y lo solíamos dibujar en papel con líneas que se cruzaban entre el código original y el movido...

Bueno, vamos a ver por qué esto es tan bueno...

Empecemos con un trozo de código como el siguiente:



Y entonces movemos un fragmento un poco hacia abajo:



Y después de haberlo movido modificamos el código como se ve aquí:



Y a ver qué es lo que puede hacer el Xdiff de Plastic!



Como veis puede localizar código que se ha movido incluso aunque después se haya modificado. Y se puede hacer click en el botón de "mostrar diferencias" que lanza un nuevo "subdiff" con el fragmento que ha detectado como movido para poder ver en detalle qué ha cambiado.



Mola, o no???

Podemos detectar el código movido en cualquier lenguaje de programación porque el algoritmo no se basa en parsing sino en detección de texto plano (os suena Levenstein?? :-P).

En el siguiente vídeo se puede ver el Xdiff en acción.



Espero que os guste!

Acabamos de lanzar Plastic SCM 3.0!

15:34 noticias 3 Comments

¡¡Plastic SCM 3.0 ya está disponible para descargar!!

Nos ha costado casi 400mil líneas de código y 83 sprints (usamos SCRUM) llegar aquí desde la versión 1.0, pero 3.0 es la mejor "release" que hemos hecho hasta ahora.

Por un lado tenemos muchas características nuevas: desde Xmerge/Xdiff (capaz de mostrar diferencias en los merges y en las diferencias, algo que ninguna otra herramienta del mercado tiene!) hasta revisión de código integrada, y por otro muchísimas mejoras de usabilidad (cosas que nos habían pedido varias veces, otras que hemos encontrado nosotros mismos) y como siempre de rendimiento (3.0 es un 30% más rápido que 2.9 en nuestras pruebas de carga).

En Códice tenemos un equipo mucho más pequeño que el de nuestros competidores: desde Accurev (www.accurev.com) a Perforce (www.perfoce.com) pasando por Clearcase (el sistema más extendido a nivel empresarial, ahora de IBM), Team Foundation Server (el ALM de Microsoft, que a nivel de control de versiones es un chiste comparado con Plastic) e incluyendo Subversion y los otros DVCS open source como Git y Mercurial, todos tienen un equipo de desarrollo al menos cuatro veces más grande (echad un vistazo al número de 'committers' diarios en Git). Por eso estamos especialmente orgullosos de 3.0, porque nuestro 'pequeño equipo' es capaz de producir uno de los SCMs más avanzados del mercado: realmente Plastic proporciona de todo, desde distribuido (ningún otro sistema comercial excepto BitKeeper es distribuido, por mucho que diga su marketing engañoso! :-P) hasta manejo ágil y avanzado de ramas, representaciones gráficas, etc. La verdad es que un equipo más pequeño no es una desventaja, más bien todo lo contrario.

Mi objetivo para las próximas semanas es reactivar el blog en español. La verdad es que casi todos nuestros clientes hablan inglés, pero creo que no viene nada mal reforzar un poco el "blog nativo". Espero contar experiencias sobre el desarrollo de 3.0, así como de nuestro propio proceso (SCRUM + branch per task + gestión de releases + testing!) (bendito testing automático!).

Pero ahora vamos a por la 3.0, ¿qué hay de nuevo?

Revisión de código integrada (y distribuida): hace unos meses desarrollamos una integración con ReviewBoard. No está mal y aunque algunos de nuestros clientes lo usan (os suena el juego GuitarHero??? Pues la gente de Vicarious Visions usa Plastic + ReviewBoard) al final nosotros nunca lo pusimos en marcha. ReviewBoard, como casi todos los sistemas de 'code review', recibe un parche (patch) y es eso lo que analiza. Para nosotros lo natural es revisar ramas y changesets, y hacerlo de esa forma, no mediante un "intermediario". Así que añadimos esa funcionalidad para 3.0: desde una rama puedes crear una "code review" y añadir comentarios. Muy sencillo. Y lo mejor: también se replica! Es decir, que acabamos de lanzar el primer sistema de code review distribuido del mercado. :)

Shell extension: integración con el Shell de Windows. Nada nuevo porque seguro que todo el mundo ha usado TortoiseSVN (o TortoiseHg, muy común en estos días también), pero algo que nos habían pedido varias veces. Por supuesto, no nos hemos limitado a las operaciones básicas y ahora puedes usar todo Plastic desde la "shellext": sacar vistas, gráficos, etc, etc... Eso ya no lo hacen las "tortugas" :)

Nuevo importador para Subversion. Bueno, en primer lugar hemos vuelto a escribir el "SVN importer" (los desarrolladores que han trabajado en esto durante meses bromeaban diciendo que ya no trabajaban en una empresa de software sino en el negocio de la "importación-exportación" :-^) que ahora es más rápido, más usable (el wizard es mejor, también la ayuda) y soporta conexión directa mediante el ra_api (raw access) en lugar de sólo automatizando la línea de comandos. Lo hemos probado con más de 100 repositorios de SVN con éxito.

Importador de Perforce: desde que estuvimos en GDC 2010 han venido muchas empresas del sector de los video-juegos interesadas en abandonar Perforce para venir a Plastic. ¿Los motivos? Los de siempre: necesitan branching y merging a tope, como todo el mundo! Y necesitan un sistema distribuido, y que sea gráfico... Bueno, el caso es que hemos desarrollado un importador de Perforce que simplifica el proceso de migración. Listo en 3.0.

Nueva vista de "cambios pendientes" en la GUI (y en la shellext): ahora los checkouts + los cambiados (modificados fuera del control de plastic, por ejemplo sobrescribiendo un fichero sin más) + los privados (y potencialmente pendientes de añadir) se muestran juntos y se les puede hacer "checkin" a la vez. Mucho más cómodo que antes, especialmente para usuarios SVN.

Xmerge / Xdiff 2.0: la joya de la corona en 3.0. Hemos estado desarrollando esta tecnología durante mucho tiempo, y por fin ve la luz. ¿De qué va esto de "cross-merge" y "cross-diff"? Símplemente, de detectar código movido en las diferencias. Editas un fichero, mueves un trozo de código de sitio, lo modificas, y Plastic sigue sabiendo de dónde viene. Y lo mejor, que es capaz de hacerlo con los "merges" también. Suena pretencioso pero... ¡¡nadie más es capaz de hacer esto a día de hoy!! Merece la pena probarlo.

External data storage: una característica totalmente pensada para los equipos de desarrollo de videojuegos que trabajan con ficheros enormes. La idea es poder "extraer" revisiones de la base de datos del repositorio de modo que dejen de ocupar en el "servidor central" pero que todavía sigan siendo accesibles, ya sea bajo demanda (el usuario accede a esa revisión y Plastic le pide que meta un DVD con esos datos, vamos, un DVD o lo que sea) o centralizado (se monta un disco externo en el servidor y se ponen ahí los datos extraídos en lugar de en el repo principal). Útil cuando se manejan ficheros muuuuy grandes.

Annotate en la GUI: ahora el annotate (cm annotate or cm blame) ya no sólo es accesible en la línea de comandos (y en IntelliJ) sino también desde la herramienta gráfica.

SQLite backend: otra base de datos más a la lista! Hasta ahora un servidor de Plastic se podía configurar para trabajar contra Oracle, SQL Server, MySQL y Firebird, y a partir de ahora SQLite está también en la lista. Yo lo llevo usando desde hace 3 meses y va muy bien (tan rápido como un MySQL para uso individual), pero claro, está pensado no para servidores centrales (no admite acceso concurrente!) sino para montarte un servidor en un portátil y replicar.

Selector explorer: algo que también nos habían pedido 1 millón de veces: poder explorar selectores, ramas, etiquetas, sin tener que bajar el contenido. Sirve para experimentar con selectores y aprender mejor cómo funcionan.

Mejoras de rendimiento. 3.0 es al menos un 30% más rápido que 2.9 en situaciones de carga. ¿Qué quiere decir esto? Probamos Plastic con un servidor (un QuadCore con 4Gb de RAM, nada del otro mundo) y 100 máquinas cliente simulando usuarios a tope de carga (de hecho realmente la carga simulada es mucho mayor que la de un grupo de 100 desarrolladores, en nuestras pruebas generamos más carga en 20 minutos de test que un grupo de 150 programadores durante un día entero), y con esa configuración optimizamos Plastic y comparamos con otros sistemas, como por ejemplo Subversion. Publicaremos en las próximas semanas los números de Plastic vs SVN, pero os puedo adelantar que, literalmente, volamos mientras SVN se arrastra... y cuanta más carga, más rápidos nosotros y peor Subversion. También se aplica a operaciones individuales. Por ejemplo, un ciclo "add + ci" (añadir un workpace y hacer ci) es mucho más rápido ahora que con 3.0.

Detallaré cada una de las características en los próximos días, mientras tanto, ¡¡descargad 3.0 y probad todas las nuevas características!! :)

Agile Retrospectives (II): Fases

14:00 0 Comments

En el artículo anterior presentábamos las generalidades de una reunión retrospectiva y algunos consejos. En esta ocasión presentaremos detalladamente las secciones de que debería constar un retrospective, que son:

1. Establecer el escenario.
2. Recoger datos y métricas.
3. Generar reflexiones y opiniones.
4. Decidir qué hacer.
5. Cerrar el retrospective.

Establecer el escenario

Introduce el encuentro, procura que todo el mundo diga sus imporesiones en una palabra o dos al comienzo. Sé breve, pero es importante hacer que todo el mundo hable desde el primer minuto, y la mejor manera de hacerlo es solicitando a cada uno una primera impresión muy breve.

Establece el tiempo que durará la reunión y los puntos a tratar. Describe una serie de objetivos o normas que identifican al equipo y que deben cumplirse durante la reunión. Ejemplo: "Todo el mundo debe participar".

Recoger datos y métricas

No sólo recoger datos, sino también compartirlo con el equipo. Esto aumenta la perspectiva de cada miembro, haciendo que expongan sus impresiones generales en lugar de sus impresiones personales. Facilita el que cada miembro comparta sus emociones con el resto acerca del último sprint. No preguntes directamente por sus emociones, sino pregunta indirectamente. Ejemplos: ¿qué día viniste a trabajar con más entusiasmo? ¿qué tarea te gustó más? ¿qué día viniste solamente por obligación? ¿qué tarea te gustó menos? Todo esto se convierte en una vía de escape controlada para el equipo, en lugar de retener sentimientos y explotar al final.

Generar reflexiones y opinones

Es el momento de pensar "¿por qué?" y pensar qué debería hacerse de forma diferente. Conduce a que el equipo piense en qué condiciones, interacciones y patrones contribuyeron al éxito. Investiga deficiencias, riesgos y malos resultados.

Decidir qué hacer

Escoge no más de dos puntos de mejora para el siguiente sprint y céntrate en cumplirlos. Demasiados puntos de mejora tienden a sobrecargar, estresar y que al final no se cumpla ninguno.

Planifica un descanso entre el retrospective y la reunión de planificación, para que la gente reflexione sobre qué y cómo planificar en base a lo decidido en el retrospective.

Cerrar el retrospective

Cierra adecuadamente la reunión. Resume conclusiones. Resume en una pizarra bien visible y a la vista de todos, los puntos de mejora adoptados. Éstos pertenecen al equipo, no al gestor. De este modo evitaremos el que cuando todo el mundo salga de la reunión se olvide de lo hablado hasta el siguiente sprint.

Haz un rápido retrospective del retrospective: qué fue bien durante la reunión y qué se puede mejorar para la siguiente.

Y en la siguiente entrega...

Actividades para realizar duante la reunión, cuyo objetivo es fomentar la participación de los asistentes, desentumedecer mentes adormiladas y fomentar la aparición de ideas. Nos leemos en el siguiente, entonces.

---

Referencias:

Agile Retrospectives – Making good teams great

Esther Derby, Diana Larsen

Agile Retrospectives: cómo mejorar

13:59 0 Comments

En una pequeña serie de artículos resumiré lo que encontré recientemente en el libro que abajo se referencia referente a cómo mejorar las reuniones retrospectivas (qué mal suena; no, no estoy hablando de Retrospector ni nada relacionado con La Hora Chanante).

¿Qué es un 'retrospective'?

Una retrospección en la vida es pararse por un momento, mirar hacia atrás y reflexionar sobre el camino trazado hasta la fecha, evaluando las cosas buenas y las malas, y aprendiendo de todo ello para ser mejor persona.

Esto, que muchos seres humanos que andan sueltos por ahí deberían hacer a menudo, en las metodologías de desarrollo ágil de software se llama "retrospective" y en un modelo de desarrollo iterativo viene muy bien para evaluar cada una de esas iteraciones que se realizan. En nuestro caso particular orientaremos el discurso hacia SCRUM, quizá la metodología ágil más conocida y extendida, junto con eXtreme Programming.

Fases de un 'retrospective'

Una buena reunión retrospectiva debería constar de las siguientes fases:

1. Establecer el escenario.
2. Recoger datos y métricas.
3. Generar reflexiones y opiniones.
4. Decidir qué hacer.
5. Cerrar el retrospective.

Estas fases, no parecen nada del otro mundo y muchos equipos las llevan a cabo, en mayor o menor medida. ¿Por qué aun así no hacen buenos retrospectives? Bueno, quizá el problema está en el cómo y no en el qué.

¿Quién dirige un 'retrospective'?

Un retrospective puede estar dirigido por el gestor del equipo o por cualquier miembro del mismo, o incluso ir variando en cada ocasión. Quien dirige la reunión deberá mantenerse lo más al margen posible, porque el poder subyacente que posee quien dirige la reunión puede coartar a los demás miembros a participar. Esto es especialmente apblicable al gestor, que en cualquier caso se mantendrá lo más al margen posible de la discusión, debido a que su estátus puede influir en las opiniones del equipo y romper la dinámica del grupo.

Es importante identificar qué parámetros se han de analizar en un retrospective. Algunos buenos ejemplos:

• Buscar modos de mejorar las prácticas.
• Descubrir qué se hizo bien.
• Entender las razones subyacentes por las que no se cumplieron los objetivos.
• Buscar modos de mejorar la responsabilidad de cara a los clientes.
• Reconstruir relaciones maltrechas.
• ...

Y para terminar esta sección, dos máximas que deben cumplirse durante una reunión retrospectiva:

1. Evitar culpabilizar a sujetos por el incumplimiento de un objetivo.
2. Facilitar el que todo el mundo hable.

¿Cuánto debe durar un retrospective?

Depende.

De la duración del sprint, de la complejidad de la tecnología que se maneja en dicho sprint, del tamaño del equipo y del nivel de conflictos y controversias en las opiniones de los miembros. Como guía: cada semana de sprint, una hora de reunión retrospectiva.

Acortar el tiempo de la reunión es hacer trampa y engañarse uno mismo; sin embargo, si los objetivos se cumplieron se puede acortar la reunión.

Por otro lado, los retrospectives deben prepararse previamente. El equipo debe entrar en la sala de reuniones con algo mínimamente preparado, un adelanto de lo que se va a hablar.

¿Cómo preparar retrospectives?

El responsable debe responder a las siguientes preguntas:

• ¿Cuál es el objetivo de la reunión?
• ¿Quién atenderá?
• ¿Cuánto durará?
• ¿Dónde se celebrará?
• ¿Cómo se organizará la sala?

¿Como hacer que el equipo prepare la reunión?

Puede enviarse un pequeño cuestionario por correo electrónico a todas las personas que van a asistir a la reunión antes de hacer el retrospective. De este modo se forzará a que el equipo se tome unos minutos en reflexionar sobre el sprint. Tras recibir las respuestas, que se tratarán anónimamente, pueden leerse los resultados en voz alta durante el retrospective, de manera que sirva como resumen de las impresiones generales del grupo.

Otra opción es solicitar un breve resumen de las impresiones del sprint.

¿Y después de la reunión?

Asigna cada acción a realizar en el siguiente sprint a un responsable. Muchos retrospectives fracasan porque, a pesar de que se aportan buenas ideas, éstas quedan en el aire y se olvidan para el siguiente sprint. Asigna responsables y haz que el equipo colabore en el cumplimiento de dichas acciones.

Y en la próxima entrega...

He dado un rodeo a propósito para no explicar detalladamente las fases de una reunión retrospectiva. Mi objetivo aquí ha sido el de sentar las bases, dar unos primeros consejos y establecer algunas ideas. En la próxima entrega explicaré detalladamente en qué consiste cada fase.

Y en siguientes entregas explicaremos una serie de actividades que pueden realizarse durante la reunión retrospectiva y cuyo objetivo primordial es fomentar la participación. Fuera aparte de las ideas que surjan, de las decisiones tomadas y todo lo demás. Lo principal es hacer que todo el mundo participe. Lo demás vendrá sólo.

---

Referencias:

Agile Retrospectives - Making good teams great

Esther Derby, Diana Larsen

¿Es tu software como esto?

12:33 software 0 Comments

He visto el link a la imagen en reddit.com, qué os parece??

Demasiada memoria gracias al Garbage Collector

16:03 .net 0 Comments

Parece que está claro que programar en algo como C#/.NET (incluso C#/Mono) es mucho más rápido que intentarlo con C/C++: unas librerías potentes, un lenguaje sencillo y (lo que todos dicen) no más mallocs ni frees.

(Nota: hace un par de semanas en Game Developers Conference 2010 había una mesa rendonda en la que precisamente hablaban de las limitaciones de C++ (su complejidad básicamente) para el desarrollo de videojuegos y cómo les gustaría tener GarbageCollector… aunque al final todo el mundo coincidía en que les gustaba C++ a pesar de todo…)

Bien, volviendo a .NET: Garbage Collector, uno de los elementos claves de framework (y lo mismo se puede decir en Java) proporciona muchas ventajas: escribes y listo, te olvidas de líos. Pero… ¿es todo positivo? En Java estamos acostumbrados a ver aplicaciones consumiendo cantidades astronómicas de memoria (incluso hay IDEs como IntelliJ con un botoncito para llamar al GC, ni más ni menos) y lo mismo puede ocurrir con .NET. En muchas ocasiones no es un problema sino un tema estético: como el GC sabe que hay memoria de sobra disponible, y para mejorar el rendimiento, no recolecta la basura, así que el proceso sigue creciendo.

Pero para mí el mayor problema no es ese sino la sensación que va creando en todos los programadores de que la memoria es gratis. ¿Qué quiero decir con esto? Pues que acabas creando objetos y objetos y objetos nuevos porque es rápido y sencillo… aunque puedes estar estresando al GC más de la cuenta.

Un ejemplo práctico: servidor y blobs

Un ejemplo claro de cómo me encontré con el problema y cómo creo que en C jamás hubiera ocurrido.

Tengo un proceso servidor en .NET que procesa peticiones de clientes realizadas a través de la red, lee datos (blobs) de una base de datos y los devuelve al cliente. Muy sencillo.

Bien, cuando el nivel de carga del servidor no es muy alto todo funciona perfectamente: el servidor lee objetos, los devuelve, libera memoria de vez en cuando… todo perfecto.

Pero, ¿qué ocurre cuando ponemos unos cuantos cientos de clientes contra el mismo servidor?

Pues que la memoria del servidor comienza a crecer muchísimo, vemos como el tiempo haciendo GC aumenta también (se puede ver con el Process Explorer de SysInternals, http://technet.microsoft.com/es-es/sysinternals/bb896653.aspx, por ejemplo, donde te da una medida del tiempo que tu proceso (.Net 2 o superior) está gastando en GC).

¿Por qué ocurre esto?

Lo que yo estaba haciendo para procesar la petición era algo como esto (tipo pseudocódigo):
public byte[] GetData(long dataId)
{
byte[] result = new
byte[GetDataLen(dataId)];
ReadData(dataId, result);
return result;
}

¿Veis el problema?

Ahora me parece totalmente evidente pero la verdad es que tardé un rato en darme cuenta porque con el profiler de memoria (usaba la herramienta de RedGate Ants, http://www.red-gate.com/products/ants_memory_profiler) no detectaba nada de nada, parecía que todo estaba bien.

Objetos en tránsito

¿Cómo funciona el servidor? Cada método GetData se va a invocar en un thread (realmente no creando un thread nuevo, que parece un pecado, sino usando un thread pool) diferente, hace su trabajo y termina.

Entonces, ¿por qué tanta memoria? El siguiente gráfico lo explica claramente:

El método GetData está funcionando bien pero lo está haciendo en "modo .NET", es decir, lo he escrito como si la memoria fuera gratis.

Cuando se acumulan peticiones la cantidad de memoria inútil reservada será enorme dependiendo de cuántas llamadas se estén procesando (de la carga del servidor). Viendo el gráfico está claro que la memoria que se reservó para procesar la primera petición en el instante 0 en el primer thread no vale para nada ya en el instante 2 y sin embargo sigue ocupando sitio en el proceso…

Y este es precisamente el problema: los objetos en tránsito, objetos que todavía no se han liberado pero que siguen ocupando sitio.

Pensamiento tipo C

Esto nunca le hubiera pasado a un desarrollador C/C++ por dos motivos: primero porque un free es un free de verdad y liberaría la memoria inmediatamente. Segundo porque estando acostumbrado a una vida mucho más dura, trataría de evitar tanto malloc/free (o new/dispose).

¿Qué pasa si creamos un buffer pool con unos cuantos buffers pre-creados que reutilizamos en cada petición? El código pasaría a ser algo como esto:

public byte[] GetData(long dataId)
{
byte[] result = GetBuffer(GetDataLen(dataId));
ReadData(dataId, result);
return result;
}

public void ProcessRequest(long dataId)
{
byte[] result = GetData(dataId);
ReturnData(result);
ReleaseBuffer(result);
}

Varios puntos a tener en cuenta:

• Para simplificar algo como esto ayuda mucho si los datos son de tamaño fijo, o al menos tienen un tamaño máximo. En mi caso un bloque de datos nunca era mayor de 4Mb, por lo que es muy sencillo de manejar el buffer pool porque todos los buffers serán del mismo tamaño (el máximo).
  


• Si todos los buffers son del mismo tamaño habrá que manejar cuál es el tamaño usado de verdad, es decir, si estás leyendo 1024bytes en un buffer de 4Mb, luego no envíes 4Mb por la red!!! Envía sólo lo que estás usando. Esto posiblemente requerirá un código del tipo:
  public void ProcessRequest(long dataId)
  {
  byte[] result = GetBuffer();
  try{
  int size = ReadData(dataId, result);
  ReturnData(size, result);
  }
  finally
  {
  ReleaseBuffer(result);
  }
  }

Que por otro lado es mucho más limpio.

• Hay que acordarse de liberar el buffer (tipo C) que realmente no hace nada más que devolverlo al buffer pool. Si el código de obtención y liberación del buffer está en el mismo método y con un try/finally, mucho mejor: más fácil de leer y menos propenso a fallos (no me gusta cuando el código de obtener y liberar un recurso o memoria, o lo que sea, no está en el mismo bloque).

Lógicamente hay que implementar el buffer pool de forma que:

• Sincronice el acceso de varios threads


• Se pueda limitar el número máximo de buffers: de este modo se puede controlar cuál va a ser el uso de memoria de nuestro servidor: no ocurrirá NUNCA que se descontrole como pasaba antes, el consumo será plano, el GC no tendrá trabajo y todo será más rápido. ¿Cómo limitarlo? Por ejemplo con un sencillo semáforo que bloquee en la llamada GetBuffer hasta que queden buffers libres. NOTA IMPORTANTE! En caso de usar un semáforo es muy importante considerar el riesgo de deadlocks si empezamos a usar múltiples pools (después del primero vendrán más) y los threads intentan acceder a ellos sin un orden muy estricto (la vieja regla: reserva SIEMPRE en el mismo orden y nunca tendrás deadlocks, reserva en orden diferente y espera el desastre).

Remoting: más complicado

En mi caso real (no descubrí esto en un programa de 5 líneas con un GetData, desgraciadamente) el servidor no estaba usando sockets directamente sino .NET Remoting, así que en la película entraban más complicaciones como la serialización de objetos y las múltiples copias que Remoting hace hasta llegar a la capa de red. Para evitarlo no quedó más remedio que escribir un custom tcp channel capaz de manejar el buffer pool reservado en la capa de aplicación y liberarlo justo después de poner los datos en la red, y evitando también la lenta serialización estándar de .Net… pero esto ya es otra historia para otro día.

Plastic SCM 2.9 ya está aquí!!

0:09 noticias 0 Comments

Plastic SCM llega a su versión 2.9 y está listo para descargarse desde nuestra web: www.plasticscm.com.

La nueva versión viene cargada con un buen número de nuevas características y también es mucho más rápida, especialmente bajo carga.

Estas son algunas de las nuevas características:

Soporte de Oracle: hemos añadido Oracle a la lista de backends con los que PLlastic puede funcionar. Hasta ahora soportábamos MySql, SQL Server y Firebird (tanto servidor como embebido). Nos han pedido Oracle varias veces, especialmente desde grandes equipos así que por fin está disponible. Se trata posíblemente del gestor de bases de datos más conocido tanto por rendimiento como estabilidad y escalabilidad y puede usarse con servidores Plastic en Windows, Linux y MacOS X.

Integración continua con Pulse: hemos desarrollado un plugin para el producto de integración continua de Zutubi. Hasta ahora ya nos integrábamos con productos como CruiseControl y FinalBuilder, pero Pulse es quizá mi favorito y estamos trabajando en ampliar la integración para que soporte patrones como rama por tarea, y así poder implantarlo internamente. Otros sistemas, como Hudson, también funcionan con Plastic.

Servidor proxy: otra de las características más esperadas. Ahora se puede configurar un servidor proxy de Plastic para reducir el uso de red mientras se trabaja conectado a un servidor central. El servidor proxy es muy sencillo: símplemente descarga datos bajo demanda que le solicitan los clientes y los cachea para el siguiente uso. Con esto se ahorra uso de red lo que puede ser crítico cuando se acceede al servidor a través de VPN o conexiones lentas. Nota: Plastic puede funcionar en modo distribuido pero algunas empresas prefieren llevar ciertos proyectos de forma centralizada, y es ahí donde el proxy server juega un papel importante.

Sparse tree y cloaking: que se traduce por algo como árboles parciales y evitar que ciertos ficheros se actualicen. Mediante un nuevo fichero de configuración llamado cloaked.conf es posible definir reglas para indicar qué ficheros se pueden descargar y qué ficheros no, es algo complementario a lo que ya se puede hacer con los selectores, pero permite funcionalidades diferentes. Por ejemplo, se puede descargar un árbol de directorios y luego indicar que ese árbol está cloaked lo que quiere decir que no se volverá a actualizar. Es útil para mejorar el rendimiento cuando se trabaja con proyectos muy grandes. Sólo para usuarios avanzados.

Uso de memoria en la replicación. El uso de memoria en todo el proceso de replicación se ha reducido considerablemente, haciendo que el proceso sea mucho más rápido y eficiente que antes. Ahora se puede replicar un repositorio completo sin que el servidor se entere a nivel de uso de memoria!

¡Eliminación del workspace server! Sí, como leeéis, el hemos eliminado el componente servidor de workspaces del mapa. Bueno, de hecho no se ha ido sino que se ha trasladado a cada cliente, de modo que el rendimiento aumenta de forma espectacular. ¿Qué significa esto? Echa un vistazo a un nuevo workspace y verás que contiene un directorio (oculto) denominado .plastic. Contiene información sobre el workspace como el selector y el árbol de la copia de trabajo. Toda esa información solía estar en el servidor y ahora se ha movido al cliente, lo que supone que se reduce significativamente el uso de red, lo que podrán apreciar especialmente los usuarios de redes VPN (en LAN la velocidad ya era tan alta que no se apreciará mucha diferencia). Nota importante: cuando te actualices de Plastic 2.8 a 2.9 verás, en el primer arranque, un diálogo como el siguiente que indicará el progreso de la conversión de workspaces.

Workspaces compartidos: tras las modificaciones realizadas en los workspaces ahora se pueden compartir: se puede ubicar un espacio de trabajo en un directorio compartido (por Samba o por NFS, por ejemplo) de forma que más de un usuario pueda acceder a él e incluso actualizarlo y acceder a información de Plastic desde varias ubicaciones. Antes se podía hacer registrando el workspace en diferentes máquinas, pero se podía llegar fácilmente a condiciones en las que el sistema no se comportase bien porque para Plastic eran workspaces diferentes. Lógicamente es una característica para usar con cuidado: es útil para usarlo con sistemas de compilación, o de paso a producción, no para trabajar a diario ya que el objetivo de un control de versiones es precísamente coordinar diferentes copias de trabajo, ¡¡no trabajar sobre una misma!!

Exploración de changesets: una de las nuevas características más potentes. Ahora se puede caminar por las ramas cambio a cambio (changeset a changeset) leyendo la historia que cuentan. Escribiré otro post sobre esto pero para hacer una breve introducción: en tu propia rama de tarea eres libre de hacer tantos checkins como quieras, pero todos esos checkins deberían de tener un significado, ir describiendo cambios uno a uno, de modo que todos tengan una lógica. Supongamos que vamos a hacer un refactor importante, de muchos ficheros, si comparas el contenido de la rama una vez que has terminado verás tantísimos cambios que será difícil de entender lo que has hecho, sin embargo si has podido descomponer el refactor en pequeñas operaciones y has ido haciendo checkin de cada una de ellas, se podrá revisar posteriormente los cambios que has hecho, como si fuera ver una repetición de la jugada. El mecanismo de commit no es nuevo, por supuesto, pero la herramienta de recorrido de cambios permite que se usen para describir cambios casi contando cómo lo has ido haciendo, dejando registrado no sólo lo que haces sino cómo lo haces, con todas las aplicaciones que eso tiene.

Mejoras en el branch explorer: siempre en evolución, hemos añadido la capacidad de búsqueda que permite ir navegando las ramas que cumplan el filtro, lo que es mucho más útil que antes. También la posibilidad de hacer clic sobre los link de merge y ver de dónde vienen y hacia dónde van. Y por último el editor de visibilidad que tantas veces nos han pedido y que permite ocultar ramas que no interese ver.





Y estas son todas las funcionalidades importantes en 2.9 junto con un buen número de correcciones.

Y por supuesto mejoras de rendimiento: probamos Plastic cada semana en un cluster con 100 nodos y bajo esa carga 2.9 es un 30% más rápida que 2.8. Recordad que Plastic 2.8 era ya 10 veces más rápido que SVN... así que calculad 2.9!!

Y por supuesto a pesar de seguir creciendo Plastic es todavía fácil de usar y de instalar. Echad un vistazo al siguiente vídeo en el que se configura un servidor en menos de 45 segundos!! Y después se hace una importación inicial de código (algo que es muy común en cualquier evaluacion) durante el siguiente minuto!