lunes, 30 de junio de 2008

MagLev o Ruby corriendo en GemStone

La gente de GemStone está encontrando la manera de empezar a hacer más conocido su producto.
Miren esta demo de Avi Bryant sobre MagLev, una implementación de Ruby corriendo en la infraestructura de GemStone.
http://www.vimeo.com/1147409
La verdad que es muy buena y está muy bien dada, creo que dieron en la tecla en la presentación

Más sobre TDD

Siempre me costó encontrar un buen ejemplo para enseñar TDD, pero creo que finalmente he encontrado un problema interesante para resolver mientras se enseña esta técnica.
El problema consiste en modelar un árbol genealógico. Es muy interesante porque se puede empezar por resolver el problema de obtener los padres de una persona y luego los abuelos y luego los tatarabuelos. Haciendo esto se encuentra una recursión que puede ser modelada primero con mensajes y luego con objetos, todo utilizando refactorings!.
Luego se puede continuar con encontrar hermanos, primos, tíos, etc. para luego cuando está todo reificado crear composiciones de búsqueda... un lindo ejercicio, este sábado lo utilice en el postgrado de la UCA con un buen resultado (según me parece).

sábado, 14 de junio de 2008

Como hacer TDD

Hace un par de semanas cuando estaba revisando como iban los trabajos prácticos de POO, vi una confusión sobre lo que significa hacer TDD. Muchos grupos habían escritos varios test pero no habían corrido dichos tests. O sea, seguían trabajando de manera clásica C o Java, donde se escribe todo primero y luego se prueba, en vez de trabajar de manera dinámica, a la Smalltalk, donde se escribe y prueba constantemente.
Es interesante ver que cambiar este hábito es uno de los puntos más costosos e interesantes de este curso. Que los alumnos entiendan que la computadora está para "usarla" y no simplemente para escribir texto es muy difícil de lograrlo y es de esas cosas que hasta que no lo hacen no lo entienden.
En fin, hago este comentario para que todos aquellos que hacen TDD, no se olviden que los pasos son:
1) Escribir UN test
2) Hacer que el test funcione
3) Hacer que todos los test corran
4) Hay que mejorar el diseño?
a) Si hay que mejorarlo, hacerlo, refactorizar, etc. Ir a 3.
b) Si el diseño es aceptable, ir a 1

En estos pasos creo que está claro que luego de escribir UN test hay que hacerlo funcionar, no vale escribir varios test y luego hacerlos funcionar a todos juntos.
De vuelta, es importante darse cuenta que haciendo lo último, estamos manteniendo muchas ideas, soluciones, problemas, etc. en nuestra cabeza en vez de descargarlas a la computadora, y recuerden que los seres humanos cuanto más cosas tenemos en la cabeza más nos equivocamos y olvidamos

viernes, 13 de junio de 2008

Smalltalks 2008

Quería comentarles que ya hicimos el anuncio de Smalltalks 2008. Este año será en otra fecha y otro lugar, pero esperamos tener la misma calidad de presentaciones y cantidad de gente y por qué no, mejorarla.
Estamos trabajando para que venga gente "importante" a dar key notes y lo anunciaremos a su debido tiempo. También estamos trabajando para hacer un "coding contest" y que hayan tutoriales interesantes.
El lugar elegido esta año para hacer el congreso es la Universidad Abierta Interamericana que tiene unas instalaciones muy lindas y nos han abierto sus puertas con muy buena predisposición.
El sitio web del congreso este año será http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008
Aún estamos trabajando para hacer la inscripción automática y no por mail, etc. así que hay algunas páginas que están bajo construcción.
Espero verlos a todos en el congreso nuevamente!

martes, 10 de junio de 2008

Por qué escribir de manera inversa?

Estos días de "reposo" que tuve que hacer, los aproveché para ver algunos videos de Abelson y Sussman que son realmente muy recomendables.
Ellos hacen mucho hincapié en los mimos principios que usamos nosotros en POO y DAO, es muy interesante ver como piensan en el MIT y como lo hacían hace más de 20 años atrás!
Sin embargo, viendo uno de los ejemplos que mostraban me di cuenta que no siempre uno cumple lo que dice. Por ejemplo, vean este código:


Más allá de que es un poco difícil de entender la sintaxis porque está escrito en Scheme, lo que quiero remarcar es que para entender lo que hace hay que leer de abajo para arriba. La idea es que esta función sume los primeros n fibonaccies que son impares, y para ello utiliza el patrón
map/filter. Se debe leer, como dije, de abajo para arriba:
1) enum-interval 1 n -> crea un intervalo de 1 a n (a)
2) map fib (a) -> mapea los números del intervalo a su fibonacci correspondiente (b)
3) filter odd (b) -> filtra aquellos fibonacci que son pares, o sea, se queda con los impares (c)
4) accumulate cons '() (c) -> Acumula los resultados en una lista usando un lista vacía como valor inicial
Ahora, si estamos abogando por escribir código entendible, que se pueda leer fácilmente, etc. por qué para leer esta función tengo que hacerlo de abajo para arriba en vez de arriba para abajo que es más natural?
Me parece que sería mejor algo así (ahora en Smalltalk):

interval := 1 to: n.
fibonacciNumbers := interval collect: [ :aNumber | aNumber fibonacci ].
oddFibonacciNumbers := interval select: [ :aNumber | aNumber odd ].
^oddFibonacciNumbers

Al hacerlo así, se puede leer de manera natural, de arriba hacia abajo, de izquierda a derecha como van realizándose el computo.
Tiene una desventaja implementativa respecto de la primera versión y es que guarda todos los fibonacci para luego filtrarlo para quedarse con los impares mientras que la versión Scheme si el fibonacci no es impar, no lo guarda. Se podría lograr lo mismo haciendo:


oddFibonacciNumbers := OrderedCollection new.
fibonacciNumbers := 1 to: n do: [ :aNumber | | fibonacci |
fibonacci := aNumber fibonacci.
fibonacci odd ifTrue: [ oddFibonacciNumbers add: fibonacci] ].
^oddFibonacciNumbers

No es tan claro como la versión anterior, por lo que se podría abstraer en algo así:

(1 to: n)
add: [ :aNumber | aNumber fibonacci ]
into: OrderedCollection new while:
[ :aFibonacciNumber | aFibonacciNumber odd ]

De esta manera queda mejor expresada la idea que se quiere implementar.

lunes, 9 de junio de 2008

Ojo con el ojo

Simplemente quería hacer un comentario de tipo personal. El jueves pasado me realizaron un operación de retina del ojo izquierdo... los Wilkinson tenemos un par de problemas genéticos con los ojos... a mi me tocó algo que no es tan grave que se llama pit de papila que es un agujero en la retina. En fin, entró un poco de líquido por ese lugar, separó la retina del nervio óptico y dejé de ver algunos "pixels".
La operación fue muy interesante, pude ver todo lo que pasaba adentro del ojo porque tenía una fibra óptica que iluminaba todo. Tengo la operación grabada así que si alguien está interesado en verla me avisa!! jaja.
En fin, ahora estoy recuperándome, en una especie de reposo donde solo puedo ver con un ojo puesto que el operado está medio "atontado" por unas gotas que me estoy poniendo para que la retina cicatrice bien.
Es increíble el avance que hay en este tipo de operaciones. Me operaron en menos de una hora y salí caminando como si nada, es más, salí muy interesado en toda la operación, seguramente por el estado de "atontamiento" que tenía por el sedante que me dieron... según mi mujer parecía chico con juguete nuevo jaja.
Voy a ver cuanto puedo escribir con un solo ojo durante una semana!!!

VM de Squeak más rápido que VisualWorks

Parece que Eliot Miranda está trabajando en hacer una VM para Squeak muy rápida, basado en todo su conocimiento de la VM de VisualWorks. Según dice en su blog, su intención es que sea más rápida que la de VisualWorks... veremos si lo logra. Su blog está en http://www.mirandabanda.org/cogblog/