Archive for 11 abril 2017

¿Cómo diferenciar un buen desarrollador de software en Ruby del resto?

abril 11, 2017

Rails != Ruby

La primer diferencia entre un buen desarrollador de software en Ruby de uno malo no tan bueno es que el primero sabe que una cosa es Ruby y otra cosa es Rails. Ruby es un lenguaje de programación y Rails es sólo un framework para desarrollo web con Ruby.

Si alguien usa indistintamente (como si fueran sinónimos) Ruby y Rails (o RoR) ya sabemos que no es un buen desarrollador de software en Ruby y desafortunadamente hay muchos. Si tú quieres ser un buen desarrollador de software en Ruby lo primero que debes tener claro es que Ruby existe sin Rails pero Rails no existe sin Ruby, es decir, puedes desarrollar software usando Ruby sin usar Rails (incluso puedes desarrollar una aplicación web usando Ruby sin usar Rails) pero no puedes usar Rails con un lenguaje de programación que no sea Ruby.

Sólo usa Rails para desarrollo de aplicaciones web si te ves obligado

Rails es sin duda el framework más famoso para desarrollo de aplicaciones web con Ruby pero eso no significa que sea el mejor, de hecho es un framework que definitivamente yo no recomiendo si se trata de hacer una aplicación web profesional y robusta

Si alguien quiere aprender Ruby, lo peor que puede hacer es empezar con Rails. ¿Por qué opino que Rails es tan malo?; voy a exponer sólo algunos puntos y se que a quienes son fans de Rails estos puntos (ni cualquier otro argumento) los va a convencer, pero este post no está dirigido a ellos, como dice el dicho “No hay peor ciego que el que no quiere ver”.

Muchos de los que usan Rails creen saber Ruby y en la mayoría de los casos no es así, ejemplo: en muchas aplicaciones desarrolladas con Rails encontrarán en el código el uso de blank?. Abran una sesión de Ruby y tecleen algo como “prueba”.blank? y verán algo como NoMethodError: undefined method `blank’ for “prueba”:String. Eso es porque blank? no existe en Ruby, es una extensión de Rails. Pero muchos de los que usan Rails no saben eso, porque creen que blank? es una instrucción válida en Ruby.

Otra de las cosas por las que Rails no es un framework recomendable es porque está muy ligado a un ORM llamado Active Record y es uno de los peores ORM que existen para Ruby, el mejor ORM para Ruby que yo he usado es Sequel, seguido de DataMapper.

Active Record no soporta llaves primarias compuestas, el default es que la llave primaria de las tablas en la base de datos este formada por un solo campo llamado id, de tipo entero y además autoincrementable. Si en la Universidad tuviste un profesor(a) de Bases de Datos que más o menos supiera de lo que estaba hablando sabrás que una base de datos en la cual la llave primaria de todas sus tablas esté formada por un solo campo que además se llame igual en todas y tenga que ser de tipo entero es una base de datos que no te encontrarás en producción en el mundo real; a menos que esa base de datos la haya creado alguien que no tiene idea de lo que es el diseño de base de datos, o que sea una base de datos que usa una aplicación hecha en Rails.

Supongamos que tienes que desarrollar una aplicación web para el área de control escolar de una institución educativa. Tienes una tabla de asignaturas en donde cada asignatura tiene una clave que es un campo alfanumérico, tienes otra tabla de estudiantes en donde cada estudiante tiene una matrícula que también es un campo alfanumérico. Lo lógico es que no existan dos asignaturas con la misma clave y tampoco existan dos estudiantes con la misma matrícula. ¿No sería razonable que la llave primaria en la tabla de asignaturas fuera la clave de asignatura y en la tabla estudiantes la llave primaria fuera la matrícula?. Aquí hay un post que ejemplifica lo que hay que hacer en Rails para usar una llave primaria que no sea de tipo entero Non-Integer primary keys in Rails

Y dado que la relación entre estudiantes y asignaturas es del tipo muchos a muchos, tendremos una tabla para saber qué estudiantes están inscritos en una asignatura o visto de otra forma, todas las asignaturas en las que está inscrito un estudiante; ¿no sería lo mejor que la llave primaria de esta tabla estuviera formada por los campos clave de asignatura y matrícula? y además esos campos serían también llaves foráneas ya que son heredados de las tablas de asignaturas y estudiantes respectivamente. Para cualquiera que sepa lo básico de bases de datos relacionales esto es obvio.

Aquí están los diagramas Entidad-Relación (obvio las tablas tendrían más campos además de los que se muestran en el ejemplo y la base de datos contendría otras tablas además de estas)

Base de datos bien diseñada

Base de datos estilo Rails

Hay una gema llamada composite_primary_keys cuyo propósito es solucionar esta situación, pero no funciona 100% como debería.

El argumento de los fans de Rails es que no “luches” en contra de las “convenciones” de Rails, el problema aquí es que esas “convenciones” están mal diseñadas, si para desarrollar una aplicación web usando rails tengo que seguir sus “convenciones”, lo que implica que haga un mal diseño de base de datos (entre otras malas prácticas) o si intento hacer un diseño de base de datos decente tengo que estarme peleando con la herramienta y “parches” para hacer que las cosas funcionen como deben entonces lo mejor es no usar Rails.

Existen otros frameworks para desarrollo web en Ruby, Sinatra por ejemplo es un framework que a diferencia de Rails, no se interpone en tu camino. Eso si, Rails puede hacer algunas cosas automáticamente por ti y en Sinatra tu tienes que programar todo, así que podemos elegir entre usar un framework con el que desarrollemos una aplicación en la que escribamos menos código pero muy probablemente esté mal hecha (si seguimos sus “convenciones”) o usar un framework en el que todo el código lo hayamos tecleado nosotros pero las cosas pueden estar bien hechas (si nosotros las hacemos bien).

Si eres flojo, no te gusta mucho programar, o si no te importa que la aplicación que vas a desarrollar utilice una base de datos mal diseñada por ejemplo, puedes usar Rails, o si en tu trabajo te obligan a usarlo porque son de los que se van con lo que la mayoría usa sin conocer realmente las implicaciones de esa decisión.

Otra muestra de porque en mi opinión Rails no es un buen framework: Estos son los archivos y directorios que tendrías si usas Rails para desarrollar una aplicación web que lo único que haga sea mostrar la hora actual

Para desarrollar la misma aplicación web usando Sinatra sólo necesitamos un archivo con el siguiente código

require 'sinatra'

get '/' do
“La hora acutal es: #{Time.now}”
end

Si usas Sinatra es más fácil que sepas exactamente qué código es Ruby y qué codigo pertenece a instrucciones del ORM (sin importar si el ORM que usas es Active Record, DataMapper, Sequel, etc.), un buen desarrollador de software en Ruby jamás intentará usar blank? si no está desarrollando en Rails; pero ningún buen desarrollador de software en Ruby usaría Rails, a menos que en su trabajo se vea obligado desde luego.

Si tú eres un buen desarrollador de software en Ruby pero te obligan a usar Rails en tu trabajo te aconsejo que busques otro trabajo o que trates de convencer a tus jefes de que usen otro framework, aunque eso muchas veces es más difícil.

Si tú eres un buen desarrollador de software en Ruby y por lo tanto no usas Rails, te felicito, no conozco a muchos

Si programas en Ruby y hasta ahora has estado usando Rails cuando necesitas desarrollar una aplicación web, espero que esta información te ayude a empezar a usar otro framework, yo uso Sinatra pero existen otros como Cuba, Padrino, etc. Te invito a que investigues y encontrarás muchas más buenas razones para no seguir usando Rails

Para algunos existen buenas razones para usar Rails, aunque esas razones para mi no son suficientes, algunas de estas razones son que hay mucha más documentación para Rails que para otros frameworks, la mayoría de las ofertas de trabajo para desarrolladores de software en Ruby son usando Rails, etc. Estos argumentos son ciertos, y el último de ellos de hecho es lamentable, pero si tu objetivo es aprender y ser un buen desarrollador de software en Ruby y no tanto usar x framework porque es el que la mayoría usa o porque con eso te será más fácil encontrar un trabajo, entónces probablemte tampoco para ti esos argumentos sean suficientes.

Anuncios