Charla de Cloud en APIT - Gracias Santi!

Esta semana en APIT, el Ing. Santi Cardarelli nos honró con su presencia para contarnos su experiencia en todos los tipos de Cloud, sus beneficios y como integrar las clouds dentro de las empresas.
Obviamente cuando uno lee revistas, noticias y blogs, por lo menos cloud es algo que se escucha muy a menudo y de alguna manera esto hizo que se deje de hablar taaaaanto de SOA (buzzword), la diferencia clave es que por lo menos cloud tiene implementaciones reales y cuando hablamos de SOA siempre fue todo muy teórico, está claro que son dos cosas distintas uno es para integrar (SOA) y el otro es un concepto más de infraestructura (Cloud). En fin, algunas cosas que generaron discusiones durante la charla fueron:
1) Performance. Está claro que cloud está basado arriba de Virtualización, y obviamente puede traer algunos inconvenientes a la hora de esperar cierto tiempo de respuesta ya que todo está corriendo sobre el mismo fierro, ejemplo una aplicación Online (Web) necesita procesar un pedido y hay un Batch de otra aplicación consumiendo muchísimo, como para todo eso es tan transparente es dificil lidiar, obviamente creo que la tecnología está cada vez más cerca de solucionarlo, ya sea migrando procesos de un fierro a otro (más ocioso) de una manera transparente, pero creo que falta un poco.
2) Seguridad. Este es un tema que yo considero importante pero no me preocupa, hace 10 años nadie ponia su tarjeta de crédito en ningún sitio web, ya pasó eso, ahora hay bancos virtuales como Paypal.
3) PaaS como modelo seguro de desarrollo? Es un tema, crear aplicaciones sobre force o GAE es realmente interesan? No terminaría casándome con una empresa y tengo que lidiar de por vida con eso, como les pasó a las empresas con los Mainframes de IBM, por ejemplo. Nose, creo que startups, aplicaciones pequeñas pueden tener un muy buen uso de los PaaS sin tener que contratar a un arquitecto :)
4) Escalabilidad: Este creo que es uno de los puntos fundamentales (posiblemente junto al costo) creo que pensándolo arquitecturalmente tiene mucho peso.
Aca les dejo la presentación que uso Santiago:

Otro cuatrimestre, otro parcial

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

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

TDD desde una perspectiva arquitectural

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

Facts acerca de TDD

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

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

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

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

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

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

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

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

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

Architects

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

Application Developers

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

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

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

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

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

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

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?

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