Ruby on Rails inconvenientes y advertencias [cerrado]

Este no es un gambito de apertura para atacar RoR, ¡honesto!

Estoy aprendiendo el marco de Ruby and the Rails. Prima facie parece ser bastante bueno, y una experiencia maravillosa en comparación con PHP. (De hecho, me recuerda los días más felices con C # y .NET).

Sin embargo, al entrar en esto, no tengo experiencia con este marco o lenguaje, y tengo curiosidad: ¿cuáles son las desventajas actuales o las cosas que desearía saber cuando comenzaba?

(¿Tal vez esto debería hacerse una wiki comunitaria?)

Esto se debe a la experiencia de aprender, continuar aprendiendo y escribir una aplicación relativamente simple en Rails.

1) curva de aprendizaje

Rails es engañosamente simple. Los tutoriales, videos y libros demuestran cuán rápido puede obtener una aplicación que funcione (aunque fea), pero estos realmente solo rascan la superficie. Tienden a depender en gran medida de la generación de código y el "andamiaje", que sin duda es una buena herramienta para el aprendizaje, pero rápidamente supera su utilidad.

No se equivoquen, Rails es difícil de dominar. Una vez que haya superado los conceptos básicos (más sobre esto más adelante), se encontrará con una pared si necesita hacer más que la funcionalidad extremadamente simple de "aplicación de demostración" que ve promocionada. Puede sobrevivir con un conocimiento básico de Ruby mientras aprende, pero rápidamente necesita recoger a Ruby o se quedará seco (y no el buen tipo DRY) si necesita salir de las restricciones de Rails.

Rails es, como me gusta llamarlo de una manera amorosa, pintar por programación de números . Si te apegas al 100% a las convenciones (es decir, te mantienes dentro de las líneas y usas los colores que te dicen que uses), puedes hacer aplicaciones decentes de manera rápida y fácil. Sin embargo, si tienes que desviarte, Rails puede pasar de tu mejor amigo a tu peor enemigo.

2) Cuando todo lo que tienes es un martillo ...

Rails hace aplicaciones CRUD simplistas muy bien. El problema surge cuando su aplicación tiene que hacer más que solo leer / escribir desde una base de datos. Ahora, para el registro, la última versión de Rails que utilicé fue 2.3.4, por lo que las cosas pueden haber cambiado desde entonces, pero me encontré con problemas importantes cuando cambiaron los requisitos comerciales, por lo que la aplicación tuvo que tener un pequeño sistema de flujo de trabajo integrado e integrarse con Una aplicación PHP heredada. La convención de Rails de "una forma, un modelo" funciona bien para aplicaciones triviales y aplicaciones de entrada de datos, pero no tanto cuando necesita hacer lógica de procesamiento, o tener flujos de trabajo, o cualquier cosa que no sea la típica "El usuario ingresa datos en unos pocos campos de texto, pulsa Enviar "tipo de cosa. Se puede hacer, pero de ninguna manera es "fácil", o más bien no fue

Además, a Rails no le gusta jugar bien con otras aplicaciones que no usan sus métodos preferidos de acceso a datos; si tiene que interactuar con una aplicación que no tiene una API de estilo "Web 2.0", debe evitar Rails en lugar de hacerlo con ella; Una vez más, hablo por experiencia aquí, ya que esto es lo que me pasó.

3) es nuevo

Finalmente, Rails sigue siendo el "chico nuevo en el bloque" en muchas áreas. Esto no importa para el uso personal o el tipo de escenarios "Creo que es genial y quiero aprenderlo", pero hablando como alguien que preferiría usar Rails en mi trabajo diario, si no estás en un lugar donde está Rails generalizado, puede ser muy difícil encontrar trabajo a tiempo completo como desarrollador de Rails. Todavía es en gran medida el dominio de las "nuevas empresas modernas" y no un jugador importante en la mayoría de las áreas metropolitanas. Su millaje puede variar en este sentido, pero sé que mi área (Tampa) Rails es esencialmente inexistente.

4) Fuego y movimiento

Rails está en constante cambio. Esto es bueno y malo a la vez; es bueno porque la comunidad evoluciona y adopta nuevos conceptos. Es malo porque la comunidad evoluciona y adopta nuevos conceptos. Puede ser muy abrumador para un novato de Rails porque, por lo general, cuando te encuentras con un problema y miras a tu alrededor, verás a personas recomendando tal y tal gema para solucionarlo, o diciendo que de todos modos eso es malo y que no deberías ' No lo use, esta es una mejor manera ... y termina teniendo una lista de herramientas adicionales para aprender junto con Rails para mantenerse al día con los cognoscenti de Rails. Cosas como Git, BDD/RSpec, Cucumber,Haml/Sass, y una gran cantidad de otras cosas flotan y son empujadas como la "forma correcta de hacer las cosas" en Rails-land, y hablando por experiencia, puede terminar abrumado tratando de aprender una docena o más de tecnologías además de Rails, porque usar el kit de herramientas estándar de Rails se siente "mal".

Esto se complica aún más con Rails 3.1, lo que hace que Sass y CoffeeScript sean todas las cosas por defecto, por lo que un novato total de Rails no solo tiene que aprender Ruby and Rails sino Sass (posiblemente simple si conoce CSS) y CoffeeScript (no es una locura difícil, pero ciertamente lo suficientemente diferente de JavaScript sin procesar) como mínimo para comenzar, además se puede suponer Git. Incluso sin tener en cuenta a RSpec y sus amigos, y la docena o más de gemas con las que generalmente terminarás, son 4 cosas diferentes que debes aprender antes de poder comenzar a escribir aplicaciones Rails. Compare esto con un lenguaje como C # o Java, o incluso PHP, donde su conocimiento de HTML / CSS / JavaScript / SQL no va a cambiar y solo tiene que aprender el lenguaje en sí y quizás los matices del marco.

Documentación.

Si bien las guías de Rails son un excelente recurso de aprendizaje, la referencia de la biblioteca Rails (y Ruby, en general) no es fácil de navegar. Digamos que quieres aprender más sobre el belongs_tométodo. Aunque se usa en ActiveRecord::Basesubclases (modelos de uno), no está documentado en ActiveRecord::Basedocumentos, sino en una combinación que importa la clase. Esencialmente, no puede ver una lista completa de todos los métodos que puede usar en un objeto en un lugar (excepto cuando enciende irby verifica el objeto en sí).

Con un lenguaje altamente dinámico como Ruby, no es sencillo saber de dónde proviene un método que está utilizando. Puede ser un problema, especialmente para los programadores de aprendizaje que intentan comprender una nueva pila de tecnología.

Ruby on Rails tiene una curva de aprendizaje significativa. Primero tienes que aprender las rarezas del idioma, luego aprender el marco, luego aprender la forma de hacer las cosas de Rails, luego aprender sobre las muchas gemas comúnmente utilizadas.

Sin embargo, cuando has aprendido esas cosas, es increíblemente natural. De hecho, otros marcos comienzan a parecer una carga.

Rails está muy orientado a TDD / BDD, por lo que si no es así, eso son dos cosas más que tendrá que aprender antes de convertirse en un programador competente de Rails. No tiene un compilador e IDE que lo respalden, por lo que la cobertura de prueba es en gran medida su respaldo.

Muchos defensores de TDD, incluido yo mismo, considerarían esta una de las fortalezas de RoR, así como su maldición. Una vez que comience a escribir TDD, encontrará que la seguridad ofrecida por la cobertura de prueba es mejor que la seguridad ofrecida por un compilador. Entonces tener que escribir código SOLO para complacer a un compilador se vuelve pesado.

TDD no se siente como una tarea adicional en RoR, se siente como la única forma de trabajar.

Rails tiene un grave problema de rendimiento: cada solicitud se pone en cola detrás de la actualmente activa, en lugar de enhebrarlas como lo hacen la mayoría de los marcos o permitir que los eventos de bloqueo liberen otras solicitudes como lo hacen Node.js y Twister. Esto significa que debe codificar para que los tiempos de respuesta sean rápidos, pero eso es bastante fácil de hacer en la mayoría de los casos.

Rails también está muy diseñado para manejar muy bien los sistemas de contenido, que para ser justos es una gran parte de Internet. Hacer algo un poco más complicado, como un juego web o un sistema de comercio electrónico, significa aprender nuevas gemas. Aprendes rápidamente que todas las gemas están ahí afuera, pero cuanto más oscuro sea lo que quieras hacer, más difícil será encontrar una buena documentación.

En mi experiencia personal, el mayor dolor de cabeza está relacionado con la compatibilidad .

Cuando:

• hay xproyectos de rieles desplegados,
• cada proyecto usa ygemas.
• mientras hay nversiones de rieles,
• mversiones más de gemas instaladas,
• con severalversiones de rubí,
• en una sola caja de Linux como máquina de producción.
• el programador trabaja en otro cuaderno de desarrollo OS X.

Como un profesional independiente, que no tiene el lujo de actualización / actualización de la mayoría de las cosas, se enfrentará a una gran cantidad de problemas de compatibilidad de las variables anteriores, mientras que ... rails, gemsy rubyseguir cambiando / evolución.

La velocidad definitivamente es un problema. La extrema flexibilidad de Ruby viene con un gran rendimiento.

Escalar horizontalmente es una tarea no obvia, excepto por tecnologías específicamente diseñadas para esa tarea, que generalmente intercambian simplicidad para escalar bien.
Si puede manejar 100 veces más solicitudes por máquina con la tecnología A que con la tecnología B, vale la pena considerar el uso de la tecnología A si tiene razones para creer que puede servir sus datos desde un único servidor durante un período de tiempo que le permite agregar paralelización posterior.
En 2009, stackoverflow todavía se servía desde un servidor web . Por supuesto, esto ya no es una opción. Pero supongo que fue bueno que comenzaran con una tecnología, que podría escalar a muchos usuarios en una sola instancia, antes de que tuvieran que preocuparse por escalar.

Comparado con eso, RoR es realmente lento. El tiempo para manejar solicitudes simples es significativo y, por lo tanto, es un problema manejar muchos clientes (todo esto se ve en relación con alternativas más rápidas).

En aras de una orientación vaga, aquí hay algunos números, comparando varios otros idiomas adecuados para el desarrollo web con Ruby:

• Ir
• Clojure
• JavaScript V8 ( node.js )
• JRuby (una alternativa que no debe olvidarse; dependiendo de su área problemática, JRuby puede ser una opción mejor o peor para obtener algo de velocidad de una aplicación de rieles)
• Scala
• Java
• DO#

Tenga en cuenta que esto no significa que si usa Framework X para Java será exactamente 200 veces más rápido que RoR. Pero la diferencia de velocidad medida en estos puntos de referencia tiene un impacto importante en el rendimiento general de su aplicación.

Rails tiene un grave problema de rendimiento: cada solicitud se pone en cola detrás de la actualmente activa, en lugar de enhebrarlas como lo hacen la mayoría de los marcos o permitir que los eventos de bloqueo liberen otras solicitudes como lo hacen Node.js y Twister. Esto significa que debe codificar para que los tiempos de respuesta sean rápidos, pero eso es bastante fácil de hacer en la mayoría de los casos.

Creo que esto es muy equivocado. Puede ejecutar Rails en modo multiproceso. Cuando se ejecuta en modo multiproceso, solo debe usar bibliotecas de E / S que liberan el GIL (por ejemplo, la gema 'mysql2'), de lo contrario, no tiene sentido.

Si está utilizando jRuby, puede ejecutar un solo proceso de rieles en modo multiproceso y utilizar completamente toda la potencia de CPU disponible. Sin embargo, si está en MRI (Ruby 1.8.xo 1.9.x), debe ejecutar varios procesos para utilizar completamente las CPU, que también es el caso con node.js.

• Rails tiene muchas sutilezas que te ocultan la complejidad. (Asociaciones ActiveRecord, todo el ciclo de vida de validación / guardado, la interpretación de los datos de la solicitud basada en los encabezados provistos) Cuando recién comienza, esto es increíble. A medida que crezca, descubrirá que comienza a adaptar su aplicación a "la forma de Rails" de manejar las cosas: a veces esto es bueno, a veces esto es inofensivo y, a veces, es contra-intuitivo a lo que está tratando de hacer. No todas las tablas de la base de datos deben modelarse como objetos, puede que sea necesario realizar un paso de validación en otro lugar, etc. Muchos programadores de Rails evitan no luchar contra el marco (lo que generalmente es sabio), pero el efecto a largo plazo de esto es ... usted llevará los hábitos de Rails a lugares donde no necesariamente se los solicite.

• La comunidad tiene la costumbre de escribir software que se llama "magia": ¡almacenar en caché bibliotecas que funcionan mágicamente! Evented I / O que mágicamente te hace más rápido! Magia Magia! Lo que suele suceder aquí es que se proporciona una API muy atractiva para una solución técnica que falta, y los ejemplos muy bonitos lo engañan de que la cosa hace lo que pretende, y solo más tarde descubre que cubre una solución incompleta. El ciclo de esto es bastante constante, y aprendes a seguirlo, pero definitivamente debes familiarizarte con la idea de leer mucho y mucho el código del que dependes (¡algo bueno!). Las soluciones mágicas de la comunidad de Rails no son tan mágicas como sugiere el archivo README.

• Corolario anterior: cuanto más uses Rails, más deberías leer su fuente. Cuanto mejor comprenda el marco interno, más feliz será a largo plazo. No es realmente Rails específico en esto, pero solo te lo digo por experiencia aquí. Los nombres de los métodos a veces prometen algo que realmente no estás obteniendo

• El cultismo de carga es un problema con Rails, pero eso probablemente sea cierto con todas las comunidades framework / lang. Parece más pronunciado (para mí) en Rails, y como tal tiende a dar un aspecto generacional extraño al código de Rails: a medida que trabajas en diferentes proyectos de Rails, notarás ciertas tendencias que tienden a traicionar el período de tiempo en el que se crearon. . Como puede deducir de esa declaración, la comunidad tiende a moverse bastante rápido en la adopción de nuevas soluciones y en desaprobación de las antiguas. Realmente deberías estar al tanto de tus noticias de Ruby, solo para entender parte del código que experimentarás a diario.

• En términos generales, creo que el problema de la concurrencia de datos generalmente no se aborda bien en la comunidad: a medida que creces una aplicación, cuando llegas al punto en el que necesitas fragmentar datos, deshacer cambios físicamente remotos y bloquear el acceso a los datos, las soluciones se vuelven un poco más afinado a mano, lo que hace que algunas de las cosas de Rails que se ven bien se enturbien con las necesidades técnicas de precisión. Rails no resuelve todos los problemas que tendrá con una aplicación web, supongo que lo digo, y aunque los creadores ciertamente no predican ese mensaje, es fácil dejarse engañar para pensar que está implícito.

Dependiendo de cómo lo veas, la velocidad con la que cambia Rails puede o no ser una advertencia para ti. Las cosas cambian radicalmente de año en año a medida que se extrae más de lo que apesta y necesita soluciones.

Sin embargo, si estás en desarrollo activo, estarás al tanto de esto.