Hace un par de semanas me involucré en un proyecto para desarrollar una aplicación para una agencia de cinematografía. La "prueba de concepto" (como dicen los grandes consultores) la hice en Rails 3 con alguna de las nuevas gemas de la corona. Incluso así se mostró el proyecto al prospecto a cliente. Sobra decir que le gustó la aplicación pero dejó en claro que no estaba dentro de sus prioridades inmediatas. No problema por eso, pero parte de la reunión también fue revisar su actual servicio de hosting para validar el soporte a Rails.
El servicio de USD$8.00 al mes no da para mucho. Claro que no para soportar Rails. ¿Qué hacer entonces? ¿Qué hacer con un hosting debajo de básico que solamente soporta cpanel? Aparecía soporte para Python ¡Oh si! No es Ruby pero no se puede caer más bajo ¿o si? Deficiente soporte. Mis habilidades cpanel'istas no dieron para arrancar web2py en el servidor.
Y ahí, debajo de la manta del 'te lo dije' apareció PHP. OMG! Sí, tendría que usar PHP. ¿Cómo podría hacer menos traumática la experiencia? Una breve búsqueda en Google me arrojó la referencia a Symfony, un framework MVC muy interesante y no tan lejano del modo Rails. Lo descargué en mi máquina, seguí el tuto y conseguí arrancar un módulo completo (controlador, vistas y modelo).
En ese momento decidí hacer la prueba de fuego. Subirlo al servidor y echarlo a andar. FAIL!. Symfony también funciona a base de 'generators' y como tal requiere el acceso a la línea de comandos. USD$24.00 al mes me darían acceso pero no hubo respuesta favorable del cliente. El tan interesante y correcto framework tuvo así que ser descartado.
¿Qué queda a estas alturas? ¿Qué queda después de buscar opciones correctas? ¿Qué queda después de buscar las mejores tecnologías? Usar tecnologías crudas, simplistas y mezclarlas con scripts de internet. Hacer un pequeño Frankestein. Y finalmente es más fácil hacerlo con PHP que con otra selección.
¿Es esa la explicación del bajo nivel que generalmente se asocia a PHP? Al no tener más opción que trabajar con lo menos (hosting de USD$8.00) hay que hacer lo peor. Hacer lo menos. Hacer lo que funcione como sea.
Symfony es una muy buena muestra de un buen nivel de desarrollo con PHP. Encontré otros frameworks minimalistas al estilo de Sinatra (Frank.php) y similares pero la limitante del hosting no permitió aprovecharlos. Solo queda hacer el trabajo sucio con código sucio. Y será en PHP. Don't take it that hard.
Finito.
Mostrando las entradas con la etiqueta architecture. Mostrar todas las entradas
Mostrando las entradas con la etiqueta architecture. Mostrar todas las entradas
domingo, octubre 10, 2010
lunes, noviembre 19, 2007
MVC significa "Más-Visto-que-Conocido"
Ultimamente se le ha dado una extensa difusión al hecho de que Microsoft está preparando una implementación del patrón de diseño MVC.
Una vez más Microsoft llega tarde y para evitar poner su cara de perdedor monta la fanfarria para compartir su última gran innovación.
MVC, el patrón, es una de las cosas más antiguas en la ingeniería de software. Fue desarrollado circa 1980 en los (realmente innovadores) laboratorios Xerox buscando una manera de separar los diferentes "concerns" al momento de construir una aplicación. Hasta ahí lo dejaron entonces.
Posteriormente, Sun Microsystems al lanzar su parafernalia conocida como J2EE buscó algo en que apoyarse para facilitar el desarrollo de aplicaciones web (el infame modelo 2), cosa que encontró en MVC dejando atrás incluso tecnologías que ellos mismos habían desarrollado.
Fue tan buena la aceptación del uso de este concepto que en el mundo del código libre aparecieron varias implementaciones del patrón MVC más puristas o independientes a Sun. Así encontramos Struts, Spring, Tapestry, WebWork y muchos otros más que por diversas cuestiones pasaron a la posteridad.
Al ser un patrón de diseño, no depende de un lenguaje o artefacto específico, sino que representa una solución genérica para aplicarse en las más diversas situaciones.
El corazón de MVC es la división de una aplicación delimitando específicamente sus responsabilidades, así tenemos:
El beneficio final de usar este patrón es la simplificación en la distribución de responsabilidades, al aislar las acciones que corresponden a cada clase participante del sistema. En pocas palabras en una excelente idea.
Es por eso que desde hace más de veinte años que alguien tuvo la ocurrencia de inventarlo (no sé realmente si valga la expresión "inventar") se utiliza obligadamente en la construcción de aplicaciones web, excepto claro, en aquellos casos en los que la premisa es No-inventado-aquí.
Hace cerca de ocho años cuando Microsoft lanzó al mercado la tecnología .NET presentó su alternativa para el desarrollo web: los formularios Web. Una idea interesante, complicada de aprender de inicio que trajo a las herramientas de Microsoft algo del dinamismo indispensable para seguir en la contienda.
Aunque algunas personas han cuestionado la cuota de mercado que ha ganado .NET, un excelente indicador son las comunidades de software libre que se basan en los componentes de .NET para arrancar, construir y compartir alternativas a los productos propietarios de Microsoft. Esta corriente hasta hace un par de años no tenía un nombre aunque si varios protagonistas. Actualmente se le conoce como ALT.NET.
Dentro de estos esfuerzos de código libre se incluyó la implementación del patrón MVC para el desarrollo de aplicaciones web, en contraposición a la línea "oficial" de Redmond que se basó principalmente en otro patrón conocido como Front Page Controller (Pa'más detalles léanse "Enterprise Solution Patterns" del equipo de Patterns & Practices). Simplemente MVC no les pareció lo suficientemente bueno, no les llenó el ojo.
Siete años después y con una estela de productos open source muertos, Microsoft anuncia que la gran solución para el desarrollo web es MVC.
Microsoft llegas tarde. Como siempre.
Finito.
Una vez más Microsoft llega tarde y para evitar poner su cara de perdedor monta la fanfarria para compartir su última gran innovación.
MVC, el patrón, es una de las cosas más antiguas en la ingeniería de software. Fue desarrollado circa 1980 en los (realmente innovadores) laboratorios Xerox buscando una manera de separar los diferentes "concerns" al momento de construir una aplicación. Hasta ahí lo dejaron entonces.
Posteriormente, Sun Microsystems al lanzar su parafernalia conocida como J2EE buscó algo en que apoyarse para facilitar el desarrollo de aplicaciones web (el infame modelo 2), cosa que encontró en MVC dejando atrás incluso tecnologías que ellos mismos habían desarrollado.
Fue tan buena la aceptación del uso de este concepto que en el mundo del código libre aparecieron varias implementaciones del patrón MVC más puristas o independientes a Sun. Así encontramos Struts, Spring, Tapestry, WebWork y muchos otros más que por diversas cuestiones pasaron a la posteridad.
Al ser un patrón de diseño, no depende de un lenguaje o artefacto específico, sino que representa una solución genérica para aplicarse en las más diversas situaciones.
El corazón de MVC es la división de una aplicación delimitando específicamente sus responsabilidades, así tenemos:
- Modelo - Se encarga de la representación específica de la información perteneciente al dominio del problema. En una implementación específica se responsabiliza del acceso y recuperación de datos.
- Controlador - Es el cerebro maestro. El que se las sabe todas, todas. Los procesos de la aplicación se encuentran concentrados en un conjunto de controladores que son el corazón y el cerebro de la aplicación.
- Vista - La parte coqueta. La parte visual. La interface de usuario que se encarga únicamente de presentar la información que le entrega el controlador. Nunca se entera (al menos no al detalle) de la existencia de los modelos.
El beneficio final de usar este patrón es la simplificación en la distribución de responsabilidades, al aislar las acciones que corresponden a cada clase participante del sistema. En pocas palabras en una excelente idea.
Es por eso que desde hace más de veinte años que alguien tuvo la ocurrencia de inventarlo (no sé realmente si valga la expresión "inventar") se utiliza obligadamente en la construcción de aplicaciones web, excepto claro, en aquellos casos en los que la premisa es No-inventado-aquí.
Hace cerca de ocho años cuando Microsoft lanzó al mercado la tecnología .NET presentó su alternativa para el desarrollo web: los formularios Web. Una idea interesante, complicada de aprender de inicio que trajo a las herramientas de Microsoft algo del dinamismo indispensable para seguir en la contienda.
Aunque algunas personas han cuestionado la cuota de mercado que ha ganado .NET, un excelente indicador son las comunidades de software libre que se basan en los componentes de .NET para arrancar, construir y compartir alternativas a los productos propietarios de Microsoft. Esta corriente hasta hace un par de años no tenía un nombre aunque si varios protagonistas. Actualmente se le conoce como ALT.NET.
Dentro de estos esfuerzos de código libre se incluyó la implementación del patrón MVC para el desarrollo de aplicaciones web, en contraposición a la línea "oficial" de Redmond que se basó principalmente en otro patrón conocido como Front Page Controller (Pa'más detalles léanse "Enterprise Solution Patterns" del equipo de Patterns & Practices). Simplemente MVC no les pareció lo suficientemente bueno, no les llenó el ojo.
Siete años después y con una estela de productos open source muertos, Microsoft anuncia que la gran solución para el desarrollo web es MVC.
Microsoft llegas tarde. Como siempre.
Finito.
sábado, noviembre 17, 2007
Desarrollo multiplataforma
Actualmente estoy desarrollando una aplicación web con Rails. Lo curioso del caso son los ambientes que manejo: desarrollo, pruebas locales y servidor de prueba.
El equipo de desarrollo como imaginarán es mi laptop, el ambiente de pruebas locales es mi laptop con otro sistema operativo y el servidor de prueba está más cercano a lo que será el ambiente de producción. En la tabla a continuación muestro los detalles
| Ambiente | Características | OS | DB Server | Ruby/Rails versions |
|---|---|---|---|---|
| Desarrollo | MacBook Core 2 Duo/2GB RAM | Mac OS X 10.4 (Tiger) | sqlite3 | 1.8.6/1.2.5 |
| Pruebas Locales | MacBook Core 2 Duo/2GB RAM | Microsoft Windows XP Professional SP2 | SQL Server 2005 Express | 1.8.6/1.2.5 |
| Servidor Pruebas | HP Xeon 2.0 GHZ x 4 | Windows 2000 Advanced Server | SQL Server 2000 Enterprise Edition | 1.8.6/1.2.5 |
El soporte a SQL Server en Windows es algo laborioso de configurar (prometo detallarlo en otro post) y algo que llama mucho la atención es el diferente comportamiento de SQL Server entre sus dos versiones, 2000 y 2005. En SQL Server 2005, todos los campos enteros aún y cuando se defina el valor por defecto como null siempre aparecen con un valor '0'. En SQL Server 2000, si dices null aparace null. Tal cual.
Fuera de eso y de las obvias configuraciones el código de la aplicación es el mismo.
Por cuestiones desconocidas para mí (y creo que para el admin del servidor también) el desempeño del servidor es terriblemente malo. En los logs de Rails se registra un cálculo aproximado de peticiones que se pueden atender según el equipo en el que estamos ejecutando. En mi laptop este número varia entre 13 y 15 peticiones por segundo. En el servidor de prueba hay valores tan bajos como 4 peticiones por segundo. Espero que el ambiente de producción esté mejor operado.
Finito.
viernes, octubre 26, 2007
Rompiendo el silencio (Trabajo)
Tres semanas en el nuevo trabajo. Es el tiempo que me ha tomado adecuarme al nuevo ritmo, al menos al grado de regresar a mi actividad en twitter y ahora a postear de nuevo. Fuera de los tristes sucesos, me siento a gusto, me siento féliz. Ya ha habido quién me ha recordado la desatención que he tenido con los compañeros y amigos del antiguo trabajo y esto me ha dado pie a reflexionar un poco sobre el tema.
Hasta ahorita me he definido como un "hombre de equipo", esto es, mis amigos son en primer lugar las personas con los que trabajo todos los días. Así, cuando cambio de equipo de trabajo, cambio de amigos. Cambio hábitos de comida, de trabajo y me esfuerzo por no cambiar de trato pero como algunos reclaman, no siempre lo consigo. Una cosa curiosa es mi nuevo equipo: Yo. Actualmente en el proyecto que trabajo soy el único recurso de tiempo completo por parte de mi empresa, así que el equipo soy Yo. Ja.
Dentro de la empresa, veo muchas áreas de oportunidad: metodología, capacitación, proyectos. Ahora necesito conseguir tiempo y concentrarme en mis tiempos "muertos" a ir armando los bloques que traigo en la cabeza.
Me voy re-encontrando con herramientas y tecnologías. Una de las cosas que quiero hacer es buscar espacios para Rails, sin embargo, éste mi primer proyecto está amarrado a .NET al cual le estoy tomando sabor de nuevo. Fueron casi tres años sin tirar código para una UI y ahora al re-aprender ASP.NET influenciado por la visión Rails le encuentro un sabor distinto. Ahora me veo usando componentes que hace un par de años (o meses) veía como objetos de pecaminosa pereza pero desde un enfoque pragmático tienen su valor (y razón) de ser.
Cuando desarrollamos con Rails hacemos usos de una cantidad inmensa de clases y componentes de los cuales aprovechamos toda la funcionalidad sin preocuparnos del detalle de la implementación. De repente nos encontramos usando ActiveRecord a diestra y siniestra confiando ciegamente en que la implementación del patrón de diseño cumple con todos los cánones habidos y por haber. No hay duda ni cuestionamiento, ActiveRecord es un componente que nos permite ser más productivos ¿para qué entrar al detalle de su funcionamiento? Funciona y listo.
En mi regreso a ASP.NET estuve a punto de retomar la complejidad de implementar patrones, armar bosques de clases y aplicar todos los principios de arquitectura existentes; la realidad es que los tiempos comprometidos me están obligando a encontrar alternativas que nos permitan avanzar más rápido y tener elementos visibles, tangibles, que hagan sentido al usuario final del sistema. Se generó en mi un gran conflicto. Siempre peleé por "hacer las cosas bien, más que rápido" y ahora tengo que "hacer las cosas rápido más que bien". Al final, encontré un punto medio. La experiencia con Rails me enseño que no tengo que recrear la complejidad (usar las clases existentes de ActiveRecord en lugar de construir de cero mi implementación del patrón de diseño) sino a usar lo ya existente y confiar en que en su momento lo puedo mejorar (esto último es más "agile oriented").
Tome los componentes ASP.NET que más me latieron y conseguí avanzar un buen tramo en la construcción del sistema sin caer en un "arrastra-controles" ni re-construyendo todo por ser víctima del síndrome "No-Inventado-Aquí". Estoy cierto que de ser estrictamente necesario más adelante puedo cambiar esos componentes así que se redujo parte de mi conflicto interno.
Esta situación también me dejo entrever otra cosa: de manera natural seguimos ciclos (o espirales dirían los dialécticos). En las artes marciales se inicia con el aprendizaje portando un cinturón blanco, signo de ignorancia, conforme se avanza el cinturón se va tornando oscuro hasta llegar al negro representando la "maestría" alcanzada. Al paso del tiempo el cinturón negro se desgasta mostrando la fibras blancas originales. Simple, complejo, simple.
En el contexto del desarrollo nos adentramos con "asistentes" y construimos aplicaciones arrastrando componentes en nuestro ambiente de desarrollo. Luego vamos conociendo nuevas tecnologías que aumentan los beneficios de nuestras aplicaciones a expensas de la erudición necesaria para su uso. Patrones, técnicas, innovación amarrada a la complejidad pero esto tiene que ser así ¿cierto? Entre más fácil para el usuario, más complicado para nosotros.
En ese momento aparece Rails y entiendo el porqué de la migración. Nos olvidamos de las complicaciones. Sabemos que los componentes de Rails son implementación de patrones y conceptos que veneramos y con eso nos basta. No los ponemos en tela de juicio ni criticamos, simplemente los usamos.
Así me paso con ASP.NET, ya no cuestiono ni critico los componentes que ofrece. Aqui y ahora me hace sentido. Sé que de requerirse puedo incluir toda la complejidad que se requiera pero de momento solo necesito una cosa: que funcione y lo estoy consiguiendo.
Finito.
Hasta ahorita me he definido como un "hombre de equipo", esto es, mis amigos son en primer lugar las personas con los que trabajo todos los días. Así, cuando cambio de equipo de trabajo, cambio de amigos. Cambio hábitos de comida, de trabajo y me esfuerzo por no cambiar de trato pero como algunos reclaman, no siempre lo consigo. Una cosa curiosa es mi nuevo equipo: Yo. Actualmente en el proyecto que trabajo soy el único recurso de tiempo completo por parte de mi empresa, así que el equipo soy Yo. Ja.
Dentro de la empresa, veo muchas áreas de oportunidad: metodología, capacitación, proyectos. Ahora necesito conseguir tiempo y concentrarme en mis tiempos "muertos" a ir armando los bloques que traigo en la cabeza.
Me voy re-encontrando con herramientas y tecnologías. Una de las cosas que quiero hacer es buscar espacios para Rails, sin embargo, éste mi primer proyecto está amarrado a .NET al cual le estoy tomando sabor de nuevo. Fueron casi tres años sin tirar código para una UI y ahora al re-aprender ASP.NET influenciado por la visión Rails le encuentro un sabor distinto. Ahora me veo usando componentes que hace un par de años (o meses) veía como objetos de pecaminosa pereza pero desde un enfoque pragmático tienen su valor (y razón) de ser.
Cuando desarrollamos con Rails hacemos usos de una cantidad inmensa de clases y componentes de los cuales aprovechamos toda la funcionalidad sin preocuparnos del detalle de la implementación. De repente nos encontramos usando ActiveRecord a diestra y siniestra confiando ciegamente en que la implementación del patrón de diseño cumple con todos los cánones habidos y por haber. No hay duda ni cuestionamiento, ActiveRecord es un componente que nos permite ser más productivos ¿para qué entrar al detalle de su funcionamiento? Funciona y listo.
En mi regreso a ASP.NET estuve a punto de retomar la complejidad de implementar patrones, armar bosques de clases y aplicar todos los principios de arquitectura existentes; la realidad es que los tiempos comprometidos me están obligando a encontrar alternativas que nos permitan avanzar más rápido y tener elementos visibles, tangibles, que hagan sentido al usuario final del sistema. Se generó en mi un gran conflicto. Siempre peleé por "hacer las cosas bien, más que rápido" y ahora tengo que "hacer las cosas rápido más que bien". Al final, encontré un punto medio. La experiencia con Rails me enseño que no tengo que recrear la complejidad (usar las clases existentes de ActiveRecord en lugar de construir de cero mi implementación del patrón de diseño) sino a usar lo ya existente y confiar en que en su momento lo puedo mejorar (esto último es más "agile oriented").
Tome los componentes ASP.NET que más me latieron y conseguí avanzar un buen tramo en la construcción del sistema sin caer en un "arrastra-controles" ni re-construyendo todo por ser víctima del síndrome "No-Inventado-Aquí". Estoy cierto que de ser estrictamente necesario más adelante puedo cambiar esos componentes así que se redujo parte de mi conflicto interno.
Esta situación también me dejo entrever otra cosa: de manera natural seguimos ciclos (o espirales dirían los dialécticos). En las artes marciales se inicia con el aprendizaje portando un cinturón blanco, signo de ignorancia, conforme se avanza el cinturón se va tornando oscuro hasta llegar al negro representando la "maestría" alcanzada. Al paso del tiempo el cinturón negro se desgasta mostrando la fibras blancas originales. Simple, complejo, simple.
En el contexto del desarrollo nos adentramos con "asistentes" y construimos aplicaciones arrastrando componentes en nuestro ambiente de desarrollo. Luego vamos conociendo nuevas tecnologías que aumentan los beneficios de nuestras aplicaciones a expensas de la erudición necesaria para su uso. Patrones, técnicas, innovación amarrada a la complejidad pero esto tiene que ser así ¿cierto? Entre más fácil para el usuario, más complicado para nosotros.
En ese momento aparece Rails y entiendo el porqué de la migración. Nos olvidamos de las complicaciones. Sabemos que los componentes de Rails son implementación de patrones y conceptos que veneramos y con eso nos basta. No los ponemos en tela de juicio ni criticamos, simplemente los usamos.
Así me paso con ASP.NET, ya no cuestiono ni critico los componentes que ofrece. Aqui y ahora me hace sentido. Sé que de requerirse puedo incluir toda la complejidad que se requiera pero de momento solo necesito una cosa: que funcione y lo estoy consiguiendo.
Finito.
jueves, junio 28, 2007
Comunidad .NET Edición Junio
Ayer se llevó a cabo la reunión mensual de la Comunidad .NET de la Cd. de México en el lugar acostumbrado. Excelente asistencia a pesar de el partido México vs Brasil.
Arrancó Raúl Guerrero con una introducción a Windows Communication Foundation, uno de los nuevos API's de .NET 3.0. El concepto detrás de WCF es realmente interesante. La unificación de tecnologías de integración bajo una misma API es para mi apreciación un mega-hit. Como es costumbre de Raúl llevó la presentación con una buena porción de código.
A continuación estuvo Juan José Karam que entró al detalle con .NET Remoting. Es obvio que lo suyo, lo suyo, lo suyo... quién sabe que sea, pero .NET Remoting lo maneja rete-chido.
El siguiente en la lista era Octavio Télis pero cambió su presentación por un agradable rato de intercambio de comentarios sobre tecnologías Microsoft, estrategias y se enriqueció con la participación de Arturo Garrido.
Finalmente nos retiramos de las instalaciones de InterSoftware pero en la salida del WTC nos aventamos otra "platicada/debrayada" sobre los más variados temas, principalmente el rol del arquitecto, project leader, project manager y lo comparamos de una manera extremadamente "light" contra la realidad. Karam estaba harto inspirado, de hecho alguien sugirió grabar un podcast comunitario sobre el tema. Sería estupendo.
Esta ha sido hasta la fecha la mejor reunión. Vamos por más.
Finito.
Arrancó Raúl Guerrero con una introducción a Windows Communication Foundation, uno de los nuevos API's de .NET 3.0. El concepto detrás de WCF es realmente interesante. La unificación de tecnologías de integración bajo una misma API es para mi apreciación un mega-hit. Como es costumbre de Raúl llevó la presentación con una buena porción de código.
A continuación estuvo Juan José Karam que entró al detalle con .NET Remoting. Es obvio que lo suyo, lo suyo, lo suyo... quién sabe que sea, pero .NET Remoting lo maneja rete-chido.
El siguiente en la lista era Octavio Télis pero cambió su presentación por un agradable rato de intercambio de comentarios sobre tecnologías Microsoft, estrategias y se enriqueció con la participación de Arturo Garrido.
Finalmente nos retiramos de las instalaciones de InterSoftware pero en la salida del WTC nos aventamos otra "platicada/debrayada" sobre los más variados temas, principalmente el rol del arquitecto, project leader, project manager y lo comparamos de una manera extremadamente "light" contra la realidad. Karam estaba harto inspirado, de hecho alguien sugirió grabar un podcast comunitario sobre el tema. Sería estupendo.
Esta ha sido hasta la fecha la mejor reunión. Vamos por más.
Finito.
viernes, mayo 25, 2007
Último Ruby on Rails vs. PHP
He aquí el último video de este par de orates. Algo que me llama la atención es que se clavaron con PHP y dejaron de lado Java ¿la razón? La ignoro. ¿Será acaso que los PHP'eros tienen menos elementos para defenderse?
Cada vez que alguien conoce Rails se entusiasma de manera increíble. Es que Rails realmente es increíble. Te deja con una sensación de productividad como si te hubieras metido no sé que cosa. Desarrollas rápido, no importan los cambios, el 90% de las veces los consigues cambiando archivos de configuración, te concentras en otorgar valor en el marco del negocio y no en el de la tecnología.
Sin embargo, casos como Twitter demuestran que no todo es miel sobre hojuelas. Menciono Twitter por que es el caso más conocido y que además uso regularmente :D. Además de la serie de posts del mismo DHH y el equipo Twitter, las extensiones a estos posts (tipo programa de notas faranduleras) en las que ponen a DHH como un ególatra energúmeno sabelotodo que lo único que hace es regañar a los desarrolladores de Twitter.
Sea cual fuere la razón Rails en Twitter fue y es rebasado. Y si miran el modelo, es terriblemente simple. ¿Significa esto que Rails no vale la pena? ¿Qué no tiene el solicitado status de nivel empresarial? Para mí significa que igual que con cualquier tecnología, la solución está de nuestro lado: desarrolladores, arquitectos, hw-junkies y demás. No hubo, no hay ni habrá tecnología que llegué a sustituir al 100% las capacidades humanas. Cuando menos no durante lo que yo viva.
Entonces, no importa que Twitter falle. Agarren Rails y cójanle cariño. Vayan probando hasta donde pueden estirar la liga de la suerte. Estirenla tan fuerte que se rompa y entonces aflojen un poquito. Esa será la medida correcta (¡Gracias Jeff!).
Después de este choro viene la diversión.
Finito.
Cada vez que alguien conoce Rails se entusiasma de manera increíble. Es que Rails realmente es increíble. Te deja con una sensación de productividad como si te hubieras metido no sé que cosa. Desarrollas rápido, no importan los cambios, el 90% de las veces los consigues cambiando archivos de configuración, te concentras en otorgar valor en el marco del negocio y no en el de la tecnología.
Sin embargo, casos como Twitter demuestran que no todo es miel sobre hojuelas. Menciono Twitter por que es el caso más conocido y que además uso regularmente :D. Además de la serie de posts del mismo DHH y el equipo Twitter, las extensiones a estos posts (tipo programa de notas faranduleras) en las que ponen a DHH como un ególatra energúmeno sabelotodo que lo único que hace es regañar a los desarrolladores de Twitter.
Sea cual fuere la razón Rails en Twitter fue y es rebasado. Y si miran el modelo, es terriblemente simple. ¿Significa esto que Rails no vale la pena? ¿Qué no tiene el solicitado status de nivel empresarial? Para mí significa que igual que con cualquier tecnología, la solución está de nuestro lado: desarrolladores, arquitectos, hw-junkies y demás. No hubo, no hay ni habrá tecnología que llegué a sustituir al 100% las capacidades humanas. Cuando menos no durante lo que yo viva.
Entonces, no importa que Twitter falle. Agarren Rails y cójanle cariño. Vayan probando hasta donde pueden estirar la liga de la suerte. Estirenla tan fuerte que se rompa y entonces aflojen un poquito. Esa será la medida correcta (¡Gracias Jeff!).
Después de este choro viene la diversión.
Finito.
jueves, mayo 24, 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, mayo 09, 2007
Entre servicios te veas
En una prueba de integración entre una aplicación .NET y otra desarrollada en Java nos apareció este mensaje:
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
Exito: 0
Código Error: 100
Desc. Error: mx.gob.imss.sigoi.quejaVerbal.exception.ValidaCampoException:
El campo Calidad de la persona que se comunica es requerido.
El campo Nombre de la persona que se comunica es requerido.
El campo Apellido paterno de la persona que se comunica es requerido.
El campo Lada de teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Lada de teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 2 Caracteres
El campo Teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 8 Caracteres
El campo Teléfono celular de la persona que se comunica tiene que ser numérico.
El campo Teléfono celular de la persona que se comunica tiene una longitud no valida, menor a 12 Caracteres
El campo Correo electrónico de la persona que se comunica no tiene un formato adecuado
Se tiene que incluir al menos un medio de contacto valido de la persona que se
comunica: Lada y número de teléfono particular, número de teléfono celular, correo electrónico, o dirección completa
Es necesario capturar el NSS de la persona que se comunica
Es necesario capturar el NSS de la persona que solicita el servicio
El campo Calidad de la persona que solicita el servicio es requerido.
El campo Teléfono celular del usuario que solicita el servicio tiene que ser numérico.
El campo Teléfono celular del usuario que solicita el servicio tiene una longitud no valida, menor a 12 Caracteres
El campo Entidad federativa del usuario que solicita el servicio tiene que ser numérico.
El campo Entidad federativa del usuario que solicita el servicio no es un valor válido de catálogo
El campo Clasificación de la solicitud del planteamiento tiene que ser numérico.
El campo Clasificación de la solicitud del planteamiento no es un valor válido de catálogo
El campo Tema del planteamiento tiene que ser numérico.
El campo Tema del planteamiento no es un valor válido de catálogo
El campo Subtema del planteamiento tiene que ser numérico.
El campo Subtema del planteamiento no es un valor válido de catálogo
El campo Delegación de Adscripción del planteamiento no es un valor válido de catálogo
El campo Unidad Medica de Adscripción del planteamiento tiene que ser numérico.
El campo Unidad Medica de Adscripción del planteamiento no es un valor válido de catálogo
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
SaveResult[] = sfdc.create(sObject[] sObjects);
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
private Error[] errorsField;
private string idField;
private bool successField;
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
private string[] fieldsField;
private string messageField;
private StatusCode statusCodeField;
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
miércoles, abril 04, 2007
Parche para un parche
Ya había dejado pasar bastante tiempo para postear de nuevo, pero hoy me sucedió lo que nunca me había pasado antes: ser víctima de las actualizaciones de Microsoft.
El lunes o la semana pasada actualice religiosamente mi PC de la ofi con el servicio de Microsoft Update que me enjaretó un par de actualizaciones de segurida'.
Pus el chiste es que la instalé, pero como he estado en curso (zzzZZZzzzzZZZ) no había encendido hasta hoy y me apareció el infame error del panel de control de Realtek.
Como por pura casualidad, al leer mis feeds me encontré con uno que se refería a este problema supe de inmediato que hacer de lo contrario ya estaría reinstalando el software de la tarjeta de audio.
En fin, un caso más del parche sobre parche.
En otro orden de ideas, voy a estar de vacaciones a partir de mañana (técnicamente desde el siguiente lunes) asi que si había retrasado mis posts, yo creo que me aventaré una semana más sin postear. Pero, pueden seguir las ideas del Tuzo en Integración a la Mexicana, que está harto interesante. ¡Caliente!
¡Felices Pascuas!
Finito.
El lunes o la semana pasada actualice religiosamente mi PC de la ofi con el servicio de Microsoft Update que me enjaretó un par de actualizaciones de segurida'.
Pus el chiste es que la instalé, pero como he estado en curso (zzzZZZzzzzZZZ) no había encendido hasta hoy y me apareció el infame error del panel de control de Realtek.
Como por pura casualidad, al leer mis feeds me encontré con uno que se refería a este problema supe de inmediato que hacer de lo contrario ya estaría reinstalando el software de la tarjeta de audio.
En fin, un caso más del parche sobre parche.
En otro orden de ideas, voy a estar de vacaciones a partir de mañana (técnicamente desde el siguiente lunes) asi que si había retrasado mis posts, yo creo que me aventaré una semana más sin postear. Pero, pueden seguir las ideas del Tuzo en Integración a la Mexicana, que está harto interesante. ¡Caliente!
¡Felices Pascuas!
Finito.
jueves, marzo 22, 2007
¡Arrancando!
Por fin apareció el primer post en Integración a la Mexicana. El valiente fue el Tuzo que se animó a publicar su primera nota. Espero que ya en estos días también Gustavo se anime a platicarnos su visión de todos esto que estamos haciendo en el trabajo.
Finito.
Finito.
miércoles, diciembre 20, 2006
Fin de Temporada
Ayer se llevó a cabo la última reunión de la Comunidad .NET de la Cd. de México. Atendiendo a la convocatoria y por lo significativo de la reunión asistí con mucho gusto. Me parece muy importante resaltar y agradecer el trabajo que han venido haciendo Héctor Obregón, Octavio Télis, Raúl Guerrero y varios más que tomaron como suyo el compromiso de mantener viva la comunidad. No puedo decir más que ¡gracias!
Vi varias caras nuevas, espero que les interese participar en las siguientes reuniones y que se sumen a este espacio de colaboración. Lo importante es que la comunidad crezca y se vaya alimentando con otros puntos de vista, otras necesidades y nuevas ideas que compartir.
Raúl anda clavadísimo en el tema de Serialización y ayer dió una excelente presentación del tema. Yo anduve medio oyendo ya que me preguntó que si podía aventarme la presentación de Mono que compartí la vez anterior en petit comite. Con todo gusto le dije que sí y me pasé repasando la presentación durante su exposición.
A continuación estuvo Octavio Télis platicándonos acerca de los delegados. Algo que me llama la atención de Octavio es su casi enciclopédico conocimiento de .NET.
Finalmente, fue mi oportunidad de pararme al frente y hablar de Mono. Me fuí más o menos rápido ya que los conceptos son idénticos a pesar que los conocemos con distintos nombres (CLI vs. CLR, MSIL vs. CIL, etc) y la presentación simultánea de ejemplos .NET y Mono creo que siempre es de interés para la audiencia (hasta la fecha no se han quejado). A los lectores del post anterior no les caera de extraño cuando mencione que pasó al hacer el cambio a Ubuntu para hacer las demos sobre Linux. Simplemente no funcionaron :@ Resulta que no instalé todos los paquetes necesarios y puras fallas. Simplemente no arrancaron.
Raúl, como el tipazo que es siempre, me dijo que no me estresara, que es normal que pase en medio de cualquier presentación. Alguien que también me brindo su apoyo fue Akin0, que llegó casi desde el inicio de la reunión. Con el gusto de dar a conocer Mono y estas muestras de solidaridad ¿qué más puedo pedir? :D
Un punto interesante fue la pregunta de uno de los asistentes de primera vez (creo que de ¿tacsa? o algo así...) fue de como hacer que dos aplicaciones se comunicaran entre sí. Esto fue como una chispa que se anidó en mi cabeza y en algún momento de la madrugada y después de la charla que nos reventamos de regreso a casa Akin0 y yo dió como resultado la idea de SOA a la Mexicana.
Si, si, si. Ya se que no van a faltar las incontables comparaciones con el famosísimo podcast de Carlos Madrigal Proyectos a la Mexicana, pero buscaremos que tenga su propio sabor. El punto es dar a conocer como hemos ido entendiendo los conceptos de integración, SOA, ESB y demás con las experiencias en el trabajo durante los últimos dos años. Hablo en plural (hemos) por que para realizar esta idea voy a tener la ayuda de dos excelentes amigos y compañeros de trabajo: Gustavo de la Cruz Tovar y Javier "El Tuzo" Cortes López.
Ya vendrán más detalles de SOA a la Mexicana. No se desconecten.
Finito.
Vi varias caras nuevas, espero que les interese participar en las siguientes reuniones y que se sumen a este espacio de colaboración. Lo importante es que la comunidad crezca y se vaya alimentando con otros puntos de vista, otras necesidades y nuevas ideas que compartir.
Raúl anda clavadísimo en el tema de Serialización y ayer dió una excelente presentación del tema. Yo anduve medio oyendo ya que me preguntó que si podía aventarme la presentación de Mono que compartí la vez anterior en petit comite. Con todo gusto le dije que sí y me pasé repasando la presentación durante su exposición.
A continuación estuvo Octavio Télis platicándonos acerca de los delegados. Algo que me llama la atención de Octavio es su casi enciclopédico conocimiento de .NET.
Finalmente, fue mi oportunidad de pararme al frente y hablar de Mono. Me fuí más o menos rápido ya que los conceptos son idénticos a pesar que los conocemos con distintos nombres (CLI vs. CLR, MSIL vs. CIL, etc) y la presentación simultánea de ejemplos .NET y Mono creo que siempre es de interés para la audiencia (hasta la fecha no se han quejado). A los lectores del post anterior no les caera de extraño cuando mencione que pasó al hacer el cambio a Ubuntu para hacer las demos sobre Linux. Simplemente no funcionaron :@ Resulta que no instalé todos los paquetes necesarios y puras fallas. Simplemente no arrancaron.
Raúl, como el tipazo que es siempre, me dijo que no me estresara, que es normal que pase en medio de cualquier presentación. Alguien que también me brindo su apoyo fue Akin0, que llegó casi desde el inicio de la reunión. Con el gusto de dar a conocer Mono y estas muestras de solidaridad ¿qué más puedo pedir? :D
Un punto interesante fue la pregunta de uno de los asistentes de primera vez (creo que de ¿tacsa? o algo así...) fue de como hacer que dos aplicaciones se comunicaran entre sí. Esto fue como una chispa que se anidó en mi cabeza y en algún momento de la madrugada y después de la charla que nos reventamos de regreso a casa Akin0 y yo dió como resultado la idea de SOA a la Mexicana.
Si, si, si. Ya se que no van a faltar las incontables comparaciones con el famosísimo podcast de Carlos Madrigal Proyectos a la Mexicana, pero buscaremos que tenga su propio sabor. El punto es dar a conocer como hemos ido entendiendo los conceptos de integración, SOA, ESB y demás con las experiencias en el trabajo durante los últimos dos años. Hablo en plural (hemos) por que para realizar esta idea voy a tener la ayuda de dos excelentes amigos y compañeros de trabajo: Gustavo de la Cruz Tovar y Javier "El Tuzo" Cortes López.
Ya vendrán más detalles de SOA a la Mexicana. No se desconecten.
Finito.
Suscribirse a:
Entradas (Atom)