2010/1/25 Nicolás Sanguinetti <[email protected]>: > Meh, todo apesta. > > Che, Gabriel: en serio te parece que alguien comente sobre django es > tratar de empezar un flame? Really? Sobre todo si lo comenta > educadamente? "Tenés miedo de que te demuestre como django encara y > todos tus frameworkcitos en ruby son una pija, totalmente inútiles?" > sería más un intento de flame q(ojo, es un ejemplo de flame, no te > enrosques ;)). El mail de Juan Pedro me parece perfecto, y un aporte a > la discusión (a diferencia del tuyo, que no dice nada relevante ;)). O > de este, que tampoco dice nada relevante :P
Ah, y en serio, Ramaze? No, en serio? mirá que por lo menos podés agarrarte de algo menos inutil, eh? pd: por si tu fallido detector de flames no se da cuenta, este sí es un intento de flame. Ignoralo. > Discutir sobre las cosas buenas de otros lenguajes no me parece mal. > Au contraire, todos podemos aprender un montón de python y de django. > > -foca > > 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. >> >>>>> >>>>> 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. >> >>> 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. >> >>>> >>>>> 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. >> >>> >>> 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. >> >>> >>> 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. >> >>> >>> 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)? >> >>>>> 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 ;) >> >>>> >>>>> 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. >> >>> 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. >> >>>>> >>>>> 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. >> >> -- >> Leandro Marcucci. >> http://twitter.com/leanucci >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> > _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
