Gracias al blog de Marcos Cobeña me encontré esta interesante aplicación: Gliffy.
Ahora resulta que podemos hacer diagramas tipo Visio o Dia en nuestro navegador. ¡Excelente! Ultimamente me había inclinado por aplicaciones de escritorio y consideraba las aplicaciones web para puro entreteniento o cosas superficiales, pero al irme haciendo cliente de las aplicaciones y servicios Google me voy despegando del escritorio.
Manejo proyectos con Google Code. Comparto documentos con Google Docs. Manejo mis listas de acciones con Google Notebook. Leo mis feeds con Google Reader. Mi correo electrónico es GMail. Y ahora hago mapas mentales con bubbl.us y diagramas con Gliffy.
¿Cuál es la ventaja? En primer lugar la ubicación transparente. No más memorias flash o discos duros externos. En casi cualquier computadora puedo trabajar. A cualquier hora.
¿Desventajas? Depender de una conexión a internet. O sufrir si es una conexión lenta. El riesgo siempre latente de no tener la ultimisisisisima versión en la mano y obvio, de que alguien más o algo más se la pase parseando o scanneando todos mis pensamientos vertidos.
Hasta ahora han sido más ventajas pero no deja de sorprenderme. Bien dice Thomas Friedman en su libro "La tierra es plana": internet es una de las aplanadoras.
Finito.
Anotaciones de diversos temas relacionados con código abierto, metodologías de desarrollo y programación con Ruby on Rails
miércoles, julio 18, 2007
martes, julio 10, 2007
bubbl.us - free web application for brainstorming online
bubbl.us - free web application for brainstorming online
Ya había encontrado en un post noticias sobre sitios web que ofrecen el servicio de mapas mentales. No los había tomado mucho en cuenta hasta que empecé a usar con más frecuencia Google Docs y su capacidad de compartir documentos. Sin embargo Google Docs solo soporta documentos tradicionales: hoja de cálculo y texto :(
En una rápida búsqueda en San Google encontré Mindomo, que era el sitio acerca del que leí y encontré también este otro bubbl.us. Hice el trámite para registrarme en los dos y simple y sencillamente bubbl.us me encantó. Muy a la Library Thing lo único que tienes que hacer es dar tu correo, nombre de usuario y contraseña y voilà! ¡Estás inscrito y listo para usar el servicio! Y es así, en cuanto di Submit apareció el canvas y empecé a dibujar mi mapa mental.
Mindomo por otra parte, te envía un correo de confirmación y en lo que escribo este post sigue cargando su "canvas".
Obvia cual fue mi decisión ¿cierto?
Finito.
Ya había encontrado en un post noticias sobre sitios web que ofrecen el servicio de mapas mentales. No los había tomado mucho en cuenta hasta que empecé a usar con más frecuencia Google Docs y su capacidad de compartir documentos. Sin embargo Google Docs solo soporta documentos tradicionales: hoja de cálculo y texto :(
En una rápida búsqueda en San Google encontré Mindomo, que era el sitio acerca del que leí y encontré también este otro bubbl.us. Hice el trámite para registrarme en los dos y simple y sencillamente bubbl.us me encantó. Muy a la Library Thing lo único que tienes que hacer es dar tu correo, nombre de usuario y contraseña y voilà! ¡Estás inscrito y listo para usar el servicio! Y es así, en cuanto di Submit apareció el canvas y empecé a dibujar mi mapa mental.
Mindomo por otra parte, te envía un correo de confirmación y en lo que escribo este post sigue cargando su "canvas".
Obvia cual fue mi decisión ¿cierto?
Finito.
miércoles, julio 04, 2007
Scripteando con Ruby
Hoy tuve que procesar un archivo de direcciones ip para contabilizar el número de conexiones desde cada dirección. Cosa simple ¿no?
Seguramente en las herramientas de todos los días (shell) lo hubiera conseguido en algunos minutos. Habrá quien lo resuelva en unas cuantas líneas de Perl, tal vez Python o whatever.
Sin embargo tuve la linda ocurrencia de hacerlo con Ruby. ¡¿Ruby?! ¿No solamente es para hacer aplicaciones web y frameworks? Pues no, creo que no.
Por alguna referencia encontré Everyday scripting with Ruby. No he comprado el libro pero el título me motivó para hacer esta prueba. ¿Puede ser Ruby un lenguaje que compita contra Perl? Muchos de los scripts de administración se construyen religiosamente con Perl o en mi caso mayormente con shell. Pero quisé probar Ruby en algo que no fuera el hype de Rails.
Realmente el problema es sencillito. Pero la experiencia es harto interesante. De inicio conseguir ayuda.
Si bien existen pruebas unitarias, es un punto que lo veo más asociado a desarrollo de aplicaciones. En este momento no veo que tanta utilidad pudieran tener para los scripts de administración.
Fue padre. Si, lo acepto. Me tardé más tiempo de lo que requiere la tarea pero valió la pena. Voy a buscar la manera de hacerlo más seguido. De hecho, voy a solicitar que instalen Ruby en los Solaris. A ver si no se me paniquean. :D
Finito.
Seguramente en las herramientas de todos los días (shell) lo hubiera conseguido en algunos minutos. Habrá quien lo resuelva en unas cuantas líneas de Perl, tal vez Python o whatever.
Sin embargo tuve la linda ocurrencia de hacerlo con Ruby. ¡¿Ruby?! ¿No solamente es para hacer aplicaciones web y frameworks? Pues no, creo que no.
Por alguna referencia encontré Everyday scripting with Ruby. No he comprado el libro pero el título me motivó para hacer esta prueba. ¿Puede ser Ruby un lenguaje que compita contra Perl? Muchos de los scripts de administración se construyen religiosamente con Perl o en mi caso mayormente con shell. Pero quisé probar Ruby en algo que no fuera el hype de Rails.
Realmente el problema es sencillito. Pero la experiencia es harto interesante. De inicio conseguir ayuda.
ri es terriblemente práctico. Respuestas concisas, precisas y macizas. Luego la experiencia iterativa e interactiva. Vas ejecutando, encontrando errores y corrigiendo (al menos a este nivel de experiencia) lo cual es altamente ¿didáctico?. Aparece un error y corres a ri para confirmar si lo que quisiste hacer se puede. Te das cuenta del error, corriges y va de nuez.Si bien existen pruebas unitarias, es un punto que lo veo más asociado a desarrollo de aplicaciones. En este momento no veo que tanta utilidad pudieran tener para los scripts de administración.
Fue padre. Si, lo acepto. Me tardé más tiempo de lo que requiere la tarea pero valió la pena. Voy a buscar la manera de hacerlo más seguido. De hecho, voy a solicitar que instalen Ruby en los Solaris. A ver si no se me paniquean. :D
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.
Etiquetas:
architecture,
community,
development,
donet,
fun,
ideas,
wcf
martes, junio 26, 2007
PartnerApi Library: Por fin ve la luz
Hace algunos años fui contratado para integrar un CRM y Salesforce (se llamaba así en ese entonces). Para realizar la integración usé C# y el Enterprise API de Salesforce para llevar los datos del CRM al repositorio en línea de Salesforce. Un ejercicio harto interesante. También leí algo acerca de la PartnerApi y de ahí surgió la inquietud de utilizarla.
El objetivo que se me presentó en mi mente fue crear una biblioteca que simplificara el uso de esta PartnerApi y pues después de mmuuuucho tiempo aquí está.
Acabo de publicar el código, licenciado bajo LGPL, para que todo mundo lo revise, lo use y ojalá y contribuya a este proyecto.
Cualquier comentario, sugerencia o pregunta son bienvenidas.
Finito.
El objetivo que se me presentó en mi mente fue crear una biblioteca que simplificara el uso de esta PartnerApi y pues después de mmuuuucho tiempo aquí está.
Acabo de publicar el código, licenciado bajo LGPL, para que todo mundo lo revise, lo use y ojalá y contribuya a este proyecto.
Cualquier comentario, sugerencia o pregunta son bienvenidas.
Finito.
Etiquetas:
api,
community,
development,
dotnet,
freedom,
milestone,
opensource,
webservice
jueves, junio 21, 2007
Solsticio de Verano
Cada año se repite y sin embargo no deja de causarme melancolía.
El 21 de junio es tu cumpleaños. El Solsticio de Verano.
Sigo enamorado del recuerdo, de tiempos añejos, tardes tibias en medio del pasto reseco y yermo.
Quedaste impresa en mi persona. Sin tí no sería el mismo. Aún y cuando tomamos caminos distintos no he conseguido dejar de extrañarte en mis momentos de soledad, confusión, esperanza y desesperanza. Te convertiste en una tabla de salvación de la que me sujeté más de una vez en medio de una madrugada de soledad e incertidumbre.
Jamás me atreví a buscarte. Siempre he tenido miedo de enfrentar el presente contra todos mis sueños inconclusos. Siempre he deseado que seas féliz, féliz, féliz. Que construyas y vivas tus sueños. Que las dificultades las dejes atrás. Que vivas cada día con la satisfacción de vivir incluso las cosas cotidianas.
Féliz cumpleaños Ara.
Finito.
El 21 de junio es tu cumpleaños. El Solsticio de Verano.
Sigo enamorado del recuerdo, de tiempos añejos, tardes tibias en medio del pasto reseco y yermo.
Quedaste impresa en mi persona. Sin tí no sería el mismo. Aún y cuando tomamos caminos distintos no he conseguido dejar de extrañarte en mis momentos de soledad, confusión, esperanza y desesperanza. Te convertiste en una tabla de salvación de la que me sujeté más de una vez en medio de una madrugada de soledad e incertidumbre.
Jamás me atreví a buscarte. Siempre he tenido miedo de enfrentar el presente contra todos mis sueños inconclusos. Siempre he deseado que seas féliz, féliz, féliz. Que construyas y vivas tus sueños. Que las dificultades las dejes atrás. Que vivas cada día con la satisfacción de vivir incluso las cosas cotidianas.
Féliz cumpleaños Ara.
Finito.
Próximas mudanzas
Y sigue la búsqueda. Me ha entrado la curiosidá de instalar Gentoo. Ja. Hay va de nuevo el ChilliCoder.
De hecho hoy empecé con la PC de la ofi. Digo, echando a perder se aprende. Es una máquina con arquitectura AMD64/EMT64, bastante interesante el caso. El ejercicio anterior de instalar Gentoo lo hice en una máquina virtual y solo llegué a conseguir un mugroso prompt. En esta ocasión tengo que llegar más lejos. No puede faltar en mi escritorio (de inicio un escritorio gráfico) reproductores de video y audio, un navegador que soporte flash y applets java, editores de audio (ya casi, ya casi sale el primer podcast), herramientas de captura de video (ya casi, ya casi sale el primer screencast), herramientas de desarrollo y demás chunches que se me ocurran.
Como estuve colgado de la pichurrienta red para descargar el stage3 (115MB) y la lap se quedó en casa, empecé a navegar con una PowerMac G4 que me emprestaron dizque pa'compilar Mono :O. Lenta la máquina por que no es de las más recientes. El Safari: insoportable. Simplemente no me pude conectar a leer mi correo en GMail (santo sr google). Tiene Netscape pero fue peor. En uno de esos arrebatos de histeria, me acordé del CD que estaba en el cajón, domidito. Ubuntu 6.06 LTS para Mac. :O
El primer pex fue conseguir insertar el CD en el drive. Control + Opción + O + F para abrir una sesión de Open Firmware :S. Reiniciar, presionar C para que arranque del CD y zzz ZZZ zzz ... esperar. Después de un ratín un escritorio hecho y derecho. FF 1.5. No problemas. GMail rulz.
Me encantó la experiencia de no mismatch impedance al usar Ubuntu en la Mac. Simple. Fácil. Lento :P. Pero me sigue el sabor en la boca de lo maravilloso que es usar "lo mismo" en otra máquina completamente distinta: PowerPC, Mac, etc, etc, etc.
Regresando al Gentoo, lo único que me ha detenido de instalarlo en mi lap es el soporte no nativo de WiFi. "shiale, este w no lee ni el sensacional de luchas" pensarán algunos gurús de Gentoo. Sip, me quedé muy acostumbrado al modo usuario de Ubuntu ¿Y?. Pa'que vean que si leo, me estoy aventando el Handbook. Algo he de aprender. Una vez lista la PC de la ofi, le caigo a mi lap.
Otra cosa que estuve repensando es la planeación de las particiones. En algún sitio encontré la recomendación de crear una partición separada para /home. En este momento me alegró de haber hecho caso. Voy a instalar una distro distinta y no voy a perder nada de mis archivos. También se me vino a la mente el caso de los servidores Solaris que tenemos y en los cuales se llega a saturar / poniendo en riesgo la estabilidad de los equipos. En una instalación de servidor seguramente se tiene que planear con más detalle la distribución de directorios, particiones y a lo mejor hasta de discos: que si /usr en el más rápido, que si /var en donde haya más espacio, que si /home donde sea...
Pues, sigo con mudanzas. Proyectos por desarrollar y sueños por perseguir.
Finito.
De hecho hoy empecé con la PC de la ofi. Digo, echando a perder se aprende. Es una máquina con arquitectura AMD64/EMT64, bastante interesante el caso. El ejercicio anterior de instalar Gentoo lo hice en una máquina virtual y solo llegué a conseguir un mugroso prompt. En esta ocasión tengo que llegar más lejos. No puede faltar en mi escritorio (de inicio un escritorio gráfico) reproductores de video y audio, un navegador que soporte flash y applets java, editores de audio (ya casi, ya casi sale el primer podcast), herramientas de captura de video (ya casi, ya casi sale el primer screencast), herramientas de desarrollo y demás chunches que se me ocurran.
Como estuve colgado de la pichurrienta red para descargar el stage3 (115MB) y la lap se quedó en casa, empecé a navegar con una PowerMac G4 que me emprestaron dizque pa'compilar Mono :O. Lenta la máquina por que no es de las más recientes. El Safari: insoportable. Simplemente no me pude conectar a leer mi correo en GMail (santo sr google). Tiene Netscape pero fue peor. En uno de esos arrebatos de histeria, me acordé del CD que estaba en el cajón, domidito. Ubuntu 6.06 LTS para Mac. :O
El primer pex fue conseguir insertar el CD en el drive. Control + Opción + O + F para abrir una sesión de Open Firmware :S. Reiniciar, presionar C para que arranque del CD y zzz ZZZ zzz ... esperar. Después de un ratín un escritorio hecho y derecho. FF 1.5. No problemas. GMail rulz.
Me encantó la experiencia de no mismatch impedance al usar Ubuntu en la Mac. Simple. Fácil. Lento :P. Pero me sigue el sabor en la boca de lo maravilloso que es usar "lo mismo" en otra máquina completamente distinta: PowerPC, Mac, etc, etc, etc.
Regresando al Gentoo, lo único que me ha detenido de instalarlo en mi lap es el soporte no nativo de WiFi. "shiale, este w no lee ni el sensacional de luchas" pensarán algunos gurús de Gentoo. Sip, me quedé muy acostumbrado al modo usuario de Ubuntu ¿Y?. Pa'que vean que si leo, me estoy aventando el Handbook. Algo he de aprender. Una vez lista la PC de la ofi, le caigo a mi lap.
Otra cosa que estuve repensando es la planeación de las particiones. En algún sitio encontré la recomendación de crear una partición separada para /home. En este momento me alegró de haber hecho caso. Voy a instalar una distro distinta y no voy a perder nada de mis archivos. También se me vino a la mente el caso de los servidores Solaris que tenemos y en los cuales se llega a saturar / poniendo en riesgo la estabilidad de los equipos. En una instalación de servidor seguramente se tiene que planear con más detalle la distribución de directorios, particiones y a lo mejor hasta de discos: que si /usr en el más rápido, que si /var en donde haya más espacio, que si /home donde sea...
Pues, sigo con mudanzas. Proyectos por desarrollar y sueños por perseguir.
Finito.
Etiquetas:
development,
fun,
ideas,
linux,
opensource,
opinion,
personal
domingo, junio 10, 2007
Otras formas de innovación
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.
¿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.
Etiquetas:
community,
freedom,
ideas,
opensource,
opinion
viernes, junio 08, 2007
Pruebas tontas...
Después de verlo en el blog de GaRaGeD me animé a tomarlo y estos son los resultados.
Traditionally, online tests would ask certain questions about your musical tastes or clothing for a stereotype, your experiences for a purity test, or deep questions for a personality test.We're turning that upside down - all the questions affect all the results, and we've got some innovative results too! Enjoy :-)
TAKE THE TEST
brought to you by thatsurveysite
La parte en la que no estoy de acuerdo es la que dice: more concerned about others than concerned about self, me considero totalmente egoísta.
De cualquier manera, los resultados son ... ¿curiosos?
Finito.
The Everything Test
There are many different types of tests on the internet today. Personality tests, purity tests, stereotype tests, political tests. But now, there is one test to rule them all.Traditionally, online tests would ask certain questions about your musical tastes or clothing for a stereotype, your experiences for a purity test, or deep questions for a personality test.We're turning that upside down - all the questions affect all the results, and we've got some innovative results too! Enjoy :-)
|
|
| |||||||||||||||||
| Politics Your political views would best be described as Socialist, whom you agree with around 50% of the time. | Socioeconomic Your attitude toward life best associates you with . You make more than 78% of those who have taken this test, and 19% less than the U.S. average. |
| If your life was a movie, it would be rated PG-13. By the way, your hottness rank is 40%, hotter than 5% of other test takers. |
TAKE THE TEST
brought to you by thatsurveysite
La parte en la que no estoy de acuerdo es la que dice: more concerned about others than concerned about self, me considero totalmente egoísta.
De cualquier manera, los resultados son ... ¿curiosos?
Finito.
martes, junio 05, 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.
Etiquetas:
community,
development,
freedom,
fun,
linux,
milestone,
mono,
opensource,
personal
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.
Etiquetas:
architecture,
development,
fun,
ideas,
java,
opinion,
rails,
video
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.
Etiquetas:
architecture,
development,
interoper,
opinion,
soa,
webservice
lunes, mayo 21, 2007
Oye Karacas
Hagamos un trato
¿Aceptas el trato?
Cuando sientas tu herida sangrar
cuando sientas tu voz sollozar
cuenta conmigo.
(de una canción de Carlos Puebla)
cuando sientas tu voz sollozar
cuenta conmigo.
(de una canción de Carlos Puebla)
Compañera,
usted sabe
que puede contar conmigo,
no hasta dos ni hasta diez
sino contar conmigo.
Si algunas veces
advierte
que la miro a los ojos,
y una veta de amor
reconoce en los míos,
no alerte sus fusiles
ni piense que deliro;
a pesar de la veta,
o tal vez porque existe,
usted puede contar
conmigo.
Si otras veces
me encuentra
huraño sin motivo,
no piense que es flojera
igual puede contar conmigo.
Pero hagamos un trato:
yo quisiera contar con usted,
es tan lindo
saber que usted existe,
uno se siente vivo;
y cuando digo esto
quiero decir contar
aunque sea hasta dos,
aunque sea hasta cinco.
No ya para que acuda
presurosa en mi auxilio,
sino para saber
a ciencia cierta
que usted sabe que puede
contar conmigo.
usted sabe
que puede contar conmigo,
no hasta dos ni hasta diez
sino contar conmigo.
Si algunas veces
advierte
que la miro a los ojos,
y una veta de amor
reconoce en los míos,
no alerte sus fusiles
ni piense que deliro;
a pesar de la veta,
o tal vez porque existe,
usted puede contar
conmigo.
Si otras veces
me encuentra
huraño sin motivo,
no piense que es flojera
igual puede contar conmigo.
Pero hagamos un trato:
yo quisiera contar con usted,
es tan lindo
saber que usted existe,
uno se siente vivo;
y cuando digo esto
quiero decir contar
aunque sea hasta dos,
aunque sea hasta cinco.
No ya para que acuda
presurosa en mi auxilio,
sino para saber
a ciencia cierta
que usted sabe que puede
contar conmigo.
Mario Benedetti
¿Aceptas el trato?
domingo, mayo 20, 2007
Ruby on Rails vs. PHP
No dejan de entretenerme. Lástima que hasta el siguiente lunes aparece el nuevo episodio.
Finito.
Finito.
Etiquetas:
development,
fun,
rails,
ruby,
video
viernes, mayo 18, 2007
Scott Hanselman's Computer Zen - Twittering my Diabetes
Scott Hanselman es un gran desarrollador, conferencista y escritor de tecnologias .NET, en particular ASP.NET y recientemente Windows CardSpace. Aparte de su conocido blog publica semanalmente un podcast del que habla de varios temas incluído el Open Source.
Lo empecé a leer por el aspecto de tecnología y después por sus experiencias como padre. Hubo un momento en que leí sobre su condición de diabético Tipo I. Entonces me quedé extremadamente sorprendido. Muchas personas en su condición han destruido su vida, tengo un familiar cercano que así lo hizo. Sin embargo Scott es un lider en muchos aspectos y es un modelo de padre y esposo a seguir.
Me motiva leerlo y ver la lucha en la que se ha embarcado contra la diabetes. En esta ocasión aprovecha el fenomeno twitter para compartir sus experiencias como diabético. Lo estaremos siguiendo.
Finito.
Lo empecé a leer por el aspecto de tecnología y después por sus experiencias como padre. Hubo un momento en que leí sobre su condición de diabético Tipo I. Entonces me quedé extremadamente sorprendido. Muchas personas en su condición han destruido su vida, tengo un familiar cercano que así lo hizo. Sin embargo Scott es un lider en muchos aspectos y es un modelo de padre y esposo a seguir.
Me motiva leerlo y ver la lucha en la que se ha embarcado contra la diabetes. En esta ocasión aprovecha el fenomeno twitter para compartir sus experiencias como diabético. Lo estaremos siguiendo.
Finito.
martes, mayo 15, 2007
Ruby vs. PHP: Sigue la mata dando
De la misma serie de videos promocionales de Ruby. Just watch it.
Finito.
Finito.
Etiquetas:
development,
fun,
rails,
ruby,
video
Habemus Mono
Se acaba de anunciar la liberación de la nueva versión 1.2.4 de Mono.
Entre las novedades más notables encontramos:
Finito.
Entre las novedades más notables encontramos:
- Más de 1,000 métodos agregados y/o actualizados
- Soporte completo de ASP.NET 2.0 (bueno... casi... los Web Parts siguen pendientes pero ¿a quién le importa?)
- Mejoras en el desempeño de ASP.NET
- Inicios de la implementación de C# 3.0
- Mono en Solaris/AMD64
- Y varios items más
Finito.
Etiquetas:
community,
development,
milestone,
mono,
opensource
lunes, mayo 14, 2007
Ruby vs. Java Parte II
Al mismo estilo de los comerciales de Apple, Mac vs PC, estos tipos se han aventado un videito bastante chulo.
Finito.
Finito.
De nuevo con lo mismo: Patentes
Ayer apareció en varios medios la noticia de que Microsoft finalmente señalaba las violaciones a patentes en las que caen varios proyectos Open Source y Free Software.
El primer punto que me viene a la cabeza es la posición de desventaja que está empezando a mostrar Microsoft. A mi parecer, no es más que el resultado de no encontrar maneras de contrarestar la pérdida de posición que está sufriendo. Anteriormente comenté que los movimientos que está haciendo para entrar en otros mercados, más que una diversificación, demuestran que ya no es posible sustentar el modelo que los vino a hacer millonarios: el software propietario. Finalmente son una empresa y siendo pública tienen que otorgar dividendos. Ya no tienen mucho de donde sacarlos.
La siguiente idea es la válidez de las patentes. ¿Realmente sigue siendo válido este modelo? Cuando vemos que grandes y pequeñas empresas hacen valer su propiedad sobre las ideas, por más abstracta, sencilla y simple me pregunto: ¿Dónde va terminar esto? ¿Ya nadie va ser capaz de idear algo sin violar una patente? Existen casos donde podrá cuestionarse menos el modelo, la industria farmacéutica por ejemplo. Si no tienen el aliciente de explotar durante varios años una patente ¿qué los motivaría a inventar nuevos medicamentos? Pero en la industria del software ¿Por qué es válido patentar el algoritmo que hace que una sección de la pantalla parpadeé? ¿No es algo de total y simple sentido común?. La idea de un conjunto de componentes para generar páginas web ¿no es demasiado abstracta o genérica como para reclamarla como propia? No desconozco el derecho de la autoría, reclamo cancelar el derecho de la exclusividad.
Definitivamente urge una revisión profunda y real de este modelo.
Finito.
El primer punto que me viene a la cabeza es la posición de desventaja que está empezando a mostrar Microsoft. A mi parecer, no es más que el resultado de no encontrar maneras de contrarestar la pérdida de posición que está sufriendo. Anteriormente comenté que los movimientos que está haciendo para entrar en otros mercados, más que una diversificación, demuestran que ya no es posible sustentar el modelo que los vino a hacer millonarios: el software propietario. Finalmente son una empresa y siendo pública tienen que otorgar dividendos. Ya no tienen mucho de donde sacarlos.
La siguiente idea es la válidez de las patentes. ¿Realmente sigue siendo válido este modelo? Cuando vemos que grandes y pequeñas empresas hacen valer su propiedad sobre las ideas, por más abstracta, sencilla y simple me pregunto: ¿Dónde va terminar esto? ¿Ya nadie va ser capaz de idear algo sin violar una patente? Existen casos donde podrá cuestionarse menos el modelo, la industria farmacéutica por ejemplo. Si no tienen el aliciente de explotar durante varios años una patente ¿qué los motivaría a inventar nuevos medicamentos? Pero en la industria del software ¿Por qué es válido patentar el algoritmo que hace que una sección de la pantalla parpadeé? ¿No es algo de total y simple sentido común?. La idea de un conjunto de componentes para generar páginas web ¿no es demasiado abstracta o genérica como para reclamarla como propia? No desconozco el derecho de la autoría, reclamo cancelar el derecho de la exclusividad.
Definitivamente urge una revisión profunda y real de este modelo.
Finito.
Etiquetas:
development,
freedom,
ideas,
linux,
opensource,
opinion
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.
Etiquetas:
api,
architecture,
development,
dotnet,
interoper,
java,
soa,
webservice
Suscribirse a:
Entradas (Atom)