Decisión comercial: por qué uso Django y no Ruby On Rails
Mi empresa actualmente está trabajando en algunos sitios web para un cliente comercial. No entraré en detalles ahora. No hay nada que pueda usar o alterar para lograr todo lo que quieren. Entonces tengo que desarrollar una solución personalizada. Antes de comenzar, estaba mirando las opciones que tenía y solo había dos que realmente consideraba. Django y Ruby On Rails. ¿Por qué elegí ir con Django y no con RoR? Déjame darte algunos pensamientos.
Antes de comenzar con las razones principales de la decisión, permítanme aclarar una cosa. Estoy 100% seguro de que podría haber implementado los sitios web en ambos marcos aproximadamente al mismo tiempo. También estoy seguro de que las expansiones que estamos planeando actualmente habrían sido posibles en ambos marcos y que los costos iniciales de desarrollo y hosting habrían sido los mismos. Entonces, ¿por qué había una razón para elegir “a” sobre “b”?
Marcos
Django y Ruby On Rails son solo frameworks. Brindan aproximadamente las mismas características y tienen defectos. No importa cuánto ames tu marco, siempre encontrarás algo que el otro está haciendo mejor. Pero dado que son solo marcos, hay algo más que debe considerar. El lenguaje debajo.
Otros marcos
Sé que hay muchos marcos por ahí. Pero no son tan completos como esos dos ni son tan ricos en funciones. Hay momentos en que la flexibilidad que le brindan es una ventaja, la mayoría de las veces simplemente complican su trabajo.
Idioma
Hay algunas diferencias entre Python y Ruby y creo que ya las conoces. Solo para el lector ocasional que investiga un breve resumen.
En Python solo hay una forma de hacer las cosas. Hay pautas sobre cómo escribir y formatear su código y hay, bueno la mayoría de las veces, una estructura limpia en su código, sin importar lo que haga. Python sigue el viejo principio “el código es mucho más leído que escrito”.
Si eliges trabajar con Ruby, sucederán tres cosas. Tendrás la sensación de que la mayoría de nosotros teníamos 199x cuando nos rompimos los dedos tratando de ingresar todos esos personajes elegantes que Perl nos pidió que escribiéramos. Leerás muchas cosas sobre los estilos de codificación y las verás violadas en cada rincón oscuro donde alguien publica un código. Y por último pero más importante: finalmente creerás en la magia. Hay muchas cosas que suceden o son posibles que ni siquiera puedes imaginar. Las construcciones más abstractas simplemente funcionan de alguna manera.
Bibliotecas de terceros
Algunos de ustedes saben lo que estoy pensando en las bibliotecas de terceros. Los usarás y tendrás problemas. Pero mi experiencia es que las bibliotecas de Python tienden a ser más potentes o maduras. Es posible que haya algunas excepciones. No pretendo conocerlos a todos.
Pequeños ayudantes
Hay algunas herramientas que te harán la vida más fácil. Le ayudarán a mantener e implementar su código. Si te tomas un tiempo para aprenderlos, te lo devolverán para ahorrarte muchas horas. Preciosas horas que puedes usar para relajarte con tus amigos, divertirte con tu chica o ganar más dinero.
La mayoría de los evangelistas de Python me odiarán por esta frase, pero casi todas las herramientas geniales están escritas en Ruby. Si nos fijamos en las alternativas, están allí. Y ellos trabajan. Pero en comparación con el original, simplemente apestan. Lamentablemente, la mayoría de ellos solo admiten Ruby.
Llamemos a esto un empate. Si prefiere un idioma sobre otro, sabe qué marco utilizará. Si no te importa y ves ventajas en ambos, se vuelve realmente interesante.
Django – Tuxedo y un sombrero de copa
Creo que la mejor descripción está en la portada.
El marco web para perfeccionistas con plazos
No hay casi nada que pueda agregar. Si solo tienes que hacerlo y si está en las capacidades de Django, eres increíblemente rápido. Y no puedes producir algo que no se pueda mantener. Tiene todas las cosas interesantes como ayudantes, un ORM que funciona, una excelente interfaz de administración y más.
Mapeador de objetos relacionales
Si odias el SQL y seamos honestos, toda persona sensata lo hace, te encanta un ORM. Gracias a la implementación predeterminada de Djangos, escribe su base de datos como clase Python y la consulta utilizando Python. No tiene que escribir una línea SQL por sí mismo.
Si intenta hacer algo que no está en línea con el ORM, está jodido. No importa cuánto lo ames, mejor espero que haya la capacidad de hacer lo que quieras o que tengas un problema.
La buena noticia es que están trabajando en ello. Desde 0.96 cuando comencé a usar Django, antes de que tuvieras que usar la versión SVN, han recorrido un largo camino y lentamente intentan resolver los problemas que tuvimos durante años. Modelos de bases de datos existentes. ¿Nadie?
La parte triste es que aún necesita una biblioteca de terceros para las migraciones. Te sugiero que eches un vistazo al sur. Funciona fuera de la caja y nunca tuve un problema importante con él.
Interfaz de administrador
Si está cuidando el sitio web o su cliente no importa. Necesita una forma de administrar todo el contenido. Si no tiene que escribirlo, ahorrará tiempo. Es potente, personalizable y creo que en la mayoría de los casos no hay necesidad de otra cosa. Si le ahorra tiempo y trabajo y si está funcionando, está bien.
Comunidad y proyectos conocidos
Hay una razón por la que dije traje gris y sombrero de copa. Uno de los ejemplos de primera plana es el Washington Post. Creo que he leído sobre algunos sitios de juegos y Curse es el más grande que también lo usa.
Y aquí está el punto principal de este tema. Django es utilizado por muchas personas. La mayoría de las veces no es espectacular. Es utilizado por personas normales para alimentar algunos sitios. No hay nada lujoso al respecto. Es solo una herramienta en una cadena de herramientas para construir cosas. La mayoría de las veces solo lees una nota breve y aburrida al respecto.
Ruby On Rails – Obtenga su camisa Hawaii y una articulación
La razón principal por la que tanta gente ama a RoR es la “convención sobre la configuración”. Las cosas simplemente funcionan. Escribe una línea de código y hace tantas cosas que ni siquiera sabe. Y ese es el punto donde RoR puede tener un dolor en el culo. Si algo no funciona, a veces es muy difícil incluso encontrar el lugar donde falla miserablemente. A veces tienes que mirar detrás de la magia y en este punto te das cuenta de que la linda chica que acaba de ser cortada por la mitad tiene algo entre sus piernas que no querías saber.
Las migraciones son geniales
Creo que RoR fue el primer proyecto que realizó correctamente las migraciones. Y están muy por delante de sus competidores. Al menos la última vez que lo revisé. Tal vez se pusieron al día, tal vez son mejores en algunos escenarios, pero la mayoría de las veces las migraciones realizadas por RoR son simplemente increíbles.
IDEs – Si te gustan, ganas
Si te gustan los IDEs, ve con RoR. Hay muchos de ellos y la mayoría simplemente rock. Le ayudan a desarrollar e implementar sus aplicaciones, al menos hasta cierto punto. Se combinan perfectamente y “simplemente funcionan”. Y actualmente no vi una alternativa para Django que funcione tan bien como RubyMine o RadRails.
Realmente no me gustan los IDEs, pero después de trabajar con RubyMine durante algunos días, tengo que admitir que lo compraría si usara RoR de forma regular. O para ser más precisos: al menos lo consideraría.
Despliegue
Por favor, no me hagas empezar. Hay tantas formas de implementar RoR que realmente no puede contarlas. Si está buscando una implementación fácil, vaya con RoR. Hay muchas herramientas, tutoriales, solo cubren casi todos los escenarios de implementación locos que puedas imaginar.
Comunidad y proyectos conocidos
Mirando esas nuevas empresas elegantes, todos parecen preferir RoR. Te dicen lo bueno que es, por qué su producto solo es posible porque RoR y otras herramientas geniales y que a todos les encanta todo sobre su configuración. Son jóvenes, dirigen startups y son hipsters. Esta es la imagen actual, para mí y algunas personas con las que hablé, del usuario típico de RoR.
Si está buscando una solución, encontrará al menos 20 formas de hacerlo. Ni una sola manera desde 2003 (eso sorprendentemente aún funciona). Puede elegir cómo trabajar y cómo resolver problemas. Puede acumular algunas deudas y simplemente juntar todo para arreglarlo más tarde o simplemente asegurarse de que su código sea hermoso y elegante desde el principio. Creo que esta es la razón por la cual tantas startups eligen RoR. Piense en todo, libere un producto, sobreviva hasta que obtenga algo de dinero y comience a pagar su deuda. En el período de tiempo más crítico, cuando no tiene dinero, ni producto y cuando los necesita a ambos, RoR lo ayuda a realizar sus tareas.
Decídete
La decisión básica que debe tomar, desde un punto de vista técnico, es cuáles son sus prioridades. ¿Quieres un lanzamiento rápido? ¿Prefieres un sistema fácil de entender? ¿Quieres jugar con todos los niños geniales o con los tipos aburridos en sus oficinas? ¿Se puede acumular deuda?
Breve nota al margen. La frescura y el factor de la comunidad es, en mi humilde opinión, no está vinculado a Django y Ruby on Rails. Lo mismo se aplica a Python y Ruby.
Lo primero que debe hacer al elegir su marco es asegurarse de que se ajuste a su proyecto y flujo de trabajo. Planeo mis proyectos y entrego a tiempo. Considero problemas y agrego algo de tiempo antes de enviarle al cliente mi presupuesto. Entrego cuando el producto está listo, no mientras estoy trabajando en él. Me puedo permitir usar Django. Esto es lo más importante en el proceso de evaluación del marco adecuado. Pero hay otras cosas.
A veces necesitas personas adicionales para tu proyecto
Si tengo un proyecto que tiene que hacerse en un corto período de tiempo, si tengo más de un proyecto en un cierto período de tiempo o si simplemente tengo otras razones por las que no puedo trabajar en él, necesito contratar a alguien.
Creo que puede obtener desarrolladores competentes para ambos marcos. Es posible que tenga una mejor oportunidad de encontrar a alguien que ya haya trabajado con RoR que Django, pero también encontrará muchas personas que pueden aprender Django en un corto período de tiempo que a veces puede permitirse.
Si trabajo con otras personas, termino teniendo que mantener el código de todas ellas. Por lo tanto, preferiblemente puedo leer y entender fácilmente el código y si tengo un deseo adicional no tengo que resolver un cubo de rubik para comprender la magia.
Despliegue
No despliegue muy a menudo. Cuando el sistema funciona, casi no hay razón para tocarlo junto a las actualizaciones o adiciones habituales. Si tuviera que hacerlo, o tendría una ventaja si lo hiciera, desplegarlo varias veces a la semana o incluso un día, consideraría este punto. Pero no es necesario, por lo que una de las mayores ventajas de RoR acaba de desaparecer.
No creo que haya grandes diferencias además de las herramientas. Cuando tiene todo en su servidor, las configuraciones se realizan en unos minutos.
Decisión
Fui por Django. Prefiero productos sólidos que sean fáciles de mantener. No digo que no puedas conseguir esto con Ruby on Rails, pero será mucho más difícil. Si estuviera en otra situación podría ser que hubiera ido por RoR.
Además de ese proyecto, mi empresa se centrará en ofrecer impresionantes aplicaciones web y sistemas basados en Django, al menos si se ajusta al cliente. En mi humilde opinión, hay muchas razones y ventajas en el uso de Django. Si usted o su empresa están ante la misma decisión, decida lo que está haciendo. Existen fuertes argumentos para ambos marcos, pero creo que depende de su proyecto, incluso si tiene la impresión de que todos son fanáticos de Ruby on Rails, que leen blogs y otros recursos.
