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.