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
viernes, 19 de agosto de 2011
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.
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
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
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
martes, 10 de mayo de 2011
Cambio
Aunque no debería usar este blog para cosas humanas, je, pues igual está relacionado con el tema
Ya llevo 7 y medio años donde trabajo. Ahí he madurado y aprendido muchas cosas y experiencias buenas y malas
Mi instinto y el odioso radiopasillo dice que ya es el momento final de mi trabajo
Sin embargo, no me siento mal, al contrario, veo que tengo muchas habilidades e igual ha llegado el momento de que la integración a la mexicana se abra a nuevos caminos
Les platicaré que pasa, esta semana seguro y se define algo
Ya llevo 7 y medio años donde trabajo. Ahí he madurado y aprendido muchas cosas y experiencias buenas y malas
Mi instinto y el odioso radiopasillo dice que ya es el momento final de mi trabajo
Sin embargo, no me siento mal, al contrario, veo que tengo muchas habilidades e igual ha llegado el momento de que la integración a la mexicana se abra a nuevos caminos
Les platicaré que pasa, esta semana seguro y se define algo
Iniciando TOGAF
Hola 3 lectores
Durante las últimas semanas he estado leyendo TOGAF, la parte básica
Si me he encontrado con un marco de referencia de arquitectura extenso y abstracto. Pero en esa abastracción, da mucho poder para ir de lo general a lo particular.
Pero también requiere de tener experiencia en este tipo de marcos, como CMMI, ITIL, PMP.
Ayer dí un taller de TOGAF, y si que me costó trabajo aterrizar, pero al mismo tiempo vi el poderío de conceptos como Enterprise Continum, ADM, Content Framework, Technical Reference Model
Me estoy poniendo como meta buscar certificación en TOGAF
Durante las últimas semanas he estado leyendo TOGAF, la parte básica
Si me he encontrado con un marco de referencia de arquitectura extenso y abstracto. Pero en esa abastracción, da mucho poder para ir de lo general a lo particular.
Pero también requiere de tener experiencia en este tipo de marcos, como CMMI, ITIL, PMP.
Ayer dí un taller de TOGAF, y si que me costó trabajo aterrizar, pero al mismo tiempo vi el poderío de conceptos como Enterprise Continum, ADM, Content Framework, Technical Reference Model
Me estoy poniendo como meta buscar certificación en TOGAF
sábado, 9 de abril de 2011
Archimate o de como si se puede modelar en serio
Hola 3 lectores
El mes de marzo fue muy bueno, por que se empezó el tema de Arquitectura Empresarial.
Como parte de la estrategia, el director de TI nos solicito utilizar Archimate para cuestiones del modelado.
El caso es que me puse aprender Archimate de volada, pero no fue dificil, por que me encontré con la grata sopresa de que es un lenguaje bastante completo y bien pensado.
A diferencia de UML, que se puede considerar como pobre en estos temas, Archimate propone un conjunto rico de elementos de su notación y que son completos para modelar el negocio, aplicaciones e infraestructura.
Y el Tuzo afortunadamente encontró una herramienta libre, llamada Archi la cual está muy bien hecha para cuestiones del modelado.
Con Archimate, el trabajo de modelar ya no cae en términos de la creatividad, sino que te va guiando. Les invito lean el libro de Archimate .
El concepot de puntos de vista (viewpoint) es muy importante, ya que te va indicando que debes modelar y como relacionar los diversos elementos.
El jueves 7 y viernes 8 de abril, estuvimos haciendo un ejercicio de modelado de dos aplicaciones y el tema hasta se vuelve adictivo; ya que el tiempo se va de volada al hacerlo y quieres poner más y más conocimiento de lo que se sabe de la aplicación
Adicional, de que se va formando un repositorio de activos de arquitectura y de lo que modelas, va constituyendo un grupo de activos.
Por fin, adios a la hojita de Excel que tanto odie para hacer el inventario de aplicaciones. Con Archimate vamos a poder expresar todos los conceptos de los que constituye una aplicación.
También estamos utilizando otra herramienta, comercial y con necesidad de licencia; que se llama BizzDesign Architect; pero la ventaja es que permite realizar el análisis de las relaciones entre los diversos activos y obtiene las tablas de cruce entre los distintos activos. Y tiene hasta un lenguaje para hacer consultas para hacer la mineria de los activos de la organización.
Y ahora estoy estudiando TOGAF, para tener ya el marco metodólogico para trabajar en el tema de arquitectura empresarial.
Estoy contento por la chamba que estamos haciendo y el equipo de personas que somos, muy bueno y con distintas perspectivas para atacar los diversos temas de arquitectura empresarial.
Con esto espero ya pasar de las presentaciones de PowerPoint a poder decir que estamos haciendo Arquitectura Empresarial ... bueno en parte, por que implica mucho mas alla de modelar. Aun faltan muchos retos por superar.
El mes de marzo fue muy bueno, por que se empezó el tema de Arquitectura Empresarial.
Como parte de la estrategia, el director de TI nos solicito utilizar Archimate para cuestiones del modelado.
El caso es que me puse aprender Archimate de volada, pero no fue dificil, por que me encontré con la grata sopresa de que es un lenguaje bastante completo y bien pensado.
A diferencia de UML, que se puede considerar como pobre en estos temas, Archimate propone un conjunto rico de elementos de su notación y que son completos para modelar el negocio, aplicaciones e infraestructura.
Y el Tuzo afortunadamente encontró una herramienta libre, llamada Archi la cual está muy bien hecha para cuestiones del modelado.
Con Archimate, el trabajo de modelar ya no cae en términos de la creatividad, sino que te va guiando. Les invito lean el libro de Archimate .
El concepot de puntos de vista (viewpoint) es muy importante, ya que te va indicando que debes modelar y como relacionar los diversos elementos.
El jueves 7 y viernes 8 de abril, estuvimos haciendo un ejercicio de modelado de dos aplicaciones y el tema hasta se vuelve adictivo; ya que el tiempo se va de volada al hacerlo y quieres poner más y más conocimiento de lo que se sabe de la aplicación
Adicional, de que se va formando un repositorio de activos de arquitectura y de lo que modelas, va constituyendo un grupo de activos.
Por fin, adios a la hojita de Excel que tanto odie para hacer el inventario de aplicaciones. Con Archimate vamos a poder expresar todos los conceptos de los que constituye una aplicación.
También estamos utilizando otra herramienta, comercial y con necesidad de licencia; que se llama BizzDesign Architect; pero la ventaja es que permite realizar el análisis de las relaciones entre los diversos activos y obtiene las tablas de cruce entre los distintos activos. Y tiene hasta un lenguaje para hacer consultas para hacer la mineria de los activos de la organización.
Y ahora estoy estudiando TOGAF, para tener ya el marco metodólogico para trabajar en el tema de arquitectura empresarial.
Estoy contento por la chamba que estamos haciendo y el equipo de personas que somos, muy bueno y con distintas perspectivas para atacar los diversos temas de arquitectura empresarial.
Con esto espero ya pasar de las presentaciones de PowerPoint a poder decir que estamos haciendo Arquitectura Empresarial ... bueno en parte, por que implica mucho mas alla de modelar. Aun faltan muchos retos por superar.
sábado, 19 de febrero de 2011
Integracion con sabor internacional
Pues el Tuzo y yo (2 de los 3 lectores de este blog) tuvimos una aventura de miercoles a jueves. Para evitar problemas de no thiklozur (hablando a la Doriga) no voy a decir nombres de empresas
El caso es que donde trabajamos, se aventaron un sistema en Java para obtener todas las facturas electrónicas de los proveedores. Todo hubiera ido bien si no hubieran utilizado el java.io.FileReader de Java, pero lo hicieron y cuando escribieron esos archivos al sistema de archivos le dieron mas feo que FECAL al país. Perdieron las secuencias especiales de los acentos y caracteres anexos.
El caso es que esos benditos archivos en formato XML, al momento de querer ser verificados contra el sistema de Factura electrónica del SAT, pues era rechazado, por que no era integro.
Sepa San Donald Knuth por que nunca los desarolladores hicieron una mondriga prueba con un solo archivo XML que pasara un ciclo completo, o quiza nunca probaron los acentos, para que si nadie los usa en este país
El caso es que el miercoles, su servidor que tenía planeada otra actividad mas interesante a las 20 pm, recibe una llamada de auxilio en el batiphone y tuvo que oir.
Para aquello de ls 19:30 pm, retoma el tema, que ya el Tuzo estaba viendo, y el panorama se veía oscuro. Ya los desarrolladores habían confesado su pecado y por lo menos ya habían corregido y usando Input/OutputStream.
Y pues me avente un programa en C, usando getchar y explore los 25,000 archivos. Como 14,000 estaban con problemas. Y ahora, que hacer. Pues dije, a sustituir byte por byte. El reto era que se le tenia que hacer al detective, por que si se alteraba algún byte, todo era inutil. Tres horas de infructosa manera de volver a los archivos a su estado original y mejor ya tirar la toalla y esperar mi indeminización, ya que el problema era mío; le digo al Tuzo, vamos a poner en Google, para buscar algo. Que le pongo criterios como acentos, UTF8. Y me encuentro que alguien mas ya había pasado la misma situación.
Eureka! Encontramos un hechizo mágico, iconv.
Gracias a que pudimos trabajar en UNIX/Solaris, empezamos a probar y por fin un archivo pudo ser validado con uso de la razón. Eras casi las 12. Dado que nuestros jefes no daban pista de darnos ni una triste mijaga, bajamos por la comida clasica de desarrollador, sabritones, cocacola, donas bimbo, fastfood microondas. Y a aventarse un script para automatizar todo. A las 2 am ya estaba todo. De ahí a sacar muestras y dejar en manos de San Meyer todos. A las 4 am acabo todo
Pero me pregunto, que necesidad había de pasar todo esto. No hubiera sido mejor tomar en cuenta los acentos.
La verdad, estas lecciones le dan a uno humilidad. Se da cuenta cuan ignorante es su servidor. Por mas de una decada ignore el tema de acentos y anexas, Unicode, internacionalización. Ahora me doy cuenta que si queremos lograr una integración es muy importante. UTF 8 e ISO 8859-1 no deben ser magia negra ni ignorados, por algo existen.
Y por favor, prueben antes de liberar a producción!
Por cierto, el equipo de desarrollo al otro día les pregunto sobre como manejan su conexión a la base de datos, si estaban usando algun pool. Su cara me lo dijo todo... Es la próxima aventura de la siguiente semana !
El caso es que donde trabajamos, se aventaron un sistema en Java para obtener todas las facturas electrónicas de los proveedores. Todo hubiera ido bien si no hubieran utilizado el java.io.FileReader de Java, pero lo hicieron y cuando escribieron esos archivos al sistema de archivos le dieron mas feo que FECAL al país. Perdieron las secuencias especiales de los acentos y caracteres anexos.
El caso es que esos benditos archivos en formato XML, al momento de querer ser verificados contra el sistema de Factura electrónica del SAT, pues era rechazado, por que no era integro.
Sepa San Donald Knuth por que nunca los desarolladores hicieron una mondriga prueba con un solo archivo XML que pasara un ciclo completo, o quiza nunca probaron los acentos, para que si nadie los usa en este país
El caso es que el miercoles, su servidor que tenía planeada otra actividad mas interesante a las 20 pm, recibe una llamada de auxilio en el batiphone y tuvo que oir.
Para aquello de ls 19:30 pm, retoma el tema, que ya el Tuzo estaba viendo, y el panorama se veía oscuro. Ya los desarrolladores habían confesado su pecado y por lo menos ya habían corregido y usando Input/OutputStream.
Y pues me avente un programa en C, usando getchar y explore los 25,000 archivos. Como 14,000 estaban con problemas. Y ahora, que hacer. Pues dije, a sustituir byte por byte. El reto era que se le tenia que hacer al detective, por que si se alteraba algún byte, todo era inutil. Tres horas de infructosa manera de volver a los archivos a su estado original y mejor ya tirar la toalla y esperar mi indeminización, ya que el problema era mío; le digo al Tuzo, vamos a poner en Google, para buscar algo. Que le pongo criterios como acentos, UTF8. Y me encuentro que alguien mas ya había pasado la misma situación.
Eureka! Encontramos un hechizo mágico, iconv.
Gracias a que pudimos trabajar en UNIX/Solaris, empezamos a probar y por fin un archivo pudo ser validado con uso de la razón. Eras casi las 12. Dado que nuestros jefes no daban pista de darnos ni una triste mijaga, bajamos por la comida clasica de desarrollador, sabritones, cocacola, donas bimbo, fastfood microondas. Y a aventarse un script para automatizar todo. A las 2 am ya estaba todo. De ahí a sacar muestras y dejar en manos de San Meyer todos. A las 4 am acabo todo
Pero me pregunto, que necesidad había de pasar todo esto. No hubiera sido mejor tomar en cuenta los acentos.
La verdad, estas lecciones le dan a uno humilidad. Se da cuenta cuan ignorante es su servidor. Por mas de una decada ignore el tema de acentos y anexas, Unicode, internacionalización. Ahora me doy cuenta que si queremos lograr una integración es muy importante. UTF 8 e ISO 8859-1 no deben ser magia negra ni ignorados, por algo existen.
Y por favor, prueben antes de liberar a producción!
Por cierto, el equipo de desarrollo al otro día les pregunto sobre como manejan su conexión a la base de datos, si estaban usando algun pool. Su cara me lo dijo todo... Es la próxima aventura de la siguiente semana !
domingo, 23 de enero de 2011
Integración a la mexicana Recargada
Hola!
Tendremos todavía lectores?
Han pasado varios años desde que creamos este blog. El Tuzo y yo seguimos trabajando juntos. Chillicoder ha recorrido un camino aparte, pero bien metido a Ruby
Y de Ruby quiero hablar
Estoy este fin de semana preparando clases, inicio en la ULSA, programación Web es la materia. Después de observar como ORACLE ha llevado a Java, he decidido por primera vez en mis casi 14 años dando clase, no impartir sobre la plataforma Java. La última vez trate sobre GRAILS
Retomando las ideas de Bruce Tate, en su libro Beyond Java, he decidido aplicar el camino, al igual que Chillicoder.
Durante ya los casi 5 años en los que Ruby on Rails ha evolucionado, encuentro una plataforma madura y bien diseñada.
Aunque seguimos usando Web Services con SOAP, WSDL y JMS; y seguimos usando el Service Bus de ahora ORACLE; ya tengo un rato que me percato de la existencia de REST y como simplifica el desarrollo
Me doy cuenta que la visión de llenar Internet con servicios Web basados en SOAP no prospero. Me encuentro al contrario, toda una serie de servicios implantados por Google, Amazon, Twitter, bajo un diseño simple
Y de cloud computing me encuentro conceptos similares a los planteados en los inicios de concepción de SOA. En algún blog anterior hable del concepto de X As a Service. Ahora, el tener la capacidad de exponer Hardware y Sistema operativo como Servicio, supero las expectativas de esos tiempos
Ahora hasta tengo un teléfono movil inteligente como los llaman hoy, un iPhone. Ya he probado el progamar sobre BlackBerry y iPhone. Me falta Android
Me percato, que el concepto de servicio no se ha perdido. En muchos lados, veo como varios "computologos" hablan de la muerte de SOA o de que ya no está "in". Me da risa esa visión de consultor que no aplica nada de lo que escribe, tipo Gartner
En una platica que oi de Mike Rossen, hablaba él de experiencias en implantaciones de SOA. Al final, la conclusión es que las organizaciones posiblemente no implantarán en su totalidad SOA. Pero la industria de software si está basando fuertemente en dicho concepto
En el temario de la materia a la que me refiero, incluí varias ideas. Espero que mis alumnos absorban los conceptos básicos para llegar a tocar los temas de servicios. Pongo aquí la liga de la presentación http://sites.google.com/site/cibgusdelact/progweb8012011/tema0/Introduccion Programacion Web.pdf
Me doy cuenta de nuevas oportunidades de trabajo, ya sea en el actual o pensar en nuevos lugares. Veo que se necesitan personas técnicas que sepan de este tema, que tengan experiencia en pasadas tecnologías que trataron la misma visión
De ahí que llamo a esta entrada, Integración Recargada por que veo nuevas posibilidades por aprender y de ahí aplicar
Empezando el 2011, y con retos interesantes en la chamba
Tendremos todavía lectores?
Han pasado varios años desde que creamos este blog. El Tuzo y yo seguimos trabajando juntos. Chillicoder ha recorrido un camino aparte, pero bien metido a Ruby
Y de Ruby quiero hablar
Estoy este fin de semana preparando clases, inicio en la ULSA, programación Web es la materia. Después de observar como ORACLE ha llevado a Java, he decidido por primera vez en mis casi 14 años dando clase, no impartir sobre la plataforma Java. La última vez trate sobre GRAILS
Retomando las ideas de Bruce Tate, en su libro Beyond Java, he decidido aplicar el camino, al igual que Chillicoder.
Durante ya los casi 5 años en los que Ruby on Rails ha evolucionado, encuentro una plataforma madura y bien diseñada.
Aunque seguimos usando Web Services con SOAP, WSDL y JMS; y seguimos usando el Service Bus de ahora ORACLE; ya tengo un rato que me percato de la existencia de REST y como simplifica el desarrollo
Me doy cuenta que la visión de llenar Internet con servicios Web basados en SOAP no prospero. Me encuentro al contrario, toda una serie de servicios implantados por Google, Amazon, Twitter, bajo un diseño simple
Y de cloud computing me encuentro conceptos similares a los planteados en los inicios de concepción de SOA. En algún blog anterior hable del concepto de X As a Service. Ahora, el tener la capacidad de exponer Hardware y Sistema operativo como Servicio, supero las expectativas de esos tiempos
Ahora hasta tengo un teléfono movil inteligente como los llaman hoy, un iPhone. Ya he probado el progamar sobre BlackBerry y iPhone. Me falta Android
Me percato, que el concepto de servicio no se ha perdido. En muchos lados, veo como varios "computologos" hablan de la muerte de SOA o de que ya no está "in". Me da risa esa visión de consultor que no aplica nada de lo que escribe, tipo Gartner
En una platica que oi de Mike Rossen, hablaba él de experiencias en implantaciones de SOA. Al final, la conclusión es que las organizaciones posiblemente no implantarán en su totalidad SOA. Pero la industria de software si está basando fuertemente en dicho concepto
En el temario de la materia a la que me refiero, incluí varias ideas. Espero que mis alumnos absorban los conceptos básicos para llegar a tocar los temas de servicios. Pongo aquí la liga de la presentación http://sites.google.com/site/cibgusdelact/progweb8012011/tema0/Introduccion Programacion Web.pdf
Me doy cuenta de nuevas oportunidades de trabajo, ya sea en el actual o pensar en nuevos lugares. Veo que se necesitan personas técnicas que sepan de este tema, que tengan experiencia en pasadas tecnologías que trataron la misma visión
De ahí que llamo a esta entrada, Integración Recargada por que veo nuevas posibilidades por aprender y de ahí aplicar
Empezando el 2011, y con retos interesantes en la chamba
Suscribirse a:
Entradas (Atom)