jueves, 13 de octubre de 2011

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.

No hay comentarios:

Publicar un comentario