2009/4/20 Agustin Nicolas Viñao Laseras [email protected]
Guillermo entiendo tu opinion, pero tambien hay que resaltar que cuando
armamos una aplicacion, hay ciertas decisiones que van mas alla de la sola
implementacion de un parecer en un instante del desarrollo, como comentaba
en otra respuesta, por acumular atributos en un modelo para definir pequeñas
cosas a medida que las vamos diseñando, podemos terminar con un problema de
performance a medida que crece la aplicacion.
Por eso decÃa que la solución es cosa suya según sus necesidades.
Tal vez haya entendido mal el desarrollo ágil, metodologÃa que me gusta
bastante. Me gustan pequeñas iteraciones sobre el producto, una
interacción
a grandes rasgos resuelve los problemas de esa iteración. Y no se hacen
planes a largo plazo. ¿Por qué voy a complicar una cosa con roles si con
decir que el admin es el que tiene el primer id, o si hay varios, añadir
el
campo de admin?
Cuando tenga problemas de rendimiento. Pues añado Ãndices a la base de
datos, cuando vuelva a tener problemas, añado caches de vista/modelo,
etc…
Y cuando se me quede corta la máquina, añado otra máquina y pongo un
balanceador. Pero no me gusta caer en la optimización prematura,
optimizar
un producto, que todavÃa no se como va a ser.
Pero insisto es simplemente como me gusta desarrollar, lo que entiendo
yo
como desarrollo agil, que casi podrÃa resumir en resolver los problemas
inmediatos que tengo. El futuro ya vendrá.
Siempre considero que hay ciertas lineas de desarrollo a seguir cuando
estamos armando una aplicacion, que van mas alla de si es algo muy pequeño o
no.
Perfecto. Eso lo veÃa mucho en desarrollo Java, cuando un producto tenÃa
que
estar muy definido antes de empezar la parte de diseño del modelo de
negocio
y antes incluso de ponerse a programar. Pararse a pensar todos los ´y
si…´
que pudiese tener la aplicación.
Por ejemplo, saber que si estamos hablando de roles de los usuarios, por
mas
que en un instante tengamos solo 2 roles posibles, saber que el dia de
mañana si en alguna parte de la aplicacion tenemos problemas con esto, saber
que el manejo de roles se maneja independientemente al usuario, es diria en
resumen, una buena metodologia de saber organizar nuestro desarrollo.
Bueno, para ti, será la buena. Para mÃ, insisto que no, y te pido que
respetes lo que yo creo que es bueno para mi o no. Para mi esa
metodolgÃa,
en desarrollo web, un desarrollo de un producto dinámico, incluso una
start-up, es totalmente erróneo. Hago la aplicación Diciendo que el
usuario
con id 1 sea el admin. Cuando necesite algo más… hago la migración y
creo
la columna admin. Necesito algo más y creo los roles. Pero como producto
dinámico que es… ¿Y si no necesito roles? ¿Por que voy a preocuparme
por
algo que todavÃa no ha llegado?
O por ejemplo, como comenta Ryan B. en un screencasts [1] de no hacer un
mass assignment, si dejamos que el flag admin se setee en el usuarios,
cualquier caso en donde se produzca un problema de seguridad con el modelo
user, cualquiera puede tomar control de la aplicacion
Efectivamente, si no sabes lo que es el mass_assigment ni como usarlo,
no lo
uses. Si lees la documentación de rails verás el attr_protected y
attr_accesible que implementa el paradigman de listas negras y listas
blancas sobre los parámetros del modelo.
[1] #26 Hackers Love Mass Assignment - RailsCasts
Lo siento, pero en cuanto a la seguridad sobre rails, no suele ver
posts de
2007.