jueves, 12 de diciembre de 2013

Charla de OpenShift en Epidata

El martes, en Epidata, lunafromthemoon dio una charla interna de OpenShift, partiendo desde lo básico, cómo sacar una cuenta, crear una aplicación, hasta conceptos más avanzados como cómo crear un cartridge, estructura interna, etc.

Hasta hace poco, Luna estuvo desarrollando un cartridge de Infinispan para OpenShift. En su github pueden ver parte de su trabajo.

La charla estuvo realmente muy buena. Les dejo aquí las slides:


miércoles, 4 de diciembre de 2013

Tweets para el Recuerdo

domingo, 24 de noviembre de 2013

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 4

Este artículo forma parte de una serie de posts en los que traduzco y resumo los principios del libro 97 Cosas que un Arquitecto de Software Debe Conocer.

Los post anteriores pueden leerse en:
Continuamos con los siguientes 15 principios:
  1. Lucha contra la Repetición: 1) La duplicación es malvada. 2) El trabajo repetitivo frena el desarrollo. La repetición en el código es algo que los desarrolladores finalmente aprenden a filtrar e ignorar al leer el código, pero, incluso aunque los desarrolladores se acostumbren a él, les ralentiza. Como arquitecto, tu responsabilidad es eliminarlo. Para ello, necesitarás frameworks, mejores abstracciones, aspectos o incluso módulos generadores de código. La repetición no va a desaparecer a menos que hagas algo al respecto. Es crucial que los ejemplos que le entregues a tu equipo sean limpios, de intención reveladora, y que no contengan nada más que lo que no puede ser abstraído: el dominio de negocio.

  2. Bienvenido al Mundo Real: El mundo real no es binario. Los clientes cancelan órdenes momentos después de crearlas, los cheques rebotan, las cartas se pierden, las promesas se rompen. Los servicios pueden caerse, ser cambiados sin previo aviso, o no proveer garantía transaccional. Despídete de las viejas y predecibles arquitecturas de pilas de llamadas. Prepárate para responder a los eventos en cualquier momento y en cualquier orden, lanzar peticiones asíncronas y concurrentes, reparar errores mediante compensaciones, reintentos u operaciones tentativas.


  3. No Controles, pero Observa: Construir un sistema flexible deriva en una arquitectura compleja de la cual es difícil obtener el panorama completo. Ser un obseso del control quedó en el pasado. Los sistemas de hoy en día son distribuidos y débilmente acoplados. Los lenguajes de programación modernos soportan reflexión, y casi todas las plataformas proporcionan métricas en tiempo de ejecución. A medida que el sistema se vuelve más configurable, la configuración es otra gran fuente de información. En lugar de diseñar un modelo exhaustivo de la arquitectura, previo al desarrollo, construye una arquitectura flexible, adaptable, y extrae el modelo del estado real del sistema.

  4. Jano, el Arquitecto: Un arquitecto se esfuerza por fusionar la realidad con la visión, el éxito del pasado con el futuro, las expectativas empresariales con las limitaciones del desarrollo. Un buen arquitecto debe tener esas dos cabezas capaces de transportar dos ideas o pensamientos, diferentes metas o visiones, para crear un producto que satisfaga las diversas partes interesadas del proyecto. Un buen arquitecto está abierto a nuevas ideas, herramientas y diseños que mejoren el proyecto, el equipo o la profesión; debe reconocer las buenas ideas y cultivar un ambiente para que crezcan. Como Jano, debe ser guardián de las puertas y los pasillos, abarcando lo viejo y lo nuevo, mezclando la creatividad con la ingeniería, para cumplir los requerimientos y satisfacer las expectativas del futuro.

  5. Los Arquitectos se Enfocan en los Límites y en las Interfaces: Siguiendo el conocido mantra de "Divide y Conquistarás", uno de los trabajos más difíciles del arquitecto es encontrar los lugares naturales para ubicar los límites y definir las interfaces necesarias para construir un sistema de trabajo. Para esto son muy útiles los patrones Bounded Context y Context Mapping del libro Domain-Driven Design. Mientras que el primero ayuda a definir explícitamente el contexto dentro del cual se aplica un modelo, estableciendo límites en cuanto a la organización de los equipos y el uso de partes específicas de la aplicación, como proyectos y bases de datos, el segundo asiste a las relaciones entre esos contextos, forzando a la definición de las interfaces de comunicación entre los mismos. Un Mapa de Contexto es una herramienta poderosa que permite centrarnos en lo que debe estar unido (cohesionado) y lo que debe mantenerse aparte (desacoplado), permitiéndonos "dividir y conquistar" sabiamente de forma comunicativa.

  6. Strategic Domain-Driven Design

  7. Desafía a las Suposiciones; Especialmente a las Tuyas: La suposición es la madre de todas las meteduras de pata. Las buenas prácticas dictan que los arquitectos deben documentar todos los razonamientos detrás de cada decisión, registrando el contexto y los factores que contribuyeron al juicio final. Esta práctica es valiosa porque ayuda a resaltar los supuestos que pueden estar afectando las decisiones importantes sobre el software que se está diseñando. Es importante exponer estos supuestos para futuras re-evaluaciones. Todas las suposiciones deben estar basadas en evidencia empírica relevante. Incluso algo que fue verdad en el pasado, no tiene que seguir siendo verdad en el presente; hasta las buenas prácticas se vuelven obsoletas en algún punto. Constantemente desafiemos los supuestos, justificando nuestras decisiones con fundamentos sólidos, actualizados y relevantes.

  8. Registra tus Razonamientos: ¿Cuál fue la decisión que tomamos? ¿Por qué tuvimos que tomar esa decisión? ¿Qué otras soluciones fueron consideradas y por qué fueron rechazadas? Una bitácora de los razonamientos utilizados para tomar las decisiones es un tipo de documentación que envejece bien, que tarda mucho en desactualizarse. El formato puede variar según el contexto del proyecto, desde notas rápidas en un texto, una wiki o un blog, hasta usar plantillas más formales para registrar todos los aspectos de cada decisión de arquitectura. Es importante que soporte búsquedas así se puede encontrar fácilmente lo que se necesita.

  9. Otórgale Poder a los Desarrolladores: El rol de un arquitecto suele imponer restricciones, pero también tienes la oportunidad de ser facilitador. Asegúrate que los desarrolladores tengan las herramientas que necesitan. El trabajo repetitivo y sin sentido debe ser automatizado siempre que sea posible. Vale la pena asegurarse que los desarrolladores tengan máquinas rápidas para trabajar, ancho de banda suficiente, acceso a software, datos e información. Asegúrate que tienen los skills que se necesitan. Consígueles entrenamiento si lo necesitan. Invierte en libros. Promueve discusiones sobre tecnología. Mantenlos activos en listas, conferencias, incentiva su hambre de aprender. Crea estándares por el bien de la consistencia, y dales libertad para tomar decisiones que no contradigan dichos lineamientos. Protéjelos del trabajo no esencial. La arquitectura debe remover obstáculos, no incrementarlos.

  10. Todo se Trata de los Datos: Una computadora no es nada más que una fantástica herramienta para acceder y manipular pilas de datos. En el fondo, el fin de cualquier algoritmo es transformar datos de una versión a otra. Los datos viven en el núcleo de la mayoría de los problemas. Podemos abordar cualquier lógica de negocio a través de los datos, y así serán más simples de comprender. ¿El sistema está recogiendo los datos correctos en el momento correcto? ¿Quiénes son los que pueden ver esos datos y modificarlos? La funcionalidad es lo que vemos primero, pero son los datos los que conforman el núcleo de todos los sistemas.


  11. Controla los Datos, no sólo el Código: El versionador de código y el servidor de integración continua son herramientas excelentes para manejar la construcción de aplicaciones y sus procesos de despliegue. Pero, ¿qué herramientas usamos para controlar los datos? Por alguna razón los datos suelen ser pasados por alto durante el planeamiento de una arquitectura. Así es que nos encontramos con esquemas incompatibles, datos inconsistentes, violaciones de restricciones, y sumémosle a esto que los problemas de base de datos son tediosos de revertir. Es altísimo el valor de un proceso automatizado de construcción que sea capaz de restaurar los datos a un estado conocido si algo salió mal. Los cambios de base de datos no deben crear un nudo es tu continuum de construcción. Debes ser capaz de construir la aplicación entera, incluyendo la base de datos, como una sola unidad.

  12. No Estires las Metáforas Arquitectónicas: Cuando las metáforas se extienden demasiado tiempo a veces pueden volverse en contra del arquitecto. Al cliente puede comenzarle a gustar más la metáfora que el sistema propuesto, por ejemplo, en la que no hay limitaciones reales. O el equipo de desarrollo puede pensar que la metáfora es más importante que el problema de negocio real y así comienzas a justificar decisiones extrañas. El sistema entregado puede contener reliquias de nombres de antiguas metáforas rotas, testimonios arqueológicos de conceptos que fueron refactorizados hasta mutar en abstracciones completamente distintas. La moraleja es: no te enamores de tus metáforas, úsalas con fines exploratorios de comunicación y no dejes que se vuelvan en tu contra.

  13. Enfócate en el Soporte y el Mantenimiento: El soporte y el mantenimiento nunca deben ser pensamientos tardíos. Dado que más del 80% del ciclo de vida de una aplicación se gasta en el mantenimiento, debemos prestar mucha atención a los problemas de soporte y mantenimiento cuando diseñamos. Para un arquitecto es fácil pensar como desarrollador, ya que la mayoría en el pasado fuimos desarrolladores y no administradores. Dificultades típicas que podemos encontrar en un ambiente de producción: requests que no pueden volverse a mandar para reproducir un problema, usuarios y CEOs enojados porque encuentran bugs, imposibilidad de debuggear, despliegues que deben planificarse, coordinarse con distintas áreas, imposibilidad de detener la aplicación para testear un bug, nivel de log mucho más bajo que en el entorno de desarrollo, etc. Para que las aplicaciones puedan sobrevivir sin sus desarrolladores, se debe: 1) entender que desarrollo y soporte requieren skills diferentes, 2) involucrar a un líder de soporte lo más temprano posible en el proyecto, 3) nombrarlo como un integrante fundamental en el equipo, e 4) involucrarlo en el planeamiento del soporte de la aplicación.

  14. Prepárate para Elegir Dos: A veces renunciar a una propiedad puede conducir a una mejor arquitectura. Las propiedades deseables suelen venir en grupos de tres y tratar de definir y construir un sistema que soporte las tres puede resultar en un sistema que no hace nada bien. Famoso es el ejemplo del teorema CAP (consistencia, disponibilidad y tolerancia a fallos). Tratar las propiedades como doctrinas religiosas no nos dejará pensar en el problema. Empezamos a hablar de desviaciones arquitectónicas en lugar de principios de diseño y a confundir dogmatismo con gobierno. Seamos siempre escépticos. Evaluemos las ventajas y desventajas, y abandonemos propiedades que son muy costosas de implementar. Seamos creativos.

  15. Prefiere los Principios, los Axiomas y las Analogías antes que las Opiniones y los Gustos: Si lo haces, documentar y comunicar tu arquitectura será más simple. Una arquitectura con principios claros libera a su arquitecto de revisar todo y estar en todas partes. No necesitarás ser un adicto al trabajo para asegurar que otros implementen, adapten, extiendan, manipulen tu arquitectura correctamente. En cambio, las opiniones y los gustos sólo conducen a discusiones políticas en las que la autoridad suele ganar. Los principios y axiomas le dan a la arquitectura consistencia a través del tiempo.

  16. Comienza con un Esqueleto Caminante: Una estrategia muy útil para implementar, verificar y evolucionar la arquitectura de una aplicación es empezar con lo que Alistair Cockburn llama un Walking Skeleton, una mínima implementación de punta a punta de tu sistema (arquitectura ejecutable) en donde intervienen todos los componentes arquitecturales principales. Una vez que el esqueleto está en su lugar, es el momento de ponerlo a rodar. Esto significa hacerlo crecer incrementalmente, agregándole funcionalidades completas. El objetivo es mantener el sistema en funcionamiento, a la vez que crece el esqueleto. Esto va muy de la mano con lo que se suele llamar Arquitectura Ágil o Arquitectura Evolutiva, donde el esqueleto evoluciona en un proceso de diseño continuo, mostrando sus falencias en etapas tempranas del proyecto para que los cambios sean menos costosos. Fail fast, fail cheap.
Fuente: Rinat Abdullin @abdullin

domingo, 17 de noviembre de 2013

Inyección de Dependencia

En el post anterior les conté de la charla de Inyección de Dependencia que iba a dar en la UTN. Tengo que dar las gracias a la gente de Epidata y la gente de la UTN que organizó la charla, ya que salió de maravilla.

En este post les comparto las slides que usé para dar la charla:


Y el código fuente con los ejemplos, que pueden descargar o forkear desde GitHub:

El ejemplo se trata de un multi-proyecto Maven con distintos módulos:
  • dependency-injection-model: contiene un modelo simple de POJOs con una clase Proyecto y diferentes tipos de Empleados, discriminados por roles para proyectos de software: PM, Arquitecto, Desarrollador, Tester; además cuenta con una interfaz ProjectRepository con una implementación JSON que sirve para recuperar una lista de proyectos desde un archivo JSON.
  • dependency-injection-base: contiene un simple proyecto Java con un ProjectDAO y un ProjectService, y JUnit Tests para cada capa. Este ejemplo no usa el patrón de inyección de dependencia. Los objetos se instancian usando el operador "new" de Java.
  • dependency-injection-adhoc: contiene un simple proyecto Java que implementa el patrón de inyección de dependencia de forma ad-hoc usando reflection.
  • dependency-injection-spring: El mismo ejemplo de ProjectDAO y ProjectService, pero implementando la inyección de dependencia con Spring Framework. No requiere ningún servidor de aplicaciones. Los tests se ejecutan con JUnit.
  • dependency-injection-javaee: El mismo ejemplo de ProjectDAO y ProjectService, pero implementando la inyección de dependencia con Weld, la implementación de referencia de JavaEE/CDI. Al igual que el ejemplo anterior, los unit tests no requieren ningún servidor de aplicaciones, ejecutan en modo standalone.

viernes, 8 de noviembre de 2013

Charla Gratuita sobre Inyección de Dependencia

Este jueves 14/11 a las 19hs, estaré dando una charla gratuita sobre Inyección de Dependencia en el Aula Magna de la sede de Medrano de la UTN (Universidad Tecnológica Nacional).


En el desarrollo de grandes aplicaciones empresariales, la dependencia entre módulos es uno de los más grandes problemas. Módulos fuertemente acoplados aceleran la entropía de un sistema, provocando rigidez, fragilidad, inmovilidad y dificultando el mantenimiento y escalamiento del código fuente. La inyección de dependencia es un patrón de diseño que sirve para reducir el acoplamiento entre dos o más módulos y facilitar la administración de dependencias. En esta charla se verán los conceptos fundamentales de Contenedores, Inversión de Control e Inyección de Dependencia, mostrando diferentes implementaciones, entre ellas Spring y Java EE, concluyendo en una comparación entre ambas tecnologías de punta.

¡Los esperamos!

miércoles, 16 de octubre de 2013

Tweets para el Recuerdo

Hace unas semanas que vengo acumulando algunos tweets muy buenos de gente que sigo en mi cuenta @aparedes82. A veces me sorprende la sabiduría que se puede concentrar en apenas 140 caracteres. En este humilde post comparto algunos de los que me resultaron más interesantes.

sábado, 21 de septiembre de 2013

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 3

Después de resumir los primeros 30 principios de 97 Cosas que un Arquitecto de Software Debe Conocer, paso a escribir sobre los siguientes 15.

El que quiera, puede repasar los posts anteriores de la serie:
  1. Programar es un Acto de Diseño: La construcción de un nuevo auto involucra dos fases: una creativa, de diseño, que incluye la definición de las líneas de montaje, y una segunda de fabricación de autos en serie. En Ingeniería de Software, el único artefacto que puede ser considerado como documento de diseño, según los criterios de la ingeniería clásica, es el código fuente, ya que a partir del código fuente la fabricación del software puede automatizarse, usando al compilador como obrero, y scripts para construir y probar. Si aceptamos que forjar software es un acto de diseño (fase 1), no un acto de construcción (fase 2), podemos adoptar prácticas usadas para manejar la creatividad y el trabajo impredecible, como las usadas para diseñar un nuevo auto, una nueva droga o un nuevo juego de computadora.

  2. El Tiempo lo Cambia Todo: A menudo cometemos el error de creer que no podemos influir en lo que se nos pide hacer. Por lo general podemos, pero nos saca de nuestra zona de confort que es el espacio de la tecnología. Sin embargo, el tiempo pasa y, a pesar de haber trabajado duro, si no hicimos lo que realmente se necesitaba, nuestro trabajo fue en vano. Con el tiempo, una buena solución al desafío correcto probablemente dure más que todos aquellos patrones y frameworks balas de plata. No solemos respetar el principio KISS, el tiempo pasa y nos hace ver como estúpidos. Al mirar atrás, siempre encontrarás diseños antiguos que no coincidirán con tus expectativas actuales. Aprende a aceptar esos viejos trabajos, y a resistir la tentación de pensar que debes volver atrás a arreglarlos.

  3. Dale Autonomía a los Desarrolladores: Si estás haciendo bien tu trabajo de arquitecto, no deberías tener tiempo suficiente para interferir con los desarrolladores. ¿Tienen problemas para escribir tests? ¡Mejora las interfaces y limita las dependencias! ¿Constantemente cometen los errores más comunes utilizando una API que diseñaste? ¡Haz el diseño más obvio! ¿Entiende la gente tu diseño? ¡Comunícalo y clarifícalo cuanto haga falta! Es razonable hacer sugerencias cuando ves a la gente trabada con algún problema, pero es aún mejor si creas el ambiente donde ellos puedan acercarse y pedir sugerencias. Es importante darle a tus compañeros de equipo suficiente autonomía para que desplieguen sus habilidades y creatividad.

  4. Valora la Administración sobre la Teatralidad: Cuando un arquitecto ingresa en un proyecto, se espera de él resultados asombrosos. Para un arquitecto es fácil encandilar con sus conocimientos. Sin embargo, los arquitectos deben ganarse el respeto del equipo proveyendo liderazgo sólido y verdadero entendimiento técnico y del dominio de negocio. Nunca es bueno satisfacer las expectativas usando la teatralidad, más propia del vendedor que del ingeniero o el artesano. Un arquitecto debe actuar según los intereses de sus clientes y no complacer las necesidades de su propio ego. Sistemas complejizados al extremo sólo por el deporte de adoptar tecnologías de moda, rara vez se construyen sin sacrificios a cargo de las empresas. Nunca olvides que estás jugando con el dinero de otras personas.

  5. ¡Cuidado! Los Problemas en el Espejo pueden ser más Grandes de lo que Parecen: En general, los problemas siempre tienen más impacto de lo que el equipo espera que tengan. Las fuerzas que contribuyen a que suceda esto pueden ser: 1) Cuestiones que en etapas tempranas parecen triviales y se convierten en críticas cuando ya es demasiado tarde: una administración proactiva de riesgos puede contrarrestar este tipo de problemas, trackeando los riesgos de la misma forma que trackeamos los bugs; 2) Individuos que enfrentan resistencia cuando el resto del equipo no comparte sus experiencias y conocimiento: por eso debemos fomentar el debate y defender el valor de disentir; 3) Optimismo infundado de los desarrolladores, que quizá han sido tildados de pesimistas en el pasado al exponer los problemas: debemos fundamentar el optimismo con valores, escenarios, pruebas; 4) Criterios diferentes de qué es o no importante: constantemente debemos testear el entendimiento del equipo y del cliente, no dar nada por asumido; 5) Puntos ciegos que todos tenemos y que nos son difíciles de reconocer: por eso es importante valorar a la gente de confianza que no teme contarnos una verdad dura cuando se necesita.


  6. El Título de Arquitecto de Software se escribe con Minúsculas, ¡Enfréntalo!: La Arquitectura de Software es un arte, y sin duda requiere de práctica y disciplina para lograr el éxito en el campo. El Desarrollo de Software sigue siendo una tarea relativamente incipiente. No sabemos aún lo suficiente sobre esta práctica para profesionalizarla adecuadamente. Los profesionales de software cuentan con una considerable compensación por su trabajo que es muy creativo y exploratorio. Medita un poco sobre eso y reflexiona sobre lo mucho por lo que tenemos que estar contentos, y lo descarado que es insistir en que el Arquitecto de Software se considera un título equivalente a Arquitecto, Abogado o Doctor.

  7. La Arquitectura de Software tiene Consecuencias Éticas: Si los programas son exitosos afectan la vida de miles o millones de personas, positiva o negativamente. Cada vez que tomas una decisión estás decidiendo qué puede o no hacer el usuario, y de forma más inflexible que la ley. Por ejemplo, los campos requeridos en un formulario parecen inofensivos, pero son siempre una imposición hacia los usuarios. No es ético empeorar la vida de los demás sólo para hacer tu trabajo más fácil.

  8. Al Final Todo Fallará: El hardware es falible, por eso añadimos redundancia, pero a mayor cantidad de hardware mayor probabilidad de fallas. El software es falible, por eso añadimos monitoreo, pero a mayor cantidad de software mayor probabilidad de fallas. Los humanos somos falibles también, por eso automatizamos acciones, diagnósticos y procesos, pero no existe un sistema automatizado que pueda responder a la misma gama de situaciones que un ser humano; y agregamos monitoreo a la automatización: más software. Cada mecanismo de seguridad que agregamos añade nuevos modos de fallos. La única certeza en los sistemas es que fallarán. Diséñalos para reaccionar a los fallos.


  9. El Contexto es el Rey: El contexto es la única fuerza que supera la simplicidad cuando se toman decisiones arquitectónicas. Una buena arquitectura es el producto de las decisiones tomadas en un contexto general, forzadas por múltiples prioridades en competencia. Tu equipo debe estar libre de dogmas y de peleas triviales (o comerciales) entre distintos frameworks, patrones o tecnologías; debe reflexionar sobre el contexto ante todo, y llegar a las soluciones más simples desde allí.

  10. Todo es Cuestión de Performance: Al considerar la implementación y operación de un sistema exitoso, los arquitectos y los diseñadores siempre deben prestar especial atención al rendimiento. Podemos encarar la performance desde tres distintos aspectos: 1) Desde el punto de vista de humanos construyendo el sistema (productividad): es importante porque afecta directamente al costo y a la planificación del proyecto; 2) Desde el punto de vista de la interacción humana con el sistema: factores como el tiempo de respuesta, intuitividad de la interfaz, cantidad de acciones que el usuario debe efectuar para alcanzar un objetivo, etc; 3) Desde el punto de vista de componentes no interactivos: un proceso batch nocturno que demore más de 24 horas en ejecutarse, por ejemplo, es completamente inusable.

  11. Ingeniero de los Espacios en Blanco: La arquitectura de un sistema a menudo consiste en un montón de "cajitas" conectadas por flechas. Sobre esas flechas anotamos cosas como "XML/HTTP" o "RMI", etc. El espacio en blanco entre las cajas es llenado por componentes de hardware y software (ej: redes, firewalls, servidores, cables oceánicos). Como arquitectos somos los Ingenieros de los Espacios en Blanco. Debemos especificar las flechas que unen componentes de la forma más detallada posible, respondiendo preguntas como: ¿Con qué frecuencia el componente A invocará al componente B? ¿Cómo debería reaccionar A ante una no-respuesta de B? ¿Cuánto debería esperar la respuesta? ¿Cuántas veces debería reintentar? ¿Qué sucede si la interfaz de B es actualizada mientras que el cliente A no?

  12. Dialecto de la Profesión: Los patrones y anti-patrones pueden ser muy útiles para facilitar la comunicación entre arquitectos. Los patrones pueden clasificarse en cuatro grandes categorías: 1) Patrones de Arquitectura: definen el marco de arquitectura a alto nivel (Ej: EDA, SOA, ROA, Pipeline, etc); 2) Patrones de Aplicaciones Enterprise: especifican cómo se deben diseñar las aplicaciones dentro del alcance de una arquitectura empresarial más grande (Ej: DataMapper, DTO, MVC, etc); 3) Patrones de Integración: importantes para el diseño y la comunicación de conceptos que involucran el intercambio de información y funcionalidad entre componentes, aplicaciones y sistemas (Ej: FileTransfer, RPC, Messaging); 4) Patrones de Diseño: especifican patrones de más bajo nivel para implementar funcionalidades comunes (Ej: Singleton, Visitor, Factory, Observer, etc). A pesar de que los Patrones de Diseño parece que son de demasiado bajo nivel para los arquitectos, forman parte del vocabulario estándar que facilita la comunicación entre arquitectos y desarrolladores. 


  13. La Heterogeneidad Gana: En los últimos años, el incremento en el ancho de banda ha permitido que una nueva generación de tecnologías de interoperabilidad basada en texto (XML/SOAP, RESTful, JSON, etc) proliferara, formando ecosistemas altamente heterogéneos. Hoy más que nunca la programación políglota está en auge. Los arquitectos pueden ahora combinar las herramientas más potentes, permitiendo elegir el lenguaje y/o paradigma más apropiado para resolver problemas específicos. El trabajo del arquitecto se ha vuelto aún más difícil, ya que los silos tecnológicos se están desmoronando. Debemos abrazar la heterogeneidad, pensar fuera de la caja, aprovechar la diversidad.

  14. Enanos, Elfos, Magos y Reyes: El personaje de la novela Cryptonomicon clasifica a las personas en enanos, elfos, magos y reyes. Los enanos, artesanos trabajadores; los elfos, elegantes y cultos; los magos, poderosos y mágicos; los reyes, visionarios que saben lo que hay que hacer con todos los demás. En esta clasificación, un arquitecto es un rey. Debe estar familiarizado con todos estos personajes, y asegurarse de que la arquitectura tiene roles para todos ellos. Una arquitectura diseñada solamente para una sola clase de personas se verá seriamente limitada en su alcance, ya que sólo puede aproximarse a los problemas de una única manera.

  15. Aprende de los Arquitectos de Edificios: ¿Cuántos Arquitectos de Software ven su rol como solitario y principalmente técnico? ¿No es más bien que son los conciliadores, intermediarios y árbitros de las facciones en conflicto entre los stakeholders? ¿Cuántos abordan su trabajo con un espíritu puramente intelectual, sin dar debida importancia a los factores humanos? ¿Tienes la fortaleza de destruir un trabajo fallido? ¿Qué has demolido recientemente? En la Arquitectura el fin debe dirigir la operación. El objetivo es construir bien. Un buen edificio cuenta con tres condiciones: comodidad, firmeza y placer. ¿Cuándo fue la última vez que viste una pieza de software cuya arquitectura te dio placer? ¿Es tu objetivo dar placer con tu trabajo? Buscamos la perfección y, sin embargo, ninguna Arquitectura puede ser verdaderamente noble si no es imperfecta.

lunes, 2 de septiembre de 2013

Infinispan en OpenShift

Infinispan es la caché distribuida que viene en el JBoss Application Server a partir de la versión 7 (o EAP 6). Se trata de un datastore clave/valor, que puede funcionar como caché distribuido o plataforma de Data Grid. De OpenShift creo que alguna vez he hablado en este blog, y si no lo hice, les recuerdo que se trata de la solución PaaS (Platform as a Service) de JBoss; en pocas palabras: un JBoss en la nube.

¿Quieren correr Infinispan en OpenShift? ¡Sencillo! Pueden tomar el siguiente proyecto de ejemplo armado por lunafromthemoon desde github:


Y en unos minutos tener funcionando su propio Infinispan en la nube.

Infinisquickstart en mi OpenShift

El código fuente sale de uno de los quickstart más simples de Infinispan que usa un cliente Java (protocolo Hot Rod). En el mismo se puede ver cómo la caché es traída por JNDI e inyectada usando la anotación @Resource, para luego utilizarla como si fuera un Map. De hecho es un Map, ya que org.infinispan.Cache implementa java.util.Map.

En el proyecto de lunafromthemoon pueden encontrar las instrucciones para descargar el código y subirlo a su espacio de OpenShift.

sábado, 24 de agosto de 2013

Sobre Arquitecturas y Arquitectos

No hay una definición única de Arquitectura en el mundo de sistemas. A menudo se habla de módulos, componentes y conectores, diseño de alto nivel, modelos conceptuales, estilos de arquitectura, patrones, gobierno, atributos de calidad, el sistema como un todo, el gran cuadro, liderazgo técnico, lineamientos, estrategia, visión y un muy largo etcétera.

Simon Brown, en su libro Software Architecture for Developers, define a la Arquitectura primero como sustantivo, como estructura: la descomposición de un producto en una colección de componentes e interacciones, y luego como verbo, como el entendimiento de lo que se debe construir, creando una visión que guíe dicha construcción y sirva para comunicar y tomar decisiones a lo largo de todo el proyecto. En resumen, dice Brown, la Arquitectura es una cuestión de estructura (sustantivo) y visión (verbo).

Pero dado que los sistemas son grandes y complejos, podemos afirmar que toda Arquitectura (estructura y visión) será consumida por muchos distintos usuarios: técnicos, no técnicos, de infraestructura, seguridad, redes, datos, base de datos, integración, negocio, procesos, etcétera. Podemos decir que toda Arquitectura presenta disonancia conceptual, ya que distintos tipos de usuarios consumen distintas vistas. Esto es lo que da origen a distintos tipos de Arquitectura y distintos tipos de Arquitectos.

Arquitectura de Aplicación

Los bloques de construcción de las aplicaciones son componentes de software e incluyen "cosas" como lenguajes de programación, librerías, frameworks, APIs, etc. La arquitectura de una aplicación es descrita en términos de clases, componentes, módulos, funciones, patrones de diseño, paquetes. En esencia, se trata de software y de la organización del código fuente.

Arquitectura de Sistema

Los bloques de construcción de los sistemas son un mix entre software y hardware. Subimos un nivel y encontramos que un sistema está compuesto por una colección de aplicaciones. Muchas de esas aplicaciones pueden utilizar distintas tecnologías; pongamos el ejemplo de un sistema web, en el que típicamente tenemos browsers que interpretan HTML, CSS y JavaScript, middleware que ejecuta código Java, y bases de datos que entienden de SQL; cada capa física cuenta con su propia arquitectura de aplicación.

Los sistemas de software nunca viven aislados. Hoy más que nunca, es común que muchos sistemas tengan que comunicarse entre sí. Por esto, la Arquitectura de Sistemas involucra también aspectos de integración e interacción entre distintos sistemas.

Arquitectura de Software

Simon Brown prefiere definir a la Arquitectura de Software como la combinación entre la Arquitectura de Aplicación y la Arquitectura de Sistema.


En otras palabras, Arquitectura de Sofware es todo lo relacionado con los elementos significativos de un sistema de software; desde la estructura y los fundamentos del código fuente hasta el despliegue exitoso de ese código fuente en un entorno real de ejecución. Por esta razón, la Arquitectura de Software, irónicamente, abarca software y también infraestructura.

Arquitectura de Empresa

Sigamos subiendo, alejándonos con la cámara para distinguir el bosque completo de sistemas de toda una empresa, la selva de artefactos de software, enlatados, desarrollados, tercerizados, legados, etc, etc, y las aristas que interconectan y/o concentran estos nodos, como pueden ser ESBs, BPMs, colas de mensajería, u otras tecnologías.

La Arquitectura de Empresa generalmente se refiere al tipo de trabajo que sucede en toda una organización. Los bloques de construcción de una empresa no son sólo piezas tecnológicas de hardware y software, sino también personas y procesos que hacen que la organización trabaje efectiva y eficientemente. La Arquitectura de Empresa no trata sobre detalles de implementación, detalles de cómo funciona esta tecnología o aquélla, sino de cómo utilizar la tecnología, las personas y los procesos en el contexto completo de la organización, y cómo interactúan todos ellos con el negocio.

Hace poco estuve leyendo un poco sobre ArchiMate, un estándar de lenguaje de modelado de Arquitecturas Empresariales que sirve para describir, analizar y visualizar la arquitectura completa de una organización a través de sus dominios de negocio de una forma no ambigua.

Bloques de Construcción del estándar ArchiMate
Creo que ArchiMate es un lenguaje de modelado extremadamente útil para entender lo que es la Arquitectura completa de una Empresa.

Otras Arquitecturas

Dependiendo del grado de adicción que una organización posea a las clasificaciones y a las especializaciones, podemos encontrar otros tipos de arquitecturas, como:
  • Arquitectura de Infraestructura
  • Arquitectura de Seguridad
  • Arquitectura de Solución
  • Arquitectura Técnica
  • Arquitectura de Red
  • Arquitectura de Datos
  • Arquitectura de Hardware
  • Arquitectura de Integración
  • Arquitectura de Base de Datos
  • Arquitectura de Información
  • Arquitectura de Proceso
  • Arquitectura de Negocio
Algunos tipos de arquitectura pueden ser más fáciles de describir que otros. ¿Qué significa Arquitectura de Solución? Para algunas organizaciones, un Arquitecto de Solución es lo mismo que un Arquitecto de Software pero con la diferencia de que el primero no se embarra con detalles de implementación. ¿Qué significa Arquitectura Técnica? ¿Es el complemento de la Arquitectura de Solución? ¿Un Arquitecto de Software es un Arquitecto de Solución más un Arquitecto Técnico? ¿La Arquitectura Técnica involucra aspectos de software y de hardware? ¿Qué diferencia un Arquitecto de Integración de un Arquitecto de Software?

Probablemente toda esta pesadilla de especializaciones y mezcla de dominios sea la que trae tanta confusión y ruido en la definición de Arquitectura de Software.

Sobre los Arquitectos y sus Roles

Por supuesto, hablar de Arquitectura y de Arquitectos es casi lo mismo. En el primer caso nos referimos a la disciplina en sí y en el segundo a los profesionales que llevan a cabo esa disciplina. Siguiendo con lo visto hasta ahora, los Arquitectos de Aplicación serán responsables por la estructura y la visión de la Arquitectura de una Aplicación, los Arquitectos de Empresa serán responsables por la estructura y la visión de la Arquitectura de una Empresa, y así.

El libro Software Architecture for Developers, como imaginarán por su título, se centra principalmente en la Arquitectura de Software. Uno de los temas más interesantes es tratado en el capítulo 3 y es el Rol del Arquitecto de Software a lo largo de todo el ciclo de vida de un proyecto de software.


El capítulo no tiene desperdicio. En 2010, Brown publicó un artículo en InfoQ llamado Are You a Software Architect? que resume bastante bien esta problemática del rol del Arquitecto de Software. Por supuesto, la versión del libro es mucho más completa y actual, ya que es posterior al artículo.

sábado, 10 de agosto de 2013

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 2

Sigamos con la serie de posts inspirados en el libro 97 Cosas que un Arquitecto de Software Debe Conocer. El que quiera refrescar la memoria sobre los primeros 15 principios puede visitar el primer post de la serie.
  1. No Puede haber más de Uno: Este principio ataca directamente a las raíces de DDD y a la utopía de SOA de concebir un único Modelo Canónico para toda la organización. ¿Por qué no enfrentar la realidad de un mundo desordenado y permitir múltiples, inconsistentes, superpuestas representaciones, servicios, soluciones? Tomemos como ejemplo el mundo de los data warehousing. El esquema de datos habitualmente está desnormalizado, los valores importados y calculados se mezclan arbitrariamente, y presentan una visión de los datos muy diferente de las bases de datos subyacentes. Distintos modelos de dominio pueden servir para representar el mismo negocio en distintos contextos, y siempre podremos contar con Traductores o Transformadores que nos sirvan para mapear las propiedades con la metadata apropiada.

  2. Unidades de Negocio: Los Arquitectos deben actuar como un puente entre el negocio y las comunidades tecnológicas de una organización. El ROI debe servir como guía importante a la hora de poner en una balanza el valor de una funcionalidad versus el costo de entrega de esa funcionalidad. La transparencia es crucial. El Arquitecto, junto con los Líderes de Proyecto, deben hacer visible el proceso de construcción del software. Para esto, técnicas como las de LeanKanban y/o Entrega Continua pueden ser muy útiles. El negocio debe guiar el desarrollo de software.

  3. Kanban Board

  4. Simplicidad antes que Generalización; Usar antes que Reutilizar: Cuando haya dos soluciones posibles, favorece siempre la más simple y la que resuelve de forma más concreta el problema. Aunque bien intencionados, a menudo los componentes que fueron diseñados para uso general terminan no satisfaciendo necesidades concretas. Los componentes de software deben ser diseñados principalmente para su uso y que cumplan bien ese uso. La generalización efectiva proviene de la comprensión, y la comprensión conduce a la simplicidad. Podemos encontrarnos con la generalidad y la flexibilidad tratando de ofrecer soluciones específicas.

  5. Los Arquitectos deben Poner Manos a la Obra: Sin una buena comprensión de la gama completa de tecnologías, un Arquitecto es poco más que un Project Manager. Es difícil imaginar cómo los integrantes del equipo pueden tener confianza en su Arquitecto si el Arquitecto no entiende la tecnología. Esto no quiere decir que un Arquitecto no pueda pedir ayuda al equipo. El equipo debe sentirse parte de la solución, pero el Arquitecto debe escuchar el debate e identificar la mejor solución. Los Arquitectos no están sentados en una Torre de Marfil dando órdenes al equipo, sino que trabajan a la par del equipo buscando soluciones a los problemas más complejos.

  6. Integra Continuamente: Como Arquitecto, debes promover y fomentar el uso de Integración Continua en cada proyecto, y de las herramientas necesarias para su implementación. Automatiza los builds, la ejecución de las pruebas unitarias, de análisis estático de código, automatiza los despliegues en los distintos ambientes, integra el producto en un servidor de Integración Continua y allana el camino para la Entrega Continua, a través de un Deployment Pipeline (Tubería de Despliegue). La era de la construcción del software como un evento Big Bang ha terminado.

  7. Evita Errores de Planificación: Jugar con el Triangulo de Hierro para abaratar Costos o reducir Tiempos puede herir gravemente la Calidad del producto y conducir al fracaso del proyecto. Una entrega apresurada de cualquier eslabón de la cadena de montaje (diseño, desarrollo, testing) conduce directamente a atrasos y/o un mayor número de problemas en Producción. La experiencia nos demuestra que ciertas reducciones provocan un encarecimiento muy superior al ahorro buscado originalmente. Como Arquitecto es tu responsabilidad no negociar la Calidad. Recuerda que "ágil es rápido, no apurado".

  8. El Triángulo de Hierro

  9. Ventajas y Desventajas Arquitectónicas: ¡No puedes tenerlo todo! Tratar de cumplir todos y cada uno de los requerimientos conduce a una arquitectura inestable que no podrá cumplir nada bien (y sino pregúntale a los tripulantes del Vasa). Hay varias herramientas disponibles para determinar las ventajas y desventajas en el diseño de una arquitectura. Entre ellas se destacan las populares Architecture Tradeoff Analysis Method (ATAM)Cost Benefit Analysis Method (CBAM) del Software Engineering Institute (SEI).

  10. La Base de Datos como una Fortaleza: La nueva escuela dice: "despliega temprano y seguido; una línea de código en producción es mejor que diez en tu cabeza". Pero mientras que las reglas de negocio y las UI evolucionan rápido, las estructuras y las relaciones entre los datos por lo general no. Las bases de datos son el custodio final de los datos. La capa de aplicación que, por diseño, es efímera, no puede ser su perro guardián. El modelo de datos debe ser lo suficientemente robusto para rechazar datos que no le pertenecen y evitar relaciones que no tienen sentido. Las claves (primarias y foráneas), los índices y las restricciones de dominio que se declaran en un esquema son breves, fáciles de entender y verificar, y sirven como documentación. Las reglas de dominio codificadas en el modelo de datos son persistentes, y un cambio en la lógica de la aplicación no tira estas reglas a la basura.

  11. Usa la Incertidumbre como un Conductor: Una arquitectura eficaz es aquella que reduce la importancia de las decisiones de diseño. Esto significa que, como Arquitectos, al enfrentarnos a dos opciones, nuestro trabajo no es elegir A o B, sino preguntarnos cómo podemos diseñar para que la decisión entre A y B sea menos significativa. Donde hay incertidumbre sobre diferentes caminos a tomar, toma la decisión de no tomar la decisión. Retrasa la decisión real hasta que ésta pueda ser tomada de forma más responsable, basada en conocimientos más profundos, pero no tan tarde que no sea posible aprovechar ese conocimiento.

  12. El Alcance es el Enemigo del Éxito: Los Arquitectos de Software amamos los proyectos complicados. Por eso tendemos a expandir el alcance de los proyectos. Pero cuanto más grande el alcance, más probable es el fracaso. Como Arquitectos debemos reducir el alcance, no expandirlo. ¿Cómo? Entendiendo las necesidades reales (cuestiona cada requerimiento no explicado en términos de valor medible para el cliente), dividiendo y conquistando (es más fácil manejar muchos proyectos pequeños que uno muy grande), priorizando (la priorización nos permite entregar los requerimientos más importantes primero) y entregando resultados lo antes posible (ya que pocas personas saben lo que quieren antes de tenerlo). Las arquitecturas complejas fallan mucho más seguido que las simples. Reduciendo el alcance del proyecto, obtendremos arquitecturas más simples.

  13. Los proyectos grandes son más propensos a caer en la hamaca de Slabbovia

  14. La Reutilización involucra a Personas y Educación, no sólo Arquitectura: Incluso la más hermosa, elegante y reutilizable arquitectura (framework, librería o API) sólo será utilizada por la gente que sabe que existe, sabe cómo usarla y está convencida de que usarla es mejor que hacerla de nuevo. Si tus equipos no saben dónde encontrar los artefactos reutilizables o cómo reutilizarlos, optarán por el camino más natural: los construirán ellos mismos. ¡Y pagarás por ello!

  15. No hay un Yo en Arquitectura: Los Arquitectos de Software solemos volvernos arrogantes y a menudo nuestro ego termina comiendo al proyecto y a nosotros mismos. ¿Cuántas veces pensamos que nosotros entendemos mejor los requerimientos que el cliente? ¿Cuántas veces vemos a los desarrolladores como recursos contratados para implementar nuestras ideas? ¿Cuántas veces estamos a la defensiva e ignoramos ideas valiosas? ¿Y por qué sucede esto? Porque los Arquitectos somos personas con auto-confianza, con la carga de varios éxitos a cuestas, la gente nos respeta y no somos más que humanos. ¿Qué podemos hacer entonces para evitar caer en la trampa del ego? 1) Trabaja con el cliente para entender los requerimientos: ten en cuenta que tú no manejas la arquitectura, son los requerimientos lo que lo hacen. 2) Enfócate en el equipo: no son recursos, son tus colegas. 3) Chequea tu trabajo: el modelo no es la arquitectura. 4) Evalúate a ti mismo: piensa en tus interacciones humanas un rato cada día: ¿fuiste egoísta?, ¿reaccionaste negativamente?

  16. Obten la Vista de Mil Pies: En un diagrama de Arquitectura pequeñas cajas representan sistemas enteros y líneas pueden significar dependencias, flujos de datos, recursos compartidos, etc. Estos diagramas son una vista del software a 30 mil pies de altura, y el código fuente se encuentra al nivel de la tierra. Claramente necesitamos vistas intermedias, vistas a mil pies. Estas vistas pueden estar compuestas por múltiples métricas como cantidad de métodos, diagramas locales de clases, complejidad ciclomática, grafos de dependencias, vistas polimétricas de los módulos y paquetes. Sonar, por ejemplo, es una excelente herramienta que nos brinda este tipo de información.

  17. Prueba Antes de Elegir: Como Arquitecto debes identificar constantemente las decisiones inminentes. Siguiendo el principio de Lean de postergarlas lo más posible, cuando se aproxime el momento, elige a varios desarrolladores del equipo y aíslate un tiempo con ellos en una sesión de descubrir-probar-evaluar distintas soluciones, analizando las ventajas y desventajas de todas las que surjan. Por lo general, luego de un análisis de estas características, la mejor solución al problema suele ser evidente para todos. El Arquitecto no tiene que tomar la decisión, simplemente orquestar el proceso de toma de decisiones. La duración de estos "Hackatones de Arquitectura" dependerá de la complejidad de la decisión a tomar.

  18. Comprende el Dominio del Negocio: Es el rol del Arquitecto de Software entender el problema, los objetivos y los requerimientos del negocio, y traducir esas necesidades en una solución de arquitectura técnica. Conocer el Dominio del Negocio ayuda a un Arquitecto a decidir qué patrones aplicar, cómo diseñar para soportar la extensibilidad, y cómo prepararse para las tendencias de la industria.

sábado, 3 de agosto de 2013

Jugando al Candy Crush con Drools

El miércoles 24 de julio, Damián Lezcano dio una muy entretenida y original charla sobre Drools en Epidata. Para esto tomó un juego muy popular entre los internautas, el Candy Crush, que se hizo famoso gracias a Facebook, y paso a paso mostró, de forma didáctica, cómo crear reglas y estrategias con el objeto de superar los distintos niveles.


La charla comenzó con una introducción a Drools Expert, el motor de reglas de negocio, luego siguió con una introducción a Drools Fusion, el módulo CEP (Complex Event Processing), para terminar completando el ejemplo de un conjunto de reglas que sirven para jugar al Candy Crush. Además, en la charla se vio cómo crear un DSL (Domain-Specific Language) para que las reglas pudieran ser escritas en lenguaje español por cualquier persona no técnica, utilizando el editor de reglas del repositorio Guvnor.


Para poder probar las reglas, Damián Lezcano desarrolló una aplicación desktop Java con Swing, que captura el tablero del nivel 2 y, al activarlo, empieza a jugar solo tomando el control del mouse.


Damián Lezcano ha subido el código fuente de la charla a GitHub para que cualquiera pueda descargarlo y aprender sobre Drools. También ha abierto un blog con las instrucciones sobre cómo correr la aplicación Swing, importando las reglas en el repositorio Guvnor.


-------------------------
Blog de Candy Crush con Drools:
http://candycrushdrools.blogspot.com.ar/

GitHub al Código Fuente:
https://github.com/damianlezcano/proyectos-java/tree/master/charla-jugando-con-drools

domingo, 28 de julio de 2013

Catálogo de Artículos de Java EE 7

Excelente catálogo de artículos de Java EE 7, referenciados en una única página y clasificados por especificación:

sábado, 13 de julio de 2013

97 Cosas que Todo Arquitecto de Software Debe Conocer

Hay un libro llamado así: 97 Cosas que Todo Arquitecto de Software Debe Conocer. No lo he leído, pero su Wiki me parece más que interesante.


En este primer post dedicado al tema, comparto los primeros 15 principios expuestos en la Wiki:
  1. Nunca pongas tu CV antes que las Necesidades del Sistema: El mejor activo de tu carrera es una larga lista de clientes satisfechos dispuestos a recomendarte porque hiciste lo correcto para ellos y para el proyecto. Este "fondo de comercio" te servirá muchísimo más que el último chiche brillante en el último lenguaje brillante o el último paradigma brillante.

  2. Simplifica la Complejidad Esencial y disminuye la Complejidad Accidental: La Complejidad Esencial representa la dificultad inherente a cualquier problema (ejemplo: la complejidad de un dominio). La Complejidad Accidental surge de las piezas tecnológicas que construimos para mitigar la Complejidad Esencial (ejemplo: la complejidad de un framework).

  3. Es probable que tu mayor Problema no sea Técnico: La mayoría de los proyectos son construidos por personas; y esas personas son la base del éxito y el fracaso.

  4. La Comunicación es la Reina; la Claridad y el Liderazgo, sus humildes servidores: Olvida los documentos Word de 100 páginas; nadie va a leerlos. Usa herramientas de modelado, diagramas simples que puedan cambiar frecuentemente, reúne al equipo en una pieza y comunica tus ideas en pizarrones, sácales fotos a los pizarrones y compártelas. El arquitecto debe ser también un líder. Ten a los desarrolladores de tu lado, trabaja con ellos, déjalos expresar sus ideas, genera un ambiente cómodo de trabajo. Haz lo mismo con los demás miembros del equipo: testers, analistas de negocio, líderes de proyectos, etc.

  5. Arquitecturar es Balancear: La Arquitectura de Software abarca mucho más que las clásicas actividades técnicas que hacen a la profesión; también involucra los requerimientos de negocio  de todos los stakeholders del proyecto. Es trabajo del Arquitecto poder balancear los aspectos más técnicos con las prioridades de otras áreas orientadas al negocio y a la rentabilidad del software a construir y mantener.

  6. Busca el Valor en las Capacidades Requeridas: A menudo, los clientes y los usuarios finales señalan lo que piensan que es una solución viable a un requerimiento, mezclando lo que es el dominio del problema con el dominio de la solución. Para evitar esto, es aconsejable organizar una serie de workshops y reuniones donde los arquitectos se enfoquen en las necesidades del cliente, ayudándolos a descubrir el "por qué" del requerimiento. Estas discusiones deberían evitar los aspectos técnicos, para que los clientes y usuarios puedan enfocarse en el dominio del negocio que conocen y no en el dominio del desarrollo de software.

  7. Administrando Requerimientos de Software

  8. ¡Ponte de Pie!: Si estás comunicando tu visión hacia otras personas, ¡ponte de pie! Así sea una revisión formal o una discusión informal, ¡ponte de pie! Sobre todo si los demás están sentados. Ponerse de pie automáticamente transmite autoridad y confianza en uno mismo. El contacto visual y el lenguaje corporal son elementos muy importantes de la comunicación. Cuando uno se pone de pie, tiende a controlar mejor la voz, hablando claro y fuerte, y reduciendo la velocidad a la hora de remarcar conceptos importantes.

  9. Los Rascacielos no son Escalables: A menudo comparamos a la Ingeniería de Software con la  Ingeniería Civil. Sin embargo, nadie en su sano juicio empieza a construir una obra de Ingeniería Civil sin saber cómo será cuando esté terminado. Agregar pisos adicionales a un edificio existente es costoso y de un riesgo incalculable, por lo que nos esforzamos por evitarlo. Una vez diseñado, no se supone que un rascacielos pueda cambiar de ubicación. Por eso es que, en contraposición con el proceso de cascada, hoy en día contamos con procesos ágiles de desarrollo, en los que podemos ir desplegando continuamente, a la vez que vamos refactorizando, corrigiendo e incluso reescribiendo funcionalidades que a priori no estaban definidas, iterando de forma flexible con el fin de poder satisfacer las necesidades del negocio a medida que el software se va construyendo.

  10. Estás negociando con más frecuencia de lo que Piensas: Lo último que quiere un negociador es hacer concesiones en la primera demanda. Cuando el líder de proyecto nos pregunte si realmente es necesario ese nuevo servidor, tenemos que hacerle entender las terribles desventajas de no tenerlo y negociar, siempre negociar, para que la peor opción técnica siempre sea el último recurso.

  11. Cuantifica: "Rápido" no es un requerimiento, tampoco "flexible", tampoco "extensible", ya que definidos de esta forma no hay manera de medirlos. Una de las grandes responsabilidades del rol del Arquitecto es conseguir que el sistema alcance estos Atributos de Calidad y balancear el constante conflicto e inconsistencia entre ellos. Sin criterios objetivos, el Arquitecto está a merced de los caprichos del usuario o de las obsesiones de los programadores. ¿Cuántos? ¿En qué plazo? ¿Con qué frecuencia? ¿Qué tan pronto? ¿Aumentar o disminuir? ¿En qué proporción? La próxima vez que alguien te diga que el sistema necesita ser "escalable", pregúntale cuándo cree que va a aumentar el número de usuarios, en qué cantidad, por qué.


  12. Una Línea de Código Productivo es más Valiosa que 500 de Especificación: Las Especificaciones por sí solas no tienen valor. El objetivo final de un proyecto de software es funcionar en producción. El diseño no es más que un medio para un fin, no un fin en sí mismo. La arquitectura siempre debe ajustarse a las restricciones del mundo real.

  13. No hay una Única Solución para Todos los Problemas: Un gran problema en la industria del software es que las personas son a menudo responsables de la solución de problemas que requieren más Sentido Contextual (a.k.a. Sentido Común) del que han acumulado. El conocimiento más importante de Patrones de Software es el de comprender cuándo aplicarlos y cuándo no. Los Arquitectos deben desarrollar y ejercer el Sentido Contextual en la formulación y solución de problemas.

  14. Nunca es Demasiado Pronto para Pensar en Performance: La gestión de los Atributos de Calidad es una de las competencias principales del Arquitecto de Software. Sin embargo, es muy común que se cometa el error de testearlos demasiado tarde dentro del ciclo de desarrollo, y muchas veces esta tarea se delega al equipo de Operaciones. Si el rendimiento es un requerimiento importante, entonces las pruebas de performance deberían planearse y ejecutarse lo antes posible. Tener en cuenta la performance en fases tempranas nos da la ventaja de ir atacando los issues arquitecturales de forma incremental, armar el ambiente cuando todavía es relativamente sencillo, y tener métricas de calidad actualizadas a lo largo de todo el ciclo de desarrollo.

  15. La Arquitectura de la Aplicación determina el Rendimiento de la Aplicación: Muchos Arquitectos de Software creen que cambiando de vendor de infraestructura, o tuneando la existente, será suficiente para resolver los problemas de performance de una aplicación, y utilizan benchmarks para avalar su decisión. Pero si sobre esa infraestructura se despliegan aplicaciones ineficientes, no preparadas para la carga esperada, entonces ningún vendor o tuning alcanzará el rendimiento deseado y la escalabilidad seguirá siendo inalcanzable.

  16. Commitear y Salir Corriendo es un Crimen: Escenario: desarrollador se tiene que ir temprano, commitea, se va y deja el sistema de build roto. Esto es grave porque los desarrolladores que quedan no pueden sincronizarse con el repositorio; saben que, si lo hacen, sus copias locales también se romperán. Aquí es donde el Arquitecto, quien ha puesto mucho esfuerzo en la creación de una arquitectura flexible, en enseñar a los programadores prácticas ágiles como el desarrollo basado en pruebas, y en configurar un servidor de Integración Continua, debe fomentar una cultura en la que no está bien malgastar el tiempo de los demás, ni cortar el flujo de trabajo. Para esto, el Arquitecto debe brindar un build system rápido y cómodo, con mocks que simulen conexiones con sistemas externos, servidores livianos para las pruebas de integración, bases de datos en memoria, dependencias mínimas, módulos desacoplados, y lo que haga falta.

sábado, 22 de junio de 2013

Buscar un Componente JSF por su ID Relativo del Lado del Servidor

Esta semana he sufrido un déjà vu. Necesitábamos obtener un UIComponent desde un ManagedBean en una aplicación JSF y no contábamos con la ruta absoluta que pedía la API que estábamos usando. Recordé entonces que esto con Seam 2 era trivial, pero como no estábamos usando Seam, necesitábamos una manera de encontrar el componente en el árbol de componentes del lado del servidor por su ID relativo.

Entonces recordé que yo ya había hecho esto en una vieja aplicación JSF.

JSFComponentFinder

Googleando un buen rato y con una idea fija en la cabeza, todo se encuentra. En este post está la solución: How to Find an UIComponent in ViewRoot.

Así que, tomé el código fuente y creé mi propia clase JSFComponentFinder.

Aplicación JSF de Prueba

Para probar el JSFComponentFinder armé una aplicación JSF Java EE 6. Para esto, partí del arquetipo para Maven de JBoss: jboss-javaee6-webapp-archetype. Luego, edité el index.xhtml para que tuviera unos pocos inputText y outputLabel vacíos con el único fin de poder buscarlos del lado del servidor. Debajo de estos tres inputs, puse otro inputText en el cual uno puede escribir el ID relativo del componente que se desea buscar. Al pulsar el botón Find, debajo aparecerá el ID absoluto, la ruta completa, del componente, que en el ejemplo de los inputs simplemente es el nombre del formulario, seguido por el separador de dos puntos, seguido por el ID relativo; en este caso es simple.

http://jsfcomponentfinder-elfrasco.rhcloud.com/index.jsf
El código fuente de la aplicación de prueba la subí a GitHub para el que desee consultarlo:
https://github.com/elfrasco/jsf-component-finder

El arquetipo de JBoss está muy bueno, pero es demasiado específico para JBoss AS para mi gusto. Así que modifiqué el pom.xml para que fuera más genérico, tomando únicamente la dependencia de la especificación de Java EE y sacando las librerías de hibernate y arquillian que para este ejemplo tan pequeño no hacían falta.
<dependency>
    <groupid>javax</groupid>
    <artifactid>javaee-api</artifactid>
    <version>6.0</version>
    <scope>provided</scope>
</dependency>
Así, minimalizando y estandarizando el proyecto, al ejecutar:
mvn clean install
Obtendremos un WAR que podremos desplegar en cualquier servidor de aplicaciones Java EE 6.

JSFComponentFinder en OpenShift

Para seguir jugando un poco más, decidí probar mi humilde aplicación de ejemplo en OpenShift y, una vez agregándole el perfil OpenShift y el directorio deployments requeridos por el cartridge de AS 7, funcionó perfecto.

Aquí lo pueden ver funcionando: