Resumen de la primera emisión de OpenTalks de JavaMéxico

El sábado 16 de octubre de 2010 en el ITESM de la Ciudad de México se concretó la iniciativa de JavaMéxico de crear un espacio para compartir experiencias, charlas relacionadas a la tecnología, con participación de gente de la propia comunidad, para la comunidad. El aula magna 7 del complejo comenzó a recibir a los entusiastas asistentes. Los avatares comenzaron a encontrar similitudes con sus rostros. Los comentarios y la camaradería se hizo presente. Cuando comenzó el registro oficial, muchas caras se habían reconocido, otras más conocido por vez primera, aún cuando se habían hablado en muchas ocasiones mediante los foros del sitio. En este preámbulo, Javier Benek se levantó, y con breves palabras inauguró oficialmente las reuniones formales de JavaMéxico. Los padrinos del evento, Enrique Zamudio y Javier Castañón. Las OpenTalks habían nacido. Que de sus proyectos y experiencias se hable por mucho tiempo.

Benek comenzó hablando de JavaMéxico, de la dinámica del sitio y del procedimiento para futuras emisiones del evento. Con todo listo y preparado, el Ing. Enrique Zamudio presentó su proyecto, jAlarms, un mecanismo de notificación a los administradores y desarrolladores involucrados, mediante los medios disponibles, con bajo impacto en la codificación e integración muy rápida. Su objetivo es mandar notificaciones sin impactar el rendimiento de la aplicación.

La idea surgió de la carencia de un proyecto similar. Tras una enorme e infructuosa búsqueda, se pensó en un proyecto con pocas dependencias, siendo una manera de contribuir al software libre, liberándolo con licencia LGPL, la cual describió brevemente para la audiencia.

La descripción del proyecto en voz de su creador, desde un AlarmSender se pueden enviar notificaciones por distintas vías: correo electrónico, un mensaje por el protocolo del mensajero de M$N, Twitter o la posibilidad de personalizar un canal. Posee un AlarmSender como Singleton.

Los canales disponibles al momento de la charla son: Test (imprime a STDOUT), correo electrónico por medio del JavaMailSender de Spring (en el JAR core), sin dependencia adicional por SMPP, enviando un SMS vía SMPP 3.4, enviando mensajes a contactos del M$N, por HTTP valiéndose de un GET/POST, por una CLI, o pudiendo ejecutar un programa externo.

Si se tiene una aplicación muy grande, pueden ponerse filtros para que ciertas alarmas sólo lleguen a ciertos sitios, por ejemplo, para enviarse a ciertos tipos de personas por ciertos canales. Al canal de Twitter se le pueden elegir ciertos criterios, al de M$N, definirle grupos de destinatarios o usar default para enviar a todos. Es tan configurable y extendible como se desee o necesite.

JAlarms utiliza Spring 3, pero no debiera tener problemas en Spring 2.5, pues sólo se vale de @Required y el JSR-250,@PortConstruct y @PreDestroy en el canal de M$N para configurarse. El canal de correo y el de M$N tienen características específicas.

Para utilizar jAlarms, en el applicationContext de Spring unas cuantas líneas hay que agregar, y en el código unas más sobre cómo mandar la alarma. Así de sencillo.

Entre los planes a futuro están el JMS de Apache Camel, ampliar el canal de Twitter para usar mensajes directos. Se tiene soporte de OAuth. En el interceptor de Log4J, que hubiera algo para escuchar vía Asterix. Se pueden hacer canales propios.

Enseguida, se mostró una demo. Abrió Eclipse. Para que no haya una avalancha de alarmas, cada canal puede configurar su tiempo entre notificaciones (para no saturarse por "insistencia" del usuario). Mostró una rápida configuración mandando errores, categorizó los "envíos" y puso qué habría de mandar por Twitter y qué no. Después, agregó cuentas de correo de los asistentes y mandó un comando en consola usando notify-sender. Tras ello describió el ExceptionHandler y sus posibilidades para con jAlarms.

En las preguntas y respuestas dio contextos de uso, pues no sólo es para tratar excepciones, sino cosas que se tiene que atender por humanos, que haya menos de $10,000 en saldo, se requiera algún tipo de intervención, se cayó la base de datos, falló la conexión de aquél lado, no responde el banco, etcétera, es decir, cualquier cosa que precise de una alarma.

En la página oficial del proyecto se pueden pedir características o aportarlas: http://jalarms.sourceforge.net/, http://www.javamexico.org/blogs/ezamudio y @chochosmx en Twitter. Por último, mostró las dos clases abstractas que deben extenderse para hacer un canal propio. Extendiendo creatteSendTask() y hasSocket() de jAlarms.

abstract protected Runnable createSendTask(String msg, String source);

abstract protected boolean hasSource(String alarmSource);

Unos minutos se tomaron de receso, mientras los asistentes compartían ideas para implementar lo que habían visto. Dieron las doce del día y se dio paso la segunda charla, de arquitectura. El Ingeniero Javier Castrejón inició diciendo que originalmente pensó se trataría sobre documentación de arquitectura, mas como en el anuncio del evento venía arquitectura a secas, decidió hablar sobre arquitectura para quienes hacen y mantienen funcionando sistemas intensivos en software.

El Ing. Castrejón ha trabajado en TI desde 1989. La mayoría de la gente apunta que 20 años dan experiencia. Él se remitió con la esperanza de pensar en 20 años de vivencias, más que un año de vivencias repetido 20 veces. Inició en forma con la siguiente aseveración:

«¡Qué logro ser arquitecto! Ganas el respeto de la gente, todos quieren hablar contigo, todo es sexy, o a lo mejor no toda la gente es tan sofisticada». Primero, pidió, definamos la materia del trabajo del arquitecto.

Martin Fowler define la arquitectura como lo que utilizamos cuando queremos hablar del diseño pero queremos "inflarlo" para que suene más importante. Esta percepción también aplica en muchos casos para el "arquitecto", pues parece implicar tener mayor responsabilidad.

En el IEEE 1471 aparece la práctica en ingeniería industrial para definir arquitecturas. Se tardarán años en llegar a ella y se le siguen haciendo revisiones ("manoseando") en comités. Se habla de la organización fundamental y la desglosará porque la especificación se está sobrecargando.

Tenemos la arquitectura como la imagen, una estructura, un diagrama, una representación. En realidad, no hay problema por llamarle arquitectura al diagrama y a la implementación, siempre que se vea y tenga en cuenta que no es lo mismo la descripción de la arquitectura y la arquitectura en sí misma.

Se le puede describir como un "mapa de alto nivel" y se puede ver como una toma satelital: se entiende nada y sirve para lo mismo. En la opinión del expositor, más que "de alto nivel" se requieren descripciones esenciales, así como respirar. Luego muestra otra vista con algunos iconos de la ciudad. Hay distintas perspectivas y sobre ellas se forman vistas u opiniones. Le gusta pensar que la arquitectura habla de lo esencial, pudiendo ser distinto para diferentes personas. El elemento clave es el contexto, dado por el ambiente que engloba el tiempo del que emerge. No es el mismo resultado con o sin requerimiento, con profesionales o becarios, la temporalidad, la estrategia, los handicaps, todos los elementos tienen interdependencias con el entorno.

«¿Arquitectura no es lo mismo que estructura?» Comenzando porque no hay un acuerdo entre los profesionales, la IEEE no habla de "estructura", para no caer en situaciones embarazosas como intentar responder a "cuál es la arquitectura de Internet". Arquitectura es la organización fundamental de un sistema continuo en sus componentes, las relaciones entre ellos y el ambiente y los principios que guían su diseño y evolución.

«No todo es estructura». La arquitectura intenta abstraer los principios que guían el diseño y evolución, no necesariamente "tangibles" como la estructura. Por lo tanto los arquitectos se socializan. Quienes lo hicieron acordaron los elementos esenciales o más importantes en un sistema. Si alguien rompiera los acuerdos, rompería la arquitectura. Las pláticas sobre lo esencial a mantener del sistema es la arquitectura. Si es una tarea social, la arquitectura, a partir de acuerdos o contextos, es aún más social, haya o no alguien con el rol.

El arquitecto ejerce liderazgo, no es gerente. Ve qué es importante y procura que llegue a buen término. Llegar por el "visto bueno" del "arqui" es mostrar diagramas, sin hablar de su construcción o escalabilidad, por muchos estándares que se digan adoptar, desde superstacks con todo listo para desempaquetar, hasta Golden stacks de hardware. Al presentarlos quieren "una firma". Ese es una representación clásica que se debe romper. Debe iniciarse, en su lugar, por un medio idóneo para el desarrollo del proyecto: ¿Quieres campañas de mercadotecnia? No uses un workflow, usa un CRM. La arquitectura es entonces un proyecto colaborativo.

Existen distintas formas de ver el rol del arquitecto. Dos extremos se evidencian, según la cantidad de decisiones, pudiendo ser desde una persona que toma muchas decisiones hasta muchas personas que toman pocas decisiones cada una. En general, hay varios tomando pocas decisiones y acordándolas con los demás en los proyectos exitosos.

Comunicar y colaborar cuesta trabajo. Pero ello reditúa.

En muchos ámbitos a quien hizo el diseño primero se le llama arquitecto. Un arquitecto de aplicación es el responsable de la solución de punta a punta, con enfoque holístico. El arquitecto de solución gestiona sobre el negocio de dominio. Más arquitectos pueden surgir según los intereses específicos.

El expositor hizo una encuesta rápida en la sala y se sintieron más "satisfechos" con el modelo de varias personas tomando pocas decisiones. El arquitecto no necesariamente es una persona técnica, pero debe tener soft skills. El principio de Dilbert o el de Peter aplica. Un arquitecto requiere experiencia, «Been there, done that», alguien que "ya se equivocó", que ya le costó bien y bonito. Eso significa "tener experiencia". Gestionar el equipo de trabajo, el trato con la gente.

Patrones de arquitectura son importantes, pero son más importantes los roles. Conocer sobre los involucrados en el desarrollo, el proceso desde requerimientos hasta su producción, cómo trabaja una computadora y cómo funciona un equipo. El que escapa de esta definición es el arquitecto de negocio, enfocado en alinear los procesos de negocio con la estrategia general de la organización, siendo el menos técnico de todos. Los demás sí deberían programar, desplegar, etcétera.

A partir de allí, los siguientes pasos se encaminarían a ver cómo se desarrolla una arquitectura desde cero, nada hay tan intimidante que una hoja en blanco o sistemas viejos para comunicarse.

En contenido, ¿qué protocolos se siguen para revisar una propuesta? El contenido de la arquitectura descansa en estándares, poner límites en qué herramientas se usarán y cuáles no para combatir en algo la heterogeneidad. ¿De cuántos proyectos consta el portafolio? Poner métricas para demostrar que dan valor al negocio. Presentarle a alguien para recibir buena retroalimentación. La actitud correcta para la comunidad de arquitectos. Principios para el respeto, orgullo y conexión. Después de lograr el buen ambiente, pase a los temas técnicos. ¿Cómo se evoluciona el Enterprise? De A a B, frameworks de arquitectura y un largo etcétera. El arquitecto actúa como embajador. Aunque no haya "visto bueno", habrá de tomar decisiones y habrá de imponerse. El consenso se logra cuando todos expongan su parte.

Pocos arquitectos para que se tomen responsabilidades, contra proyectos donde todos "cucharean" y se diluye la responsabilidad. El diseñador de sistemas es un sintetizador. Acotar responsabilidades y roles. La revisión de la arquitectura un proceso de diligencia de vida. Ese es el gobierno de arquitectura. Cuando es maduro es un Steering de arquitectura, si se le toma en serio. Como no hay libros o reglas para el diseño al límite, por ejemplo, se piden tantas opiniones como sea posible. Si se hará un marco de gobierno, véanse para que si alguien hace una lamentable equivocación, se afecte lo menos posible al proyecto, de reducir el riesgo, que el impacto sea mínimo.

Como ejemplos de altísimo riesgo, en bases de datos, ante fraudes bancarios, no debe darse ingreso físico por ley. El Virtual Case File del FBI de los noventas es otro ejemplo de alto riesgo. El departamento de defensa gringa es el mayor cliente de software del mundo. El puesto mejor pagado en 2010 en EEUU fue el de Software Architect. Detrás quedaron los médicos y los abogados.

Como conclusión: 1) la arquitectura no son patrones de diseño, no exclusivamente. 2) hay que aprender a negociar, a comunicarse. 3) sugiera el título de "líder técnico" antes del de "arquitecto". Prefiera una "especificación técnica". El problema en México es cambiar el rol. Si es cuestión de sueldo, habrá que inventar otro título. Llegó la hora que se pueda crecer sin tener que ser Manager. Debe tenerse cierto empowerment para tener consensos y no acallar. Hard skills y soft skills. Aconseja comenzar como arquitecto de dominio (el que mejor se entienda). El poder de comunicarse con el negocio, analista y sentenciador. Dotes de humildad y de sentido común. Ser analista. El arquitecto en muchas organizaciones es quien no tiene gente a su cargo, sino cosas técnicas. Hablar de qué quiere cada persona.

Por último, llamarse "programador" con orgullo. Un programador de software debe programar con orgullo. Porque es capaz de hacerlo. Actualizarse y hacerlo. Aún el más administrativo tiene gran entendimiento de la tecnología, el profundo conocimiento desde data centers hasta el desarrollo de software. No hay aquí que no domine su materia, por eso es Senior, aunque sea contador de carrera.


Tras la segunda charla, se habló de nuevo de la organización de futuras sesiones. Se planteó de hablar "en vivo" sobre algún tema del foro, sobre problemáticas comunes, sobre discusiones (sí, discusiones como implica la voz en español) espinosas o novedades en tiempos breves. Se regalaron plumas, licencias de IntelliJ Idea y playeras con distintas preguntas, las últimas muy buenas de la voz del doctor Bárbaro Ferro. Se mencionó a Cafelog, Pascal en la JVM, que no hay contravarianza en valores de retorno, quién fue el creador de C++, sobre los premios Turing de computación, el MetaObject Protocol y el Object Common LISP, buscar las tácticas que ofrece un lenguaje, Smalltalk como el mejor orientado a objetos y se preguntó cuáles fueron los 5 lenguajes que Sun dio dinero para que la JVM soportara desde mediados de 2008. Por sí mismas, estas interrogantes debieran ser motivo suficiente para asistir. El poder de la comunicación y la interacción con gente afín es una motivación a la que muy pocas se le comparan. Este es el principal objetivo: compartir.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

muy bueno

Muy buen resumen!

Imagen de JaimeItlzc

Me gusto

Lo malo que no pude asistir.