Agiles Argentina 2014

Sensación general

Agotador, 90% ok, contento con la gente y el lugar. Como que faltó gente.

Los números de la asistencia

Ha habido un record de proporción de inasistencia, superando incluso a los prodigiosos Agile Open Seguridad. De todos modos, vino mucha gente. De unos 250 inscriptos vinieron 90. 80 el viernes y 40 el sábado, de los cuales 30 habían venido el viernes

A varios nos llamó la atención que el viernes fuera más gente que el sábado. Varios motivos se me ocurren:

• El viernes ya aprendí lo suficiente
• El viernes ya me dí cuenta que no tendría que haber venido
• El viernes iba a ir a trabajar de todos modos

De este último motivo surgió el chiste:

• Yo no puedo venir el sábado por que tengo familia.
• Yo no puedo porque salgo el viernes.

Hubo gente que vino desde Santiago del Estero, Tucumán, Mar del Plata, Bariloche, Brasil y seguro algún otro lugar que no recuerdo. Me dan ganas de ir al Agile Open de Tucumán, pero el impacto familiar y económico de haber ido a Mar del Plata aún está fresco.

Paula A. y UB

Como en otras ocasiones, indispensable su presencia, lidiando con cada problemita que aparecía. Pobre, venía de otro evento, mucho más pesado, no como este Open Space. En un lugar grande como la UB, hacer actividades en horarios no previstos se complica, cuesta encontrar la llave por que quien es reponsable ese día no asiste.

Tribus foros

De modo bastante mal educado, cuando estaba por empezar la retrospectiva final del evento, interrumí y manifesté que quería hacer un juego de tribus desde el primer minuto de la conferencia. Alan C., gran aprovechador de situaciones inaprovechables, convocó a las tribus y tiré la consigna: para acá los que están inscriptos en Agiles Argentina, por acá los que no. Respetando esta separación, los que están en Foro Agiles y los que no. Quedaron tres grupos parecidos:

		Agiles Argentina
		Si	No
Foro Agiles	Si	1/3
	No	1/3	1/3

Así que han sido convocados a normalizar su situación.

En alguna sesión conversamos acerca de hacer una depuración, como podría ser migrando a google groups. Tambien nos intriga que pasa a nivel de listas regionales. Pienso ahora que lo mejor sería usar sólo agiles-argentina y que se creen o utilicen listas reducidas cuando la ocasión lo amerite.

Por ejemplo, para la organización de este evento se convocó la lista y se hizo una nueva, privada y descartable, con los diez o quince que estabamos interesados alrededor de Soledad P.

¿Por qué no hay lista CABA/GBA? ¿Para qué la querríamos? ¿Es CABA/GBA == Argentina? No es que CABA/GBA se adueñe de Argentina sino que MDQ, Tandil, etc. no se adueñan de Argentina.

Ekoparty Challenge

La organización de la ekoparty (www.ekoparty.org) donó generosamente dos entradas para regalar, con la condición que no fuera al azar. Tratándose de un ambiente alejado de la seguridad preparé dos actividades: una de preguntas de seguridad informática y la otra de pensamiento lateral. No sé si por falta de interés, dificultad en poder asistir a los tres días que dura ekopary o una falla mía de comunicación, NADIE asistió, así que devolví la entradas. Algo en qué pensar.

Catering

Aunque un tanto ineficiente, nadie se quedó con hambre. Pienso que sería mejor que se formaran como grupos y comprar una horma de queso, un jamón entero y cosas así, pero eso requiere una mayor organización.

El viernes hubo que ajustarle los piolines a la asistencia, que tenía una actitud tipo conferencia convencional, donde hay algún tipo de servidumbre que limpia las mesas, por ejemplo. El sábado todo estuvo bien.

Convocatoria Botona

Había convocado en agiles y en seguridad-agile voluntarios para las ingratas tareas de registrar la asistencia en la puerta y estar atentos en general, cosa que no hizo falta. Durante un momento estuve un tanto resentido, pues las dos personas que se acercaron (Maxi R. y Javier V.) son de seguridad-agile y son dos de veinte contra cero de 750. Medio que se perdieron el marketplace y era su segunda vez en Open Space. Cuando reclamé en la retrospectiva del viernes, Diego F. me hizo notar que probablemente la convocatoria había dejado afuera a gente que quizas de buen grado hubiese tomado la tarea de registración.

Ante la justeza de su perspectiva perdí todo resentimiento, salvo conmigo mismo por no haberme dado cuenta. Tomamos su propuesta de "registro tipo cumpleaños": el último en llegar recibe al próximo, que funcionó bastante bien y pienso será la manera de proceder en futuras ocasiones.

Seguridad, Diversión y Aprendizaje

Alguien mencionó este concepto. Yo, que ya tengo los pies inflados de "seguridad" prefiero pensarlo como Protección, Diversión y Aprendizaje. Para cualquiera que haya asistido a alguna actividad o capacitación mía, es evidente que al concepto de Diversión ya lo tengo en muy alta estima, al punto que en alguna ocasión he dicho "este curso debe resultar entretenido, fundamentalmente para mí, pues sería imperdonable que me quede dormido".

Lo que siempre he dado por supuesta es la Protección, en el sentido de "preguntá lo que quieras, si supieras no hubieses venido", pero me faltaba el "no se te está evaluando", que pasaré a incorporar desde ahora mismo.

Sesión de juegos de seguridad

Por fin he logrado derrotar a mis archienemigas María T. e Ingrid A., que durante años se han resistido a considerar la seguridad o su educación como un tema relevante. Por consejo de Ricardo C. que había visto esta misma actividad en Mar del Plata y con la excusa de que conmigo se divierten en los breaks, vinieron y se han lamentado de todos estos años perdidos, jaja.

Anécdota módulo de seguridad

Esta bloque ha sido editado a partir de feedback en privado.

Alguna persona mencionó que está dictando capacitación para desarrolladores y le pregunté por el "módulo de seguridad", a lo cual contestó algo que me dió la sensación que medio que no lo tenía, qué le podía sugerir. En el momento, más por instinto que por malicia me retraí y lo remití a OWASP Top Ten, quedándome con una leve sensación de mezquindad de mi parte.

Según conversaciones posteriores, tuvimos una falla de comunicación, ya que tuvo una actitud como de tanteo, dándome la oportunidad de que yo ofreciera algo, pero como no estoy brindando capacitación fuera del trabajo o estos eventos, ni me dí cuenta.

Me encuentro con que hay alguien que manifiesta interés, pero esto no se refleja en el día a día de las listas de ágiles, ni en los eventos.

La sensación que esta situación me dá es la misma que tiene todo lo que tiene que ver con seguridad, en la parte de la comunidad de seguridad que conozco no está tan enraizada como en agile el espíritu de compartir conocimiento, dejando de lado la discreción que este tema a veces requiere.


Me agarra una terrible inquietud. La falta de enganche a las propuestas de sesiones y conversaciones de seguridad, ¿es resultado como vengo pensando de una falta de priorización o tiene que ver con no compartir?

El rincón de la vergüenza

Por suerte creo que nunca lo dije y menos lo escribí: es complejidad ciclomática, no ciclotímica. Alguien lo mencionó y revisando en mi mente encontré mi error.

Agradecimientos

En eventos simétricos como estos, no me gusta agradecer ni recibir agradecimientos, pues en cierto modo siento que eso nos separa. Si dijera gracias por participar sería "vos a nuestro evento". Si dijera gracias por colaborar sería "vos a nuestra tarea".

Sí puedo agradecer a quienes comparten su conocimiento, por hacerlo nuestro.

Agile Open MDP 2014

Muy buen evento, con una concurrencia mayor a la prevista (o sea más de la mitad de los inscriptos), sin inconvenientes logísticos y un buen clima que nos saludaba desde afuera.

Notas de la sesión de retrospectivas

Algunas personas manifestaron que pese a tener las retrospectivas instaladas había una suerte de estancamiento, una de ellas sospechaba que podía ser por la presencia del PO.

Con respecto al estancamiento, conversamos acerca de usar recursos como ECVP (gracias a Sergio[1] por habérmelo enseñado en su momento y recordado ahora):

Cada uno dice como se siente:

• Explorador: viene a proponer soluciones, buscando formas novedosas de encarar los problemas.
• Comprador: no viene a proponer, pero si a escuchar ideas.
• Vacacionista: viene a la reunión porque prefiere estar acá que en otro lado.
• Prisionero: prefiere estar en otro lugar y no en esta reunión.

Con lo del PO se complica. Es para un equipo distribuido y el PO es english speaker y está todo bien, pero puede estar estorbando. Esto me produjo el primer premio de la jornada.

Pienso, la restrospectiva sirve para mejorar el producto y el proceso. El producto es del PO, obvio, pero ¿el proceso y los subproductos?

Por ejemplo, en Amazon el producto es el sistema de ventas. Pero para desarrollarlo generaron una serie de subproductos como AWS y sus amigos, de importancia comparable al sistema de ventas. Algo parecido con Netflix y ChaosMonkey [2].

Los PO o mejor aun quienes ponen el billete suelen tener, no sé como decirlo, el comportamiento por default de ciertos algoritmos de expresiones regulares: "greedy". Y uno puede tener una cierta reticencia a producir algo y que otro se lo apropie. Mm, no sé, quizás amerita otra entrada aparte.

Notas de la sesión de testing

Lo que resta de este bloque será salvajemente editado resultado de las conversaciones en foro-agiles[3]/agiles-argentina[4] (si no los conocés ¿qué esperás para subcribirte?). Antes de tildarme de desprolijo, recordá que lo perfecto es enemigo de lo bueno, si espero a tener este bloque bien, no lo termino jamás.


Nico Paez expuso algunos conceptos acerca de testing que espero desarrolle en su blog[4]. Tuvimos una discusión acerca de si el análisis estático de código forma parte del testing y para él la linea divisoria está dada por "la ejecución del código".



Dada mi posición actual, para mi no hay distinción, ya que para mi son todas vulnerabililidades (errores de seguridad) y pueden surgir por:

• testeo funcional black box (ethical hacking)
• revisión white box de código de modo manual o automático (static code analysis)
• intuición white box (me parece que esta vulnerabilidad está presente)
• divulgación de vulnerabilidades comunes, que no son de desarrollo propio, por ejemplo un error en un servidor web que se corrige actualizando, reconfigurando o implementando algún parche externo.

A esto le sumaríamos los resultantes de probar que la aplicación cumpla con lo que se supone que tiene que hacer.

Lo que veo del análisis estático, es que son tests pero no están aplicados a un caso de uso, un flujo, una clase o método en particular, sino al texto del código, por ejemplo, es un error que:

• halla una clase con más de ... lineas
• halla un método con más de ... lineas
• hallan nombres de clases, métodos o variables demasiado largos o cortos
• halla un nivel de anidamiento mayor a ...
• una referencia a un objeto pueda llegar a ser usada siendo null
• un dato proveniente del exterior, source, pueda llegar a ser utilizado, sink, sin pasar por un sanitizer

Si mi build se rompe por que no paso jUnit y se rompe tambien por Fortify/FindBugs, para mi es lo mismo, no me importa si el código se ejecutó o no.



No es mi situación actual, pero para mi las vulnerabilidades deben estar junto a los otros bugs, aunque con un tratamiento especial: a menos que el bug tracker/project management tool tenga un soporte completo de roles y permisos a nivel de entrada, no se puede poner la descripción ni ningún detalle, pues se está mostrando como afectar al sistema.

Para destacar

Liliana la decana de la Universidad Atlántica Argentina reiteró su ofrecimiento a la comunidad local de usar las instalaciones para los encuentros periódicos necesarios para su funcionamiento.

Disparadores

Me parece que se sembró la semilla de Agiles Argentina 2015 @mdp, para que germine va a hacer falta el apoyo de todos.


No se si es tarde para AA2014 pero podría ser factible para AA2015, sea donde sea, el Agile Micro/Hotel, supongo que contratar un micro/hotel lleno puede resultar significativamente más barato que viajar/alojarse individualmente.


[1] http://www.ideasagiles.com/

[2] http://blog.codinghorror.com/working-with-the-chaos-monkey/
[3] http://groups.yahoo.com/group/foro-agiles/
[4] http://groups.yahoo.com/group/agiles-argentina/


[5] http://nicopaez.wordpress.com/

Propuesta de sesión Seguridad vs Agile en Agiles Argentina 2014

Por si no tenés sintonizado el canal Agile y no llegaste desde el listado de temas propuestos, voy a tener que contarte que el viernes 26 y sábado 27 haremos Agiles Argentina 2014, las primeras jornadas nacionales de metodologías ágiles, en el espacio gentilmente provisto por la Universidad de Belgrano.

Será puro Open Space, tan puro que hasta la comida será autoorganizada. No voy a repetir lo que ya dice en el sitio[1], sólo le voy a dar un poco de cuerpo a la propuesta de sesión[2] que quizás te trajo acá.

Mi idea es enunciar una lista de tensiones que noto tanto a nivel intuitivo como en la práctica misma a modo de punto de partida y que luego compartamos nuestras experiencias e intentemos arreglar el mundo.

Por supuesto, lo más seguro es que no bien termine de decir "en esta sesión veremos el conflicto existente entre seguridad y agile..." todos nos avalancemos sobre el tema como niños al volcar el camión de los helados, pero bueno, hay gente que necesita saber de antemano a donde piensa que va a ir.

• Tensión entre "need to know" y "collective ownership"
• Mínimo privilegio y mínimo conocimiento vs segregación de funciones.
• El típico waterfall de segurida vs "timely tests", roi temprano,
• Agile desde la gestión de riesgos a la luz de maturiy.

No faltés, es gratis, en horario de trabajo un día si y otro no. Si tu jefe te aprecia, que faltés te deprecia, mostráselo como inversión. Si tu familia te necesita, venir mejora tu futuro profesional. Si sos hombre, vas a tener que hacer tarea del hogar como deberías hacer de todos modos. Si sos mujer, no tendrías que justificar nada, velo como un bien merecido descanso.

Si no se entendió el párrafo anterior, pensalo bien antes de pegarme, repensalo y luego pegame.

[1] http://aa2014.agiles.org/
[2] http://agilesargentina.uservoice.com/forums/261590-%C3%81giles-argentina-2014-26-y-27-sept-en-buenos-aire/suggestions/6275665-agilidad-vs-seguridad

Agile Open Educación 2013 y los dos pies

Dejando de lado una leve desprolijidad con la comida, que los concurrentes no creo que hayan notado, todo salió de maravillas. Hubo un buen porcentaje de asistencia, hubieron muchas y variadas sesiones. Incluso yo, que soy bastante quejica, no me puedo quejar.

Design Thinking

Convocada por Ezequiel Kahan. trató de un método de análisis.
Me resultó interesante la etapa de ponerse en el lugar del otro, que es algo que siempre he considerado útil y beneficioso.

No regalamos caballos de Troya

Me quedó desligado la segunda del título "No regalamos caballos de Troya", en el sentido que según relaté, muchos han rechazado mis ofrecimientos de capacitación quizás por una cierta desconfianza, en el sentido de "y despues me vas a pedir que...", cosa que no había. El dato útil que me llevé es que los centro culturales suelen estar ávidos de actividades gratuitas y no son tan burocráticos como las escuelas.

Experiencias de enseñanza de seguridad

Me olvidé de mencionar que había llevado juegos, lo que quizás influyó en que no hubiera suficiente asistencia como para jugarlos. Para mi pesar, las personas asistentes no tenían experiencia, venían a ver.

En ambas sesiones quedé en una situación un tanto incómoda, pues aunque aclaré en ambos casos "compartir experiencias", como que quedé de expositor.

Enseñando a programar

Convocadas por Lucas Videla y Mariano Tugnarelli, fue lo que más me gustó del evento. Me llevo a Alice, que es como scratch pero mucho más divertido  y tambien el método de hacer los algoritmos a mano con cosas. Al escribir esto recuerdo que hace mucho tiempo intenté hacerlo en Algoritmos I, pero no le aposté lo suficiente, además en mi posición de colaborador ad honorem, no podía afectar el centro de gravedad de la cátedra.

Los dos pies

Incluso yo, que soy bastante quejica, no me puedo quejar. Aún así, me voy a sacar las ganas de quejarme.

En el Open Space hay un regla, la de "los dos pies", que se suele explicar como  "si no estás aprendiendo o contribuyendo en una sesión, se requiere que te levantes y que te dirijas hacia otra sesión en desarrollo, donde sientas que eres más útil y te sientas más inspirado"

A mi no me gusta esa definición, no es un mero derecho del asistente, pues no lo necesita, ni en un agile open ni en ninguna otra ocasión.

Para mi esta regla es más una protección para el convocante o expositor si lo hubiera y para el resto de los participantes de la sesión. Estamos acostumbrados a la idea de que si alguien se levanta y se vá es una agresión.

La reformularía así: "No te quedés por compromiso en un sesión en que no estás aportando ni recibiendo, tampoco pretendas que nadie lo haga. Intentá adaptar  la sesión y no te ofendas si alguien lo hace"


Lo que me molesta es que más que un derecho se ha convertido en una obligación moral, que no sólo está presente en un Open Space si no en muchas otras actividades. Si no te gusta, andate. Es la completa enajenación de tu actividad. Sos un recurso y como tal, no sos dueño de tu producto. Ahora bien, no te comportes como un recurso pues sos una persona, manifestalo ejerciendo tu derecho a irte. No transformes la realidad que no te gusta, cambiala por otra, en otro lado, sin indemnización, sin problemas, en el cielo.

Agiles 2011 dia 3

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.

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.

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.