Paso a poneros un poemilla, que me ha dedicado un amigo, y que me ha hecho una ilusión tremenda :-)
Tengo un amigo empresario
que es un Bill Gates en potencia;
tenía un tres por ciento escaso
y anda ya por la veintena.Informática es la empresa,
porque él es informático,
ahora tan solo comienza,
es proyecto a largo plazo.Aguanta nuestras bromitas
con ánimo extraordinario
y paciencia santojóbica.Verás tu al flowerniano,
se oirá la risa en Salónica
cuando sea millonario...
Juan J. Sánchez
Y es que Google ha dedicido dar soporte a OpenID en la próxima versión de Blogger. Por ahora, nuestra cuenta OpenID, nos valdrá para poder comentar en cualquiera de los blogs que se encuentre en sus dominios. Pero oye, que ya es algo..
Me hace ilusión poder escribir en el blog del mejor equipo de futbol sala en una de las ligas menos importante de Sevilla, mi equipo, con mi cuenta OpenID ^_^!
Bueno, ya recuperado es buen momento para dedicar unas palabrillas al evento.
En lineas generales, y a nivel personal, el evento me ha parecido una pasada. Estar bien cerquita de todos los desarrolladores de los que tanto has leido, ya sean tutoriales, screencasts, lista de correo.. no tiene precio. El Hollywood Rails era aquello.
El formato de las ponencias tal vez no sea el más acertado dado el escaso tiempo del que se contaba. Ponencias mucho más concretas y que nos pudiesemos llevar puesto para probar luego en nuestros desarrollos, tal vez sea para lo que den esos minutillos. Nota: Menos predicar y más practicar.. :P
Lo que si me ha sorprendido mucho es nivel de los asistentes, que hacían mucho más enriquecedora las ponencias. Sorprendidisimo me quedé al comprobar que más del 50% de los asistentes a "Más allá del testing " hacían sus test antes que sus implementaciones.
En fins, al final he salido de allí, aparte de viviendo una gran, y cansada, experiencia, con muchas ganas de hacer mis propios plugins (uno ya de camino..), mi propia araña (un trabajillo..) y ¡ de testear todo lo que se mueva ! :P
El control de mando está últimamente muy activo creando misiones espaciales, misiones que necesitan su primera puesta a punto: generación, sus primeros ignores, sus primeros plugins,.. Despues de ir generando varios de ellos, te das cuenta de que ya eres incapaz de entender Rails sin muchos de estos plugins.
Imprescindibles
HAML: La manera más DRY de escribir nuestro código XHTML (markup haiku ;P). Pros: A la hora de codear es limpio y claro, al igual que el código generado. Si trabajas en equipo se mantiene una regla de escritura implicita. Contras: Por esto último puede que al principio sea una lata adaptarse a dichas reglas. Extra: Soy FAN number One de Hampton Catlin y su equipo ;D
rSpec: Testeando nuestro código a través de su comportamiento (BDD). Pros: Usarse debería ser una obligatorio, los pros son tantos.. Contras: Las mayoría de las soluciones testing se basan en TDD. La curva de aprendizaje es lenta.
restful_open_id_authentication: Una versión de restful_authentication con OpenID. Pros: Ofreces OpenID en tu aplicación en un visto y no visto. Contras: Al no ser una versión de la más populares no sé hasta que punto se mantendrá actualizado.
WillPaginate: Con un ojo al frente y otro a err_the_blog :P Pros: ¿Hay paginación más sencilla? Contras: En alguna que otra situación se nos queda corto: Paginar arrays (googleando se encuentra la solución a esto), forms,..
Grandes compañeros de viaje
annotate_models: ¿Que campos tiene este modelo? No más viajes a la BD para recordarlos. Toda la información en nuestros modelos y fixtures.
exception_notification: Enterate antes que el jefe o el cliente que la aplicación tiene fallos de programación. Todos los fallos generados a tu correo al instante.
acts_as_state_machine: Modelos actuando como una máquina finita de estados. Permite, entre otras cosas, lanzar metodos asociados a un tipo de cambio de estado. Genial.
upload_column: Para subir nuestros ficheros, imagenes,.. asociadas a un modelo. Este es el tercer plugin con esta finalidad que hemos usado y el más práctico con diferencia.
Hay alguno más pero con misiones muy puntuales y que por ahora no viajan lo suficiente como para estar por aquí ;)
Esta mañana, poniendome al día con la blogesfera, dí con este pequeño y genial hack para hacer nuestros metodos algo más semanticos:
class Object
define_method :not do
Not.new(self)
end
class Not
private *instance_methods.select { |m| m !~ /(^__|^\W|^binding$)/ }
def initialize(subject)
@subject = subject
end
def method_missing(sym, *args, &blk)
!@subject.send(sym,*args,&blk)
end
end
end
Y bueno, los ejemplos más sencillos no pueden ser:
usuario.not.visible? usuario.not.admin?
Me encanta ^_^!
Fuente: http://blog.jayfields.com/2007/08/ruby-adding-not-method-for-readability.html
¡ Nuestro primer proyecto ya en orbita !
Menuda satisfacción acabar lo que se empieza, y aunque queda mucho por refinar, personalmente, las tareas de refactorización son las que más me gustan ^_^!
Es mi obligación, despues de mi novatillo artículo de como integrar OpenID en el plugin Acts_As_Authenticated, recomendaros el uso del siguiente plugin:
Extiende de RESTful Authentication y este a su vez de AAA. No es tan popular como el plugin del que extiende, por lo que no sé si se irá actualizando en el tiempo. Para los que no quieran arriesgarse, les recomiendo ver el próximo railscasts de Ryan Bates en el que añadirá OpenID al plugin RESTful Authentication.
Para los arriesgados, cambiar esto en el fichero /app/views/users/new.rhtml trás generar el user y session (leer el README!):
<% form_for :user do |f| -%>
por
<% form_for :user, :url => users_path do |f| -%>
En fins, darle todas las opciones a nuestros usuarios está a un generate de distancia :P
De primero, uno sencillo y popular... ;D
Cuando realizamos una asignación multiple tal que así...
@usuario = Usuario.create(params[:usuario])
... corremos el riesgo de que un hackerillo nos pueda hacer de las suyas. ¿Como? Si esta persona, de moral descuidada, conoce campos que no debe conocer (vease uno llamado :admin, por ejemplo) podria alterar las propiedades del nuevo usuario y darse un bonito permiso de administrador en nuestra web.
Solución: Utilizar el metodo attr_protected en los atributos del modelo que queramos proteger de éstas asignaciones multiples. Cuando ésta se realice los valores de los atributos que hayamos protegido serán ignorados.
attr_protected :admin
Si por el contrario tenemos más claro que atributos podrán ser modificados podemos utilizar attr_accessible. Con este metodo los campos que no marquemos como accesibles quedarán protegidos.
Nota: Con este último metodo, los nuevos atributos entrarán automaticamente en el "grupo de los protegidos".
Mucho más en http://manuals.rubyonrails.com/read/chapter/47
Juan Gallego Galisteo
Sevilla, España
Juan
ver perfil »
