lunes, 30 de septiembre de 2013

En el 2013 que ha pasado

Bien, pues este blog fue terriblemente abandonado por todos sus autores , je Aunque les digo, que los tres autores siguen vivos y coleando El Tuzo sigue en la institución de salud que yo deje en julio 2012. Chillicoder sigue pegando duro a Rails ... Técnicamente que ha pasado por mi vida de bytes He aprendido Node.js Me he metido a TOGAF y me he certificado, al igual que Archimate... Me adentre a ver los puntos de arquitectura de software y aterrizarlo con patrones de Fowler y POSA ... Y los MOOC me han ayudado mucho . Gracias a ellos se puede aterrizar el tema de Big Data, Programación funcional, arquitectura empresarial Estoy con deseo de un bocado de implantar una arquitectura empresarial que haga sentido a la organización que decida esa aventura ... No me he metido al asunto de emprendedores, aunque sigo de cerca varias ideas Gamification me inspira para algo así El tema de software factories aun no lo abandono como un concepto viable para implantar DSL, DDD, patrones SOA no reniego de ella, solo veo cuanto falta por rascar en el tema ... Sigo renegando de programadores, arquitectos y similares que son soberbios o que no hacen bien su chamba El Tuzo y otro nuevo amigo, Rafael Cruz, agregaron otra comunidad de arquitectura a la mexicana ...

domingo, 21 de octubre de 2012

No andaba muerto y ni andaba de parranda

Hola! Del grupo Tuzo, Martín, yo Gus me desaparecí por un rato muy prolongado. Por fin decidí plasmar algunas ideas ... En julio di mi brinco ya tan necesario y cambie de trabajo. Mi tiempo ya había acabado y a pesar de que mucho trabajo había por hacer aún, fue lo sano. Tuve muchos sentimientos encontrados pero ya estaba yo en una situación de agotamiento y estrés fuerte. Por un mes, en donde estuve explorando opciones, desde trabajar con un proveedor muy grande de software y patrocinador de los Avengers, en una farmaceutica, con una empresa de consultoría de procesos al final opté ingresara IT Era, para trabajar en temas de Arquitectura Empresarial. Ingresé el 16 de septiembre, no fue para mí desconocido el ambiente de trabajo. Me ha dado la oportunidad de ver TOGAF con mas detalle y explorar como aplicarlo. De hecho, regrese este viernes 19 de octubre de Quito, donde impartí el curso de TOGAF a un Banco de la región Pichincha. Fue una experiencia muy agradable, donde mi conocimiento fue útil. Tengo muchas ideas en mi cabeza sobre Arquitectura Empresarial. De hecho, me lleva a nuevas experiencias sobre integración a la Mexicana. Espero ser constante en escribir mis ideas en este blog

martes, 25 de septiembre de 2012

De vuelta a la actividad

Hola queridos 3 lectores,

Hasta hace unos meses me daba a la tarea de empaparme de conceptos de arquitectura empresarial, estudiando y leyendo con el fin de reforzar algunos proyectos que llevo a cabo, en esta ardua vida de búsqueda de oportunidades.

Me he topado en los últimos meses a diferentes retos tanto técnicos como laborales y de cada uno de ellos voy aprendiendo.

No había tenido oportunidad de agradecer a gusdelact por todo el apoyo que me brindo durante casi 8 anios de convivir juntos y enfrentar varias responsabilidades, he aprendido mucho de el, ha sido mi guru. En este largo camino de lo profesional te deseo mucha suerte mi estimado.

Ahora he quedado al mando por decirlo de una manera de un equipo de trabajo que sigue con la filosofia de este grupo de locos y eso me hace ser mucho mas responsable y cuidar al equipo. Sigo aprendiendo día con día que lo valioso que es el crecer tanto humanamente como profesionalmente para alimentarte de los buenos resultados.

Sigo aprendiendo que por mas que digas ser "algo" o saber de "algo" no vale mas que los hechos y el trabajo. Aprendo que a veces tienes que ver el traje del emperador aunque sea un poquito con tal de que te dejen trabajar. Aprendo que los "Pseudo Arquitectos"siguen siendo arrogantes y hasta tontos, pero que hay que lidiar con ellos. Creo en el trabajo y la honestidad de la gente que en verdad desea aprender por el deseo de hacerlo o no por el ego del saber.

Actualmente me encuentro con varios retos profesionales en mi institucion y fuera de ella cosas interesantes de TOGAF, de ALM, de SOA Reference, etc que les ire platicando poco a poco.

Espero nos vuelvan a leer y como dice un clásico ....

Por una integración mejor.

Hasta la vista

Tuzo



viernes, 19 de agosto de 2011

Primera fase de Arquitectura Empresarial, lista

Acabo mi día, reflexionando sobre el logro que tuvimos en mi equipo de trabajo

Gracias al entendimiento de modelos como TOGAF y Archimate, las diversas opiniones de los integrantes del equipo; logramos una versión de un repositorio de Arquitectura empresarial con un empuje inicial muy bueno.

Representa el salir de la teoría a la práctica

El demostrar que un "arquitecto" no es titulo nobiliario, sino se gana con trabajo

Acabamos celebrando, comiendo pizza, como una fraternidad, que nos une un interés común. Mejorar nuestro ámbito

Me daré tiempo para platicar los detalles técnicos

domingo, 31 de julio de 2011

Leyendo a Tanenbaum

Por andar rascando a temas de mainframe y anexas, acabe desenterrando el libro de Tanenbaum, Organización de Computadoras pero la segunda edición, de 1984.

Lo interesante, es que muchas personas del ramo de TI que se presumen arquitectos, deberín de leer este libro como ejemplo.

Sin presunción alguna, Tanenbaum se pone a trabajar en los diferentes niveles de la organización (arquitectura de computadoras) y metódicamente describe cada uno de ellos y explica muchas veces las decisiones que llevaron al diseño y las restricciones que presentan

Pues yo puedo decir, que gracias a que mi profesor de Arquitectura de Computadoras, tuve una visión del concepto de arquitectura. Me acuerdo que su definición de una arquitectura de computadora era la manera como se debe organizar los elementos de procesamiento de símbolos. Elegante definición, por que no se fue al nivel de bytes ni de hardware. Y lo interesante de esa definción, es que no solo cubre los niveles de hardware o firmware; sino de software; y como escribe Tanenbaum en su libro, el hardware y software pueden indiscriminadamente cambiar papeles.

Gracias a esa idea, cuando por primera vez tuve que hacer una arquitectura de solución, y de hecho sin tener precedentes teóricos del tema, salvo el ejemplo de arquitectura de computadoras; define la solución por bloques de procesamiento (como chips de software) que tenían una funcíon específica.

Algún para de años después me tope con que la disciplina de arquitectura en software era un tema extenso; pero por desgracia mal entendido.

Cerrando el tema con dos anécdotas.

En mi última asistencia al taller de Arquitectura Empresarial que impartió Cutter; me senté en una mesa, donde obvio, todos se decían arquitectos. Por un azar, una persona le dí clases en su momento y por cierto su compañero medio chistin (de los que dicen comentarios poco asertivos); y me dicen que trabajan para una sociedad de inversión algo conocida (y que también conozco por sus a veces erroneas percepcions en conceptos de CMMI, desarrollo, pruebas). Le pregunto a la persona en cuestión, estás en desarrollo? y pues hagan de cuenta que le dije una ofensa o la denigre, y también su expresión corporal mostro disgusto a lo que le insinue. Me contesto, como crees! Yo soy arquitecto empresarial! No me quiero imaginar que tipo de arquitecturas diseñaran ese par de personas, pero dudo que le sirva a los equipos de desarrollo. Un arquitecto es alguien que sabe de técnicas de desarrollo, de tecnología.

Otra mas, en el trabajo, se me acerca uno de los ingenieros de un proyecto "super importante" y me realizar preguntas sobre como hacer un tipo publish-suscribe con AJAX. Para no hacerles mas largo el cuento, le comento, pues hagan pruebas de concepto. Y a lo cual me contesta, pues es que el equipo de arquitectura es lógico, ellos no ven cuestiones de desarrollo.

Es decir, parece que mucha gente está tomando el concepto de arquitectura como si fuera la misma visión erronea de la gente de procesos o pruebas; que son gente que no acaban agregando valor y dibujando cajitas bien bonitas en PowerPoint o con herramientas más caras de "arquitectura"

Error muy malo. Lastima que no me aceptaron mi exposición para la Expo de Software Gurú, quería hacer un pequeño manifiesto de independencia hacia los susodichos arquitectos lógicos o de su torre de marfil, que según ellos con mucho estatus se dicen arquitecto, pero acaban no haciendo trabajando y metiendo confusiones

Me gustaría tomar a todos esos falsos arquitectos y sentarlos a estudiar los libros de Tanenbaum, a Date, a Patterson, Design Patterns de GoF, PoSA, EIP, el de compiladores de Aho, los 3 tomos de Knuth, un buen libro de referencia de mainframe; para que realmente tomen en cuenta todos los conceptos subyacentes para hacer una arquitectura sólida y no algo que acaba en papel y no da valor a los equipos de desarrollo.

Mis 2 únicos lectores, ojala me perdonen esta entrada poco objetiva, pero tenía que hacer cartasis escribiendo.

Con esto, me dan ganas de hacer el temario de un tipo diplomado de Arquitectura Empresarial y darlo gratis, como servicio a la comunidad de TI, donde pondría a estudiar a la gente en varios temas, y enseñarles que el título de arquitecto no se obtiene por que te nombren solo así, sino con humildad, experiencia, trabajo y conocimiento técnico.

jueves, 28 de julio de 2011

Domain Specific Languages (DSL) primer comentario

Para mi el concepto de DSL no fue dificil de entender, ya que desde hace casi 2 decadas me tope con ese concepto con un libro de Bertrand Meyer, llamado Introduction to the Theory of Programming Languages

En ese libro, Meyer expone los conceptos "básicos" para diseñar un lenguaje de programación, no se enfoca a decir como definir la sintáxis o los algoritmos de anális sintáctico. Se enfoca a explicar que un lenguaje de programación es una manera abstracta de manipular una máquina. De hecho, define una modelo simple de una máquina y un lenguaje de programación de alto nivel para dicha máquina

Recuerdo que una idea muy importante de este libro, es como explica que una plataforma de computación es completa si existen diversas maneras para manejarla. Es decir, como UNIX, donde existe un API para invocar al núcleo, o un shell para manejar comandos simples para crear nuevos comandos o interfaces gráficas como X Windows. Es decir, una plataforma de cómputo con una arquitectura que se puede extender y proporcionar herramientas mas orientadas a un problema de un DOMINIO en particular.

Cuando leí eso, me di cuenta que al definir un API de programación, hay que pensarlo como si definiera un lenguaje de programación, con su sintáxis, sus acciones semánticas. Y que también, para simplificar el uso del API, puede definirse un nuevo lenguaje que genere código sobre ese API.

Ahora, incios de siglo XXI, ese concepto se llama DSL y es una manera para lograr la extensión de plataformas de computo.

Me encontre esta referencia en la Dr. Dobss de Julio, Xtext

viernes, 1 de julio de 2011

Entre Middleware te veras

Que tal muchachos, feliz viernes!!!! yeeeah

Hace algunos meses por necesidades de un proyecto (por cierto muy interesante), nos invitan a participar en la parte de arquitectura de integración, que dicho sea de paso es usando plataforma OpenSource.

Herramientas Middleware muy interesantes son ocupadas dentro de la arquitectura algunas de ellas:
  • MDM - Talend Community Edition: Un excelente propuesta de Bases de Datos Maestros.
  • Application Server: Jboss
  • Enterprise Service Bus - Jboss ESB : De los ESBs mas intuitivos que me toco trabajar.
El proyecto involucra varios retos que si se plantean de manera general, son muy conocidos en el ámbito de integración en la industria, aquí algunos:
  • Comunicación con Bases de Datos Legadas
  • Comunicación con Aplicaciones Legadas que usan COBOL
  • Comunicación con una MDM
  • Comunicación con un BPM
  • y le podemos seguir.
Dentro de la arquitectura, se tomo la decisión de usar al ESB como mediador de todas las peticiones a los sistemas legados o propietarios (tal como se hace comúnmente), lo cual resulto muy interesante, ya que seria el ESB quien tendría que manejar conceptos de EIP en este sentido, tales como transformaciones, ruteo basado en contenido, Pipelines, etc.

Particularmente los Post siguientes, serán hablando del tema de Jboss ESB y estarán enfocados a como resolver ciertos escenarios de integración de los cuales comúnmente me he topado en estos ya 7 años como Arquitecto/Ingeniero de Integración de Aplicaciones, la mayoría trabajando con middleware de BEA (Aqualogic ESB, ALDS) ahora ORACLE (SOA Suite)

Les adelanto algunos temas puntuales del Jboss ESB que vamos a tocar en el uso de:
  • org.jboss.soa.esb.actions.soap.proxy.SOAPProxy
  • org.jboss.soa.esb.actions.routing.http.HttpRouter
  • org.jboss.soa.esb.actions.transformation.xslt.XsltAction
  • org.jboss.soa.esb.actions.ContentBasedRouter
  • org.jboss.soa.esb.actions.SystemPrintln
Cada uno de estos temas los veremos en conjunto con ejemplos de su uso.

Por una integración mejor, nos vemos pronto.

Saludos Tuzo