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.

Diseñador - Rasgos y Características del Arquitecto de Software - Parte 3

Diseñador
Este es uno de los rasgos diferenciadores, debido a que es sumamente necesario aunque no es suficiente. La creación o el diseño de la arquitectura es uno de las principales tareas del arquitecto a lo largo del proyecto por lo tanto es muy importante tener un criterio de diseño y evaluación de alternativas muy aceitado para poder articular dichas decisiones, utilización de principios y patrones, descomposición de módulos, alocaciones y sobre todos los trade offs necesarios para la construcción de la arquitectura. Quiero dejar claro que diseñar no es "documentar" en modelos, todo lo contrario, diseñar es la actividad de entender el problema y buscar a traves de las tácticas disponibles la mejor solución basadas, generalmente, en abtraciones, creatividad y reuso de soluciones anteriores (patrones). Las características asociadas al diseño las podemos catalogar de la siguiente manera:
- Creatividad, a la hora de buscar alternativas para solución de problemas y decisiones necesarias.
- Conceptualizador, esto está muy relacionado con los modelos mentales y la visión del arquitecto, pero básicamente es necesario entender el problema antes de tomar decisiones, y que la conceptualización esté lo mejor posible (que terreno pantanoso me he metido)
- Modelador, en esta característica está en juego la conceptualización (punto anterior) donde modelamos para representar la realidad (negocio, recursos, etc) y por otro lado la comunicación de lo decidido, aca se mezcla con lo que hablamos en el rasgo de traductor.
- Colaborador y Moderador, colaborar a la hora de resolver problemas y moderador para generar consenso en una reunión y búsqueda de compromiso, ya que es muy común tener reuniones con diferentes tipos de stakeholders y generalmente las decisiones son tomadas en un contexto donde la arquitectura es el centro o guía dicha decisión.
- Comunicador de conceptos y modelos.
- Perspectivas, es la habilidad para ver un problema y plantear diferentes soluciones y en cada una de ellas poder ver que impactos va a tener en el corto, mediano y largo plazo. Para este punto en particular recomiendo mirar la siguiente página de un método llamado, "análisis basado en perspectiva"

Traductor - Rasgos y Características del Arquitecto de Software - Parte 2

Traductor
Este es uno de los rasgos que más pongo énfasis durante la cursada de la materia, a la hora de comunicar el conjunto de decisiones que van materializando la arquitectura necesitan ser comunicadas y consensuadas con todos los stakeholders, no pueden ser presentadas de la misma manera, ni con el mismo lenguaje, ni con los mismos modelos a todos, el arquitecto debe asegurarse que cada tipo de stakeholder entienda la vista de arquitectura que tiene que entender con el lenguaje correcto, por lo tanto el arquitecto debe tener las siguientes características asociadas:
- Poliglota / Multi-lingual, para poder comunicar la misma arquitectura a diferentes stakeholders que poseen diferentes lenguajes.
- Analista, es importante estár al tanto del contexto que cada stakeholder se encuentra, que preocupaciones (concerns) posee.
- Capacidad de síntesis, esta característica puede ahorrar mucho tiempo en las reuniones del arquitecto, pudiendo guardar tiempo para otro tipo de actividades, esto no quiere decir ocultar nada sino comunicar lo justo y necesario.
- Generalista, el arquitecto debe ver siempre la "Big Picture", debe concertarse en las decisiones que guían la construcción de la aplicación trabajando y comunicando abstracciones, los detalles hay que dejarlos para los analistas del negocio y diseñadores/programadores.
- Identificar qué es lo relevante, qué tiene impacto que no, clasificar y priorizar
- Alta tolerancia a la ambigüedad, esto puede ayudar mucho a acortar el tiempo en las reuiones, las abigüedades son sanas, siempre y cuando no haya buena fe en el entorno de los stakeholders, pero mi recomendación es no invertir tiempo en discusiones que no aportan al proyecto, si un administrador de SCM le dice robustez a la latencia (response tiem), todo bien, no hay que enseñarle en medio de una reunión que lo que dice está mal, lo importante es poder manejar esa ambigüedad tener bien claro de que se está hablando, no discutamos temas de nomenclatura, lo que importa es el significado (Como dice Nico Passerini).
- Mentalidad abierta, esto no es exclusivo del arquitecto de software, aunque lamentablemente muchos cerecen de esta característica :(

Visionario - Rasgos y Características del Arquitecto de Software - Parte 1

Visionario
Ser Visionario para un arquitecto es poder definir esa idea de arquitectura, comunicarla y generar el compromiso para cumplirla. Para poder tener siempre esa visión y alinear al resto de los stakeholders es importante cumplir con las siguientes características:
- Escucha Activa, para el correcto entendimiento del negocio y las posibles críticas a las decisiones del arquitecto.
- Comunicación verbal, no verbal, oratoria y capacidad para modelar.
- Sagacidad Política, tengo que preguntarle a Gastón bien por que es esto, suena lindo.
- Liderazgo para la creación del team de desarrollo, movilización y motivación del mismo alineándolo detrás de la visión.
- Carisma para poder alinear al team detras de la visión (de la arquitectura a construir). Y es por eso que el carisma es tan importante en un Arquitecto, es ese grado de atracción y desenvolvimiento personal que permite agrupar y convencer personas para lograr algo, en este caso, para sumarse a la abstracción que el arquitecto propone construir.

Rasgos y Características del Arquitecto de Software

Hace un par de años, cuando arrancó la materia con Gastón Escobar definimos una serie de rasgos o características que debía tener el arquitecto de software, obviamente excluimos los temas técnicos y más que nada apuntamos a los skilles interpersonales y de liderazgo que todo arquitecto de software debería tener o intentar desarrollar, aquí los explico más detalladamente, separando en 4 posts:

• Parte 1 - Visionario
• Parte 2 - Traductor
• Parte 3 - Diseñador
• Parte 4 - Crítico y Consultor

Tagged

Leyendo el Blog de uno de mis mejores alumnos de APIT, Adrian Alonso (de quien espero que actualice su blog más seguido), me dí cuenta que me taggeo para que cuenta cinco cosas de mi que pocos conoce, por lo tanto aquí van:

• Muchos saben que me recibí en la UTN de Ing. en Sistemas, lo que nadie sabe es como llegué ahi. Como varios adolecentes, en la secundaria, estudian solo para zafar y pasar un buen momento, pero no era el caso de Ezequiel Issa, digamos, el Nerd de la clase al cual todos acudiamos a la hora de copiar la tarea que no habiamos hecho el día anterior, una muy buena persona que vivia para el colegio. El tema fue así, un Jueves de Agosto (1998), sentado al lado de el, obviamente, tratando de careatear la copiada de tarea y haciendome el amigo, le pregunte, "Che Hugo (por que le deciamos así), que vas a estudiar el año que viene, estamos en quinto año??" Y me dijo muy seguro, "Y mirá, a mi me gusta la computación, así que voy a estudiar en la mejor facultad de computación de la argentina, la UTN"?, "UT que????", le pegunté, y bueno, despues de contarme un poco sobre la facultad me convenció, no teniamos mucha idea de que era Sistemas, pero si que tenia que ver con la computadora, al otro día fui a anotarme, por que estaban llamando por apellido en esa fecha y desde 1999 al 2004, estuve estudiando en mi amada universidad, obviamente que al tiempo me dí cuenta que Sistemas no es Computación, por suerte, por que al ir entendiendo los Sistemas de Información me fui apasionando cada vez más, si hubiese sido una carrera de Computación, estoy seguro que no la hubiese terminado... ahora bien, que pasó con Ezequiel Issa?, al tiempo me lo encontré en el Laboratorio de Sistemas, creo que todavía sigue estudiando, creo que está por cuarto año..... Gracias Hugo!!!
• Tengo 3 hermanos, Gastón y María Victoria mayores (del matrimonio anterior de mi viejo) y una hermana llamada Barbara un año más chica que yo. Con Barby hablo todos los días y con los más grande, de vez en cuando, aunque me gustaría estar más en contacto.
• Hace unos meses que empecé a jugar al tenis, todavía no con profe, y el otro día, jugando al tenis con mi mujer en MDQ, sacando para el Set, maté un pajarito, si aunque no lo crean, una en un millon, vi cuando la pelota despedida de mi raqueta impactó en la cara el pajarito, y este cayó haciendo circulos en el aire, de no creer, todos los jugadores de otras canchas vinieron a ver la escena del crimen :)
• Desde que nací vivo en Buenos Aires, Villa del Parque principalmente y actualmente en Palermo, pero me encantaría poder vivir en una ciudad mucho más tranquila, como Mar del Plata (aka MDQ), creo que no es el momento, pero si lo tengo muy en mente principalmente pensando en la calidad de vida de mi(s) hijo(s), por ahora tengo uno pero me gustaría tener una más, a quien vamos a llamar Luz Brey, en caso de que salga nene y económicamente/sentimentalmente estemos preparados buscaremos otra vez :), no más de tres.
• Suelo ser muy tolerante con las personas y confio en la gente, pero lo que no puedo soportar, tanto en ambiente laboral como en lo personal, es la soberbia y la mentira, me general mucha bronca la gente que posee alguna de esas dos características y puedo ser muy duro (a veces desconozco mis actitudes con ese tipo de gente), debe ser por que siempre intento ser lo más transparente, sincero y humilde posible....
  

Ahora es mi turno de "taggear", y lo voy a hacer a: Gastón Escobar, Marisa Espinosa, Luciano Bello, Mercedes Caracotche, Gonzalo De Pedro (Gona) y Nicolas Passerini, espero que estos últimos dos publiquen su blog pronto...

Design & Programming Trends

Debido que en las próximas dos semanas recibimos visitas a IBM Argentina de India (1) y USA (3) para llevar a cabo unas sesiones de diseño y arquitectura para la nueva release del proyecto, me tomé el tiempo de poner a todo el team "on top" de las últimas tendencias (patterns, principios, tecnologías, etc) en lo que refiere a diseño y programación. Básicamente son las cosas que se vienen utilizando y desarrollando en la industria y tiene mucho sentido tenerlas en cuenta.
El mail lo mandé en ingles, pero bueh, cuando tenga un rato lo traduzco :) (mil disculpas para quienes no entiendan el idioma o mi ingles ladri)

• Test Driven Development has become as one of the best design technique and was the most acceptable XP practice. (plus Refactoring). UI Arg team had great result using it during R2. I have also gave a 2 hours course about it here. Finally I have also hear about Behavior Driven Development, it is a step beyond TDD.
• Inversion of Control Design Principle and Dependency Injection Pattern had become de facto technique to deal with dependencies and object life cycle. Spring Framework is example of how important is this technique. During R2 We were implementing IoC in some part of the UIFramework.
• Ruby On Rails web framework has impulsed a revolution against Big-Complex-HardToUse-HyperXMLConfigurable Java Web frameworks, Ruby On Rails gives different approach for Web Development, using principles like "Convention Over Configuration", "AJAX is part of the framework", "Flash Memory Context" and "Easy and Rapid web development"... those are important concepts, many Java Frameworks have been introducing something similar to RoR, i.e. Rife, Grails, AppFuse, Trails, xFramework, etc.
  
• Domain Driven Design (DDD) is a technique that reinforces the use of Object Oriented Design to solve domain problems and complexity.
• Web Flows this kind of frameworks allows to implement continuation concepts that gives the ability to keep track on double submitions and back buttons.
• RIA - Rich Internet Applications (AJAX).
• Defensive Code / Design By Contract. I think that we have to insist on this principle, mainly with Dependencies, there are interesting ways to solve this with Aspect Oriented Programing or using annotations (with Java 1.5)

Tengan en cuenta que es un Team de UI, por lo tanto está un poco acotado.

Se les ocurre algo más?