[Rubies] Ruby on Rails: más sencillo, más rápido, más barato
memoayuda
Ruby es un lenguaje de programación que goza de una creciente popularidad entre los desarolladores de aplicaciones web. Según la consultora Gartner existen alrededor de un millón de programadores de este lenguaje en el mundo y proyecta que para el 2013 serán más de 4 millones.
Fue creado por el japonés Yukihiro "Matz"Matsumoto a inicios de los años 90.
Pedro Visintin es arquitecto de software con veinte años de experiencia y uno de los especialistas más conocidos de Argentina en dicha tecnología. Para él la creciente popularidad del lenguaje y del framework Ruby on Rails se debe a que facilita el desarrollo de aplicaciones pues disimuye la dificultad técnica, lo cual puede repercutir en menores tiempos de salida al mercado (Time to Market) e incluso costos menores, en comparación con otras tecnologías como Java o .Net.
Aunque también reconoce que su rendimiento versus otros como PHP es menor.
Visintin hizo escala en San José de Costa Rica, donde lo entrevistamos, para dar un taller a un grupo de desarrolladores de la empresa Avantica. Provenía de la Railsconf 2008, recientmente realizada en Portland, Estados Unidos e iba en dirección hacia su natal Buenos Aires.
¿Cuales factores considerás que impulsan la creciente popularidad de Ruby?
Lo que lo ha hecho popular es lo fácil y rápido que se puede desarrollar una aplicación web. El código queda muy claro, es entendible por cualquier programador y realmente el Time to Market es mejor que cualquier otro lenguaje.
La mayoría de los lenguajes, sobre todo los compilados fueron hechos pensando en el compilador, pero Ruby está pensado en el programador, en que trabaje cómodo y rápido. El rendimiento de la máquina no es el mejor pero el de desarrollado si, lo que implica menos costosos e incluso menos riesgos porque hay menos código. Ahí está el punto clave.
Ruby on Rails realmente no es un lenguaje si no un framework de desarrollo...
Correcto. Digamos que el principal framework es una implementación de Model View Controller. En Java el equivalente podría ser Struts. En el caso de Ruby, el modelo donde va la lógica del negocio está en el sub framework Active Record, el cual se encarga de hacer la persistencia de los objetos en la base de datos, de manera transparente. Solo le decís dame tal cosa, no hay que escribir sentencias SQL, si realmente usas mal el framework y haces un mal diseño de la aplicación usas sentencias SQL.
El sub framework Action Pack contiene tanto la parte de Controller como la parte de View, todos están compuestos de liberías y clases.
¿Se trata de hacer Drag and Drop?
En realidad no existe el next, next next. El programador tiene que subirse las mangas y escribir desde la consola, aunque Rails te da facilidades como programar un mantenimiento desde una línea de comandos, con Scaffold.
La herramienta IDE que se usa es Net Beans, pero la mayoría de desarrolladores utilizan procesadores de texto, por ejemplo en Mac se utiliza TextMate, hay muchos otros editores en Linux.
Al escribir tan poco código el IDE se hace demasiado complejo para algo que es sencillo.
¿Para qué tipo de desarrollos es ideal?
Para todo lo que es web con contenido dinámico, obviamente. No discriminaría ningún proyecto web, para algunas cosas más complejas quizá haya que usar algún framework asincrónico, para cuando se necesitan cosas desantendidas, por ejemplo en un workflow en el cual se necesita alguna interacción humana, donde el proceso no es online. Ruby está preparado para eso, pero no viene dentro de Rails, pero podes usar ser alguna plataforma adicional.
¿Cuando escojerías PHP y cuando Rubi?
En mi caso si tengo que empezar desde cero no lo voy a pensar y voy a escojer Ruby por la velocidad de desarrollo. Además hay mejores herramientas que permiten formalizar las mejores prácticas, como Behaviour Driven Development (BDD), que es la evolución de Test Driven Development, esta es una buena práctica, porque cuando uno hace un desarrollo primero debe escribir el test para ver que la aplicación agregue valor al negocio.
Los tests en un proyecto grande son muy útiles, imaginate que trabajas en un desarrollo grande y regresas seis meses después, si hacés un cambio podes ver muy fácilmente como eso impactó tu código. Ahorra mucho tiempo y te da seguridad de saber que las cosas funcionan. Por ejemplo en el test de un producto escribís que si no tiene nombre o modelo y lo tratas de guardar en la base de datos, arroja error, pero imaginate que en seis meses cambias el producto, solamente haces el test de nombre y modelo, sabés si la aplicación funciona si se comporta igual en tu test, no tenés que hacer más. Eso también aplica en PHP pero no existe BDD.
No hay duda de que PHP es mucho más rápido que Ruby, por lo que escojería PHP en casos en los cuales el rendimiento es crítico y realmente no haya forma de igualarlo de otras maneras.
El asunto es que si necesitas más rendimiento ponés más hardware y listo. Vos sabes cuanto cuesta el hardware pero no sabés cuanto te cuesta extender el desarrollo. Pues en el desarrollo está el componente humano que es el más complejo.
¿Cual es tu percepción del mercado?
Para mi el tema es que tanto Microsoft como IBM están muy metidos dentro de las universidades y todos los estudiantes salen con el librito bajo el brazo. Rails no se conoce tanto y por eso no tiene tantos adeptos, en las universidades no se enseña Rails. PHP tiene más gente porque tiene más tiempo en la calle pero Rails se está ganado poco a poco su lugar.
¿Que sucede cuando Rails tiene integrarse con otras tecnologías?
Ruby interactua muy bien con otras tecnologías, por ejemplo con las colas de MQ Series, hay librerías para acceder a casi todo. Ahora, integración web, si tenés que consumir un web service lo puedes hacer pues Rails tiene librerías que te pemiten hacerlo, te da esa integración de una manera muy sencilla a través de REST (Representational State Transfer), recomiendo estudiar la tesis de Roy Fielding al respecto. REST está basado en usar todos los verbos del protocolo HTTP, pues normalmente solo se usan el Get y Post pero también existe Put y Delete.
Esa teoría dice que todo lo que tenemos en el sistema son recursos y los cuatro verbos te permiten interactuar con todos esos recursos, por ejemplo para traer datos, crear, borrar, modificar, todo lo podés hacer con los mismos cuatro verbos, eso hace que la comunicación sea mucho más sencilla. Rails utiliza REST y uno puede exponer todos los recursos que de la aplicación. Todos los recursos hablan el mismo idioma. Esto lo están usando grandes sitios como Yahoo e Ebay.
¿De qué manera interactúa Rubi con las aplicaciones híbridas o mashups?
Rails funciona muy bien con eso pues muchos de los mashups ya están pensandos en REST, es muy fácil llegar a ellos porque Rails tiene un Framework que se llama Active Resource, si la otra aplicación expone los recursos en forma REST automáticamente yo puedo tener esos recursos mapeados en mi aplicación, como si estuvieran locales.
No puedo hacer lo mismo como si estuviera en mi sistema, pero puedo hacer un find, un get, un save como si estuviera en mi lado.
Por ejemplo si tenés comments en tu aplicación, hacés active resource.comments, le das la URL de tus comments, hacés comments.new y los comments se grabaron en tu aplicación vía HTTP, solo con tres líneas de código. La única condición es que tu aplicación debe soportar REST.
¿Cual es el uso a nivel corporativo que se le está dando a Ruby
En las corporaciones es un tema difícil. Ruby on Rails está siendo adoptado por empresas tipo Venture Capitals donde se entiende el concepto de riesgo, ellas se animan a hacer una inversión y en seguida están en el mercado con una aplicación funcionando.
Creo que en muchas corporaciones hay directores a los cuales les faltan pelotas y que realmente no se animan a poner a sus empresas en una posición realmente competitiva, usando tecnología innovadora, pues siguen atados a las grandes compañías.
Si tuvieras que vender Ruby On Rails a un manager de una empresa, ¿Cual sería tu argumento?
Básicamente el Time To Market, el cual es mejor que cualquier otra tecnología. También tener a la gente realmente motivada con el trabajo porque es un placer programar en Ruby, es un lenguaje pensado en el programador. Todos los problemas técnicos básicos están resueltos. Por ejemplo en Ruby se pueden restar arrays, sin escribir el código para hacerlo. Uno realmente se puede enfocar en el problema de negocios y no hay que andar escribiendo tonterías con el lenguaje, el programador es muy productivo con Ruby on Rails.
¿Cómo es el proceso de adaptación de un programador que viene de Java, PHP, .Net?
Uno de los retos es que la tecnología se mueve muy rápido y tiene que estar leyendo mucho para que este al día. Java y .Net no se están moviendo tan rápido, incluso PHP.
También el cambio de paradigma hacia una verdadera orientación a objetos es grande. Java es un lenguaje estáticamente tipado y uno termina chocando con los tipos primitivos, la única forma de extender objetos es con herencia. En Ruby tenemos formas en las cuales compartir un objeto y agregarle métodos, no hace falta la herencia, eso hace que se pueda crear objetos más rápido y compartir los métodos.
Al inicio los programadores tienden a escribir más código que el que realmente se necesita, hay vicios tales como llamar funciones cuando realmente se necesitan métodos o hacer selects en la base de datos, pero eso lo hace Active Record.
¿Cuales son los tendencias del framework, hacia donde se está dirigiendo?
Está tomando auge MERB, que un framework hecho en Ruby, para ciertas circunstancias es mejor que Rails, sobre todo cuando se necesita más performance, aunque hay que escribir más código
Rails tiene otro framework que se llama Data Mapper, que digamos es competencia de Active Record y tiene ciertas ventajas, permite acceder a sistemas legados y compartir datos con diferentes bases de datos, de forma bastante natural. La versión 0.9 es muy prometedora, pero no se puede usar con Rails. La combinación de MERB y Data Mapper es una alternativa a Rails dentro de Ruby.
¿Cual es el aporte de Ruby en la academia?
Uno tiene que pasar tanto por lenguajes dinámicamente tipados como estáticamente tipados, por ejemplo conocer como se programa en Ruby, Smaltalk o Java, luego el programador debe decidir en que mundo se desarrolla.
El programador tiene que tener el conocimiento de programar a diferentes niveles, saber escojer los lenguajes y hacer los diseños correctos para cada caso de estudio.