Boxeadores en la cabina de un avión

No se si es leyenda urbana o realidad el que a los boxeadores de cierta categoría se les prohibe pelear fuera del ring, se los considera armados. Suena razonable que tenga algún tipo de restricción alguien que te puede matar de una piña.

Si es historia el caso del famoso hacker Kevin Mitnick[1] a quien se le prohibió usar computadoras y teléfonos dada su capacidad de utilizarlos para cometer delitos.

A la luz del mediático caso de la chica en la cabina, cuyo nombre no citaré dado que los abogados son muy creativos, me parece que una restricción similar se debería aplicar a ciertas personas en relación a su atractivo físico.

No sé cuantas mujeres puedan comprender realmente este punto de vista que la mayor parte de los hombres si no comprenden, al menos sufren. Lo cual no es atenuente: esos pilotos sean bastante pelotudos.

Si la invitaron a la cabina es como si hubieran provocado a Tyson, son unos insensatos suicidas.

Si ella tomo la iniciativa, se debería considerar que en las simulaciones, además de los escenarios como "fallo en motor 2", halla que agregar "entra vedette a la cabina"

Hechos como este lo más probable es que no sean inusuales[2], la diferencia es que fue durante una maniobra delicada y que quedó filmado. Ahí está la clave, la evidencia.

Echando a los pilotos lo que se gana es "no seas pelotudo, no filmés", que es un punto de vista completamente legítimo para los actos privados. Apuesto a que aunque ahora es imposible entrar a una cabina, en unos pocos meses esto pasará al olvido y volverá la normalidad.

Si los pilotos brindan capacitación, contando su experiencia, quizás se puede rescatar "no seas pelotudo, no hagas pelotudeces". Además pagarían su deuda pasando vergüenza delante de centenares de otros pilotos. Tambien hay que recordar que "los conversos son los peores" y tras semejante cagada, no tienen mucha opción, ¿no?

Me pregunto que pasaría en el caso inverso, un galancillo entrando en la cabina de una tripulación femenina.

Quizás la solución de fondo es que las tripulaciones sean mixtas.

¿Qué tiene que ver esto con Seguridad y Agile? Mmmh, se complica. La verdad es que me gustó la comparación con el boxeador y lo de la simulación, le escribí todo esto alrededor como para que no sea un twitt.

Podría rescatar que en Agile el error se suele utilizar más para aprender que para castigar, suponiendo que quien erra está en mejores condiciones de no volverlo a hacer y quienes están alrededor tienen la oportunidad de aprender de la falla sin transitarla.

[1] https://es.wikipedia.org/wiki/Kevin_Mitnick

[2] perdón, pero a este tipo de noticias no amerita que las documente mucho, recuerdo haber visto algo por ahí.

RTFN

Para mi hay cuatro maneras principales, útiles y necesarias de documentar. Ninguna es descubrimiento mío ni tampoco es novedosa esta agrupación.

Nombres significativos en el código

Esto viene para contrarrestar la práctica iniciada con la falta de memoria, las tarjetas perforadas y la programación matemática y científica de usar letras en lugar de nombres. Esta ok usar x,y y z cuando estás hablando de coordenadas, pero no cuando deberían ser yaOrdenado, cantidadPajaros o nombre.

Esto lo he sacado del dolor de ver código ajeno o propio un tiempo despues.

xDoc (javaDoc, phpDoc, etc [1])

La vida es corta, por favor leé [2], no confundir con xDoc[3]

Intenciones y motivos

¿Por qué elegí sequential search en lugar de binary search? Pues por que se invoca dos veces en toda la ejecución y son cien elementos, no vale la pena ordenar.

El código puede ser muy claro, los nombres muy significativos, pero el propósito y los motivos es algo externo al programa o a su código fuente.

Esto lo he aprendido en un excelente curso de arquitectura de sofware en la ECI y el libro del docente que lo dictó [4]

Tests

Los test son de las mejores documentaciones, pues a diferencia de las anteriores, no se desincroniza con el código. Es común encontrar ejemplos que no se pueden ejecutar por algún motivo, pero los tests, si están funcionando, sí se pueden ejecutar, valga la redundancia.

Los tests son autodocumentación, aunque no tengan ningún comentario. Muestran exactamente como se utilizan los artefactos, que reciben y que deben devolver.

Quizás esto no cumpla con las normativas, pero si con el pragmatismo de "código funcionando antes que documentación exhaustiva" [5]

Voy a suponer que aunque no del todo de acuerdo, al menos me has comprendido.

¿Quá hay de malo en:

/**

 * Load configuration

 */

void loadConfig() {....}

?

¿Ya viste? ¿No? ¿Y ahora?

/**

 * Set date

 */

void setDate() {....}

/**

 * Get date

 */

Date getDate() {....}

/**

 * XXXX YYYY

 */

void xxxxYyyyyyy() {....}

Es esto casos es difícil defender xDoc y me frustra el haber usado "nombres significativos". ¿Para qué voy a ponerle nombre significativo y despues ponerle lo mismo en la documentación? Me recuerda esta atrocidad:

//increment cycle counter

countC++;

Propongo entonces la incorporación de un nuevo tag xDoc que sea RTFN (Read The Fucking Name)

/**

 * @RTFN

 */

void setDate() {....}

Como humanos no tenemos ninguna dificultad en entenderlo y si hiciera falta, se podría enseñar a xDoc o Doxygen a interpretarlo, cuando lo hallen que pongan en la descripción o el mismo nombre de la función o método o reemplacen según un mapa o una heurística.

El mapa puede tener nombres comunes como

[

   "setDate":"Set the date",

   "drawButton":"Draw the button"

]

Y la heurística se aprovecharía de camelCase:

setDate -> Set Date

Parece poco, pero la verdad es que poner uno esa documentación es kafkiano.

No tengo el ímpetu ni el tiempo para hacer los patches necesarios a las herramientas para poder ofrecerlas a sus desarrolladores (no es lo mismo "te propongo una idea" que "te propongo una idea y acá tenés la implementación"), pero estoy dispuesto a secundar a quien lo haga.

Gracias por las ilustraciones a Greta[6]

[1] https://en.wikipedia.org/wiki/Comparison_of_documentation_generators

[2] http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html

[3] https://maven.apache.org/doxia/references/xdoc-format.html

[4] Software Architecture: Foundations, Theory and Practice - Nenad Medvidović y otros http://www.wiley.com/WileyCDA/WileyTitle/productCd-EHEP000180.html

[5] http://agilemanifesto.org/

[6] http://lanilunatejidos.blogspot.com.ar/