Hugh Laurie y Quique San Francisco son… ¡la misma persona!

Esto se me ocurrió el otro día viendo el programa de Cuatro El Hormiguero, en el cual asistió como invitado el actor y humorista Quique San Francisco, al cual admiro mucho por su inteligencia, por su sátira, por su acidez humorística y por su saber hacer, en definitiva.

Y en una de estas pensé: ¡coño, cómo se parece este tío a Hugh Laurie! ¡Cuántas cosas tienen en común! Puesto que a Hugh Laurie también lo admiro mucho, como sabrán aquellos que hayan leído esto, aunque debo reconocer que todo mi conocimiento de este actor viene por su archiconocida serie House M.D., he decidido hacer esta pequeña broma, sobre todo a los fans de ambos actores, ya que dudo mucho que alguna vez lleguen a leer esto los propios personajes implicados, más que nada porque sé de buena tinta que Hugh Laurie no se maneja del todo bien con el español.

Bien, vamos al meollo de la cuestión. Me propongo demostrar, de forma lógica y científica que Hugh Laurie y Quique San Francisco son la misma persona. ¿Sorprendidos? ¡Qué coño!, ¿es que no han leído el título del artículo o qué? Pues eso, céntrense, por favor. He aquí mi razonamiento, aunque primero vean las fotos que a continuación he colocado para centrar ideas. Me ha llamado mucho la atención el por qué al buscar “Hugh Laurie” en Google aparece un listado de vínculos y al buscar “Quique San Francisco” aparece en primer lugar vídeos de YouTube y Resultados de Imágenes. Debe de ser que Quique es más atractivo.

Quique San Francisco

Quique San Francisco

Hugh Laurie

Hugh Laurie

Vale, quizá viendo las fotos me digan que qué barbaridad, que no hay ningún parecido en absoluto, que tal, que cual y que Pascual. Aguarden un momento, lean y verán cómo tengo razón:

Ambos son actores.
Ambos son descuidados en su afeitado e imagen personal.
Ambos son hombres. En serio.
Ambos son maduritos, digamos cincuentones.
Es más: a ambos les ha llegado su época de gloria en la madurez. En esto también coinciden con George Clooney, pero aquí se acaban las analogías.
Ambos tienen el pelo gris, con ciertas deficiencias alopécicas.
Ambos tienen los ojos azules, ¡muy importante!
Ambos hablan un perfecto inglés. En el caso de Quique, para que hable un perfecto inglés hay que invitarle a unas cañas primeramente.

Bien, si nos fijamos ahora más concretamente en el personaje de Hugh Laurie, Gregory House, las analogías se multiplican:

A ambos les gustan las cazadoras de cuero.
A ambos les gustan las motos.
Ambos tienen problemas con las piernas: recordemos los accidentes de Quique y la eterna dolencia de House.
Ambos tienen una drogodependencia: Vicodina y cerveza respectivamente.
Ambos tienen un sentido del humor inteligente y satírico.
De hecho, ambos son humoristas, aunque no payasos, y mucho menos gilipollas.
Ambos tienen muchísimo carisma. Sus gestos les dan un carácter arrollador.
Ambos son muy inteligentes.
Ambos tienen el mismo nivel de éxito con las mujeres: Cero.

Por todo ello, he llegado a la conclusión de que Quique San Francisco y Hugh Laurie son la misma persona. ¡Chúpate esa, Sócrates, Einstein y demás pandilla de aficionados!

Ahora van, y lo cascan.

Anuncios

Patrones en Gestión de Configuraciones Software (II)

Private Workspace

Cuando el objetivo fundamental es trabajar en entornos cambiantes, como por ejemplo un desarrollador que debe retomar el trabajo de otro, es neceasario aislar el trabajo propio del realizado por el resto. Para lograr esto, evitando además inconsistencias en las copias locales de cada programador, tenemos este patrón.

Actualizar cada mínimo cambio que se realiza no parece muy eficiente. Parece más útil manejar un espacio de trabajo privado, que permita decidir cuándo y cómo cambiar el entorno para actualizar los cambios propios. Estos espacios de trabajo solamente contendrán los archivos que modifica cada individuo, junto con copias (que en principio no será necesario modificar) de los archivos del resto de desarrolladores. Aquellos archivos comunes que apenas cambian o afectan a todos deberían estar en el control de versiones, pero no en espacios de trabajo privados.

La forma de actuar sería actualizar a la última versión antes de empezar a trabajar. También sería muy útil mantener un espacio de trabajo privado diferente para cada rama en la cual se vaya a trabajar. Antes de hacer una protección (o checkin), se verificaría que el entorno no se ve afectado por los cambios realizados; para ello, habría que volver a actualizar, para asegurarnos.

Si los cambios realizados van a llevar demasiado tiempo, quizá sea bueno actualizar más a menudo, con mayor frecuencia.

La idea del Private Workspace yo la entiendo como una “caja de arena”.

Repository

¿Cómo obtener las versiones adecuadas de los componentes deseados a la hora de crear un nuevo espacio de trabajo? ¿Cómo recuperar versiones y revisiones antiguas, etc.? Sería útil, además, tener una traza de los cambios para cada artefacto, revisión a revisión. Teniendo un sólo punto de acceso (el repositorio), es más sencillo y transparente la creación de nuevos espacios de trabajo. El mismo control de versiones sirve para aplicar este patrón. Para aplicarlo, crea y etiqueta cada versión para que sea sencillo descargar estas versiones en nuevos espacios de trabajo. Utiliza versiones y ramas de forma coherente.

Private System Build

Este patrón enfoca el problema de cómo verificar que los cambios locales realizados por un individuo no afectan al sistema de forma nociva. ¿Qué elementos externos al trabajo local (pero relativos al proyecto) se verán afectados por los cambios realizados? Antes de subir los cambios al repositorio, realiza una construcción local (private build) de todo el sistema para ver si todo funciona correctamente. Tal construcción debe imitar lo más fielmente posible la construcción real del sistema: misma estructura de directorios, mismas dependencias, etc. Es decir, una construcción muy similar al nighty build (construcción automática de todo el sistema que se realiza diariamente por las noches, que es cuando el sistema tiene menos carga de trabajo).

Si el sistema es demasiado grande, se pueden realizar construcciones incrementales, con la posibilidad de excluir artefactos que no afecten de ningún modo. En caso de encontrar un error o conflicto entre el trabajo local y el de otros, realizar un merge cuidadosamente y hablar con el desarrollador de cuya parte del código existe tal conflicto.

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

Referencias:

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

La Sexta rebasando sus propios límites

la_sexta-7659171Éste no es un artículo como aquél y como este otro en los cuales elogiaba a laSexta, no. Éste no es un pequeño discurso para agradecer a los de “Sé lo que hicísteis…” su labor crítica, no. Este es un pequeño escrito para demostrar a los que piensan que un servidor tiene una fe ciega en algo o en alguien están equivocados, que el sentido crítico prevalece sobre todo y sobre todos.

Digamos que si la ética periodística fuera una especie de área circular, Telecinco la rebasa por uno de los puntos de la circunferencia que delimita tal círculo y la Sexta lo empieza a rebasar por otro. Diferente, pero también lo rebasa. Una cosa es criticar y someter al juicio del espectador lo que nos venden en otras cadenas. Despertar la mente crítica del espectador. Esto es algo loable, y bien merece un aplauso. Otra cosa muy diferente es engañar a noticiarios, programas de televisión y demás y por ende, al público, con noticias falsas, para luego cachondearse de que los demás medios “no contrastan las noticias“. Esto bien merece un abucheo. Porque vamos a ver, demagogos de pacotilla: ¿quién cojones contrasta las noticias en este país? ¿a qué llamáis contrastar noticias? si yo hago un montaje encadenándome a la plaza mayor de Valladolid diciendo que quiero que me devuelvan a mi perrito Lulú y van los noticiarios a cubrir la noticia, ¿cómo demonios van a contrastar y comprobar que lo que digo es cierto? ¿me llaman y me preguntan si lo que hago es una farsa? ¿despertamos, entonces, el carácter avieso y desconfiado de los periodistas? Si así fuera, yo no me creería ni la mitad de la mitad de lo que se dice en la tele: niños con hambre en el tercer mundo, guerras, conflictos, desastres naturales… ¡todo un montaje! ya me gustaría a mí, ¿verdad, señores de la Sexta? Ya lo veo en los próximos años, de seguir así: periodistas en países como Camboya o Kenia preguntando a los niños que mueren de hambre: “¿oigan, esto no será un montaje de la Sexta, verdad?”

Bastantes montajes hacen ustedes con sus noticiarios manipulados, probablemente los más manipulados de la televisión. Los más partidistas, los más coloristas, los menos objetivos. La gente es cada vez menos inculta, señores, gracias a Dios (es una expresión, no me vayan a recriminar esto ahora), y cada vez más colocaremos a cada individuo en el lugar que le corresponde. Si quieren criticar, critiquen a todos los partidos, que bien se lo merecen y bien cuestionables son todas sus acciones. No que sólo critican a los de un color, el azul, y besan el culo a los de otro color, el del clavel (si dijo color rojo se malinterpreta lo que quiero decir).

No me gustó el montaje de la lotería de navidad del Follonero, me pareció que rayaba lo absurdo, pero al fin y al cabo no hacía daño a nadie, y bien mirado se lo podía tomar uno con buen humor; aunque engañar a los noticiarios y no sólo a los estúpidos programas del corazón me parece que se sale de lo razonable.

La sobrada de esta ocasión es la del Gran Wyoming y su maltrato a la “becaria”. Un montaje en el cual el tipo este (al que todavíawyoming le quedaba algo de dignidad después de su maestría en CQC, programa que, todo hay que decirlo, no ha vuelto a ser ni su sombra sin aquellos personajes) se comporta como un auténtico cabrón facha insultando a una chica. Porque en este país las palabras “cabrón” y “facha” van siempre muy asociadas, aunque la primera no tenga, en principio, nada que ver con la segunda.

Señor Wyoming: una cosa es simular una web de apoyo a Julián Muñoz o una plataforma de apoyo a los programas del corazón, lo cual es bastante gracioso y no hace daño a nadie, y otra cosa es jugar con semejante vejación. Si lo ha hecho usted, como dicen por ahí, para subir su lastimosa cuota de audiencia… déjeme entonces que le compare con su cadena “amiga”, Telecinco. Si quiere ser respetado, olvide las audiencias. Ahí tiene la 2: probablemente el canal que menos se preocupa por la audiencia, y es un canal respetadísimo, bueno, al menos por todas aquellas personas con algo de cultura, chonis abstenerse.

Quizá este picado porque sí, es verdad, me lo creí. Quizá le sienta como un guante ese comportamiento al Gran Wyoming pues, a veces he seguido su programa y en el directo se le notaba a veces cierto nerviosismo con el por dónde me va a salir tal o cual colaborador, por la izquierda o por la derecha del plató. Me lo creí porque no le veo a gusto haciendo ese programa, tiene pequeños errores de directo. Finalmente, me lo creí porque me pareció de muy mal gusto si aquello era un montaje.

Me prometí a mí mismo que si esto era un montaje (no, no puede ser, esto pasa de lo absurdo, ¡coño, parece que esté hablando de Telecinco!) lo denunciaría en mi blog, que no quedaría impune, que cuando tengo que dar palo a unos se lo doy, y cuando se lo tengo que dar a otros también. Si no, esto no sería lo mismo.

Señores de la Sexta: si su objetivo es que dejemos de creer en la televisión, van por buen camino: a este paso, todos apagaremos la televisión y ustedes y todos los demás que salen en la caja tonta se irán a zurrir mierdas con un látigo. Buen provecho.

Patrones en Gestión de Configuraciones Software (I)

Existen numerosos tratados sobre el tema que nos atañe hoy, aunque los principales autores son, sin duda, Steve Berczuk y Brad Appleton. Ambos, que se conocieron en una de las numerosas conferencias sobre el tema, decidieron escribir juntos un libro que reuniera sus ensayos y artículos anteriores. El resultado es Software Configuration Management Patterns, Effective Teamwork, Practical Integration.

Este libro trata de recoger todas aquellas prácticas y técnicas que nos ayudan a crear un entorno de construcción software adecuado al proyecto que estemos desarrollando.

Personalmente, no veo adecuada la idea de llamar a estas técnicas “patrones”, puesto que entiendo como patrón una solución concreta, aceptada y comprobada a un problema bien identificado. Yo diría que lo que se presenta en este libro son más bien técnicas, buenas prácticas, etc., porque si aceptamos la idea de Private Workspace como patrón, por ejemplo, entonces las miles de ideas que recoge McConnell en su Code Complete podrían, así mismo, identificarse como patrones, creo yo. Y todo en informática sería “patrones”.
Como ejemplo: problema: ¿Como preveer posibles situaciones caóticas y minimizar sus consecuencias? Solución: Análisis de Riesgos. ¿Es esto un patrón? para mí, no.

Al final, muchos patrones acaban repitiendo una serie de ideas y técnicas que, de llevarse a cabo, estaríamos aplicando tales patrones sin siquiera ser conscientes de ello, con lo cual se podría haber escrito un libro que explicara una serie de técnicas y no andarse con tanta zarandaja. En cualquier caso no soy más que un humilde ignorante, así que si alguien tiene una razón de peso para convencerme de que las ideas recogidas en el libro de Berczuk son patrones y no otra cosa, le pido tenga a bien el explicarme y corregirme.

Realizado este análisis o crítica de la obrita, de unas doscientas páginas, entramos a fondo con los patrones (aceptaré este término puesto que es el que utiliza el autor, y no soy yo nadie para ponerme en su contra). Este repaso nos llevará varios artículos, en los cuales trataré de resumir los patrones, de la forma más escueta y entendible posible. De todos modos, si alguien desea una explicación más extensa de los patrones, gráficos, ejemplos, casos de estudio, etc., siempre puede recurrir al libro original, lo cual recomiendo.

NOTA: En lo que a continuación se presenta, entenderé que el lector está familiarizado con el vocabulario técnico propio de la GCS (Gestión de Configuraciones Software), y que por tanto conoce perfectamente lo que significan palabras como espacio de trabajo, codeline, revisión, versión, etiqueta, rama, control de versiones y merge, así como las operaciones de check-in, check-out y actualización. Si no es así, por favor revise en la Red aquellos términos que no conozca, pues se utilizarán asiduamente.

Clasificación de los patrones

Berczuk y Appleton clasifican sus patrones en dos categorías: aquellos que atienden al espacio de trabajo o workspace y aquellos que tratan sobre el desarrollo del código propiamente o codeline. Entre los primeros, se situarían los patrones Mainline, Active Development Line, Private Workspace, Integration Build, Private System Build, Repository, Third Party Codeline, Task Level Commit, Smoke Test, Unit Test y Regression Test. Entre los segundos tendríamos Private Versions, Release Line, Release Prep Codeline, Task Branch y Codeline Policy.

Los patrones

A continuación presentaremos, en subsecciones para que se visualicen mejor, los distintos patrones, de una forma anotada, informal, sin presentar el problema, fuerzas, solución, interacciones, etc., sino simplemente enumerando las ideas interesantes que conciernen a cada patrón. Para más información, remito nuevamente al lector a hacerse con el libro.

Mainline

El más fundamental de todos. El que da sustento y base al resto. Presenta una política de saber hacer, de cómo organizar y cómo distribuir el código en el control de versiones.

Si abrimos muchas ramas (versiones de producción, distintas plataformas, etc.), luego es realmente problemático tener que reunirlas mediante un merge. No es cuestión de no utilizar ramas, sino de utilizarlas coherentemente y tratando de reunirlas con la rama principal cuanto antes. El patrón aconseja evitar iniciar ramas a partir de otras ramas secundarias, porque el merge sería complejo de realizar. En su lugar, es conveniente crear ramas para versiones de producción (release) y mantener la rama principal para desarrollo, que es la que tiene la mayor parte del trabajo. Así, la mainline es la raíz del proyecto en el control de versiones. Antes de crear una nueva rama para un nuevo release, es conveniente unir la rama del último release con la rama principal.

Otras razones para crear ramas podrían ser: productos paralelos distanciados con el original, en los cuales se tengan previstos pocos merges con la rama principal; integración del trabajo de desarrollo, de este modo el mainline no se detiene y puede progresar añadiendo funcionalidad para un release posterior.

Active Development Line

Este patrón supone como asimilado el patrón Mainline, que acabamos de presentar.

Trata de dar respuesta a la pregunta de cómo gestionar el codeline en el cual está trabajando un grupo de gente de forma simultánea. Para ello, es conveniente hacer que el codeline sea lo más estable posible para que no interfiera con el trabajo de nadie. Esto es particularmente importante en fases de depurado y pruebas, que es cuando más operaciones check-in y check-out se realizan, y en las cuales surgen la mayoría de los problemas.

El acceso exclusivo a un recurso no es una opción, porque sería muy poco eficiente. La solución es crear un Mainline estable y activo; no perfecto, pero sí útil. Instanciar políticas de uso. Para ello, realizar cambios frecuentes, puntos de comprobación bien probados. ¿Qué estabilidad es necesaria? depende de quién usa el codeline, cómo es el ciclo de release, qué mecanismos de pruebas se usan, cuánto (con qué rapidez) evoluciona el sistema, daños de los riesgos que causarían el que algo se rompiera, etc. Es decir: atender a las características del proyecto.

Ojo con las políticas de testado pre-check-in: si son muy largas los programadores las utilizarán con poca frecuencia, alargando tiempos entre check-ins con más cambios en cada uno, y por tanto merges más traumáticos al tener que reunir más cantidad de trabajo. Por ello, alterna tests exhaustivos con otros más ligeros (uno diario, cuatro o cinco diarios, respectivamente), o en épocas de release, abre una rama para no detener la rama principal. Que los test ligeros sean personalizados para cada espacio de trabajo. Periódicamente, integra los espacios de trabajo y ejecuta los test más exhaustivos.

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

Referencias:

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