Como ya varios saben, soy lector regular del blog de Scott Hanselman. Es un tipo realmente brillante no solo tirando código sino llevando la tecnología a nichos que simplemente dejamos pasar de largo.
¿Cuántas veces se ha utilizado Google Earth para buscar monumentos, la casa de tu novia o una dirección? Peor aún ¿cuántas veces no se ha usado para buscar gente desnuda tomando el sol en el patio de su casa?. Puede ser divertido pero definitivamente es un desperdicio de tecnología.
Pues bien, Scott publicó un post sobre como utilizar Google Earth o Virtual Earth para visualizar un nuevo fraccionamiento.
Lo interesante de esto es que son herramientas que están al alcance de cualquier persona. No necesitas ser un mega-dooper-super experto en AutoCAD o cosa similar (claro, el resultado tampoco es igual), simplemente con unas pocas herramientas en tu PC casera consigues el resultado.
Eso también es innovación. Los mexicanos nos preciamos mucho de ser ocurrentes, tal vez alguien acá de este lado de la frontera tuvo la misma ocurrencia. Pero al no compartir ese conocimiento cualquier otro que sí lo hace se convierte en innovador por ese simple hecho.
Estamos muy acostumbrados a construir nichos y compartir un poquito de conocimiento con otros para convertirlos en nuestros aliados. Armamos batallas de escritorio para tirar los nichos de otros. Negociamos con el conocimiento como con cualquier baratija.
Entonces ¡compártamos nuestro conocimiento! Una de las bellezas del software libre es ese ambiente de compartir, de buscar a quién ofrecerle (sin ningún interés por detrás) lo último que construimos, de pedir opinión a otros para mejorar, de mirar en el trabajo del vecino para buscar una segunda opinión sobre lo que estamos haciendo.
Busquemos compartir en lugar de aislar. Tratar el conocimiento, simple o formalizado, con el valor que se merece. Tratemos a los demás como compañeros de creación.
Finito.
domingo, 10 de junio de 2007
miércoles, 6 de junio de 2007
Software Factories & SOA
El concepto de Software Factories, planteado por Jack Greenfield plantea un modelo para construir software a partir de combinar modelos, herramientas, patrones y frameworks que permitan automatizar el desarrollo de software. Este diagrama que pongo, es la ruta de lectura del libro
La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.
Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender
Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"
Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:
+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios
¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse
Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes
Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración
Asi ya no son necesarios los wizards
Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas
Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories
¿Ya esta la visión, ahora quien empieza a concretar?
La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.
Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender
Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"
Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:
+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios
¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse
Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes
Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración
Asi ya no son necesarios los wizards
Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas
Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories
¿Ya esta la visión, ahora quien empieza a concretar?
martes, 5 de junio de 2007
FONASOL: Pendiente
Pues bien, el FONASOL concluyó el sábado y ya tengo un bonche de recuerdos más que atesorar, nuevos amigos que conocer y algunas fotos que compartir.
Definitivamente es una historia para contar por episodios. No se desconecten.
Finito.
Definitivamente es una historia para contar por episodios. No se desconecten.
Finito.
lunes, 4 de junio de 2007
Web Services Manejables
Hola que tal! de nuevo por aqui
Como se habran dado cuenta, hace algunos dias hablamos (o nos quejamos jeje ) del diseno de unos servicios web.... aqui les dejo unas recomendaciones (Best Practices) a tomar en cuenta, quiza sean simples... pero elementales.. aunque muchas ocasiones no se siguen ;)
Va pues, comentarios bienvenidos :)
Por una integracion mejor, hasta la vista!
Tuzo
Como se habran dado cuenta, hace algunos dias hablamos (o nos quejamos jeje ) del diseno de unos servicios web.... aqui les dejo unas recomendaciones (Best Practices) a tomar en cuenta, quiza sean simples... pero elementales.. aunque muchas ocasiones no se siguen ;)
- NO usar elementos simples en las firmas de los metodos ; tomando como ejemplo public int obtenerCotizaciones(int nss), tenemos un problema: la escalabilidad del mensaje, si desearamos agregar la fecha de alta trendriamos que colocarlo de la siguiente manera public int obtenerCotizaciones(int nss,long fecha).. MAL , en lugar de eso debemos modelar un objeto que defina mi negocio (tanto entradas como salidas).... siguiendo con el ejemplo definamos:
- public class entradaCotizaciones {
private int nss;
private long fecha;
} - public class salidaCotizaciones {
private int numeroCotizaciones;
private boolean error;
private int codigoError;
private String descripcion;
} - public salidaCotizaciones obtenerCotizaciones(entradaCotizaciones entrada)
- Usar Built-Data Types al disenar el XSD del servicio
- Si se pretende utilizar mensajes estandar (Hl7, eGov, xCIL, XNAL), evitar el uso de anyType en el envio del mensaje, es recomendable generar un modelo de negocio basado en los XSD que vienen con el estandar.
- Muy importante, definir los elementos para el manejo de errores, que permitan manipular la respuesta de acuerdo a las condiciones que se presenten
- private boolean error; // describe si existie o no error
private int codigoError; // indica el tipo del error
private String descripcion; // describe que fue lo que sucedio
Va pues, comentarios bienvenidos :)
Por una integracion mejor, hasta la vista!
Tuzo
lunes, 28 de mayo de 2007
CMMI
Bueno, esto deberia estar mas del lado del post de Tuzoftwar, pero el tuzo no me invito al club de tobby-tuzos, y menos por que en la final le iba yo al America y solo por el afan de molestarlo
Empecemos con lo que quiero decir
Mucho de lo expuesto aqui en este blog, puede ya ser calificados como antipatterns de integracion, como lo han notado. Y habla de lo que no se debe hacer.
Sin embargo, muchas veces, sea cual sea el tamaño de la organizacion que desarrolla, siempre se acaba en un punto en el cual algo no fue interpretado como se debia
El punto es, y ahora que lo veo; es muy arriesgado aventarse a desarrollar sin tener un modelo de referencia. Sin embargo todos lo hacemos
Normalmente los de sistemas, vemos el punto de programar, tirar codigo, hacer arquitectura, integrar.
Pero se nos olvida facilmente que detras de ese esfuerzo estan grupos de seres humanos y que tienen un ritmo de trabajo cuando trabajan en equipo.
La administracion de proyectos trata de atacar esa problematica, que tiene varias soluciones por ser enfocada a la mas incierta de las variables, el humano y lograr la meta.
El CMMI es un modelo que indica como debe madurar una organizacion que desarrolla software tomando en cuenta los humanos, definiendo un proceso y lograr obtener productos de software
Lo primero que pide es que seas capaz de administrar tus proyectos, que puedas hacer que algo que lograste una vez, vuelva a suceder; y que minimo te dediques a controlar los requerimientos. Este es el nivel 2 de CMMI. No se preocupa por decir como hacer la ingenieria de software. Y tambien pide que controles tus cambios antes de que te ahogues con ellos, que asegures la calidad y tomes medida (lo que no se puede medir no se puede administrar)
El nivel 3 de CMMI basicamente dice, escribe tu proceso indicando la manera como quieres que todos trabajen y de ahi, ajusta tus proyectos a esa vision (no siempre vas a modelar en UML o si?) y coordinate con otros grupos de trabajo. Y hecho eso, empieza a ver la ingenieria de software, analizar, desarrollar e integrar componentes. Y revisa que cada componente cumpla con lo especificado y validar que se pueda usar por el usuario.
El nivel 4 dice, ya que defines procesos, mide cuantitaviamente como los trabajas y empieza a estimar tu desarrollo en base a estadistica, y reducir la incertidumbre
Y el nivel 5 es, si ya haces tu proceso, ya lo mides, ahora preparate para innovar, para meter nueva tecnologia, para aprovechar oportunidades
Si, son cinco niveles , nada sencillos de alcanzar, pero la verdad es lo fundamental para sacar cualquier proyecto de desarrollo
He visto mucha gente desgastarse en poner decenas o centenas de programadores para sacar mas rapido proyectos, he visto muchos gritando y matando gente bajando la calidad de vida, trabajo inutil en sabado y domingo. Y he visto como en muchos proyectos se tienen que admitir resultados tecnicamente mediocres, con que jale mañana esta bien, al otro dia vemos
Y no es mala fe de las personas, creo que cuando todos arrancamos un proyecto, pensamos " acabo en la fecha, siendo amigos de todos los involucrados y me tomo mis vacaciones". Pero es vivir de la ilusion
Sin embargo, esa buena fe de las personas puede ser mejor utilizada si decidieran abrir su mente al modelo que les menciono o similar. Es ser profesional en tu manera de ser, es hacer lo que debe hacerse, quitarte de tu complejo de superprogramador o de mandon
Solo es estudiar, leer y usarlo para servir a los demas en base a tu conocimiento
Asi que yo creo que mucho de lo puesto en este blog, integracion a la mexicana no es para enfatizar el error de alguien. Es para aprender de la experiencia y demostrar que mas vale razonar las cosas que andar de griton o neurastenico con la gente, que al final son humanos como todos.
Asi que, busquen en Google la palabra CMMI. Puede ser que se topen con un documento muy grande del SEI, muy abstracto; pero al entenderlo, se van a perctar que es tan noble como cualquier pieza de ingenieria hecha por los humanos.
Una vez mas, esto no es religion es ingenieria
Empecemos con lo que quiero decir
Mucho de lo expuesto aqui en este blog, puede ya ser calificados como antipatterns de integracion, como lo han notado. Y habla de lo que no se debe hacer.
Sin embargo, muchas veces, sea cual sea el tamaño de la organizacion que desarrolla, siempre se acaba en un punto en el cual algo no fue interpretado como se debia
El punto es, y ahora que lo veo; es muy arriesgado aventarse a desarrollar sin tener un modelo de referencia. Sin embargo todos lo hacemos
Normalmente los de sistemas, vemos el punto de programar, tirar codigo, hacer arquitectura, integrar.
Pero se nos olvida facilmente que detras de ese esfuerzo estan grupos de seres humanos y que tienen un ritmo de trabajo cuando trabajan en equipo.
La administracion de proyectos trata de atacar esa problematica, que tiene varias soluciones por ser enfocada a la mas incierta de las variables, el humano y lograr la meta.
El CMMI es un modelo que indica como debe madurar una organizacion que desarrolla software tomando en cuenta los humanos, definiendo un proceso y lograr obtener productos de software
Lo primero que pide es que seas capaz de administrar tus proyectos, que puedas hacer que algo que lograste una vez, vuelva a suceder; y que minimo te dediques a controlar los requerimientos. Este es el nivel 2 de CMMI. No se preocupa por decir como hacer la ingenieria de software. Y tambien pide que controles tus cambios antes de que te ahogues con ellos, que asegures la calidad y tomes medida (lo que no se puede medir no se puede administrar)
El nivel 3 de CMMI basicamente dice, escribe tu proceso indicando la manera como quieres que todos trabajen y de ahi, ajusta tus proyectos a esa vision (no siempre vas a modelar en UML o si?) y coordinate con otros grupos de trabajo. Y hecho eso, empieza a ver la ingenieria de software, analizar, desarrollar e integrar componentes. Y revisa que cada componente cumpla con lo especificado y validar que se pueda usar por el usuario.
El nivel 4 dice, ya que defines procesos, mide cuantitaviamente como los trabajas y empieza a estimar tu desarrollo en base a estadistica, y reducir la incertidumbre
Y el nivel 5 es, si ya haces tu proceso, ya lo mides, ahora preparate para innovar, para meter nueva tecnologia, para aprovechar oportunidades
Si, son cinco niveles , nada sencillos de alcanzar, pero la verdad es lo fundamental para sacar cualquier proyecto de desarrollo
He visto mucha gente desgastarse en poner decenas o centenas de programadores para sacar mas rapido proyectos, he visto muchos gritando y matando gente bajando la calidad de vida, trabajo inutil en sabado y domingo. Y he visto como en muchos proyectos se tienen que admitir resultados tecnicamente mediocres, con que jale mañana esta bien, al otro dia vemos
Y no es mala fe de las personas, creo que cuando todos arrancamos un proyecto, pensamos " acabo en la fecha, siendo amigos de todos los involucrados y me tomo mis vacaciones". Pero es vivir de la ilusion
Sin embargo, esa buena fe de las personas puede ser mejor utilizada si decidieran abrir su mente al modelo que les menciono o similar. Es ser profesional en tu manera de ser, es hacer lo que debe hacerse, quitarte de tu complejo de superprogramador o de mandon
Solo es estudiar, leer y usarlo para servir a los demas en base a tu conocimiento
Asi que yo creo que mucho de lo puesto en este blog, integracion a la mexicana no es para enfatizar el error de alguien. Es para aprender de la experiencia y demostrar que mas vale razonar las cosas que andar de griton o neurastenico con la gente, que al final son humanos como todos.
Asi que, busquen en Google la palabra CMMI. Puede ser que se topen con un documento muy grande del SEI, muy abstracto; pero al entenderlo, se van a perctar que es tan noble como cualquier pieza de ingenieria hecha por los humanos.
Una vez mas, esto no es religion es ingenieria
jueves, 24 de mayo de 2007
La culpa no la tiene el servicio sino el que lo hace Web Service
Hace un par de días hubo una acalorada discusión en relación a un proceso de integración entre dos sistemas: el expediente clínico electónico (ECE) y el sistema que se encarga de administrar a los usuarios de los diversos servicios de centros deportivos y sociales.
Resulta que los web services que expone ECE se definen en el correspondiente WSDL de la sigte manera:
<s:element name="CargaReferencia">
<s:complextype>
<s:sequence>
<s:element minoccurs="0" maxoccurs="1" name="docHL7Referencia">
<s:complextype mixed="true">
<s:sequence>
<s:any/>
</s:sequence>
</s:complextype>
</s:element>
</s:sequence>
</s:complextype>
</s:element>
Y del otro lado se tiene
<s:element name="procesaOci">
<s:complexType>
<s:sequence>
<s:any/>
</s:sequence>
</s:complexType>
</s:element>
Es decir. Técnicamente reciben cualquier cosa (<s:any/>).
Hace un poco más de un año, se realizó una junta para evaluar una propuesta de arquitectura para los servicios del ECE. Lo curioso es que pasado el tiempo siguen en las mismas.
¿pa'qué definir un contrato? Le pasamos cualquier cosa. ¿pa'qué validar contra un esquema? La validación la hacemos con un flujo o mejor aún: tirando código (que se factura por hora). No tiene ningún caso desacoplar, incluso cuando existen appliances para validar esquemas.
El chiste del outsourcing es quemar horas reinventando el hilo negro, divagando en arquitecturas y pelearse entre sí.
En fin, la culpa no la tiene el servicio.
Finito.
Resulta que los web services que expone ECE se definen en el correspondiente WSDL de la sigte manera:
<s:element name="CargaReferencia">
<s:complextype>
<s:sequence>
<s:element minoccurs="0" maxoccurs="1" name="docHL7Referencia">
<s:complextype mixed="true">
<s:sequence>
<s:any/>
</s:sequence>
</s:complextype>
</s:element>
</s:sequence>
</s:complextype>
</s:element>
Y del otro lado se tiene
<s:element name="procesaOci">
<s:complexType>
<s:sequence>
<s:any/>
</s:sequence>
</s:complexType>
</s:element>
Es decir. Técnicamente reciben cualquier cosa (<s:any/>).
Hace un poco más de un año, se realizó una junta para evaluar una propuesta de arquitectura para los servicios del ECE. Lo curioso es que pasado el tiempo siguen en las mismas.
¿pa'qué definir un contrato? Le pasamos cualquier cosa. ¿pa'qué validar contra un esquema? La validación la hacemos con un flujo o mejor aún: tirando código (que se factura por hora). No tiene ningún caso desacoplar, incluso cuando existen appliances para validar esquemas.
El chiste del outsourcing es quemar horas reinventando el hilo negro, divagando en arquitecturas y pelearse entre sí.
En fin, la culpa no la tiene el servicio.
Finito.
miércoles, 23 de mayo de 2007
WEBCAST Data Services: Essential Foundation For SOA Success
Hola que tal
Hace unos dias me encargaron la mision de trabajar cosas de Data Services usando Aqualogic Data Service Platform.... pues bien, me encontre con un webcast que al menos en el nombre se me hace interesante.... espero lo puedan atender, la cita es el dia 30 de Mayo
Aqui los datos:
TITLE: Data Services: Essential Foundation For SOA Success
WHEN: May 30, 2007 at 2:00 PM EDT (18:00 GMT)
SPEAKER: Sandy Rogers - Program Director for SOA, Web services, and Integration Research at IDC
SPEAKER: Robert Eve - VP Marketing, Composite Software
SPONSOR: Composite Software
SITE: SearchWebServices.com
Sale pues ahi ta
Por una integracion mejor, hasta la vista!
Tuzo
Hace unos dias me encargaron la mision de trabajar cosas de Data Services usando Aqualogic Data Service Platform.... pues bien, me encontre con un webcast que al menos en el nombre se me hace interesante.... espero lo puedan atender, la cita es el dia 30 de Mayo
Aqui los datos:
TITLE: Data Services: Essential Foundation For SOA Success
WHEN: May 30, 2007 at 2:00 PM EDT (18:00 GMT)
SPEAKER: Sandy Rogers - Program Director for SOA, Web services, and Integration Research at IDC
SPEAKER: Robert Eve - VP Marketing, Composite Software
SPONSOR: Composite Software
SITE: SearchWebServices.com
Sale pues ahi ta
Por una integracion mejor, hasta la vista!
Tuzo
Suscribirse a:
Entradas (Atom)