Hoy es el gran dia del open space, pero no es mi gran dia. Mi sesión de seguridad no ha sucitado ningún interés, asi que tengo que ver como meter la demo en otra.
Luego me hice una lista de las que me interesan, que eran ocho. Salieron cuatro, dos de ellas a la vez.
Primera sesión, propuesta por Nico Paez, acerca de colaboración académica. Su propuesta es hacer un equipo de trabajo con múltiples integrantes de varias facultades para resolver un trabajo práctico, una práctica de equipos distribuidos. Asistieron personas de La Plata, Paraguay, Chile, Perú, Tucumán, BA, Trelew y Salta. Dada mi no docencia, nada he podido aportar. Quedó ofrecida mi magra ayuda posterior.
Segunda sesión, por Sergio Gianazza, acerca de las raices ágiles, comenzando por el manifiesto, pasando por los principios y otras cosas similares.
Enunció lo de los estados: miedo, tristeza, enojo y contento, con su potenciador, la pasión.
Miedo + pasión: coraje
Tristeza + pasión: sensibilidad
Enojo + pasión: (no recuerdo)
Contento + pasión: (no recuerdo)
Yo lo veo más así:
Miedo + pasión: huida desesperada
Tristeza + pasión: suicidio
Enojo + pasión: asesinato
Contento + pasión: lujuria y lucha en el barro.
Pero es sólo un punto de vista.
Luego mencionó algo de la motivación, tipo que desde el big bang hasta 1600 era la reproducción (o el sexo, no recuerdo), luego el dinero y recientemente algo distinto. Le pregunté si lo que habia cambiado era la motivación o la percepción de la motivación y me parece que no me entendió o que si pero yo no entendí su respuesta, asi que agoté el diálogo con transparencia e integridad: "Sergio, me parece que esa idea es una tremenda gansada, pero tenemos meses por delante para deliverar" (es que vamos a renunciar a tc y poner un delivery, obvio).
Tercera sesión: nada interesante, me quedé en el bar configurando mi Fake Access Point, con un 95% de éxito:
Internet -> universidad de palermo -> host -> virtual con fake AP -> víctima
Logré que la víctima navegue un sitio en el host, pero no pude salir a Internet, quizas haya alguna protección en up, otro dia pruebo en casa.
Cuarta sesión: Equipos distribuidos. Gente de Ecuador, Bolivia, Perú y Argentina. Usar audio y video todo lo posible, pero grabarlos o generar minutas, ya que las cuentas claras mantienen la amistad.
Unos tienen video hd + proyector mas QoS.
Otros, estando a 15 cuadras un sistema pago. Por asuntos contractuales no pueden trabajar juntos los de dev y qa (distintas consultoras). Tienen las camaras apuntando a los pizarrones. El que necesita golpea la pantalla como si fuera un ventana y del otro lado suena.
Otro recurso: escritorios compartidos.
Conclusión: mucho peso en la comunicación.
Cierre a cargo de Juan Gabardini: mencionó que el generalista típico de los equipos pequeños no tiene un cv presentable (si, sé programar, pero administro los servidores y hago de mesa de ayudas... y tambien soy team leader), pero calza muy bien en agile. Luego, espero citar bien, una frase para enmarcar "en las empresas grandes se arman y desarman equipos por proyecto, que es un forma de locura"
Decano ingeniería UP: decano de universidad privada? prejuzgué que debía ser un bandido latoso. Quizas lo era, pero me sorprendió su lucidez, chau UBA, me voy con los oligarcas de la UP.
Dijo que los proyectos [de software] a diez años no son posibles. Agrego yo que la vorágine actual (que viene de hace no menos de una década), impide hacer nada a largo plazo desde el punto de vista tecnológico/táctico. Pero me parece que eso afecta a sólo un tipo de negocios. Hacer el soft de un barco, un avión, un sistema de tráfico, un sistema operativo, sigue siendo una tarea a mediano/largo plazo y hay que convivir con tener ciertas partes obsoletas al salir a producción.
Es un fenómeno del que ya habia leido en el espectacular libro "Los nuevos alquimistas : Silicon Valley y la revolución microelectrónica" de Dirk Hanson (1984). Comenta como al salir un avión de combate de la fábrica, la electrónica es obsoleta, dado que el tiempo que lleva diseñar un avión de ese tipo es de 10 a 15 años. No puedo recomendar que lean el libro en parte por que quién se lee un libro de tecnología de hace 25 años y en parte por que, ¿dónde lo van a encontrar, hijos de google?
En el 2009, le pregunté al autor: have you ever considered updating it?
Thanks for the kind note. At one time, I had considered updating the book to tell the story of the birth of the personal PC, as a coda to the story of the transistor on a chip.
However, as often happens, my publisher, Little, Brown and Co., chose not to keep the book in print. And you can't update an out-of-print book.
But now that I have jumped into the publish-on-demand world of BookSurge and Amazon, this aging alchemist might consider the project again if time and circumstance allow.
Regards,
Dirk
Ya que me estoy yendo tan por las ramas, hace rato que para el asunto del hardware obsoleto existen los FPGA. Para el caso de los aviones supongo que deben trabajar con módulos reemplazables. El avión sale de la fábrica con un cierto hardware que no es el diseñado originalmente, sino un subproyecto que arranca mas recientemente. No bien está el nuevo hardware, se reemplaza durante el tiempo de vida del avión varias veces, me imagino.
Pero acabo de recordar, aunque no de donde lo saqué, que para sistemas científicos satelitales, creo, se usan arquitecturas obsoletas ya que cumplen con lo necesario y son mucho mas conocidas que las que están en la cresta de la ola, lo cual a mi me suena razonable.
En el soft no existe tal problema, ya que el soft es actualizable, jeje. Pero ya es tarde y no pienso claro, esto es tema a desarrollar.
2011/10/13
2011/10/12
Agiles 2011 dia 2
Hoy no perdí el anotador, pero me olvidé la fuente, asi que cargué un alargador de seis metros con zapatilla de cuatro tomas con térmica de mas de un kilo en vano.
En lugar de atender a la key note, me puse a preparar una demo para proponer mañana en la open space. Tengo que montar un access point trucho para mostrar los inconvenientes de conectarse a redes desconocidas para integrantes itinerantes de equipos. Tiene que ser algo corto y efectivo, menos de 10 minutos para que haya tiempo para el posterior debate.
Primera charla, Hernán Wilkinson sobre los diez mandamientos de tdd, que resultaron ser mas. Transcribo y decoro mis notas:
Sacar los tests implícitos y efímeros de la cabeza del dev. Hacerlos explícitos, persistentes, repetibles y automatizables.
El buen programador lo es si y sólo si es buen tester.
La tabla de management:
Tdd es un cambio cultural, no automático, no ocurre por si mismo. Hay que proveer el entorno. Pair Programming ayuda. LLeva tiempo, que pata a mediano plazo. Mientras da una detección temprana de errores. No hay que abandonarlo por eventuales retrasos, o al menos hay que hacer explícita la desición. Tdd no es infalible. 100% cobertura no es posible ni tiene sentido. 60 a 80%.
Para medir la calidad de los test Mutation Testing: se invierten las relaciones de cada if y se ejecutan los test. Si no fallan, hay un problema.
No reemplazar QA por TDD. No mezclar Jr con Sr, si Jr con SSr y SSr con Sr. Para lograr el estado "test infected", puede llevar 3 a 4 meses.
Tabla de dev:
Primero se escribe el test.
Cada test debe tener un assert.
Un test a la ves (si estás muy creativo, el resto a una todo list afuera).
TDD no equivale a Unit Testing.
El nombre es el QUE, no el COMO y debe ser tan (ridículamente) largo como sea necesario.
En un test debe haber un solo caso.
No testear dos veces lo mismo.
Los test son otro sistema, keep clean.
No testear desde las interfaces, hacerlo desde el modelo.
No usar DB relacionales (al testear) por performance y por contaminación al modelo de objetos. Esto induce desacoplamiento.
No usar sistemas externos.
No hay que mockear el modelo.
TDD no implica buen diseño.
No preocuparse por la performance al comienzo.
Fin charla.
Luego me salteé el siguiente bloque para intentar levantar el fake AP. Me parece que lo logré, al menos Sergio lo vió. Pero no pude comprobar que funcionara, me quedé sin power. Termino de escribir esto y le doy.
La otra propuesta de sesión parte de que tengo un análisis FODA/SWOT de seguridad para una empresa de software que lleva a una colisión directa y brutal con el principio ágile de "transparencia".
Story Planning con Jeff Patton.
No voy a relatar lo que fue. Me desbordó totalmente, me va a llevar dias de trabajo subconciente asimilar toda la información. O un par de horas terminar de olvidar todo. Afortunadamente Sergio tiene algo parecido para dictar.
Buenas noches.
En lugar de atender a la key note, me puse a preparar una demo para proponer mañana en la open space. Tengo que montar un access point trucho para mostrar los inconvenientes de conectarse a redes desconocidas para integrantes itinerantes de equipos. Tiene que ser algo corto y efectivo, menos de 10 minutos para que haya tiempo para el posterior debate.
Primera charla, Hernán Wilkinson sobre los diez mandamientos de tdd, que resultaron ser mas. Transcribo y decoro mis notas:
Sacar los tests implícitos y efímeros de la cabeza del dev. Hacerlos explícitos, persistentes, repetibles y automatizables.
El buen programador lo es si y sólo si es buen tester.
La tabla de management:
Tdd es un cambio cultural, no automático, no ocurre por si mismo. Hay que proveer el entorno. Pair Programming ayuda. LLeva tiempo, que pata a mediano plazo. Mientras da una detección temprana de errores. No hay que abandonarlo por eventuales retrasos, o al menos hay que hacer explícita la desición. Tdd no es infalible. 100% cobertura no es posible ni tiene sentido. 60 a 80%.
Para medir la calidad de los test Mutation Testing: se invierten las relaciones de cada if y se ejecutan los test. Si no fallan, hay un problema.
No reemplazar QA por TDD. No mezclar Jr con Sr, si Jr con SSr y SSr con Sr. Para lograr el estado "test infected", puede llevar 3 a 4 meses.
Tabla de dev:
Primero se escribe el test.
Cada test debe tener un assert.
Un test a la ves (si estás muy creativo, el resto a una todo list afuera).
TDD no equivale a Unit Testing.
El nombre es el QUE, no el COMO y debe ser tan (ridículamente) largo como sea necesario.
En un test debe haber un solo caso.
No testear dos veces lo mismo.
Los test son otro sistema, keep clean.
No testear desde las interfaces, hacerlo desde el modelo.
No usar DB relacionales (al testear) por performance y por contaminación al modelo de objetos. Esto induce desacoplamiento.
No usar sistemas externos.
No hay que mockear el modelo.
TDD no implica buen diseño.
No preocuparse por la performance al comienzo.
Fin charla.
Luego me salteé el siguiente bloque para intentar levantar el fake AP. Me parece que lo logré, al menos Sergio lo vió. Pero no pude comprobar que funcionara, me quedé sin power. Termino de escribir esto y le doy.
La otra propuesta de sesión parte de que tengo un análisis FODA/SWOT de seguridad para una empresa de software que lleva a una colisión directa y brutal con el principio ágile de "transparencia".
Story Planning con Jeff Patton.
No voy a relatar lo que fue. Me desbordó totalmente, me va a llevar dias de trabajo subconciente asimilar toda la información. O un par de horas terminar de olvidar todo. Afortunadamente Sergio tiene algo parecido para dictar.
Buenas noches.
2011/10/11
Agiles 2011 dia 1
Lamentablemente he perdido mi anotador. Como le puse mi nombre, quizas lo recupere mañana, en cuyo caso editaré esto un poco.
Habló un tal Jeff Patton (http://lmgtfy.com/?q=jeff%20patton pero no se sientan lucky, pues hay otro jeff patton que sale primero).
Fui entonces a las sesión de unos brasileños que dijeron sim, sim cuando les dije fala devagar, pero no devagaron nada. Analizaron los motivos por los cuales se hacen branches y por que evitarlos.
Luego, Jorge Silva y Hernán Wilkinson mostraron las bondades de los lenguajes metacirculares y los closures, señalando la relación entre el lenguaje y el pensamiento. Como un lenguaje con esas bondades, permite pensar en cosas que en otros no. Si no me creen, miren una página de assembler y traten de pensar en interfaces.
Uh, me tocó a mi. Gracias a la tarea de apuntador de Sergio Gianazza (Teracode y http://www.dosideas.com, aunque este último no me consta, ya que no encuentro entradas recientes) salió mejor que en ninguna otra ocasión. Expuse un sencillo ejercicio de TDD guiado por el descubrimiento de vulnerabilidades en un sencillo sistema web que permite hacer posts. Es una versión mejorada de lo presentado en agile open sec 2010 y en TechTalks en Teracode. La diferencia es que esta vez logré encontrarle el flujo de requerimiento/vulnerabilidad -> creación test -> fail -> corrección -> pass. Me quedaron incluso unos minutos libres, pero no lo suficiente para la segunda vuelta donde expongo path traversal.
Almuerzo: entre otras cosas habían unas ciruelas envueltas en jamón o panceta de aspecto repulsivo, pero me comí no menos de seis, estaban deliciosas (perdón por el offtopic, pero realmente estaban buenas).
Me quería meter en el workshop de Jeff, pero habiendo cupo y llegando un minuto antes de que empezara, no, no, imposible, quizas mañana. Caí entonces en un Refactoring Golf a cargo de unos peruanos. Era un ejercicio diabólico en el que habia que, ¡sorpresa!, refactorizar código de una versión a otra evitando cortar y pegar o escribir, priorizando las capacidades de refactoring de eclipse. Esta bueno para hacer en otra ocasión, pero con más tiempo.
Finalmente asistí a algo de User Stories a cargo de Katia Sullivan. Muy clara y divertida. Además me regaló unas Planning Poker Chips, muy cool, parecen oreos.
Para compensar la pobreza de este reporte (por el extravío de mi anotador, que tienen mi nombre, si alguien lo encuentra...) la nota de color: la renuncia de JP produce estupor mientras se propaga como voraz incendio. Es que no esperaba perder el anotador, obvio, entonces no hice el esfuerzo de recordar y no le hago justicia a ninguna exposición.
Habló un tal Jeff Patton (http://lmgtfy.com/?q=jeff%20patton pero no se sientan lucky, pues hay otro jeff patton que sale primero).
Fui entonces a las sesión de unos brasileños que dijeron sim, sim cuando les dije fala devagar, pero no devagaron nada. Analizaron los motivos por los cuales se hacen branches y por que evitarlos.
Luego, Jorge Silva y Hernán Wilkinson mostraron las bondades de los lenguajes metacirculares y los closures, señalando la relación entre el lenguaje y el pensamiento. Como un lenguaje con esas bondades, permite pensar en cosas que en otros no. Si no me creen, miren una página de assembler y traten de pensar en interfaces.
Uh, me tocó a mi. Gracias a la tarea de apuntador de Sergio Gianazza (Teracode y http://www.dosideas.com, aunque este último no me consta, ya que no encuentro entradas recientes) salió mejor que en ninguna otra ocasión. Expuse un sencillo ejercicio de TDD guiado por el descubrimiento de vulnerabilidades en un sencillo sistema web que permite hacer posts. Es una versión mejorada de lo presentado en agile open sec 2010 y en TechTalks en Teracode. La diferencia es que esta vez logré encontrarle el flujo de requerimiento/vulnerabilidad -> creación test -> fail -> corrección -> pass. Me quedaron incluso unos minutos libres, pero no lo suficiente para la segunda vuelta donde expongo path traversal.
Almuerzo: entre otras cosas habían unas ciruelas envueltas en jamón o panceta de aspecto repulsivo, pero me comí no menos de seis, estaban deliciosas (perdón por el offtopic, pero realmente estaban buenas).
Me quería meter en el workshop de Jeff, pero habiendo cupo y llegando un minuto antes de que empezara, no, no, imposible, quizas mañana. Caí entonces en un Refactoring Golf a cargo de unos peruanos. Era un ejercicio diabólico en el que habia que, ¡sorpresa!, refactorizar código de una versión a otra evitando cortar y pegar o escribir, priorizando las capacidades de refactoring de eclipse. Esta bueno para hacer en otra ocasión, pero con más tiempo.
Finalmente asistí a algo de User Stories a cargo de Katia Sullivan. Muy clara y divertida. Además me regaló unas Planning Poker Chips, muy cool, parecen oreos.
Para compensar la pobreza de este reporte (por el extravío de mi anotador, que tienen mi nombre, si alguien lo encuentra...) la nota de color: la renuncia de JP produce estupor mientras se propaga como voraz incendio. Es que no esperaba perder el anotador, obvio, entonces no hice el esfuerzo de recordar y no le hago justicia a ninguna exposición.
Suscribirse a:
Entradas (Atom)