doce cosas

Queda poco para que termine el año así que va siendo hora de ir planificando las propuestas que todos nos hacemos para el 2009, y como no fumo pues tendré que empezar con otras.

• Lo primero que decidí, ya hace unos meses, es que el 2009 sería el año de La Torre Oscura. Mi objetivo será (re)leer la saga de Stephen King así como otros libros que rodean el universo de la búsqueda de Roland. En total supone una veintena aproximada de libros.
• Me gustaría aprender Haskell, ya que en programming.reddit.com es muy mencionado y creo que nunca viene mal tener algo de soltura en programación funcional (cosa que perdí desde mis años de facultad).
• En el aspecto ecónomico, en esta última mitad del 2008 he conseguido estabilizar la situación y la idea es conseguir algo de ahorro, aunque el siguiente propósito igual complica ese asunto.
• Automovilizarme. El año pasado me saqué el carné de conducir y ahora mismo no tenemos vehículo, estamos planteando qué hacer en ese aspecto y ya veremos cómo va todo.
• En el aspecto laboral supongo que a pesar de tener en mente unas apuestas personales lo mejor será declarar en público un virgencita, virgencita, que me quede como estoy :-).
• Seguir intentando y conseguirlo.
• Tendría que decir algo de mi sobrepeso y de el ejercicio, pero no quiero ponermelo como propósito porque no se si seré capaz y tendría que ser algo que se transformara en hábito.

Supongo que quizás tendría que hacer otro post con algunas predicciones sobre el mundo tecnológico, sistemas, Internet y wireless, pero eso hay que reflexionarlo más, que no se me da tan bien.

Acabo de leer Así lo hace Matt, una conferencia con metología Ignite de Matt, el creador del vídeo inspiracional posiblemente más popular de todo el mundo.

El final de la conferencia es lo que uno se esperaría de una charla de Matt, ya que pide a todo los asistentes que suban a bailar con él y al verlos me di cuenta de que uno se apartaba para sacar una foto y me pregunté, si hubiera estado allí ¿habría bailado? ¿me habría preocupado en fotografiar o grabar el evento? ¿o habría twitteado sobre ello? Me gustaría pensar que habría bailado sin más recuerdo que mi memoría pero no se si podría aseguarlo ¿Qué hariais vosotros?

Hoy estaba haciendo unas cosas con una serie de listas de listas que contienen listas y me estaba encontrando con algún pequeño follón y he descubierto algo que no será para tirar cohetes pero me ha venido bien.


[ ['Triangulos', 1], ['Circulos', 2],['Cuadrados', 3] ].each { |fig,count| p “#{fig} aparece #{count} veces@}


No es gran cosa, pero el poder usar algo como |fig, count| en vez de |a| y tener que recurrir a a[0] y a[1], y aunque en este ridículo ejemplo quizás podría usarse un Hash en lugar del los Array como tuplas en mi caso sí que me ha ayudado a hacer un poquito más legible en código. No es gran cosa, pero algo ayuda.

Cualquiera que haya tenido que mantener tests de aplicaciones en Rails habrá llegado a soltar algún improperio al tener que mantener Fixtures (y eso que en Rails 2.0 facilitaron algo la gestión) ya que en cuanto el proyecto tiene algo de envergadura y movimiento ese sistema se vuelve inmanejable, se emplea demasiado tiempo en gestionar unos datos en unos ficheros de texto para solucionar problemas en los tests.

Sin embargo no parece que haya una alternativa ideal para los tests, hay muchas posibilidades y parece que no está clara cual es la forma más adecuada al sistema integrado en Rails. Personalmente me gusta Fixtures Replace 2 y tengo planeado echarle un vistazo a Fixture Scenarios (un interesante artículo: “Fixin’ fixtures“) pero no tengo muy claro cuál sería el mejor método. También tengo pendiente probar RSpec, pero cambiar toda la metodología de tests puede llegar a ser costoso así que me gustaría preguntar aquí ¿qué es lo que más apropiado habéis visto para usar con Rails?

De un tiempo para acá estoy teniendo en cuenta DataMapper, un ORM para Ruby que tiene similitudes con Active Record pero se nota que es una librería posterior por muchos detalles. De las cosas interesantes que puede hacer hay algunas muy dignas de tener en cuenta.

• Las actualizaciones parciales, que ya se encuentran disponibles en la nueva versión de Active Record en Rails 2.1
• Actúa contra la base de datos con inteligencia, minimizando en lo posible el número de accesos a las tablas.
• Las búsquedas son totalmente en Ruby, con lo que no hay que hacer extraños inventos para búsquedas complejas (en ActiveRecord hay que tocar el SQL para unir varias condiciones).
• Es explícito. Al definir la clase también definimos los campos y el tipado de éstos. En ActiveRecord a veces me siento un poco desorientado ya que las propiedades de la clase se definen al conectar con la base de datos, en DataMapper se definen explícitamente en la clase.
• Acceso directo. Si tenemos el modelo Post podemos hacer Post[3] en lugar de Post.find(3) y otras muchas más formas de encontrar lo que buscamos.
• Paranoia. DataMapper incluye de serie el borrado lógico al definir una propiedad como property :deleted_at, ParanoidDateTime. La realidad es que casi siempre que borramos sólo queremos marcar como borrados, y que el ORM de serie incluya esta funcionalidad nos facilita mucho el trabajo. Con ActiveRecord puede conseguirse, pero no es lo mismo

No es oro todo lo que reluce y DataMapper todavía no está completo del todo (siguen trabajando en las relaciones entre objetos y algunas cosas más) pero la verdad es que para proyectos Ruby que no sean Rails puede ser una interesante opción, sobre todo si estamos probando algo como Merb con DataMapper.