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?

Y asi termino mi ulitmo codigo del 2007 - Green!

Unit Test para renderizadores de HTML

Actualmente estamos en la etapa de diseño y desarrollo de una nueva release del proyecto en el que vengo trabajando hace 4 años (uhhh, como pasa el tiempo)... si bien la release no es algo tan complicada, nos tomamos el tiempo para mejorar el componente de Vista, y cuando digo vista estoy hablando principalmente de la renderización a html. La metáfora que tenemos es que al componente de Vista solo llega un ViewBean que es la representación de la pantalla en objetos, y este componente debe a través de renderers asociados a cada elemento del ViewBean generar el HTML. Con lo cual apuntamos a que la generación de la vista sea creando objetos estándares y no tocar absolutamente nada de HTML o el lenguaje que general el html como Velocity o JSP. Pero para esto necesitamos crear buenas abstracciones de UI, y va a ser un proceso muy iterativo, dudo que pueda ser para esta release, todavía necesitamos mucha interacción con la persona que define las pantallas para que trate primero de tener una consistencia funcional. De todas maneras, exista o no una consistencia funcional, la idea de tener objetos/componentes abstracto que permitan reutilizar los renderers sigue siendo interesante.
En fin, me estoy perdiendo el foco, del post, una de las cosas que estoy tratando de hacer es crear un framework de Unit Test, para que todos los desarrolladores de renderers pueden Uni Testear los renderizadores sin necesidad de ver el resultado en el browser, con lo cual mi idea es poder, para cada test case hacer algo como:
1- Crear el ViewBean con la información que del escenario que quiero testear
2- Ejecutar el Renderizador que devuelve el HTML
3- Realizar los asserts, queriando el HTML para ver si la información se reemplazó correctamente, ver si hizo los cantidad de Loops correctos, si pasó por los caminos que yo especifiqué , etc, etc, etc. No me interesa saber si el html tiene todos los temas de estetica ya que eso lo va a tocar una persona a fin.

El problema que tengo hoy en día es que no encuentro un framework/componente que me permita llegar al paso tres, ya que al HTML llego sin problema, lo que necesito ahora es buscar una forma de inspeccionar el HTML en texto que tengo y poder consultarlo para hacer los assert correspondientes. Se me ocurrieron tres ideas :

• Usar HtmlUnit. Pareciera la solución más obvia, pero investigando un poco el framework me di cuenta que no es tán feliz como yo pensaba. Si o si para consultar un HTML tenes que hacer un pedido por la red y http, cosa bastante poco práctica. Obviamente esto se puede evitar mockeando el conector y devolviendo siempre un HTML fijo. El problema es que estos componentes que yo quiero unitestear solo me devuelven una porción de HTML y no un HTML bien formado con el head y el body, con lo cual es imposible llegar a tener una representación objetosa del HTML que me permita consultarlo. Lo que me gustó de HTMLUnit es que tiene la representación objetosa de los elementos del HTML. Obviamente estuve muy poco tiempo viendo el framework y quizá se pueda, pero en fin... me hizo sentir un poco infeliz el HtmlUnit, aparte de haber muy poca documentación.
• Usar Expresiones Regulares, en principio me pareció que era una idea copada, pero despues pensé en el resto, si a la gente ya le cuesta hacer un Test Case de codigo de Modelo o Controller, o sea Java puro, también le pido que haga un Test Unitario para los renderizadores, sumado a esto, aprender expresiones regulares que entiendan el HTML para verificarlo, me recibo de necio. Digamos que las Expresiones Regulares son algo duras de entender, incluso las que creó uno mismo... con lo cual solución descartada...
• La ultima, que es la que voy a probar es usar XPath, ya que en teoría cada HTML renderizado por cada renderer debería ser un XML bien formado, con lo cual eso me permitiría hacer queries con XPath y tener assert mucho más sencillos. Obviamente la gente que haga estos test cases tiene que aprender Xpath, lo cual no es algo trivial, pero bue por ahora es lo mejor que se me ocurre.
  

Hace 4 años estuve viendo jameleon y creo que me puede servir, pero cuando entré a la página me asustó un poco, alguno tuvo alguna experiencia con esto? creen que me pude servir?

En cuanto tenga algún resultado les voy a contar...

Tell, Don't Ask

Le verdad que me gustó mucho este post de uno de mis ídolos, Michael Feathers. Creo que este concepto es hasta casi más importante en Objetos que temas de Herencia y Polimorfismo (con esto me pueden llegar a enterrar) pero si, creo que esto es una de las cosas más importantes para diseñar en objetos (dependencias).
Creo que habría que tomarse el tiempo y probarlo de una manera bien extremista como para ver que sale y obviamente ver como encarar los mensajes entre los objetos y desglosar un poco (como dice Mark Miller) el concepto de "Tell".
No tengo más que decir por el momento sobre este tema, pero les aseguro que voy a ver que pasa yéndome a un extremo.

Ya es hora de mirar nuevos horizontes - Beyond Java

En dos semanas tengo planificado, junto con Gonzalo de Pedro y Andrés Calabrese, dar una charla con el objetivo de presentar técnicas y conceptos de programación que están cambiando a la industria del desarrollo de software y que Java, por ser la plataforma de desarrollo indiscutida, le cuesta adoptarlas aunque muchas veces se pueda.
Estaría dirigida a los profesionales que trabajan en java y quieren abrir sus mentes y ver como se están desarrollando el software en otras plataformas para luego traer esas técnicas al mundo java.
En principio los temas que se nos ocurren son los siguientes:

• Continuation
• Open classes
• AOP / Hooks
• Subject Oriented Porgramming
• Duck Typing
• Mix-in
• Clousures
• OOP con Prototipado (Javascript & Self)
• Domain Specific Languages
• Behavior Driven Development
• Conventions over Configuration
• Concurrencia con Earlang
• Behavioral completeness

Un poco la idea es abrirle la cabeza a los desarrolladores Java como para que vean que fuera de la burbuja java (empresarial) existen conceptos muy interesantes que le puede hacer la vida como desarrollador mucho más feliz y como dice DHH más productiva.

Si tienen alguna sugerencia, por favor no duden en comentar.

RadRails 0.9.1 - El Code Assist ya está funcionando

En el post anterior comenté que el Code Assitant del RadRails (Aptana) no estaba funcionando muy bien, bueno, antes de ayer bajé la nueva versión y ahora está funcionando bien, asi hagan el update, pero ojo que es una beta y para hacer el update hay que apuntar a otra URL, por favor lean aca como hacerlo.
Lo que si me dejó de funcionar, pero tenemos que investigarlo un poco más, es el tema de el output de los rSpec que venimos usando para diseño y test. El problema es que el output (a diferencia de xunit) antes lo tiraba a consola dentro del aptaba y ahora me lo tira a una consola de DOS que cuando termina de ejecutar se cierra sola... pero bue ya lo resolveremos.

Bill on Rails... segunda iteración cumplida

Hace un par de meses comencé junto a un grupo de gente de IBM un proyecto relativamente pequeño, que se encargará del manejo de ordenes de compra y seguimiento de facturas emitidas por los proveedores. Obviamente, este proyecto tiene otros dos objetivos:
- Implementar y aprender sobre Ruby on Rail y sobre todo el lenguaje Ruby
- Desarrollar el software de una manera iterativa incremental utilizando metodologías ágiles como Scrum y XP,
Luego de cuatro meses en donde estuvimos investigando, aprendiendo en conjunto y luego comenzando con el desarrollo de la aplicación tuvimos muy buenos resultados y me gustaría comentarle algunas cosas que venimos haciendo:

• Estamos usando Aptana como entorno de desarrollo que posee un plug-in muy copado para desarrollo de aplicaciones RoR llamado RadRails, este fue comprado (o algo por el estilo) por Aptana hace unos meses. Si bien todavía está un poco verde y no tiene mucho code assistance te da una mano bastante grande facilitándote la ejecución de los generators y las tareas rake. Aparte de permitir debug y syntax high-lighting.
• Como base del Aptana tambien estamos usando InstanRails que te instala de una todo el entorno Ruby, MySQL (con phpMyAdmin) y el Apache, en dos clicks tenes el entorno listo para comenzar a programar. No hay que olvidarse que al Aptana hay que apuntar al IntantRails para que tome el interprete Ruby.
• Como herramienta fundamental de comunicación estamos usando el Wiki, tenemos todo centralizado assets, tutoriales, backlog de requerimientos, direcciones de svn, estandares, arquitectura, release plan, build & deploy, etc, etc.
• Todo el manejo de Tareas e Issue tracking estamos usando la fantástica herramienta de Trac que nos permite mantener en un único lugar parte del SCM necesario para llevar a cabo el desarrollo, obviamente integrado con Mylyn y SVN. Realmente es una herramienta muy simple y que tiene todo lo necesario para asignación de tareas y defectos como así también su seguimiento.
  
• No hubo mucha discusión con la decisión de usar SVN para el versionado, es rápido, fácil de configurar, se pone atrás de un apache, lo que permite mantener la autenticación y autorización corporativa y se integra perfectamente con el eclipse y el Trac. En este ultimo punto, le pusimos un hook para no permitir commitear a menos que haya una tarea en estado "working" asociada.
• Uno de los Plug-ins que me está maravillando (gracias Andrés Calabrese) es Mylyn, la verdad que la gente que lo inventó realmente tuvo una idea genial debido a que no solo permite integrar las tareas del trac (o de cualquier issue tracking) en el IDE, sinó que también permite el uso de contextos lo cual aumenta la productividad minimizando la cantidad de información visualizada. Les recomiendo escuchar este podcast de 20 minutos en donde explica brevemente que es Mylyn y como utilizarlo.
• El Build & Deploy automático lo estamos encarando utilizando Capistrano y guiándonos con el nuevo libro de la serie de pragmatic programmers llamado "Deploying Rails Applications". Todavía no tenemos un entorno con Capistrano funcionando pero no falta mucho, cuando cierre voy a postear algo sobre el tema.
• La referencia obligatoria del lenguaje es este libro "Programming Ruby", la primera edición está abierta y es gratuita. No se que hablar mas de Ruby, realmente es un lenguaje que cada día me gusta más. En este post explico por que. Lo único que voy a agregar es que definitivamente antes de tirar líneas en Ruby, les pido por favor que lean, no se les ocurra programar como si estarían en Java.... no van a llegar a nada.
• El framework, Ruby on Rails, que les puedo decir... está muy bien enfocado y acotado a los que quisieron hacer, pequeñas aplicaciones web con bases de datos atrás. Lo único que me resulta un poco flojo es el tema de la concurrencia de migrations, si bien es una excelente idea, si no tenés cuidado se puede armar un con los mapeos a la base de datos, nosotros lo minimizamos tratando de poner un solo encargado para crear las migraciones, les pido que lean por que la idea es muy buena, todavía le falta madurar pero el approach está bueno. Todo lo que es ActiveRecord y AJAX, la verdad que me tengo que sacar el sombrero, Rails lo resuelve de una manera muy elegante, ya voy a hablar del tema.
• En cuanto al Diseño y Unit Test venimos usando técnicas de BDD (Behavior Driven Development) utilizando rSpec y el plug-in para rails de rSpec que realmente está bastante cerradito para lo que es la parte de Modelos (ActiveRecords). Resultó muy práctico e interesante empezar a escribir las especificaciones de los Modelos para empezar y luego a través de los generadores de rSpec para Rails creamos los modelos. Lo único un poco málo es que la documentación es bastante poca y siempre que te topas con un problema hay que arremangarse y tratar de solucionarlo y muchas veces se pierde mucho tiempo, pero bueh... es un costo que estamos asumiendo. Obviamente no solo estoy trabajando en esto, con lo cual cuando vuelvo a Java y a JUnit me quiero pegar un tiro :(
  

Me faltó hablar un poco de la metodología que usamos, pero prefiero terminar aca y escribir en otro post sobre esto ya que hace una semana también estuve involucrado en la definición de una metodología (ágil) para un proyecto un poco más grande y más importante que este :p

Cursos muy buenos de JavaScript en Video

Hace un tiempo, en Yahoo! UI Library: YUI Theater, se publicó un curso muy completo de un lenguaje que me resultó muy interesante, y que muchos piensan que más que un lenguaje es un juguete. En mi humilde opinión, es el gran lenguaje con conceptos increibles. Ya algo escribí luego de la charla de lenguajes prototipados.
Este curso es muy completo y el instructor (Douglas Crockford) lo hace muy llevadero. Yo lo hubiese querido haber hecho 8 años atrás cuando empecé a programar aplicaciones Web y pensaba que JS era un juguete (que equivocado que estaba)
Parte 1

Parte 2

Parte 3

Parte 4


Las diapositivas las pueden bajar de aca

Espero que les guste.

Ruby: un lenguaje muy simpático

En IBM estamos empezando un proyecto en Ruby y la verdad que el lenguaje me está cayendo muy pero muy simpático.
Acá les quiero dejar una presentación muy buena sobre 10 features que tiene el lenguaje. Espero que les guste, también les dejo un resumen:
#10 Convenciones
#9 Todo es un objeto
#8 (Casi) Todo es un mensaje
#7 Ruby es más dinámico de lo que parece (Open clases, reflection, hooks, singleton method, code evaluation, etc)
#6 Ruby es fuertemente tipado pero no estáticamente tipado
#5 No te preocupes por las interfaces (Duck Typing)
#4 Soporta Mix-Ins (Algo parecido a lo que se podría hacer con herencia multiple)
#3 Closures
#2 IR (docs) es tu amigo, IRB (consola interactiva, recomendable) también es otro amigo
#1 Deja de escribir tanto código!
Este es el link
Creo que todos, antes de hablar bien o mal de ruby, deberían saber que posee estas features.

Un camino que lleva a RIA

Luego de 7 meses bastante duros, pudimos llevar a producción la release 2.3 del proyecto que vengo trabajando hace años. La verdad que esta release tuvo un gustito particular, debido a que no solo se agregó mucha funcionalidad, en muy poco tiempo, sino que también tuvimos que implementar nuevas tecnologías para agregar items de usabilidad que impactaron bastante en la arquitectura.
Básicamente el objetivo fue pasar de una aplicación web tradicional a algo más híbrido y más parecido a una RIA (Rich Internet Application).

Voy a tratar de listar un par de prácticas y lecciones aprendidas que tuvimos en esta release:

• Tener bien separado los diferentes concerns del browser, Contenido (HTML), los Estilos (CSS), Eventos(JavaScript) y Comportamientos (JavaScript). Esto ayuda a tener un código más simple, claro y mantenible. Lo que hicimos fue framework en JavaScript que obligó a estructurar un poco más el código javascript, con lo cual cada funcionalidad tenia su archivo/objeto/metodo en donde debía escribirse. Realmente JavaScript me resultó un lenguaje increíble, muy potente...
  
• Como parte del proceso de transformar una Web Tradicional a una RIA, tuvimos que mantener las páginas como están y agregar los items de usabilidad desde allí, o sea, tener un único refresco completo por pagina (cada vez que se va de una página a otra), y mientras el usuario realice transacciones en esa página, recién ahí utilizar AJAX/AHAH para actualizar partes de ella. Es importante destacar que el uso de AJAX y AHAH brinda una gran performance, mejorando la latencia y utilización de recursos, debido a que hay menor transferencia de datos y que la página no se refresca por cada transacción.
• JSON es la mejor manera para intercambiar datos entre el browser y el Server. Todos los delta de página son devueltos en un único objeto JSON con pedacitos de HTML renderizados en el Server. Está claro que JSON es muy superior a XML en este conexto, ya voy a hablar un poco más de esto.
• Una parte interesante fue la modificación que le hicimos al componente de Vista, debido que se componentizaron los renderizadores de HTML, y ahora estos renderers son utilizados tanto para crear el HTML de la página completa como los delta de HTML que viajan a través de JSON.
• El manejo de eventos en el browser tuvo un cambio en el final de la release, empezamos usando Event Handling y terminamos con Event Delegation (con bubbling) lo que mejoró muchísimo la performance. En este link se explica muy bien la diferencia.
  
• Ni Client Pulling, ni Server Pushing son la mejor solución. Luego de implementar un Indicador de Progreso para transacciones largas, llegamos a la conclusión que las actualizaciones del Server al Browser (Reverse AJAX) debe ser una solución intermedia entre los dos enfoques, ya que esto evita muchos problemas de performance y concurrencia.
• YUI Yahoo es una librería de JavaScript increíble ya que posee muchísimos widgets y componentes configurables, como los Menus, Paneles (eliminamos los malditos popups), Connections, etc Pero sobre todo nos permitió lidiar con el cross browser compatibility.
• Firebug rocks!
  

Obviamente nos faltaron muchas cosas por mejorar y hacer:

• Armar un buen entorno de Unit Test de JavaScript, estuve probando JSUnit, pero no lo pudimos institucionalizar :(
  
• Realizar inclusiones de JS dinámicamente
• Tener un mapeo de Evento<->Comportamiento más declarativo en JS que permita reutilizar más comportamientos o behavior, creo que estamos bastante bien, pero todavía necesitamos más trabajo.
• No pudimos resolver, por falta de tiempo, como enviar solo la información que cambió en el formulario del browser.
  
• El HTML de la aplicación todavía es muy muy feo, hay que trabajar más en este tema para poder tener el contenido mejor representado.
• No pudimos incluir el Spring Webflow, lo que nos hubiese permitido tener una aplicación con flujos mejor definidos y un modelo más stateful en el server.
  

Espero que les sirva esta experiencia que ganamos, calculo que en algún momento explotaré cada uno de los puntos planteados y daré más detalles... probablemente en algún articulo y mejor redactado.

Web Semántica - Seminario Athenas - 21 de Agosto

La agenda es la siguiente:
19:00 hs: Presentación.
19:05 hs: Grandes personajes de la historia: Tim Berners-Lee.
19:20 hs: Cómo funciona internet hoy
19:35 hs: Qué es la web semántica (metadatos, XML y RDF)
20:15 hs: Coffee break.
20:30 hs: Qué es una ontología y para qué sirve
20:45 hs: Ejemplos de OWL
20:55 hs: Cómo integramos todo esto: webservices
21:10 hs: Cómo funcionará internet mañana.
21:30 hs: Cierre

Hace un tiempo que vengo tratando de seguir el tema, escuché un podcast de Tim Berners-Lee, en el cual dijo que el actualmente está trabajando en esto y tambien escuché un par de comentarios de compañeros de trabajo como Fernando Sanabria y Gona, aunque todavía no lo pude conceptualizar. Creo que va a ser muy interesante.

5 puntos débiles que se le podrían encontrar a YUI Yahoo!

En IBM venimos trabajando hace un par de meses transformando nuestra aplicación Web Tradicional en algo más "RIA Oriented" y la verdad que fue un trabajo duro pero que viene resultando muy pero muy interesante, todavía estamos en el medio del testing y refactoring pero ya puedo decir que realmente es posible enriquecer una aplicación web con JavaScript, AJAX y CSS y sobre todo utilizando un excelente toolkit como YUI, ya que es una herramienta excelente, con mucha documentación, con una madurez y soporte increíble... podría estar escribiendo 5.000 líneas de lo bueno que YUI es y no creo que tenga mucho sentido, me parece que lo mejor en estos casos es buscar los puntos flojos para poder solucionarlos, y bueno, aquí van:

1. El excelente componente Connection Manager carece de llamadas sincrónicas (bloqueantes) y esto es más por un capricho del autor que por otra cosa (en mi humilde opinión). Está claro que no son tan importantes pero no cuesta nada dejar la posibilidad.
2. Todavía no tienen una solución para almacenar información del lado del browser y asi permitir construir aplicaciones RIA offline. Creo que este es un tema que hay que tener algo en cuenta ya otras tools como Dojo están un poco adelante.
3. Los componente son un poco duros para extender, si bien son bastante configurables muchas veces es necesario dejar puntos de extensión sencillos para poder agregar funcionalidad que todavía no traen. Alguno puede decir que JavaScript es un lenguaje prototipado que te permite extender y modificar el comportamiento en tiempo de ejecución y es verdad, pero muchas veces eso no es muy simple te hacer. Aca se puede hablar mucho más pero estoy con un poco de sueño :)
   
4. No provee una implementación para hacer Server Pushing o Comet y esto es algo bastante interesante a tener en cuenta. Justamente estas semanas estamos trabajando en esto pero estamos concentrados en el modelo de threads que hay que tener en el server poder enviar info al browser sin que el browser la pida. Actualmente estamos resolviendo el esto teniendo un client polling con una única conexión ajax por vez y con un time out relativamente largo (de 4 a 5 segundos aprox) como para que venga siempre con info del server.
5. Le faltan utilidades sencillas para manejo de JavaScript como tiene Prototype y JQuery, realmente es invaluable poder acceder a elementos del DOM utilizando el $, o agregar estilos de manera muy sencilla y obviamente sin perder portabilidad.

Antes de cerrar quiero destacar dos puntos importantes:

• esto es una critica totalmente constructiva a YUI desde mi humilde opinión. Vuelvo a repetir que de las herramientas que vi, y me recomendaron, es la que más documentación, soporte y madurez tiene.
• muchos de estos puntos débiles que he encontrado a YUI principalmente vienen por el lado de la integridad conceptual que quisimos lograr armando el framework en JavaScript ya que en un momento estábamos usando 3 tools diferentes y no era muy lógico. Actualmente estamos usando YUI y Prototype, pero calculo que próximamente la saquemos o pongamos JQuery que es un poco más liviana y hace cosas parecidas.

Esto es todo...

De paseo por Tandil

La semana pasada nos vinimos con mi familia a MDQ por unos 10 días y el Viernes pasado decidimos ir a Tandil , por un lado a pasear (ya que está a 165 KM de aca) y por otro lado a visitar y cenar con mis 5 compañeros de IBM que están estudiando en la UNICEN y trabajan desde Tandil ya que IBM nos regaló una cena a todo el proyecto (31 personas) y la gente de Tandil por no estar en Bs As no pudo asistir, asi que fui allá a replicarla. Aca están algunas de las fotos que sacamos:

Y luego de haber disfrutado de tandil estas son las actividades que hicimos y recomiendo hacer:

• Comer una picada en "Epocas de Quesos"
• Comprar fiambres para llevar en Syquet (Para la gente de IBM, Bs As... lo prometido es deuda)
• Cenar en Antares (Fue ahi donde comimos con la gente de IBM Tandil)
  
• Hacer todos los recorridos de Sierras (centinela, reserva del tigre, piedra movediza, etc) y Lagos (dique)
  
• La verdad que la ruta MDQ-Tandil es bellisima

Muchas gracias a Esteban Storch que me guió y me recomendó los lugares que arriba describí.

Comentario: How to spot the dreaded non-coding architect

Me encantó este post... sore todo me recuerda hace un par de años cuando el termino de Arquitecto se estaba poniendo de moda y todo se hacia en java y los "arquitectos" lo unico que hacien eran leer ariculos de SUN y Patrones.
Igualmente quiero hacer una salvedad.. si bien se puden detectar estos dos tipos de arquitectos, pero que nadie se olvide de la tercera categoría de arquitectos.... que esos si son los peores que ni se gastan en leer ni estandares, patrones,
buenas practicas.

Este es el link: http://softarc.blogspot.com/2007/06/how-to-spot-dreaded-non-coding.html

Resumen: (Could this be flamebait - probably! But here goes anyway)

By Architect here I'm not talking Enterprise level folk who pretty much don't cod

Aplicaciones RIA con JavaScript offline - Indignado

En estas ultimas semanas estuve un poco ocupado con el proyecto con el que vengo trabajando hace años en IBM, ya vo y a hablar un poco de todo lo que estamos haciendo con JavaScripts, AJAX, AHAH, JSON y CSS....
En este post solo quiero expresar mi indignación de como parece cierta parte de la industria (google con google gears, mozilla con firefox 3, etc) esta encarando el manejo de aplicaciones RIA con JavaScript para que puedan funcionar sin conexión a internet, debido a que apuntan a tener una base de datos RELACIONAL!!!! en el browser, nada más no nada menos... Mi humilde opinión es la siguiente
"Si ya tenemos nuestros objetos en un lenguaje potente como JavaScript (OO y Prototipado) por que no persistimos o mantenemos dichos objetos, para que meter una RDBMS en el browser?? Para que SQL??"
Estas son mis razones:

1. La gente se olvida de los problemas de transformar objetos en tablas y viceversa?
   
2. Estamos en el browser, o sea, vamos a tener como todo, objetos que solo tienen comportamiento y objetos que tienen estado y comportamiento, y objetos que solo van a tener estado, ese estado que estamos persistiendo va a terminar en otro modelos de objetos, como es el DOM, para que necesito pasar por SQL y Tablas? No nos alcanza con objetos??
3. Se olvidan de los problemas de performance ? o sea, una nueva capa en el browser que nos abstraiga de la persistencia de datos, ejemplo Google Gears, vamos a tener más comportamiento, más interacciones, más transformaciones de datos, más uso de memoria, con que sentido??? Ya están diciendo que Google Gears likea mal, te cuelga todo...
   
4. Se olvidan de los problemas de modificabilidad que esto trae? Ejemplo, se agrega un campo más a un formulario, lo cual implica, cambiar como mínimo 5 lugares entre el html, el javascritp, la validación, el objeto, la tabla, el sql, y sigo contando
5. La gente se da cuenta que van a tener que empezar a mantener dos bases de datos como mínimo? Las migraciones? Que onda los upgrades? Me parce que estamos equivocando el camino.
6. En Java, todo está apuntando a la transparencia, en donde todo debería ser más "simple", llegar a un nivel en el cual ni tengas que hacer un objeto.save(), por que en JavaScript tenemos que volver a conceptos arcaicos...
7. La gente se olvida que meter un modelo relacional en el browser obliga a perder las abstracciones que ya se pueden modelar con objetos en JavaScript, que pasa con el polimorfismo?? la herencia?, la posibilidad de agregar comportamiento de manera dinámica? Nos están obligando a separar los datos del comportamiento otra vez, pero esta vez sin ninguna razón
   
8. Que va a pasar con los tipos?? JavaScript no es Java, quizá se mas facil guardando todo en string, aunque no lo se, la transformación siempre cuesta y en este caso vamos a tener que definir mas cosas

Seguramente hay más razones, pero tengo que entrar en una reunión y tengo que cortar aca...
Espero que la gente no caiga en estoy y haya aprendido la lección del problema que tenemos hoy en día en el server para integrar un modelo objetos con un modelo relacional...

Igualmente voy a investigar un poco más, debe haber alguna librería javascript que nos permita algo más transparente sin tener que usar SQL, creo que dojo offline está apuntando por ese lado, y con independencia de método de persistencia.

Metodologías Agiles - Seminario Athenas - 25 de Junio

Abstract
Luego de 30 años desarrollando software, la industria sigue teniendo muchos problemas para terminar los proyectos en tiempo y forma. Durante ese tiempo evolucionaron tanto las tecnologías que utilizamos como los tipos de sistemas que construimos, sin embargo las metodologías parecen no haber sufrido grandes modificaciones. Con esa perspectiva, a partir de finales de los '90 surgieron algunas ideas que proponen renovar la forma en que construimos software y hoy comienzan a popularizarse a nivel mundial.
El objetivo de este seminario es introducir los conceptos que guían estas nuevas metodologías "ágiles", haciendo foco en dos de sus representantes más reconocidos: eXtreme Programming y Scrum.

La agenda es la siguiente:
19:00 hs: Presentación.
19:05 hs: Grandes personajes de la historia: Donald Knuth.
19:20 hs: Teoría e historia de las metodologías ágiles.
20:00 hs: Coffee break.
20:10 hs: eXtreme Programming. Conceptos y casos exitosos.
20:50 hs: Scrum. Conceptos y casos exitosos.
21:30 hs: Conclusiones y cierre

Video cómico de RoR vs Java

APIT en el SEI!

La semana pasada tuvimos un intercambio de mails con Paul Clements y uno de los primeros resultados de esto fue incluir, en la lista de (http://www.sei.cmu.edu/architecture/educators.html) Universidades que enseñan Arquitectura de Software, nuestra materia (APIT).

El segundo resultado estará por venir, pero les puedo adelantar que Paul se encontró interesado en el contenido de una de nuestras clases, la de "Rol del Arquitecto de Software", si bien el 40% del material no es nuestro el resto si lo es, por lo tanto creo que puede haber mucho fruto en el futuro.

Andres tuvo su primer encuentro nerd en APIT

Como todos los martes, nos juntamos con la gente de APIT, a discutir sobre las próximas clases. Ayer eramos pocos, así que lo llevé al chancho para que escuche y vaya aprendiendo de arquitectura de software. Así que para que vayan viendo, la calidad que van a tener las clases y presentaciones con la ayuda de Andrés, aca pueden bajarlas:

• Estilos Arquitectónicos (Garlan & Shawn)
• Tácticas para lograr atributos de calidad

La verdad que se portó muy bien, eso sí, cuando vino la picada, se desesperó y tuve que abrirle un danonino que se devoró y quedó pipon por un buen rato.

Al que posteo esto lo mataría - Diferencias entre C++/Java/C#

Los que me conocen, saben que el detalle extremo de las cosas me rompe un poco. Y este tipo de post me ponen frenetico por que nunca voy a saber la respuesta a menos que alguien me la diga.

http://www.bloggingaboutjava.org/cms/wordpress/2007/04/differences-between-c-java-and-c/

Ahora bien, ganas algo sabiendo dicha diferencia???, si igualmente tenes que tener el test case para verificar el comportamiento.

Hoy empiezan los seminarios athenas 2007 con un disertante de lujo

Venia notando hace tiempo que al seminario athena le estaba faltando un poquito más de difusión, por lo tanto doy mi granito de arena para que se conozca un poco más esta iniciativa que tuvo en estos últimos meses excelentes charlas y este año están planificadas muchas más.
Hoy arranca con Luciano Bello, alias "el taliban del software libre", sobrenombre puesto por Flavio Fernandez (alto groso del labsistemas también), la descripción de la charla la pueden encontrar acá.

Quilmes Rock 2007 en vivo por Internet

Está todo el mundo al tanto que el sitio 10Musica.com está transmitiendo el Quilmes Rock 2007 en vivo??? Ya lo habían hecho el año pasado con el Pepsi. La calidad de video y sonido no es del todo mala. Bueno, era eso, espero que puedan disfrutar de lo que queda, si lo leen antes de las 22, van a poder ver a los piojos ;)
http://www.10musica.com/micro_site/quilmesrock/home/envivo.php?idxBanda=0

El traspié de un grande - Almirante Irizar

En mi país todos los días se escuchan malas noticias que me hacen poner algo mal, pero hacer mucho que no me pasaba lo que me pasó cuando me enteré lo que pasó con el emblemático Almirante Julian Irizar. Desde que me enseñaron sobre este grande, en la secundaria, me generaba mucha espectativa poder verlo en acción, pero el día que lo vi anclado en el puerto de Bs. As. esos metros de largo y algo me dejaron con la boca abierta y con un orgullo de que mi pais pudiera contar con un rompehielos de esta envergadura para la expediciones a la antartida. Recuerdo que estuve con un amigo más de media hora observándolo e imaginándolo en acción.
Realmente espero que pueda ser remolcado y reparado para que siga permitiendo a mi país el uso de este emblemático rompehielos.

APIT - Primer Cuatrimestre 2007

Mañana, Jueves 22 de Marzo, empieza el primer cuatrimestre del 2007, no tengo idea cuanta gente se habrá anotado pero por lo que me vienen comentando hay varios, espero que así sea, cuanta más gente haya en el curso más divertido se pone.
Con respecto al programa, finalmente, hicimos una mezcla entre las supuestas dos materias y quedó algo como esto:

1-Metodologías Iterativas de Desarrollo

• Introducción a las metodologías orientadas a Iteraciones
• Metodologías Ágiles de Desarrollo
• Buenas prácticas para el desarrollo de software y la Arquitectura

2-Arquitectura de Software

• Concepto de Arquitectura de Software
• Tipos de Arquitectura y Ciclos de Generación de Arquitecturas
• Modelado y Vistas de Arquitecturas
• Principios de Arquitectura
• Requerimientos Funcionales, Restricciones y No Funcionales.
• Análisis de Atributos de Calidad y QAW (Método del SEI)
• Influencias de la Arquitectura
• Primera solución técnica y primera percepción de la arquitectura.

3-Creación de Arquitecturas de Software

• Tácticas para la lograr los Atributos de Calidad
• Estilos Arquitectónicos y Patrones de Arquitectura (POSA)
• Método de Creación de Arquitecturas ADD (Método del SEI)
• Organización de la Lógica de Negocio (Arquitectura no Intrusiva, Domain Driven Design, Transaction Script, Workflows, Aspectos y Declaratividad)
• Presentación (Tipos de Dispositivos y Clientes, Control y Navegabilidad, Integración con el Dominio o Lógica de Negocio, Clientes Pesados, Clientes Livianos – Web y Rich Internet Application)
• Persistencia (Mecanismos de Persistencia, Archivos, Base de Datos, Base de Objetos, Prevalencia, Frameworks de Persistencia y Impedance Mismatch)
• Integración (Business Integration, Point-to-Point, EAI, SOA, Colas, Web Services, ESB, Coreografia de Procesos)

4-Comunicación de la Arquitectura

• Concepto de Comunicación y Entendimiento de Arquitectura
• StakeHolders y Preocupaciones. ViewPoints, Views y Modelos IEEE 1470
• Workproducts y Deliverables de la Arquitectura
• Frameworks y Roadmap de Arquitecturas (Model View 4.1, The Open Group Architecture Framework)
• Armado del SAD
• Características de la documentación de la Arquitectura

5-Evaluación y Viabilidad de Arquitecturas

• En que consiste la evaluación
• Cuando y Por que.
• Riesgos
• Costos y Beneficios
• Métodos de Evaluación de Arquitecturas, ATAM (Método del SEI)

6-Implementación de Arquitectura y Rol del Arquitecto de Software

• Responsabilidades del Arquitecto.
• Rasgos y Características del Arquitecto
• Liderazgo y Mentoring
• Responsabilidades y Aseguramiento de la calidad del Arquitecto
• Propuesta de Solución y Evaluación Técnica incluyendo Estimaciones y Métricas
• Procesos de Construcción de Software
• Mantenimiento de Software.
• SCM

Como pueden ver, al programa es más o menos lo mismo que venimos dando, excepto que :
- sacamos un par de temas de metodologías, solo vamos a dar metodologías iterativas y ágiles
- agregamos el QAW, en la intro a Arquitectura, una manera muy interesante para relevar y priorizar los Atributos de Calidad
- vamos a dar el método del SEI, ADD (Architecture Driven Desing) como para guiar la creación de la arquitectura, voy a ver de invitar a alguien con experiencia utilizando dicho método.
- sacamos la clase de Arquitectura de Seguridad, debido a que vamos a hablar de seguridad como algo ortogonal a lo largo de toda la materia.
- Agregamos SCM
Con respecto a los integrantes de la cátedra, hemos perdido a una mente celebre como Hernan Liendo, ya que va a dedicarle a full a TADP y no va a poder dedicarle tiempo a APIT, por otro lado hemos un posible nuevo ingreso de Leo Gassman, de TADP, fue alumno en el 2005 cuando empezamos.
Con respecto a los TP, seguimos manteniendo el Paper, una investigación, y el TP Cuatrimestral en donde el grupo debe crear a implementar en código una arquitectura.
Para quien esté interesado de participar de oyente, vamos a dar clases todos los jueves en Medrano, pueden ver el calendario en el siguiente link, ahí lo vamos a tener actualizado.
Estoy muy contento debido a que en dos años de la materia ya nos estamos sintiendo cómodos en como va quedando y siento que estamos cumpliendo los objetivos que tuvimos cuando empezamos. Está claro que mucho tuvo que ver la incorporación grandes mentes como Nicolas Passerini, Gastón Coco, Juan Arias y Hernan Liendo.

Critico y Consultor - Rasgos y Características del Arquitecto de Software - Parte 4

Crítico y Consultor
Es muy importante como crítico la habilidad para tener una mirada fresca e imparcial acerca de su propio trabajo, separando las personas del problema, aceptando críticas y buscando feedback constante que puede venir de cualquier rol. Es más que importante tener la voluntad para reconsiderar y volver atrás si es necesario las decisiones tomadas. Con respecto al rasgo de consultor, es muy importante a la hora de la construcción es muy importante al soporte y la educación sobre la arquitectura, las revisiones y el feedback para un posible cambio. Agunas de las características que salen, podrían ser las siguientes:
- Busqueda constante de feedback
- Tener la capacidad de reconsiderar decisiones previamente tomadas en base a una crítica
- Educador de la arquitectura
- Revisor de la implementación, que cumpla con lo que la arquitectura define

Con esto termino esta serie de posts sobre los rasgos del Arquitecto de Software. Cualquier opinión y sugerencia va a ser bienvenida.