2010/1/25 Michel Martens <[email protected]>: > 2010/1/25 Leandro Marcucci <[email protected]>: >> 2010/1/25 Michel Martens <[email protected]>: >>> 2010/1/24 Leandro Marcucci <[email protected]>: >>>> 2010/1/24 Michel Martens <[email protected]>: >>>>> 2010/1/24 Federico Brubacher <[email protected]>: >>>>>> Michel creo q ahi entramos en un tema de gustos : >>>>>> hay mucha gente creo (aunque no es 100% mi caso ni cerca, es mas cada >>>>>> vez me gusta mas ruby y menos las dsl) que le gustan las DSL locas y >>>>>> la magia de ActiveSupport y no se cuantas cosas mas. >>>>>> >>>>>> Creo que Rails 3 esta prolijo, si bien obviamente viene con "batteries >>>>>> included" para hacer la transicion de los usuarios de 2.3 mas facil, >>>>>> uno puede por ejemplo : elegir que partes de ActiveSupport usar, que >>>>>> partes de ActionController usar, el router esta mejorado (cada ruta es >>>>>> un rack endpoint y solo dsp de q pasa por Rack Realities creo se fija >>>>>> como le "pega" a un controlador. En fin son varias razones por la cual >>>>>> Rails 3 esta mejor . >>>>> >>>>> Lo de las DLSs supérfluas está ejemplificado acá: >>>>> http://blog.citrusbyte.com/2009/12/15/superfluous-dsls/ >>>>> >>>>> Con mapeo innecesario me refiero más que nada a las RESTful routes. Es >>>>> posible crear un website RESTful con Rails, Sinatra, PHP, Java, HTML >>>>> pelado, siempre y cuando se honren las convenciones REST. Con esto >>>>> quiero decir que no hace falta poner map.resources :photos o resources >>>>> :photos, hay otras maneras. >>>>> >>>>> En Rails 3: >>>>> resources :posts >>>>> >>>>> Esto genera las siguientes rutas: >>>>> >>>>> # GET /photos >>>>> def index; ... end >>>>> >>>>> # GET /photos/new >>>>> def new; ... end >>>>> >>>>> # POST /photos >>>>> def create; ... end >>>>> >>>>> # GET /photos/1 >>>>> def show; ... end >>>>> >>>>> # GET /photos/1/edit >>>>> def edit; ... end >>>>> >>>>> # PUT /photos/1 >>>>> def update; ... end >>>>> >>>>> # DELETE /photos/1 >>>>> def destroy; ... end >>>>> >>>>> Si sólo se quiere exponer GET /photos/1, hay que poner map.resources >>>>> :photos, :only => :show. >>>>> >>>>> El gusto por las DSLs puede ser legítimo. Lo que es dudoso es el gusto >>>>> por las DSLs innecesarias. En este caso, el "resources" de Rails está >>>>> generando código para mapear URLs a métodos en un controller, cuando >>>>> Sinatra demostró que es un paso innecesario. La mera existencia del >>>>> comentario antes de cada método --cada "action"-- es indicador de que >>>>> la abstracción es, como mínimo, imperfecta. El efecto colateral de que >>>>> olvidar un :only o un :except implique que un website exponga deletes >>>>> y updates de forma insegura, es indicador de una leaky abstraction. >>>> >>>> Estoy de acuerdo con el argumento, no con la conclusion. No me parece >>>> una abstracion defectuosa. Si usas mal el framework, seguramente el >>>> resultado sera desagradable. >>> >>> Te invito a justificar esa abstracción. Tratá de demostrar por qué ese >>> mapeo es relevante. >>> >> >> Es facil: si querés exponer sólo un método de los siete que define >> REST (index, new, create, edit, update, show, destroy), y usas el >> método resources, estas haciendo, a mi entender, dos cosas mal: la >> primera es usar el metodo que permite que tu aplicacion responda a los >> 7 cuando solo queres usar uno solo; la segunda es ignorar que rails te >> da un metodo para declara una ruta puntual para un recurso. En ningun >> caso veo defecto del framework, es todo error de capa 8. > > Sí, estamos de acuerdo en que es error del usuario. Lo que intento > decir es que hay lugar para que el usuario se equivoque (si olvida > agregar el :only o el :except), y que con Sinatra, como no existe ese > mapeo entre recursos y métodos no hay lugar a esa equivocación. >
El error humano no me parece un argumento muy solido para declarar inconveniente el dsl. Y ojo, quiero que se entienda algo: estoy de acuerdo con los principios que utilizas para evaluar Rails, pero los razonamientos no me parecen correctos. Si el usuario quiere exponer un solo metodo, y no lo hace, la culpa no es del framework por ser flexible. >> >>>>> >>>>> El equivalente con Sinatra: >>>>> >>>>> get "/photos" do ... end >>>>> get "/photos/new" do ... end >>>>> post "/photos" do ... end >>>>> get "/photos/:id" do ... end >>>>> get "/photos/:id/edit" do ... end >>>>> put "/photos/:id" do ... end >>>>> delete "/photos/:id" do ... end >>>>> >>>>> En primer lugar, el comentario cuasi imprescindible de Rails es ahora >>>>> irrelevante. >>>> >>>> ¿? >>> >>> Rails inserta este comentario: >>> # GET /photos :id >>> >> >> Falso, lo inserta el generador de scaffolds. Rails no toca tu codigo >> en absoluto. > > Bueno, lo inserta el generador de scaffolds de Rails. De todas > maneras, el punto es que ese comentario es útil para saber cuál es la > tarea de ese método. > >>> Digo que al usar Sinatra, no hace falta generar ese comentario porque >>> la definición del entry point es más que explícita: >>> >>> get "/photos/:id" >>> >> >> En rails tambien. Convencion sobre configuracion. Si tenes un def >> create end en tu controlador, o bien algo en routes declara que tu >> aplicacion respondera al post para ese controlador, o esta mal >> testeada, o es codigo basura. > > Claro, mi punto es que hay una indirección innecesaria. Necesitás que > haya una ruta declarada y un def create; end declarado para que > funcione. Si borrás uno de los dos, ya no funciona, porque la ruta > está mapeada a ese def create. Mi planteo es que no hace falta mapear > una ruta a un método, porque podés hacerlo con un bloque como hace > Sinatra. > No creo que por hacer las cosas de forma diferente, alguno sea mejor que otro. >>>> >>>>> En segundo lugar, la posibilidad de exponer por accidente >>>>> algún método es casi inexistente. >>>> >>>> Claro, no podes exponer nada que no escribiste. Con rails no necesitas >>>> escribirlo, y la mayoria de las veces vas a querer exponerlo, he aqui >>>> la ventaja de lo que ofrece Rails. (ojo, una cosa es una cosa y otra >>>> cosa es otra cosa: el resultado bueno a cualquier precio no es >>>> correcto, podria estar bien hecho). >>> >>> No veo la ventaja. Hablás del generador de código? >> >> No. Del generador de codigo no hablo nunca. > > OK. Decís que "con rails no necesitas escribirlo, y la mayoria de las > veces vas a querer exponerlo, he aqui la ventaja de lo que ofrece > Rails", y creo que la clave es "la mayoría de las veces vas a querer > exponerlo". La minoría de las veces se trata del error/accidente que > describo. > Claro, pero bueno, no se puede tener en cuenta todos los casos de uso al mismo tiempo. Sin embargo, Rails ofrece simpleza para el uso mas comun (exponer los 7 metodos) y para los casos especiales, te da herramientas especiales. >>> >>> Supongamos el caso de DELETE /photos/:id >>> >>> Con Sinatra: >>> >>> delete "/photos/:id" do ... end >> >> Incompleto. >> >> Con Sinatra: >> >> delete "/photos/:id" do ... end >> delete "/foos/:id" do ... end >> delete "/bars/:id" do ... end >> >> y asi para cada recurso de tu aplicacion que pueda ser borrado. >> >> Con Rails: >> >> resources :photos, :foos, :bars >> >> Y el verbo http no lo escribo nunca, porque ya lo conozco. >> >> Claro, estoy corriendo un framework varios ordenes mas extenso en >> lineas de codigo. > > Pero con lo de resources :photos, :foos, :bars todavía te falta > escribir los métodos en el controller: def destroy; end, def destroy; > end, def destroy; end. Por eso digo que es más código. > Pero es menos! Escribis una linea en el routes, y te evitas escribir la palabra get 4 veces en lugares obvios, un put, un post y un delete... es menos codigo! >>> >>> Con Rails: >>> >>> resources :photos >>> def destroy; ... end >>> >>> En la versión de Rails hay más código, no? El hecho de que no >>> necesites escribirlo por haberlo generado con un scaffold creo que es >>> irrelevante, porque hay generadores de código para cualquier >>> framework. >> >> De nuevo, no. Si estoy programando REST, el verbo http de cada accion >> es inamovible (¿?), y salvo que maneje un solo recurso en mi >> aplicacion, los repito en cada "controller" de forma innecesaria. > > Acá me perdí :-( > Qué es lo que repetís en cada controller de forma innecesaria? > El nombre del verbo http, que, aunque no lo repitieras, es obvio para cualquier aplicacion REST. >>> >>> Cuando hablaba de métodos expuestos por error me refería a lo >>> siguiente: supongamos que tenés un método def edit; ... end, con su >>> correspondiente vista. Al borrar el método del controller, la vista >>> sigue siendo accesible. >>> >> Claro, eso es como estacionar el auto y dejarlo abierto. Si te afanan >> vas a culpar al fabricante de la alarma (o a la alarma misma)? > > Un programador se cruza con esto: > > def edit > end > > Tiene pinta de ser código que se puede borrar. Si el programador lo > borra, corre los tests y todo pasa, se puede quedar tranquilo porque > sabe que borró código irrelevante. Lo que hace Rails es renderear la > vista de todas maneras. Otra vez. Entiendo lo que tratas de decir, pero lo escrito apunta a otra cosa. Si borras codigo y los tests pasan, es error de los tests, o, en este caso, si tu accion no hace nada, no necesitas escribirla. Y si tenes dudas si un controlador x expone o no un metodo que no esta explicitamente escrito, podes ir a un unico archivo (el routes) y ver lo referente a ese recurso. Donde me parece que Rails falla es en no tener un modo de eliminar vistas que nunca van a ser rendereadas en caso que existan. > > Lo que debería hacer el programador responsable es revisar si no hay > una vista para ese método y también borrarla. Revisar si no hay una > ruta y también borrarla. Si no borra todo, está dejando el auto > abierto, según tus palabras. Si le afanan el auto, probablemente sea > su culpa. Lo que digo es que Rails deja ese margen para el error. Si > no hiciera el render automático, me estaría quejando de otros > problemas pero no de este, ahora se entiende? > Si, se entiende. Me sigue pareciendo ventajoso en algunos casos, pero deberia conocer un poco mas de Sinatra antes de dar la opinion completa. >>>>> En tercer lugar, la cantidad de >>>>> memoria y ciclos de CPU es ridículamente menor. >>>> >>>> En C es mucho menor que en ruby, habria que hacer sitios web en C. >>> >>> Es en serio este comentario? >>> >> >> El tenor es el mismo que el del comentario al que hace referencia ;) > > Lo que pasa es que hablo de dos soluciones al mismo problema y en el > mismo lenguaje. Si sale Rails 3.1, que hace exactamente lo mismo que > Rails 3.0 pero con menos ciclos de CPU, no te parece una mejora > interesante? > Si, pero bajar ciclos de CPU no viene a cualquier precio, y las opciones son pocas: o le sacas features, o haces un buen refactor. No puedo hacer por ahora ninguna de las dos, y el costo de CPU me da ventajas que me encantan. Win-win. >>>> >>>>> En cuarto, la cantidad >>>>> de ciclos cerebrales (para seguirle la corriente al mapeo de Rails) es >>>>> reducida a cero. >>>> >>>> Siempre me molesto muchisimo lo dificil de seguir que es el trace de >>>> cualquier cosa que haga rails. + 1 a la no simplicidad. >>>> >>>>> Si lo que Rails ofrece es un atajo para generar >>>>> websites restful, por qué razón con Sinatra obtengo un mejor resultado >>>>> tipeando menos? >>>> >>>> El resultado no es necesariamente mejor siempre, ni peor siempre. >>>> Tampoco estas tipeando menos. Es mas, estas tipeando de mas. Salvo que >>>> quieras programar REST mal, siempre vas a tener el mismo verbo http >>>> antes de la misma accion/ruta. Estas tipeando --muchisimas-- mas cosas >>>> obvias que el comentario de rails, que solo es escrito por el >>>> generador de scaffold (dejo lugar a que en rails 3 estos comentarios >>>> sean necesarios, pero lo dudo mucho). >>> >>> De nuevo creo que estás confundiendo cantidad de código con quién lo >>> genera. No importa que lo generes con un scaffold, >> >> Si, si importa. Los scaffolds no sirven para casi nada, y no me parece >> que el codigo que generan sirva para juzgar a Rails (tampoco me gusta >> el blog en 15 minutos, apesta). Escribiendo delete por cada recurso, >> tengo chances de escribirlo como el tujes y tener un error por eso. Y >> estoy inflando de codigo poco informativo mi aplicacion. > > Hmm... lo de escribir algo mal es fácil de detectar en Sinatra, no > tanto así en Rails. Va un ejemplo: > > def edti > redirect_to ... > end > > Silenciosamente va a seguir rendereando la vista de edit. En cambio, > si en Sinatra ponés deltee "foo", salta un error. > > Con respecto a lo de código poco informativo: > > resources :photos + def destroy; end > vs > delete "/photos/:id > > Si las opciones son esas, me parece que lo de abajo es más > informativo, estás de acuerdo? > Esta mas completo lo de abajo, sin dudas. >>> porque lo mismo >>> aplica para cualquier framework. Lo importante es que hay mayor >>> cantidad de código en la versión de Rails que en la de Sinatra. >>> >> >> Estoy de acuerdo con los principios de la apreciacion, pero la >> conclusion es falsa. El desarrollador debe escribir menos codigo en >> Rails que en Sinatra, con todos los riesgos que eso reduce. > > Ejemplo? > Relei y mi apreciacion inicial me parece trivial ahora. Puede que sean mas caracteres (tampoco estoy seguro de esto) en Sinatra, puntualmente hablando de el modo de escribir a que acciones responde la aplicacion, sin embargo es una alternativa muy valida al dsl de Rails. >>>>> >>>>> En Rails 3 es más sencillo integrar middlewares de Rack. Incluso es >>>>> sencillo integrar aplicaciones de Sinatra como midlewares de Rack. >>>>> Para qué me tomaría el trabajo de armar algo con Rails, incurrir en >>>>> los costos (mentales y otros) que describí, para poder "bajar" a >>>>> "metal" e insertar aplicaciones de Sinatra, cuando puedo escribirlas >>>>> directamente y obtener algo mejor, que ocupa una fracción del RAM y se >>>>> ejecuta mucho más rápido? Cuál es la ganancia? >>>>> >>>>> Saludos, >>>>> >>>>> -- >>>>> Michel >>>>> _______________________________________________ >>>>> Ruby mailing list >>>>> [email protected] >>>>> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >>>>> >>>> >>>> Como dicen por ahi, la mejor herramienta para cada caso. Rails es una >>>> buena herramienta para desarrollar sitios web seguros, con codigo >>>> elegante corriendo "sobre" él, así como lo es Sinatra, y cualquier >>>> otro. Simplemente cada uno sirve para solucionar problemas diferentes. >>> >>> No lo veo así, creo que ambas herramientas apuntan a solucionar el >>> mismo problema. Por qué creés que sirven para solucionar problemas >>> diferentes? >>> >> >> Porque los dos son "enlatados", y estan desarrollados con principios >> diferentes, para ser de utilidad a mucha gente. Yo estoy tomando en >> cuenta como aporta cada uno a facilitar trabajos especificos, y Rails >> me parece mas flexible. Tiene defectos, la mayoria ocasionados por ese >> afan de ser lo mas cercano al todo para casi todos (curiosamente en >> Getting Real DHH postula lo opuesto: no podes ser todo para todos). >> >> No creo que uno sea mejor que el otro objetivamente, pero si creo que >> subjetivamente tienen cosas diferentes para ofrecer, lo que los hace >> mejor herramienta para casos especificos. Pago ciclos de procesador y >> uso de memoria para no programar todo en assembler, por eso uso ruby. >> Tambien los pago para no redesarrollar cosas que rails trae >> solucionadas de entrada. Rails no es perfecto. Lastima. Sigue >> mejorando todos los dias, gracias a los colaboradores. >> > > Usaste Sinatra? No lo use mucho pero lei algunas aplicaciones hechas en él y me senti libre de las convenciones de Rails. Me parece que Sinatra precisa un esfuerzo de coordinacion superior al de Rails para definir la forma de solucionar problemas comunes que en rails fueron abstraidos con activesupport principalmente, por lo que soy esceptico a si es mas practico en proyectos grandes (tanto en cantidad de features como en cantidad de personas en el equipo de trabajo). Igual, como dije antes, no tengo experiencia suficiente en su uso como para estar 100% seguro de esto. Me gustaria aclarar que Sinatra me parece un framework espectacular (al menos lo poco que vi), y que no creo que invalide a otros frameworks, simplemente aporta un enfoque mas al desarrollo de aplicaciones, pero algunos puntos de tu mail me parecieron debatibles, asique aca estamos. Abrazo. -- Leandro Marcucci. http://twitter.com/leanucci _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
