Busting Ruby on Rails Myths

Question

Estoy trabajando en un proyecto para un cliente de la compañía de TI para la que trabajo y estoy convencido de que Rails es perfecto para él. Tengo una reunión al día siguiente, y me temo que me bombardearán con "¿por qué Rails?" escriba preguntas, y sin dudas, un montón de retórica como "Rails no escala", "Rails es solo un CMS" y los otros miles de mitos que la gente parece tener sobre Ruby on Rails.

Todos tenemos argumentos sobre cómo Rails no escala, es difícil de implementar o explotará en sus manos en cualquier momento. Para aquellos de nosotros que usamos Rails diariamente, sabemos que al igual que cualquier otro idioma o marco. Parece que hay mucha información errónea sobre RoR y, a menudo, Rails recibe una mala versión. Para ayudarme con esta reunión, esperaba compilar una lista de mitos, quizás un mito por respuesta, y podemos votar por los mitos que hemos escuchado antes, para eliminar el miedo, la incertidumbre y la duda que a menudo nublan la verdad sobre Rails.

Después de buscar en Google encontré this blog post, que es exactamente el tipo de cosas que me gustaría recopilar aquí. Como dice David Heinemeier Hansson en el post:

Así que pensé que sería hora de poner las cosas en una serie de temores infundados, incertidumbres y dudas . Revisaré estos mitos uno a uno en el tiempo y te mostraré exactamente por qué no son ciertos.

Esto no es realmente para convencerte que deberías estar usando Rails. Solo puede hacer esa elección. Pero para dar usted los hechos para que pueda tomar su propia decisión informada . Uno que no es fundado en los muchos mitos flotantes alrededor.

¡Aclaremos!

Answer 1

Mito: "Ruby on Rails no escala"

Busto: Esa no es una pregunta específica, responsable. Por favor aclara

Decir que cualquiera que sea la tecnología "no escala" suena muy profesional y muy empresarial, pero no es una pregunta clara. Es solo una forma perezosa de descartar lo desconocido/no comprobado. Pediría una aclaración:

"¿Qué quiere decir precisamente con 'escala'? ¿Cómo lo mide en este momento?"

podría significar:

• Máximo de sesiones de usuario
• tiempo medio de respuesta dada carga
• rendimiento de escenarios simultáneos dados por servidor en un tiempo fijo.
• ... dificultades para organizar el proyecto, por lo que un gran equipo de desarrolladores podría trabajar en él.

Hay muchas maneras de manejar la "escala", pero hasta que sepa con cuál está tratando no siempre es obvio qué hacer al respecto.

hay un montón de soluciones basadas en rubí, incluyendo

• almacenamiento en caché de fragmentos de HTML
• sharding la aplicación a través de múltiples bases de datos
• pre cálculo de trabajo que es compartida entre los usuarios
• empujando un montón de view-rendering funciona en AJAX/Javascript land para que ocurra en el cliente
• usando un servidor front-end web más eficientemente
• simplemente use más hardware (es decir tiempo de desarrollo es caro & los precios del hardware caen), pero este enfoque depende de una tasa baja de crecimiento de la demanda
• hacer menos de forma interactiva y tener más trabajo por lotes
• haciendo sólo una parte de la obra en rubí - por ejemplo, backend existentes legado + carriles frontend, o tal vez las transacciones a través de un sistema de programación funcional + carriles frontend

Si el aspirante no puede llegar a un significado específico de "escala", entonces no es una preocupación válida.

Sin embargo, si el aspirante no llegar a algo específico y medible, a continuación, que haría uso de un timeboxed, solución pico (http://c2.com/xp/SpikeSolution.html) para volver con algunos números - y, posiblemente, algunas opciones sobre cómo hacerlo eso.

Answer 2

¡Haga el argumento desde la única perspectiva que el cliente entiende, dinero!

Muestre cuánto tiempo cree que le tomará realizar en Java, JSP, o cualquiera que sea su tecnología actual, junto con los pros y los contras, como la facilidad para obtener desarrolladores. Luego, indique las escalas de tiempo en Ruby, que seguramente serán menores costos de desarrollo, pero también a costa de que los administradores tengan que implementar un sistema diferente, posiblemente sea más difícil contratar personal que conozca Rails, etc. Es su dinero, así que denles los hechos y dejarlos tomar la decisión.

En respuesta a las críticas específicas que una empresa podría tener contra Ruby on Rails en comparación con sus propios sistemas, hay muchas razones por las que una empresa puede dar, algunas no específicas de Ruby o Rails, ya que tienen muchos desarrollos Java en casa, o infraestructura existente escrita en Java, que siempre será más fácil de usar con un mismo sistema de lenguaje como Java. De todos modos, para responder a sus puntos específicos:

1) ¿Por qué Rails? Simple, Rails está "diseñado" para crear sitios web y hace un trabajo eficiente.Encuentra algunas estadísticas para hacer copias de seguridad (No estoy diciendo que las estadísticas en el enlace son exactos, pero los números siempre impresionar a un cliente)

http://www.theserverside.com/news/thread.tss?thread_id=33120

2) Rieles no escala

http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html

3) ¿Rails es solo un CMS? Si están construyendo un CMS, entonces recomiende Drupal, no Rails

Supongo que tendrá que pensar en sus pies cuando responda a las preguntas de sus clientes, y querrán a alguien que entienda otros frameworks aparte de Rails, tipo de como usar la herramienta correcta para el trabajo correcto

Answer 3

Mito: es difícil contratar un buen programador de Ruby on Rails.

(En realidad, no puedo busto, eso es sólo una idea de un mito potenciales que pueden, por favor, edite éste o crear otra respuesta.)

Answer 4

Mito: Carriles no es lo suficientemente maduro tener la plétora de bibliotecas de código abierto reforzadas construidas a su alrededor que uno necesita para llevar a cabo un proyecto a gran escala de forma rápida y confiable.

Busto: De hecho, hay un montón de gemas y complementos disponibles para la comunidad RoR, muchos de los cuales han sido probados y encontrados por la comunidad activa. No solo existen los recursos, sino que son fáciles de administrar con 'gem' y la arquitectura de plugins incorporada de Rails. En el peor de los casos: no puede encontrar esa joya o complemento perfecto. En ese caso, puede escribir fácilmente su propio documento o pedir prestado al mundo de Java si utiliza JRuby.