¿Cuáles son los beneficios de Ruby on Rails? Después de dos décadas de programación, uso Rails

A veces escucho gente quejándose de sus clientes, diciendo que insisten en usar Rails, que han tomado demasiado Kool Aid. Si son reclutadores, casi se sienten mal del estómago por tener que encontrar otro desarrollador 'primadona' de Ruby on Rails. Luego sacan algo similar a esta comparación increíblemente ignorante entre Git y PHP para probar su punto. “Ni siquiera saben lo que están pidiendo”, dicen.

Para nosotros como programadores, a veces parece que nuestros clientes no tienen ni idea. Nos encanta exagerar casos como este. Cuando lo piensas un poco, no parece correcto pensar que una persona que me está dando dinero para construir cosas es de alguna manera limitada y 'simplemente no lo entiende'. De hecho, creo que la mayoría de los clientes conocen muy bien sus opciones y aún así deciden optar por Rails.

Trataré de explicar lo que, en mi opinión, hace que Rails sea lo suficientemente beneficioso como para ser considerado seriamente para una plétora de proyectos y necesidades.

Beneficios de Rubí

Es posible que nadie sepa acerca de los beneficios de Ruby si no fuera por el propio Rails. A algunas personas les gusta menospreciar a Ruby diciendo que es "tan fácil para Ruby" con su "caballero de brillante armadura llamado Rails" y que sin Rails, "Ruby sería irrelevante". No puedo decir con seguridad si eso es cierto o no, pero sé que sería una gran pena que el mundo se perdiera un idioma tan magnífico. El hecho es que el autor de Rails escogió a Ruby deliberadamente, y su apuesta 'salvaje' dio sus frutos con un gran interés. Lo que él vio entonces, muchos otros lo pueden ver hoy. Ruby de alguna manera permite a los programadores de una manera especial que es tan difícil de explicar a las 'masas sucias'. Entonces, ¿por qué usar Ruby on Rails? Ruby hace felices a los programadores, como se anuncia.

Si bien la mayoría de los desarrolladores están de acuerdo en que Ruby es útil, algunos lo ven demasiado . Se preocupan por lo que podría pasar con todas las libertades que permite Ruby, todo el potencial de uso indebido. Permítanme ilustrar con algunos parches de mono:

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

Es así de fácil: con solo cinco líneas de código, hemos tomado una clase existente y anulado su comportamiento. Nada es sagrado, ni siquiera una cuerda. Este error en particular sería fácil de detectar, pero las cosas pueden volverse mucho más siniestras:

 class String def to_i self.to_f - 1.13 end end "2".to_i #=> 0.8700000000000001

Así, hemos introducido un error en la clase String que podría envolverse y oscurecerse capa tras capa de complejidad.

Entonces, podrías estar pensando: ¿Pueden todos y su madre estropear mi preciosa aplicación? Si bien este comportamiento parece aterrador, en realidad no lo es. En cinco años de usar Ruby, no he tenido exactamente ningún problema con este comportamiento. Puede parecer contradictorio, pero también lo es conducir automóviles a 60 MPH en direcciones opuestas separados solo por una delgada línea blanca en el medio de la carretera. En la práctica, ambos funcionan notablemente bien.

Otro beneficio es que Ruby es una herramienta versátil. Como tal, tiene bordes afilados como cuchillos. Me gusta pensar que los adultos pueden manejar cuchillos muy bien: la protección contra niños es para, bueno, niños (Tweet). Y ser tratado como un niño en TI lo convierte en víctima de la paradoja Blub de Paul Graham: cree que está mejor sin ciertas características que no comprende o que alguien le dijo que son demasiado peligrosas. Por supuesto, hoy nos preguntamos “por qué usar Ruby on Rails”; por lo tanto, este es un debate para otro momento. Es cierto que Ruby pierde algunas características que tienen otros lenguajes (Lisp hmm, hmm). En general, Ruby está cerca de la cima del 'continuo de poder del lenguaje'.

Mis primeros años con Ruby fueron una lección de humildad. Aprendí mucho simplemente leyendo el código de otros. A veces me asombraba; a veces, estaba enojado; pero eventualmente, este conocimiento me permitió comunicarme con mi computadora mucho más efectivamente que antes. Casi siento lástima por algunos otros lenguajes de 'burocracia' que te hacen saltar a través de aros solo por el hecho de saltar a través de ellos, todo mientras te dicen "Solo estoy haciendo lo que es mejor para ti, ¡es por tu propio bien!"

Pragmatismo

Hay un profundo respeto por el pragmatismo entretejido en el ADN de Rails al nivel más bajo posible. En combinación con los beneficios de Ruby, este pragmatismo produce soluciones elegantes y alienta/inspira a la comunidad de desarrollo de Ruby on Rails a hacer lo mismo. El pragmatismo a menudo se anuncia como una carpa de Rails, por lo que esta afirmación no es nueva, pero recientemente recordé su veracidad cuando un amigo mío trató de mostrarme cuán "genial" es realmente Hibernate. Él estaba luchando. Pude sentir su dolor porque no pudo establecer una gran cantidad de opciones y parámetros de configuración que deberían haber sido los valores predeterminados del marco en primer lugar.

Con la edad, mis estándares de complejidad artificial han crecido más y más. Teniendo en cuenta que comencé a escribir código de producción en 1989 a los 11 años (empezando con un proyecto para mi vecino de al lado en Clipper Summer '87), tengo una tolerancia cercana a cero para las complicaciones innecesarias. Y Rails obtiene una puntuación realmente alta en ese departamento. Es algo más que 'convención sobre configuración'; Me refiero a toda la mentalidad pragmática que se valora mucho en la comunidad de Rails y que impregna toda ella.

Expresividad

Rails es lo más cercano al inglés posible (a menos que esté usando COBOL). Utiliza lo que se conoce como DSL interno, extendiendo Ruby con su propia semántica. Construir un DSL siempre es peligroso ya que está desarrollando efectivamente un nuevo idioma. Debido a que es interno, no necesita usar un analizador externo, pero en cierto sentido se siente como un nuevo lenguaje. El equipo de Rails logró un buen equilibrio con su DSL, usándolo donde tiene sentido y rara vez exagerándolo, demostrando un excelente autocontrol. Creo que cualquier programador, independientemente de su experiencia con Rails, (e incluso algunos no programadores) podrían entender esto:

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

De hecho, si no está familiarizado con Ruby, esto puede parecer extraño, es casi como si no fuera un lenguaje de programación. Una vez que te das cuenta de que son solo llamadas a métodos sin paréntesis, estás listo para comenzar. Aún así, Rails DSL se siente como si fuera un lenguaje especial para describir requisitos cuando, de hecho, es solo una denominación inteligente y un uso inherente de la excelente sintaxis de Ruby.

Comunidad

Rails tiene un ejército de committers que se aseguran de que se mantenga en óptimas condiciones. Muchos proyectos se calman con la edad, sin embargo, con Rails, las chispas aún vuelan cuando se deben tomar decisiones. Parece que los mantenedores (todavía) realmente se preocupan y quieren que las personas usen Ruby on Rails y entiendan sus beneficios.

Debajo de Rails, como guinda del pastel, se encuentra Ruby con su formidable administrador de paquetes, RubyGems, comparable a CPAN en términos de cantidad de paquetes, y considerando la antigüedad de CPAN, esa afirmación es (por decirlo suavemente) muy impresionante. Rails tuvo un breve descarrilamiento cuando intentó crear sus propios "complementos de Rails". Afortunadamente, esto no funcionó, por lo que RubyGems sigue siendo la excelente fuente unificada de código programado por personas muy brillantes.

La sinergia entre un lenguaje genial, un marco web pragmático y una comunidad excelente le da a Rails un resultado mucho mejor que la suma de sus partes.

Madurez

Rails ha estado alrededor de la cuadra. De una manera hipster, ya ni siquiera es tan genial. Esto es bueno cuando se trata de elegir una pila de tecnología: quieres algo probado. Y Rails es solo eso. Recientemente escribimos un artículo sobre la amplia variedad de intérpretes y tiempos de ejecución de Ruby que ahora están disponibles.

Márketing

Sé que sé. Como profesional de TI, realmente debería valorar las cosas 'serias' e ignorar el 'brillo' . Puede parecer superficial, pero seamos sinceros:

1. En comparación con la competencia, el sitio de Rails se ve bien .
2. El primer elenco de pantalla de Rails, en su día, fue simplemente impresionante. Puede que no parezca tan impresionante hoy, pero recuerda que la única razón por la que todos conocemos Java es que todo el mundo estaba tan entusiasmado con la posibilidad de ejecutar un Java Applet en el navegador. Esto resultó no ser tan importante después de todo, pero aun así, esto puso a Java en el radar. Del mismo modo, este screencast de motor de blog de 15 minutos fue un gran éxito que entusiasmó a mucha gente.

Ni siquiera se trata de vanidad; se trata de involucrar a tantas personas inteligentes como sea posible para poner agua en el molino. Cuando se consideran los marcos, el mejor lugar para estar es entre la multitud. Elegir un marco en el que estas personas inteligentes se están enfocando simplemente significa que ya tienes mucho más terreno cubierto. Y esto me lleva al siguiente punto.

(No) reinventar la rueda

Tengo debilidad por los marcos diminutos. Me gusta cuando puedo entender qué está haciendo un marco en particular y por qué. En este sentido, Rails resulta algo abultado, e incluso abrumador por momentos.

El dilema aquí: ¿cuántas veces quieres escribir lo mismo una y otra vez? Algo de esto se puede reescribir mejor, estoy seguro, pero lleva tiempo, mucho tiempo. Cuanto más permita que Rails haga por usted, menos tendrá que preocuparse por reescribir o volver a implementar su funcionalidad.

Rails es (como dicen) 'baterías incluidas'. Esto no es bueno si le gusta la escasez o si siente la necesidad de tener un amplio conocimiento de cómo funciona todo. En la práctica, si dejas ir tus miedos, parece funcionar. Rails tiene valores predeterminados razonables para casi todo lo que necesita y es lo suficientemente modular para evitar arrinconarlo en un aprieto.

Conclusión

Pregúntese nuevamente, ¿por qué usar Ruby on Rails? Rails es adecuado tanto para sitios web públicos de última generación que compiten con aplicaciones de JavaScript de una sola página como para aplicaciones complejas de sistemas centrales empresariales que generalmente se ven un poco "más feas" (con una interfaz de usuario más genérica y de menor fidelidad), pero compensan esto. mancha con un montón de complicadas reglas y lógica de negocios. Su beneficio es que es versátil y capaz de competir tanto con los elegantes como con los poderosos.

Para la mayoría de los problemas comunes, Rails tiene un componente a su disposición casi listo para usar con documentación que está constantemente por encima del promedio (de alguna manera, el equipo central de Rails convenció a los contribuyentes de que escribir documentación es genial (aunque todos sabemos que es no), lo que conduce a documentos bien escritos, concisos y que ahorran tiempo).

Cuando deja de lado los unicornios y los abrazos de los viernes, termina con un marco poderoso que puede usar tanto para su futuro cambio de juego como para su próximo sitio comercial intermedio. Y con su grupo de gemas de primera línea, tiene al alcance de su mano un arsenal que implementa algunas de las ideas más brillantes en la programación de computadoras. Sin alboroto.