Rails sucks?
Fede
Pablo Astigarraga
Nicolás Sanguinetti
> todos los que piensen que Rails sucks are welcome to drop a line
/me prepara pop
Angel Java Lopez
Bruno Deferrari
Q.E.D.
No te puedo decir porque no está bueno, hace mucho que no toco Rails,
pero en general no me gusta la mentalidad que tiene para resolver las
cosas, ni tampoco las capas sobre capas sobre capas, a mi me gustan
las abstracciones finitas que están bien pegaditas al suelo.
Creo que la parte que me gusta menos de Rails, y que seguro no ha
cambiado mucho es ActiveRecord, no me entra en la cabeza como la gente
lo usa existiendo una alternativa como Sequel.
Ah, y por último: ActiveSupport
2012/2/10 Angel Java Lopez <ajlop...@gmail.com>:
--
BD
Nicolás Sanguinetti
https://groups.google.com/forum/?fromgroups#!searchin/rubysur/from:mic...@soveran.com$20$2Brails
(aparentemente tenés que estar loggeado en google groups para que ese
link funcione, BTW)
Geronimo Diaz
pd: de esta lista de frameworks basados en ruby http://vemod.net/list-of-ruby-web-frameworks quizas alguien pueda recomendar alguna otra opcion.
H. Gerónimo Díaz.
RoR Developer
gtalk: geronimod
skype: geronimodiaz
jabber: gd...@jabber.belnet.be
twitter: @geronimodiaz
linkedIn: http://ar.linkedin.com/pub/geronimod
github: http://geronimod.github.com
Bruno Deferrari
> El 10/02/12 10:46, Nicolás Sanguinetti escribió:
>
> 2012/2/10 Angel Java Lopez <ajlop...@gmail.com>:
>
> O una lista de razones por aca en la lista?
>
> https://groups.google.com/forum/?fromgroups#!searchin/rubysur/from:mic...@soveran.com$20$2Brails
>
> (aparentemente tenés que estar loggeado en google groups para que ese
> link funcione, BTW)
>
> alguna recomendación sobre alternativas que no sean Merb y Sinatra ? es
> decir, obviamente dependera de "que" hay que desarrollar, pero quizas
> alguien con experiencia pueda recomendar por ejm Padrino por x causa.
>
Padrino = Rails disfrazado de Sinatra. Cualquier cosa que dependa de
ActiveSupport es casi como estar usando Rails.
> pd: de esta lista de frameworks basados en ruby
> http://vemod.net/list-of-ruby-web-frameworks quizas alguien pueda recomendar
> alguna otra opcion.
>
Dos que no están en esa lista:
Cuba: http://cuba.is/
Fiasco (es un work in progress): http://tizoc.github.com/fiasco/
> --
> H. Gerónimo Díaz.
> RoR Developer
>
> gtalk: geronimod
> skype: geronimodiaz
> jabber: gd...@jabber.belnet.be
>
> twitter: @geronimodiaz
> linkedIn: http://ar.linkedin.com/pub/geronimod
> github: http://geronimod.github.com
--
BD
Julio Napurí Carlos
Martens tiene un excelente framework publicado, llamado cuba [1] a lo
Sinatra. Pero vamos, que hay mucho para escoger. (Sinatra + DataMapper
por ejemplo)
He vuelto a usar Rails, desde la 3.1 en adelante, y me ha gustado
mucho más que la 2.x, pero concuerdo que ActiveRecord da dolores de
cabeza... si lo tuyo es algo pequeño y mucho CRUDs tal vez sea una
buena opción Rails.
[1] https://github.com/soveran/cuba
--
Twitter: http://twitter.com/#!/julionc
Github: https://github.com/julionc
Nicolás Sanguinetti
> Fiasco (es un fiasco): http://tizoc.github.com/fiasco/
FTFY
Instr. Dwayne Macgowan
Dwayne Macgowan Instructor del Método DeRose Para conocer el Método DeRose visitá: Blog de DeRose |
|
Instr. Dwayne Macgowan
Dwayne Macgowan Instructor del Método DeRose Para conocer el Método DeRose visitá: Blog de DeRose |
|
Paul Martens
Hola, ayer en el meetup algunos dijeron que Rails no estaba bueno, uso solo rails y no se muy bien que onda los otros frameworks. Me gustaria saber su punto de vista. todos los que piensen que Rails sucks are welcome to drop a line. Los de Rails rocks en otro thread.
Paul
Michel Martens
Yo comenté que ahora estoy más moderado. No porque me guste Rails, sino porque
reconozco que puede ser la herramienta adecuada para muchas personas.
La discusión que engloba esto tiene que ver con Frameworks vs Libraries. Voy a
copiar un párrafo de la introducción de "Software Tools" (Kernighan y Plauger,
1976):
"Whenever possible, we will build more complicated programs up from the
simpler; whenever possible we will avoid building at all, by finding new uses
for existing tools, singly or in combination. Our programs work together; their
cumulative effect is much greater than you could get from a similar collection
of programs that you couldn't easily connect. (...) Learning to think in terms
of tools will encourage you to write programs that solve only the unique parts
of your problem, then interface to existing programs to do the rest."
Ahí se puede leer entre líneas el motto "Write programs that do one thing and
do it well. Write programs to work together."
Cuba es una herramienta que estamos usando en Citrusbyte, similar a Sinatra.
Hace unos días, copié la lista de gemas que estamos usando en un proyecto:
an -v 0.0.1.rc1
cuba -v 2.2.1
mote -v 0.2.0
cutest -v 1.1.3
malone -v 0.0.2
capybara -v 1.1.2
spawn -v 0.1.4
faker -v 1.0.1
imagery -v 0.2.2
shield -v 0.1.0.rc1
pbkdf2 -v 0.1.0
cuba-contrib -v 0.1.0.rc2
nest -v 1.1.0
scrivener -v 0.0.3
sequel -v 3.31.0
sqlite3 -v 1.3.5
Si quisiéramos pasar esa aplicación a Sinatra, necesitaríamos cambiar una gema
y actualizar las rutas de la aplicación. En un proyecto mediano o grande, no
debería llevar más de un día. Esto es porque la función que cumple cada
herramienta está definida y delimitada.
El problema que tiene Rails, para mi gusto, es que no permite cambios de este
tipo. Si bien hay una intención de que cada vez sea más modular, en la
práctica esa modularidad se limita a la seleccion de ORMs, templating engines y
poco más. La interdependencia de sus componentes es enorme.
Por ejemplo, para el envío de mails estamos usando malone, que depende de
mailfactory, que a su vez depende de mime-types. Podríamos tranquilamente
reemplazarla por actionmailer, el equivalente que usa Rails. El problema es que
actionmailer depende, por un lado, de mail (que depende de i18n, mime-types y
treetop), y por otro de actionpack, que depende de activesupport, activemodel,
rack-cache, builder, rack, rack-test, journey, sprockets y erubis. Cada una de
estas gemas tiene dependencias. En total son 19 gemas las que se necesitan para
usar actionmailer. Creo que Rails instala 30 gemas.
Como actionmailer tiene tantas dependencias (y, por lo tanto, reutiliza código
de otras herramientas), uno esperaría que malone compensara con más líneas de
código. Sin embargo, malone tiene 86 LOC contra las 509 LOC de actionmailer.
Acerca del código de Rails: la costumbre de extender las clases built-in
conlleva problemas de compatibilidad entre distintas librerías. Por la forma en
que funciona el sistema de módulos de Ruby (no sé cómo llamarlo, es bastante
pobre como para ser llamado así), al extender una clase se invalida el caché de
llamadas de todos los objetos y las modificaciones son accessibles desde
cualquier otra librería. En parte es para resolver este tipo de problemas que
nacieron herramientas como Bundler o Isolate.
Lo de extender clases built-in para todo el mundo tiene que ver con la forma de
pensar en "frameworks" en vez de pensar en librerías. Lleva a desarrollar
plugins o gemas "para Rails", en vez de desarrollar librerías para Ruby.
Supongamos que se nos ocurre crear una gema llamada "abstract_controller". El
nombre de la gema está disponible: https://rubygems.org/gems/abstract_controller
Sin embargo:
$ gem install actionpack
$ irb
>> require "abstract_controller"
=> true
Esto pasa porque actionpack poluciona el load path, está mal armada la gema
(https://github.com/rails/rails/tree/master/actionpack/lib).
Entonces, además del tema framework vs librerías, está el tema de que Rails no
es un buen ciudadano. No respeta ciertas convenciones que permiten una
interacción sana entre distintas librerías.
Otro aspecto que no me gusta está detallado en los primeros slides de esta
presentación: http://files.soveran.com/simplicity/
En particular, las router me parece mal resuelto (más sobre esto:
http://peepcode.com/blog/2010/rethinking-rails-3-routes).
Hay otros problemas que podría mencionar, pero temo aburrir.
Saludos.
Sebastián Galkin
Una tonelada de sabiduría...
Para muchos, la mayoría de los puntos les hará correr un frío por la
espalda evocando el recuerdo de los sufrimientos pasados. Para los que
no hayan sufrido los problemas mencionados en carne propia, no pierdan
la oportunidad de repasarlos y entenderlos, y sobre todo, pensar un
poco sobre simplicidad y complejidad. Si cuando arrancás un proyecto
nuevo, usás un template que te instala 50 dependencias, pensá que
talvez no es la mejor forma.
--
Sebastián Galkin
@paraseba
Alvaro Olivencia
Sebastián Galkin
> Entonces yo me pregunto: que es más popular? rails, cuba o sinatra ?
PHP
--
Sebastián Galkin
@paraseba
Bruno Deferrari
> No soy experto en rails ni ruby. Creo que a la hora de decir si rails sucks
> o no también depende (aparte de lo técnico) del support/community que el
> framework tenga.
> Entonces yo me pregunto: que es más popular? rails, cuba o sinatra ?
>
Rails. Las masas siguen a las masas. Las masas no son muy inteligentes
tampoco. Lleva mucho tiempo y experiencia el poder elegir una
herramienta sabiendo ver más allá de lo superficial y de lo que dicen
otros.
PHP siempre fue extremadamente popular.
--
BD
Bruno Deferrari
> 2012/2/10 Alvaro Olivencia <alvaroo...@gmail.com>:
>> No soy experto en rails ni ruby. Creo que a la hora de decir si rails sucks
>> o no también depende (aparte de lo técnico) del support/community que el
>> framework tenga.
>> Entonces yo me pregunto: que es más popular? rails, cuba o sinatra ?
>>
>
> Rails. Las masas siguen a las masas. Las masas no son muy inteligentes
> tampoco. Lleva mucho tiempo y experiencia el poder elegir una
> herramienta sabiendo ver más allá de lo superficial y de lo que dicen
> otros.
>
> PHP siempre fue extremadamente popular.
>
Y antes de que me peleen, no estoy diciendo que alguien por usar Rails
o PHP o lo que sea tenga menos capacidad, solo me refiero a que en la
gran mayoría de los casos, cuando se elige una herramienta, ni esta ni
las alternativas fueron evaluadas con profundidad.
--
BD
Alejandro Caserez
Disculpen, yo estoy empezando y creo que por la documentacion en la web es conveniente empezar con rails. Ustedes opinan los mismo?
Nicolás Berger
>> Entonces yo me pregunto: que es más popular? rails, cuba o sinatra ?
>
> PHP
+1 Seba, te banco por tu ironía
+2 Michel, como dijo Seba, una tonelada de sabiduría, gracias!
Angel Java Lopez
Alvaro Olivencia
Enviado desde mi iPad
Nicolás Sanguinetti
> or la forma en
> que funciona el sistema de módulos de Ruby (no sé cómo llamarlo, es bastante
> pobre como para ser llamado así), al extender una clase se invalida el caché de
> llamadas de todos los objetos
Estoy bastante de acuerdo con la mayoría que decís, pero esto es meh.
O sea, Rails no extiende clases en "request time", las extiende en
"boot time". O sea que a menos que el programador sea bruto y esté
haciendo obj.extend Mod en el código que se ejecute dentro de cada
request, esto no debería significar una penalidad de performance.
(Ta, ayuda a la demora en bootear el framework, eso es cierto, pero en
realidad hay otras mil cagadas en rails que demoran eso, dudo que esa
sea la significativa).
Y ta, si el programador es bruto y hace eso lo va a hacer usando
rails, sinatra, cuba, merb, camping, o fiasco :)
-foca
Nicolás Sanguinetti
> 2012/2/10 Alvaro Olivencia <alvaroo...@gmail.com>:
>> No soy experto en rails ni ruby. Creo que a la hora de decir si rails sucks
>> o no también depende (aparte de lo técnico) del support/community que el
>> framework tenga.
>> Entonces yo me pregunto: que es más popular? rails, cuba o sinatra ?
>>
>
> Rails. Las masas siguen a las masas. Las masas no son muy inteligentes
> tampoco. Lleva mucho tiempo y experiencia el poder elegir una
> herramienta sabiendo ver más allá de lo superficial y de lo que dicen
> otros.
Un poco en relación a esto, mi experiencia personal
Tuve mi época de "Rails es una mierda". Use sinatra por mucho tiempo.
Hoy en día para cuando hago algo jugando no uso Rails, cuando hago
algo de trabajo, por lo general uso Rails.
Rails es mejor que otras cosas? Nah. Estoy bastante de acuerdo en todo
lo que dijo Michel. Rails es una mierda? Sí, pero mucho menos que
antes, lo cierto es que ha mejorado mucho.
Pero lo que veo es que, estando hoy en día en una consultoría, es que
el workflow es más o menos este:
* Cliente viene con nuevo clon de groupon que va a ser más grande que
groupon. (Antes fue en lugar de groupon era facebook, o youtube, o lo
que estuviera de moda, en realidad, no viene al caso).
* Nosotros le hacemos una versión inicial que lo ayuda a descubrir que
no va a ser más grande que groupon.
* El cliente se empeña en que va a seguir siendo más grande, pero no
se puede permitir los costos de una consultora, por lo que contrata
dos o tres programadores in house que van a mantener el código y
continuarlo hasta que la empresa fracase completamente.
El punto tres implica que, si yo elijo un stack "raro" (o mejor dicho,
"no común") seguramente me implique más tiempo explicarles a los
nuevos programadores cómo funciona todo.
Sí, podrían leer el código y tratar de entenderlo. Pero lo más posible
es que vengan a romperme las bolas a preguntarme cómo funciona algo
cada tanto.
* Si eso se lo cobrás al rate de la consultora, entonces el cliente no
va a quedar contento "el código que hicieron es una mierda que sólo
ellos entienden, te sale muy caro mantenerlos full time, y te sale
casi tan caro contratar a otra persona porque seguís dependiendo de
ellos, mejor no los contrates" le va a decir a sus
posibles-clientes-amigos con los que juega golf y comenta como su
groupon va a ser más grande que groupon.
* Si no le cobrás, para evitar lo anterior, entonces te sale carísimo a vos.
Rails? Mal o bien, está todo documentado, es "lo standard" (que no
quiere decir que sea lo mejor—siempre me gustó lo de "coma mierda,
trillones de moscas no pueden estar equivocadas"), y si trabajaste en
un proyecto rails, más allá de las sutilezas del proyecto, trabajaste
en todos.
Claramente todo lo que puse en este mail está bastante exagerado para
efecto dramático, tomenlo con un grano de sal :)
Pero lo cierto es que Rails *funciona*, es mucho menos mierda de lo
que era antes, y te simplifica traspasarle el proyecto a quien venga
después, eliminándote dolores de cabeza.
My ¢2
Ah, eso sí. ActiveSupport::Dependencies debería ser violado repetidas
veces y arder en una hoguera (no necesariamente en ese orden).
-foca
Paul Martens
(Ta, ayuda a la demora en bootear el framework, eso es cierto, pero enrealidad hay otras mil cagadas en rails que demoran eso, dudo que esa
sea la significativa).
Paul
Nicolás Sanguinetti
Eka
Hernan Fernandez
Matias B
pobres, más de estilo o forma, que de contenido. Sacando algunos
puntuales como ciertas taras de ActiveRecord. La realidad es que Rails
cubre perfectamente la mayoria de las demandas de aplicaciones medianas
y tiene una comunidad activa. Sinatra y Rack solo tienen sentido para
aplicaciones chicas. Yo trabaje con aplicaciones web que pensarlas en
Sinatra hubiesen sido un dolor de bolas increible. Rails 2 no era lo
mejor del mundo, pero era mejor que 1, como Rails 3 es mejor que 2, y
continua mejorando.
Me parece que el rails sucks guarda un poco de "es de las masas,
diferenciemonos para que no nos confundan" y tiene pocos fundamentos
reales.
Instr. Dwayne Macgowan
|
Dwayne Macgowan Instructor del Método DeRose
Para conocer el Método DeRose visitá:
Blog de DeRose |
|
Alvaro Olivencia
>
> Bueno pero eso es como decir "está mal hecho pero no le des bola, ni se siente, además hay males peores". Digamos que no es lo que me gustaría escuchar de alguien que me está queriendo vender su producto.
En mi experiencia, sea la tecnologia que sea, en general, al cliente no le interesa mucho que tan prolija o modular es la tecnologia/lenguaje/framework, sino que funcione bien (para el usuario final), sea razonablemente performante y que se desarrolle rapido.
Bruno Deferrari
> el fenomeno:
>
Yo si te lo afirmo. No es solo en programación, es en cualquier
contexto, elegí música, política, o lo que se te antoje. La mayoría
sigue a la mayoría, en cualquier contexto los "expertos" (y con eso me
refiero a gente con experiencia variada suficiente, no necesariamente
genios ni nada que se le parezca) son una minoría.
Esto no quiere decir que las cosas que elige la mayoría sean malas,
solo que no porque la mayoría las elija son buenas, porque la mayoría
no elige haciendo un análisis técnico ni en base a la experiencia.
> - Hay gente que tiene que hacer cosas
> - No tiene todo el tiempo para analizar y elegir la mejor forma
> - Tambien puede ser lo bastante inteligente para decir: "Aunque analice, mi
> conclusion no es segura"
> - Decide que es mejor seguir un camino donde hay una comunidad activa
> - Con eso cumple con el time to market
> - Cuando crece, tiene muchos desarrolladores que conocen Rails
> - Y con eso se forma una empresa y se compra una casa en el country :-)
>
Y eso que decís no contradice en nada a lo que dije, es de nuevo lo
mismo, la mayoría sigue a la mayoría. Es pensar en no tener que pensar
las cosas.
> Es todo cuestion de como uno decide. Entonces, hay dos clases:
>
> - Veo que mucha gente sigue los pasos de arriba
> - Habra gente que elige Rails por que es lo mas popular, sin pensar en
> ninguna de las razones de arriba
>
> Lo que hay que ver, es cuanto porcentaje hay de personas en cada clase.
>
> Un punto a favor de PHP: no es opinionated, como Rails. Con lo que te deja
> elegir el camino a seguir, construyendo, a baby steps, lo que quieras. Podes
> comenzar simple, y luego adoptar o no un framework, o implementar un patron.
> Tiene sus limitaciones, pero hay que reconocer que hay parva de sitios en
> PHP.
>
> No se, gran parte de Facebook esta o nacio en PHP... sera gente no muy
> inteligente? Con la IPO que viene, parece que son mas piolas que todos
> nosotros :-)
>
Facebook fué hecho por un grupo de individuos, no por la comunidad de
PHP. Esto sin entrar en la parte en que Facebook usa un montón de
tecnologías, varias inventadas por ellos mismos (de entre estas, su
propio compilador de su propia versión de PHP).
--
BD
Bruno Deferrari
> Muy interesante thread. Soy nuevo en Ruby, vengo de Python y me pasa mas o
> menos lo mismo con Django, muy acoplado, y Flask se parece a Sinatra.
>
En el Rubylandia creo que es es la comparación que podés hacer. Rails
es Django, y Sinatra es Flask (Fiasco se parece mucho más a Flask
porque está inspirado en Flask, pero para que tengas una idea, porque
Rails y Django no se parecen en casi nada tampoco).
Si tenés experiencia tanto con Django como Flask, te habrás dado
cuenta de que Django decide un montón de cosas por vos (a pesar de que
puedas cambiar vos esas desiciones, aunque cueste), mientras que en
Flask tenés bastante más libertad, y empezás con menos peso encima. Si
querés estudiar la implementación de Flask el código es más compacto y
fácil de seguir también.
En Django tenés una comunidad más grande, porque es el framework web
de-facto de Pythonlandia, pero si te ponés a usar Flask, o Bottle, o
Pyramid te vas a dar cuenta de que soporte vas a conseguir igual (y
hasta mejor, porque hay más concentración de gente experiente y capaz
de ayudarte). En el caso de Ruby es parecido (solo que en general la
documentación es más pobre a nivel general, una de las razones por las
cuales prefiero trabajar con Python).
Rails es como Django, decide un montón de cosas por vos, podés
buscarle la vuelta y cambiar cosas, pero en si estás viviendo dentro
de lo que Rails ya decidió. No tener que decidir te va a ahorrar
tiempo, y en muchos proyectos esas deciciones son detalles que en
realidad no importan. Por otro lado, las deciciones genéricas que
tratan de abarcar tanto como puedan, rara ves (por no decir nunca) son
óptimas, ni mucho menos.
Al elegir Rails o Django estás adoptando un framework, esto te da el
piso, las paredes y el techo (que lo podés tirar abajo, pero para que
tenerlo en primer lugar entonces?), al agarrar algo como Flask, Cuba,
Sinatra, etc te estás armando tu propio toolkit, tenés un piso, pero
en el paquete no te viene el techo. Vas a tener que tomar más
deciciones, lo cual es más dificil al principio, y no siempre val la
pena, pero una ves que ya estás familiarizado con las alternativas que
tenés a la mano, vas a poder lograr un resultado mucho mejor, y vas a
tener un entendimiento mucho mayor de los tradeoffs que hay en el
conjuto de herramientas que elegiste.
Btw, yo también vengo de Python, y desde el comienzo me di cuenta de
que prefería las soluciones que me provee Python a las que me provee
Ruby, y en 4 años de seguir ganando experiencia (con ambos) mi opinión
no ha cambiado (tanto porque me gusta más el lenguaje, como se maneja
la comunidad, la documentación, la librería estandard y las librerías
3rd party). Pero la realidad es que hoy x hoy para nosotros los
sudacas, Ruby paga mejor.
> La pregunta es: En que caso puntual (o ejemplo de caso) conviene usar RoR?
> Porque vi por ahi que dicen que en algunos casos conviene.
>
> Gracias y Saludos
>
> E
--
BD
Angel Java Lopez
Bueno, disculpen lo largo del email.... tiempo de ir a comprar las cervezas de hoy!
Bruno Deferrari
> mucho en elegir algo o no. Por eso no calificaria de "masa" a los que
> deciden.
>
No voy a responder todo ahora porque tu mail es tremendo WALL OF TEXT
que no puedo procesar ahora, solo quiero responder un par de puntos.
Primero: Justamente la masa no "decide" (o decide "no decidir" o
decide "usar lo que usan todos", a lo que me refiero es que no decide
evaluando con profundidad), está siguiendo lo que ya decidieron otros.
> Y, si, lo que digo en los puntos, por lo menos es distinto de "las masas no
> son muy inteligentes".
Las masas no son lo mismo que los individuos que las integran. Cuando
digo que las masas no son inteligentes me refiero a que no hubo
inteligencia de la masa en si para llegar a las conclusiones de que
tal y tal herramienta es mejor, simplemente se siguió casi que
ciegamente al resto.
Bajo esta definición de "inteligencia" del diccionario (http://rae.es):
3. f. Conocimiento, comprensión, acto de entender.
En la elección de dicha masa no hubo un acto de conocer las
alternativas, comprender los tradeoffs, ni entender porque algo es
"mejor". Para este caso en particular, seguro hay varios individuos
que integran esa "masa que elige Rails por sobre las alternativas" que
se tomó el trabajo de estudiar y entender las cosas y decidió que
Rails era lo que le servía mejor, pero no es el caso para la mayoría
de los individuos que integran esa masa. Se entiende mi punto?
En fin, solo quería aclarar esto porque veo que no quedó claro,
después leo el resto.
--
BD
Carlos Aguilar
> BD
>
--
Carlos Aguilar
Consultor Hardware y Software
DWD&Solutions
http://www.dwdandsolutions.com
Bruno Deferrari
La mierda es la comida apropiada para las moscas. Para nosotros son
desechos, pero todavía tiene nutrientes que son muy útiles para las
moscas. El olor también le ayuda a las moscas a encontrar la comida
fácil, lo mismo pasa con la basura, y flores como esta que huele a
carne podrida y mierda para atraer moscas:
http://news.nationalgeographic.com/news/2012/02/120208-corpse-flower-penis-species-madagascar-plants-science
Igual las moscas no "deciden" comer mierda, evolucionaron así en
muchísimo tiempo, y es como están programadas a funcionar, y es a lo
que está adaptado su organismo.
http://en.wikipedia.org/wiki/Hype_cycle
Node.js es un ejemplo de seguir el Hype (como lo fue Rails hace años).
Hay un montón de usuarios de Node.js que lo usan siendo concientes de
los tradeoffs, pero la mayoría solo está siguiendo el Hype, o porque
siempre hicieron Javascript y vieron a Node.js como una salida de eso
en la cual no tenían que aprender un lenguaje nuevo. No hay un
análisis de como y porque node.js funciona como funciona, ni de cuales
son las alternativas.
También creen que Node.js inventó algo nuevo (no es, Node.js es una
idea muy vieja implementada arriba de algo "nuevo" que es V8), y que
ese algo nuevo es una panacea (a pesar de que no funcionó en el
pasado) y que resuelve todo. No quiere decir que no sea apto para
ciertas cosas, lo es.
Es muy probable que en varios años siga existiendo, y sea una
herramienta bastante estandard y robusta (no va a ser la mejor, pero
va a ser decente). Es la historia de Ruby. Mirá a Ruby hace 10 años,
hace 5, y hoy. No es ni ahí el mejor stack que hay en la vuelta para
web, pero se defiende muy bien, y llegó a ser así a la fuerza (mucha
gente lo quería usar, y de peor o mejor manera fue resolviendo los
problemas que habían que le limitaban su uso en la práctica).
Antes de que Zed Shaw lanzara Mongrel tratar de hacer algo en serio
era un chiste, y esto pasó recién en el 2006. Poco después (alrededor
del 2007 creo) apareció Rack (basándose en WSGI de Python que es del
2003 si mal no recuerdo).
--
BD
Bruno Deferrari
> Creo que un resumen breve seria que cada uno usa lo que mejor conoce, le
> funciona y le hacen la vida más fácil. Yo he desarrollado en varios
> frameworks php, me pase a Python + django y estoy tratando de aprender ruby
> y siempre trato de usar en mis desarrollos la que considero mejor
> herramienta para que yo pueda realizar el trabajo.
>
Hacerse la vida fácil es la idea. Pero para poder hacer eso bien hay
que aprender, pero aprender duele y te hace salirte de tu zona de
comfort ("NO PAIN, NO GAIN!!!" debe ser una de las frases chiclé más
ciertas que existe).
Al momento de empezar a armar algo, las herramientas con las que ya
tengas bastante familiaridad siempre van a tener ventaja por sobre las
cuales no te son familiares. Estas herramientas que ya conocés las vas
a poder seguir aprendiendo mejor y mejor, hasta es posible que con tu
experiencia las puedas mejorar. Por otro lado estás limitado a lo que
la herramienta es de por si, y una herramienta alternativa, siendo
manejada con el mismo nivel de familiaridad que manejás la actual te
puede resultar mucho mejor, pero al principio te va a doler.
Es posible que la aprendas y te resulte que la herramienta que ya
conocías era más apta. Igual no perdiste el tiempo, seguro de esta
herramienta nueva aprendiste cosas nuevas, que podés aplicar, o que
podés usar para poder juzgar más rápido otras herramientas que mires
en el futuro (porque expandiste tu mapa, ahora tenés territorios ya
explorados que antes no tenías).
Suponete que viendo este thread decís, "bueno, Rails es una cagada, ni
me gasto en aprenderlo". Te conviene aprenderlo igual, en parte porque
capaz que NO es una cagada, pero más importante para poder comparar
con las alternativas y sentir en carne propia que cosas tiene que son
una cagada y cuales no (yo detesto Chef, aún así lo estoy tratando, se
que no lo voy a volver a tocar ni con un palo en el futuro, pero en
este momento me sirve como ejercicio).
Respecto a hacerse la vida fácil: http://www.lambdassociates.org/Blog/code.htm
--
BD
Ary Borenszweig
Another way to qualify columns is to use the qualify method:
items.literal(:price.qualify(:items)) # items.price
Bruno Deferrari
> De la documentación de Sequel:
>
> http://sequel.rubyforge.org/rdoc/files/README_rdoc.html
>
> Another way to qualify columns is to use the qualify method:
>
> items.literal(:price.qualify(:items))
> # items.price
>
> Umm... le agregaron el método qualify a Symbol?
>
Si. Y hay una opción para desactivar esto (ya sea con la constante
SEQUEL_NO_CORE_EXTENSIONS o con una variable de entorno del mismo
nombre). En cuyo caso usás la sintaxis más nueva de bloques que tiene
Sequel desde hace rato ya.
Ahora, aunque no lo hubiera, realmente te parece que esto está al
mismo nivel de lo que hace ActiveSupport ?
--
BD
Michel Martens
> De la documentación de Sequel:
>
> http://sequel.rubyforge.org/rdoc/files/README_rdoc.html
>
> Another way to qualify columns is to use the qualify method:
>
> items.literal(:price.qualify(:items))
> # items.price
>
> Umm... le agregaron el método qualify a Symbol?
>
> Y ustedes hablan de no tocar las clases built-in... :-P
Y esa es la gran crítica que le hago a Sequel, aunque brinden la
opción de no extender Symbol.
>
> Yo creo que está perfecto extender las clases. Después tenés que hacer
> foo.bar y no algo horrible como Utils.bar(foo), donde tenés que aprender
> primero dónde se encuentra "bar".
Sin dudas hay casos donde tiene sentido. No me parece el caso de los
símbolos de Sequel, ni del Array#forty_two.
A vos sí te parece buena idea Array#forty_two?
>
> Creo que en definitiva la discusión se resume a: cada uno usa lo que el
> resulta más cómodo. Si te resulta más cómodo en cada proyecto volver a
> escribir de cero la configuración de conexión a la base de datos, pensar
> cómo organizar el código y demás, usá Sinatra. Si no, usá Rails.
Es medio ingenuo pensar que alguien que trabaja desde hace años con
Sinatra reescribe la configuración de conexión a la base de datos o la
estructura de directorios al comenzar cada proyecto.
> En mi laburo venimos usando Rails hace tiempo y jamás nos defraudó (incluso
> para aplicaciones no típicas, como un servicio de mensajería y algo parecido
> a Twilio). Una vez que aprendés las convenciones vas a las chapas
Creo que se puede argumentar lo mismo para otras herramientas. Pero
eso no significa que hayan alcanzado un ideal de perfección, porque lo
único que se está afirmando es que el usuario está conforme y que
adquirió cierto grado de dominio.