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 web. Mostrar todas las entradas
Mostrando las entradas con la etiqueta web. Mostrar todas las entradas
domingo, octubre 10, 2010
lunes, noviembre 19, 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.
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.
miércoles, julio 18, 2007
Otra aplicación web
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.
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.
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.
Suscribirse a:
Entradas (Atom)