Calidad de una gema

[Ernesto - OmbuShop]

Buenas,

Creo que todos tenemos nuestra opinión al momento de elegir una gema vs. otra.

Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque tiene más calidad que otra.

Por ejemplo, yo generalmente tengo en cuenta estos factores (el orden varía)

* Funcionalidad: ¿Se ajusta a lo que tengo que resolver?

* Soporte: ¿Está abandonada? ¿Se sigue manteniendo?

* Calidad según Code Climate ¿Qué puntaje tiene?

* Mantenimiento: ¿Cuántos issues/pull requests abiertos tiene en ?

* Documentación: ¿Están documentados los métodos? ¿Se entiende?

* Comunidad: ¿Cuánta gente ya está usando la gema? ¿Qué alternativas existen según ruby-toolbox?

¿Ustedes qué factores tienen en cuenta para elegir gemas?

(Por favor tratemos de que no se convierta en una pelea entre una gema u otra. Gracias!)

Saludos!

--

Ernesto Tagwerker

Founder, OmbuShop  

Tu Tienda Online

[Ernesto - OmbuShop]

Quise decir: "Mantenimiento: ¿Cuántos issues/pull requests abiertos tiene en Github?"

Ernesto Tagwerker

Founder, OmbuShop  

Tu Tienda Online en Minutos

Of.: +56 (2) 2897-7599 (Chi)

Of.: +54 (11) 5368-1840 (Arg)

Of.: +55 8421 8428 (Mex)

[Damian Janowski]

2014-03-20 8:59 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com>:

> Buenas,
>
> Creo que todos tenemos nuestra opinión al momento de elegir una gema vs.
> otra.
>
> Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque
> tiene más calidad que otra.
>
> Por ejemplo, yo generalmente tengo en cuenta estos factores (el orden varía)
>
> * Funcionalidad: ¿Se ajusta a lo que tengo que resolver?

Desde ya. Suelo mirar que resuelva el problema que tengo yo y no muchísimos más.

> * Soporte: ¿Está abandonada? ¿Se sigue manteniendo?

Esto no lo miro tanto. Hay cosas que llegan a ser feature-complete y
luego no es necesario estar iterando todo el tiempo. Sí miro que siga
las buenas prácticas actuales: por ejemplo, hay gemas que tienen cosas
rebuscadas por Ruby 1.8 que en Ruby 1.9-2.0 se solucionan muy fácil.
En estos casos, muchas veces el autor solo perdió interés en la gema y
hay chances de que acepte un parche o te agregue como colaborador.

> * Calidad según Code Climate ¿Qué puntaje tiene?

No uso mucho Code Climate, debería verlo más.

> * Mantenimiento: ¿Cuántos issues/pull requests abiertos tiene en ?

Me parece que tener ninguno o muy pocos PR abiertos es un buen signo,
pero tener muchos no necesariamente es malo.

> * Documentación: ¿Están documentados los métodos? ¿Se entiende?

Casi que no lo miro.

> * Comunidad: ¿Cuánta gente ya está usando la gema? ¿Qué alternativas existen
> según ruby-toolbox?

Cuánta gente la usa seguramente es lo que menos me interesa. Es muy
común que, a medida que una gema se populariza, los autores empiezan a
querer solucionarle todos los problemas a todos los usuarios,
introduciendo complejidad innecesaria para la mayoría. Por eso
prefiero gemas más de nicho, que solucionen problemas acotados y
parecidos a los míos. Si tienen una forma sana de ser extendidas por
otras gemas, mejor.

> ¿Ustedes qué factores tienen en cuenta para elegir gemas?

Solo agregaría: mirar el código. A veces solamente scaneando un poco
te das cuenta de anti-patterns y cosas que no te van a funcionar, o
que van a ser difíciles de debuggear cuando haya un problema.

[Patricio Mac Adden]

Hola Ernesto, muy interesante el tema que planteas!

En mi caso suelo fijarme, respecto de los puntos que planteas:

* Que resuelva mi problema y si es con pocas vueltas, mejor.

* Si se sigue manteniendo y el desarrollo está activo, mucho mejor. Aunque a veces hay que usar cosas que no tenga mucho mantenimiento… En un caso puntal, tengo que usar una gema que no está muy mantenida pero me salva de hacer requests SOAP a mano. Y bueno, como dice el viejo proverbio: Agua y Ajo!

* No me suelo fijar mucho en la calidad de CodeClimate, pero si tiene buen puntaje, mejor!

* No me fijo en si está muy documentada o no. Si suelo fijarme en el README. Si no tiene un buen README, es decir, que no me explica bien para que sirve la gema y caso de uso básico, no es que la descarto de plano, pero no suma muchos puntos que digamos.

* Siempre es bueno buscar alternativas que se ajusten mejor a uno (ruby-toolbox era una buena herramienta). Trato de no fijarme mucho en la cantidad de estrellas que tenga en github, sin embargo a veces este factor inclina la cancha.

Saludos!

-- 

Patricio Mac Adden

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje de correo a rubysur+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Michel Martens]

A grandes rasgos:

. Funcionalidad (tiene que hacer una cosa y hacerla bien)
. Calidad (reviso el código)
. Dependencias (mismo procedimiento con cada una)

El tema de la calidad es medio subjetivo/instintivo, no uso Code
Climate o flog. Pero hay muchos indicios que son fáciles de detectar,
por ejemplo el uso/abuso de metaprogramming, rubyismos, etc.

Me parece bien usar Code Climate, o flog, o aunque sea contar las
líneas de código y mirar cómo está escrita una librería, si es
entendible, etc.

También tiene que haber una relación adecuada entre el tamaño (en
LOC, SLOC o como quieran medirlo) y el problema que resuelve. Hay
muchas librerías complejas y enormes que resuelven problemas
triviales, o librerías que abordan un problema desde un ángulo
equivocado, con lo cual transforman un problema trivial en uno
complejo antes de resolverlo. El ejemplo típico es Devise, que
resuelve el problema de autenticación en Rails, pero require 98029
líneas de código (contando todas las dependencias). Es como que te
pida la receta de una limonada y me des una enciclopedia de 20
tomos.

Agrego unos comentarios:

. Funcionalidad: ¿Se ajusta a lo que tengo que resolver?

OK

. Soporte: ¿Está abandonada? ¿Se sigue manteniendo?

Esto en mi caso funciona medio a la inversa. Si tiene mucha actividad,
a lo sumo es un indicio de un aspecto negativo (requiere mucho
mantenimiento). Es como un edificio al que todo el tiempo le están
arreglando algo: puede ser un signo de una mala construcción.

Hay herramientas que como dijo Damian ya están feature complete y
que no necesitan más atención, por ejemplo `cat` o `ls` o una
infinidad de herramientas que usamos a diario y que fueron actualizadas
en años.

. Calidad según Code Climate ¿Qué puntaje tiene?

Esto no lo uso pero no me parece mala idea.

. Mantenimiento: ¿Cuántos issues/pull requests abiertos tiene en GitHub?

Esto es interesante para ver cuántos bugs tiene, pero no tanto para
ver qué tantos features le piden a los autores. Hay librerías grandes
que tienen más de 30 bugs reportados en cualquier momento. Arreglan
uno y aparece otro. Lo que hay que evitar es toparse con uno de
esos bugs.

. Documentación: ¿Están documentados los métodos? ¿Se entiende?

En Ruby en particular, no me interesan tanto los comentarios en los
métodos porque el lenguaje es muy expresivo. Sí leo el README para
ver ejemplos de cómo se usa, como para tener un pantallazo inicial.

. Comunidad: ¿Cuánta gente ya está usando la gema? ¿Qué alternativas
existen según ruby-toolbox?

A esto no le doy importancia, creo que ruby-toolbox premia algunos
criterios erróneos. Por ejemplo, cuando una gema no tiene actualizaciones
la marcan en rojo. Una herramienta que se cae a pedazos y necesita
muchísimos colaboradores estaría en verde, mientras que `cat`, `ls`
y similares estarían en rojo. Entonces están alentando un defecto
en vez de una virtud.

También me parece un error premiar la popularidad, principalmente
por dos motivos: primero, no hay correlación entre popularidad y
calidad (por ejemplo, Justin Bieber no es el mejor cantante), y por
otro lado es muy difícil modificar una tendencia, porque quien parte
en la delantera va a sumar más usuarios siempre y cuando la popularidad
sea el criterio de adopción.

También hay que tener en cuenta que una librería grande, que soluciona
más problemas (y es por lo tanto más compleja y frágil) y que tiene
más colaboradores, va a tener más exposición casi que por necesidad.
Hay libros escritos sobre Rails, RSpec, Cucumber, hay conferencias
sobre Chef. Y nunca va a haber una conferencia sobre `cat` y `ls.

Y por supuesto, no digo que todas las librerías populares son malas,
sino que no hay correlación entre popularidad y calidad. Esto lo
digo especialmente para no herir la susceptibilidad de los fans de
Rails. O de Justin Bieber.

[Ernesto - OmbuShop]

2014-03-20 9:31 GMT-03:00 Damian Janowski <damian....@gmail.com>:

2014-03-20 8:59 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com>:

> Buenas,
>
> Creo que todos tenemos nuestra opinión al momento de elegir una gema vs.
> otra.
>
> Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque
> tiene más calidad que otra.
>
> Por ejemplo, yo generalmente tengo en cuenta estos factores (el orden varía)
>
> * Funcionalidad: ¿Se ajusta a lo que tengo que resolver?

Desde ya. Suelo mirar que resuelva el problema que tengo yo y no muchísimos más.

> * Soporte: ¿Está abandonada? ¿Se sigue manteniendo?

Esto no lo miro tanto. Hay cosas que llegan a ser feature-complete y
luego no es necesario estar iterando todo el tiempo. Sí miro que siga
las buenas prácticas actuales: por ejemplo, hay gemas que tienen cosas
rebuscadas por Ruby 1.8 que en Ruby 1.9-2.0 se solucionan muy fácil.
En estos casos, muchas veces el autor solo perdió interés en la gema y
hay chances de que acepte un parche o te agregue como colaborador.

 

Generalmente este chequeo va de la mano con la cantidad de issues reportados. Puede ser que se dé el caso que decís, pero también puede ser que no la está manteniendo, no va a aceptar parches. Entonces tenés que evaluar si querés empezar tu propio fork.

> * Calidad según Code Climate ¿Qué puntaje tiene?

No uso mucho Code Climate, debería verlo más.

> * Mantenimiento: ¿Cuántos issues/pull requests abiertos tiene en ?

Me parece que tener ninguno o muy pocos PR abiertos es un buen signo,
pero tener muchos no necesariamente es malo.

Claro, todavía no termino de definir mi criterio con esto.
 

> * Documentación: ¿Están documentados los métodos? ¿Se entiende?

Casi que no lo miro.

> * Comunidad: ¿Cuánta gente ya está usando la gema? ¿Qué alternativas existen
> según ruby-toolbox?

Cuánta gente la usa seguramente es lo que menos me interesa. Es muy
común que, a medida que una gema se populariza, los autores empiezan a
querer solucionarle todos los problemas a todos los usuarios,
introduciendo complejidad innecesaria para la mayoría. Por eso
prefiero gemas más de nicho, que solucionen problemas acotados y
parecidos a los míos. Si tienen una forma sana de ser extendidas por
otras gemas, mejor.

 

Cierto, pero tiene que haber cierta correlación entre la gente que usa una gema y la cantidad de issues reportados, preguntas/respuestas en stackoverflow, blog posts sobre la gema. ¿Esto no te suma?

> ¿Ustedes qué factores tienen en cuenta para elegir gemas?

Solo agregaría: mirar el código. A veces solamente scaneando un poco
te das cuenta de anti-patterns y cosas que no te van a funcionar, o
que van a ser difíciles de debuggear cuando haya un problema.

Buenísimo, gracias por aportar.  

[Ernesto - OmbuShop]

De acuerdo con qué no hay correlación entre popularidad y calidad.

Pero generalmente la cantidad de gente que lo usa genera información que después te resulta útil para resolver un problema.

A mí me importa la cantidad de gente que usa una gema, no porque es un concurso de popularidad, si no porque es más probable que haya más issues reportados, más preguntas/respuestas en stack overflow, más potenciales contributors.

Entonces, el día que tenga un problema con esa gema, puedo googlear y encontrar algo relacionado rápidamente.

ruby-toolbox lo veo como una buena herramienta para descubrir librerías alternativas y decidir cuál es la mejor, según mi requerimiento.

[Michel Martens]

> A mí me importa la cantidad de gente que usa una gema, no porque
es un concurso de popularidad, si no porque es más probable que
haya más issues reportados, más preguntas/respuestas en stack
overflow, más potenciales contributors.

Creo que acá el supuesto es que la librería es muy compleja, y por
lo tanto no es posible entender lo que hace o cómo lo hace en caso
de toparte con un problema, es así?

[Nacho Facello]

No necesariamente. No necesita haber mucha complejidad para que sea más fácil googlear "error message gem_name" que mirar el código. Por más fácil que sea mirar el código, la búsqueda te lleva dos segundos.

--
Nacho Facello
:wq

[Michel Martens]

>>> A mí me importa la cantidad de gente que usa una gema, no porque
es un concurso de popularidad, si no porque es más probable que
haya más issues reportados, más preguntas/respuestas en stack
overflow, más potenciales contributors.

>> Creo que acá el supuesto es que la librería es muy compleja, y
por lo tanto no es posible entender lo que hace o cómo lo hace en
caso de toparte con un problema, es así?

> No necesariamente. No necesita haber mucha complejidad para que
sea más fácil googlear "error message gem_name" que mirar el código.
Por más fácil que sea mirar el código, la búsqueda te lleva dos
segundos.

Es cierto, siempre es más rápido y más fácil googlear o escribir a
una lista que leer y entender cómo funciona una librería y detectar
por qué puede estar fallando.

[emanuelF]

siempre depende... hay ocasiones en que la inversa lleva al camino más fácil y rápido, por las respuestas que no dan en el blanco y nos hacen probar cosas que no son el problema... además del grande hecho de que nos quedamos sin el conocimiento de haber aprendido la gema/libreria, o algunas cosas más que nos llevamos de paso: nuevos enfoques, nuevas formas de solucionar un problema y demás. 

Por lo demás trato de fijarme en los casos de éxito y en la documentación, que tan rica es. 

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje de correo a rubysur+u...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/d/optout.

--

Emanuel Friedrich - Casi licenciado en Sistemas... :)
Cel: 3754-495887

Haya paz

[Bruno Bonamin]

Lo primero que miro es el último commit... por alguna razón los ojos siempre se me van hacia esta fecha cuando abro el repositorio de una gema... Después veo la cantidad de issues abiertas, si los que mantienen la gema responden a los issues, ya sea con comentarios o código... y si tengo que elegir, trato de buscar en Google referencias a la gema, y a veces saltan blog posts con explicaciones, casos de uso, etc; aunque la gema no sea muy popular.

Anecdóticamente me pasó que nunca me gustó mucho CanCan, y gracias a ruby toolbox y un post de un blog, conocí Authority, que me terminó gustando muchísimo y se adaptó mucho mejor a lo que tenía que desarrollar.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Bruno Bonamin.

[Michel Martens]

El subject es "Calidad de una gema", y el planteo original es este:

> 2014-03-20 8:59 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com:

> Creo que todos tenemos nuestra opinión al momento de elegir una gema vs.
> otra.
>
> Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque
> tiene más calidad que otra.

Entonces me parece que la cantidad de issues reportados, respuestas
en stack overflow y demás no son una medida de la calidad de la
gema.

Sí entiendo que es un criterio que utilizan varios en esta lista
para elegir qué librería usar, pero estamos de acuerdo con que no
es la calidad lo que se está midiendo?

O estamos manejando distintas definiciones de "calidad", que también es
posible.

[Ernesto - OmbuShop]

2014-03-20 16:56 GMT-03:00 Michel Martens <sov...@gmail.com>:

El subject es "Calidad de una gema", y el planteo original es este:

> 2014-03-20 8:59 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com:

> Creo que todos tenemos nuestra opinión al momento de elegir una gema vs.
> otra.
>
> Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque
> tiene más calidad que otra.

Entonces me parece que la cantidad de issues reportados, respuestas
en stack overflow y demás no son una medida de la calidad de la
gema.

Creo que esto dá para una discusión aparte. Pero está bueno saber la opinión de todos los que opinaron.
 

Sí entiendo que es un criterio que utilizan varios en esta lista
para elegir qué librería usar, pero estamos de acuerdo con que no
es la calidad lo que se está midiendo?

O estamos manejando distintas definiciones de "calidad", que también es
posible.

La calidad es relativa. En mi caso, suma que una gema A tenga una comunidad más grande que una gema B. Pero no es el factor decisivo.

Todos los puntos que mencioné en mi lista tienen un peso relativo para definir si uso la gema A o la gema B.

Este punto en particular no tiene tanto peso como los otros que mencioné. Sí estaría bueno empezar otra discusión sobre el tema "popularidad" de una gema.

[Michel Martens]

2014-03-20 17:40 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com>:
> 2014-03-20 16:56 GMT-03:00 Michel Martens <sov...@gmail.com>:
>>
>> El subject es "Calidad de una gema", y el planteo original es este:
>>
>> > 2014-03-20 8:59 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com:
>> > Creo que todos tenemos nuestra opinión al momento de elegir una gema vs.
>> > otra.
>> >
>> > Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque
>> > tiene más calidad que otra.
>>
>> Entonces me parece que la cantidad de issues reportados, respuestas
>> en stack overflow y demás no son una medida de la calidad de la
>> gema.
>
>
> Creo que esto dá para una discusión aparte. Pero está bueno saber la opinión
> de todos los que opinaron.

Es como decir que la calidad de un vino depende de cuántas persona se quejaron,
o de cuántas personas lo produjeron, etc. Qué definición de "calidad"
estás usando?

>>
>> Sí entiendo que es un criterio que utilizan varios en esta lista
>> para elegir qué librería usar, pero estamos de acuerdo con que no
>> es la calidad lo que se está midiendo?
>>
>> O estamos manejando distintas definiciones de "calidad", que también es
>> posible.
>
>
> La calidad es relativa. En mi caso, suma que una gema A tenga una comunidad
> más grande que una gema B. Pero no es el factor decisivo.
>
> Todos los puntos que mencioné en mi lista tienen un peso relativo para
> definir si uso la gema A o la gema B.
>
> Este punto en particular no tiene tanto peso como los otros que mencioné. Sí
> estaría bueno empezar otra discusión sobre el tema "popularidad" de una
> gema.

Que "sume" significa que te sirve para juzgar apropiado elegir una librería,
pero no significa que el tamaño de la comunidad determine su calidad. Incluso
se puede decir justamente lo contrario, sin que pierda validez: podés elegir
una librería por la comunidad que tiene, más allá de su calidad intrínseca.

Falta la definición de "calidad" que estás usando.

[Ernesto - OmbuShop]

Es lo que dije en mi primer mail:

* Funcionalidad: ¿Se ajusta a lo que tengo que resolver?

* Soporte: ¿Está abandonada? ¿Se sigue manteniendo?

* Calidad según Code Climate ¿Qué puntaje tiene?

* Mantenimiento: ¿Cuántos issues/pull requests abiertos tiene en ?

* Documentación: ¿Están documentados los métodos? ¿Se entiende?

* Comunidad: ¿Cuánta gente ya está usando la gema? ¿Qué alternativas existen según ruby-toolbox?

¿Cuál es tu definición de calidad de una gema?

[Ernesto - OmbuShop]

Volví a leer tu mail. Para vos calidad es esto:

* Funcionalidad (tiene que hacer una cosa y hacerla bien)
* Calidad (reviso el código)
* Dependencias (mismo procedimiento con cada una)

Todo bien.

Estaría bueno saber si otro usa otros criterios para definir la calidad de una gema.

[Bruno Aguirre]

Bueno, estos son mis criterios para calidad:

* No  require activesupport.

* No monkey patchea stdlib.

* Se encarga de solucionar un (1) problema.

* Explicito vs implicito.

* Sus dependencias son por funcionamiento y no por la facilidad de escribir codigo.

* Documentada.

Y totalmente paralelo y no aplica a la calidad de la gema: http://lostechies.com/derickbailey/2012/12/14/dear-open-source-project-leader-quit-being-a-jerk/

--

[Alvaro Gil]

Completamente de acuerdo con Bruno Aguirre y agrego la siguiente que estoy seguro que él también la considera pero se le paso.

* Que este testeada

--
Alvaro

[Pablo Astigarraga]

Dos puntos que siempre miro y no mencionaron todavía:

* El autor - si lo conozco ya me dice bastantes cosas sobre como puedo esperar que opere determinada librería.

* Cantidad de contributors - no es un be all and end all, pero proyectos más maduros tienden a tener más contributors.  

[Bruno Aguirre]

Bueno, en realidad no se me paso.

No veo los tests como una prueba de la calidad de una gema.

He sido victima de tener que modificar la aplicación para poder testearla "como se debe".

Es un nice to have.

[emanuelF]

O estamos manejando distintas definiciones de "calidad", que también es
posible.

Podría ser... Creo que Michel define calidad en base al término más puramente técnico, y no hace distinción (lo que está bien a mi criterio) entre la calidad de una gema y la calidad de software en sí.

Dentro de las definiciones técnicas la que me gustó mucho y que la respeto decía algo así:

"Si el diseño es mágnifico, pero el usuario queda insatisfecho, no hay calidad de software. La más importante medida es la satisfacción del usuario"

No tengo la fuente, perdón.

El tema es que como son programadores los usuarios de las gemas (librerías, módulos, etc) , pedimos (o deberíamos pedir) que el diseño e implementación sean buenos, no solamente las interfaces que presenta la gema (libreria, blabla).

Creo que buena parte discute y valora de las interfaces para afuera, y Michael rescata el punto más "técnico" y/o "apropiado". 

Ahora, creo que debería haber por parte del que arránco el thread, la definición de calidad que propuso para el thread. 

Pero sinceramente opino que el subject no parece subject del cuerpo del mensaje, sino que el cuerpo pregunta: "que criterios usan para elegir una gema". Ahora sería bueno que se aclare que es lo que se busca saber. Creo que es muy enriquecedor saber que criterios se usa para elegir....

[Damian Janowski]

2014-03-20 18:03 GMT-03:00 Michel Martens <sov...@gmail.com>:
> Que "sume" significa que te sirve para juzgar apropiado elegir una librería,
> pero no significa que el tamaño de la comunidad determine su calidad. Incluso
> se puede decir justamente lo contrario, sin que pierda validez: podés elegir
> una librería por la comunidad que tiene, más allá de su calidad intrínseca.

Razón principal por la que sigo usando Ruby.

[Ernesto - OmbuShop]

2014-03-21 8:08 GMT-03:00 emanuelF <aemanuel...@gmail.com>:

O estamos manejando distintas definiciones de "calidad", que también es
posible.

Podría ser... Creo que Michel define calidad en base al término más puramente técnico, y no hace distinción (lo que está bien a mi criterio) entre la calidad de una gema y la calidad de software en sí.

No sé si responder esto acá o abrir otro thread, porque dá para escribir mucho más sobre la calidad del software.

 

Dentro de las definiciones técnicas la que me gustó mucho y que la respeto decía algo así:

"Si el diseño es mágnifico, pero el usuario queda insatisfecho, no hay calidad de software. La más importante medida es la satisfacción del usuario"

No me gusta esta definición. Hay muchas definiciones de la calidad del software. Definiciones tan malas como: "Calidad es que el software cumpla con los requerimientos."

No tengo la fuente, pero lo ví en la clase de Introducción a Ing. en Software (UTN, Buenos Aires) donde se ven algunas definiciones. 

El que use esa definición seguramente nunca tuvo que mantener un proyecto que era hermoso para el usuario pero el código era algo inmantenible.

No tengo la fuente, perdón.

El tema es que como son programadores los usuarios de las gemas (librerías, módulos, etc) , pedimos (o deberíamos pedir) que el diseño e implementación sean buenos, no solamente las interfaces que presenta la gema (libreria, blabla).

Creo que buena parte discute y valora de las interfaces para afuera, y Michael rescata el punto más "técnico" y/o "apropiado". 

Ahora, creo que debería haber por parte del que arránco el thread, la definición de calidad que propuso para el thread. 

Cuando empecé el thread era para saber los criterios de la comunidad para elegir una gema. Todos tienen su criterio y está bueno para aprender a qué le dan importancia para elegir una u otra gema.

 

Pero sinceramente opino que el subject no parece subject del cuerpo del mensaje, sino que el cuerpo pregunta: "que criterios usan para elegir una gema". Ahora sería bueno que se aclare que es lo que se busca saber. Creo que es muy enriquecedor saber que criterios se usa para elegir....

 

No tengo una definición de "calidad de software" que me agrade 100%, pero la que más me gusta es la ISO 9126. http://en.wikipedia.org/wiki/ISO/IEC_9126

Otra definición que está buena es la de las 8 dimensiones de la calidad de Garvin: http://en.wikipedia.org/wiki/Eight_dimensions_of_quality

Pero bueno, hay ciertos puntos de esas definiciones que no tienen sentido para una gema.

[emanuelF]

golaso... me quedo con la buena idea de saber que criterios usa la comunidad al usar una gema;) grandioso aporte Ernesto

--

Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje de correo a rubysur+u...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Paul Martens]

2014-03-20 8:59 GMT-03:00 Ernesto - OmbuShop <ern...@ombushop.com>:

Me gustaría saber qué toman en cuenta ustedes para usar una gema, porque tiene más calidad que otra.

Entiendo que hay dos preguntas, no una.

A. En mi opinión, una gema goza de buena calidad cuando es precisa, concisa y eficiente.

B. Para determinar si una gema es precisa, concisa y eficiente, sigo los siguientes pasos:

  1. Leo la documentación.

  2. Miro el código.

  3. Leo comentarios de usuarios (a veces encuentro allí información valiosa).

  3. Le pido opinión a mi hermano ;)

No le doy gran valor a la popularidad porque muchas veces ese factor juega en contra, de modo que no puede ser determinante. Digo, una comunidad enorme, puede también aportar mucha basura.

Por otra parte, tengo ciertos prejuicios que influyen en mi decisión. Menciono algunos:

  . Si la gema es enorme, ya siento que va para atrás.

  . Si está atada a un framework, chau.

  . Si tiene muchas opciones para cubrir muchos casos, -1.

Por supuesto que reviso el código analizando el enfoque del autor, los patterns que implementa, etc., pero si detecto algo de lo mencionado anteriormente, ya es como que difícilmente opte por esa gema.

Saludos,

P.

 

[Michel Martens]

Justo publicaron esto en Reddit:

http://www.reddit.com/r/ruby/comments/22j2eq/a_guide_to_choosing_the_best_gems_for_your_ruby/