Que le falta a Rails

El año pasado en la “Conferencia Rails” comenté que a Rails le faltaba
una manera sencilla para hacer los deployments, eso se comentó al
hablar de Django en la mesa redonda sobre frameworks. Este año ha
aparecido Phusion Passenger (mod_rails) y ya no tenemos ese problema.

Por otra parte, una cosa que yo echaba mucho de menos en Rails era un
sistema como el de Django para generar interficies administrativas de
una manera rà pida. Django lo tenia, Rails supongo que tambien …
Durante este año han aparecido varias y yo poco a poco he ido
mejorando la mia (http://github.com/fesplugas/typus) y ya está en
producción en varios proyectos, mios y de otras empresas que incluso
han mandado sus sugerencias y parches.

Tenemos por ejemplo una alternativa a attachment_fu, que es Paperclip.
Han aparecido cientos de plugins más … entre los que podriamos
destacar shoulda. Rails 2.2 está a la vuelta de la esquina … con sus
threads, l10n y i18n.

Así que mi pregunta, es … que creeis que le falta a Rails?

que escale :slight_smile:
na es
coña
le falta que los plugins sean gemas

El 09/09/2008, a las 14:30, Francesc E.
escribió:

El año pasado en la “Conferencia Rails” comenté que a Rails le faltaba

2008/9/9 Marcelino L. Villa [email protected]:

le falta que los plugins sean gemas

Eso ya lo tiene. No? will_paginate se puede utilizar como una gema.
Igualmente comentar que si hay algun plugin que creeis que puede ser
una gema, podeis hacer un fork, convertirlo en gema y mandar un pull
request al desarrollador y si le gusta que haga un merge. :wink:

2008/9/9 Francesc E. [email protected]

Así que mi pregunta, es … que creeis que le falta a Rails?

Lo que le falta es ligereza. Será un mal menor con la entrada de los
threads… pero aún así, cada instancia ocupa lo suyo. Que bien van a
venir
los threads, para por ejemplo otra cosa que hecho en falta en rails y
que
tiene merb. El decidir cuando se mandan los datos al cliente.

def Comment.create
c = Comment.create(params[:comment])
render c # se envían los datos al cliente.
make a heavy load block
end

La verdad, que día a día, me estoy pasando a Merb. La magia está chula,
pero
se paga, y yo soy pobre.

On Tue, Sep 9, 2008 at 3:33 PM, Marcelino L. Villa
[email protected]wrote:

rails-paperclip

o algo así?

Ahí no estoy de acuerdo. Me acabo de crear un
merb-packhttp://github.com/guillermo/merb-packque contenga las gemas
necesarias para usar una aplicación de merb+dm+spec,
por que estoy hasta las narices de tanto fragmentito y su incoherencia
de
versiones entre paquetes. Está bien dividir el framework y cargar solo
lo
necesario, pero bien se podría hacer dentro de la misma gema, leches.

2008/9/9 Guillermo [email protected]:

Lo que le falta es ligereza. Será un mal menor con la entrada de los
threads… pero aún así, cada instancia ocupa lo suyo. Que bien van a venir
los threads, para por ejemplo otra cosa que hecho en falta en rails y que
tiene merb. El decidir cuando se mandan los datos al cliente.

def Comment.create
c = Comment.create(params[:comment])
render c # se envían los datos al cliente.
make a heavy load block
end

Eso es bastante interesante.

2008/9/9 Guillermo [email protected]:

Ahí no estoy de acuerdo. Me acabo de crear un merb-pack que contenga las
gemas necesarias para usar una aplicación de merb+dm+spec, por que estoy
hasta las narices de tanto fragmentito y su incoherencia de versiones entre
paquetes. Está bien dividir el framework y cargar solo lo necesario, pero
bien se podría hacer dentro de la misma gema, leches.

No se donde leí hace poco que eso de separar un proyecto en
sub-proyectos se habia cargado algun proyecto dentro de la Apache
Software Fundation.

2008/9/9 Francesc E. [email protected]:

make a heavy load block
end

Eso es bastante interesante.

Quizá no esté en el framework, pero algo parecido se puede hacer con
cosas como Starling ¿no? Entiendo que render debería ser render
“ahora” y no render “cuando termines este método” (al menos eso es lo
más intuitivo), pero vamos, que hacerse se puede hacer ¿no?

que se instalen como gemas, quiero decir, no tener su propio sistema
de plugins
merb me parece que lo hace más adecuadamente

merb-core
merb-more

me gustaría ver

rails-paperclip
rails-restuful_auth

pero bueno, lo principal es que no veo el tener que usar otro sistema
de plugins
no sería genial hacer

script/plugin install paperclip …
… gem succesfully installed
… installing paperclip

o algo
así?
marze!

El 09/09/2008, a las 15:17, Francesc E.
escribió:

Eso ya lo tiene. No? will_paginate se puede utilizar como una gema.

Asi­ que mi pregunta, es … que creeis que le falta a Rails?

  • Creo que le sobra un poco de magia, todo ese ‘monkey patching’ a veces
    tiene efectos secundarios.
  • Ya en 2.2 han dado un paso pero necesitan un soporte de i18n y l10n,
    no
    sólo traducir cadenas de texto, creo que hace falta algo más versátil
    (fechas, monedas) ya que usar extensiones como gettext o globalize a
    veces
    introduce efectos secundarios (por el ‘monkey patching’)
  • Estabilidad. Que llegue un punto estable en el que las best-practices
    estén bien definidas y documentadas, que no haya que estar en una
    constante carrera aprendiendo novedades, librerías y nuevas formas de
    hacer las cosas.

Ya se ha mencionado que la evolución de Merb parece interesante, y tiene
cosas que me atraen: el uso de DataMapper, la descripción explícita del
modelo (no que se adivine “mágicamente” al conectar con la BD)

Eso sería lo que respondería a la pregunta, teniendo en cuenta que estoy
de siesta.


Pablo M. Schroder
http://docecosas.com

  • Creo que le sobra un poco de magia, todo ese ‘monkey patching’ a veces
    tiene efectos secundarios.
    Como por ejemplo?

Esa pregunta delata que no has sufrido los efectos dañinos de un cambio de
versión con gettext :slight_smile: Problemas con el renderizado, con rake o con
algunos plugins me vienen a la mente.

Yo creia que eso ya estaba resuelto en edge, la 2.2 todavia no está
lista.

Por lo que yo se 2.2 sólo incluirá traducción de cadenas, creo que ni
siquiera tiene establecido aún un mecanismo para usar diferentes
plantillas para cada idioma, pero la verdad es que el soporte de
internacionalización es primitivo, además el anuncio de i18n dejaba claro
que se iba a ofrecer eso, algo muy básico.


Pablo M. Schroder
http://docecosas.com

2008/9/9 Pablo M. Schroder [email protected]:

  • Creo que le sobra un poco de magia, todo ese ‘monkey patching’ a veces
    tiene efectos secundarios.

Como por ejemplo?

  • Ya en 2.2 han dado un paso pero necesitan un soporte de i18n y l10n, no
    sólo traducir cadenas de texto, creo que hace falta algo más versátil
    (fechas, monedas) ya que usar extensiones como gettext o globalize a veces
    introduce efectos secundarios (por el ‘monkey patching’)

Yo creia que eso ya estaba resuelto en edge, la 2.2 todavia no está
lista.

  • Estabilidad. Que llegue un punto estable en el que las best-practices
    estén bien definidas y documentadas, que no haya que estar en una
    constante carrera aprendiendo novedades, librerías y nuevas formas de
    hacer las cosas.

Desde mi punto de vista el framework es estable, y creo que no se está
redefiniendo nada. Si no me equivoco creo que lo de REST se habla
desde ya hace casi 2 años. ¿A que nuevas formas de hacer las cosas te
refieres?

Ya se ha mencionado que la evolución de Merb parece interesante, y tiene
cosas que me atraen: el uso de DataMapper, la descripción explícita del
modelo (no que se adivine “mágicamente” al conectar con la BD)

Ahí te doy la razón … eso Django tambien lo tiene, y creo que es un
buen feature, pero no creo que eso mejore mucho el rendimiento de una
aplicación. Si quieres ver la definición del modelo, puedes por
ejemplo utilizar AnnotateModels. Recordemos que Rails tiene las
migrations, cosa que Django lo acaban de sacar, y de las de DataMapper
no se si fiarme mucho.

Esa pregunta delata que no has sufrido los efectos dañinos de un cambio de
versión con gettext :slight_smile: Problemas con el renderizado, con rake o con
algunos plugins me vienen a la mente.

Los de Gettext si … los de los plugins tambien, lo que pasa es que
como nunca he sido un gran fan de los plugins, pues el problema no me
ha aparecido muchas veces.

Por lo que yo se 2.2 sólo incluirá traducción de cadenas, creo que ni
siquiera tiene establecido aún un mecanismo para usar diferentes
plantillas para cada idioma, pero la verdad es que el soporte de
internacionalización es primitivo, además el anuncio de i18n dejaba claro
que se iba a ofrecer eso, algo muy básico.

Ellos lo que han hecho es definir un sistema de localización de manera
que cualquiera a partir de ahora puede programar uno a partir de las
definiciones, y así elegir el que más nos guste sin romper la
aplicación.

2008/9/9 Guillermo [email protected]:

La verdad, que día a día, me estoy pasando a Merb. La magia está chula, pero
se paga, y yo soy pobre.

Una pregunta que puede sonar tonta … a medida que DataMapper vaya
evolucionando y le vayan añadiendo features, no crees que va a
volverse igual de lento que ActiveRecord?

2008/9/9 Francesc E. [email protected]

2008/9/9 Guillermo [email protected]:

La verdad, que día a día, me estoy pasando a Merb. La magia está chula,
pero
se paga, y yo soy pobre.

Una pregunta que puede sonar tonta … a medida que DataMapper vaya
evolucionando y le vayan añadiendo features, no crees que va a
volverse igual de lento que ActiveRecord?

Si y no. Si uno carga datamapper con todos y cada uno de sus módulos,
puede
hacer que se parezca a activerecord.

Sin embargo, para poder usar created_at con su magica, tengo que añadir
la
dependencia.

dependency “dm-timestamps”

De lo contrario son columnas normales.

Aparte, DM supera en features a AR. Cosas como dirty, ya lo soportaban
mucho
antes que AR, manteniendo aún la ligereza.

Volviendo al tema del hilo, ahora que empiezo con la comparación con
merb,
en rails hecho de menos:

Merb-slices (o ejecutar apps dentro de otras y que rails dejo de
soportar
hace tiempo)
Merb-Parts (Lo mismo que los partials, pero con su controlador en
archivo
separado).

Son un par de cosas que en el día a día se agradecen mucho, ya que
puedes
segmentar la aplicación con slices muy fácilmente, o añadir cache a de
parciales que incluyan su controlador.

2008/9/9 Daniel R. Troitiño [email protected]:

Quizá no esté en el framework, pero algo parecido se puede hacer con
cosas como Starling ¿no? Entiendo que render debería ser render
“ahora” y no render “cuando termines este método” (al menos eso es lo
más intuitivo), pero vamos, que hacerse se puede hacer ¿no?

Si claro, eso se puede hacer metiendo el proceso en una cola mediante
Starling, Beanstalkd, BackgroundRb, DelayedJobs o cualquier otro
sistema de colas que exista. Yo eso de Merb no lo habia visto y parece
interesante desde el punto de vista que al ser multi-hilo el proceso
no se queda bloqueado y porque nos quita una cap de complejidad al no
tener que meter un sistema de colas. (Corrijanme si me equivoco).

Y la funcionalidad de las Merb-slices la puedes conseguir con Desert [1]

http://github.com/pivotal/desert/tree/master

Las Merb-parts, si he entendido bien qué son, las puedes tener en
Rails con el plugin embebed_actions de Sebastian:

2008/9/9 Guillermo [email protected]:

2008/9/9 Guillermo [email protected]:

miedo a romper la compatibilidad hacia atrás en API, todo por el
rendimiento.

Guillermo, son una cucada (creo que querias decir eso), pero hemos de
recordar que Merb todavia no tiene una versión 1.0 por lo que pueden
hacer lo que quieran con la API, de la misma manera que en Rails se
hizo.

2008/9/9 Francesc E. [email protected]

interesante desde el punto de vista que al ser multi-hilo el proceso
no se queda bloqueado y porque nos quita una cap de complejidad al no
tener que meter un sistema de colas. (Corrijanme si me equivoco).

Mirate la api
oficialhttp://merbivore.com/documentation/merb-core/head/index.html?a=M000549&name=render_deferred.
Como ves, una verdadera qucada de métodos.

def Comment.create
run_later do {
HackTools.attack(request.remote_ip)
}
render “Guay, tu coment se creó”
end

Son cosas que me han hecho meterme en merb de lleno. Unos tios que no
tengan
miedo a romper la compatibilidad hacia atrás en API, todo por el
rendimiento.