ruby on rails - software - ¿Rails es una caja negra?

ruby on rails software (9)

¿Rails es una caja negra?

Rails tiene un "código mágico" en el que solo escribes lo que dice un tutorial para escribir, y todo funciona mágicamente, pero no es una caja negra.

Por definición, una "caja negra" es algo que no se puede mirar adentro. Por lo tanto, no puede tener un proyecto de código abierto de ''caja negra''. Aquí está el código fuente estable de los rieles 2.1 , eche un vistazo
Si leer código fuente no es lo tuyo, la mayoría de estas "características mágicas" están bien documentadas y explicadas en muchos sitios web y blogs (y si no lo son, siempre puedes preguntar aquí y estoy 100% seguro de que obtendrás una buena respuesta)
Recuerda que si todavía estás en la etapa de tutorial, cualquier tutorial tendrá mucho de ''solo poner esta línea de código'', porque están tratando de transmitir conceptos , no profundizar en el funcionamiento interno de todo. Cualquier otro marco en el planeta, no solo raíles, tiene ''magia'' en sus tutoriales

He estado haciendo algunas aplicaciones de rails simples últimamente. Conozco a Ruby bastante bien, pero cuando comencé a hacer las cosas "a la manera de los rieles" noté que algunas cosas se hacían "solo porque" y es difícil para un (novato) novato saber qué hace el código.

¿Los rieles han perdido el punto y se han convertido en algún tipo de lenguaje de cuarta generación? Quiero decir, TIENES que hacer algunas cosas (que no necesitas entender) para desarrollar sitios web de rieles, y la alternativa es explorar el código fuente para descubrir qué hace qué.

También he visto que la gente estaba pagando en efectivo a cualquiera que pudiera hacer buenos tutoriales de rieles ... Estamos hablando de un marco que pone la simplicidad en primer lugar, ¿es necesario pagar buenos tutoriales?

No me malinterpreten, creo que Rails ha traído muy buenas ideas a la corriente principal (como la convención sobre la configuración), pero tiene esta simplificación excesiva ("¡simplemente ponga esta línea de código y ... funciona!") Redujo la simplicidad del marco tratando de lograr?

Como con cualquier cosa, creo que el Diablo está en los detalles. Sí, es extremadamente fácil levantar un sitio y poner las piezas juntas para hacer algo que funcione, pero crear un sistema robusto y bien diseñado requiere un diseño y pensamiento más profundos. Es muy fácil comenzar a tomar malas decisiones de OO, como romper la ley de Demeter porque las cosas son muy rápidas de armar. Rails es así de fácil. Great Rails no lo es.

Creo que "conocer sus convenciones" no es el problema. Sé que si hago X entonces tengo Y funcionando. Pero, ¿qué hace X? Rails me parece una caja negra e, irónicamente, cuando habla de "convención sobre configuración", todo el proceso de creación de una aplicación de Rails es más parecido a la configuración que a la programación.

Tuve esta extraña excepción hace un tiempo cuando seguí un ejemplo de Jruby on Rails (Ola Bini) ...

CreateProductCategories no pierde constante ProductType!

Esto sucedió porque las versiones de los rieles eran diferentes, pero el punto es ... todo está bien, hasta que te deslizas por el camino dorado, y la caja negra ya no te ayuda, y LUEGO te das cuenta de que no tienes idea de lo que estabas haciendo todo el tiempo y empiece a pedir ayuda en foros / listas de correo (y luego descubre que la mayoría de la gente no sabe lo que estaban haciendo o por qué, solo que funcionó).

De todos modos, es bueno saber que no estoy loco y que algunas personas se han enfrentado a este tipo de problemas. Gracias a todos.

PD: El inglés no es mi lenguaje natural, así que si encuentras errores gramaticales, edítalos.

Creo que es una cuestión de perspectiva. Desde una perspectiva amplia, la comunidad de Rails ha mantenido el marco como algo que es así de fácil. Pero la verdad es que no lo es. De hecho, cuanto más trabajo con Rails, menos fanboy me vuelvo. No creo que esto sea culpa de Rails, pero creo que mucha gente ha tenido la impresión de que escribir una aplicación Rails is de alguna manera es similar a agitar una varita mágica (y yo mismo he bebido ese kool-aid).

Sin embargo, Rails cumple muchas promesas, ya que proporciona una gran cantidad de funcionalidades que requieren poca o ninguna configuración. Cosas como ORM, las relaciones entre modelos y la validación son triviales de configurar, y dejan mucho más tiempo para cosas como la lógica de la aplicación de ajuste y el enfoque en el diseño. El código de Rails también es muy, muy fácil de volver a factorizar. Rails te permite hacer mucho con poco código.

Donde me siento frustrado es cuando quiero alejarme de lo común. Es posible que desee lograr "una funcionalidad X muy específica", pero no puedo averiguar por dónde empezar. Me parece que cuanto más profundo me meto en el marco, más escasa es la información. Partes de la API lamentablemente no están suficientemente documentadas. Esto me obliga a depender de complementos de terceros, algunos de los cuales no tienen documentación, y no están bien mantenidos. Estoy bastante atrapado con una publicación de blog que me dice que copie este código o ese código en mi aplicación, y las cosas simplemente funcionarán (afortunadamente, generalmente lo hacen).

Algunos de mis problemas pueden estar relacionados con la inexperiencia general (aún haciendo la transición de diseñador a programador), pero a menudo siento que mientras que Rails proporciona excelentes herramientas para construir sitios web, no proporciona, al menos en la superficie, grandes herramientas para construyendo otras herramientas. Tiene el potencial, pero realmente tienes que cavar profundo.

El problema con la convención sobre la configuración es que necesita conocer la convención. Al menos con un archivo de configuración, usted tiene algo que leer cuando comienza ... Una vez que conoce la convención, va mucho más rápido, pero tiene el obstáculo de aprendizaje con el que lidiar mientras tanto.

Me pareció muy fácil trabajar con Rails. Es posible que desee obtener Desarrollo web ágil con Rails . Fue una gran ayuda para mí aprender el "camino de Rails". Lo utilicé más como referencia que como tutorial, pero lo guiará en la creación de una aplicación y explicará lo que está sucediendo. FWIW, recogí Rails más rápido que ASP.NET (que aún estoy aprendiendo) y sabiendo que Rails tiene una gran ayuda en el aprendizaje de ASP.NET MVC.

Pablo es posible que desee examinar Django, que está siendo desarrollado por un grupo que ha elegido centrarse en proporcionar documentación de alta calidad como prioridad.

Tengo un poco de conocimiento sobre cómo funciona Internal Rings, y realmente espero que el trabajo que Katz está haciendo para Rails 3.0 haga que los rieles internos sean mucho más fáciles de entender, y especialmente mucho más documentados. AFAIK, ha estado creando algunas interfaces bien definidas entre los "módulos / capas", por ejemplo, todos los ORM comparten interfaces comunes, por lo que podrá no solo reemplazar el ORM, sino también comprender fácilmente la interfaz que comunica los raíles y el ORM

En contra de la opinión general, creo que los rieles son un marco muy difícil, mucho más que php puro. El relevo en un marco que no comprendes tiene alguna consecuencia, y aprender los componentes internos de los raíles no es fácil, incluso para los expertos en rubíes.

Por otro lado, el ecosistema de rieles se mueve extremadamente rápido, y eso agrega otra capa de dificultad. En el último mes agregué al menos 3 o 4 gemas y el mes antes de cambiar por completo mi flujo de trabajo agregando pepino a mi proceso. pero, supongo que ese es el precio que estoy pagando por estar en la industria de TI.

Estoy de acuerdo con Bryan M.

Mucha magia negra y cosas tenebrosas sucediendo, miles de líneas de código, programación meta-meta por todas partes.

Pero para ser justo, Rails me pareció tanto como el desarrollo basado en especificaciones, REST y buena comprensión de Ruby.

En este momento estoy en el punto en que el 20% del tiempo es fluido y el otro 80% gasto luchando contra las convenciones de Rails. Me siento mucho más productivo cuando escribo Ruby puro.

En algún momento, Merb parecía una opción, el próximo proyecto que iba con Rack / Sinatra y CouchDB.