Entradas etiquetadas como Rails

AngularJS y nuevas posibilidades para las aplicaciones Web

AngularJS

AngularJS Architectural Overview

Recientemente en Arckanto software estoy desarrollando una aplicación Web para automatizar un proceso de negocios operativo de una institución microfinanciera. Al margen de las características funcionales, el desarrollo técnico está basado principalmente en una base de datos MySQL y en el framework de desarrollo Yii, el cual por cierto ha resultado una gratísima sorpresa para mi. Perfectamente podemos imaginar a Yii como el Rails pero para el mundo PHP: Un sólido framework basado en el patrón MVC y la filosofía de “Convention over Configuration”.

Pero en realidad, este post no está dedicado a Yii (quizá en otro post futuro comentaré más de él) sino a otra tecnología: AngularJS. Resulta que para poder desarrollar alguna de las características de la aplicación mencionada, requería muchos elementos de programación del lado del cliente en lenguaje javascript (o sea, programación a ser ejecutada por el Navegador mismo). Aunque antes había hecho algunas pequeñas cosas en javascript, principalmente en jQuery, en realidad no había profundizado mucho en el tema.

Esta vez requería un poco más de “inteligencia” del lado del Browser porque requería calcular totales, subtotales y validaciones relacionadas, antes de “postear” (enviar) la información al servidor y la aplicación Yii. Así que decidí investigar un poco el tema y vi que existen muchos frameworks javascript para desarrollar modernas aplicaciones Web (single-page applications) que requieran mucha interactividad en el Navegador. Algunas de los frameworks más relevantes son Backbone.js, Ember.js, Knockout.js y otros. Pero el que más me llamó la atención fue AngularJS (la razón bastante técnica para describirla en este post pero en síntesis puedo decir que fue debido a su filosofía de no manipular el DOM desde los controladores sino separarlo completamente usando Directivas: Controlador imperativo y View Declarativo).

AngularJS es un framework javascript desarrollado e impulsado por Google (así que imaginarán el respaldo que tiene) orientado a lo que se llama “Single-Page Applications” que se traduce en Aplicaciones de una sola Página (este tema por sí solo merecería otro post). Llamadas así porque todo el sistema reside en un solo archivo HTML, y desde él se llaman a todos los controladores javascript que le dan forma al funcionamiento del sistema. ¿Impresionante, no? Todo el sistema en una sola página. Bueno, aunque así se llaman y efectivamente una página puede contener todo el sistema, la realidad es que uno puede tener varias páginas Web (especie de módulos) que juntas forman un amplio sistema Web. Dicho de otro modo, no es necesario que estén en una sola página pero esa es la intención.

Eso da una interactividad enorme a la aplicación pues mucho de la lógica es ejecutada por el Navegador mismo. AngularJS quedó como “anillo al dedo” para lo que yo requería. Pero lo más importante para mi fue que en el proceso entendí (o más bien, estoy entendiendo) todo lo que significa desarrollar en AngularJS (o con un framework javascript; javascript puro en el caso de AngularJS) y cómo puede interrelacionarse este tipo de aplicaciones con aplicaciones del lado del servidor (como Rails o Yii) basadas en una base de datos central.

En mi opinión, todo este movimiento de frameworks javascript, con AngularJS como un ejemplo icónico, vendrá a fortalecer muchísimo el desarrollo de aplicaciones de Nube. Es el complemento ideal de Rails o de Yii, estos siempre necesarios para darle solidez al backend y la persistencia de datos. Pero ahora el desarrollo Web logra emular en interactividad, sino es que superar, los antiguos desarrollos para Desktop. Ergo: Es la tendencia. Por ahí está gran parte del futuro de las aplicaciones Web de Nube, sin duda.

Reflexión final: ¿No será que todo tiende a ser cíclico? De Mainframes a PCs. De PCs a Cliente/Servidor. Y se reinicia el ciclo: De sistemas centrales Web a sistemas distribuidos y comunicados con arquitectura REST (algo así como de nuevo en cliente-servidor). Pero claro, esta vez yo obviamente no apostaría por VisualBasic y MS-SQL-Server como amplia base de difusión tecnológica. Apostaría por AngularJS (en el cliente), más algún framework MVC de servidor (preferiblemente Ruby on Rails), más MySQL y/o MongoDB como Bases de Datos. ¿Qué tal suena? Veremos…!

Mientras, aquí “Hola Mundo” en AngularJS:

, , , ,

4 comentarios

SaaS y ¿cómo “juega” Heroku en el mundo Salesforce?

Recientemente Salesforce ha anunciado que seguirá apoyando sus dos plataformas de desarrollo de aplicaciones para la Nube: Heroku y Force.com. Esto podría parecer extraño dado que ambas plataformas están diseñadas para alojar aplicaciones Web de Nube. Sin embargo las razones que Salesforce aduce me parecen muy lógicas: Force.com es una plataforma de desarrollo de aplicaciones de procesos de negocios. Básicamente los usuarios de estas aplicaciones son el personal mismo de las empresas. Por otro lado, Heroku está orientado a aplicaciones masivas de tipo “público”. Las aplicaciones de Nube en Heroku son más usadas por el público en general (Twitter, Groupon, Shopify, etc.) ya sean clientes o no de una empresa en particular.

La división anterior me parece no sólo natural sino que también nos indica una clasificación de las aplicaciones de Nube. OJO: No estoy diciendo que en Salesforce no se puedan alojar aplicaciones masivas ni que en Heroku no se puedan hospedar aplicaciones de negocio de backoffice. Sin embargo, la clasificación resulta bastante lógica. Me explico.

Heroku tradicionalmente ha venido apoyando el mundo de los Desarrolladores Ruby (y Ruby on Rails) para que desplieguen sus habilidades técnicas en iniciativas empresariales de desarrollo de aplicaciones masivas de alta calidad. Su orientación es más que nada hacerle la vida fácil al desarrollador o empresario de software para crear de manera relativamente sencilla sus aplicaciones y poder desplegarlas en un ambiente de producción optimizado, moderno y seguro. Para ello, da acceso a muy valiosas extensiones o “add-on´s” que añaden mucha funcionalidad a las aplicaciones ahí alojadas.

En cambio Force.com ha venido siendo la plataforma idónea para desarrollar aplicaciones de negocios ligadas al CRM de Salesforce y sus otros productos. Ha servido como una buena vía para extender las capacidades del CRM de Salesforce y crear otras aplicaciones alrededor de él. Inclusive sistemas completos de negocios, estilo ERP, que son tan o más grandes aún que el CRM original de Salesforce.

Mi propuesta personal: desarrollar productos de software (modelo software as a service SaaS, lógicamente) desplegados sobre Heroku y creados en Ruby on Rails pero accediendo a información contenida dentro del CRM de Salesforce. De hecho, ya existen buenas herramientas de integración de información para esta vía y, de acuerdo a los ejecutivos de Salesforce, la integración será cada día mayor (es lógico pues ambas forman parte de la misma empresa global). En síntesis, concibo algo así como Backoffice con Salesforce, Force.com y otras aplicaciones de negocios maduras (Financial Force, por ejemplo), mientras que productos de Frontoffice con Rails sobre Heroku pero integrados con los productos Salesforce mencionados.

Voilá. Y con ello tendremos un completo set de productos de software para la Nube. ¡Hasta pronto!

, , , , , , ,

1 comentario

[Video] Multitenancy con Ruby on Rails

Una de las características esenciales de las aplicaciones para la Nube es su arquitectura de Multitenancy. La arquitectura multitenancy implica una sola instancia de la aplicación y una sola base de datos para múltiples empresas clientes quienes usan la aplicación de negocios de acuerdo a sus necesidades. Para cada empresa cliente es como si la aplicación fuera únicamente para ellos. El concepto de Multitenancy es fácil de entender cuando lo comparamos con lo que no es Multitenancy. Veamos:

1. Una aplicación que desarrollamos y que aunque está lista para funcionar en Web e Internet (o en Intranet), tenemos que instalarla nuevamente cada vez que alguna empresa la requiere. Así, si hacemos 10 instalaciones (aunque sea en el mismo servidor Web físicamente; o sea, en la misma infraestructura) tenemos 10 Bases de Datos y 10 instancias de la aplicación. Si el sistema tenemos que corregirlo o hacer algún upgrade tendríamos que hacerlo 10 veces. So, esa aplicación aunque funciona en Web e Internet NO es Multitenant. Sí; es una aplicación Web pero No es una aplicación de Nube. De hecho este es el típico modelo anterior que se usaba en los servicios de los Application Service Providers (ASP).

2. Una aplicación masiva (muchos usuarios) tales como Facebook o Twitter no se considera Multitenant porque su modelo de separación de datos está basado en el Rol de Acceso de los usuarios que Inician Sesión. Es decir, todos los usuarios ven lo mismo (o casi) basándose en los permisos que le otorga el sistema. Aunque es una base de datos, los usuarios no entran a un espacio donde sus datos están separados de los demás.

3. Siendo así, la característica fundamental de una aplicación Multitenant es que tengamos una sola base de datos para las 10 ó 100 ó las que sean empresas clientes de nuestra aplicación. Un ERP Multitenant (o sea, de Nube) tendrá una única base de datos y una sola instancia de la aplicación. Si debemos corregir un error o hacer un upgrade bastará con que lo hagamos una sola vez y todos las empresas clientes del ERP recibirían el beneficio de manera inmediata. Buenos ejemplos: Salesforce, Zoho, Paymo, entre muchos.

Con esto en mente, vean este excelente video donde Guy Naor, CTO de MorphLabs, explica cómo diseñar una aplicación Ruby on Rails con Arquitectura Multitenancy y, por ende, una aplicación 100% de Nube. Si eres un Rails Developer o Rails Architect y estás por empezar una aplicación Nube Multitenant, entonces este video es imperdible..!

Vodpod videos no longer available.

Fuente: Confreaks 2009

, , , , , ,

Deja un comentario

Desarrollo Ágil y sus posibilidades con Rails

Proceso SCRUM

Fuente: Scrum Alliance

El desarrollo de software para la Web ha venido a apuntalar y terminar por validar diversas metodologías de Ingeniería de Software conocidas como Metodologías de Desarrollo Ágiles. Aunque existan muchas, y con variantes entre sí, de las más conocidas está SCRUM, XP (Extreme Programming) y la de Desarrollo de software Lean (o delgado). Aunque existen muchas, todas ellas están basadas en el Manifiesto de Desarrollo Ágil:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

En general, podemos decir que se intenta provilegiar la construcción iterativa e incremental de los productos de software, tomando mucho en consideración, en cada ciclo, el punto de vista de los usuarios o clientes. Todo esto se basa en la idea, que considero completamente correcta, de que el usuario o el cliente termina por definir los requerimientos del software únicamente después de que ve y “siente y prueba” el software que se está creando, y no antes.

Aunque el cliente previamente puede tener una idea, ya sea extremadamente vaga o bien imaginada, de lo que requiere en su software, es en el momento que ve en la pantalla de la computadora cuando el cliente realmente termina de definir bien lo que requiere. E inclusive podría requerir varios ciclos de mejora antes de que su necesidad haga “click” en su cabeza. Dicho de otro modo, se trata de ir construyendo y clarificando los requerimientos del software durante (y no antes) la construcción del mismo.

Hoy día se intenta ir incluso más allá con técnicas muy innovadoras como el Test Driven Development (TDD – Desarrollo dirigido por las Pruebas) ó el Behaviour Driven Development (BDD – Desarrollo dirigido por el comportamiento del software). A continuación, una brevísima explicación de ambas.

El TDD se basa en el concepto de que el desarrollador debe codificar primero la prueba o pruebas de algún requerimiento específico. Una vez codificada la prueba asegurarse de que la prueba en realidad es fallida y posteriormente realizar la programación para que la prueba pase. Ya que logró pasar la prueba entonces realizar un proceso de afinado del código para “limpiarlo”, optimizarlo y documentarlo. También en muchas ocasiones el developer o equipo de developers debe estar consciente de que antes de codificar la primera prueba de este ciclo primero debe decidir si el sistema tal como está en ese momento es el idóneo para codificar la prueba o si debe restructurarlo para que sea más adecuado para satisfacer el requerimiento que se va a probar/codificar. Algo así:

Técnica TDD = Refactoring (opcional) + Codificación de la primera prueba del requerimiento

Pero lo esencial del TDD es “First code the Test, then code to pass the test” ó “Primero codifica la prueba, luego codifica para pasar la prueba”.

El método BDD incluye TDD pero lo extiende de manera que las pruebas no sólo sean creadas por el Developer sino también por éste y el cliente o usuario final, utilizando para definir el requerimiento (cierto comportamiento específico del software) un lenguaje casi natural. Dicho de otro modo, el cliente en conjunto con el Developer definen (en un lenguaje específico legible para usuarios no técnicos) el comportamiento y tomando este como insumo el developer codifica la prueba y sigue el método TDD. Excelente, ¿eh?

¿Qué tiene que ver todo esto con la computación en la Nube? Bueno pues que el Software-as-a-Service tiene hoy día una matrimonio con las nuevas metodologías Ágiles de desarrollo, y con técnicas como BDD/TDD. La Web, o al menos la buena Web, se está construyendo alrededor de esta Ingeniería de Software. Un proyecto de construcción de un producto para la Nube debe tomar en consideración estos métodos más que los tradicionales métodos de Project Management.

En el caso de Ruby on Rails, el framework no sólo ya cuenta con mecanismos incluidos dentro de la plataforma (por ejemplo, un subsistema de pruebas) que apalancan métodos ágiles y TDD sino que también se han construido herramientas excelentes y que están ganando momentum en el mercado, tales como Cucumber, herramienta programada en Ruby, que automatiza de manera elegante y sencilla el método BDD para proyectos no sólo de Ruby on Rails sino también Java, Python y C#.

¡Bien por Rails y las metodologías ágiles! Si bien es cierto que esto no es exclusivo de Rails, sí es una razón más para seleccionar Rails como framework de desarrollo para la Nube.

, , , , , , , ,

Deja un comentario

Algunas razones de porqué elegiría Rails + Database.com + Heroku para una solución de Nube … Parte 2

En la primera parte de este post, había descrito las razones por las que yo elegiría Ruby on Rails para el desarrollo de un sistema Web. Al final, comentaba que me parecía que la base de datos ideal debería ser una basada en la Nube y que Xeround (MySQL cloud based) podría ser la opción idónea. Sin embargo, existe una fuerte alternativa. Se trata de Database.com, el producto de base de datos de Salesforce que también está orientada a aplicaciones en la nube (tal como lo es Salesforce).

Me parece que, aunque ambos productos son sólidos (Xeround y Database.com) y tienen las características adecuadas, existe una poderosa razón de mercado y de negocios que favorece la opción de Database.com. Este producto es el que Salesforce utiliza para sus aplicaciones CRM basadas en la nube y que utiliza también en su plataforma de desarrollo Force.com, la cual está ganando mucho momentum en los últimos meses.

Dicho de otro modo, una nueva aplicación de negocios que use Database.com estará íntimamente ligada desde el punto de vista técnico con los datos y las aplicaciones nativas de Salesforce (aunque uno podría usar Database.com sin depender de la plataforma Force.com). Y una integración natural con el líder del mercado en aplicaciones de negocios para la nube representa un potencial valor de mercado de una eventual futura aplicación de negocios. Inclusive existe también la posibilidad de alianzas estratégicas futuras no sólo con Salesforce sino con muchos otros proveedores de aplicaciones de negocios del ecosistema de Force.com.

4. Plataforma de desarrollo y deployment Heroku.com. Existen varios, y muy buenos, proveedores de servicios que ofrecen un óptimo deployment de una aplicación Ruby on Rails. Uno de los mejores es Heroku.com. Ofrece un medio ambiente y plataforma sólida para aplicaciones Ruby, una arquitectura Multi-tenancy natural, múltiples Add-on´s que pueden enriquecer y apalancar las aplicaciones desplegadas en Heroku, y una reputación excelente como proveedor de servicios Platform-as-a-Service (PaaS).

Aunque pudieran existir otros proveedores Ruby (Engine Yard, en particular), Heroku recientemente ha adquirido una enorme ventaja de mercado ya que fue comprada en enero del 2011 por Salesforce. Al margen de la ventajosa liquidez financiera que esto trae para Heroku, es también de esperar entonces que Heroku y Force.com vayan siguiendo rutas técnicas paralelas o con una integración mejorada. Dicho de otro modo, Salesforce está también apostando por el ecosistema Ruby on Rails, paso lógico dado que Apex (el lenguaje de programación usado en Force.com) es muy cerrado y no cuenta con una comunidad fuerte de Web developers (como Ruby) salvo por los que ya desarrollan en Force.com.

Conclusión: la arquitectura Ruby on Rails + Database.com + Heroku me parece la ideal para aplicaciones de negocio para la Nube. Su principal desventaja (creo que temporal) es que actualmente la integración RoR-Database.com no es factible con la versión 3 de Rails sino únicamente con una anterior. Ello debido a que el adaptador de la base de datos (ActiveSalesforce) no es compatible con Rails 3. Sin embargo esto deja de tener relevancia ahora que Force.com está apostando también por las APIs basadas en REST por lo que seguramente pronto veremos un adaptador REST (a febrero del 2011, existe incluso ya una versión alfa) en lugar del actual basado en SOAP.

(Nota relevante agregada el 22-mar-2011: Rails 3 & Force.com REST API)

Quizá en otro post comentaré de alternativas también sólidas como arquitectura de base para aplicaciones Nube. Sin embargo, la aquí expuesta es la que yo elegiría en definitiva.

, , , , , , ,

2 comentarios

Algunas razones de porqué elegiría Rails + Database.com + Heroku para una solución de Nube … Parte 1

Hace más o menos un par de meses (finales de diciembre del 2010) me vi inmerso por esos azares del destino en buscar cuál sería la plataforma idónea para desarrollar “from scratch” soluciones de negocio y procesos organizacionales bajo el concepto de computación en la Nube (Cloud Computing). Software-as-a-Service (SaaS) en su definición más pura. Lo más interesante del caso es que yo no tenía ninguna restricción; o sea, no tenía ninguna inversión tecnológica heredada que tuviese que “respetar” o con la que tuviese que interactuar; es decir, ¡el mundo ideal del Arquitecto de Software!

So.. me di a la tarea de investigar un poco el asunto y leer algo de material al respecto. Tenía que considerar muchos factores, no sólo técnicos sino también como estrategia de negocios e inversión futura. Simple y llanamente debía elegir en qué desarrollar un producto que mi empresa pudiese invertir y rentabilizar en el futuro. En este post explico la primera parte de las razones por las que elegí cierta tecnología. En la segunda parte continuaré comentando el razonamiento de mi decisión.

Mi elección:

He aquí algunas de las razones por las que seleccioné la tecnología descrita:

  1. Ruby es un lenguaje de programación orientado a objetos creado en Japón por Yukihiro Matsumoto, “Matz”, a principios de los años 90s; lo suficientemente maduro para demostrar que no es flor de un día pero lo suficientemente “moderno” y poderoso como lenguaje de programación. Es elegante, sencillo de aprender, tiene una comunidad de desarrolladores vibrante y ha sido definido por Marc Benioff, director de Salesforce, como el lenguaje de la Nube. Además, existen implementaciones Java (JRuby) para los developers que aún se sienten cómodos con Java pero quieren acceder a la elegancia de Ruby. Y finalmente, Ruby es también Open Source.
  2. Ruby on Rails (RoR). Es el framework de desarrollo Web que mayormente usa el lenguaje Ruby (aunque existen otros; Sinatra en particular) y es ampliamente conocido y aceptado por la comunidad Ruby. Rails es uno de los primeros frameworks de desarrollo en utilizar el patrón MVC (Model-View-Controller) que prácticamente se ha convertido en un estándar del desarrollo de aplicaciones para la Web. Sólido y maduro.
  3. Base de Datos: En este tema hay mucho por escoger. MySQL es muy bueno, es Open Source y es ampliamente aceptado por la comunidad de Web Developers. Por otro lado, Apache tiene una muy interesante iniciativa de base de datos (document-oriented) llamada CouchDB que también tiene ya proveedores en la Nube: Cloudant.com. Si consideramos que “la Nube” será nuestro pan de cada día, debemos privilegiar la decisión de una base de datos “de Nube”. Es por ello que la versión “Nube” basada en MySQL llamada Xeround sería nuestra primera opción; máxime que Xeround ya tiene un add-on para funcionar en la plataforma de Heroku.

Sin embargo, aquí es donde entra nuestra primera gran consideración en favor del mundo Salesforce, más específicamente, del mundo Force.com que es la plataforma de desarrollo de aplicaciones para la Nube de Salesforce. En la segunda parte de este post abordaré porqué me pareció importante integrarse con Force.com, vía su producto de base de datos Database.com y también terminaremos de justificar nuestra decisión completando el cuadro con la plataforma de desarrollo de Heroku.com.

¡Back soon!

, , , , , , , ,

1 comentario