el blog de cHagHi

Y así pasaron las 8vas. Jornadas Regionales de Software Libre.

Para mi fueron las primeras, gracias a que fueron en Buenos Aires, y las viví como una "CaFeConf on steroids" :p
Lamentablemente son muchos días hábiles (3), y es complicado coordinar en el laburo la oportunidad de ir todos los días, quizás no por el contenido (al fin y al cabo, en el trabajo varias de nuestras core-tools son software libre), pero sí por el tiempo. Es muy difícil "desaparecer" 3 días. En años anteriores, a la complejidad extra de que las jornadas eran en alguna otra provincia, se sumó que coincidieron con la implementación de algún proyecto. Este año, estamos teniendo (¡por suerte!) un mediados-de-agosto tranquilo, y pude organizar las cosas para asisitir a las charlas que más me interesaban.

También mi participación esta vez fue meramente como expectador (comparando con CaFeConf 2006 y 2007). No es que otros años haya organizado nada... pero al menos, participaba más activamente del stand de PyAr, y de la presencia de PyAr en el evento, al menos aportando ideas. Esta vez, ni eso. Quizás tiene un poco que ver con que PyAr ya lleva varios años participando en estas cosas... y todo sale más de taquito.

Anyway, hay ciertas cosas que deberíamos aprender a distribuir mejor. Por ejemplo, para el pobre de Facu, la "carga" de ser una de las estrellas de PyAr, una de las personas más consultadas, organizar y dar dos charlas, asistir a Raymond Hettinger, coordinar afuera ayuda de la PSF, conseguir libros de O'Reilly para sortear, organizar el sorteo, organizar el concurso de diseño, proceso de selección, confección, y posterior venta de las remeras, y darse el lujo de además colaborar con la organización general de las 8JRSL... es *MUCHO*. Ojo, no dudo que lo disfruta, lo hace por que le gusta, y que mucha otra gente colabora con él en muchas cosas... pero el punto es que PyAr creció mucho, sigue creciendo, y no se... me queda una crítica mínimo a mi mismo por no involucrarme más (de hecho al contrario, estoy menos involucrado de lo que estaba hace un par de años), y tomar la posta para por ejemplo dar una mano con las remeras, que consume un montón de tiempo. Si bien hay cosas en las que es más complicado colaborar (ejemplo, lo de O'Reilly es mucho mejor / más fácil si lo coordina Facu como mimbro de la PSF, que si lo hace un "don nadie"), hay muchas otras cosas para hacer.

El stand de PyAr funcionó re-bien (¡como siempre!), y también se repitió la historia de que en general, los stands de "la comunidad" funcionan mucho mejor que los formales y aburridos stands de las empresas que van solo a venderse.

De las charlas que fui, me quedo con las de Raymond Hettinger; aprendí *un montón* de cositas interesantes de Python. En particular, el tutorial sobre descriptores fue bastante mind-blowing para mí, y terminó gustándome más que la charla sobre core containers.

¿Qué más? Tuvimos nuestra reunión de PyAr, la 31... creo, con record absoluto de gente, de la cual tengo pendiente redactar la minuta. Gracias a toda la gente que vino a Capital Federeal para participar de las jornadas, fue también una reunión realmente "federal", con presencia de gente de varios lugares.

¡Me gané un libro! ¡Sí! Nunca me gano NADA en ningún sorteo... así que fue completamente inesperado. Y qué libro... Programming Python, de Mark Lutz. Unas 1500 páginas. Una Biblia. Gracias PyAr, gracias O'Reilly, y gracias Facu por organizarlo.

No saqué fotos. Eventualmente iré posteando links a las fotos que publiquen otros miembros de PyAr.

¡Bien! La beta4 de IronPython 2.0 va a incluir la librería estándar de Python. En el laburo estamos usando bastante IronPython para algunas herramientas internas. Y siempre me molestó que por un lado hacían un laburo realmente MUY BUENO en brindar un runtime de Python perfectamente integrado con .NET, y por el otro... le sacaban las baterías (para los no iniciados: solemos decir que "Python viene con las baterías incluídas", por lo amplia, útil y poderosa que es la librería estándar que uno obtiene out-of-the-box cuando lo instala).

La realidad es que no van a incluir TODA la stdlib; hay cosas que hoy por hoy ya se sabe que no funcionan (mayormente, módulos que en todo o en parte están implementados en C, y para los cuales no se hizo ningún wrapper "managed" del lado de .NET). Pero es algo.

Otro punto positivo: IronPython 2.0 va a salir con una licencia dual: La licencia MS-PL de Microsoft, que cubre IronPython, y la Python Software Foundation License, cubriendo la stdlib. Esto es todo un hito: MS acepta, y reconoce, la licencia de la PSF. Según comentan en otro blog, hasta hubo abogados de por medio para poder dar este paso. Bien por la PSF, bien por el software libre, y bien MS.

IronPython 2.0 va a ser compatible con Python 2.5, lo cual agregará varios chiches por sobre 1.1, y probablemente habilitará a que funcionen algunos módulos de terceros que hoy por hoy no funcionan.

Aún tengo pendiente probar todo esto; en particular, quiero aprovechar estas últimas betas para verificar que nuestras herramientas funcionen correctamente con el nuevo runtime.

(gracias Facu por pasarme la data)

 

En el trabajo ya hace bastante tiempo estamos usando Trac, con bastante éxito. Tiene sus limitaciones, ya que manejamos muchos proyectos, y sobretodo para la gente que tiene que coordinar más de un proyecto, se vuelve muy tediosa la falta de una "vista consolidada" que permita consultar y administrar al conjunto de proyectos como un todo. Por ejemplo, responder la pregunta "¿cuántos tickets tiene asignados fulano en TODOS los proyectos en los que está?" es complicado.

Esa parte la resolvió Diego exportando cada N tiempo cada una de las bases de datos SQLite de cada proyecto a una base de datos dentro de SQLServer, y ahora se están desarrollando varios reportes usando las herramientas estándares de la consultora. La desventaja es que la información es un snapshot (i.e., no tenemos la info en tiempo real, actualizada al instante), la enorme ventaja es que estamos pudiendo explotar la info de Trac de una manera mucho más rica, a la vez que nos permite una integración mucho más fuerte con nuestras otras herramientas. En cuanto a esta parte del dilema (consolidación de la información), la pata que está faltando es interactuar con Trac, es decir, no solo consultar la info, sino por ejemplo hacer operaciones masivas, del estilo seleccionar N tickets de X proyectos que cumplen tal criteria y cerrarlos. Diego está experimentando con una especie de RPC casero haciendo POSTs a Trac, yo tengo pendiente instalar en un entorno de prueba el XmlRpcPlugin y ver si nos da alguna ventaja.

Otro problema que teníamos era la consistencia entre proyectos en cuanto a "Prioridades", "Tipos de tickets", "Severidades", etc., etc., más cuestiones como definir que componentes por defecto están activos, que usuarios tienen que permisos, etc. Eso lo resolvimos haciendo un wrapper alrededor de TracAdmin. Pero no "trac-admin" el comando, sino TracAdmin a nivel de componente. Este wrapper puede usarse por línea de comandos o como un servicio web (que invocamos por ejemplo desde una página de creación de proyectos), y "sabe" hacer un initenv usando todos nuestros defaults: borra las cosas que no necesitamos, agrega las que sí, setea defaults y permisos, etc. Así cualquiera puede inicializar un nuevo proyecto en Trac con total confianza de no olvidarse ningún paso, y de que va a cumplir con nuestro estándar interno. Y el 99% de las cosas que hace este wrapper están definidas en un archivo externo de configuración, con lo cual es simple modificar / extender lo que hace.

Sacando esos dos grandes temas, aún tenemos pendientes varios detalles mas finitos, varios de los cuales son candidatos a o bien encontrar un plug-in en Trac Hacks que nos de la funcionalidad requerida, o implementar nuestro propio plug-in. Uno de esos temas tiene que ver con que Trac 0.10 no maneja workflows, la versión 0.11 se sigue demorando... y demoraaaaaaando, y estábamos necesitando empezar a validar ciertas cosas, en particular, de consistencia de valores de algunos campos al cerrar un ticket. Así que con un poco de expermientación del finde, más un ratito hoy en el trabajo para afinar detalles, me largué a escribir mi primer plugin para Trac.

Es realmente MUY fácil. La mayor parte del tiempo la invertí investigando de cual de tooooooooodos los puntos de extensión que expone Trac tenía que colgarme para hacer lo que yo quería. Una vez descubierto eso, fue muy sencillo. Quería validar el ticket al grabar cambios. La interfaz a implementar resultó ser ITicketManipulator. Macheteandome un poco en el código SpamFilterPlugin, y leyendo la MUY buena doc de Trac, el resto fue coser y cantar.

No publico el código completo porque está muy pegado a lo que hacemos internamente en el trabajo, pero en esencia, el core del plug-in es algo así:

from trac.core import *
from trac.ticket import ITicketManipulator, TicketSystem

class RechazarTicket(TracError):
  """Excepcion a generar si el ticket es inválido."""

class MiValidator(Component):
  implements(ITicketManipulator)

  # Métodos de ITicketManipulator

  def prepare_ticket(self, req, ticket, fields, actions):
    pass

  def validate_ticket(self, req, ticket):
    if 'preview' in req.args:
      # Si es un preview, y no estamos grabando, no validamos nada
      return []

    if ticket['status'] != 'closed':
      if ticket['version'] in ('XXX', 'YYY'):
        raise RechazarTicket('La versión %s solo es válida si el ticket está cerrado.' % ticket['version'])
      # El ticket aún no está cerrado: No validamos nada más
      return []

    # Recuperamos todos los campos que NO son de texto
    fields = [f['name'] for f in
              TicketSystem(self.env).get_ticket_fields()
              if f['type'] not in ('textarea', 'text')]
    for field in fields:
      # Acá implemento las validaciones que quiera...
      # "field" tiene el nombre del campo (ej., "version", "status", etc.)
      # puedo acceder al valor haciendo
      #    ticket[field]
      # y puedo ver el valor anterior (para ver si se está modificando) haciendo
      #    ticket._old[field]
      # Si alguna de mis validaciones custom no se cumple, se hace un
      # raise de RechazarTicket... y listo.

    return []

Como ven, muy fácil. Ahora entiendo un poco más por qué en Trac Hacks hay TANTAS cosas... es que realmente es simple extender Trac. Ahora que rompimos el hielo con este primer plugin... probablemente se vengan más a futuro.

 

El sábado se realizó el Ciclo de Charlas UNLUX 2007, "Conectando Puntos", organizado por el Grupo de Usuarios de Software Libre de la Universidad Nacional de Luján (UNLUX para los amigos :p)

Evento que tuvo el "honor" de ser auspiciado por PyAr. ¿Será un honor? Jeje... hablando en serio, el honor fue nuestro, y marca un hito. Esperemos que en adelante podamos seguir auspiciando estos eventos.

Otro punto que hace especial a este ciclo de charlas es que fue generado desde adentro de una universidad, y eso es fantástico. Las universidades tendrían que tener un contacto MUCHO más grande con el software libre del que tienen... por una cuestión de soberanía y autonomía, por una cuestión de flexibilidad a la hora de adaptar el software a sus necesidades, por una cuestión pedagógica, especialmente en carreras de informática, dada por la posibilidad de de ver y modificar el código fuente, y como si todo eso fuera poco, por una cuestión económica.

Este fue el primer ciclo de charlas organizado por el UNLUX, y fue todo un éxito. Mucha más gente de la que esperábamos (el puntapié inicial de estas cosas no siempre tiene la convocatoria que uno quisiera), y la organización estuvo muy prolija. Hasta los chicos tuvieron que capear un corte de luz general de varias horas en toda la universidad.

Hubo una gran cantidad de charlas, de diversos temas. Obviamente, Python estuvo ahí, como corresponde :)

Luego del cierre de las charlas, gran parte de los organizadores, disertantes, un grupo de PyAr y algunos otros asistentes nos fuimos a festejar, cenar y pasar un rato agradable a una pizzería.

Facundo escribió un review bastante detallado del evento en este post.

Por último, si quieren fotos... las mías están en este álbum. Los chicos de UNLUX también publicaron fotos en su site, en el álbum CDC -> 2007 :: Conectando puntos. Y Facundo subió más fotos acá.

 

Y así pasaron las Sextas Conferencias Abiertas de Software Libre y GNU/Linux.

Al igual que el año pasado, Python fue el lenguaje con más presencia en las conferencias, tanto en charlas, como en "comunidad". Esto es un logro de todo PyAr, pero creo que merece ser destacado el esfuerzo de Alecu, Dani, Dave, Lucio y Facu generando contenido, y el de los chicos de Santa Fe y Córdoba, siempre presentes. Como siempre, y a pesar de los reparos que yo en lo personal tengo al respecto, pyWeek vende. Y tener dos OLPC (gracias Educ.ar!) en el stand para mostrar, fue como tener un tarro de miel a un metro de un hormiguero... :)

Otro "debut" de este año fue la cartelera de trabajo, organizada por Alecu: http://python.com.ar/trabajos. Además de su contrapartida web, estuvo "físicamente" en forma de un gran afiche junto a nuestro stand, y todo el tiempo ví gente tomando nota.

Hubo muchas menos charlas que el año pasado, y creo que eso es un plus. Como comentábamos con los chicos de Lanux anoche, eso ayudó a subir el nivel: Hubo mucha menos superposición de contenidos, y más gente en cada charla. No si es esto fue casual o la gente de CaFeLUG específicamente buscó este efecto... pero es para tomar nota.

De las charlas a las que asistí, me quedo en especial con dos:

• "Python más rápido que C", por Lucio Torre y Facundo Batista. Una muy entretenida e ilustrativa charla para mostrar que sí, que a veces Python es (bueno, casi...) más rápido que C, y que otras tantas, C es más rápido pero, ¿vale la pena el esfuerzo? Habían generado mucha espectativa con su charla, el título de entrada fue un gancho de marketing fenomenal. Y salieron muy bien parados de la prueba. Felicitaciones.

• "Caperucita en el Bosque", por Enrique Chaparro, de la Fundación Vía Libre. Excelente. Sumamente ocurrente, en cuanto a usar el cuento de caperucita roja como analogía e hilo conductor de la charla. Muy amena. Y muy ilustrativa. Esta fue la "Key note", la única charla plenaria. Espero que se haya grabado... traten de buscarla, bájenla y véanla. Vale la pena.

El cierre de CaFeConf quedó una vez más a cargo de Leito Monk, y al igual que el año pasado, estuvo absolutamente desopilante. NADIE, absolutamente NADIE se esperaba verlo entrar al escenario disfrazado de pingüino, y gritando "developers! developers! developers!" La organización de todo el evento estuvo muy bien, realmente la muchachada de CaFeLUG labura un montón para esto... y se nota. Gracias!

El único punto "flaco", al igual que el año pasado, fue el lugar: UADE no es el mejor ámbito para estas conferencias. Los cacheos de seguridad, LENTOS y BUROCRATICOS son sumamente molestos. Así y todo, desapareció una laptop. Y algo me dice que UADE va a mirar seguramente para otro lado (ojalá que no... but I'm not holding my breath...). Pero bueno, por ahora, es lo que hay. 

En cuanto al aspecto puramente social y pythonico, la noche del viernes nos fuimos a tomar unas cervezas por San Telmo. La excusa oficial fue festejar los buenos resultados de los grupos argentinos en la última edición de pyWeek... y terminó siendo una pseudo-reunión de PyAr. Luego de pasar un rato en una coqueta parrilla de San Telmo de la cual no recuerdo el nombre (ni lo quiero recordar...), en la que solo tomamos unas cervezas, terminamos en la pizzería Tío Felipe, en Balcarce y San Lorenzo. BUENISIMO. La pasamos genial. Y como siempre, los lugares más tradicionales, más "de barrio", son los mejores. Si alguien de Tío Felipe lee esto: Sigan así. No se dejen aggiornar por la movida "transformemos San Telmo en un lugar solo apto para europeos con euros". Ojo, no tengo NADA en contra del turismo europeo... solo de los comerciantes inescrupulosos argentinos que arman una mentira cara para vender a los turistas, que NO tiene nada que ver con la escencia de uno de los barrios más antiguos y tradicionales de Bs. As., y hacen que solo puedas salir a comer afuera por la zona si a), te creés la mentira y b) estás dispuesto a pagar por un servicio que no lo vale.

La noche del sábado, un pequeñísimo grupo de PyAr (Dave, Alecu y yo) acompañamos a los chicos de Lanux a tomar algo... oooootra vez, una muy buena cervezeada con picada y pizza, en el local de Zapi de Independencia y Perú.

Fotos, fotos y más fotos.

 

IronPython, como buena implementación de Python, provee una consola interactiva.

Tiene un gran problema: En linux, anda MUY mal. Al menos en Ubuntu, desde gnome-terminal, suckea. Mucho. Pero que mucho. En Windows, anda un poquitín mejor. Por ejemplo, uno puede apretar backspace y sucede esa cosa mágica de borrar el caracter a la izquierda del cursor y todo!!! En linux, por default, ni eso.

Este finde estuve por primera vez en varios meses usando en serio IronPython, y si bien los ajustes finales de este mini-proyecto los terminé sobre .NET en Windows, arranqué trabajando con Mono en Linux. Y trabajar con Python con una consola que NO funciona, es desesperante. Me cansé de googlear buscando soluciones... y no encontré nada. Mi última búsqueda fue "ironpython console on linux sucks". Y para mi sorpresa, no arrojó resultados significativos. Porque IT REALLY SUCKS! Al toque empecé con mis teorías conspirativas, en la línea "claro, ahora que es un proyecto de Microsoft, no nos importa como anda en Linux". Pero no tenía sentido... porque debería haber una legión de usuarios de Linux/Mono descontentos. Y si Google no los encontraba, ¿dónde estaban? No cerraba. Evidentemente *yo* estaba haciendo algo mal.

Y ahí fue cuando entre tantas vueltas, descubrí que la consola de IronPython se puede iniciar con una serie de opciones... y al toque 3 llamaron poderosamente mi atención:

 -X:AutoIndent        Automatically insert indentation
 -X:ColorfulConsole   Enable ColorfulConsole
 -X:TabCompletion     Enable TabCompletion mode

Si bien a priori no tenían que ver con mi problema (que es un manejo absolutamente BROKEN de las secuencias de escape, movimiento del cursor y demás), decidí probar. Y para mi sorpresa... no solo gané color, tab-completion (bastante similar a la que ofrece iPython) y auto-indent... sino que con esas opciones se resuelven los demás problemas!!! Fantástico. No se cual de las 3 hace la magia (sinceramente no lo probé... se los dejo como tarea para el hogar) pero sospecho que la opción salvadora debe ser -X:ColorfulConsole, que para manejar el color debe usar otra librería para interactuar con la consola.

Así que ahora tengo en mi .bash_aliases lo siguiente:

alias ipy='ipy -X:AutoIndent -X:ColorfulConsole -X:TabCompletion'

... de manera que cuando ejecuto 'ipy' (el intérprete de IronPython), lo hago con las opciones correctas. Y me pregunto por qué mierda esas opciones no están activas por default, y/o por qué Ubuntu no las activa por default. Porque la diferencia es ABISMAL.

Bonus-track: Esas opciones son también útiles en Windows. 

 

En varios posts anteriores creo haber mencionado (a veces al pasar, y a veces no tanto), al generador de código que usamos en el laburo en los desarrollos .NET, a quien su autor, Darío, denominó Exodus. No, el nombre no es arbitrario... pero en todo caso le tocará a Darío algún día escribir sobre ello en su propio blog... :)

Sin entrar en detalles (je! a ver si avivamos giles y perdemos la ventaja competitiva que nos da!), digamos que es una herramienta mediante la cual se define el "dominio" de una aplicación, generalmente haciendo algo de introspección sobre el modelo de datos (o sea, sobre la base de datos a usar), y genera automáticamente un montón de código boilerplate: el mapeo entre el ORM y la base de datos, "finders" para recuperar datos, consultas y ABMs estándares (al estilo de las que genera por ejemplo Django), las fachadas y business delegates (en el laburo, a pesar de usar .NET, usamos muchos de los patrones arquitectónicos de J2EE) y un sinfín de cosas más.

La herramienta es fantástica, e imprescindible: Creo que sería imposible desarrollar sistemas del tamaño de los que estamos generando, si tuviéramos que escribir todo eso a mano, cada vez (y si cada vez que tocáramos el modelo de datos, tuviéramos que ir manualmente a reajustar TODOS los lugares en los que pega). A pesar de todo, desde el comienzo que hay algo que me "molesta" (muy entre comillas, porque en definitiva, FUNCIONA, y bien), y es que internamente, el core de Exodus no deja de ser un template engine, que toma una descripción del dominio de la aplicación, y una serie de plantillas, y escupe código (o más académicamente hablando, "text artifacts" (¿ahí les gusta más?)). Y el problema es que usa un template engine custom, y peor, ese template engine usa un lenguaje scripting custom, que tiene varias limitaciones (se han tenido que hacer cosas "raras" en las plantillas, y en el código generado, por limitaciones en los tipos de datos que maneja este lenguaje, por ejemplo). Y sobre todo, es LENTO. Esto hasta ahora no era un problema, pero en el proyecto en el que estoy trabajando desde hace varios meses, que es MUY MUY grande, regenerar código lleva más de 10 minutos.

Ninguna de las dos cosas constituyen una limitación "insalvable". De nuevo, funciona, funciona ok, el código no se regenera a cada rato, no todos los proyectos son tan grandes, y cada vez que nos topamos con alguna limitación a nivel de templates... Darío encontró un workarround.

Pero la cuestión es que a mí el tema me seguía dando vueltas en la cabeza... y siempre tenía en la cabeza una vocesita diciendo "que bien que vendría Python y alguno de los tantos templates engines que tiene acá..."  Encima, Exodus desde hace un tiempo atrás tiene embebida una consola de IronPython, que sirve para levantar "on-the-fly" el modelo antes de generar código, y jugar un poquito. Todavía no le hemos dado mucho vuelo... pero es cool :)

Hace unos meses atrás, mejorando el esquema de remoting estándar que usan nuestras aplicaciones, se presentó un problema "recursivo": Ciertos Business Delegates dependían del código escrito por nosotros (no del auto-generado), con lo cual en principio no se podían generar con Exodus... y ahí nació "Exoditus", que no es más que un hook de post-compilación de parte del proyecto que levanta el core de Exodus, levanta el assembly recién compilado con la lógica de negocios, mediante reflection extrae algunas propiedades, genera código adicional, y sigue compilando. Nice.

Este fin de semana, decidí poner manos a la obra, y ver si podía, como experimento y prueba de concepto, re-escribir Exoditus en IronPython. Elegí Exoditus porque es lo más fácil de reemplazar. Hoy por hoy, aunque la idea funcione, reescribir todos los templates y modificar Exodus para que "dialogue" con este esquema ya no es tan trivial (aunque tampoco lo veo como algo muy complejo). En cambio Exoditus bien puede no depender para nada de Exodus; es un paso intermedio en la compilación. Nada más. Y solo UN template.

Bueno, el experimento funcionó. La parte más compleja, fue encontrar un template engine que funcionara BIEN en IronPyhon. Los template engines que hay suelen (todos) hacer uso de mucha magia negra y de features de CPython que aún no funcionan en IronPython. Luego de algunas pruebas, y con la ayuda de Google, el candidato elegido fue Cheetah. Buenísimo. Quizás no sea el ciudadano más ilustre por estos días, con todo el buzz alrededor de Django, TurboGears y cía., y los template engines orientados al desarrollo web. Pero es un producto maduro, estable, en producción, rápido... y MUY poderoso.

Así que prueba superada: pyExoditus se compone de +/-90 líneas de código, de los cuales el 70% se va en dos métodos que realizan introspección sobre un assembly que recibe como parámetro, para extraer nombres de clases y métodos que cumplen ciertos patrones, un template, Cheetah, y unos 32 módulos de la stdlib de Python (me tomé el laburo de identificar uno a uno cuales eran, para poder armar un "paquete" autocontenido con todo lo necesario que no requiera tener CPython instalado para andar). La buena noticia: No solo anda, sino que anda sensiblemente más rápido :)

No se si terminará metido o no en nuestro estándar de desarrollo... pero en cualquier caso, fue divertido y productivo. Y si termina metido, quizás sea el primer paso para apuntar a otro objetivo: Darío está en estos momentos escribiendo la versión 2.0 de Exodus, con muchas mejoras y cambios estructurales... quizás... solo quizás, Exodus 2.0 podría usar como template engine a Cheetah, y como scripting language a Python...

 

Hace algunas semanas que estoy leyendo la doc y haciendo algunos experimentos "caseros" (descolgados, sin ningún propósito concreto de momento) con SQLAlchemy.

SQLAlchemy es, al mismo tiempo, un set de herramientas de acceso a SQL  y un ORM. Y resalto el "y". Es la primera herramienta de estas características que veo que implementa este concepto de separar claramente, e incluso como cosas usables de manera independiente, las dos caras de la moneda: El "lidiar" con SQL desde una aplicación (sobretodo para consultas), y el mapear un modelo de objetos a una base de datos.

Traducción libre de la página principal del sitio:

Las bases de datos SQL se alejan más del comportamiento de una colección de objetos a medida que la performance y el tamaño de la base de datos se vuelve más importante; las colecciones de objetos se alejan más de conceptos como tablas y filas conforme la abstracción se vuelve más importante. SQLAlchemy intenta acomodar simultáneamente estos principios.

SQLAlchemy no ve a las bases de datos sólo como una colección de tablas; las ve como motores de álgebra relacional. Su ORM permite mapear clases contra una base de datos de varias formas distintas. Las sentencias SQL no solamente consultan tablas—es posible realizar consultas de joins, subqueries y uniones. Así, las relaciones de la base de datos y el modelo de objetos se desacoplan desde el principio, permitiendo que los dos conceptos se exploten a su máximo potencial.

Realmente esto no es marketing, cuando uno empieza a usar la herramienta y analizar los ejemplos en la documentación, se ve claramente que esta filosofía se aplica... y da frutos. De todos los ORM existentes para Python, creo que SQLAlchemy es el único considerado "de verdad", es decir, que podría usarse en escenarios más complejos de la simple aplicación web con 3 o 4 ABMs que normalmente se desarrollan con Django o TurboGears. Es a su vez uno de los más nuevos, pero ha tomado la comunidad "por asalto", y me atrevo a especular que es por lejos el que más rápidamente ha avanzado (y continúa avanzando...)

SQLAlchemy escala hacia arriba... y hacia abajo. Por ejemplo, está creciendo bastante también un proyecto, Elixir, que implementa una capa "declarativa" sobre SQLAlchemy que resuelve de una manera sencilla e intuitiva (muy al estilo del Active Record de Ruby on Rails) los casos más comunes.

Por último (y esto no es exclusivo de SQLAlchemy, sino extensivo a todos los otros ORMs para Python): Cuánto más "lindo" es un ORM con un lenguaje dinámico. Cuando hay que acercar los mundos de SQL y OOP en Java o C#, se nota mucho el overhead de jerarquías de clases y abstracciones e interfaces que se "apilan" para lograr algo extensible y robusto... y que adhiera a las restricciones del tipado estático. Con Python (o Ruby), se puede crear el puente, igualmente extensible y robusto, de una manera mucho más directa. Gracias a Dios Darío en el laburo tenemos un excelente generador de código que nos resuelve automágicamente toda la parafernalia de código extra... si no lo tuviéramos, calculo que estaría pidiendo a gritos que laburemos con otra cosa... jeje.

 

Pongámonos al día. Lamento si el título del post confunde a los web spiders... but so be it :)

El viernes pasado cumplimos con Facu el viejo "proyecto" de ir a tomar chocolate con churros a La Giralda. El día no podría haber estado mejor: Frío, lluvioso... especial para un "chocolate espeso con churros", la especialidad de la casa. Fuimos ahí porque es como un clásico, y está este mito urbano de que "el" lugar para tomar chocolate con churros en Baires es La Giralda. ¿Estuvo bueno? Si. ¿Es para cortarse las venas? No. El lugar es pintoresco... tanto como tantas otras viejas confiterías y bares de Bs. As. que aún están en pie, y mantienen su mobiliario y decoración original. Hay mucha gente, la atención es buena, el servicio rápido, y los precios razonables. Pero el chocolate hecho por mi vieja, mi tía, mi abuela (en mi familia hay cierto rito por ejemplo de tomar chocolate el domingo de Pascuas) no tiene NADA que envidiarle. Y los churros están buenos, sí, pero no espectaculares. Podrían haber estado más frescos, por ejemplo. El churro es algo que hay que hacer y comer relativamente en el momento. La masa no se lleva bien con la humedad, Baires es húmedo, y el viernes el día era un pegote. Mala combinación si vas a tener los churros preparados de antemano.

Después vimos un par de capítulos de Cosmos. Sí, aquella serie "Cosmos" de Carl Sagan hecha para TV, que se corresponde con el libro homónimo. Resulta que hace ya una pila de tiempo que tengo los DVDs, pero cuesta hacerse el tiempo para verlos. Ya llevamos 4 episodios (¿o 5?), y si no subimos el ritmo (hasta ahora, un pobre dos por año), nos vamos a jubilar antes de llegar al 13.

Aprovechamos para hablar un poco de Python. Básicamente porque quiero engancharme en algún proyecto con Python, y no termino de definir cual, si sumarme a algo, si arrancar algo por mi cuenta... tengo el tiempo y la motivación. Quiero volver a tener el hobby de meterme en un proyecto en el que programar sea divertido, y no tengas todo el tiempo que luchar contra imposiciones y complejidades de una tecnología (y/o lenguaje) que todo el tiempo se mete en medio de lo que querés lograr, o te hace perder el 50% del tiempo de desarrollo compilando, debuggeando, esperando al IDE, etc. Y el único lenguaje que conozco que cumple esa premisa hasta ahora es Python :)

Tengo ganas de hacer algo web, para meterme más en TurboGears, o Django, o Pylons, pero no tiene mucho sentido hacer algo web si uno luego no va a dar un servicio. Tampoco quiero meterme en un proyecto demasiado grande... me gustaría poder ver resultados más rápido, y no quisiera lidiar con un codebase enorme, viejo, parchado (sí, en Python también se pueden hacer chanchadas...). Veremos que sale de todo esto.

Parte de la motivación de hacer algo web tiene que ver con que últimamente estoy usando bastante Netvibes y RememberTheMilk. Cada uno en lo suyo los dos sites tienen muchas cosas interesantísimas de usabilidad en una aplicación web que me parece muy piola extrapolar a otros escenarios. Así que básicamente tenía ganas de hacer algo en lo que pueda ver hasta donde se puede lograr este tipo de cosas con muuuuuucho AJAX usando, por ejemplo, Django.

Para terminar este "catch up", el sábado mi prima Agus festejó sus 15. Puf...! Ratazo que no iba a una fiesta de 15. Creo que la última fue la de Flor, su hermana... y de eso hace ya bastante tiempo. Nos divertimos mucho, me puse al día con los usos y costumbres (que siempre van cambiando). Por ejemplo: Ahora se usa que las amigas más íntimas de la cumpleañera le armen un baile, una coreografía, con vestuario y todo, sobre algún tema musical. Y no voy a comentar más, porque después van a decir que soy un depravado. :) Además, vino especialmente de Yankeelandia Fede para estar presente en calidad de hermano mayor en el evento, así que de paso nos pusimos al día.

Algo que me llamó la atención fue la música: Es básicamente *la misma* que se escuchaba "en mi época" (Dios! me siento un viejo choto diciendo eso...). Más o menos remixada, con algún ritmo cambiado, cantada por otro intérprete/banda, pero la misma. La excepción es alguna que otra cumbia. Pero nada más. Raro. Uno espera escuchar la misma música en los casamientos de mis amigos, por ejemplo, porque bueno, compartimos una generación. Pero no en un cumpleaños de 15. Creo que eso demuestra lo pobre que está el escenario musical hoy en día: O te vas a la cumbia (por goleada, el ritmo más fructífero de los últimos años), o te vas a la música electrónica (que en una fiesta así, heterogénea, es insoportable, y supongo que por eso no se pasa), o tenés que caer en los clásicos (y no tanto) de hace 10, 15, 20 o más años. Es que en lo que respecta a Pop / Rock... el terreno tiene cada vez más vacantes.

 

Acabo de enterarme de un proyecto de Mozilla, ActionMonkey, que cuenta con el apoyo de Adobe, que es la fusión de otros dos proyectos que no sabía que estaban en danza: Tamarin y SpiderMonkey. ¿Y para qué tantos proyectos y siglas? Para lograr que en un futuro, se pueda usar IronPython e IronRuby (las implementaciones .NET de Python y Ruby), de la misma forma que hoy se usa JavaScript.

Es buenísimo. Imaginen poder hacer algo como <script lang="text/python">

Y además, la idea es que esto NO requerirá que el cliente tenga instalado el runtime de .NET (ni el de Mono, para el caso), ya que se pretende mapear (traducir) el bytecode de IronPython / IronRuby en el bytecode de Tamarin.

Tamarin es el plato fuerte de esta ensalada: Es el componente de Firefox que se encarga de ejecutar el JavaScript, por ejemplo. A futuro, la idea es transformarlo en una implementación open source de alta performance de ECMAScript 4. Actualmente los usuarios de Firefox estamos usando una versión de Tamarin que soporta ECMAScript 3. La siguiente versión, incorporaría la última especificación de Adobe (que fue "donada" a Mozilla), y abriría la puerta a hacer esta "traducción" en tiempo de ejecución de CIL a Tamarin.

Acá hay bastante más información al respecto:

• El anuncio de Brendan Eich, CTO de Mozilla;
• La nota en Ars Technica de la que saqué en principio esta info;
• El post de Colins Walters en Planet GNOME gracias al que llegué a todo esto;

Ja! Esto le agrega algo más de significado a aquel slogan inicial de Firefox que decía "Rediscover the web"... ;)