viernes, septiembre 30, 2005

Post para aumentar eltráfico

Es increíble analizar los "referals" de este blog. Hay gente, aunque cueste creerlo, que llega a mi blog después de haber buscado en google "concepto de arroz con leche".

Para ver si puedo aumentar el tráfico, voy a meter en este post algunas palabras que, creo, interesarán a la gente:

SEXO

GRATIS

CHICHAS

PROMISCUIDAD

LUJURIA

GULA

PEREZA


Aunque no lo crean, esto es una especie de estudio sociológico.

miércoles, septiembre 14, 2005

La magia del Smalltalk: Capítulo 12 - ¡Basta ya de las bases de datos relacionales!

Hace tiempo que no discuto con mi esposa, así que ando con un poco de ganas de pelear y voy a sacar de la galera uno de los tópicos más controversiales en lo que respecta al desarrollo de software:

El (ab)uso de las bases de datos relacionales.


No quiero entrar en una de esas discusiones estériles que tanto nos gustan a los programadores. Ya gasté muchísimo tiempo en discusiones tipo: Vi -> Emacs, Linux -> FreeBSD, GPL -> Licencia MIT, GNOME -> KDE y, sobre todo, en elRestoDelMundo/Smalltalk.

De la misma forma en que nadie puede decir que un paradigma de programación sea mejor que el otro, no podemos decir que el paradigma de objetos sea mejor o peor que el paradigma relacional.

No dudo que las bases de datos relacionales sean útiles, pero de lo que estoy seguro es que la mayoría de los usos que se les da a las bases de datos relacionales son incorrectos, incómodos e ineficientes.

Excepto por algún loco que condene el paradigma de objetos, hay un consenso bastante amplio en considerar que el modelado con objetos mejora en el desarrollo de software. Alcanza con ver como los lenguajes de moda se van pareciendo, cada vez más, a Smalltalk. Si no lo creen, analicen la linea sucesoria: C++ -> Java -> C# -> Python -> Ruby o piensen en los cambios que sufrieron el Basic (en su paso a Visual Basic o Gambas) o el Pascal (en su paso a Delphi y Oberon).

El problema se nos presenta porque la mayoría de los proyectos de desarrollo de software, que usan alguna forma del paradigma de objetos, usan una base de datos relacional como mecanismo de persistencia de los datos.

Ese mundo híbrido en el que nos toca (sobre)vivir tiene muchos inconvenientes. Hablemos de algunos:

  • Costos de capacitación: Todas las personas involucradas en el desarrollo tiene que poder expresarse fluidamente en dos paradigmas diferentes y cambiar, en la forma de pensar, entre el álgebra relacional y los objetos durante el proceso de desarrollo.

  • Costos de desarrollo: No es raro encontrar que el costo de desarrollo del mapeo objeto/relacional llegue a ser un porcentaje importante del desarrollo. No es raro encontrarse con sistemas que sólo piden datos a los usuarios para meterlos en tablas.

  • Rigidez en los diseños: Los cambios en el diseño del sistema son más caros ya que hay que hacer los cambios en 2 modelos diferentes, y en el mapeo entre los modelos. No es raro encontrarse con jerarquías de clases terriblemente planas con tal de evitar problemas en el mapeo.

  • Problemas de performance: Las técnicas para mejorar los tiempos de procesamiento y respuesta son diferentes entre el modelo relacional y el modelo de objetos y, para peor, muchos de las técnicas que mejoran la performance en un modelo, producen el efecto contrario en el otro. Eso sin hablar del tiempo (de ejecución) que implica hacer el mapeo objetos/relacional todo el tiempo. Ciclos del tipo: Leer datos de la DB -> instanciar objetos con esos datos -> mostrar los objetos para su modificación -> pasar los datos de los objetos a la DB no son excepciones.


Estas son algunas cosas que, creo, deberíamos preguntarnos los programadores:

  • ¿Cuantas tablas, en las bases de datos relacionales, no tienen más que unos pocos cientos de registros?

  • ¿Y cuanta duplicación genera el modelo relacional? o más concretamente: ¿Cuanto ocupan, en las bases de datos relacionales, 1000 clientes que se llamen todos “Juan Pérez”?

  • ¿Cuantos objetos entran en los 512Mb de RAM que tiene mi notebook?



Entonces, ¿Cuál es la alternativa?

Por supuesto que no hay sólo una alternativa, pero me gustaría detenerme sobre una de ellas. La que más me gusta, la más simple, la más barata y que puede usarse en un porcentaje muy alto de proyectos:

Use the RAM memory, Luke!
(¡Usá la memoría RAM, Luke!)


La solución es muy simple: Guardar todos los objetos en la imagen de Smalltalk o, si no usan Smalltalk, la solución sería tener todo en memoria y deserializar/serializar al arrancar/detener el sistema.

Si, ya se que parece una solución naive y que me estoy olvidando de cosas muy serias como acceso concurrente, seguridad, políticas de lockeo, etc. En realidad no me estoy olvidando de esos temas, sólo les digo que con el tiempo de desarrollo que se van a ahorrar si no usan bases de datos relacionales les va a sobrar para atender a todos esos puntos.

viernes, septiembre 09, 2005

Plataforma de Educación para Indígenas utilizando Squeak

Wuilmer Olaya Bardales, desde Lima - Perú, anunció en la lista de correo de Small-Land la puesta en marcha de una plataforma de e-learning que utiliza Squeak.

El email original dice:

Hola amigos, les envio el link de la plataforma e-learning para la
comunidad ashaninka de Perú, donde estamos utilizando Squeak para
elaborar contenidos ( http://www.fopecal.org/peruindigena/ashaninka/ )

Les agradecería que la visiten y me hagan llegar sus observaciones tanto
de la Plataforma como del contenido en Squeak.

Si me pudieran dar referencias de otras plataformas que utilicen Squeak
para elaborar contenidos se lo agradecería.

Wuilmer Olaya Bardales
Lima - Perú

Para siempre es mucho tiempo

Una (otra¿?) nota que versa sobre la ya famosa licencia de Squeak.



viernes, septiembre 02, 2005

El wiki de Nicolás Gómez Deck


Mi hijo, de 8 años, Nicolás tiene su propio wiki donde nos cuenta las cosas que le vienen en ganas.

En la foto estamos, de izquierda a derecha, Alan Kay, Nico y yo.

Perdonen la frivolidad.

La magia del Smalltalk: Capítulo 11 - Manteniendo la identidad



Ya hemos hablado, en posts anteriores, de la identidad de los objetos en Smalltalk y como eso impacta en la forma de trabajo.

En los lenguajes de programación "tradicionales" los objetos no pueden sobrevivir a una ejecución del programa. Por eso se usan técnicas donde se reemplaza la identidad con IDs, claves únicas, etc.

También es muy frecuente encontrar programas donde más de una instancia en el modelo por cada objeto real con los consiguientes típicos problemas de duplicación. Ni hablar de los casos típicos de tener objetos que no pueden sobrevivir una conexión/sesión/etc. He visto muchos sistemas donde lo único importante, para el funcionamiento interno, es el ID de los objetos.



A grandes problemas, soluciones simples: Cuando modelamos la realidad (es decir, cuando estamos programando) conviene vincular el ciclo de vida de nuestros objetos al ciclo de vida de los objetos de la vida real.

Por ejemplo: Si estamos modelando uno de esos clásicos sistemas de facturación, conviene que los objetos ArticuloDeVenta de nuestro modelo vivan tanto como viven los Artículos de Venta reales. Si tenemos un artículo para la venta disponible por 10 años, conviene que la instancia que representa a dicho artículo viva los mismos 10 años. Si tenemos sólo 1 artículo real para la venta, no instanciamos más 1 instancia en nuestro modelo.

En un mundo ideal, instanciamos en nuestro ambiente el artículo en cuanto la empresa decide venderlo y este objeto desaparecerá cuando nadie lo use ni lo recuerde.

Lamentablemente el mundo dista bastante de ser ideal y muchas veces tenemos que convivir con feas bases de datos relacionales, archivos de texto y demás cosas que no nos permiten utilizar la identidad de Smalltalk ya que los objetos "viven" fuera.

Supongamos que tenemos que hacer un lindo sistemita en Smalltalk que tenga que ir a buscar los datos a una fea base de datos relacional. Esa base de datos se actualiza desde fuera de nuestro programa, así que tenemos que descartar la alternativa de importar todos los datos a nuestra imagen.

Una solución muy elegante es mantener la identidad dentro de nuestro ambiente siempre que sea necesario. Para eso tendremos en nuestro (casi seguro Singleton) objeto Sistema (el sistema es un objeto, ¿no?) un método del tipo #findXXXByID:.

Veamos un poco de código usando la recién estrenada opción “copiar como html" que acabo de subir al update-stream del Squeak de Small-Land versión 3.8.

SampleSystem>>initialize
    "initialize the receiver"
    customers := WeakValueDictionary new


SampleSystem>>findCustomerByID: aString
    "Answer the customer represented by the given ID"
    | customer |

    customer := customers
                            at: aString
                            ifAbsent: [nil].

    ^ customer
                ifNil: [self loadCustomerID: aString].


SampleSystem>>loadCustomerID: aString
    "PRIVATE - load the data from the outer space"
    << CARGAR LOS DATOS DE LA BASE DE DATOS Y CREAR UNA INSTANCIA >>


Gran parte del truco de este idiom/patrón/nombreQueLesGuste reside en usar el diccionario WeakValueDictionary. Ese diccionario mantiene una referencia débil (Weak), una referencia débil es una forma de referenciar a un objeto que NO evita que el garbage collector lo elimine.

La forma de utilizar referencias débiles es muy sencilla, se guardan los objetos en este tipo de colecciones (WeakValueDictionary, WeakKeyDictionary, WeakSet, WeakArray, etc.) y estos vivirán mientras alguien mantenga una referencia fuerte (una referencia normalita, las de toda la vida). Si el objeto está sólo referenciado en forma débil, en algún momento el garbage collector se lo llevará y nos dejará un nil en su lugar. Así que la única precaución que debemos tomar es considerar que la colección nos devuelva un nil.

Veamos el código de arriba... mientras alguien mantenga una referencia fuerte (las normales, las de toda la vida) el WeakValueDictionary va a mantener una referencia débil y nuestro método #findCustomerByID: devolverá siempre esa misma instancia manteniendo la identidad. Para el mismo ID siempre devolvemos la misma instancia. En cuanto todos se olviden del objeto en cuestión, y el garbage collector decida llevarse la instancia, nuestra colección olvidará al customer en cuestión.