Un tema que parece reciente, Domain Specific Language, es algo que estuve leyendo en esta madrugada
Sin embargo, me desentierra una idea que tuve desde hace 15 años, cuando estaba en la carrera, y viendo compiladores.
Todo empezo con el libro del sabio Bertrand Meyer, Introduction to the Theory of programming language, que describe la teoria necesaria para diseñar un lenguaje de programacion, utilizando conceptos como calculo lambda, semantica denotacional. Pero un punto muy importante del que hablar Meyer es que cualquier computo puede ser expresado en un lenguaje de programacion, y lo mejor, que es posible la definicion de un lenguaje especifico a un problema o dominio en particular.
Por ejemplo, se puede definir un lenguaje para definir interfaces graficas, ya sea definiendo una sintaxis que se puede interpretar o compilar; o se puede crear un API en algun lenguaje.
Y precesiamente, el concepto de DSL es que se defina un lenguaje de programacion que exprese de mejero manera el dominio del problema a definir.
Para no explicar mal, les dejo estas ligas
Martin Fowler
Java World
lunes, 14 de julio de 2008
martes, 24 de junio de 2008
Google Developer Day 2008
Ayer fue un día muy emocionante: el primer Google Developer Day en México.
Único desde el proceso de inscripción en el cual tenías que proporcionar mucho de tu perfil e incluso url's de aplicaciones desarrolladas.
Finalmente llegó la confirmación y empezó la cuenta atrás para la fecha del evento y la travesía de media ciudad (o ciudad y media) para arribar al Centro Banamex.
El registro simple y directo. Cero complicaciones. Se perfilaba el look de la gente de Google, todos con unas curiosas batas tipo laboratorio.
En ese momento fue cuando empecé a encontrar conocidos y a conocer a muchas personas. Varios amigos nos fuimos encontrando y se fue armando la banda antes de entrar al salón de las conferencias plenarias.
Estas conferencias estuvieron interesantes, si tuviera que reducir al máximo lo que me dejaron quedan solamente dos palabras: comunidad y compartir. Realmente creó que la gente de Google se preparó para dar un mensaje positivo, incluyente e incluso comercial pero en un marco de una relación "ganar-ganar".
Al termino de las plenarias se organizó un brunch y me impactó de sobre manera la diferencia de cultura, actitudes y gente contra la conferencia gubernamental que se llevaba a cabo paralelamente. El área de los visitantes del GDD era un bonche de puffs para desparramarte a tu gusto. Lamentablemente no fueron suficientes y algunos tuvimos que buscar espacios alternativos.
Las conferencias por separado (breakout) dieron inicio y me apunté a la que trataba el tema de Google App Engine (GAE). Lo primero que me decepcionó fue ver que ponente utilizaba Windows... al menos era XP. Lo noté nervioso y algunas veces novatón. Esperaba más de la presentación.
A continuación vino el tema de GWT, que ya lo conocía y que me pareció interesante escucharlo de alguien que lo conoce muy, muy, muy a fondo. Excelente ponente.
El penúltimo tema fue Gears, la herramienta de Google para desarrollar aplicaciones web que pueden funcionar fuera de línea (offline). El ponente estuvo de miedo: ¡excelente! Y pues el tema da harto para hablar.
La última presentación a la que asistí fue la de OpenSocial + GAE. El ponente ya estaba muy cansado y la veda' fue como que de medio hueva.... pero bueno...
Como casi siempre lo mejor de todo fue la gente. Harto twittero, harto geek, harto conocido. Creo que a la fecha ha sido el mejor evento del año.
Finito.
Único desde el proceso de inscripción en el cual tenías que proporcionar mucho de tu perfil e incluso url's de aplicaciones desarrolladas.
Finalmente llegó la confirmación y empezó la cuenta atrás para la fecha del evento y la travesía de media ciudad (o ciudad y media) para arribar al Centro Banamex.
El registro simple y directo. Cero complicaciones. Se perfilaba el look de la gente de Google, todos con unas curiosas batas tipo laboratorio.
En ese momento fue cuando empecé a encontrar conocidos y a conocer a muchas personas. Varios amigos nos fuimos encontrando y se fue armando la banda antes de entrar al salón de las conferencias plenarias.
Estas conferencias estuvieron interesantes, si tuviera que reducir al máximo lo que me dejaron quedan solamente dos palabras: comunidad y compartir. Realmente creó que la gente de Google se preparó para dar un mensaje positivo, incluyente e incluso comercial pero en un marco de una relación "ganar-ganar".
Al termino de las plenarias se organizó un brunch y me impactó de sobre manera la diferencia de cultura, actitudes y gente contra la conferencia gubernamental que se llevaba a cabo paralelamente. El área de los visitantes del GDD era un bonche de puffs para desparramarte a tu gusto. Lamentablemente no fueron suficientes y algunos tuvimos que buscar espacios alternativos.
Las conferencias por separado (breakout) dieron inicio y me apunté a la que trataba el tema de Google App Engine (GAE). Lo primero que me decepcionó fue ver que ponente utilizaba Windows... al menos era XP. Lo noté nervioso y algunas veces novatón. Esperaba más de la presentación.
A continuación vino el tema de GWT, que ya lo conocía y que me pareció interesante escucharlo de alguien que lo conoce muy, muy, muy a fondo. Excelente ponente.
El penúltimo tema fue Gears, la herramienta de Google para desarrollar aplicaciones web que pueden funcionar fuera de línea (offline). El ponente estuvo de miedo: ¡excelente! Y pues el tema da harto para hablar.
La última presentación a la que asistí fue la de OpenSocial + GAE. El ponente ya estaba muy cansado y la veda' fue como que de medio hueva.... pero bueno...
Como casi siempre lo mejor de todo fue la gente. Harto twittero, harto geek, harto conocido. Creo que a la fecha ha sido el mejor evento del año.
Finito.
miércoles, 5 de marzo de 2008
Con muchas cosas que compartir..
Hi folks.... pues regresando a dar un poquito de lata.
Ya con los primeros 2 meses del año que se fueron como agua...he de comentarles que este año trae consigo retos muy importantes tanto en lo profesional como en lo personal y hay que enfrentarlos como dice una cancion... con alma vida y corazon
Pues a lo que me truje chencha dijeran...
Hay muchos temas que me interesa tocar: SOA, Arquitectura Empresarial, Continuar con los ejemplos de Integracion de aplicaciones, hablar de algunos modelos y marcos de referencia, mas de ESBs Open Source, en fin...
Estos 2 dias estaremos asistiendo el buen Gus y su servidor a platicas de Cutter Enterprise Architectre Summit, de entrada las platicas del dia de hoy me parecieron bastante interesantes en especial la denominada "Enterprise Architecture By Example" el ponenete Mike Rosen.
Ya hablare mas a detalle de AE, pero de entrada creo que hoy dia estamos entrando a un punto interesante en la parte de Arquitectura, mas alla de la Arquitectura de Software (que como parte de la AE no deja de ser importante), existen diferentes aspectos que que necesitamos tomar en cuentas al definir una arquitectura empresarial, Mike lo denomina Enterprise Architecture Stack, y se compone principalmente de 4 arquitecturas:
Mike menciona tambien que existen un modelo para evaluar la Madures de una Arquitectura Empresarial, tal como lo manejan el CMMI o el SOA Maturity Model.. ya platicare de esto con un poco mas de detalle.
Bueno pues los dejo con una presentacion que me parecio interesante se llama: Pragmatic SOA by Arjen Poutsma, espero la visiten
Ciao
Tuzo
Ya con los primeros 2 meses del año que se fueron como agua...he de comentarles que este año trae consigo retos muy importantes tanto en lo profesional como en lo personal y hay que enfrentarlos como dice una cancion... con alma vida y corazon
Pues a lo que me truje chencha dijeran...
Hay muchos temas que me interesa tocar: SOA, Arquitectura Empresarial, Continuar con los ejemplos de Integracion de aplicaciones, hablar de algunos modelos y marcos de referencia, mas de ESBs Open Source, en fin...
Estos 2 dias estaremos asistiendo el buen Gus y su servidor a platicas de Cutter Enterprise Architectre Summit, de entrada las platicas del dia de hoy me parecieron bastante interesantes en especial la denominada "Enterprise Architecture By Example" el ponenete Mike Rosen.
Ya hablare mas a detalle de AE, pero de entrada creo que hoy dia estamos entrando a un punto interesante en la parte de Arquitectura, mas alla de la Arquitectura de Software (que como parte de la AE no deja de ser importante), existen diferentes aspectos que que necesitamos tomar en cuentas al definir una arquitectura empresarial, Mike lo denomina Enterprise Architecture Stack, y se compone principalmente de 4 arquitecturas:
- Arquitectura de Negocio: Cadenas de valor , Modelos del negocio, Portafolio de servicios, Procesos de negocio
- Arquitectura de Informacion: Informacion que soporta la toma de decisiones, Modelos de datos del negocio, informacion de datos operacionales y transaccionales
- Arquitectura de Aplicaciones: Informacion de las responsabilidades de los componentes que forman parte de una aplicacion
- Arquitectura Tecnologica: Harware, software, Infraestructura de Red, Data Centers
Mike menciona tambien que existen un modelo para evaluar la Madures de una Arquitectura Empresarial, tal como lo manejan el CMMI o el SOA Maturity Model.. ya platicare de esto con un poco mas de detalle.
Bueno pues los dejo con una presentacion que me parecio interesante se llama: Pragmatic SOA by Arjen Poutsma, espero la visiten
Ciao
Tuzo
viernes, 28 de diciembre de 2007
La ultima entrada del 2007
Pues mientras casi todo mundo esta de vacaciones y yo sintiendome como el cuadrado de Flatland, que intuye que hay mas alla de lo que normalmente se llama vida, expongo las ideas para cerrar el año (odio medir la vida en cierres de año, por lo que esta es señal de que estoy envejeciendo y volviendome algo conservador)
Llevo años hablando de Arquitectura Empresarial (Zachman, FEA, TOGAF) y tratando de explicar en que consiste
Lo que me doy cuenta es como he evolucionado en el enfoque y me permito hacer una simulacion de una bitacora de como fue la historia
+ La primera vez, fue cuando me pidieron hiciera un modelo de arquitectura para todas las arquitecturas. Fue hace ya 4 años y me fui topando con el concepto de arquitectura empresarial. Despues de un rato de investigar y medio juntar bibliografia, me di cuenta de la famosa matriz de Zachman. Como cuate mas orientado a los bytes, me clave mucho en la parte tecnologica y por ahi me surgio la idea de hablar de arquitectura de aplicaciones, datos e infraestructura y obtener un modelo para soportar integracion entre aplicaciones y unificarlas
+ La segunda vez, un buen amigo, Juan Lozada, me ayudo a entender como en la practica se puede concebir el marco de Zachman. Y de el oi los terminos como Governance y referencia a modelos de calidad o mejores practicas como CMMI, ITIL, COBIT, PMBOK. De ahi salieron documentos que tenian como objetivo el normar el actuar de toda una organizacion y todo parecia indicar que ya habia algo hecho
+ Pero el tratar de hacer la vision realidad siempre fue un reto. Llegas con tu marco de referencia (el cual por cierto no era perfecto) y te topas que ya existen aplicaciones ejecutandose y que fueron hechas sin tomar en cuenta el concepto de arquitectura, sin embargo estan operando y dando servicio y generando impacto en la organizacion. No tienen la mejor arquitectura sin embargo son valores de lao organizacion. ¿Entonces que hacer? Ponerse en un papel dogmatico tipo Iglesia en la Edad Media o ser tolerante. La respuesta era obvia ser tolerante y tratar de organizar poco a poco para que las aplicaciones empiecen a tomar buenas practicas
+ Sin embargo, los eventos externos, eventos politicos, riñas de poder, no permiten que la vision sea comprendida, atascado un rato en resolver problemas operativos, pobre marco de referencia de arquitectura empresarial empolvandose. Sin embargo si se dispone de tecnlogia, ESB, Gestor de contenido, Motor de reglas de negocio, muchos sabores de BPM, marco de referencia, muchas maneras de hacer sevicios Web, Portal, registro UDDI
+ Cambio de aires, nueva administracion en la organizacion, se topan con que existe mucha tecnologia, muchas aplicaciones, pero visiones dispares y tambien costos altos en TI que deben ser controlados. Lo que si reconocen es que no hay estandares. Sin embargo si se habian definido. ¿Que habia pasado? El modelo de la organizacion orienta a que se creen silos de informacion, poco unificados y muy propensos a ser manipulados por cuestiones politicas.
+ El problema no es tanto la cuestion tecnologica es la interoperabilidad entre las personas. La vision del marco de referencia de Zachman necesita tomar en cuenta a la organizacion. Ups! Creo que el primer renglon del marco de Zachman si sirve para algo!
+ Chamba para unificar las visiones, se confunden proyectos para beneficio como cotos de poder para poder impresionar a los altos mandos de la TI. Se manipulan conceptos tecnologicos para hacer creer que existen muchos beneficios en hacerlo pero sin tomar en cuenta el como, olvidando que la organizacion necesita un alto impacto. Sin embargo, no son malas ideas, algo tiene que unificar todo, algo como un marco de referencia de arquitectura empresarial.
+ Eureka, platicando con un amigo, me sugiere que si quiero hablar de una arquitectura empresarial, piense en un modelo de operacion de servicios (operation management). Me doy cuenta que no era lo mismo que investigacion de operaciones. Me compro tres y muy buenos libros en el tema y me doy cuenta que hablan de procesos, servicios, cadenas de valor, mucho de ellos aplicados para ERP, CRM, SCM. ¡Sin embargo no quiero que la organizacion donde estoy trate de solucionar todo con un ERP! He dicho muchas cosas sobre lo que pienso sobre un ERP pero principalmente no es la panacea y menos para la organizacion donde trabajo
+ Pero el modelo de administracion de operaciones es bueno. Pienso en que cadenas de valor tenemos:
+ La que da servicios a nuestros clientes (ciudadanos). Su objetivo es fomentar el autoservicio y darles la mayor informacion que necesiten sin enredarlos en procesos burocraticos. Un call center, un portal y otras estrategias bien diseñadas (como kiosocos) pueden dar impacto. Pero es muy importante que este cadena de valor se flexible, la menos complicada y la que debe ser capaz de entregar la informacion a los ciudadanos sin importar su condicion social, educacion
+ La que soporta la operacion de la organizacion. La organizacion esta basada en servicios, no manufactura, pero es muy criticada por los servicios que da y su burocracia. Entonces es necesario que la cadena de valor de operacion sea capaz de permitir que los que otorgan el servicio conozcan de su trabajo (gestion del conocimiento), que tengan un proceso base que seguir y que se pueda medir (BPM y BAM) y con referencia a modelos de calidad (TQM, Six Sigma, ISO), permitir que manipulen sus procesos y reglas de negocio, fomentar flujos de trabajo centrados en documentos (gestion de contenido). Ademas otorgarles herramientas de TI para innovar (colaboracion, mashups, Web 2.0), hacer un portal de operacion de la organizacion
+ La que soporta todos los procesos de la organizacion. Tomar las aplicaciones ya existentes y convertirlas a servicios, utilizando SOA, usar las herramientas como ESB, Data Services y gobernarlos a traves de un servicio de registros. Esto es el "backend" de la organizacion.
+ La que soporta a los administradores de la organizacion, alta direccion, los que definen las politicas, los modelos de operacion, manejan presupuesto, toman decisiones, tienen que cumplir con normatividad gubernamental. Dar herramientas especializadas que tomen informacion de todas las demas cadenas de valores, analisis de informacion y procesos, simulacion. Integrarlos para que usando la TI definan y mejoren los procesos de la organizacion
+ La que soporta la informacion de la organizacion, la cadena de valor de TI. La TI para innovar. Definir catalogos de servicios con ITIL, mesa de ayuda para TI, aplicar los modelos de desarrollo y mantnimiento de software (CMMI RUP), oficina de administracion de proyectos (PMO, PMBOK), servicios de infraestructura de software y hardware, orientar a calidad en servicios de TI, hacer que cada integrante de TI sea un agente de cambio e innovacion
+Entonces la arquitectura empresarial es entender a las cadenas de valor de la organizacion, soportar su ejecucion con Tecnologia de Informacion y utilizar como estrategia de implantacion los modelos de SOA+BPM+ Web 2.0
Suena muy bien la idea. Es un buen reto, me imagino que si se logra en la organizacion puede hacer que la TI le de el valor. Hace justicia a nuestra chamba de ingenieros y lo mas importante, hace que nuestros clientes tengan servicios de primera
El punto es convencer a mucha gente, a la propia de TI, a los demas no TI de la organizacion. a los clientes, proveedores y reguladores
Interoperabilidad entre personas, lo mas dificil, buen reto para el 2008, pero vale la pena intentarlo
Llevo años hablando de Arquitectura Empresarial (Zachman, FEA, TOGAF) y tratando de explicar en que consiste
Lo que me doy cuenta es como he evolucionado en el enfoque y me permito hacer una simulacion de una bitacora de como fue la historia
+ La primera vez, fue cuando me pidieron hiciera un modelo de arquitectura para todas las arquitecturas. Fue hace ya 4 años y me fui topando con el concepto de arquitectura empresarial. Despues de un rato de investigar y medio juntar bibliografia, me di cuenta de la famosa matriz de Zachman. Como cuate mas orientado a los bytes, me clave mucho en la parte tecnologica y por ahi me surgio la idea de hablar de arquitectura de aplicaciones, datos e infraestructura y obtener un modelo para soportar integracion entre aplicaciones y unificarlas
+ La segunda vez, un buen amigo, Juan Lozada, me ayudo a entender como en la practica se puede concebir el marco de Zachman. Y de el oi los terminos como Governance y referencia a modelos de calidad o mejores practicas como CMMI, ITIL, COBIT, PMBOK. De ahi salieron documentos que tenian como objetivo el normar el actuar de toda una organizacion y todo parecia indicar que ya habia algo hecho
+ Pero el tratar de hacer la vision realidad siempre fue un reto. Llegas con tu marco de referencia (el cual por cierto no era perfecto) y te topas que ya existen aplicaciones ejecutandose y que fueron hechas sin tomar en cuenta el concepto de arquitectura, sin embargo estan operando y dando servicio y generando impacto en la organizacion. No tienen la mejor arquitectura sin embargo son valores de lao organizacion. ¿Entonces que hacer? Ponerse en un papel dogmatico tipo Iglesia en la Edad Media o ser tolerante. La respuesta era obvia ser tolerante y tratar de organizar poco a poco para que las aplicaciones empiecen a tomar buenas practicas
+ Sin embargo, los eventos externos, eventos politicos, riñas de poder, no permiten que la vision sea comprendida, atascado un rato en resolver problemas operativos, pobre marco de referencia de arquitectura empresarial empolvandose. Sin embargo si se dispone de tecnlogia, ESB, Gestor de contenido, Motor de reglas de negocio, muchos sabores de BPM, marco de referencia, muchas maneras de hacer sevicios Web, Portal, registro UDDI
+ Cambio de aires, nueva administracion en la organizacion, se topan con que existe mucha tecnologia, muchas aplicaciones, pero visiones dispares y tambien costos altos en TI que deben ser controlados. Lo que si reconocen es que no hay estandares. Sin embargo si se habian definido. ¿Que habia pasado? El modelo de la organizacion orienta a que se creen silos de informacion, poco unificados y muy propensos a ser manipulados por cuestiones politicas.
+ El problema no es tanto la cuestion tecnologica es la interoperabilidad entre las personas. La vision del marco de referencia de Zachman necesita tomar en cuenta a la organizacion. Ups! Creo que el primer renglon del marco de Zachman si sirve para algo!
+ Chamba para unificar las visiones, se confunden proyectos para beneficio como cotos de poder para poder impresionar a los altos mandos de la TI. Se manipulan conceptos tecnologicos para hacer creer que existen muchos beneficios en hacerlo pero sin tomar en cuenta el como, olvidando que la organizacion necesita un alto impacto. Sin embargo, no son malas ideas, algo tiene que unificar todo, algo como un marco de referencia de arquitectura empresarial.
+ Eureka, platicando con un amigo, me sugiere que si quiero hablar de una arquitectura empresarial, piense en un modelo de operacion de servicios (operation management). Me doy cuenta que no era lo mismo que investigacion de operaciones. Me compro tres y muy buenos libros en el tema y me doy cuenta que hablan de procesos, servicios, cadenas de valor, mucho de ellos aplicados para ERP, CRM, SCM. ¡Sin embargo no quiero que la organizacion donde estoy trate de solucionar todo con un ERP! He dicho muchas cosas sobre lo que pienso sobre un ERP pero principalmente no es la panacea y menos para la organizacion donde trabajo
+ Pero el modelo de administracion de operaciones es bueno. Pienso en que cadenas de valor tenemos:
+ La que da servicios a nuestros clientes (ciudadanos). Su objetivo es fomentar el autoservicio y darles la mayor informacion que necesiten sin enredarlos en procesos burocraticos. Un call center, un portal y otras estrategias bien diseñadas (como kiosocos) pueden dar impacto. Pero es muy importante que este cadena de valor se flexible, la menos complicada y la que debe ser capaz de entregar la informacion a los ciudadanos sin importar su condicion social, educacion
+ La que soporta la operacion de la organizacion. La organizacion esta basada en servicios, no manufactura, pero es muy criticada por los servicios que da y su burocracia. Entonces es necesario que la cadena de valor de operacion sea capaz de permitir que los que otorgan el servicio conozcan de su trabajo (gestion del conocimiento), que tengan un proceso base que seguir y que se pueda medir (BPM y BAM) y con referencia a modelos de calidad (TQM, Six Sigma, ISO), permitir que manipulen sus procesos y reglas de negocio, fomentar flujos de trabajo centrados en documentos (gestion de contenido). Ademas otorgarles herramientas de TI para innovar (colaboracion, mashups, Web 2.0), hacer un portal de operacion de la organizacion
+ La que soporta todos los procesos de la organizacion. Tomar las aplicaciones ya existentes y convertirlas a servicios, utilizando SOA, usar las herramientas como ESB, Data Services y gobernarlos a traves de un servicio de registros. Esto es el "backend" de la organizacion.
+ La que soporta a los administradores de la organizacion, alta direccion, los que definen las politicas, los modelos de operacion, manejan presupuesto, toman decisiones, tienen que cumplir con normatividad gubernamental. Dar herramientas especializadas que tomen informacion de todas las demas cadenas de valores, analisis de informacion y procesos, simulacion. Integrarlos para que usando la TI definan y mejoren los procesos de la organizacion
+ La que soporta la informacion de la organizacion, la cadena de valor de TI. La TI para innovar. Definir catalogos de servicios con ITIL, mesa de ayuda para TI, aplicar los modelos de desarrollo y mantnimiento de software (CMMI RUP), oficina de administracion de proyectos (PMO, PMBOK), servicios de infraestructura de software y hardware, orientar a calidad en servicios de TI, hacer que cada integrante de TI sea un agente de cambio e innovacion
+Entonces la arquitectura empresarial es entender a las cadenas de valor de la organizacion, soportar su ejecucion con Tecnologia de Informacion y utilizar como estrategia de implantacion los modelos de SOA+BPM+ Web 2.0
Suena muy bien la idea. Es un buen reto, me imagino que si se logra en la organizacion puede hacer que la TI le de el valor. Hace justicia a nuestra chamba de ingenieros y lo mas importante, hace que nuestros clientes tengan servicios de primera
El punto es convencer a mucha gente, a la propia de TI, a los demas no TI de la organizacion. a los clientes, proveedores y reguladores
Interoperabilidad entre personas, lo mas dificil, buen reto para el 2008, pero vale la pena intentarlo
jueves, 22 de noviembre de 2007
Libro Open Source ESBs in Action
Por fin!
Con alegria me entere que ya salio un libro que trata de ESBs Open Source (Manning), el capitulo 1 esta disponible para lectura en linea. Mule ESB, Service Mix, Open ESB, Jboss ESB, Synapse son algunos de los que se mencionan en el libro.
Explorare su contenido y ya dare mis comentarios.
Existe otro libro de ESB pero este habla de Aqualogic Service Bus, el titulo del libro es: The Definitive Guide to SOA: BEA Aqualogic Service Bus.
Saludos!
Tuzo
Con alegria me entere que ya salio un libro que trata de ESBs Open Source (Manning), el capitulo 1 esta disponible para lectura en linea. Mule ESB, Service Mix, Open ESB, Jboss ESB, Synapse son algunos de los que se mencionan en el libro.
Explorare su contenido y ya dare mis comentarios.
Existe otro libro de ESB pero este habla de Aqualogic Service Bus, el titulo del libro es: The Definitive Guide to SOA: BEA Aqualogic Service Bus.
Saludos!
Tuzo
lunes, 19 de noviembre de 2007
Configuración de Rails y SQL Server
La naturaleza multiplataforma de Ruby On Rails nos demanda adecuarnos a todos los ambientes de ejecución disponibles aún y cuando estos no sigan la filosofía del software libre.
Un ambiente que se va a presentar muy comunmente es Windows y SQL Server.
Entonces he aquí la receta sencilla y probada para soportar SQL Server dentro de Rails.
Primero, habrá que descargarse la gem ruby-dbi desde http://rubyforge.org/projects/ruby-dbi . ruby-dbi es un mecanismo de acceso a datos inspirado en Perl::DBI. En la gem viene incluido el soporte a varias bases de datos y durante el proceso de instalación se selecciona cuales se van a soportar.
La descarga es un archivo .tar el cual se expande en un directorio desde el cual ejecutamos las siguientes instrucciones:
Con esto ya tenemos la capacidad de acceder a SQL Server desde Ruby. Ahora falta configurar SQL Server para que permita conexiones mediante usuario/contraseña. Para esto configuramos el modo de autenticación "mixed" dentro de las propiedades de seguridad del servidor.
A continuación se crean el login de SQL Server y la base de datos asociando el login como dbo de la base recién creada y se crea el proyecto rails como de costumbre.
Después se actualizan los datos del archivo config/database.yml
Esta configuración funciona con las versiones 2000 y 2005 de SQL Server. La diferencia que he encontrado es el manejo de valores nulos en columnas de tipo integer. En SQL Server 2005 sustituye los valores nulos con ceros mientras que en la versión 2000 funciona correctamente.
Finito.
Un ambiente que se va a presentar muy comunmente es Windows y SQL Server.
Entonces he aquí la receta sencilla y probada para soportar SQL Server dentro de Rails.
Primero, habrá que descargarse la gem ruby-dbi desde http://rubyforge.org/projects/ruby-dbi . ruby-dbi es un mecanismo de acceso a datos inspirado en Perl::DBI. En la gem viene incluido el soporte a varias bases de datos y durante el proceso de instalación se selecciona cuales se van a soportar.
La descarga es un archivo .tar el cual se expande en un directorio desde el cual ejecutamos las siguientes instrucciones:
# primero configuramos el ambiente para usar ActiveX Data Objects (depende de win32ole)
c:\>ruby setup.rb config --with=dbi,dbd_ado
# la llamada de siempre
c:\>ruby setup.rb setup
# finalmente la instalación
c:\>ruby setup.rb install
Con esto ya tenemos la capacidad de acceder a SQL Server desde Ruby. Ahora falta configurar SQL Server para que permita conexiones mediante usuario/contraseña. Para esto configuramos el modo de autenticación "mixed" dentro de las propiedades de seguridad del servidor.
A continuación se crean el login de SQL Server y la base de datos asociando el login como dbo de la base recién creada y se crea el proyecto rails como de costumbre.
c:\>rails proyecto
Después se actualizan los datos del archivo config/database.yml
development:
adapter: sqlserver
database: database_development
username: user
password: password
host: .\SQLEXPRESS
Esta configuración funciona con las versiones 2000 y 2005 de SQL Server. La diferencia que he encontrado es el manejo de valores nulos en columnas de tipo integer. En SQL Server 2005 sustituye los valores nulos con ceros mientras que en la versión 2000 funciona correctamente.
Finito.
martes, 6 de noviembre de 2007
La importancia de los contratos
Hace unos dias en el trabajo me encomendaron la tarea de trabajar con unos compañeros que deseaban exponer unos servicios de Abastecimiento de medicamentos a sus proveedores....
Ellos ya habian avanzado un poco y me comentaban "Ya tenemos desarrollados unos WebServices", a lo que les pedi que me pasaran su WSDL
Al echarle un vistazo a ese documento me encontre algo como lo siguiente (entre otras cosas):
como operacion de entrada:
s:element name="ObtenerOrdenes"
como parametro:
element minOccurs="0" maxOccurs="1" name="SQL" type="s:string"
como respuesta:
s:any
Ok veamos que tenemos. El nombre OBTENERORDENES de entrada me suena a negocio hasta ahi todo va bien, el problema viene en el parametro que estan pasando se llama SQL, que por el solo nombre me pone a pensar que estan pasando sentencias de SQL para hacer la consulta (lo cual deja abierto al cliente a poner cualquier cosa dentro de la consulta)
Luego veamos la respuesta, si vemos regresa un Any (Que los que han leido el blog, siempre nos oponemos al uso de ANY como resultado o entrada) que cuando les pregunte me dijeron coloquialmente que ahi regresaban el "ResulSet" ajale!!! osea que si regresan la consulta tal cual de su base de datos.... y para finalizar en el servicio no hay ningun mensaje que indique los errores que pueden ocurrir.
Bien ya no pongo los demas metodos, porque solo estos me permiten ejemplificar la importancia de manejar un buen contrato.
Al diseñar un contrato de negocio de un servicio (independientemente si lo vas a hacer con: Web Services, RMI, COM, o palomas mensajeras) es muy importante definir los mensajes que estatas intercambiando entre el servicio, es decir, basicamente es constuir un layout (que tenga nombres, tipos de datos, tamaño y si es obligatorio el campo) de las ENTRADAS, SALIDAS y MENSAJES DE ERROR.
Asi de sencillo, en verdad utilizar esta practica nos ayudado mucho cuando tratamos de integrar aplicaciones.
Saludos
Tuzo
Ellos ya habian avanzado un poco y me comentaban "Ya tenemos desarrollados unos WebServices", a lo que les pedi que me pasaran su WSDL
Al echarle un vistazo a ese documento me encontre algo como lo siguiente (entre otras cosas):
como operacion de entrada:
s:element name="ObtenerOrdenes"
como parametro:
element minOccurs="0" maxOccurs="1" name="SQL" type="s:string"
como respuesta:
s:any
Ok veamos que tenemos. El nombre OBTENERORDENES de entrada me suena a negocio hasta ahi todo va bien, el problema viene en el parametro que estan pasando se llama SQL, que por el solo nombre me pone a pensar que estan pasando sentencias de SQL para hacer la consulta (lo cual deja abierto al cliente a poner cualquier cosa dentro de la consulta)
Luego veamos la respuesta, si vemos regresa un Any (Que los que han leido el blog, siempre nos oponemos al uso de ANY como resultado o entrada) que cuando les pregunte me dijeron coloquialmente que ahi regresaban el "ResulSet" ajale!!! osea que si regresan la consulta tal cual de su base de datos.... y para finalizar en el servicio no hay ningun mensaje que indique los errores que pueden ocurrir.
Bien ya no pongo los demas metodos, porque solo estos me permiten ejemplificar la importancia de manejar un buen contrato.
Al diseñar un contrato de negocio de un servicio (independientemente si lo vas a hacer con: Web Services, RMI, COM, o palomas mensajeras) es muy importante definir los mensajes que estatas intercambiando entre el servicio, es decir, basicamente es constuir un layout (que tenga nombres, tipos de datos, tamaño y si es obligatorio el campo) de las ENTRADAS, SALIDAS y MENSAJES DE ERROR.
Asi de sencillo, en verdad utilizar esta practica nos ayudado mucho cuando tratamos de integrar aplicaciones.
Saludos
Tuzo
Suscribirse a:
Entradas (Atom)