jump to navigation

Un año “Realizando la idealidad” Junio 2, 2009

Posted by ravelus in Experiencias.
add a comment

Vale, no he realizado ninguna idealidad, pero el título quedaba chulo, no me dirán que no.

Hace algo más de un año que abrimos las puertas por primera vez, nos trasladamos a WordPress, montamos el chiringuito, nuestro púlpito y ale, a disertar estupideces. Y si el tío de Kriptópolis, los de Microsiervos, el otro y el otro (vean más abajo la sección de Enlaces) hacen autopropaganda y falsa modestia publicando cada poco sus cientos de miles de visitas recibidas, vendiéndolas como un “gracias” cuando en realidad es un “cómo molo, molo muchísimo, si llegara a chupármela me la metería hasta el esófago, oiga”, pues yo no voy a ser menos. A partir de aquí toda comparación sería absurda, pues las visitas que he recibido en un año son menos de las que estos sitios reciben en un día, y su mérito tienen, sin duda alguna. Pero desde el punto de vista personal estoy más que satisfecho que cada día me siguan más de 40 personas, a pesar de las divagaciones y de las estupideces; hace que me sienta “alguien” en el inmenso mundo de Internet el tener 70 comentarios, que aunque las cifras son ridículas bien merecen mis más sincero agradecimiento. No espero más, no aporto nada original ni rompedor, simplemente escribo palabras, no nos equivoquemos.

Esto no es falsa modestia, es lo que hay. Es cierto que me gusta escribir y  que probablemente aunque tuviera cinco visitas o ninguna lo seguiría haciendo, pero saber que probablemente hay unas veinte o treinta personas (como mínimo, calculo yo) que no conozco y que me siguen al menos una vez a la semana (se notan los picos a comienzo de semana), aparte de las que me conocen y me siguen, que unas veces me critican por tiquismiquis, cutre, sabelotodo y prepotente y otras veces me dicen que soy gracioso, sincero, o que están de acuerdo conmigo, eso para mí es mucho. Eso anima a seguir escribiendo. No soy nadie, no espero cientos de miles de seguidores; sólo espero que alguien, por pura casualidad, y buscando quién sabe el qué, se deje caer por aquí y le guste lo que vea, o que le disguste, y lo comente. Muchas gracias, de verdad. Estos son los números, y estoy muy orgulloso de ellos:

totalesvisitasmediasvisitasmesresumenpagsmasvisitadas

Elecciones Europeas ‘09 Mayo 26, 2009

Posted by ravelus in Crítica social.
add a comment

El próximo día 7 de junio los europeos votamos. Algunos, al menos. Ya sé que estas elecciones no despiertan tanta expectación que las generales, craso error nuestro. De acuerdo, ni siquiera yo sé a quién votaré, los políticos de hoy día no tienen ni carisma, ni personalidad ni encanto, ni siquiera para mentir. Ya no hablemos siquiera de inteligencia, ya que siempre presumieron de ello…

Y sin embargo, hay que votar. Pasa como en las elecciones generales, exactamente igual. No importa si eres de derechas, de izquierdas, anarquista o liberal. Mientras seas demócrata, en el más puro sentido de la palabra, debes votar. A quien te de la gana, pero vota. Es una simple cuestión de mirar atrás y pensar: ¿Estamos ahora mejor que hace 60 años? ¿y de 30? ¿y de 20? Yo creo que sí, indudablemente. Y desde el punto de vista de España se ha beneficiado tremendamente de la Unión Europea. Lo malo es que ahora nos tocará dar a nosotros. Siguiendo con la enumeración de antes, ¿estamos mejor ahora que hace 10 años? Vale, quizá esto ya sea más cuestionable, porque el Euro no ha salido todo lo bien que pensábamos, la Constitución Europea ha resultado otro fiasco, etc. Pero ello debe ser un acicate para tratar de cambiar las cosas, precisamente, pues ha quedado demostrado que la fórmula funciona; otra cosa es cómo la llevemos a cabo.

Volviendo al tema de la Constitución Europea, quizá por esto último que apunto fracasó. A mí no me gustó que algunos partidos de izquierda de aquí instaran a votar el NO, porque en aquel momento pensaba que quizá no fuera una constitución perfecta, pero todo es susceptible de remodelarse y mejorarse con el tiempo, y que aquello era mejor que no tener nada, que era un paso adelante. Por otro lado, tratando de comprender su punto de vista, quizá tengan razón en aquello de “Constitución, sí, pero no a cualquier precio”. Y la verdad es que todos (yo me incluyo) fuimos a votar un SI como corderitos, sin tener ni la más puñetera idea de qué era eso. Yo intenté leer los estatutos, de verdad, pero de puro sopor no pasé de las cuatro o cinco primeras páginas. Y quizá la izquierda tenía razón. Quizá era un poco una manzana envenenada, no sé. Como el Euro.

Ahora es cuando alguien me dice: “un momento, que el PSOE votó que sí a la Constitución”. Y yo le responderé: “ah, ¿que el PSOE es un partido de izquierdas?”… Miren, no sé a quién votaré, lo que sí tengo claro es a quién no votaré. No votaré a unos hipócritas que pretenden ser de centro y van de enrollados con la familia y todo eso y son de derechas; no tan radicales como algunos les acusan de ser pero de derechas al fin y al cabo (siendo demócrata, ¿tiene algo eso de malo?). Tampoco votaré a unos hipócritas que pretenden convencernos de que son de izquierdas y luego son promocionados por la élite burguesa y sibarita, a los cuales reparten después pingües beneficios y suculentas tajadas. No diré nombres, quien tenga ojos para leer y raciocinio para comprender, comprenda.

Creo que votaré a un partido ecologista. Creo que el problema de lo medioambiental es un problema gordo que, a pesar de toda la propaganda que venden unos y otros, al final se lo van a pasar por el forro de los casquetes polares. Al menos así habría una mosca cojonera en el Parlamento que les dijera de vez en cuando, cual voz de conciencia acusadora: no estáis cumpliendo con Kioto, no cumplís lo que prometísteis. Eso estaría bien.

Por otra parte, quizá sería bueno votar un partido de izquierdas, pero de los de izquierdas de verdad. Creo que las izquierdas se están echando a perder en todo el mundo, y creo que los principales responsables de que eso ocurra son precisamente los propios representantes de los partidos de izquierdas. Los ideales de la izquierda parecen haberse convertido en algo así como el coño de la Bernarda, donde todo cabe y todo encaja holgadamente. Y los votantes dicen no. Porque no es lo mismo un partido nacionalista de izquierda que un partido nacional de izquierda. No pueden reconciliar eso. Y eso está ocurriendo con la izquierda, que tratan de aglutinarse todos juntos como uno sólo, y eso no es así. Los votantes de la izquierda se sienten traicionados, llenos de un sentimiento de “por qué se juntan a esos, si yo no tengo nada que ver con ellos”. Sin embargo es una pena que la izquierda de verdad caiga, se pierda, sería peligroso, sería una catástrofe, pues es necesario un equilibrio de fuerzas, de pensamientos, de formas de ver el mundo. Sin una izquierda potente, estamos abocados al capitalismo más cruel, del cual, amigos, no nos engañemos, no nos van a sacar esos fariseos de izquierda capitalista, sino que más bien nos introducirán del mismo modo que la declarada derecha.

Sin un partido de izquierdas fuerte esto se convertirá en el modelo americano: unos son de derecha moderada, los otros de derecha radical. No hay más, no hay alternativa, no hay más cojones que los suyos. Sin embargo, algo muy positivo que tiene el modelo americano es que todo ciudadano se toma muy en serio a quién va a dar su voto. Mucho más que aquí. Es un voto, pero para ellos es más que un papel. Es una ración de confianza depositada en alguien. Allí se vota a las personas, esto también me parece positivo, aunque tiene un problema: la camarilla que rodea a esas personas. Felipe González era bueno, lo malo era la mafia que se aglutinaba a su alrededor. Si yo decidiera votar a personas y no a partidos, lo tendría aún más crudo.

Quizá vote a UPyD. Me parecen los menos hipócritas, por lo menos sus siglas reflejan mi propio sentir. Parecen coger cosas buenas de la derecha y cosas buenas de la izquierda. Tienen puntos decididamente progresistas que me atraen mucho, sin perder un sentido común y una visión realista de las cosas. Son los que más encajan con mi perfil. Ya tendrán tiempo de decepcionarme, digo yo. Pero si perdemos la ilusión, y más en la veintena, no sé qué será de nosotros en la cuarentena.

En cualquier caso, voten. Voten por la Unión, voten por la Democracia, voten a quien quieran, pero voten. No voten a cualquiera porque sí, voten en blanco si hace falta, pero voten.

Tipos de equipos según su organización (II y final) Mayo 19, 2009

Posted by ravelus in Informática.
add a comment

Feature Team

Consiste en pequeños equipos encargados de un área específica: desarrollo, calidad, documentación, gestión, interfaz de usuario… Cada grupo tiene un responsable que funciona como portavoz e interfaz de comunicación con los otros grupos. Las responsabilidades están claras y bien definidas. Funciona bien en proyectos tipo resolución de problemas (ver artículo anterior) porque tales problemas pueden ser divididos y focalizados en un grupo. También puede funcionar bien en proyectos de creatividad (ver artículo anterior), al enfocar cada grupo mejoras de calidad desde un punto de vista diferente. Proyectos de ejecución táctica (ver artículo anterior) no se ven favorecidos por este tipo de organización.

Search and Rescue Team

Actúa como un equipo de salvamento de montaña. Los miembros se centran en resolver problemas muy específicos. Requiere un profundo conocimiento del entorno y del modelo de negocio. Requiere una buena previsión de imprevistos (riesgos: planificación y resolución). Claramente favorable para proyectos tipo resolución de problemas. No es buena opción en otro caso.

SWAT Team

“Special Weapons And Tactics” se transforma en el mundo software en “Skilled With Advanced Tools“. Cada miembro es experto en el manejo de una herramienta o técnica específica, y la suma de todos ellos es sinérgica y hace que el equipo actúe como uno sólo. Debido a sus características son equipos permanentes, inamovibles. Especialmente útil en proyectos de ejecución táctica. Buena idea para proyectos de resolución de problemas.

Professional Athletic Team

Los miembros del equipo son seleccionados muy cuidadosamente. Son las estrellas. El gestor hace trabajo de “trastienda”, pues los fans no quieren verlo a él, quieren al equipo. El gestor hace posible que el equipo sea eficiente. El proyecto puede salir adelante sin el gestor, pero no sin el equipo. Cada miembro tiene un rol específico, el cual maneja perfectamente. El gestor está para dar soporte. Por si a alguien no se le ha ocurrido aún, esto es igual que un deporte de equipo. Útil en productos de interés general, y no de cliente.

Particularmente me parece que incentiva la creatividad y la resolución de problemas.

Theather Team

Fuerte dirección y mucha negociación acerca de los roles en el proyecto. El “director” manda: su opinión prevalece sobre la del resto. Cada rol no debe salirse demasiado de su cometido o papel. Los papeles son intercambiables entre proyectos, de manera que no hay especialistas en este sentido, pero en un proyecto dado el papel no cambia. El gestor hace trabajo de gestión puro: mucha gestión, poca técnica. Útil en proyectos multimedia.

¿Y vosotros? ¿En qué tipo de equipo trabajáis? ;-)

Referencias:

Rapid Development: Taming Wild Schedules, Steve McConnell

Españoles de pacotilla Mayo 10, 2009

Posted by ravelus in Crítica social.
add a comment

Hace escasas semanas estuve en Salamanca en casa de un amigo en plan quedada de la pandilla para salir por allí. A altas horas de la madrugada fuimos a una discoteca que de antemano sabía que no me iba a gustar, pues el estilo se decía que era de tintes bacalutis, cosa que detesto profundamente. Al llegar a la puerta, sendos maromos tamaño estándar (estándar para un maromo, entiéndase) nos retuvieron en la entrada y no dejaron pasar a un chaval que iba con nosotros por no ir adecuadamente arreglado para la ocasión. Ya saben, hay que mantenter el caché aunque sea en una discotecucha de tres al cuarto, y en una ciudad estudiantil donde su principal belleza, socialmente hablando, es precisamente la diversidad de culturas, gustos y aficiones.

En estas estábamos pensando largarnos con la música a otra parte cuando aconteció lo habitual en estas lides. Una panda de mozos de estética moderna (ya saben, cresta cutre, peinados tope mazo modernos y ropa guapa de verdad), de esos que no destacan porque los hay a patadas, visten siguiendo los mismos clichés y son la mar de originales, era expulsado de la discoteca. Desconozco totalmente qué tipo de rifi-rafe ocurrió dentro, pero poco me importa. ‘Ya estamos con los gorilas estos de las narices’, pensé yo. Joder, qué manía de echar a la gente, qué asco me dan. No sé. La cosa es que la pinta de los otros mozalbetes no era de fiar. Tras unas cuantas provocaciones a los porteros, a las cuales ninguno entró al trapo, claro, cojonudas están las cosas como para meterse en un lío por un mocoso, uno de ellos soltó un ” a ver si contratáis a más españoles y menos gente de fuera”.

Y esto me llegó al alma, claro. No pude reprimir una sarta de insultos y comentarios con mis amigos ante tal afirmación tan ignorante como de claro indicio de retardo mental. Lo más triste de todo esto es que eran chavales, no mamarrachos viejunos de terca mente y recio cráneo. Esta juventud es la que continúa la saga de los maltratos a las mujeres, las palizas a los inmigrantes, son los que queman yonkis y vagabundos en cajeros, son los que hacen la vida imposible a compañeros de clase… esta juventud es el resultado de una educación ineficiente, que produce unos futuros activos lelos, analfabetos y, lo que es peor, fácilmente manipulables. Esta es la juventud que quieren los gobiernos, esta es la juventud que quiere el capitalismo en el que vivimos inmersos todos, y de los cuales, en España, los principales responsables son el PP y el PSOE por igual. Una juventud lela, una juventud tonta, una juventud fácilmente manipulable, sin opinión propia.

Amigos garrulillos (domésticos, con cariño): si los inmigrantes se fueran de España, estaríamos los españolitos de pro, los de ‘pura raza’, más que jodidos, con una población en clara tendencia hacia el envejecimiento. Si los inmigrantes se fueran de España, a ver quién cojones se encargaría de los curros duros, esos que nadie quiere, porque claro, somos muy señoritos. Los inmigrantes cotizan a la Seguridad Social, y pagan sus impuestos. Si los inmigrantes se fueran de España, a ver quién pagaría las pensiones de los jubilados de hoy y de mañana. Qué cojones: ojalá se largaran todos los inmigrantes, como desean mis queridos tontainas; a ver si así espabilaban de una puta vez.

Tipos de equipos según su organización (I) Mayo 6, 2009

Posted by ravelus in Informática.
1 comment so far

Introducción

En este artículo trataremos las diferentes formas que existen para organizar los miembros que conforman un equipo de desarrollo software y en qué consisten, qué rol desempeña cada miembro, etc.

Para entrar en calor, digamos que según sus objetivos existen tres formas de organizar un equipo según el tipo de proyecto a desarrollar:

- Resolución de problemas: casos en los que los requisitos son confusos, proyectos de investigación, etc.

- Creatividad: proyectos en los cuales es necesario explorar alternativas y evaluar distintas posibilidades.

- Ejecución táctica: proyectos que constan de un plan bien definido y conocido, con menor incertidumbre.

La elección de uno u otro enfoque dependerá del objetivo fundamental del proyecto. Es por esto que la definición de tal objetivo u objetivos es primordial, ya que seleccionar un enfoque no adecuado puede dañar en cierta medida la consecución de dicho objetivo.

Por otro lado, algunos aspectos a tener en cuenta a la hora de mantener equipos productivos son: roles claros (¿qué papel desempeña cada uno?), monitorización del desempeño individual (qué tareas tiene asignadas, qué tal lo hace, qué dificultades tiene cada miembro en la consecución de sus tareas, etc), comunicación efectiva (¿qué problemas tiene el desarrollo del proyecto en este preciso momento?) y toma de decisiones basada en hechos (conociendo el estado actual del desarrollo, ¿qué acciones tomar? ¿qué camino se seguirá a partir de ahora?).

Tipos de equipos

Business Team

Entre pares, cada miembro se especializa en un tema concreto. El equipo es dirigido por un líder técnico, que será un “par” con experiencia. Lo de par significa que existirá una serie de miembros que serán pares entre sí, en el sentido de iguales en cuanto a su liderazgo, experiencia y capacidades técnicas. Cada equipo será liderado por uno de estos  “pares”. Este líder tomará decisiones finales en temas técnicos. Este rol no tiene por qué ser desempeñado por el propio gestor del proyecto. Funciona bien con equipos pequeños y/o estables. Es lo suficientemente adaptable como para funcionar bien en todo tipo de proyectos (ver introducción). Esta versatilidad es precisamente su principal debilidad, pues no ofrece un rendimiento neto excepcionalmente bueno en ningún tipo de proyecto específico.

Chief-Programmer Team

El equipo se comporta como el equipo de médicos de un quirófano: uno, el más productivo, es el cirujano jefe, el que desarrolla la mayoría del proyecto; el resto están para dar soporte y descongestionar al jefe de las tareas más sencillas. Estas tareas, de muy diversa índole, pueden ser desarrolladas por personal no informático. El jefe debe ser excepcionalmente bueno en lo que hace (lo cual restringe mucho el número de personas que pueden desempeñar este papel). Puede funcionar bien en proyectos creativos y de ejecución táctica.

Skunkworks Team

Consiste en aislar un grupo de desarrolladores con talento y creatividad en una sala donde nadie los moleste y darles libertad para trabajar e innovar. Desde el punto de vista de la gestión, el equipo se comporta como una caja negra:  el gestor no conoce los detalles del estado del proyecto, y de eso se trata precisamente: el equipo trabaja y no es molestado ni coaccionado. Eventualmente surgirá un líder técnico en un cierto aspecto, tarea o tema a tratar; éste será elegido por el equipo. Esta organización maximiza la motivación, la responsabilidad y hace que los miembros se involucren en lo que hacen al máximo. Por otra parte, la falta de visibilidad externa puede ser un problema a tener en cuenta (véase como riesgo). Por todo ello, es fácil entender que este modelo es apropiado para proyectos de creatividad y muy desaconsejable para aquellos de ejecución táctica.

Referencias:

Rapid Development: Taming Wild Schedules, Steve McConnell

JAD (Joint Application Development) Abril 27, 2009

Posted by ravelus in Informática.
add a comment

No, no. No se trata de JASP, aquel famoso eslógan publicitario de principios de los 90. Aquí voy a hablar de JAD, que es otra cosa bien diferente, si bien todo parecido sería pura casualidad a la par que absurdo. JAD es uno de esos inventos que hacen los americanos, que no tiene nada del otro jueves pero que le ponen unas siglas chulas, para que suene guay y la gente se quede con cara de papagallo cuando les dices que haces JAD, escribas libros y ganes dinero a chorretones. Y aunque yo no voy a ver un puto duro por hablar aquí de esto, escribo porque es una técnica más, interesante, y me gustaría que el lector se quedara con lo que le gustara, desechara lo que no, y de todo ello extrajera algo positivo, aunque sólo sea hacer tiempo hasta que termina de descargar algo en el eMule o en lo que carga un vídeo en YouTube.

¿Qué es JAD?

Dicho esto, comenzamos. JAD es una técnica de definición de requisitos y de diseño de la interfaz de usuario, basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha reunión los temas a tratar se centran más en el negocio que en el asunto técnico. Lógicamente está más orientado a proyectos de cliente (o bien sistemas a medida, como también se los conoce), y permite recolectar requisitos eficientemente.

Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una falsa realidad en cuanto al progreso del proyecto o la productividad. Además, hay que prestar especial cuidado con las estimaciones tempranas, aquellas que entrañan un mayor riesgo por el mayor desconocimiento del sistema y que deben ofrecer una amplitud de rango mayor entre mejor estimación y estimación pesimista.

Esta técnica sale beneficiada si se utiliza en modelos incrementales, ya que permite pulir poco a poco el sistema en función de las necesidades del cliente. Para su buen funcionamiento es fundamental que cada grupo o rol que participa en las reuniones se implique al máximo. Bien utilizada, esta técnica permite ver conflictos entre requisitos y eliminar aquellos menos útiles (costosos, poco beneficio o rendimiento logrado, etc.).

Estructura de la técnica

JAD consta de dos fases: planificación y diseño. Ambas tratan los requisitos, pero a distinto nivel de abstracción. Si bien en planificación se tratan los requisitos a un nivel más alto, estudiando sobre todo la utilidad y la viabilidad de los mismos, en la fase de diseño se realiza un uso intensivo de prototipos y se diseña la interfaz de usuario, el presupuesto, la calendarización y el esquema de la base de datos (en caso de que esto último sea aplicable al sistema a tratar). Cada una de estas fases llevaría en torno a entre uno y diez días. No confundir la fase diseño-JAD con la fase de diseño del proyecto; JAD es una técnica que se aplicaría en fase de planificación y análisis.

Cada fase, además, consta de tres partes: preparación (decidir quién asistirá a cada reunión), sesión o reunión propiamente dicha y conclusión, donde se extraen los principales puntos consensuados durante la sesión y se plasman en algún soporte permanente. El papel está bien, no caigamos ya en la tecnofilia, siempre que sea un soporte permanente, accesible por todos y, sobre todo, refleje un consenso aceptado por todas las partes. Algo así como un contrato.

Una vez terminado el proceso de JAD, se sigue con el modelo de desarrollo elegido. Es decir, JAD es independiente del modelo de desarrollo, con lo cual es aplicable siempre.

Las sesiones

Las sesiones tendrán lugar en lugares apartados, neutrales (sí, esto es la guerra: tú junta clientes, directivos y desarrolladores y no dejes a mano armas de fuego ni blancas o presenciarás una cutre película gore). Además se facilitará todo lo necesario para centrarse en el trabajo: piscolabis, refrescos, nolotiles, aspirinas, etc.

Los roles son los siguientes: moderador, ejecutivo cliente, usuario final, desarrollador, secretario y especialistas en determinados campos de interés para el producto. Estos últimos son los únicos personajes que no necesitan estar presentes todo el tiempo que dure la sesión. Es importante recalcar que cada rol debe ser desempeñado por gente clave, y no debería asistir más de ocho personas (como número orientativo).

Temas a tratar en las sesiones

En el JAD de planificación, que dura entre 1 y 5 días, se trata lo siguiente:

1.- Conducir la orientación. Introducción.

2.- Definir los requisitos de alto nivel.

3.- Limitar el alcance del sistema.

4.- Identificar y estimar las fases del diseño JAD.

5.- Identificar los participantes del diseño JAD.

6.- Planificar la sesión de diseño JAD.

7.- Documentar las decisiones tomadas.

8.- Conclusión.

En la reunión llevada a cabo durante la fase de diseño JAD se tratarán los siguientes puntos:

1.- Conducir la orientación. Introducción.

2.- Refiniar y limitar los requisitos de alto nivel identificados en la fase de plan JAD.

3.- Desarrollar un flujo de trabajo (workflow).

4.- Desarrollar la descripción de dicho workflow.

5.- Diseñar la interfaz de usuario.

6.- Especificar requisitos de procesamiento.

7.- Definir interfaces.

8.- Identificar grupos de datos y funciones.

9.- Documentar las decisiones consensuadas.

10.- Conclusión.

Para terminar…

Como hemos podido ver, tras las siglas JAD se esconde un conjunto de directrices, técnicas y consejos que no son nada nuevas. Aquél que esperaba oír hablar de filostros y forlayos (véase Memorias de un Ingeniero, de Alfredo de Hoces) se ha llevado un chasco. Sin embargo no nos confundamos: JAD reúne un compendio de buenas técnicas de demostrada utilidad, que pueden mejorar el tiempo de desarrollo y aumentar la visibilidad del proyecto. Además utilizada de forma regular, esta técnica puede aportar una mejora en el desarrollo de proyectos en general que la puede hacer muy útil. Finalmente señalar que, utilizada con inteligencia, puede hacer que la satisfacción de los clientes se vea incrementada.

Fuentes bibliográficas:

Rapid Development: Taming Wild Schedules, Steve McConnell

Caras nuevas, viejas caras Abril 20, 2009

Posted by ravelus in Crítica social.
add a comment
Radiografía de un hombre feliz

La historia del afortunado José Blanco, o Radiografía de un hombre feliz

Tras un año y pico de las últimas elecciones, y muy probablemente debido a la negativa influencia de la crisis y sus consecuencias, Zapatero ha decidido cambiar algunas caras en su gobierno. O administración, qué coño, que es una palabra muy americana, muy estupenda y muy de moda en estos últimos tiempos. Y claro, los periodistas, que viven de estas cosas (ojo, que no lo digo en tono peyorativo; al fin y al cabo no afirmo más que una verdad como un templo), se frotan las manos.

Para unos, el gobierno sufre el desgaste de la crisis; para otros, Zapatero reacciona positiva e inteligentemente; para unos terceros, el cambio era necesario pero los personajes no son en absoluto adecuados; para unos cuartos, que si muchos son socialistas; para unos quintos, que si el PP también metió a un buen rebaño de afiliados a su partido cuando gobernaban, para unos sextos… De verdad que no exagero; que todo esto lo he oído en las últimas semanas en la SER y en la Cope…

Jo, parece mentira que con lo mal que me caen tanto unos tipos como otros los siga escuchando, pero es que Francino es ameno, y en la Linterna sale un señor con voz de abuelo cascarrabias que estoy convencido que un día le dará un síncope y presenciaré una muerte en directo en la radio por atragantamiento con su propia saliva; pobre señor, ojalá me equivoque, pero es que parece que se le salen los higadillos por la boca cuando habla, qué abuelito más encantador.

Personalmente, me parece una reacción el cambio de algunas caras. Por aquello de la acción-reacción. Sin más. Todo intento siempre es positivo, por qué no decirlo. Ahora bien, que hayan metido a mi querido Pepiño Blanco de ministro dice mucho de nuestro país de pandereta, sevillana y olé. Que un señor que apenas tiene el bachiller llegue a ser Ministro de Fomento, da que pensar. Para que luego digan que EE.UU. es el país de las oportunidades. Para cojones los nuestros, sí señor. Luego está la de economía, que se lució con una ley del tabaco que estaba bien fundada pero mal implementada (cómo nos gusta esta palabra a los informáticos), y que después casi nos quita el vino, aunque dio marcha atrás a tiempo. Reconocer nuestros errores es de sabios, si señora; pero a mí no me toque mis Toros, mis Riberas y Cigales… que la tenemos. Vaya si la tenemos.

Para terminar está la de Cultura. Sinde-mocracia, sinde-scargas… ¿han visto qué fácil es crear chistes fáciles? Esta tipa me da miedo, viendo su trayectoria, su amor por la SGAE y por el colectivo tan idolatrado por mí al que pertenece… Tengo la sensación de que, muy a mi pesar, voy a dedicarle muchas líneas en este blog, seguro.

Hoy también ha salido hablando el de siempre, Aznar, que si no calla revienta, y como no nos quiere dar ese placer, pues tiene que desahogarse, el hombre. Y nuevamente ha sido para soltar gruñidos, rebuznos y demás sonidos inarticulados y sin sentido. También ha abierto el pico Monseñor Rouco, para decir que la Iglesia no está politizada. Qué va, no. ¿Quién ha dicho semejante blasfemia? ¡Rásguese las vestiduras y a la hoguera con él! ¡Por discípulo de Satán! ¡O por ser de izquierdas, que es lo mismo!

Bueno, como ven tengo para todos. Ah, sí, se me olvida IU, pero creo que estos están apagados o fuera de cobertura. Y los sindicatos, que se manifestaron contra doña Espe, la pizpireta. De mayor quiero ser como estos: cogerme horas sindicales a porrillo, ir a manifestaciones a que se me vea bien el jeto, y luego a echar en cara a los que no se afilian que me parto la cara por su culo. Sí que me parto, sí. Inviertan las palabras ‘cara’ y ‘culo’ y cambien alguna preposición más en la oración anterior y entenderán de que se parte la gente que vive de los sindicatos. Para que vean que yo también se hacer chistes fáciles.

Fariseos del siglo XXI Abril 12, 2009

Posted by ravelus in Crítica social, Experiencias.
add a comment

Esta Semana Santa hemos podido ver lazos blancos, himnos patrióticos, cuerpos policiales desfilando y otras mamarrachadas varias que bien poco tienen que ver con el significado religioso de la Semana Santa. Salvando la excepción de El Cristo de los Legionarios, ¿alguien me puede decir qué pinta el himno de España en una procesión en la que sacan a Jesucristo crucificado? ¿y que desfilen los distintos cuerpos policiales con él? ¿acaso la Benemérita existía ya en tiempos de Pilatos?

La gota que colma el vaso es la utilización de unas jornadas religiosas para hacer propaganda política. Que conste que no estoy ni a favor ni en contra de lo que proclamaban, simplemente digo que no es el momento. Esto, que parece algo simple y de cajón, algunos no lo ven así. Sonreía yo recordando cómo en aquél pasaje del Nuevo Testamento Jesucristo se ensañaba a latigazos con aquellos ruines mercaderes que utilizaron el Templo de su Padre a modo de Hipercor… ¿qué haría Jesucristo con todos estos fariseos? ¿con esos famosillos que aparecen en primera fila en las procesiones más sonadas de las ciudades más célebres por sus Pasos?

¿Acaso nadie ve que no tiene nada que ver una cosa con la otra? ¿Que en un momento de profundo fervor religioso como éste (para aquél que profese tal religión, ojo) no caben mítines políticos y sandeces varias?

Personalmente, Jesucristo para mí es todo un héroe. Quitando el rollo ese de que sea o no hijo de Dios, es un héroe en toda regla. Todo lo que hizo y dijo es bueno a ojos de cualquiera, y tiene un profundo sentido correcto aún en nuestros días. Si adoramos a El Cid, a Hernán Cortés, a Spiderman o a los 4 Fantásticos, que no son más que, al fin y al cabo, no nos engañemos, asesinos en unos casos y seres de ficción en otros, ¿cómo no vamos a postrarnos y decir “chapó” a una persona que resucitó a sus amigos y curó a sus enemigos? ¿Que en lugar de devolver los golpes perdonaba a sus agresores? En lugar de lanzar rayos por los ojos, telarañas con sus manos o bofetadas a rodabrazo, este tío le curó una oreja a uno de sus captores. Ni siquiera huyó cuando sabía que le iban a apresar. Soportó estoicamente por una causa, por una razón: enseñarnos que debemos amarnos los unos a los otros. Hubiera sido bien fácil vengarse de sus enemigos; cualquiera lo hubiera hecho. De hecho pienso que si lo hubiera hecho, por muy Hijo de Dios que fuera, hoy día sería un poquito menos grande y respetable para todos, particularmente para mí. Por eso pienso que realmente existió, y que no era humano. Un humano jamás hubiera actuado con tanta bondad. Tampoco pienso que alguien lo inventara; es demasiado inteligente, demasiado perfecto.

Por un mensaje de paz, por un mensaje de amor, por enseñarnos que el odio no lleva más que al odio, la ira a la ira, y la venganza a más venganza. Y que al final de todo esto, cuando se acaba el odio, la ira y la venganza, sólo queda una cosa: la Nada. La nada más absoluta y deprimente.

La lección que nos ha pretendido dar después la Iglesia sobre lo que era y es Jesucristo no tiene en absoluto que ver con todo esto, en algunas ocasiones, pero en ello no voy a entrar aquí. Personalmente he perdido todo el respeto a la Iglesia, pues me parece un impedimento más que un apoyo para acercarme a Dios. Quizá por ello sólo tengo los sacramentos que realmente instauró o apoyó Jesucristo: el bautizo, la penitencia y la comunión. Hoy día, en la mayoría de los casos, lo tocante a la Iglesia es poco menos que un circo.

Ojalá hubiera algún Jesucristo por ahí para correr a más de uno a gorrazos. A ver si espabilaba de una puta vez.

Patrones en Gestión de Configuraciones Software (VI y final) Abril 7, 2009

Posted by ravelus in Informática.
add a comment

Release-Prep Codeline

Este patrón trata de estabilizar un baseline para un release inminente, permitiendo paralelamente el desarrollo del proyecto sin afectar a tal release. Preparar un release implica pasar un buen número de pruebas, solucionar errores, preparar instaladores, documentación, etc. Si se realizan cambios importantes en este periodo crítico, pueden aparecer, de forma accidental, nuevos errores. Por otra parte, si congelamos el desarrollo por pulir el release, perdemos productividad.

Una posibilidad es crear una rama para tal release (al lector avispado que ha llegado hasta aquí leyendo los anteriores post seguramente ya se le había ocurrido tal solución antes de empezar a leer este párrafo), pero si bifurcamos demasiado pronto tal rama se pueden encontrar luego muchos errores en desarrollo que corregir en la release. Por consiguiente habrá que realizar muchas operaciones de fusión o merge, y tales operaciones sabemos bien que son complicadas. Aun así, es una buena solución, y es la que hemos ido adelantando en anteriores patrones.

¿Cómo solventar, entonces, los problemas de dicha solución? Crea la rama cuando el código se aproxime a la mayor estabilidad posible. De este modo el número de errores detectados (y consiguientes merges) será menor. Pero ojo: no esperes demasiado a crear tal rama de release o congelaras el desarrollo paralelo… en resumen: control, visibilidad máxima del progreso, y ojo al dato.

Task Branch

De este patrón podría hablar largo y tendido, y todo serían alabanzas; no en vano es el que usamos en la empresa donde trabajo y los resultados no pueden ser mejores: facilita el control de los cambios, la localización de dichos cambios y a qué afecta, facilita además la integración de dichos cambios en la rama principal, y favorece la productividad, junto con un software de control de tareas competente (Jira, OnTime, y en menor medida Bugzilla, Mantis…).

¿Cómo podría el equipo realizar múltiples cambios a largo plazo y que se solapan en una línea base sin comprometer la consistencia ni la integridad? No vale renunciar al uso de un control de versiones común, por descontado. El problema ya se propuso en otra ocasión: cómo controlar una tarea grande sin interferir en el trabajo de los demás.

La solución, una vez más: ramificar. Y es que el uso de ramas es tremendamente positivo, siempre que se usen con sentido, claro. Utiliza una rama diferente para cada actividad que represente cambios significativos en la línea base. Por tanto este patrón ya necesita un elevado soporte de políticas de desarrollo: definir tareas, asignar tareas, con un determinado tamaño, etc.

De este modo, disminuímos los riesgos (sus efectos, su probabilidad de ocurrencia). Una vez terminada tal tarea, la uniremos, junto con las demás, a la línea de desarrollo principal. Este merge deberá realizarse cuidadosamente para no romper nada que ya estuviera hecho (el lector ya debe estar pensando en otros patrones, como test unitarios, de smoke o de regresión…).

Este enfoque es muy útil cuando hay varias personas compartiendo un trabajo que debe integrarse en un todo. Por tanto, como hemos dicho, este patrón facilita la integración (si algún compañero lee esto se reíra de mí, pero tendrá que reconocer que si integrar es complejo y doloroso, sin este patrón sería una tarea bastante infernal…). Es importante integrar cada cierto tiempo cada rama (que representa a cada tarea) en la rama principal, sino la operación de fusión al final será muy trabajosa. Sin olvidar los riesgos que conlleva trabajar durante mucho tiempo con código desactualizado, lo cual ocurriría en ramas que se bifurcaron hace mucho y que han tardado mucho en integrarse. Solución: tareas cortas. ¿A alguien se le ha ocurrido ya que este patrón funciona de maravilla con metodologías ágiles, como Scrum?

Named Stable Bases

¿Con qué frecuencia integrar? Es importante estabilizar interfaces cuanto antes y que el resto de cambios, más frecuentes, tengan que ver con el cuerpo del código. Etiqueta claramente y de forma coherente aquellos puntos del desarrollo más estables. Son un seguro de vida…

Daily Build & Smoke Test

Control sobre los cambios: contener el potencial de errores en cada compilación del código. Solución: al menos una vez cada día, construir el proyecto (compilarlo) y ejecutar una ristra de Smoke Test. Sobre este patrón Steve Mc Connell sabe mucho, así que si desea obtener más información, el lector puede consultar Code Complete, donde se habla del asunto de forma somera, y Rapid Development: Taming Wild Schedules, donde se trata esta estrategia con mayor profundidad.

Con esto terminamos los patrones. Espero que hayan disfrutado de la serie tanto como yo.

———————————————————-

Referencias:

Steven Berczuk, Brad Appleton: “Software Configuration Management Patterns, Effective Teamwork, Practical Integration“

Patrones en Gestión de Configuraciones Software (V) Marzo 29, 2009

Posted by ravelus in Informática.
add a comment

Regression Test

En esta ocasión, el problema a plantear es cómo conocer si el código en un momento determinado durante el desarrollo no habrá empeorado desde los últimos cambios mientras se realizaban otras tareas. La solución pasa por utilizar otros test complementarios a los Smoke Test que tengan otras características diferentes. ¿Cómo son estas pruebas a realizar? ¿Qué politica seguir para su utilización?

Un problema que surge una vez podría darse más veces. Esto es lo que llamamos regresión. Con esta premisa construiremos unos test que tratarán de asegurar estabilidad en el desarrollo: antes de cada release, antes de un cambio particularmente arriesgado, realizaremos unas pruebas que nos permitan tener un cierto nivel de seguridad de que no hemos desandado parte del camino. Estos test se generarán a partir de cambios que ocurrieron en el pasado: hitos, funcionalidades especiales, etc. Se trata de unos test de caja negra que pueden no identificar qué es lo que falla, con lo cual necesitaremos apoyarnos en otros tipos de test, como por ejemplo los unitarios. Son de grano grueso porque prueban funcionalidades completas, comprueban la integración entre diferentes partes, etc.

Los casos que componen estos test pueden ser antiguos fallos detectados por estos mismos test, fallos informados por clientes, fallos detectados por otros tipos de pruebas… Al final habrá un gran número de casos, que nos ayudarán a comprobar que el sistema avanza. Si el sistemas no pasa las pruebas habrá ocurrido una regresión. Nunca se eliminan casos de prueba de este tipo, porque los errores pueden volver. Debido a su tamaño, estos test podrían ejecutarse por la noche, que suele ser cuando menos carga de trabajo se da. Si es posible ejecutarlos en cada operación de protección o check-in (lo cual es complicado debido al tamaño que van adquiriendo  estos test) podremos ver exactamente el punto en el cual el sistema retrocede.

Private Versions

¿Cómo evaluar un cambio complejo, beneficiándose del control de versiones, sin hacer ese cambio público? Pongámonos en el caso de querer probar un cambio localmente, sin correr el riesgo de romper el sistema global. Para ello, podemos establecer checkpoints en ciertos períodos del camino de tal cambio. Recordar que cuando se sube un cambio al control de versiones, el resto de ítems asimila tal cambio al actualizar sus propias revisiones para formar nuevas versiones. Por tanto, es necesario proveer un mecanismo para hacer checkpoints de cambios con la granularidad adecuada que el desarrollador estime conveniente. Esto podría proveerlo un área local de control de revisiones. Sólo los cambios estables van a parar al control de versiones público. Este sistema debería proveer también de un modo de integración para esos cambios inestables con el estado actual del proyecto. El funcionamiento de este área local funcionará como el control de versiones: una vez estabilizados los cambios, éstos se integran en la línea principal del proyecto siguiendo las políticas adecuadas.

Puede utilizarse, para esto, un repositorio local, una rama privada para el desarrollador en cuestión, etc. Algunas herramientas software de gestión de configuraciones proveen mecanismos para esto mediante, por ejemplo, sistemas de permisos del estilo de ACLs (Access Control List o listas de control de acceso, que vigilan el acceso a determinado elementos de un todo; en este caso, artefactos generados en un proyecto y gestionados por el control de versiones). Lo importante es que el programador pueda trabajar cómodamente subiendo los cambios cuando él considere apropiado, sin entorpecer el trabajo de los demás.

Release Line

¿Cómo realizar el mantenimiento de versiones publicadas (releases) sin interferir con el trabajo propiamente de desarrollo? Debería aislarse lo uno de lo otro. Una versión de producción o release evoluciona de forma totalmente diferente a una de desarrollo, ya que necesita mejoras y mantenimiento. Los problemas surgen cuando se detecta un problema en la versión de desarrollo que hay que actualizar urgentemente en la versión de producción: las operaciones de fusión (merge) son complejas.

Para evitar estas situaciones, es recomendable mantener cada versión de release en una línea de producción diferente. Esto permite que tal línea avance a medida que se solucionan errores. Para ello,  se podría crear una rama (o repositorio) para cada versión de producción. Posteriormente se actualizarán las mejoras y repararciones realizadas en la rama o repositorio de cada release de forma periódica, mediante una operación de merge. La línea de desarrollo (línea principal) será la guía, la cual recibirá los resultados de los merge fruto de las mejoras realizadas release a release.

———————————————————-

Referencias:

Steven Berczuk, Brad Appleton: “Software Configuration Management Patterns, Effective Teamwork, Practical Integration“