domingo, febrero 25, 2007

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:

domingo, febrero 18, 2007

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...

jueves, febrero 01, 2007

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?

Es la Robustez un Atributo de Calidad?

Hace unas semanas, Juan Pablo Picasso (Socio de Andina Software y Profesor de TADP) envió un mail a una lista iniciando una discusión sobre que realmente es la Robustez. En este post explico lo que para mí es la robustez y por que.

Me inclinaría por una definición como la siguiente para la robustez:

"Es el grado de percepción/sensación que da una aplicación para responder a eventos no contemplados o que exceden los requerimientos no funcionales y que su respuesta permita medirse en parametros calculables, o sea, no ocurra un desastre"

No estoy seguro si se entendió, pero me gustaría dar algunos ejemplos. Si tenemos un NFR de Performance como el siguiente

"El sistema debe poder responder a 1000tx por Hora con un tiempo de respuesta menor a 5 segundos para las transacciones Tx1 y Tx2",

Podríamos pensar en que la robustez entraría en juego en casos en los cuales si hay 1001tx por hora el sistema responda de manera aceptable y que no se caiga Obviamente podriamos pensar que no se va a cumplir con los 5 segundos, pero tampoco que no se cumpla por mucho, o sea, que responda en 6 o un poco más... se entiende el ejemplo?
Lo mismo pasa con la robustez para los Atributos de Calidad No runtime, en donde vos tenes algun NFR de modificabilidad definido, por ejemplo:

"El sistema debe permitir la modificación de parámetros la interfaces X e Y a pedido del usuario y debe ponerse en producción en un tiempo de 40 días, incluyendo el analisis, diseño, desarrollo, testing y deploy",

Y si te llega algún Change Request, que pide dentro de la modificación de parámetros de las interfaces X e Y, y aparte agregar una exception, como notaran, la exception no está contemplada, en este caso la robustez entra en juego por el lado de esa misma sensación de que si no la habias contemplado el cambio se puede realizar bajo parametros decentes.

Por la tanto ya sea para Atributos de Calidad Runtime y No Runtime la robustez se podria pensar como ese grado de sensación ortogonal a cualquier tipo de Atributo de Calidad que mide el grade poder responder con parámetros decentes.

Esta es una conclusión personal después de haber discutido con varios profesionales sobre este tema. Principalmente con Gonzalo De Pedro y Nicolas Passerini.

Opiniones?

lunes, enero 29, 2007

SOA Bootcamp - Día 4

Jueves 18, ultimo día del Curso. El día anterior estuvimos todos comiendo en Rodizio, invitación de IBM, la verdad que la pasamos muy bien, no faltó casi nadie. Ali se comprometió a dar un feedback del curso en Argentina en su blog, vamos a ver lo hace. Ya tambien me comprometí a traducir los conclusiones del primer día, no puedo ser tan vago. Durante todo el día lo que estuvimos viendo principalmente es SOMA V3.0, que aun está en beta, recuerdan? El gran cambio en esta nueva versión es que SOMA pasa a ser una metodología de desarrollo de proyectos SOA End2End. Incluyendo etapas de implementación, testing, deploy y mantenimiento. Digamos que fue una unión entre SOMA y RUP. Todavia está bastante verde y necesita muchos reviews, pero creo que se va clarificando bastante, es más dentro del curso Ali nos preguntó bastante sobre algunos puntos que no le gustaban como estaban hechos y tomo nuestros comentarios, calculo que en la versión final estén nuestros inputs. Lo que si, le pedí por temas de "mejor entendimiento" que la "M" de SOMA, deje de ser "Modeling" y pase a ser "Method" o "Methodology" ya que trae a confusión, a Ali le gustó la idea y dijo que lo iba a proponer :) En este post de Ali se explica muy bien el cambio de SOMA en la nueva versión.

Otra de las cosas que estuvimos charlando fue de un plug-in que desarrollaron para un nuevo producto llamado, Rational Method Composer, dicho producto permite armar modelos de desarrollo, detallando el ciclo de vida, los work products, entregables, dependencias y papers, entre otras cosas, con lo que al final de dicho trabajo podes exportar a MS Project o RPM (ational Porfolio Manager), el plug-in que desarrollaron es un template para la metodología SOMA. Con el cual podes crear tu WBS desde dicho templeta y customizar de acuerdo a las necesidades y restricciones del proyecto.

Y por ultimo dio un panorama muy pero muy por arriba de SOMA Modeling Environment for RSA, que es un plugin para el RSA que permite organizar el modelado y documentación de la arquitectura y diseño en proyecto SOA. Este si está muy verde ya que quieren migrar a la nueva versión del RSA, la 7.0 que está basada en eclipse 3.2.

Esto es todo, espero que les haya interesado.

lunes, enero 22, 2007

SOA Bootcamp - Día 3

Miercoles 17, con algunas caras cansadas, sobre todo la gente de Uruguay y Venezuela, ya que estuvimos tomando unas cervezas el día anterior y para cuando yo me volví todavía quedaban algunos tirando tiros en la cigale.
Durante la primera hora Ali estuvo hablando sobre algunos SOA Patterns, básicamente todos los que se desccriben en el "Design SOA Solutions and Apply Project, Technical, and Operational Governance (SW718)", Proxy Interaction Patterns, Remote Strategy Pattern, Enterprise Service Bus pattern y Service Registry pattern. Digamos que los más interesantes son los úlimos dos. Los primeros si bien son muy usados son un sub-conjunto del ESB Pattern. Una de las cosas que comentó Ali, fue que IBM fue la primer empresa en hablar de un ESB como un estilo arquitectónico, yo lo recuerdo, esto era por el 2004, pero tambien sabia que en algún momento iba a salir el Websphere ESB, y obviamente ese producto llegó ;)
El segundo tema fue, SOA Architectural Reference (S3), este es uno de los temas más interesantes del curso, básicamente es la arquitectura de referencia de todo proyecto de integración implementando SOA. Esto ya lo habia leido en un paper que me llegó hace un tiempo y realmente es muy interesan, muestra con lujo de detalle todas las capas, elementos, componentes e interacciones que pueden aparecer en una integración con SOA. Para describir un poco esta arquitectura de referencia, transcribo la explicación "literalmente" de un post del blog de Ali en DeveloperWorks (se pueden ayudar de la imagen):

These layers are:

1. Consumer layer - any consumer of a service would reside in this layer
2. Business process layer (choreography and composition)-- a process uses a set of loosely coupled services in a choreography or composite application
3. Services layers -- a layer of service descriptions and policies, implemented through
4. Service Components -- (e.g., EJB's or .NET components) who privide the actual realization of the service operation, or the service directly uses or exposes
5. Operational Systems and Data -- which include packaged applications like SAP, Siebel, PeopleSoft (Oracle), Legacy systems, and of course the data bases that support the applications.

Cross cutting these functional layers are the operational layers that support and intersect the above:

6. Integration Layer -- if you need/have an ESB it's here
7. Quality of Service layer -- all, aspects of security, monitoring, management and all other quality of service aspects are implemented and ensure through this layer
8. Data Architecture, Business Intelligence and meta-data layer -- provides data models, star cshemas or meta-data relating to and supporting the SOA
9. Governance Layer -- includes the procedures, processes, registry , repository and run-time governance needed to servce as support for the entire life-cycle


Durante la tarde estuvimos viendo las capas "cross-cutting" que se ven en la figura, de la 6 a la 9:
El tercer tema del día fue SOA Governance, si bien fue un poco abstracto y generalista, se pudo entender que significa el tema. Básicamente apunta de dictar las normas a nivel organizacional de como se van a integrar las aplicaciones, es como el gobierno en una ciudad, bueno pero esto es en un empresa, buenas normas de IT Governance aseguran una correcta implementación de los sistemas, obviamente si se siguen. Esta sería la herramienta fundamental para el Enterprise Architect.
Seguimos con SOI (Service Oriented Integration) y ESB (Enterprise Service Bus), si bien fue bastante corta, se pudo revisar en detalle cada uno de los temas, más adelante voy a explicar un poco más estos conceptos.
El siguiente tema fue QoS (Quality of Service), digamos que para mi gusto no fue lo esperado, solo explicaron un poco de Monitoreo, Logs y algunos productos que soportan. Faltaron conceptos un poco más arquitectónicos como tácticas para lograr performance, disponibilidad, tolerancia a fallos, etc...
Creo que habló un poco de Data Architecture, aunque no estoy muy seguro, si encuentro algo de info la voy a compartir.

Lo más interesante de este día, obviamente, fue el SOA Architectural Reference, ya que es el template que tendríamos que seguir para construir arquitecturas de integración SOA.

SOA Bootcamp - Día 2

Martes 16, con Ali recién llegado de USA, continuamos con el curso.
El primer tema que estuvimos viendo fue SOMA, la versión 2.4, básicamente esta versión es una técnica de análisis y diseño de servicios dentro de una arquitectura SOA, aca tienen una descripción más detallada de SOMA 2.x. La técnica tiene 3 fases principales, Identificación, Especificación y Realización, en cada fase se tomaban decisiones y es algo bastante iterativo a lo largo del proyecto.

Luego estuvimos viendo los tipos de soluciones que IBM (SOA Offerings) tiene para ofrecer a sus clientes en lo que refiere a SOA, siempre desde el punto de vista del Servicio/Cosultoría/Desarrollo, nada de Software IBM. Algunos ejemplos que recuerdo eran para SOA Governance, integración a través de servicios, Evaluación de la madurez SOA en la empresa (SIMM), etc. La verdad que hay varios offerings y no se que tan confidenciales sean, la idea era mostrar de que manera IBM ofrece sus servicios para la implementación de SOA en las empresas.

El último de los puntos que estuvimos viendo, aunque un poco aburrido, fueron todos los estándares sobre Web Services, como WSDL, SOAP, BPEL, UDDI, etc. Digamos hubo dos cosas bastante interesante que me dejó esta parte del curso con respecto a los estándares:
1- Esto no lo sabía de bruto que soy, WSDL 1.x tiene una sección en donde se puede especificar el tipo de bindding tecnológico en el cual se debe acceder al servicio, ejemplo, si es por SOAP-HTTP, SOAP-JMS, EJB-IIOP, POJO o lo que sea. Yo pensaba que esa sección venia solo a partir de WSDL 2.
2- Teniendo el punto 1 claro, surge una pequeña discrepancia en la industria en el entendimiento de Web Servicies, ya que para MS y otros un Web Service implica el uso de WSDL, SOAP y HTTP, con lo cual está recortando la posibilidad que nos dá el WSDL para extender el bindding. IBM dice que para llamar Web Service a un servicio solo tiene que ser expuesto a través de WSDL, con lo cual, desde mi punto de vista, suena más lógico... de este modo para IBM, SOA implica el uso de Web Service.
Esto fue todo en el segundo día del curso.

martes, enero 16, 2007

SOA Bootcamp – Día 1

Luego del primer día del Bootcamp, me dí cuenta que lo mejor del curso es el grupo de arquitectos que fueron convocados, es un nivel excelente. Como ya les comenté, vinieron arquitectos de Argentina, Uruguay, Perú y Venezuela, tengo que decir que el nivel técnico es genial.
Durante el primer día fue todo muy introductorio, sinceramente no hubo nada que no haya leído antes, aunque lo más enriquecedor de todo fueron las discusiones (más 3 horas entre tema y tema charlando entre nosotros) e intercambios de ideas que hubo entre todos nosotros, pude sacar una serie de conclusiones:
  • Hablando consensuamos, según la experiencia en cada país, que la industria (clientes) cuando piensa en SOA solo ve la parte tecnológica y no como una estrategia que debe tomar la Enterprise Architecture para guiar la integración de aplicaciones. Por lo menos es lo que pasa en America del Sur, no ve el valor que tiene como la flexibilidad, adaptabilidad y reusabilidad.
  • Quedó claro que los productos que soportan SOA, (ejemplo ESBs, BPMs, Registries) todavía están muy inmaduros. Supongo que en algún momento van a madurar.
  • El ESB en SOA = EAI.
  • SOA NO es Web Services, tener una arquitectura SOA no quiere decir que vas a usar Web Services, y que tengas WS tampoco quiere decir que implementas SOA.
  • La nueva especificación de WSDL debería ser sin la W, o sea, SDL (Service Description Language)
  • EL discovery dinámico de Servicios por el momento no tiene sentido. Discutimos que este podría empezar a usarse cuando la Web Semántica gane más adeptos y esté mas madura, con protocolos como RDF, WS-Agreement, etc.
  • Uno de los grandes problemas para implementar una arquitectura SOA es el uso indiscriminado de SAP en la compañía. Esto no quiere decir que está mal, sino que cada empresa tiene los drivers arquitecturales que su EA guía. Pero es cierto, cuanto más funcionalidad tiene SAP menos procesos de negocio se van a poder estandarizar y flexibilizar.
Si bien muchas de estas cosas ya las venía discutiendo con Gastón Escobar y Fernando Sanabria en Argentina, estuvo bueno poder exponer ese tipo de ideas y consensuarlas con otros arquitectos con experiencia en proyectos SOA. Calculo que el curso se va a poner más interesan mañana cuando Ali de los temas que no conozco en profundidad.
Si tienen alguna pregunta interesante sobre SOA… adelante!

sábado, enero 13, 2007

Viaje a Bs As - SOA Bootcamp

Mañana Domingo, a las 8:30 hs, tomo un ómnibus a Bs As, interrumpiendo mi mes de vacaciones debido a que Ali Arsanjani, Chief Architect SOA de IBM a nivel mundial viene a la argentina dar un curso de 4 días (completos) sobre SOA, SOMA, ESB, Web Services, SOA Governance, SOA Patterns, etc...
La verdad que estoy muy contento y tengo muchas expectativas, ya que vengo participando de muchas calls/webconference de Ali y también leyendo su blog, y verdaderamente es un profesional que tiene mucha experiencia en el tema, y por comentarios de Gastón Escobar que lo conoce personalmente, es una persona muy copada y abierta.
Si bien, muchos de los conceptos ya los he leido, lo más interesante van a ser las discusiones que se van a generar ya que en el curso van a participar varios arquitectos de Argentina y america del sur.
Les voy a tener más novedades!

viernes, enero 05, 2007

Blogs que suelo leer (Geek Blogs)

Les voy a detallar los Weblogs que suelo leer sobre Arquitectura, Java, JavaScript, Ruby, RoR, Diseño, Metodologías, SOA, Programación y software en general. Todos excepto uno (Luciano Bello) son en ingles.

también les voy a adjuntar el archivo exportado de mi Reader (RSSOwl), quien use el mismo reader puede importarlo tranquilamente.

Hace mucho que quería hacer esto, pero por una cosa o por otra no lo hacia, hoy me puse las pilas tiré un par de lineas en Ruby (4 exactamente) y generé el HTML parseando con un RegEx muy muy pedorra el xml que exporta el RSSOwl, asi que aca está.


Carol Jones
Autor : Carol Jones
Comentario : Es Fellow de IBM, la tiene muy clara con Web2.0 y herramientas de colaboración. No actualiza mucho el blog

Bill Higgins
Autor : Bill Higgins
Comentario : Es un grande, sabe mucho de RIA/AJAX y más también, es el típico Geek que cuando habla de tecnología se le debe caer la baba ;)

Ali Arsanjani
Autor : Ali Arsanjani
Comentario : Un groso de IBM, en teoría es la persona que más sabe de SOA en IBM, pronto lo voy a conocer personalmente ya que va a venir a un curso en Argentina. No actualiza mucho el blog

Enterprise Integration Patterns: Gregor's Ramblings
Autor : Gregor Hohpe
Comentario : Debe ser uno de los que más sabe de integración, actualmente trabaja en Google, escribió el mejor libro de EAI que existe hasta el momento en conjunto con Bobby Wolf. No actualiza mucho el blog

Loud Thinking - DHH
Autor : Loud Thinking - DHH
Comentario : Un groso, creador del framework Web Ruby on Rails, con solo 26 años...

luciano's blog
Autor : Luciano Bello
Comentario : Un loco lindo... aparte de leer su blog, lo conozco bastante. Es un excelente escritor y Taliban del software libre, no tiene que ver mucho con mi palo pero es interesante leer sobre su experiencia sobre developer de Debian y más

.: Manageability :.
Autor : Carlos E. Perez
Comentario : El mejor Blog de todos, habla sobre Diseño, Arquitectura y Programación, escribe muy bien y actualiza muy seguido.

Martin Fowler's Bliki
Autor : Martin Fowler's Bliki
Comentario : Que puedo decir, es uno de los mejores escritores sobre Arquitectura, Metodologías, Diseño y Programación, si bien actualiza muy seguido aveces me pone frenetico

Grady - Handbook of Software Architecture
Autor : Grady Booch
Comentario : Que puedo decir de Gardy?, un grande, tambien Fellow en IBM, actualiza seguido y te mantiene al tanto de lo que pasa en el software en general, no baja para nada al detalle.

Joel on Software
Autor : Joel Spolsky
Comentario : Excelente escritor y gran técnico. Me gusta leer mucho su blog tiene algunos post que hasta se publicaron en libros. Es el blog de software más leido en todo el mundo

Venkatesh Krishnamurthys Architecture NotesNA
Autor : Venkatesh Krishnamurthys
Comentario : Le acabo de agregar me gustó el título y un par de post.

developer.* Blogs
Autor : developer.* Blogs
Comentario : Son muchos desarrolladores en general actulizan seguido y hablan de Diseño, Arquitectura y Programación en general

Paddle Like Hell
Autor : Bruce Tate
Comentario : Un excelente escritor exhiliado de Java y ahora evangelizador de Ruby y RoR. Me gusta mucho su manera de escribir y hablar. Publicó muchos libros y una excelente serie en developerWorks llamada "Crossing Borders"

Artima
Autor : Varios
Comentario : Al igual que .Developers, son varios que postean, aunque ultimamente está bajando la cantidad y calidad de sus post, el sitio es muy interesante. Diseño y Programacion.

Blog Blah Blah Architecture
Autor : Mario Cardinal
Comentario : A este blog llegué despues de escuchar muchos de sus podcast que estuvieron geniales, aunque el blog se actuliza muy poco a veces postea cosas interesantes de arquitectura y tecnología. Aunque a veces los post son Francés

Michael Feathers' Weblog
Autor : Michael Feathers
Comentario : Un groso! Es el autor de uno de los mejores libros que leí "Working Effective with Legacy Code". Aunque ultimamente no postea mucho, hay que tenerlo siempre ahi. Ya que cuando postea, la calidad es increible. Mucho de Diseño y TDD

Andi's Blog
Autor : Andy Hunt
Comentario : Creador de la serie de libros "Pragmatic Programmers", con eso digo todo :). No actualiza mucho su blog

The Pragmatic ArchitectNA
Autor : Varios
Comentario : Recien lo acabo de agregar, el título y algunos post me gustaron

DaveAstels.com
Autor : Dave Astels
Comentario : Creador del framework rSpec para BDD en Ruby, me gusta como escribe y publicó uno de los mejores libros de TDD. Ultimamente con la salida del PSIII y Wii no para de postear sobre eso, con lo cual su blog está decayendo mucho.

PragDave
Autor : Dave Thomas
Comentario : Creador de la serie de libros "Pragmatic Programmers", con eso digo todo :). No actualiza mucho su blog. Antes generalmente hablaba de TDD y Ruby/RoR

ambysoft at Yahoo! Groups
Autor : Scott Ambler
Comentario : IT Architect de IBM y excelente escritor, publicó millones de libros, aunque por ahora no leí ninguno de el, tengo en mi backlog de libros varios para arrancar. Generalmente hablar de Aruitectura, Metodologías y Diseño. Lo malo del blog es que no baja el contenido en el RSS, tenes que entrar si o si por web y con user/pass

Mike Does Tech
Autor : Mike Pence
Comentario : Programador independiente que la tiene muy clara con Ruby/RoR, tiene muy buenos posts

Java Competence Centre LogicaCMG
Autor : Varios
Comentario : It's all about Java Technology! No actualiza muy seguido.

Joe Walker's Blog
Autor : Joe Walker
Comentario : Creador de uno de los frameworks mas interesante de AJAX llamado DWR. Me gusta mucho como escribe y está on top de toda la tecnolgia AJAX, la verdad que la tiene muy clara, habla mucho de diseño, arquitectura de UI y programación.

Agregarían alguno/s más?

miércoles, diciembre 27, 2006

Transcript del Chat sobre AJAX en developerWorks

Hace un par de semanas participé de un chat público sobre AJAX que hosteo Bill Higgins en developerWorks, la verdad que estuvo muy bueno, y como todo lo bueno... se termina muy rápido. El chat contó con presencia de grandes eminencias del software como Grady Booch (uno de los creadores del UML entre otras cosas). Tambien participaron desarrolladores y líderes de frameworks y tools muy interesantes como de Dojo y AFT (Ajax Toolkit Framework). Aca les dejo el transcript que les puede resultar interesante se charló principalmente de:
  • Dojo
  • DWR (Direct Web Remoting)
  • AJAX and REST integration
  • Accessibility
  • Eclipse ATF
  • AJAX Maturity
  • JSON as data interchange mechanism
  • Open Laszlo and Dojo integration

jueves, diciembre 21, 2006

Impacto de Clientes RIA en los Atributos de Calidad


La semana pasada dimos una charla en IBM sobre Rich Internet Application en general, describiendo un poco de que se trata este nuevo tipo de cliente, desde una visión arquitectónica. Tambien pasamos por las tecnologías disponibles para crear RIA, JavaScript/Ajax, Flash (Flex y OpenLazslo) y Browser Objects. Uno de los puntos que más me interesó armar fue el del impacto que tienen estos tipos de clientes en los atributos de calidad.
Debido a que la charla no era sobre esto, no pudimos bajar mucho a detalle, asi que les dejo algo de lo que pudimos armar:
Performance
  • Better latency because of less data interchanged
  • May decrease bandwidth
  • Delta processing on Server Side (More CPU Cycles)
  • Stateful applications, needs more memory to keep screen on server side
  • Needs more resources on Client Side, processing (renderization) and screen state (memory)
  • More than one transactions could be triggered at the same period of time, so more resources on server we will needed to support it
  • Start Managing concurrency on Browser Side
Usability
  • Improve users experiences
  • Adapting the system to user needs and Personalization
  • Support more input events
  • User has the control
  • RIA allows GUI Effects on a browser (i.e. drag & drop, real progress bar, etc)
  • Interactive applications
  • Partial reloading
  • Reverse AJAX concept, Server can update the screen
Portability
  • Cross browser compatibility
  • Operating System portability (I.E. Flash 9 was not supported on Linux Desktop)
  • W3C Standards
  • Open Ajax Alliance (http://www.openajax.org/)
Accessibility
  • Use of Images (SVG) and Media (RDF) contents
  • Access Keys
  • GUI Effects
  • Event Handling
  • Partial update
  • XForm and XHTML2
  • Web Accessibility Initiative for Rich Internet Application (http://www.w3.org/TR/aria-roadmap/)
En algún momento me gustaría escribir un paper sobre esto y sobre los otros atributos de calidad, algún comentario?? cosas para agregar??

miércoles, diciembre 20, 2006

martes, diciembre 19, 2006

Software Estimation: Demystifying the Black Art


Me acaban de regalar este, tan esperado, libro de Steve McConnells!!!!! Todavía no lo puedo creer, este fue uno de los mejores regalos de este cumpleaños!!! Lo hizo uno de mis mejores amigos, Muchas gracias Gastón Escobar!!!!!. Este podría ser el libro que marque un punto de inflexión en la ingeniería en software y para dejar de pensar y utilizar métodos rusticos y artezanales en la estimación de software. Aunque no tengo espectativa alguna que leyendo este libro me estimar un proyecto de gran embergadura (con más de 6 ceros a la derecha, sin tener los requerimientos claros y plazos de 2 años), ya que creo que ese no es el objetivo del libro y aparte no es mi estilo de construir software...
Tengo la plena confianza que Steve debe haber creado una excelente obra... como ya ha hecho, tal es el caso de Rapid Development, biblia de la ingeniería en software. Por suerte tengo tiempo y muchas ganas de leerlo, calculo que para febrero lo voy a terminar y dar un feedback a todos los que tengan ganas de leerlo. Este libro es bastante nuevo, ya que salió en marzo de este año (2006).

lunes, diciembre 18, 2006

I'm back @ MDQ


Despues de un mes y medio volví ;=) no fue que no quise escribir pero como estuve en mediode de la mudanza y sin internet en casa se me complicaba mucho postear... y por otro lado como ultimamente no estoy recibiendo muchos comentarios en los posts tampoco me motivaba mucho seguir escribiendo, ya que uno de los objetivos del blog es la colaboración principalmente a traves de comentarios. Muchos me responden por mail o por chat y son cosas muy interesantes, pero lamentablemente si no se hacen a traves del los comentarios no queda plasmado en el blog y otros lectores no se enteran.
Para contar lo que paso en estos días:
  • Finalmente compramos (junto con el banco hipotecario) el hermoso PH en Palermo Viejo o Soho
  • Nos mudamos, por suerte pudimos pintar...
  • Terminó la cursada de APIT y ya tomamos finales, la verdad que un muy buen cuatrimestre
  • Nos vinimos a MDQ, yo voy a trabajar dos semanas y en Enero empiezo mis tan ansiadas vacaciones
En estas semanas estuve avanzando un poco en Rails, viendo Antipatterns para TDD y RIA, por supuesto, creo que tengo bastante para contar, nos vemos pronto!

lunes, noviembre 06, 2006

26 años

Hoy 6 de noviembre estoy cumpliendo mis 26... la verdad que me siento en un cumpleaños bastante atípico, pero en fin, quería compartir un balance del año:
  • Allá por el 6 de noviembre del 2005 hemos puesto la semillita :P de lo más hermoso que me dió la vida
  • Por Enero, se nos informa desde USA que una gran parte de la release de Blue Horizon iba a ser desarrollada completamente en Argentina (PM, Arquitectura, Diseño y Código), la verdad que estuve con bastantes responsabilidades y por suerte salio todo muy bien, terminamos antes de lo previsto y el proyecto pudo arrancar los 16 diferentes tipos de testing dos semanas antes de lo planificado, el team tuvo una respuesta increíble... TDD, IoC y Design evolutivo y por contratos fue la clave de exito...
  • Por Febrero del 2006, viaje a Mardel tengo un accidente terrible en la Ruta 2, con Mecha embarazada... pero por suerte no paso nada, el auto solo el tren delantero, solo una costillita que todavía en los días de humedad me molesta (Muchas gracias a Gerardo, Lucas, Barby, Los Pibes... por el apoyo, ayuda y contención)
  • En abril, finalmente, me dieron el título, ahora si soy Ing. Gustavo André Brey
  • 26 de Junio, me casé con la mujer que más me maravilló y me atrajo en toda la tierra
  • Por Julio, APIT tomo un nuevo camino, se nos unieron al team mentes brillantes que ya están dejando destellos de su profesionalismo, y esto recién empieza
  • Me puse a ver mas de cerca Ruby y luego con Ruby on Rail (de esto voy a postear algo en la semana)
  • También por Julio, arrancamos en mi proyecto, Blue Horizon Web Configurator, ver mas de cerca temas como RIA/AJAX, si bien ya veníamos charlando con los Geeks de IBM, lo pudismos ver más de cerca y hemos trabajado bastante, he dado presentaciones e investigado bastante, pero esto también recién empieza....
  • Mas cerca de la fecha, el 8 de Agosto nació Andrés
  • 25 de octubre, firmé el boleto de compraventa de mi futura casa, pensé que para esta fecha ya estaría mudado, pero la maldita AFIP sacó la fucking resolución 2148, con lo cual todavía no pude mudarme
  • El proyecto en el que estoy como líder (local) está creciendo de manera exponencial, ya es el proyecto con mayor cantidad de profesionales del area, estamos incorporando gente con capacidades increibles, me encanta poder seguir creciendo y mantener la calidad de profesionales que este proyecto siempre se caracterizó.
  • En Noviembre, presenté la nueva materia en la UTN-FRBA, Arquitectura de Software I
Que año agitadito que tuve ehh..... si me arrepiendo de algo? Si, la verdad que si, con todo esto me privé de ver a personas a las cuales aprecio mucho, como los Pibes, ex-compañeros de trabajo, ex-compañeros de la facu.

domingo, noviembre 05, 2006

Arquitectura de Software I (ex-APIT)

Como comenté en el post APIT, a partir del año que viene la idea es dividir la materia en dos, una para el primer cuatrimestre de quinto y otra para la segunda, o sea, Arquitectura de Software I y II. Ambas en calidad de materia electiva y donde la uno la voy a seguir un poco más yo y la otra Nicolas Passerini.
Esta semana presentamos la primera de ellas formalmente, siguiendo el nuevo procedimiento.
Aca muestro el programa de lo que se viene para AS1... no me gusta esa sigla, me parece que la voy a seguir llamando APIT ;)

PROGRAMA ANALITICO

  1. Introducción y Repaso de Ingeniería en Software
    1. Project Management
    2. SCM (Software Configuration Management)
      1. Baseline
      2. Change Management
      3. Defect Management
      4. Release Management
    3. Análisis de Riesgo
    4. Testing
    5. Introducción a Métricas
    6. QA
  2. Metodologías de Desarrollo
    1. Introducción a las metodologías orientadas a Iteraciones
    2. Proceso Unificado
    3. Metodologías Ágiles de Desarrollo
      1. XP - eXtreme Programming
      2. Scrum
      3. Test Driven Development
    4. Buenas prácticas para el desarrollo de software y la Arquitectura
      1. Diferentes puntos de vistas según el rol en la Metodología
  3. Arquitectura de Software
    1. Concepto de Arquitectura de Software
      1. Tipos de Arquitectura y Ciclos de Generación de Arquitecturas
      2. Modelado y Vistas de Arquitecturas
      3. Principios de Arquitectura
    2. Atributos de Calidad. Requerimientos Funcionales y No Funcionales.
    3. Restricciones
    4. Capacidad y Volumetría
    5. Influencias de la Arquitectura
    6. Entorno Técnico y Estándares
    7. Primera solución técnica y primera percepción de la arquitectura.
  4. Creación de Arquitecturas de Software
    1. Implementar Atributos de Calidad
    2. Definir el Esqueleto de la arquitectura.
    3. Definir o seleccionar los Módulos, Componentes, Interacciones e Interfaces.
    4. Estilos Arquitectónicos y Patrones de Arquitectura (POSA)
    5. Definir nodos, tipos de nodo, conexiones y zonas de redes
    6. Definir y Alocar los módulos y componentes en unidades físicas.
  5. Frameworks de Arquitectura
    1. La importancia de la reutilización
    2. Frameworks y Roadmap de Arquitecturas
      1. Model View 4.1
      2. The Open Group Architecture Framework
      3. Zatchman Framework
    3. Software Product Lines
  6. Comunicación de la Arquitectura
    1. Concepto de Comunicación y Entendimiento de Arquitectura
      1. Comunicar la Arquitectura
      2. StakeHolders y Preocupaciones
      3. ViewPoints, Views y Modelos
      4. IEEE 1470
    2. Workproducts y Deliverables de la Arquitectura
    3. Metodologia de Documentación (Patricio)
    4. Armado del SAD
    5. Características de la documentación de la Arquitectura
  7. Evaluación de Arquitecturas
    1. En que consiste la evaluación
    2. Cuando y Por que.
    3. Riesgos, Costos y Beneficios de las evaluaciones
    4. Métodos de Evaluación de Arquitecturas
      1. Ejemplo ATAM
  8. Rol del Arquitecto de Software
    1. Diferentes niveles y tipos de Arquitectos
    2. Responsabilidades del Arquitecto.
    3. Rasgos y Características del Arquitecto
      1. Liderazgo y Mentoring
      2. Responsabilidades y Aseguramiento de la calidad del Arquitecto
    4. Tareas del Arquitecto a los largo del Desarrollo de Software
      1. Propuesta de Solución y Evaluación Técnica incluyendo Estimaciones y Métricas
      2. Procesos de Construcción de Software
      3. Mantenimiento de Software.
Cualquier comentario será muy bien recibido...

martes, octubre 24, 2006

Seminario de "Prototype Oriented Programming"

Hace varios días que no posteo nada... estuve un poco entretenido con la compra de la casa, participando en seminarios/cursos y obviamente disfrutando de mi hijo.
El Martes 17 de Octubre, la gente de APIT me invitó a un seminario de "Programación Orientada a Prototipos", todos los martes nos juntamos para discutir temas de la materia, pero como justo ese martes caia el seminario del grupo athenas.
Quien dió el seminario, fue el Lic. Hernan Wilkinson, muchas veces habia escuchado hablar de el en IBM, si hablas con la gente es casi un dios, todos los que están hace mas de 8 años lo conocen como un excelente arquitecto y evangelizador del eXtreme Programming y Smalltalk. Lamentablemente no tuve la oportunidad de conocerlo. y apenas estoy hace 3 años.

Con respecto a la charla, sinceramente, estuvo muy buena, casualmente el mismo día, sin saber que a la noche iba a ir al seminario, lo estuve charlando con Gona sobre el tema, el me estuvo explicando de que se trataba.
Lo que realmente me interesó fue la comparación que hizo entre la Filosofía y la Programación Orientada a Objetos, verdaderamente yo no estaba al tanto el mapeo que habia entre lo que Platon y luego Aristoteles que encaja perfectamente con la POO, con clases. No es una rebundancia decir "POO con Clases"?? NO, para nada, la POO no expecifica que tienen que existir clasificaciones de objetos, ahi viene la mayor diferenciación entre lo que todos conocemos por POO (Smalltalk/Java/C# etc) y la POO Orientada a Prototipos. En pocas palabras se puede decir que la Programación Orientada a Prototipos es un sub-grupo de la POO, que utiliza las mismas herramientas pero sin clasificar a los objetos, cada objeto tiene su propio comportamiento, que puede variar a lo largo de la ejecución. Si entiende más o menos el concepto (cualquier cosa UTFW)??
Si bien, no es la manera en la que nos enseñaron a programar, tiene cierto sentido pensar de esta manera. Si lo vemos desde el punto de vista del modelado y el aprendizaje de cierto dominio de una aplicación, tiene más sentido empezar a utilizar objetos especificos y concretos para ir prototipando e ir entendiendo el dominio de la aplicación que estamos desarrollando, que clasificar o abstraer antes de aprender o entender el dominio???
Actualmente trabajamos de esa manera, primero abstraemos para aprender un dominio, no digo que esté mal, pero tambien creo que deberiamos incorporar algunos conceptos de Prototype Oriented Programming. En el seminario se mostraron ejemplos de este paradigma, con Self y con JavaScript.

Basicamente eso es lo que me quedó del seminario... hubo una pregunta interesante sobre las desventajas que tiene esto, y obviamente la respuesta de alguna manera dió algunas pistas de por que no es usado y ampliamente extendido. Ya que una vez que entendemos y aprendemos del dominio ya estamos capacitados para clasificar/abstraer/jerarquizar los objetos por lo tanto los prototipos no son tan necesitamos como al principio del aprendizaje/modelado, es aqui donde falla, no hay herramientas para poder pasar de un modelo en prototipos a clases...

Algo interesante que podemos destacar de Ruby es que permite ambos paradigmas de objeto, tanto con clases como prototipos... es probable que con el crecimiento de este lenguaje dinámico se pueda solucionar la falencia de los lenguajes orientados a prototipos.

El disertante (Hernan) comentó que si bien Ruby permite ambas cosas tiene un problema de que este es críptico....

Realmente piensan que Ruby puede ser el lenguaje para utilizar este paradigma?? Que es criptico ;) ?

lunes, octubre 09, 2006

Libros que toda organización de desarrollo de software debería tener

Estos son los libros "técnicos"que toda organización que desarrolle o mantenga software no puede dejar de tener, básicamente son biblias, todavía no he leido todos pero los que no leí les di una mirada y muchos profesionales me los recomendaron.

Software Architecture in Practice, Second Edition
By Len Bass, Paul Clements, Rick Kazman. Addison Wesley, 2003, ISBN 0-321-15495-9.
Price: $50.99 + Envio a Argentina (en USA es Free)

Evaluating Software Architectures: Methods and Case Studies
By Paul Clements, Rick Kazman, Mark Klein. Addison Wesley Professional. ISBN: 020170482X Price: $50.99 + Envio a Argentina (en USA es Free)

Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions

By Gregor Hoppe and Bobby Woolf. Addison Wesley, 2003, ISBN 0-321-20068-3
Price: $39.59 + Envio a Argentina (en USA es Free)

Software Estimation: Demystifying the Black Art. Redmond
By Steve McConnels. Microsoft Press, ISBN: 0-735-60535-1.
Price: $25.19 + Envio a Argentina (en USA es Free)

Domain Driven Design, Tackling Complexity in the Heart of Software

By Eric Evans. Addison Wesley, 2003, ISBN 0-321-12521-5
Price: $43.44 + Envio a Argentina (en USA es Free)

Object Design: Roles, Responsibilities, and Collaborations

By Rebecca Wirfs-Brock, Alan McKean. Addison Wesley. ISBN: 0-201-37943-0
Price: $42.42 + Envio a Argentina (en USA es Free)

Design Patterns: Elements of Reusable Object-Oriented Software
By GoF. Addison Wesley, 1995, ISBN: 0201633612
Price: $39.59 + Envio a Argentina (en USA es Free)

Working Effectively with Legacy Code
By Michael C. Feathers.
Price: $41.49 + Envio a Argentina (en USA es Free)

Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Price: $47.79 + Envio a Argentina (en USA es Free)

The Pragmatic Programmer
By Andrew Hunt, David Thomas
Price: $33.96 + Envio a Argentina (en USA es Free)

Code Complete, 2nd Ed
By Steve McConnels. Microsoft Press.
Price: $32.99 + Envio a Argentina (en USA es Free)

Como se habran dado cuenta no he agregado ninguno de de Java/C#/Ruby ni ninguno de PM o Metodologías, eso lo dejo para otro momento.

Que otro libro agregarían a esta lista??

viernes, octubre 06, 2006

El Bliki Martin Fowler me pone frenético

Suelo hablar muy bien de Martin Fowler, aprendí/aprendo mucho leyendo de el. Tiene excelentes libros y formidables articulos, pero si hay algo que me pone frenetico es que cada vez que leo el blog/wiki de Martin Fowler es que tengo que terminar leyendo otros 50 post debido a que en vez de llamar a las cosas por su nombre le pone nombre a todo.
No es mala la idea de linkear (al estilo Wiki) para determinadas palabras, pero si a eso le agregas terminos inventados (y ya existentes con otra nomenclartura) por el y que el solo usa, realmente me pone frenetico: vean este ejemplo:

El problema es que todos esos post linkeados a su vez tienen 10 más links...
En fin, de a poquito me voy enojando un poco más de este "guru" del diseño y metodologías. Otra cosa que me pasa con MF es que veo que le cambia los nombres a las cosas, ahora se me viene a la cabeza, IoC por DI, o DSL por Wrokbench Language, que se yo, eso me rompe un poco...
No puedo dejar de decir que es uno de los mejores escritores del software que he leido, y obviamente tiene una visión increible del software y por supuesto, lo voy a seguir leyendo, articulos como "Is design dead", "The new methodology" y "Continuos integration" son una reliquia.

Opinan lo mismo que yo o estoy equivocado?

lunes, octubre 02, 2006

Era de suponer...le costó un poco a Rational pero ya vino

Hace un año y un poquito más que vengo diciendo que IBM/Rational necesitaba alguna herramienta de Build and Release Management, en los ultimos tiempos muchas organizaciones fueron creciendo en madurez incorporando herramientas como Crouise Control, Maven, Custimizaciones de ANT , etc... pero IBM estaba muy atrasado en el tema, varios proyecto internos de IBM usaban herramientas customizadas para realizar esta tarea tan importante. Pero bueno, finalmente el area de software se dió cuenta que estaba perdiendo una gran parte importante del desarrolo y compró una empresa que tenía una herramienta de Build que parece muy interesante, ahora llamada Rational Build Forge, que tiene features muy interesantes y diferenciadores:
  • como la integración con varias herramientas de testeo automático (Test Manager, Robot, Performance, Unit, etc)
  • soporta diferentes "Source Control" y "Feature/Change/Defects Items" mas que cualquier otra herramienta de build, lo cual permite la tan importante trazabilidad
  • Lo que ellos llaman, "Build Acceleration" implementando paralelización de tareas y threads
  • Alta granuralidad para manejo de roles, diferencia de lo que es un tester, un build manager, desarrollador, lider, pm, etc.
Obviamente estoy obviando todos los features que una herramienta de build y release tiene que tener (automatización, countinous integration, IDE integration, etc). Una de las cosas "interesantes" de todo es que el grafiquito de Rational se sigue incrementando, ahora ya agregaron al Build Manager :)

lunes, septiembre 25, 2006

Nuevo Servicio de Google - Photos

Google sigue sacando productos gratuitos, digamos que lo que hizo no es nada bueno, lo mejor que tiene es que es de google, KISS y muy buen uso de AJAX basicamente....
Aparte se integra muy bien con el picasa, que es fat client para manejo de fotos, tambien de google.
Subi un par de fotos de mi hijo y la familia...

http://picasaweb.google.com/gusbrey

miércoles, septiembre 20, 2006

Indexador de Podcast - http://podcastindexer.blogspot.com/


Junto a Gonzalo De Pedro, hemos creado un nuevo blog, el objetivo es indexar, comentar y taguear podcast. Como ya saben suelo escuchar muchos de estos, y lo que me pasa es que luego de escucharlo, pasan unos días y olvido el contenido, el por eso que creamos el "Indexador de Podcast".
Por cada podcast vamos a describirlo muy por arriba, vamos a dar una opinión y vamos a taguearlo como para que quede accesible de una manera elegante. Espero que les guste y se sumen a la idea, si quieren participar como "Catalogadores" pongan un comentario en el primer post y los doy de alta.

miércoles, septiembre 13, 2006

Comentario: Offensive Coding

El autor de este blog es un grande, es quien escribió "Working Effectively with Legacy Code", es muy interesante como explica el concepto. Comparto su opinión, y sobre todo cada vez que leo sobre DBC, me gusta más...

Que opinan?

Este es el link: http://www.artima.com/weblogs/viewpost.jsp?thread=168511

Resumen: Tempted to code defensively? Maybe it's because you're dealing with offensive code.

sábado, septiembre 09, 2006

Joel on Software

Uno de los blogs mas interesantes que suelo leer es el de Joel on Software. Siempre tiene post interesantes que van desde tecnicos, metodológicos, project management, desarrollo ágil y trabajo en equipo. Varios de sus post me sorprendieron bastante, tiene una interesante redacción y mucha experiencia. Ultimamente todos sus post están relacionada con su empresa, llamada "Fog Creek", que tiene una visión muy interesante:
"Building the company where the best software developers in the world want to work"
En español: "Creando la compañia donde los mejores desarrolladores de software en el mundo quieran trabajar"
Si uno mas o menos sigue sus post plantea cosas muy copadas en lo que refiere al ambiente laboral, cultura y relaciones entre puestos, recomiendo leer este post, es genial, un poco largo pero muy interesante. Obviamente usa su blog para mostrar lo excelente que es su empresa y el excelente trato que tiene con el personal.
Igualmente, solo leyendo su blog me alcanza para querer laburar ahi. No se si todo lo que dice es cierto pero uno nunca sabe.
Bueno, les dejo esta recomendación y espero que les guste...
Justamente esta semana, creó dentro de su site un nuevo espacio para busqueda de trabajo, con determinadas particularidades que caracterizan a Joel, peguen una mira al post y al sitio de busqueda laboral.

domingo, septiembre 03, 2006

Arrancó otro cuatrimestre de APIT

Este es un post un poco tardío, ya que arrancamos hace 3 semanas aprox. Tenemos varias novedades:
  • Nicolas Passerini va a liderar la materia, yo no voy a poder dedicarle el tiempo que le venia haciendo debido a mi nuevo rol de papa :)
  • Tuvimos tres excelentes ingresos:
    • Prof. Jorge Bodoc, ya he mencionado su posible inclusión, trabajamos juntos en un proyecto que estaba incendiado y tuvimos muy buena onda, el era algo asi como el arquitecto del framework. Trabaja hace treinta años desarrollando software, toda una reliquia.
    • Ing. Hernan Liendo, le habia escuchado nombrar muchas veces y muy buenos comentarios, trabajó en cubika como arquitecto en un proyecto enorme con chile, ademas participó en la materia TADP
    • Lic. Gastón Coco, viene de la excelente universidad de tandil y la verdad que hubo muy buena onda, trabaja como Arquitecto en Cubika. Es increible lo que sabe, y lo que lee.
  • Nicolas Rossi, nos deja, debido a su emprendimiento personal, su nueva empresa llamada Identicum, Mucha Suerte!! estoy seguro que no la vas a necesitar...
  • Patricio Echagüe y Sei Wan Roh, debido a sus viajes personales/laborales tampoco van a poder participar.
  • La materia va a ser los Jueves en cambio de los viernes
  • Agregamos un TP en donde, aparte de crear una arquitectura, van a tener que codificar parte del sistema.
Con respecto al programa, es un poco lo que expliqué en otro post, la idea es dar algo mas técnico, lo que en algún momento vamos a dar en APIT 2. Describo un poco las clases:
  1. Introducción a Arq. de SW
  2. Metodologias
  3. Atributos de Calidad. Estilos Arquitectónicos
  4. Tacticas para lograr Attr. de Calidad
  5. Organización de la lógica de negocio
  6. Intefaz de Usuario (UI)
  7. Integración de Aplicaciones (EAI/SOA)
  8. Persistencia
  9. Testing
  10. Software Configuration Management
  11. Delirio (La idea es romper el estado del arte actual y pensar en lo que puede venir a futuro)
Con respecto a los papers de investigación, se pusieron temas bastante interesantes, la unica diferencia, es que el Tutor del paper va a participar de manera activa y va a ser parte del paper, estos son los temas que quedaron:
  • Automatización de Tests de Integracion
  • Por que Arquitecturas en Capas?
  • Cuando conviene RIA?
  • Clusterizacion de aplicaciones con GNU
  • Adaptive SOA
Tambien estamos viendo de mejorar la comunicación y hemos levantado un wiki en el lab de sistemas, pero como la red de la UTN está cada vez más descuidada... increible, quien lidera el Depto de Sistemas es Jefe de Catedra de Redes, sin palabras...

viernes, agosto 25, 2006

Ubuntu recien llegado

Acabo de recibir copias de la distro Ubuntu, lamentablemente no las puedo probar en este momento, pero apenas lo haga voy a dar algún feedback. No veo la hora para probarlo y seguir probando ruby/ror, pero esta vez sobre linux.
Me llegó la versión desktop (fue la que pedí gratuitamente) que es en formato live cd, que es lo unico que puedo usar en la laptop, por el momento.

Luego de la Charlar de TDD

Ayer, finalmente, dí la charla de TDD, muchas gracias por los comentarios, me sirvieron mucho. Creo que salio bastante bien, o al menos yo me sentí coforme y tuve buen feedback, quedó grabada, si en algun momento puedo ripearla a algún formato "reproducible" fuera de IBM lo voy a hacer.
En los temas que mas me focalicé que muchas charlar olvidan discutir:
- El origen del TDD y los problemas actuales
- Que ventajas tiene el TDD
- Y los problemas y como manejarlos que puede traer implementarlo en un proyecto (mas allá de usar o no XP)
Dejo las ventajas y los problemas para discutir:
Ventajas:
  • Tests determine what code you need to write
  • Constant Regression Testing
  • Improved Communication
  • Improved Software Design
  • Tests are well completion criteria
  • Facilitate software changes
  • Remove / Reduce reliance on the debugger
  • Reduced defects
Problemas a la hora de implementarlo (la mayoria fueron sacados del ibro Paragmatic Unit Testing):
  • It takes too much time to write the tests
  • It takes too long to run the tests
  • It's not my job to test my codeI don't really know how the code is supposed to behave so I can't test it
  • But it compiles!
    I'm being paid to write code, not to write tests
  • I feel guilty about putting testers and QA staff out of work
  • My company won't let me run unit tests on the live system
  • Dependency is complex to handle
Todos estos problemas obviamente pueden ser solucionados, eso lo explique en la charla.
Si encuentran alguno más para compartir bienvenido sea.

martes, agosto 22, 2006

Charla de Test Driven Development

Dentro de lo que es la comunidad técnica, en IBM, algo de lo que voy a hablar en algún post, el próximo jueves voy a dar una charla sobre TDD. Aca soy casi un evangelizador de esta práctica, por las ventajas que esta provee, y todavía no puedo creer que solo en mi proyecto y algún otro se use. No estaba previsto que yo de esta charla, sino la persona que más sabe de esto, que yo conozco, Emilio Costa Giomi, lo conocí trabajando en Telefonica el año pasado, y fue un placer discutir con un taliban de las metodologías ágiles y diseño, pero lamentablemente (para IBM) el ya no está más trabajando para IBM.
Como objetivo de esta charla es espero explicar que es TDD, y que ventajas tiene para se empiece a usar de manera mas seria. Esto va a ser más o menos la agenda que tengo, si alguno tiene algún tipo de consejo o ayuda, será bienvenida.

  • Global Delivery, Java Developer, the importance of TDD
  • Agile Methodologies and TDD. TDD is not just for Agile Methodologies
  • TDD Introduction. What is TDD? Buzzword. Hello world example.
  • TDD Process. Test First. Automating. Repeat. Flows and Stages
  • Using TDD inside a project and others best practices (Measurings, Refactoring, Continuous Integration, etc).
  • Dependency Management Techniques. MockObjects.
  • TDD as Design. Dependency Injection Patterns. TDD as Specification.
  • Tools, Books and Frameworks References
  • Two Common Problems Examples. (Web UI TDD and Data Access TDD)
  • Why TDD?

viernes, agosto 18, 2006

Gracias Centro de Estudiante!

No soy de meterme en política, menos en lo que a la UTN refiere, prefiero sumar por otros lados (lab y docencia), pero lo que me enteré la semana pasada a través de un mail, me dejó realmente muy mal... y es la renuncia de las principales cabezas del cuerpo docentes y ayudantes de la materia Sistemas Operativos de segundo año de Ing. en Sistemas de Información.
Todos sabemos el valor agregado que esta materia da a los estudiantes de la UTN es increíble, no solo, lo viví en carne propia, sino también lo viví desde el otro lado staffeando gente, cualquier estudiante que haya cursado y aprobado dicha materia es muy superior a cualquier otro estudiante a ese nivel de cualquier universidad. Es más creo que Sistemas Operativos (junto con otras) es la materia diferenciadora en cuanto a calidad educativa y formación de profesionales.
Sinceramente estoy muy dolido por que sin gente como Adrian, Diego, Maximo y Rosario a la cabeza nose si van a poder seguir tal excelencia. Yo pude ver desde muy cerca el esfuerzo que le ponen día a día a la calidad educativa y me saco el sombrero. Que tenían/tienen muchas cosas por mejorar, seguro, pero puedo poner mis manos en el fuego que Adrian se ocupó siempre de eso.
Solo quiero apoyar a la gente que lideró esta materia y cuenten conmigo para lo que sea, les debo mucho y creo que esto no se tiene que cortar.

Y por que del titulo del post? Debido a que la actitud que venían teniendo con esta cátedra era lamentable (incluido el jefe del depto), en vez de ocuparse de la calidad educativa y valor agregado en la industria, como otras veces doy fe que lo hacen, se ocuparon de agredir de diferentes maneras, espero muchachos que mejoren, no podemos seguir perdiendo la identidad.

jueves, agosto 17, 2006

Extensions Utiles para el Firefox (De Andrés Calabrese)

La semana pasada recibí un mail de un compañero de trabajo, y me pareció interesante para compartir:

Image Zoom
Te permite hacer zoom sobre las imagenes, sobre toda la página, setearle un tamaño específico, etc.

DownThemAll
Es un download manager integrado en el firefox. Hace varias conexiones para bajar el mismo archivo, tiene resume sobre los downloads, etc.

Restart Tabbed
Agrega dos opciones nuevas para reiniciar y para cerrar el firefox guardando los tabs existente. Útil cuando hay que reiniciar el firefox por alguna actualización.

Tab Mix Plus
Mejora mucho el manejo de tabs que tiene el firefox. Como el control de los links que se abren, para forzar que los cargue en un tab y no abra otro firefox. Agrega el manejo de sesiones (permite grabar un conjunto de tabs abiertos) y tambien guarda la última sesión utilizada (por ejemplo para recuperar los tabs cuando se cerró por un error el firefox).

Extended Statusbar
Barra como la de Opera que muestra, velocidad, porcentaje y tiempo de carga de la página (a mi no me anduvo muy bien)

Minimize To Tray
En vez de minimizar el firefox a la barra de tareas, lo agrega a la tray bar.

Venkman JavaScript Debugger

Este es un lujo para debuggear JS, es un entorno de debug muy parecido al del eclipse.

Fire FTP
Cliente FTP integrado en el firefox. Agrega más funcionalidad a la básica que ya tiene.

Dicen que el Firefox 2.0 ya va a tener varios de estos add ons incluidos...

lunes, agosto 14, 2006

La ultima y no jodo mas

Juro que es la ultima foto de mi hijo :) solo queria mostrarlo con su body de All Boys que bordó mi suegra, Naná. No es una hermosura??? Prometo escribir cosas tecnicas en los proximos posts, tengo pendiente escribir de Ruby, Portal/Porlets y RIA.
Posted by Picasa

domingo, agosto 13, 2006

Un nuevo hincha de All Boys!!!

Como muchos ya saben, el Martes 8 de Agosto, nació mi hijo, Andrés Brey. Obviamente esto me tuvo mas que entretenido la semana pasada. Por suerte salió todo muy bien, estuvimos en la clínica hasta el viernes y recibimos muchas visitas y regalos, desde ya les agradezco a todos los que vinieron y enviaron mensajes, mails, etc.
Les puedo asegurar que viví el momento más importante de mi vida. No se puede entender como una cosita tan chiquita creada a base de amor, te pueda hacer sentir cosas tan profundas e imposibles de explicar en palabras. Nunca voy a olvidar ese momento, en el quirófano de la Suizo (Clinica y Marternidad) donde lloré por 30 minutos seguidos y me sentí el hombre más feliz del mundo. Estas son unas fotos de mi chancho, y puedo asegurar que es igual al la 4D que hicimos en la semana 28.

jueves, agosto 03, 2006

Morphing

Alguien puede creer semejante panza?? Y todavía falta la de esta semana.... y no son dos!!! Andrés sos un pichon de mamut.....
http://www.brey.com.ar/Panza/