Cerrando el año - Lo bueno

Estamos terminando el año y si bien no me gustan los balances pero tengo el blog un poco descuidado, voy a compartir mis buenos y malos momentos resumidamente.
Primero las buenas:

• Como Padre este año siento que crecí muchísimo, ya Andrés comenzó a depender mucho más de mi y yo logre pasar muchos de los miedos de que la madre no esté. Ya dice que es hincha de All Boys (aloy), pide jugar el Futbol (ubol), juega a la play (apei), me llama a la noche cuando no se puede dormir (bue, eso no es tan bueno). Creo que lo que queda ahora en más va a ser genial, todavía tengo mucho por mejorar pero creo que estoy mucho mejor que antes.
  
• Tuve mi primera release como Arquitecto formalmente nombrado y se pudo cumplir con el objetivo de la versión que llevamos a producción. Realmente no fue nada fácil, mucha política, gente nueva, revisiones de arquitecturas, presentaciones a más de 50 personas de todo el mundo por teléfono, desarrolladores alrededor del mundo, etc, etc, etc a veces es muy dificil ser arquitecto y buscar el tiempo para bajar a tierra y escribirse un par de test cases, pero de vez en cuando me dí el lujo de hacerlo :)
• Ruby2Real, este año me pude dar el lujo de llevar a la realidad a Ruby, hicimos varias cosas en IBM y ya forma parte de la estrategia como para comenzar a vender servicios en dicha plataforma. Junto con Damian Garcia y Leandro Godon armamos planes de capacitación, capacitamos, creamos dos aplicaciones internas que todavía no se usan y un pequeño componente de autenticación interno que ya tiene varios downloads. La verdad que formar parte de un equipo de gente tan grosa como hay en IBM es genial.
  
• Uno de los aspectos que más me involucré este año fue con el aprendizaje, evangelización e implementación de las metodologías ágiles. Ya saben que hace años que vengo molestando con el tema. Ya el año pasado tuve algunas experiencias dando cursos y implementandolas en sistemas pequeños internos. Pero este año, en el proyecto que estoy como Arquitecto, pude ir un paso más in convencer al Cliente de utilizarlas, ahora estamos a puntos de darle un moñito y trabajando muy duro para tener todo listo, ya voy a postear sobre esto.
  
• Con respecto a las charlas que di/escuché que había propuesto a principio de año, en balance más del 70% se hicieron realidad, escuché charlas de rails, javascript, grails, etc Y tambien di charlas de continuations, ruby, rails, tdd, arquitectura, etc. Obviamente faltaron temas como earlang, SOA que ya me viene irritando un poco, pero bue.
• Creo que APIT está impecable, se mejoró mucho en varios aspectos de la materia, los últimos aportes fueron de lo mejor, Esteban Lorenzano y Santiago Blanco, creo que si seguimos reclutando los cereblos de los alumnos van a explotar. Creo que en cuanto a transmitir los conceptos de Arquitectura yo tambien he mejorado, este año también di un curso de tres días muy importante de la carrera de Arquitectos en IBM y obviamente me sirve mucho para hacer sinergia con lo que damos en la UTN.
• Comencé a tratar de stress!!! Creo que eso me permitió llegar vivo a fin de año :) Igualmente no estoy del todo bien, sigo el tratamiento que por sierto todavía tengo que llamar al doctor para coordinar la proxima sesión del MDS. Pero en conclusión pude seguir conociéndo, entender como funciona el stress (y muchas veces afectando mi salud) y pude tomar acción para evitar la parte negativa de este, haciendo deporte, saliendo más con mecha, etc, etc.
  

Creo que esto es todo por ahora, en breve se viene el post de lo malo :P

Otro cuatrimestre, otro parcial

Como todos los cuatrimestres, aca está el parcial que tomamos en APIT, fue algo parecido al parcial del cuatrimestre pasado pero esta vez, utilizamos un BPM (simplificado) como base para tomar las decisiones arquitectónicas.

Obviamente el objetivo de este parcial es poder hacer pensar a los estudiantes como un arquitecto sin tener que estudiar de memoria, cosa que detesto. Está claro que fue complicado ya que con una sola clase de SOA e Integración, el BPM es uno de los conceptos más complicados.
Como pueden ver pudimos lograr unificar todos las unidades de la materia, el único tema que quedó afuera fueron las metodolgías que realmente son un punto fundamental en la materia.
Asi que comentearios, sugerencias?

TDD desde una perspectiva arquitectural

La semana pasada di una conferencia por teléfono para todos los arquitectos que trabajan para proyectos internos de IBM y que con planes de utilizar metodologías ágile y/o ya están utilizando. Fue una linda y desafiante experiencia debido a que había gente de muchas partes del mundo (USA, Francia, India, Sudamerica, etc), nunca había dado una charla técnica en inglés (sacando las presentaciones de arquitectura de la aplicación) y yo pongo un 4, creo que aprobé, pero tengo mucho que mejorar. Independientemente de esto, creo que lo más interesante que quiero comentar en el post es sobre las influencias que tiene TDD en lo arquitectural, esto es el resultado a una pequeña investigación que vengo haciendo para APIT sobre Arquitecturas y Metodologías Agiles. El contenido básicamente fue el siguiente.

Facts acerca de TDD

• TDD se compone de, Unit Test, Test Automation, Test First y Enfoque iterativo con refactoring
• TDD es una técnica de diseño y es utilizada por Desarrolladores (Código).
• TDD incrementa la calidad en el código facilitando el cambio en el software
• TDD reduce defectos y permite tener un testeo de regresion constante
• El manejo de dependencias es la parte más dificil de TDD

Requerimientos no funcionales impactados por TDD
Como siempre digo, las decisiones arquitecturales habilitan los atributos de calidad, pero obviamente no siempre los garantizan, hay otros aspectos y decisiones que entran en juego y el arquitecto no siempre puede manejar. Pero inevitablemente, la Arquitectura es la principal responsable de garantizarlos, y como arquitectos debemos buscar las formas, y TDD es una de ellas, con lo cual considero que TDD permite lograr los siguientes atributos de calidad:
Maintainability: Siguiendo las guías de Feathers, primero haciendo fallar el test case y luego corregirlo, la mantenibilidad se vuelve un detalle, lo mismo pasa con lo simple que queda el código y con la no necesidad de perder tiempo en un debugger. No nos olvidemos del regression test aca.
Extensibility / Modifiability: Esto es básico, como excelente técnica de diseño, al tiempo de aplicarla la productividad aumenta y el código queda mucho mas simple.
Reliability: Tiene que ver con la robustez en lo que respecta a las reestructuraciones o cambios en la arquitectura, un codigo que se construyo utilizando TDD, difícilmente sea complicado de modificar a cambios inesperados
Geographic (including Localization): TDD es una excelente técnica de comunicación, para equipos distribuidos es fundamental, tener bien claro y definido cual es el comportamiento esperado, no se paga con mastercard
Time: Ya hablé de la Productividad que trae aparejada el Test First, aca hay un paper que habla de los estudios que aumenta la productividad, hasta que lo leí fue solo un feeling mio y personal, ahora se ve que está probado.

Decisiones Arquitectónicas para Soportar TDD
Ahora, como (re) diseñamos nuestra arquitectura para soportar el uso de TDD, bueno, lo encaré desde el punto de vista de "Tácticas y Principios de Diseño" y "Estilos Arquitectónicos y Diseño Estratégico":
Tácticas y Principios de Diseño

• Separation of Concerns.
  Una correcta separación de módulos, permite un mejor manejo de la complejidad y también permite el reuso del lado de los Test Cases (que no es poco)
  
• Separación de la interface de la implementación.
  Hace falta explicar esto? Bueno, principalmente es para el manejo de dependencias y el trabajo en paralelo
  
• Design by Contract
  Dos técnicas complementarias en el bajo nivel, desde un punto de vista arquitectural, definir los pre/post conditions entre módulos es básico
  
• Informacion hiding
  Previene cambios no deseados
  
• Prevent Ripple Effects
  Con 8 tipos de dependencias entre módulos, nos ayuda a no tener dependencias ocultas entre módulos, esto es muy importante, muchas veces hay modulos que dependen en variables de contexto y está oculta, TDD ayuda a evitarlo.
  

Estilos Arquitectónicos y Diseño Estratégico
Mas allá de cosas específicas, hay estilos arquitectónicos que ayudan muchísimo al uso de TDD en aplicaciones empresariales, estos son algunos:

• Inversion of Control/Dependency Injection
  Aca no hay nada que discutir, por excelencia permite permite el uso de TDD, sumado a esto la separación de interface de la implementación.
• Hierarchical Layers
  Estilo super conocido, con un modelo sencillo de dependencias, permite el coverage de una layer solo mockeando una layer inferior. Obviamente este patrón tiene cosas malas aparejadas, como la dificultad por encontrar las abstracciones y la modificabilidad.
• Domain Driven Design
  Un estilo muy interesante para dominios complejos, se lleva muy bien con el Dependency Injections y la Iteratividad.
  
• Transaction Scripts
  Modelo sencillo, en donde se puede lograr una completa de cada servicios a testear.

Acá estuve hablando como 30 minutos, es un poco difícil plasmarlo en un post, pero obviamente es la parte más interesante de la charla (al menos para mi)

Quejas de otros profesionales para implementar TDD y como solucionarla
No siempre es fácil convencer el uso del TDD, hay muchas quejas que hay que afrontar, aca puse las que fui recolectando, en algún otro post voy a poner lo que dije verbalmente, así que por ahora se lo dejo a uds para que piensen :)
Project Managers

• Toma mucho tiempo para escribir test y termina impactando en la productividad.
• Me siento mal por dejar afuera del proyecto a Testers y gente de QA
  

Architects

• No me importa TDD, es una técnica de bajo nivel para programadores
  
• No es necesario to test drive el código, la arquitectura cubre todas las posibilidades

Application Developers

• Toma mucho tiempo en correr los test cases
  
• No es mi trabajo testear mi código
  
• Pero compila!
  
• A mi me pagan por escribir código, no para escribir tests
  
• Las dependencias son difíciles de manejar y toman mucho tiempo
  

Esto es todo, espero que les guste y espero feedback! realmente quiero escribir un paper con esto

Visión Visión Visión

Y si, según mechi cada 3 palabras que digo, menciono la palabra "visión"4 veces, al igual que "abstracción" o sus derivadas. En fin, son dos palabras que me sientan muy bien y creo que son básicas en los dos laburos que más me gusta hacer, "Liderar" y "Arquitecturar".
Hace un tiempo en IBM, vengo cumpliendo un nuevo rol de liderazgo desde un aspecto técnico como líder de la práctica Web (Java, .NET, Notes, etc) con implicancias en todos los proyectos que usen dichas tecnologías, y esta semana estoy teniendo una serie de reuniones con todos los profesionales, son como 80. Lo que quiero compartir en este Blog es la visión que tengo sobre la organización que quiero armar. Está claro que se aceptan críticas, insultos, etc...

• Quiero convertir a Argentina en un Centro de Excelencia para IBM de todo el mundo en lo que el desarrollo Web respecta. Le explico el contexto, IBM tiene 8 centros de desarrollo globales, uno de ellos es Argentina, y un poco la idea es de que cada uno se especialice en una o más plataformas como para que cualquier IBM mundial (USA, España, Francia, etc) pueda requerir servicios de desarrollo de software y poder particionar de acuerdo a la especialidad. Con lo cual si Argentina se especializa en Web, cualquier proyecto que IBM (en todo el mundo) venda a sus clientes, Argentina sería el principal referente, esto posibilidad tener una estructura paralela de investigación, innovación y generación de conocimientos financiada por IBM Mundial que podría ser más que interesaante. Osea un area de investigación para la generación de metodologías, frameworks, componentes, buenas prácticas, etc que permitirían diferenciarse en calidad y en productividad. Está claro que Argentina está muy bien parado en cuando a skills en RIA (JS/AJAX o FLEX) creo que por ahi debería venir la mano.
• Quiero formar una "Organización que Aprende", obviamente focalizándome en los profesionales que la componen. No quiero hacer un post sobre esto, pero realmente estoy muy alineado con la idea de Peter Sengue, y sus 5 disciplinas. Sobre todo en el desarrollo de software que es una actividad que depende 80&% en la gente y 20 en vaya a saber quien. No concibo pensar en una organización con gente que realice tareas automáticas, prefiero tener menos personas y más programas. La capacidad y los procesos de selección de personal son claves, y realmente no importa el volumen sino la calidad de los profesionales.
• Quiero fomentar el Ease @ Work. La idea es buscar un ambiente confortable de trabajo para generar los resultados deseados. No quiero perjuicios, quiero que los profesionales se sientan libres de hablar, sin perjuicios, sin pensar en el "que diran" cuando expresamos nuestras ideas. Es fundamental intentar concebir un ambiente de trabajo que fomente la creatividad, soy un apasionado de eso, cuando uno se siente confortable, sabiendo que solo se tiene que preocupar de su trabajo y los objetivos del equipo las posibilidades de fracasos son mínimas, como así tambien la capacidad de innovar es infita. Este es un concepto que vengo ideando y fue llevado a la practiva por Kent Beck, please google it.
• Sigo insistiendo, el diferenciador de Argentina es la Calidad, y no el Costo. No podemos depender en la economía con picos tan bajos cada 10 años. Lamentablemente es asi, el costo es una variable ajena al software y la tenemos que dejar fluctuar, nunca depender del costo. Tenemos que focalizarnos en vender soluciones/servicios que dependan totalmente en la calidad, y que generen un valor agregado al negocio. Si logramos brindar servicios con calidad, vamos a ser siempre una potencia en el desarrollo de software, pero si solo pensamos en la paridad cambiaria, es muy "cortoplacista", hay que entender que por más que pensemos en el cambio, la inflación termina impactando tambien.
• Y por último, el 5to item de visión que tengo para mi organización es en la innovación constante. La innovación a esta altura no se discute, obviamente esto es un cambio de mentalidad y dejar de pensar un poco en el corto plazo, pero esta claro que los proyectos son finitos y siempre se piensa a corto plazo, y es por eso que quiero pensar en formas de fomentar la innovación y que eso sirva como retroalimentación a los proyectos.

En fin, esa es la visión que quiero para la organización que estoy liderando... todavía estoy en proceso de comunicación y delineamiento de como llegar a cumplirla, pero estoy seguro que voy a ser muy feliz cuando lo haga y muchas personas van a verse beneficiadas.

Empezando mal...

Me parece que tengo que tomarme unas vacaciones, relato los hechos...
1) Salgo de casa 7:45 rumbo al garaje, obvio que me mojo.... y me doy cuenta que me faltaron los papeles del auto, vuelvo, los agarro... tipo precavido (y mojado) tomo un paraguas que no tenía.
2) Salgo, no llueve más.... me subo al auto, y escucho quejas José (del estacionamiento) que la lluvia es todo culpa mía, que como lavo el auto cada tres meses siempre llueve, y si... lo lavé el sábado y era lógico que llueva, yo me lo busqué.
3) El tema es que salgo, en plaza serrano escucho un ruido feo así que vuelvo (exactamente di una vuelta manzana) y me voy al mecánico a 4 cuadras de casa, uno nuevo recomendado por el mismo José que se me quejó minutos atrás, y lo dejo ahí, no hay peor sensación que la que te deja un nuevo mecánico, por lo menos esta vez viene recomendado
4) Vuelvo cabizbajo para casa, mitad del camino y se vuelve a largar a llover (esta vez mal) y obvio el paraguas había quedado en el auto.

En fin, para que me levanté!!!! espero que la semana cambie, quien lea este post le pido por favor que me trate bien.

Salimos el Jueves ? - PAMPA YAKUZA

El jueves pasado finalmente pude ir al último recital del ciclo, "Salimos el Jueves?" de la gran banda Pampa Yakuza. Realmente no puedo explicar las sensaciones que tuve en este recital 1 hora y media, fue realmente increible, si bien no puedo tener una opinión objetiva desde el punto de vista "musical" aunque podría decir que cada nota, de cada instrumento que salió desde el escenario lo pude sentir, como toda la gente (bastante) que estaba ahí.
Si tendría que decir cuales fueron los mejores mis mejores 5 recitales de mi vida, indiscutidamente los dos recitales de pampa están ahí, no hay discusión... los que faltan creo que sería uno de Los Fabulosos y Los Cafres gratuito que fue en Pampa y Figueroa Alcorta, en los Bs As Vivo que hacía chupete un par de años atrás o cuando Bersuit hizo su presentación de Libertinaje en mi querido club de Floresta (recuerdo atener la barra del recital con 17 años...) y uno de los piojos en el Pepsi del 06' creo.
Si realmente tienen ganas de escuchar una banda nueva, yo se las recomiendo... desde mi punto de vista tiene una onda may parecida a Bersuit, sumandole Reggae y bastante percusión es una banda puramente Argentina 100 x 100, se los aseguro no los va a desfraudar. El disco Orillas es el que más me gusta y el tema "Contra las cuerdas", con el que abrieron el jueves la rompe y podría decir que es el que más me gusta.
Aca les dejo un par de links para que escuchen temas, fotos, etc:
http://www.purevolume.com/pampayakuza
http://www.myspace.com/pampayakuza
http://www.fotolog.com/pampayakuza
http://es.youtube.com/pampayakuzavideos

Esto es poesia - FEST Fluent Assertions Module

Si bien, cada día que me voy acercando a Ruby, Java me da más bronca, todavía creo mantener cierta objetividad como para ver cosas copadas que se van logrando en Java, y este es el caso de FEST Fluent Assertions Module, si bien no le llega ni a los talones a BDD, creo que se merecen un aplauso:

Ya lo había visto hace unos años, gracias a Java Lobby y me gustó bastante. Ahora en ASIT ya hace unos meses Gaby Benmergui, uno de mis nerds preferidos de IBM lo está utilizándolo con TestNG, espero ver sus frutos.

Me casé con una nerd - Segunda Entrega

Si bien tengo muchos hechos que lo demuestran, voy entregando de a poco....
Este es un chat que tenía por el Sametime con Mecha, obviamente junto con otros 20 y una call de por medio, aca se la ve enojada por que no le contesto o no la endiendo (vaya a saber que).

Eso si, se nota que está estudiando para Sistemas Operativos :)

Estimaciones de Software, algunos pensamientos

Ahora que se me rompió la laptop de IBM, tengo un tiempito libre setupeando mi laptop personal (una Dell Latitud D610, viejita pero se la banca) hasta que el soporte técnico se digne a arreglarla. Quería de hablar de un tema bastante heavy del software y siempre trae lindas discusiones en la materia.
El Viernes, con Esteban Lorenzano, antes de dar la charla en Cafelug, nos colgamos hablando del tema y vimos que hay dos cosas totalmente equivocadas o mitos sobre las estimaciones que no estamos de acuerdo para nada, y son:

1. Querer establecer un modelo matemático para poder justificar un metodo de estimación. Si bien sería algo ideal, es algo imposible (desde nuestro punto de vista) y principalmente por que la unidad de trabajo (ya sea, LoC, UCP, FP, CocomoFuckingFactors) es inmedible, recuerden que la construcción de software es un proceso creativo y no repetible!!! y no solo eso las personas importan y no hay proceso que pueda hacer repetible ninguna tarea de construcción de software.
2. Los profesionales del software no entienden que quiere decir una Estimación. No quieren entender que es un Pronóstico, una simple (o compleja, de acuerdo a que método uses) predicción del esfuerzo (tiempo, costo y scope) que puede tomar la construcción. Nunca debe tomarse como un hecho, ni tampoco se puede planificar detalladamente y menos que menos controlar en base a una planificación errónea asumiendo estimación... o sea, todo mal. Con lo cual, tomemos el resultado de una estimación como debe ser, algo que nos permita tener una idea y tengamos en cuenta que es errónea desde un principio.

Luego de haber leído un libro muy interesante, les dejo una serie de tips que me gustaron:

• Separar lo que es un restricción del negocio (para cuando se quiere el software) de una estimación de esfuerzos, son cosas diferentes... no hay que confundirlas.
• Muchas veces, la estimación es un problema de ineptitud del Equipo que la ejecuta el proyecto. Esto puede ser por falta de comunicación de la estimación y los fundamentos de esa estimación, falta de recursos en tiempo, mal manejo de requerimientos, etc, etc.
• Hay que tener muy en cuenta el nivel de in/certidumbre por falta de información u otros temas, y eso no solo se mitiga agregando más tiempo a la estimación, sino poniendo el % de desvío correspondiente.
• Tener en cuenta que el software es algo creativo y depende muuuuuuucho de las personas, y aca se te va la estimación a la mierda, aca es donde hay que estimar "constantemente" por cada iteración para generar un compromiso del team para lograr algo, y eso va ajustando el estimación original que nunca es precisa.
• Segun McConnel, (opino lo mismo) siempre está mejor sobre estimar que estimar menos de lo que es, ya que estar siempre atras de lo que se estimó genera más ruido, más comunicación, mas reuniones de tracking, mal ambiente que sigue atrasando el proyecto... pero obviamente hay que tener cuidado con la ley de parkinson.
• No solo se estima tiempo, sino que se estima esfuerzo y costo, ojo aca
• Las factores son un excelente medio de ir perfeccionando una estimación, pero cuidado con los pesos que se le ponen a dichos factores por que pueden ser comienzo del problema, creo que definir una serie de factores que ajusten la estimación es correcto (no más de 10/15) ya después entra la subjetividad.
• Está claro que Wideband Delphi es el método que puede tener mejores resultados, pero es muy costoso hacerlo. Y lo que te queda es irte a las estadísticas de la organización para buscar proyectos similares, con tecnologías iguales y dominios similares.

Que lindo sería una materia de esto, no? Aunque prefiero antes que la gente aprenda a construir software como la gente, luego aprender a estimar, asi que todavía tenemos un largo camino que transitar.

Que cosas no ayudan al TDD - Revisited

La semana pasada encontré una herramienta muy interesante que mide la testeabilidad de un programa Java y me pareció muy interesante desde el punto de vista arquitectural y seguramente fue esta la que me hizo pensar que evitar a la hora del TDD que dió origen al post anterior. Todavía no la probé, pero en breve seguramente la incluya a mi lista de herramientas que ayudan a sacar métricas interesantes para un arquitectos sobre el código (buen título para un post).

Bueno, la idea de este post era la de contar que el autor (Miško Hevery) de la herramienta tiene un blog super interesante y ya hizo el post un poco más completo que el mio y lo que agregó Pablo (BTW Gracias!).

Me cayó muy bien el tipo de posts, evidentemente odia más el Singleton que yo :)
Bueno era eso, el post van a encontrar otras cosas que no ayudan.

Que cosas no ayudan al TDD

Hoy tuve un viaje bastante pesadito de MDQ a BA, 8 horitas, se rompió el auto, llegamos BA a las 19 (o sea todos volviendo del trabajo) y que se yo... en fin estuve pensando en que cosas molestan y mucho al la hora hacer TDD, obviamente tienen más que ver con el el buen diseño y la programación también, estas fueron mis ideas:
Métodos Estáticos
Esta es una de las cosas que más me molesta y sobre todo se vuelve un problema cuando los desarrolladores no utilizan los conceptos de OO y siguen trabajando o pensando en Estructurado. Los métodos estáticos son una mala práctica, realmente no justifico su utilización. Para los que no los notaron, los métodos estáticos son un problema a la hora de querer modificar su comportamiento para poder ejecutar cierto escenario del comportamiento unitesteado, existe varias técnicas para poder evitarlos.
Singletons.
Hay algo para decir aca? Realmente yo a los Singleton los veo como un Anti Pattern, raramente justifico el uso. No solo son dificiles de mokear sino que tambien son muy complicados para unitestear, siempre tenes que caer en agregar un método solo para la hora del testeo.
Service Locators
Piensen lo siguiente, como se implementa un Service Locator, Singleton + Métodos Estáticos, o sea que más puedo decir :) y si, algo más tengo para decir, si bien está claro que IoC es muy superior en terminos de manejo de dependencia y el 60% de los problemas del TDD tienen que ver con el manejo de dependencias, la implementación incorrecta de un Service Locator puede obligarte a no testear absolutamente nada de tu código. Está claro que si se implementa correctamente (no métodos estaticos y no singleton) puede no ser tan malo en terminos de TDD, igualmente dudo que decida utilizar TDD utilice un Service Locator en vez de IoC y DI.

Hasta aquí son las tres cosas que más podrían molestar o en algunos casos fracasar el uso de TDD, y ahora que estoy terminando el post veo que todos tienen que ver con el manejo de la dependencia de objetos... en conclusión, si queres usar TDD y tenes posibilidades de tomar decisiones sobre como se está construyendo un sistema, sinceramente te recomiendo que evites estas tres cosas y trates de focalizarte en como vas a hacer el manejo de dependencias, no estoy diciendo que tengas que usar si o si un IoC framework (cosa que tiene mucha onda en muchos casos) pero si que lo tengas muy en cuenta.

Está claro que lo que acabo de decir puedo asegurar que aplica principalmente con java, todavía quiero ver que pasa con lenguajes dinámicos como Ruby o Smalltalk, creo que no debería cambiar mucho, pero por algo DI no es algo que se usa en Smalltalk, quizá sea o por que son cerrados o realmente no lo necesitan por las características del lenguaje. Es una charla que me debo con Esteban Lorenzano, siempre que intenté tenerla nos fuimos por la tangente. En el caso de Ruby, lo poco que hice la injección de dependencia fue bastante sucia redefiniendo en runtime el comportamiento de las clases, cosa que no está del todo mal, pero prefiero el DI.

Cruzando Fronteras - Jornadas Regionales del CafeLug

Este viernes, con Esteban Lorenzano, vamos a dar nuevamente la charla "Cruzando Fronteras", si, la misma que dimos en el Snoop Update 08' y que? :) Pero esta vez con los amigos del Cafelug en el contexto de las Jornadas Regionales 2008.
Esta es la descripción de la charla para los que nos quieran venir a pelear, insultar, hablar bien de Java o SOA, estamos dispuestos a dar combate.

Título: Cruzando Fronteras - Respuestas revolucionarias a la crisis de las web-applications (Rails y Seaside)
Tiempo estimado de duración: 1 hora
Día, Hora y Lugar: 22 de Agosto, a las 16hs. Universidad de Belgrano, Zabala 1837, Capital Federal
Inscripción: El evento es gratuito pero Inscripción Obligatoria.
Breve descripción de la charla: Cruzando Fronteras, es el resultado de una investigación que intenta analizar el estado actual del arte, en lo que al desarrollo de aplicaciones webdentro de las organizaciones respecta, principalmente en plataformas como Java y .NET, y enfatizar en la crisis que se está viviendo y como respuestas revolucionares en otras plataformas como Ruby y Seaside están ayudando a cambiar y mejorar las arquitecturas actuales de las Aplicaciones Web
Presentación: http://www.slideshare.net/EstebanLM/cruzando-fronteras-respuestas-revolucionarias-a-la-crisis-de-las-webapplications-rails-y-seaside-359454?src=embed

Los espero, creo que esta vez es la última reutilización de la muy interesante investigación que hicimos, no intenta enseñar nada de RoR (que hace mucho que no codeo nada) ni de Seaside, solo compartir unas conclusiones de como creemos que puede venir la mano respecto al desarrollo de aplicaciones web.

All Boys Campeon!!!! Esta vez me toco festejar desde EEUU

Este es un post un poco tarde, pero no quería dejar de publicarlo ya que muchos de uds saben que sos hincha del Club Atlético All Boys, Floresta, Argentina... y durante mi estadía en EEUU salió campeón de la Primera B frente a los amargos de Atlanta y en su cancha con un par de fechas adelantadas, en fin, algo parecido a lo que pasó en 1993 cuando le ganamos a Defensores de Belgrano en la cancha de Ferro, aquella vez salimos campeones en la última fecha del torneo. Recordando aquella vez se me pone la piel de gallina, ver lagrimear a mi viejo (cosa que nunca en mi vida vi), volver caminando desde Caballito hasta Floresta para dar la vuelta olímpica con mi viejo y mi mejor amigo de aquel entonces (el tanito). En fin, esta vez no lo pude hacer, pero estuvo mi hermana Bárbara con mi viejo en mi representación :=)
Aca les dejo unas fotos en USA festejando a mi manera...

Parcial de Arquitectura (APIT) esta vez le tocó al Broker

El martes pasado tomamos el parcial de la materia. A diferencias de casi todas las materias de la UTN, nuestro parcial apunta a que los alumnos piensen como Arquitectos dada ciertas restricciones y puedan tomar las decisiones justificando correctamente, realmente cada una de las pregunta tiene infinitas respuestas como así también sus justificaciones. Estamos muy conformes (al igual que los alumnos de años anteriores) con esta metodología, ya que estudies lo que estudies, si no conceptualizaron los elementos de la Arquitectura de Software que enseñamos en la materia, es dificil que aprueben, es más permitimos apuntes, presentas... o sea carpeta abierta que realmente no sirve para mucho si no estás dispuesto a pensar.
Aca les dejo una copia y ojala yo hubiese tenido más parciales de estos en aquellos años felices como estudiante :)

Voy a ver si a lo largo del finde escribo algunas respuestas que podrían haber sido correctas :) todavía estoy corrigiendo los parciales.

Dave Matthews Band en Argentina?

Todavía no puedo creer lo que estoy escribiendo, pero hace tres semanas que lo vengo escuchando de parte de mi mejor amigo (Fede), un par de veces en la R&P, un par de foros y en dbmla.com... todavía no quiero ilusionarme, pero parece bastante real, asi que tenemos que ir preparándonos, estoy seguro que no soy el único fana, pero si hay otro que lea este blog tan poco actualizado, cual son tus canciones favoritas? las mías serían (de dificil y rápida elección) son:

• Crush
• Grace is Gone
• Say Goodbay
• So Right
• The best of what's around

Aca les dejo otras referencias:
http://www.dmbla.com/
http://www.dmbfans.com.ar/forum/viewtopic.php?f=3&t=3&st=0&sk=t&sd=a

Assus EEE PC 4G

Luego de una recomendacion de Damian Garcia, le compre a mi mama la TripeE en NY, USA. La verdad que para lo que da la maquina tiene un precio espectacular que van de 299 a 399.
La que compré fue la 4G Surf, o sea, 4 GB, 512 de RAM, WinXP y WebCAM.
Por el momento puedo decir que esta espectcular, llevo poco tiempo usando y ya se la tengo que dar a mi vieja.

Las cosas que me encantaron fueron

• Bootea en no mas de 25 segundos


• Extremadamente compacta y liviana, me encantaria tenerla como para llevarla a lugares y no estar incomodo.


• Le Web CAM tiene una muy buena resolucion.


• Provee salida SVGA, 3 USBs y posibilidad de meterle sticks de memoria SD y MMC (esto la rompe)


• El LCD es bastante bueno

Comida Internacional

Un de las cosas que tengo que destacar de este viaje, fue que estuve bastante abierto a probar nuevas comidas y platos, como que a mi me cuesta mucho... pero la verdad que no podía comer todos los días Hamburguesas con Panceta y Queso :)
Antes de este viaje pensaba que aca solo que comía eso, solo fafud (fastfood) pero no, realmente estoy sorprendido como las diferentes culturas fueron ganando terreno en el ambito de la gastronomía, aca voy a describir algunas comidas que recuerdo y su origen...

• Comida China Americanizada en P.F. Chang's Bistro, fue la primer noche que salimos con los compañeros del team y nos llevaron a este lugar. La verdad que la atención fue excelente y la comida bastante buena, comí unos pedacitos de carne bien cocida y super picante con con arroz que me gustó, punto. El puntaje que le voy a dar van a ser 7 Breys.

• Comida Italiana en Magiano's, aca fue una invitación de IBM, fuimos como 25, aca la verdad que la comida fue buena. He comida mejores lasañas, milanesas de mozzarella y ravioles. Lo bueno fue que conocimos más al team de USA. Le doy 4 Breys. En Argentina tenemos muuuuuucho mejor comida italiana (por que será? ajjaj).
  
• Otro día nos fuimos con Anand (que es de India y vive hace 20 años en USA) y Ronni (es de Indonesia y vive en Singapore) a un restoran Indio de comida del Norte de India. La verdad que quedé alusinado, nunca comí tan bien, una entrada más que interesante y luego unos platos para compartir de Camaorones, Cordero y otro de Pollo, los tres con diferentes salsas muy picantes, como los comías con Pan, el picante no te mataba. La gente de india tiene como tradición, solo comer con una mano, sin cubiertos, con lo cual todo lo levantabas con el pan en tu plato. Tambien se acompañaba con arroz blanco. Aca está la descripción de lo que comimos, me la pasó Anand por chat en ingles. "chicken tikka masala (chicken in spiced tomato sauce), lamb vindaloo (lamb curry in spiced sauce with potatoes) and crab masala (crab meat in spiced creamy sauce); Dessert platter had: gulab jamun (deep fried balls of dough soaked in sugar syrup) and kheer (rice pudding with cardamom flavoring plus cashews/raisins in it)". Le voy a dar 10 Breys.
• Los Viernes, la gente de IBM, suele ir a un lugar tipo "Buffet" o tenedor libre en criollo, llamado Con-Fusion. Básicamente es comida de Japon, Korea y China. A mi me gustó, comí diferentes tipos de pollo y nuddles. Le doy 6 Breys.
• Lo que tambien nos cansamos fue de comer Burritos y Tacos, comida mexicana por todos lados y la verdad que muy rica. Creo que la que más me gustó fue la de la cafetería de IBM. Le doy 8 Breys.
• Ayer fuimos despues de hacer unas compras, terminamos comiendo en un lugar de comida armenia. 6 Breys.
• Y hoy, la gente de IBM Raleigh, nos invitaron a comer comida Griega a ,comí unos Kabos con unas ensaladas, una de ellas muy fuertes que ni la pude poner cerca de mi boca, la otra era arroz con porotos y cebolla salteada, un manjar. Le vamos a dar tambien 7 Breys
  

En fin, creo que eso fue todo, obviamente tambien comimos en los conocidos fafud, pero realmente no vale la pena, USA está plagada de muchas culturas y hay varias opciones que hay que probar, y creo que lo aproveche, y igual nunca me voy a olvidar de la mejor Haburguesa con Queso y Bacon que comí en mi vida.... te quiero CHAMPS, un bar con miles de LCDs y comida Norteamericana excelente.

Que lindo que te extraño...

... por que se que te amo como nunca, y eso es lo lindo del amor, poder llorar y reír al mismo tiempo escribiendo un post en el blog :)
En estas pocas palabras te quiero dedicar este tema....

To see you when I wake up
Is a gift I didn't think could be real.
To know that you feel the same as I do
Is a three-fold, Utopian dream.

You do something to me that I can't explain.
So would I be out of line if I said "I miss you"?

I see your picture.
I smell your skin on
The empty pillow next to mine.
You have only been gone ten days,
But already I'm wasting away.
I know I'll see you again
Whether far or soon.
But I need you to know that I care,
And I miss you.

Fin de semana de descanso

Bueno, llegó el segundo fin de semana y me llegó el cansancio todo de una. Una semana bastante agitada pero con muy buenos resultados.
Por un lado estamos tratando de entender funcionalmente que es lo que hace la aplicación, y se me ocurrió la idea de ir definiendo los casos de uso y que el Arquitecto que creó la aplicación nos explique que es lo que la aplicación hace, obviamente esto no solo va a dejar la aplicación documentada desde el punto de vista funcional, sino que también me va a servir a mi para poder evaluar los futuros cambios, tanto para corrección como para mejoras, también va a servir a los desarrolladores para entender como lo funcional termina impactando el estado de la aplicación por cada interacción con el usuario.
Creo que haber tomado esa decisión fue muy acertada y bien recibida, ya que la gente que nos tiene que contar la aplicación no tiene mucho tiempo para dedicarnos ni tampoco algo documentado, entonces este tipo de especificación sirve muchísimo para organizar las ideas. Antes de que alguno me diga "pero si tenes el código, por que no mirás ahi que es la mejor documentación de lo que hace la aplicación", bueno, si... comparto, tengo el código que veo como la aplicación resolvió un problema, pero no tengo que es lo que la aplicación tiene que hacer, o sea el "que". Aparte de que el código, lamentablemente, no está muy programmer-friendly, hay mucho codigo de presentación y negocio muy pegoteado y sin mucha reutilización y uso extremo de ifs.
Por otro lado, como la aplicación requiere nuevas versiones cada mes y en producción, con eso me bastó como para proponer el uso de alguna metodología ágil y como en IBM USA, por fin, le están dando algo de bola, picaron... por suerte tengo al Chief Architect (un arquitecto bastante cross) y al Arquitecto de Build bastante al tanto del tema, podría decir que en breve finalmente voy a poder poner en practica todo lo que vengo investigando (desde el 2004), implementando pequeños approachs y enseñando... todo en práctica, con lo cual de aca a Julio, voy a estar, junto con la Project Manager (que es una grande y muy abierta) y otros roles del proyectos tratando de adaptar alguna de las metodologías ágiles disponibles.
En fin, profesionalmente creo que nos está yendo bastante bien, aunque calculo que los resultados se verán en un tiempo. Lo lindo de este viaje, es que conocí gente muy copada de India, USA, Singapore y se pudo trabajar muy muy bien.

Les dije que había gente copada aca?

Este mail lo recibí el Viernes a las 16:00... un grande Randy!

Gustavo-

I am busy this weekend ( wasnt last weekend )........but at my desk I left a magazine called "Whats Up" that lists what is going on in the area.

THe Winery is called "Chatham Hill" and it is in Morrisville. It is off 40 East - a sign with a bunch of grapes marks the exit.
Tastings are Fri nites until 6 and Sat from 11-4 I think.

If you get arrested partying in the US - here is my number - 919-622-XXXX - I will come and bail you out!

Regards,
Randall C Hxxxx (por si las moscas)

Recien llegados del DC

Estuvimos todo el finde en Washington, la verdad que la pasamos muy bien, caminamos bastante y conocimos varios monumentos y museos, como así también la casa blanca que me desilusionó un poco, bastante chica, me la hacía mucho más grande. La verdad que para manejar 5 horas y poder conocer la capital valió totalmente la pena. Un dato interesante es que en el DC viven alrededor de 750 mil personas y la 2/3 parte trabaja para el gobierno. La ciudad es muy muy limpia y perfectamente diseñada, no es nada increible pero la conjunción de Monumentos, Edificios, Calles grandes y poco pobladas con zonas residenciales muy a lo "Ingles" me resultaron bastante interesantes.
Tambien estuvimos en Georgetown, entiendo que es parte del DC, y tiene una Universidad muy linda y una catedral muy linda y nueva.

La verdad que con Gabriel y Rubén nos divertimos mucho, quedaron muchas historias que voy a ir contando cuando esté un poco menos cansado... ahora estoy aca tratando de cerrar unas presentaciones que tengo de la Arquitectura y tengo que presentar mañana, calculo que me acostaré a las 2 AM, con suerte, pero calavera no chilla :)

Lost, que enfermedad...

Como bien lo dijo Damian en un comentario de mi ultimo post, si, acabo de terminar de ver el capitulo 10 de la 4ta temporada de LOST. No voy a comentar mucho por respeto a todo el clan de LOST de Argentina que todavía le faltan un par de horas para poder bajarlo y verlo, pero lo único que voy a decir es que le doy un puntaje de 6 al capítulo.
Lo más interesante de todo esto es que hoy planificamos todo el día como para poder estar a las 10 de la noche, trabquilos y en el hotel para disfrutar del capítulo, fue la unica vez que comimos con la gente del team a un horario de merienda, siempre lo estiramos por que, obviamente, no nos gusta salir del trabajo a las 17 e ir a comer, pero bue... esta vez fue solo por LOST.
Una de las cosas divertidas fue que arreglé con mi mujer, que está en Bs As, para transmitirle por Webcam el capítulo, aca dejo el print screen.... les dejo un abrazo a todos

Primeros 4 días en Raleigh

Ya van 4 días en North Carolina y la verdad que muchas cosas pasaron, mucha copada tanto en lo profesional como en lo personal. Una cosa que me impresionó totalmente es la organización, es increíble, todo, desde el aeropuerto, las rutas, el alquiler del auto, el hotel... fue increíble llegar y tener prácticamente todo servido. Excepto por a valija que nunca llegó a tiempo, así que tuve que hacer el reporte pero el mismo domingo a las 11:30 ya estaba en la puerta del Hotel.
Mas o menos la cosa vino así, el viaje fue Bs As->Miami, Miami->Raleigh/Durham. Llegamos al rededor de las 12 del mediodía y lo primero que hicimos fue buscar el auto, también hubo una pequeña equivocación y ligué un Corolla negro, podría decir que es el auto que deseo tener de aca a un tiempo, asi que con eso pasó el mal gusto de no tener la valija en mi poder :)
El tema es así con la zona, hay dos ciudades muy cercas, una es Raleigh y la otra es Durham, ambas están muy cercas, alrededor de 20 mintos por autopista. En el medio de ellas se encuentra el Aeropuerto y el RTP (Research Triangle Park), nosotros estamos parando en el centro de Raleigh, bastante lejos de la oficina que está en el RTP... más o menos tardamos 30 minutos para llegar de un lado al otro. Las oficinas de IBM son increíbles, son las más grande que tiene en todo el mundo, son más de 30 edificios, de uno a otro es probable que tengas que ir en auto, hay varios comedores y starbucks.
El Hotel, la verdad que bastante bueno (de la cadena Hilton) me sorprendió bastante, tiene un pub muy muy copado con 12 tipos cervezas tiradas, 40 tvs ydos LCDs (los más grandes que existen) transmitiendo en HDV, la verda que increible. Tambien tiene una linda pileta climatizada y las habitaciones son bastantes agradables, mañana o pasado voy a postear un par de fotos.
Con respecto al trabajo, la verdad que venimos bastante bien, estamos de a poco tratando de cumplir los objetivos pero se me complica un poco ya que tengo mucho trabajo del día a día atrasado. La gente con la que estoy es muy copada y de distintos países, como India, Singapore e Inglaterra y obviamente estadounidenses. Somos alrededor de 22 personas en diferentes salas, trabajando e intercambiando ideas y conocimiento constantemente.
Realmente me impresionó muchísimo como todas las decisiones que venimos tomando y comunicando por telefono y ppts fueron excelentemente entendidas y muy bien trabajadas, ahora estamos de alguna manera uniendo todas las patas y la verdad que van encajando perfectamente. Estos días estuvimos trabajando muy cerca del Arquitecto de Build, Tony Marcotte, realmente me sorprendió tanto personalmente como profesionalmente, es una persona con la que tuve muy poca comunicación (pero efectiva) por teléfono y f2f fue genial, es increible como pudo desde mis diagramas de Componentes, Unidades de Deploy y Diagrama de Zonas de Red/Nodos armar y automatizar todo el proceso de Build and Deploy y dejar las cosas preparadas para comenzar a usar el Continuous Integration Server con Rational Build Forge. Estamos prepearando una agilización para este proyecto y creo que vamos a tener que innovar bastante ya que los procesos de mi organización son bastante tradicionales y waterfall (más de esto en el futuro).
La onda en general es muy buena, la PM, que es de Dallas es una fenómena, nos dá mucha flexibilidad y soporte en cuanto a las decisiones que tomemos, así que no me puedo quejar.
El día a día es bastante agitado, los levantamos a las 7:30 y volvemos a las 12:30, tratamos de salir de la oficina a las 17, nos quedamos un rato "hanging out", una nueva frase que aprendí, en criollo es "boludeando", luego vamos a comer o tomar algo y luego nos quedamos hasta tarde charlando y tomando alguna cervezas, ayer vimos en un plasma de 42 el partido de los spurs contra phenix.
Bueno, son las 1:20 AM aca y me estoy cayendo del sueño, en cuanto tenga algo más para contar lo voy a hacer, es probable que este fin de nos vayamos a Washington y tenga que cerrar algunas presentaciones de la Arquitectura para el Martes, así que hasta ese día dudo que pueda postear algo, pero voy a intentarlo.

Preparando las valijas

Esta noche estoy saliendo, si Dios quiere, para USA, más precisamente al RTP (Research Triangle Park) en Raleigh, en el estado North Carolina, junto a dos compañeros de trabajo, Rubén y Gabriel.
Vamos a estar por unos dias para cumplir con muchos objetivos, primero terminar de definir la arquitectura (implica para mí terminar de entender todos los temas de datos y algunas discusiones con el equipo de Build & Deploy), luego terminar de entender el negocio (cosa que me tiene un poco preocupado, si bien esta release es más de Infraestructura y cumplir algunos requerimientos no funcionales, ya en la próxima vamos a tener que agregar funcionalidad) y por último que planificar los cambios a la arquitectura para el armado de un DSL (esta si es mi idea) con el objetivo que los modeladores de productos puedan manipular las diferentes posibilidades de configuración para los clusters en linux.
No recuerdo si hablé algo o no, pero ASIT, es una aplicación que permite configurar Cluster 1350 y fue desarrollada por ingenieros en HW, con lo cual cumple muy bien con lo funcional, pero tiene serios problemas de mantenibilidad y calidad. Es una herramienta en SWING y en donde la vamos a deployar por Java WebStart (antes era una Applet). Hace tiempo que tengo ganas de trabajar en una herramienta Standalone pero esta vez me tocó como Arquitecto.
Creo que va a estar muy buena la experiencia, para poder conocer al resto del equipo dispersado por todo USA, a veces resulta un poco difícil el trabajo de arquitecto tan a la distancia.
Creo que en el tiempo libre vamos a ver de irnos a New York o a la Costa, no se, veremos como viene la mano, yo tengo mucho trabajo y espero poder hacerlo durante los días de la semana y no el finde.
Es la primera vez que me pasa que me voy de viaje y me pega un poco, y si... ahora soy papá, y voy a extrañar mucho a mi familia:

De vacaciones

Desde el viernes 11 he decidido tomarme un par de días de vacaciones. La verdad que los necesitaba muchísimo y mi mujer me organizó unas mini vacaciones espectaculares (gracias bombón).... asi que estuvimos visitando San Luis, aca les dejo las fotos...

La verdad que San Luis tiene lugares muy lindos, me quedo con Trapiche, Potrero de los Funes y la Florida, entre los que más me gustaron. Una particularidad del viaje fue que me encontré, de casualidad, con Jorge Bodoc, un groso, me invitó a comer un asado y la verdad que la pasamos genial, y si, todavía sigue fana de los Applets y con la idea de XObject más desarrollada :) Gracias Jorge!!
Práctiamente volví para dar la charla de en Snoop y ahora estoy definiendo un poco que hago, si se soluciona el tema del humo me voy a San Pedro, sino alguna otra escapada con Mechi y el chancho me voy a hacer.

Seguir un sueño.... suerte SmallWorks!

Quiero recomendarles un blog muy interesante que vengo leyendo hace un par de días y hoy, en mis vacaciones, me atrapó por completo por casi 2 horas, ya que no solo habla de cosas técnicas, sino de otros ámbitos como los negocios y por que no el aspecto humano.
Básicamente el blog fue creado por 3 profesionales de IT que están creando una empresa, si una empresa de sus sueños, con identidad propia, para poder trabajar en el tipo de proyectos que a ellos les gusta y en la plataforma que se sienten más cómodos, o sea Smalltalk.
Uno de esos tres profesionales es Esteban Lorenzano, participa en la cátedra de APIT, y realmente suma mucho a la materia ya que tiene muchos años de experiencia en Arquitectura de Software.
Espero que les guste el blog!

Cruzando Fronteras - Respuestas revolucionarias a la crisis de las web-applications (Rails y Seaside)

Si, ese fue el nombre de la charla que dimos con Esteban Lorenzano en el Snoop Update 08. La verdad que la pasé muy bien y me gustó mucho el resultado. En cuanto a asistentes, había muchos, alrededor del 65/70% de la sala Pablo Neruda llena, calculo que alrededor de 350/400 personas.... la verdad que fue la vez que más gente tuve en una charla.
Básicamente la charla apuntaba a explicar el por que de la crisis y como evolucionar, y se dividió en 3 partes, primero fue el por que de la crisis, con sus síntomas, contexto y motivos, luego con las respuestas radicales como RoR y Seaside, y por último algo de futurología.
Estamos tratando de escribir un paper al respecto y es por eso que no pongo tanto detalle. Aca les dejo las slides, espero que les gusten...

| View | Upload your own

Algo al margen, fue lo loco la cantidad de gente que me encontré en el Update, y muchas de ellas muy grosos, tal es el caso de Diego Mansilla, con el habia empezado un grupo de investigación sobre metodologías de desarrollo y habiamos investigado mucho el tema de las metodologías ágiles, y hasta dimos una charla en la UTN en el 2004, muy buenos recuerdos...
Tambien me encontré con mi primer profesor de computación de la secundaria (1999), Gonzalo Bellino (creo que ese era el apellido) que ahora está trabajando en Arquitectura en la AFIP, o eso le entendí. Fue muy loco ver al tipo que me enseñó comandos de DOS y WIN32.
Tambien me encontré con gente grosa del laboratorio como Diego del Yerro y Nico Passerini que nos vino a hacer el aguante.
Por ahora todo el feedback fue bueno, espero escuchar algo nás feedback!

Charla de Haskell

Ayer, Sábado tuve la oportunidad de participar de una charla que dio Nicolas Passerini sobre Haskell en la UTN, junto a otros docentes de diferentes materias como Paradigmas de Programación, Técnicas Avanzadas de Programación y APIT.
La verdad que estuvo muy buena y fue muy al grano, hace tiempo que tenías ganas de cursar algunas clases de la materia PDP pero nunca pude coordinar con Nico para ir a los días de Funcional. Un par de cosas que me quedaron:

• La verdad que hacía mucho que la cabeza no me funcionaba de esa manera, me hizo acordar a mis días en la facu con la pizarra totalmente llena y tratando de entender e interiorizar los conceptos, por momentos parecía AM2. La diferencia que aca no anotaba con lo cual no perdía el tiempo y podía seguir mucho mejor la clase.
  
• El lenguaje en general me pareció bastante similar al Prolog, sobre todo en la separación de los predicados y las consultas, como también el manejo de listas y la recursividad.
• Me gustó mucho la idea de no hay que abusar de la recursividad en el paradigma, no es que la recursividad es mala, pero en este tipo de ambiente, hay otras técnicas que permiten resolver los mismos problemas que la recursividad.
• Me sorprendió gratamente el lenguaje como maneja la definición de listas por comprensión. Aca hay un par de ejemplos, seguramente me meta un poco más adelante.
  
• Sin duda lo más interesante del lenguaje (o paradigma, no estoy muy seguro) es el manejo de Lazy Evaluation (evaluación perezosa), Composición de Funciones (esto es zarpado) y las Funciones de Orden Superior (esto no me provocó mucha sopresa, ya que de alguna manera lo vengo usando). Lo que si realmente me sorprendió fue el uso y potencia que pueden tener los dos primeros puntos.
• Realmente también me quedé fascinado con la relación que tiene el lenguaje con las matemáticas, Nico comentó que fue diseñado por matemáticos, pero lo llevaron a un punto muy extremo. Ya saben que a mi los extremos no me gustan, y tampoco la matemática me agrada del todo, no me resultó complicada, pero definitivamente no me gusta.... y debe ser por eso que me considero un programador mediocre.
• Otro temita que me quedó fue cuando preguntamos por TDD, y la respuesta ensayada fue algo como que la metáfora (esto lo agregué yo) que tienen en Haskell es poder demostrar que el programa va a funcionar gracias a la especificación / lenguaje formal que este tiene. Con lo cual el mismo código te demuestra que funciona. Sería lindo tener algo parecido en el mundo objetos, no? Igualmente IMHO algo para TDD es necesaria.
  

Sinceramente es un tema que voy a seguir, no se en que momento, pero me resultó muy muy interesante, no solo como Arquitecto y las posibles integraciones que podría llegar a haber entre plataformas como Java y Haskell, uno de los asistentes, Claudio Cancinos, comentó que se puede generar una DLL y llamarla, si no también como programador, muchas de las maneras de pensar y solucionar problemas (parecidas al Tell don't Ask) se pueden llevar con ciertos truquitos a Java o Ruby.
Aca les dejo algunos links que fui recolectando...
http://tadp.no-ip.org/paradigmas/uploads/Introduccion_al_lenguaje_Haskell.pdf
http://tadp.no-ip.org/paradigmas/uploads/ParadigmaFuncional2007-complemento.doc
Un libro que me recomendo la nerd de mi mujer. Introduction Functional Programming usin Haskell
Un Eclipse para Haskell

Se está armando una comunidad de Ruby on Rails en Argentina

Por lo que pude entender una empresa (aparentemente de extranjeros) esta formando parte de una iniciativa de formar una comunidad de RoR en Argentina, y como kick off van a dar un par de charlas cortitas sobre sobre Rails, creo que vale la pena darse una vuelta, es por Palermo.

http://www.facebook.com/event.php?eid=24680795888

Tom Addland and I are starting a Ruby on Rails group in Buenos Aires called Tango Rails. Our goal is to help promote the growth of the Rails community in Argentina. We plan to meet every month or so and host short talks on Rails that last 20 minutes or so. Next week we will be having our first meeting at my office in Palermo. The address is Córdoba 5110 piso 1 and here is the agenda.

Tango Rails Kickoff Meeting 3rd of April 2008
19:00 Open discussion/Intros and such
19:30(sharp/en punto) Scaffolds on Steroids: Intro to Active Scaffold in English (Eric Northam)
19:50 Open discussion/Coffee break
20:10 Intro to hosting your apps with Amazon Web Services in English (Tom Addland)
20:35 Closing remarks, comments, and where to go with the group

The talks will sometimes be in Spanish but for our first meeting both will
be in English.

Please RSVP by email if you plan to attend.

Tom Addland y yo estamos empezando un grupo de Ruby on Rails en Buenos Aires llamado Tango Rails. Nuestra meta es de promover el crecimiento de la comunidad de Rails en Argentina. La idea es reunirnos cada mes y facilitar charlas de unos 20 minutos sobre Rails. La semana que viene vamos a tener nuestra primera reunión en mi oficina en Palermo. La dirección es Córdoba 5110 piso 1 y acá está la agenda:

Tango Rails Kickoff Meeting 3rd of April 2008
19:00 Open discussion/Intros and such
19:30(sharp/en punto) Scaffolds on Steroids: Intro to Active Scaffold in English (Eric Northam)
19:50 Open discussion/Coffee break
20:10 Intro to hosting your apps with Amazon Web Services in English (Tom Addland)
20:35 Closing remarks, comments, and where to go with the group

Y arrancó un nuevo cuatrimestre en APIT

Un día bastante atípico en el cual a las 5 de la tarde parecía de noche y caía una cantidad de agua increible, y yo en el medio de una call con un colega de Brasil hablando en ingles (patético), se pasaba el tiempo y no podía salir para la facu, donde hoy era el primer cuatrimestre... el tema fue que recien a las 18:30 partimos para la facu y era un diluvio, no menos de 3 choques se pudieron observar en las 20km que tengo que recorrer por panamericana, gral paz y lugones para llegar a la facultad, lo bueno, venía con dos de mis dos nerds preferidos de IBM en el auto (Gona y Andres), lo cual lo hizo bastante ameno el viaje, salieron temas como metodologías ágiles e ingeniería en software en general, justo el tema que dábamos hoy en la materia.

La cosa es que llegué bastante tarde a la clase y Nico ya había arrancada con la presentación de la materia, y lo primero que me encuentro es un curso repleto y cuando entro al aula de repente un fuerte aplauso por haber llegado (tarde obvio) partio de las manos de Nico y seguido por todo el curso, en fin linda recibida :)

Tengo todas las expectativas para este cuatrimestre ya que en el último tiempo, tuve bastantes nuevos desafíos laborales y que quiero compartir como ejemplo a lo largo de la teoría que exponemos en la materia. Con respecto al cronograma y tp, la verdad que no cambia demasiado, seguimos repitiendo un poco todo, que es lo que nos viene dando muy buenos resultados. Un poco la diferencia de este cuatrimestre es que no lo tenemos más al Lic. Carlos Leone, como representante formal, sino que a partir de ahora yo soy el Profesor Adjunto de la materia, obviamente falta un poco de papelerío pero todo parece indicar que sale. Así que todo la parte administrativa, ahora es mía... es pero que no me coma mucho tiempo.

Como todos los años elegimos los topicos de los papers a ser desarrollados y nos quedó algo asi:

• RIA Offline, es posible?
• Métricas de Arquitectura
• Domain Specific Languages
• Lenguajes Dinámicos
• Arquitectura en metodologías ágiles
• Software as a Service (SaaS)
• Arquitectura de Aplicacions Móbiles

Donde yo probablemente me incline a tutorear los temas de RIA (que original no?), Métricas de Arquitecturas y SaaS.

No me quiero olvidar de decir que se nos unió a la catedra Santiago Blanco, un excelente alumno del cuatrimestre pasado y con mucha experiencia, acá pueden conocer un poco más de el.

Esto es todo.

Primer Post de la serie "Me casé con una nerd"

Para los que no lo saben el amor de mi vida (Mecha) aparte de ser una excelente madre, es una nerd si, y a veces muuuucho peor que yo, asi que decidí iniciar esta sección en mi blog para contar las salidas de geek que tiene y que muchas veces me deja descolocado ;) aca va el primero, espero que les sea divertido...
Mientras Andrés (mi hijo) dormía la siesta estábamos cada uno con su laptop y me manda por chat, "Gus, mirá este video te va a gustar yo lo estoy viendo http://www.youtube.com/watch?v=Tcwx-I6Arwk "
La verdad que pensé que era alguna propaganda, video música.... o un avance de LOST, pero no... era una google talk con el título "Teaching Kids To Code" jajaj, aca se los dejo ;)

En que ando... lost, snoop, apit, asit, peopleware

Hace bastante que no escribo y la verdad que no es por que no quiero sino que estoy teniendo unas semanas bastante ocupadas preparando y trabajando muchísimo, aca van algunas de las cosas:

1. Una de las cosas que me permite bajar un poco a tierra (aunque me deja muchas veces pensando) es esta serie adictiva de LOST, en unn fin de semana con mecha nos pusimos al día y nos miramos 8 capítulos seguidos, la verdad que es una enfermedad, pero ya que estoy comparto un par de links interesantes (nada de spoilers), lostzilla.com, lostpedia.com, abc.go.com/primetime/lost/
2. En ASIT, mi actual proyecto, todavía estamos en una etapa de mucha preparación en donde mi equipo todavía no es el owner del código, ya que hay otro equipo cerrando algunos features y yo estoy más que nada creando algunos documentos de arquitectura utilizando la metodología interna de IBM (de arquitecture) que está bastante buena, sobre todo por que tiene un IDE (sobre eclipse) que te permite llevar todo el crecimiento evolutivo de la arquitectura y mantener todo relacionado, empezando por un System Context, pasando por requerimientos, use cases, componentes, unidades de deploy, nodos, zonas de red y obviamente pudiendo trackear todas las decisiones arquitecturales, assumptions, etc. La verdad que si bien no hay mucha adrenalina, el hecho de crear los diagramas y comunicarlos a diferentes stakeholders como Build Architects, Developers, Infrastructure Architects, Analistas y PM es más que un lindo desafío. Por el momento estoy solo creando documentos uni-viewpoints, bastante distinto a lo que digo en la materia, pero bue.... el proyecto está un poco a las corridas y se hace lo que se puede. La parte buena de todo este que ya se sumaron dos developers (Gabriel Benemergui y Ruben Ghio) en Argentina de gente excelente, eso como arquitecto me deja más que tranquilo.
3. Con respecto a APIT, la verdad que le vengo dedicando poco y nada, la idea que este cuatrimestre, otra vez de 14 clases va a ser bastante parecido a los dos anteriores, pero estoy muy contento por que generalmente los primeros cuatrimestres el nivel de la gente que cursa es muuuuuuy superior al del segundo, aunque todos los ayudantes que tenemos en la materia salieron del segundo cuatrimestre :)
   
4. Esteban Lorenzano, me invitó a participar del Snoop Update 08' para dar una charla sobre los problemas actuales de las aplicaciones web y que soluciones radicales existen, y aquí vienen Ruby on Rails y Seaside, la verdad que estoy muy contento por que es un tema que me gusta mucho y vengo trabajando de costado con RoR. Lo que vamos a tratar de hacer es crear un paper que guie la presentación, voy a postear un poco más sobre esto.
5. Y por ultimo, asi no los aburro, en este ultimo tiempo estoy terminando de leer Peopleware — Productive Projects and Teams, la verdad que es un libro super interesante y me sorprendió al mismo nivel que lo hizo, Mythical Man Month, lo recomiendo a todos los que tienen aspiraciones de líderes o ya lo son. Es más creo que las metodologías ágiles sacaron muchas cosas de este libro.
   

Que queres que tu gerente sepa sobre metodologías ágiles?

Hoy leí un post muy interesante en infoQ, que comentaba sobre una encuesta que le hicieron a 50 desarrolladores sobre que cosas nos gustaría que nuestros gerentes sepan acerca de las metodologías ágiles.
Mi primera respuesta, sin inhibiciones ni filtros sería:
"Vamos! lean un poco y dejen de creer en prácticas de hace 20 (o menos) años atrás que ni sirvieron cuando estaban en los proyectos y que menos sirven ahora, la ingeniería en software está cambiando y no hay duda que este tipo de metodologías son única manera de construir software decente, por favor... tomen y lean al menos este articulo", media vuelta y portazo en la cara :)
Hablando en serio, es obvio que no haría eso, pero la gente con experiencia generalmente critica sin conocer y eso no está bien. Lo que si me gustaría agregar a esa lista es que es que usar una metodología Agile no quiere decir que el proyecto va a ser más rápido o va a costar menos, una cosa no implica la otra... lo que si te va a asegurar es que el software va a cumplir con los que el usuario quiere y va a tener como dice el articulo mucha más calidad.

Epoca de cambios - Say it isn't so

En este momento de mi vida laboral y profesional estoy experimentando una serie de cambios que me están representando desafíos muy interesantes, y por suerte todo parece alinearse (afortunadamente) con la visión que tengo desde hace 3 años, que obviamente no fue fácil de definir allá por el 2004/2005 cuando me estaba recibiendo.
En pocas palabras mi visión cuenta con dos focos muy alineables, uno más a nivel país y otro más personal y básicamente tiene que ver con lograr que Argentina sea considerado una potencia mundial en lo que al desarrollo de software respecta, diferenciado por la calidad... y por el lado personal, está más que claro que quiero participar activamente de esto con un rol de liderazgo técnico.
Acá viene un poco la disyuntiva entre el líder técnico o arquitecto, la verdad que me gustan un poco las dos, creo que tengo un buen skill de relación personal, que lo vengo trabajando hace mucho tiempo, tanto en la práctica como en el estudio, y obviamente la arquitectura y las metodologías me apasionan. Creo que no tengo que jugarme por uno rol o el otro, todo lo contrario, se complementan y mucho.

Afortunadamente estando en IBM, tengo muchas posibilidades de cumplir con esa visión, ya que hace 4 años que estoy trabajando en el offshoring con USA, 3 años que cumplo con un rol de liderazgo técnico de un grupo que fue creciendo muchísimo a lo largo del tiempo y en Enero acabo de ser asignado a un nuevo proyecto ya con el rol formal de arquitecto de software o application architect, también de USA. Obviamente esto se pudo dar gracias a la cantidad de educación y esfuerzo que estuve teniendo dentro de la carrera de arquitecto, que realmente es algo que destaco muchisimo de IBM, que es que tiene una gran cantidad de recursos y conocimientos para capacitarse como IT Architect (como se le dice aca), hablando con otros Arquitectos, de otras empresas la verdad que no encontré nada igual, eso si, te tiene que gustar o soportar la burocracia y los procesos pesados asociados a la metodología de arquitectura, pero pronto calculo que se va a ir agilizando (o eso espero)...

En fin, la idea de este post era contar que estoy dejando un equipo que me lleno de alegrías por varios años, formado por gente de USA, India y Argentina... me está costando mucho dar un paso al costado ya que el 70% del equipo fue armado en gran parte por mi y sinceramente son todos excelentes profesionales y personas. Pero se que es algo que tengo que hacer para seguir creciendo... UI Team, fue el mejor ejemplo de teamworking que he tenido y nunca lo voy a olvidar, la líder del equipo de USA me preparó una presentación que realmente me llenó los ojos de lágrimas y que nunca voy a olvidar, y aca la posteo



Probablemente escriba un post en ingles agradeciéndole esto a Angela Savino, aparte de ser una gran líder, una gran persona, creo que nunca, en 4 años, tuve un reproche por alguna decisión tomada, realmente intachable.

Charlas en el 2008 que me gustaría dar o escuchar

Como todos los años, junto a la gente técnica y copada de IBM planificamos una serie de charlar en las cuales intercambiamos conocimiento. Lo venimos haciendo desde el 2005 y la verdad que son de muy buena calidad, lo único malo es que desde que las hacemos vía telefónica, se perdió bastante el debate, cosa que era lo más importante cuando empezamos. Con un objetivo de listar y que me ayuden sobre que temas sería importante no olvidar este año:

• Creo que Grails debería ser un tema a escuchar, más allá de Groovy, creo que ver como el mundo Java desde el lado de scripting adaptó RoR sería algo interesante de ver.
• Groovy sigue siendo algo que no hay que perder de viste, sobre todo para incorporar en aplicaciones Java, creo que usarlo como medio de contenido para extender o modificar la aplicacion en runtime puede ser muy interesante. Hoy generalmente usamos XML, pero creo que Groovy podría ser tambien interesante.
• Ruby on Rail, todavía me debo armar una charla sobre este framework junto a Damian Garcia, no tanto en la gilada del scaffolding (CRUDs) , sinó en los principios y ventajas que tiene construido sobre un gran lenguaje.
• Creo que Continuation seguirá siendo un area en la cual tenemos que seguir investigando y aprendiendo para la correcta implementación.
• Uno de los temas que hay que ir teniendo en cuenta es la Performance en las aplicaciones RIA con CSS y JavaScript, sobre todo con los ítems de usabilidad y cantidad de pedidos ajax que se están haciendo por pantalla. Creo que muy pocos lo estan teniendo en cuenta y es un tema que hay que ver de manera urgente.
• Creo que SOA va a seguir siendo un tema interesante de charlar, sobre todo temas de armado de equipos, prácticas de desarrollo (construcción), integración continua en desarrollos de integración, por que no TDD para BPM, todo ese tipo de cosas que están muy maduras en aplicaciones, pero esta vez para integración.
• Yo calculo que voy a dar alguna otra charla de TDD un poco más avanzada, y quizá ver la manera de como enganchar el TDD con los frameworks de desarrollo, la idea es como ver de facilitar el TDD con un framework.
• Por que no algo de JavaScript, me parece un lenguaje increíble, y quiero que se use correctamente, ya por el 2000 programaba en JavaScript y sentía que lo hacia bien y sabia, pero ahora me doy cuenta la manera en la cual lo usaba era patética, y lo que me molesta que hoy exista gente que primero, lo menosprecia y por otro lado lo use de la manera que yo lo usaba en el 2000. Me gustaría ver temas de prototipado, clousures, performance, entornos de desarrollo, interacción con el DOM (cualquiera sea) y tdd.
• Otra charla que me gustaría dar es sobre los AntiPatters de los patrones de diseño... quiero erradicar el uso del Singleton indiscriminado, no lo soporto más... quiero que la gente antes de implementar un patron de diseño piense por que y no que lo use por el solo hecho de que soluciona el problema, si no que lo use por que es la solución más simple de todas. También quiero que se priorice la orientación a objetos por sobre el uso de patrones de diseño, muchas veces los patterns te obligan a separar el comportamiento del estado y eso si que está muy mal, en algunos casos, muchas veces cometí este error y creo que pudo hablar de ello.
• Me gustaría escuchar una charla sobre los 6 principios de Robert C. Martins de la programación y diseño orientado a objetos. Introductorio sobre Patterns y Principios - http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
• Un colega ya está preparando para presentar un resumen del libro de Pragmatic Programmer, biblia del programador cuando entra a IBM, o al menos a mi area.
• Creo que algo de Earlang me gustaría escuchar, es un lenguaje que viene sonando y lo poco que pude ver es interesante sobre todo por el uso del paradigma funcional.
• Y por que no DSLs... o en Ruby o LISP

Esto es lo que se me ocurre por ahora, por favor tienen algo para aconsejar, se los agradezco...

Tipos de Arquitecturas de IT

Uno de las primeras cosas que hay que entender sobre la Arquitectura es que existen diferentes tipos en el ámbito de IT, con lo cual es muy importante tener claro que rama o especialización de la arquitectura uno quiere desarrollarse y obviamente el alcance de cada una. Esta es la clasificación que más me gusta y es la damos en APIT:

Enterprise Architecture (EA) : Es la arquitectura toma las decisiones necesarias para que Organizació de IT de la compañia esté alineada y permita cumplir con visión/misión de la organización en cuestiones de negocio , definiendo guías y políticas para que el conjuntos componentes de IT (redes, hardware, software, aplicaciones, etc) crezca de manera ordenada siguiendo un objetivo bien definido.

System architecture: Relaciona los requerimientos y el mundo externo con las estructuras del sistema, incluyendo el hardware y el software. Vendría a ser la Infraestructura.

Software architecture (o Application Architecture): Está relacionada con una aplicación en particular, o sea con el desarrollo de un software en particular, son las decisiones que se toman pero acotadas a un proyecto o aplicación en particular y no cross a la organización como la EA. Esta es el tipo de Arquitectura en la que trabajo y está focalizada la materia.
Integration Architecture: Está relacionada con las decisiones tomadas desde el punto de vista de la integración de las diferentes aplicaciones y los procesos de negocio asociados. Como para dar un mejor entendimiento, temas como SOA o EAI, estarían en este tipo de Arquitecturas.

Existen otro tipo de Arquitecturas pero en mi opinión ya con la clasificación planteada alcanza, como por ejemplo, Data Architect, Business Architect, etc.

Alguno creo que se puede mejorar esa clasificación?