Hola que tal, este post originalmente fu creado para integramx, pero aqui les va
¿cuantas veces les ha tocado hacer un cambio en una aplicación? ¿Cuantas veces pensamos en las aplicaciones que se verán afectadas cuando cambiamos algo? ¿Quienes de nosotros tenemos un control de nuestras aplicaciones así como las dependencias que tenemos con otros sistemas?
¿Cuantas veces no les ha pasado que alguna área cambia versión de aplicación y las nuestras dejan de funcionar correctamente? nunca !!.. que bien!!! ... pero a los que nos ha pasado eso y fuera de los dolores de cabeza, a los jefes esperando, el tiempo encima.... todo, todo es desesperante.......... ahora combinen esa situación con una solución de integración mmm digamos ..... Mainframe si Mainframe, pantallas verdes, screen scraping, emuladores 3270... ¿Interesante escenario?
La finalidad de este post es tratar de mostrar una de las debilidades pienso yo, que existe en la integración de aplicaciones basada en captura de pantallas o screen scraping. Cabe resaltar que este tipo de integración tiene una ventaja importante: no es intrusivo en las aplicaciones a las que se trata de integrar.
Aquí en la empresa, tenemos varias interfaces basadas en este estilo de integración (échale un vistazo a esta liga ); como veras nosotros utilizamos Iway Telnet 3270, que es una serie de APIs que permiten interactuar con las pantallas verdes del mainframe... bien pues el punto flaco de estas interfaces es que están altamente acopladas por decirlo de alguna manera a las coordenadas, quien ha trabajado alguna vez con COBOL sabe de que le estoy hablando...
Bajo este esquema hasta un guión"-" te puede afectar (y mas si lo agregan de un día a otro :S, ahh y en la noche), sí, literalmente un guión te puede afectar.... eso fue lo que nos paso recientemente... se agrego un carácter a una pantalla de una aplicación dentro del mainframe y esto ocasiono que se movieran las posiciones de los campos, es decir, si para mi el campo 76 era NSS, ahora se había recorrido hasta la 78.... el punto delicado aquí es que la producción estaba parada mientras se detectaba el error, una vez que se detecto se dio marcha atrás a la versión de la aplicación mainframe....... mientras todo esto ocurría la operación se detuvo por al rededor de 3 horas...
Se aplico el cambio tal y como se debió de hacer desde un principio, es decir nos colocaron la versión de la aplicación mainframe en DESARROLLO hicimos los ajustes en nuestra interfase y liberamos a la par las nuevas versiones...
Todo el cuento anterior se pudo evitar teniendo un buen CONTROL DE CAMBIOS... se escucha tan sencillo y a veces trillado cuando nos hablan de esto en CMM, ITIL, RUP, en lo que ustedes quieran.... pero créanme que es muy importante...
Para muestra basta un botón... ¿recuerdas cuantos millones perdió TELCEL hace unos meses debido a un problema en su sistema?
Por una integración mejor, hasta la vista!!!
Tuzo
Wednesday, September 12, 2007
Tuesday, June 26, 2007
Metodologias de desarrollo ¿se usan?
Hola que tal tuzolectores
¿Frases conocidas? Lider: "El proyecto lleva un atraso un año (bromeo,... jaja eso no sucede :P )", Usuario final: "Aaahhh no es lo que yo queria", Desarrollador "Aarrgg no se pueden poner de acuerdo, van N veces que cambio el codigo" El que pone el $ para el proyecto: "uupss llevamos invertidos $$$ y no veo resultados".... y muchas mas.......
Como experiencia propia puedo contarles una anegdota que tuve hace algunos años "me piden estimar un modulo para un proyecto (no digo nombres para evitar suceptibilidades), bien, llego feliz y le doy mi estimacion:
Tuzo: 1 mes sin contar pruebas.....
Lider Proyecto: ¿que?¡¡¡ es mucho tiempo... lo tenemos que entregar en 3 dias ¡¡ ya me comprometi con el usuario ¡¡¡¡
¿que dirian ante esto?.... ¿Felicidades?.... Ha veces digo ahh como quisiera regresar a los tiempos de la escuela cuando solo era el gusto por programar sin preouparte de todas estas cosas, en fin ¿a que voy?....
Hoy en dia (y aunque parezca broma), hay quien todavia tiene la creencia que las metodologias de desarrollo no funcionan o peor aun que solo sirven para generar documentacion de mas, .....Falso con F mayuscula, lo importante aqui es saber que metodoliga ocupar para nuestro proyecto asi como la documentacion que genera mas valor en nuestro ciclo de vida del proyecto.
Actualmente existen un sin numero de metodologias de desarrollo divididas en dos grandes grupos... Metodologias Formales y Metodologias Agiles.
Las metodologias Formales son planeadas y disciplinadas generalmente usadas para sistemas de mediano a largo plazo, a diferencia de las metodologias Agiles... que no por ser agiles sean completamente contrarias a las formales... que quiero decir que no por ser agiles, sean llevadas a cabo sin plan, mas bien este tipo de metodologias son Adaptativas..... ¿porque adaptativas? simple y sencillamente porque al usuario siempre se le ocurre algo nuevo... y cambia constantemente los requerimientos...
Rational Unified Process es una metodologia formal, la caracteristica principal es que es Iterativo e Incremental, es centrado en la arquitectura, dirigido por casos de uso y busca mitigar lo menos posible los riesgos de un proyecto..... a diferencia Xtreme Programing es una metodologia agile, adaptativa y centrada en el usuario.. cuyo ciclo principal es Capturar el Requerimiento, desarrollar y probar con el usuario...
Ya cualquier chavo le preguntas ¿El Modelo Tradicional de Cascada es Malo? y te contestan de facto SI
pensemos ... y de verdad el ¿Modelo de Casadada es Malo? entonces ¿porque lo toman como base las demas metodologias?.. vuelvo al comentario inicial.. simplemente debemos ver en DONDE ocupar QUE, ese es el secreto de todo..quizá no exista una clasificacion de tipos de proyectos, pero asi de simple como responder las preguntas ¿usarias RUP para hacer un sistema de mantenimiento de inventario? o ¿usarias XP para un sistema de calculo de nomina bancaria?
Podemos encontrar muchas metodologias: RUP, XP, Agile Modeling, Scrum, MSF, etc..
Asi que como gente de sistemas debemos de tener claras cada una de las ventajas de usar las metodologias de desarrollo.. asi que a estudiar!!!!
Por el buen compartir, hasta la vista
Javo
¿Frases conocidas? Lider: "El proyecto lleva un atraso un año (bromeo,... jaja eso no sucede :P )", Usuario final: "Aaahhh no es lo que yo queria", Desarrollador "Aarrgg no se pueden poner de acuerdo, van N veces que cambio el codigo" El que pone el $ para el proyecto: "uupss llevamos invertidos $$$ y no veo resultados".... y muchas mas.......
Como experiencia propia puedo contarles una anegdota que tuve hace algunos años "me piden estimar un modulo para un proyecto (no digo nombres para evitar suceptibilidades), bien, llego feliz y le doy mi estimacion:
Tuzo: 1 mes sin contar pruebas.....
Lider Proyecto: ¿que?¡¡¡ es mucho tiempo... lo tenemos que entregar en 3 dias ¡¡ ya me comprometi con el usuario ¡¡¡¡
¿que dirian ante esto?.... ¿Felicidades?.... Ha veces digo ahh como quisiera regresar a los tiempos de la escuela cuando solo era el gusto por programar sin preouparte de todas estas cosas, en fin ¿a que voy?....
Hoy en dia (y aunque parezca broma), hay quien todavia tiene la creencia que las metodologias de desarrollo no funcionan o peor aun que solo sirven para generar documentacion de mas, .....Falso con F mayuscula, lo importante aqui es saber que metodoliga ocupar para nuestro proyecto asi como la documentacion que genera mas valor en nuestro ciclo de vida del proyecto.
Actualmente existen un sin numero de metodologias de desarrollo divididas en dos grandes grupos... Metodologias Formales y Metodologias Agiles.
Las metodologias Formales son planeadas y disciplinadas generalmente usadas para sistemas de mediano a largo plazo, a diferencia de las metodologias Agiles... que no por ser agiles sean completamente contrarias a las formales... que quiero decir que no por ser agiles, sean llevadas a cabo sin plan, mas bien este tipo de metodologias son Adaptativas..... ¿porque adaptativas? simple y sencillamente porque al usuario siempre se le ocurre algo nuevo... y cambia constantemente los requerimientos...
Rational Unified Process es una metodologia formal, la caracteristica principal es que es Iterativo e Incremental, es centrado en la arquitectura, dirigido por casos de uso y busca mitigar lo menos posible los riesgos de un proyecto..... a diferencia Xtreme Programing es una metodologia agile, adaptativa y centrada en el usuario.. cuyo ciclo principal es Capturar el Requerimiento, desarrollar y probar con el usuario...
Ya cualquier chavo le preguntas ¿El Modelo Tradicional de Cascada es Malo? y te contestan de facto SI
pensemos ... y de verdad el ¿Modelo de Casadada es Malo? entonces ¿porque lo toman como base las demas metodologias?.. vuelvo al comentario inicial.. simplemente debemos ver en DONDE ocupar QUE, ese es el secreto de todo..quizá no exista una clasificacion de tipos de proyectos, pero asi de simple como responder las preguntas ¿usarias RUP para hacer un sistema de mantenimiento de inventario? o ¿usarias XP para un sistema de calculo de nomina bancaria?
Podemos encontrar muchas metodologias: RUP, XP, Agile Modeling, Scrum, MSF, etc..
Asi que como gente de sistemas debemos de tener claras cada una de las ventajas de usar las metodologias de desarrollo.. asi que a estudiar!!!!
Por el buen compartir, hasta la vista
Javo
Labels:
Agile Modeling,
MSF,
RUP,
Scrum,
XP
Tuesday, June 19, 2007
Un poco de conciencia ambiental
Hola a todos. Cada día a través de los medios de comunicación escuchamos más y más acerca de la deploración ambiental que está sufriendo nuestro planeta y si no ha hecho aún, debería ya, hacer conciencia en nuestra persona.
Podría yo buscar en internet y listar aquí un buen de estadísticas acerca de cuándo se tiene estimado que se acaben cada uno de los recursos naturales (agua, árboles, petróleo, etc) A cambio solamente enlistaré algunas de las actividades que hago día con día para tratar de ayudar a no contaminar de más y proponer que tal vez si cada uno de nosotros hiciera algo diferente podría ayudar en tener una Tierra más limpia (o menos sucia :)).
En el baño no gasto agua de más.
En lo que sale el agua caliente pongo una cubeta para que esa cantidad de agua sirva para el inodoro.
Minimizo el uso del papel.
En la oficina uso papel reciclable.
Bueno, son algunas de las cosas que en lo personal realizo y propongo para un mejor cuidado del medio ambiente, ya que aquel futuro lejano en el que se veía a la Tierra desvastada cada vez es más cercano.
Me falta hacer algo más con la clasificación de la basura en mi casa, creo que ese será el siguiente hábito por tomar. :)
Saludos.
Podría yo buscar en internet y listar aquí un buen de estadísticas acerca de cuándo se tiene estimado que se acaben cada uno de los recursos naturales (agua, árboles, petróleo, etc) A cambio solamente enlistaré algunas de las actividades que hago día con día para tratar de ayudar a no contaminar de más y proponer que tal vez si cada uno de nosotros hiciera algo diferente podría ayudar en tener una Tierra más limpia (o menos sucia :)).
En el baño no gasto agua de más.
En lo que sale el agua caliente pongo una cubeta para que esa cantidad de agua sirva para el inodoro.
Minimizo el uso del papel.
En la oficina uso papel reciclable.
Bueno, son algunas de las cosas que en lo personal realizo y propongo para un mejor cuidado del medio ambiente, ya que aquel futuro lejano en el que se veía a la Tierra desvastada cada vez es más cercano.
Me falta hacer algo más con la clasificación de la basura en mi casa, creo que ese será el siguiente hábito por tomar. :)
Saludos.
Monday, June 4, 2007
Web Services Manejables
Hola que tal tuzo lectores
Espero que hayan disfrutado de un buen fin de semana.
Como les comente estare publicando una serie de post referentes a lo Servicios Web, por lo pronto he publicado uno llamado Web Services Manejables, en el blog hermano de integracion a la mexicana espero le echen un vistaso, son algunas recomendaciones, que aunque basicas.. son elementales.. espero les sea de utilidad.
Por el buen compartir, hasta la vista!!
Javo
Espero que hayan disfrutado de un buen fin de semana.
Como les comente estare publicando una serie de post referentes a lo Servicios Web, por lo pronto he publicado uno llamado Web Services Manejables, en el blog hermano de integracion a la mexicana espero le echen un vistaso, son algunas recomendaciones, que aunque basicas.. son elementales.. espero les sea de utilidad.
Por el buen compartir, hasta la vista!!
Javo
Labels:
best practices,
Buenas practicas,
web services,
xml,
XSD
Thursday, May 24, 2007
Recordando viejos tiempos
Hola, que tal, solo anexo una foto para recordar viejos tiempo (hace ya 6 años de esta foto), en la que mis conpañeros Cardoso, Migue, Zamo, Javo, Toño, y por su puesto Yo (Rana), iniciabamos nuestra vida profesional en el desarrollo de software, especificamente en la Fábrica de Software de Bursatec, en Pachuca Hidalgo. Me pongo a pensar lo que mucho o poco que hemos aprendido desde esa epoca hasta ahora, solo me resta decir que esperemos seguir echandole los kilos, divertirnos con lo que hacemos, porque estoy seguro de que nos gusta nuestro trabajo, como dice el Toño, ser albañiles del software :), Saludos.
Wednesday, May 23, 2007
Hablemos de Web services
Hola que tal,
Hace algunas semanas (curiosamente) se acercaron varios cuates a preguntarme acerca de web services...... eso me motivo hacer una serie de post que hablen acerca de los servicios web....
Iniciemos... pues bien en terminos practicos un web service es una manera estandar de integrar aplicaciones utilizando XML, SOAP y WSDL como estandares base... la manera mas comun de transportar es mediante HTTP, aunque puedes exponer un Web services con JMS de Java...
Aqui el punto importante es lo que el web service estara exponiendo.... es decir logica de negocio, datos y procesos, algo harto importante para mi ( que bueno... despues hay que ver como le haces para pensar en procesos de negocio, exposicion de datos y procesos )...
Es bien sabido que los Web services son usados como parte fundamental dentro de la Arquitectura Orientada a Servicios, de ahi la importancia de que es lo que se esta exponiendo....
Hay algunas cuestiones y recomendaciones a seguir al disenar un web service ....... tambien cosas que NO se deben de hacer :S, como decimos aqui en la chamba ... "La culpa no la tiene el indio..., o mejor dicho, el problema no es la tecnologia, si no el que la implementa"
Como veran, hay un buen de cosas que intervienen en una buena implementacion de los servicios web.. poco apoco iremos tocando cada tema..
Saludos !!!
Tuzo
Hace algunas semanas (curiosamente) se acercaron varios cuates a preguntarme acerca de web services...... eso me motivo hacer una serie de post que hablen acerca de los servicios web....
Iniciemos... pues bien en terminos practicos un web service es una manera estandar de integrar aplicaciones utilizando XML, SOAP y WSDL como estandares base... la manera mas comun de transportar es mediante HTTP, aunque puedes exponer un Web services con JMS de Java...
- XML es usado para representar los datos
- SOAP se encarga de transferir los datos
- WSDL describe el servicio, metodos y parametros
Aqui el punto importante es lo que el web service estara exponiendo.... es decir logica de negocio, datos y procesos, algo harto importante para mi ( que bueno... despues hay que ver como le haces para pensar en procesos de negocio, exposicion de datos y procesos )...
Es bien sabido que los Web services son usados como parte fundamental dentro de la Arquitectura Orientada a Servicios, de ahi la importancia de que es lo que se esta exponiendo....
Hay algunas cuestiones y recomendaciones a seguir al disenar un web service ....... tambien cosas que NO se deben de hacer :S, como decimos aqui en la chamba ... "La culpa no la tiene el indio..., o mejor dicho, el problema no es la tecnologia, si no el que la implementa"
Como veran, hay un buen de cosas que intervienen en una buena implementacion de los servicios web.. poco apoco iremos tocando cada tema..
Saludos !!!
Tuzo
Labels:
SOA,
soap,
web services,
wsdl,
xml
Tuesday, May 22, 2007
Multiprogramación o un método alternativo de relajamiento
Hola a todos, buenas tardes.
Llamo así a este post, Multiprogramación, debido al momento por el que estoy pasando y que, estoy seguro que a más de uno le ha pasado.
En la empresa para la cual trabajo desde hace ya 7 años y medio, Bursatec, estoy en un proyecto tipo Cliente-Servidor el cual involucra desarrollo en el cliente con C# y servidores en C. Cabe aclarar que C# es para mi un lenguaje de recién aprendizaje, digo recién aunque ya llevo poco más de un año trabajando con C# y es el mismo tiempo que lleva el proyecto.
No conforme con esto en el proyecto de mi tesis, por parte de la escuela, lo estoy desarrollando en VC++6 con la intención (y a ver si no muero en el intento) de hacerlo en VC++ .net.
El estar trabajando casi simultáneamente con distintos lenguajes podría ser una de las causas para diagnosticar locura y, lo reconozco, las primeras ocasiones en que me sucedía esto solía escribir instrucciones de un lenguaje en otro y viceversa causando una ligera confusión en mi cabeza al no hacer el ‘switcheo’ de lenguajes a tiempo.
Actualmente ya no me sucede esto, y siendo sincero y sin presunción, creo que a los que nos gusta esto de la programación, escribir simultáneamente con más de un lenguaje puede resultar terapéutico, de tal modo que nuestra cabeza no se encierra con un solo lenguaje y no llegar a estar hartos del proyecto en el que estamos trabajando. Aunado a esto, si uno de los lenguajes requiere de investigación (mi proyecto de tesis me está exigiendo investigación en VC++.net, DirectX y OpenGL) pues es un recurso más para distraerse un poco y oxigenar el cerebro. Claro, además de las idas al baño o las caminatas por el pasillo que bien pueden ser tema de otro post.
Quisiera terminar este post proponiendo a todos aquellos que empiezan a experimentar tedio en lo que están haciendo, intenten con la distracción en la investigación o desarrollo de un programa Express.
Saludos a todos.
Llamo así a este post, Multiprogramación, debido al momento por el que estoy pasando y que, estoy seguro que a más de uno le ha pasado.
En la empresa para la cual trabajo desde hace ya 7 años y medio, Bursatec, estoy en un proyecto tipo Cliente-Servidor el cual involucra desarrollo en el cliente con C# y servidores en C. Cabe aclarar que C# es para mi un lenguaje de recién aprendizaje, digo recién aunque ya llevo poco más de un año trabajando con C# y es el mismo tiempo que lleva el proyecto.
No conforme con esto en el proyecto de mi tesis, por parte de la escuela, lo estoy desarrollando en VC++6 con la intención (y a ver si no muero en el intento) de hacerlo en VC++ .net.
El estar trabajando casi simultáneamente con distintos lenguajes podría ser una de las causas para diagnosticar locura y, lo reconozco, las primeras ocasiones en que me sucedía esto solía escribir instrucciones de un lenguaje en otro y viceversa causando una ligera confusión en mi cabeza al no hacer el ‘switcheo’ de lenguajes a tiempo.
Actualmente ya no me sucede esto, y siendo sincero y sin presunción, creo que a los que nos gusta esto de la programación, escribir simultáneamente con más de un lenguaje puede resultar terapéutico, de tal modo que nuestra cabeza no se encierra con un solo lenguaje y no llegar a estar hartos del proyecto en el que estamos trabajando. Aunado a esto, si uno de los lenguajes requiere de investigación (mi proyecto de tesis me está exigiendo investigación en VC++.net, DirectX y OpenGL) pues es un recurso más para distraerse un poco y oxigenar el cerebro. Claro, además de las idas al baño o las caminatas por el pasillo que bien pueden ser tema de otro post.
Quisiera terminar este post proponiendo a todos aquellos que empiezan a experimentar tedio en lo que están haciendo, intenten con la distracción en la investigación o desarrollo de un programa Express.
Saludos a todos.
Subscribe to:
Posts (Atom)