Archivo de la categoría: Python

Exoditus en Python

Publicado el por
1

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…

 

SQLAlchemy: Un ORM que sabe de álgebra relacional

Publicado el por
3

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.

 

Potpurri: Chocolate, Cosmos, Python, AJAX, 15 años no es nada…

Publicado el por
1

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.

 

ActionMonkey == Python y Ruby en Firefox

Publicado el por
Responder

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:

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

 

CaFeCONF 2006 – Promoviendo Python

Publicado el por
Responder

Uffff…! Que findesemanita! Estoy volviendo a mi casa luego de un rally de 3 días, en el que prácticamente no paré un minuto. Ok, hubo ratos (literalmente) en los que estuve en mi casa en los últimos días, pero recién ahora puedo sentarme, mirar atrás, y poner en blanco y negro un fin de semana excelente.

El viernes y sábado se realizó la 5ta edición de  CaFeCONF, el evento anual que organiza CaFeLUG (Grupo de Usuarios de Software Libre de Capital Federal), para promover, disertar e informar sobre Software Libre.

Python, y por lo tanto, PyAr, tuvo una participación notable en el evento: La única charla plenaria, la "keynote" del evento, fue sobre Python, y brindada nada menos que por el mismísimo Alex Martelli, que vino gracias a Google, la Python Software Foundation, y… en el fondo, gracias a las gestiones que inició Facu. También tuvimos una charla de su esposa, Anna Ravenscroft. Y la charla de introducción a Python de Facundo, Y la charla sobre PyWeek de Alecu. Y la de Oveja Eléctrica de Yaco. Y John Lenton, en su debate sobre Como Hacer Plata con Software Libre.

Tuvimos nuestro propio stand, estrenando bandera, e informando a un montón de gente que se acercó muy interesada, y que estuvo jugando un poco también.

Socialmente, pude conocer a Sebastián Bassi, a John y Antony Lenton, a Manuel Kaufman, gente de Córdoba y Santa Fé que yo hasta ahora conocía solo por la lista.

CaFeCONF 2006 - Stand de PyAr

Organizamos la reunión 19, aka "La Internacional", con varias personas que se pudieron acercar por primera vez a una reunión, aprovechando que estaba en Baires. Y obviamente celebramos la reunión con Alex y Anna.

PyAr - Reunión 19

Y como si todo esto fuera poco, el domingo hicimos un asado con un grupo de amigos (que son miembros de PyAr, pero que gracias a eso, hoy son más amigos que otra cosa) para homenajear a Alex y Anna, y que no se fueran de Argentina sin probar un asado, y sin ver, más allá de comer buena carne, como es toda la "liturgia" del asadito.

Asado para Alex y Anna

Estoy extenuado, pero muy contento. Creo que hicimos un buen papel difundiendo Python (y los primeros mails de gente nueva que están entrando a la lista de PyAr mientras escribo esto parece confirmarlo), y a su vez, nos quedamos con la sensación de que "se subió la apuesta", y ahora tenemos que estar a la altura de las circunstancias. Al "core" de PyAr también le ha servido para iniciar el debate de como sigue la historia a futuro, y que más podemos hacer para seguir consolidando PyAr.

Tenemos en el tintero algunas ideas de capacitación, y medios alternativos de difusión de nuestras actividades  que esperamos poder consolidar en los próximos meses.

 

 

PyAr ya tiene bandera

Publicado el por
2

Ayer finalizó la votación, y ya tenemos al diseño ganador:

Bandera PyAr

En la página de resultados, pueden ver todos los modelos y el detalle de la votación. También Facundo posteó sobre el concurso hace un par de días.

Personalmente, me gustaban más los diseños de Facundo. Básicamente, porque incluían a nuestro logo oficial, que me encanta. Es irónico que el modelo ganador es de PabloZ, creador del logo… y que no lo haya usado en ninguno de sus diseños :( Pablo tiene una relación de amor y odio con su propio logo. Muchas veces lo ha criticado, diciendo que no se ajusta a todos los contextos, porque es muy complejo. Y justo ahora, donde tenía la oportunidad de usarlo en una bandera de varios mts. cuadrados, donde el nivel de detalle no es un problema… usó solamente la víbora-sol. Buh!

Igual me gusta. Me gustan mucho prácticamente todos los modelos de Facundo y Pablo.

Y antes de que alguien diga "antes de criticar hubieras mandado tu propio diseño", aclaremos:

  • No estoy criticando, estoy dando mi opinión personal.
  • No tuve tiempo de mandar un diseño. Alecu eligió una mala semana para organizar el concurso :(
  • No todo el mundo puede pintar un cuadro, pero muchos podemos mirarlo, y comentar sobre las sensaciones que nos despierta, ¿no? (¿se entiende la analogía? Ok).

Lo bueno de todo esto, es que ahora, cuando PyAr de una charla o asista a algún evento, ya tenemos una bandera que nos represente para colgar en el recinto.

Alocado Alocador

Publicado el por
3

Con algunos miembros de PyAr (alecu, dave, lucio, facu, nubis y yo) armamos un equipo para participar del desafío Pygame.draw, organizado por la misma gente de PyWeek, que básicamente consistía en hacer un juego en menos de 64Kb de código Python, usando SOLAMENTE pygame y la librería estándar, sin recursos externos.

El resultado es Alocado Alocador, un juego en el que tenemos que "administrar" la memoria, ubicando en la misma los bloques de memoria de los procesos que van apareciendo en una cola. La idea es hacerlo rápido, porque si se tarda en ubicar los bloques, el sistema se vuelve menos responsivo, y el usuario va perdiendo la paciencia. Cuando la paciencia del usuario se agota… perdemos. Hay algunas variables más en el juego (la verdad, quedó divertido!), pero les propongo bajarlo y enterarse jugándolo y leyendo la ayuda.

En unos días iremos completando seguramente la página wiki del proyecto con algo más de info. El juego puede bajarse acá, y necesita unicamente el intérprete de Python y la librería pygame.

Fue muy divertido participar en este desafío… si bien me faltó tiempo y recién me pude enganchar a full estos últimos dos días. El finde me la pasé probando el juego, discutiendo cambios, tocando algo de código, y sobretodo, "afinando" el mini-sintetizador que hizo alecu para tocar las melodías, y transcribiendo archivos MIDIs a la notación de ese sintetizador para ponerle música a la cosa.

Ahora nos queda esperar el resultado de la competencia… estuve jugando el resto de los juegos enviados, y la verdad… ¡tengo esperanzas!

SiGeFi otra vez…

Publicado el por
1

Después de varios meses, hoy hice otra vez un par de commits en sigefi. Tras haber estado hiper-activamente involucrado en el proyecto desde su inicio, y durante todo el desarrollo del core de la aplicación, resultó que las múltiples complicaciones inútiles de wxWidgets (el toolkit que elegimos para desarrollar la interfaz gráfica) terminaron inclinando la balanza para el otro lado: de pronto era mayor el tiempo que perdíamos luchando contra una estupidez, que el tiempo que invertíamos logrando un resultado CONCRETO, visible, en la aplicación.

Mi historia con wxWidgets es larga, y quizás algún día escriba sobre ella, no lo sé. La cuestión es que Facundo quedó virtualmente solo en el desarrollo, porque yo nunca más junté motivación suficiente para tocar una sola línea de código. El core estaba hecho, y básicamente todo el trabajo se limitaba a pelear con wxWidgets.

Por suerte, Facundo tiene mucha más paciencia que yo, y el proyecto siguió adelante.

Ahora que la GUI está más madura, otra vez empiezan a aparecer oportunidades de hacer cosas divertidas (al menos, divertidas para mí). y entre ayer y hoy, romí el hielo arreglando dos pequeñísimos bugs, retocando un detalle mínimo de la configuración, y… [trompetas] ¡hasta volví a bucear por la documentación de wxWidgets! ¡y logré hacer lo que yo quería!

Como siempre pasa con wxWidgets, perdí 3hs tratando de encontrar como hacer lo que yo quería. Tres horas. Tres preciosas horas. Lo que yo quería hacer, se resolvía con UNA miserable línea de código. Pero wxWidgets tiene esas cosas: Al menos que ya seas un experto en el toolkit, pareciera que la idea de sus desarrolladores es que pierdas tu tiempo buscando en Google, en lugar de desarrollando. En fin.

Nada. Una mínima contribución a SiGeFi otra vez. Espero ir recuperando la motivación, como para contribuir más seguido.

¡Nuevo portal de PyAr!

Publicado el por
Responder

Finalmente, bastante antes de lo que yo esperaba, la prueba piloto terminó bien, y PyAr tiene nuevo portal, basado en MoinMoin :)

Tuvimos que pelear un rato demasiado largo con Apache para mi gusto… pero bueno, son gajes del oficio. Una cosa fue instalar en mi casa, a prueba, y otra es una configuración "de verdad", en un server de verdad, que además de hostear PyAr está dando un servicio a muchas otras empresas. Pero sobre todo, se complicó porque ninguno de los que estábamos (Facu, Pablo Z y yo) es precisamente un experto en Apache.

Migrando la página de PyAr a MoinMoin

Publicado el por
8

[Actualizado el 05/02/2006]

Hace un par de semanas, motivado por el virtual abandono del sitio oficial de PyAr, y alentado por algunas opiniones que se generaron en la lista de correo, decidí hacer una prueba piloto sobre como quedaría el portal de PyAr basado completamente en un Wiki, más precisamente, en MoinMoin.

Actualización: el portal original en Zope/Plone al que se refiere este artículo, está en http://plone.python.com.ar

Tenía pendiente escribir un poco sobre este tema, porque algunas experiencias y los fundamentos (el por qué) de la migración me parecen interesantes. Pero antes que nada, algunas aclaraciones:

  • Si no te interesa Python y/o no estás relacionado de alguna manera con PyAr o alguna otra comunidad de usuarios de Python, o no te interesa leer sobre el mantenimiento y la administración de un portal, probablemente podrías pasar este artículo de largo.
  • Es un trabajo en progreso. Aún no hay nada implementado, ni nada para ver (al menos oficialmente…). Ni siquiera está dicha la última palabra respecto a que este laburo va a terminar reemplazando el sitio actual de PyAr. Bien podría pasar al olvido como un intento. [Actualización: pocos días después de escribir este artículo, finalmente migramos a MoinMoin... y todo esto dejó de ser un trabajo en progreso para ser una realidad :) ]
  • Las opiniones que expreso acá no necesariamente representan la opinión de PyAr. Digamos que estamos de acuerdo en que el portal necesitaba urgente una renovación (probablemente si no no estaría laburando en esto, y escribiendo este post). Pero en lo que respecta a la necesidad de abandonar Zope y Plone, y cambiar de tecnología, las opiniones están más divididas.
  • Tengo una opinión personal bastante negativa hacia Zope y Plone, y esto se que es un punto conflictivo. Así que vale la pena aclarar que mi opinión debe leerse en el contexto del portal de PyAr, y nuestras necesidades. Probablemente en otros contextos sean la mejor alternativa que existe. Y también es importante destacar que nunca tuve suficientes motivaciones para aceptar el desafío de escalar la empinada curva de aprendizaje de Zope y ver que hay del otro lado. Por lo tanto, admito abiertamente que en lo que respecta a Zope, están leyendo la opinión de un newbie.

 

     

     

Hay que hacer algo

Cualquiera que entre a la página de PyAr a la fecha de redacción de este artículo, verá que está desactualizada. Muy. Y desde hace mucho. Eso es una porquería, habla mal de nosotros, y no podemos ser una comunidad digna de Python con un portal en ese estado.

Es el producto de muchas horas de esfuerzo, está hecho con la colaboración y la buena voluntad de mucha gente, y tiene detalles de diseño y contenidos que están realmente muy bien. Pero tomándolo como un todo, en su estado actual, es vergonzozo :(

¿Por qué se llegó a esto?

Por un lado, porque la herramienta de comunicación principal de PyAr es la lista de correo. Esto es algo que se dió así. Incluso podríamos debatir si esto es una consecuencia de que el portal no sea bueno, y entrar en una recursión interesante ;)

Pero en concreto, lo que pasa en PyAr, pasa por la lista. Eso hace que prácticamente ninguno de los miembros activos ingrese al portal como para decir "uy! esto está completamente desactualizado!".

La segunda causa, es la dupla Zope + Plone. Es innecesaria- y extremadamente compleja para nuestros propósitos. Normalmente, la gente que tiene tiempo de dedicarse al contenido del portal, no tiene el conocimiento para lidiar con Zope (o Plone). Cuando intenta lidiar con él, se encuentra con que algo que debería llevar 5' se transforma en una tarea de 30', con la ayuda de Google, y mucha buena voluntad. Obvio, esto es porque esa persona no conoce a fondo la herramienta… pero eso nos lleva al segundo grupo de gente: La gente de PyAr que sabe de Zope, no tiene tiempo para administrarlo, o no tiene acceso a hacerlo (por restricciones de seguridad).

Resultado: Para los que quieren aportar contenido, Zope y Plone representan una barrera de entrada demasiado alta.

¿Cómo resolver el problema?

Basándonos en lo anterior, y suponiendo que el diagnóstico sea correcto ;) hay dos frentes para atacar:

  • Lograr que el portal gane en contenidos, para que parte de la dinámica del grupo pase por ahí, y sea más fácil mantenerlo integrado a nuestras actividades. De esa forma, para nosotros se transforma en una herramienta actualizada, y el efecto colateral es que los visitantes ocasionales se encuentran con un portal más digno :)
  • Hacer que sea fácil para todos (o la gran mayoría) de los miembros de PyAr generar contenido, de manera que cuando alguien tiene 10' de su tiempo para realizar un aporte, pueda invertir el 100% de su tiempo en eso, en el contenido, y no en pelear con la herramienta.

… y miren que loco como están relacionados los dos cursos de acción. Son un hermoso círculo virtuoso.

Solución: pongamos un Wiki

Quizás no sea la única alternativa. Pero estamos casi convencidos que es la mejor. ¿Por qué? Porque está pensado precisamente para que la generación y la administración del contenido pase por un grupo de gente amplio, sin tener que depender de roles de editores o revisores o escritores. Después se verá que páginas del wiki requieren algún permiso especial para tocarse, o cuales son los requisitos mínimos para poder editar contenido (¿registrarse? ¿ser miembro de la listsa?), pero lo importante es que nos da la posibilidad de tener un camino rápido y dinámico para generar contenido.

¿Por qué no ZWiki?

El portal actual tiene un wiki (ZWiki), montando sobre Plone (¿o es sobre Zope? Vaya uno a saber… :p)

De hecho, gran parte del contenido está ahí, y en su momento, ayudó bastante a destrabar la primera paralización que sufrió el portal (si! La historia de PyAr es corta, pero ya vamos por la segunda crisis de portal :p)

El tema es que necesitamos un Wiki, sin todo el resto. Sin estar embebido en la estructura de portlets y permisos y parafernalia de configuración de ninguna otra cosa. Porque aún cuando se pudiera personalizar más la combinación de Zope + Plone + ZWiki para ocultar la complejidad del resto, y todo aquello que no usamos, la realidad es que no hay nadie que reuna los conocimientos, las ganas y el tiempo necesario.

¿Por qué Python Powered?

Cuando empezamos a proponer alternativas, surgió que en PyAr hay dos opiniones claramente divididas respecto al lenguaje en el que esté desarrollada la herramienta que usemos:

  • Los que no nos importa tanto, y consideramos que lo importante es la funcionalidad que brinde la herramienta y su usabilidad;
  • Los que tienen una opinión cuasi-religiosa respecto a que el portal de PyAr tiene que ser Python Powered, y están dispuestos a iniciar una cruzada para defender su causa :p

Esto hizo que MediaWiki (realizado en PHP), que para mí era la mejor alternativa (inspirado en las experiencias recientes de los portales de Mono, Hula, The Tango Desktop Project, Beagle, …) quedara descartado.

PyAr es una comunidad, y la idea es sumar, no dividir. Así que aquellos a quienes nos daba casi lo mismo, nos decantamos por la alternativa de Python. Si de acercar posiciones se trata… era el camino lógico, ¿no?

Más allá del argumento "religioso", Lucio Torre dió después un argumento mucho más sólido: Si en algún momento nos topamos con un bug de la herramienta, o queremos extenderla, o queremos customizar algo que requiera meter mano en el código, o queremos contribuir en algo con el proyecto… más vale que esté hecho en Python, porque somos un grupo de usuarios de Python, y se supone que nos gusta mucho más echar código en ese lenguaje que en PHP o Ruby o cualquier otra cosa.

Y eso terminó de convencerme: Si estaba dispuesto a invertir tiempo en armar una prueba piloto en mi casa, en mi PC, con alguna otra herramienta, más vale que fuera en Python.

¿Por qué MoinMoin?

Acá no hubo que pensar tanto… el wiki oficial de Python corre desde hace años (¿desde siempre?) en MoinMoin, Python Brasil usa MoinMoin, y en popularidad, historia y cantidad de implementaciones, Wiki + Python = MoinMoin. Punto.

También llegamos a evaluar Trac, pero lo descartamos porque si bien posee un Wiki, no es un wiki. Está orientado a la administración y documentación de un proyecto de software, y no a armar un portal comunitario. Por más que parece un buen producto, y está de moda, no estábamos seguros como se adaptaría a nuestro caso de uso. Todavía no está tan maduro. Y lo que terminó impidiendo que al menos le diéramos una oportunidad, es que solo está en inglés. Oficialmente no hay versiones internacionalizadas, y los esfuerzos de internacionalización están en el ToDo, recién para después de la versión 1.0. Y más vale que no íbamos a poner el portal de Python Argentina en inglés…

Sé que hay algunos productos derivados de MoinMoin. Probablemente haya más alternativas… y lo que es seguro es que no las evaluamos todas. Pero allá fuimos… a por MoinMoin.

So far, so good

La instalación resultó más compleja que la de MediaWiki, pero está muy bien documentada. En general, la doc de Moin es muy buena.

Por lo demás, fue cuestión de migrar contenido (como era poco, y el markup de ZWiki no es tan diferente al de MoinMoin, lo hice manualmente), y reorganizarlo. Podría haberse automatizado, pero fue una buena oportunidad de repasar todos los textos, corregir errores, e ir definiendo la nueva organización sobre la marcha.

A medida que fui jugando, descubrí o aprendí a valorar mucho algunas características:

  • No hay base de datos. Las páginas son archivos de texto, con el mismo markup en crudo, con los mismos nombres, y con la misma estructura jerárquica. No solo facilita la administración (no hay que lidiar con un RDBMS), sino que abre la puerta a acceder de manera transparente a los datos desde afuera del wiki, para mantenimiento, backup, o para procesos masivos, como agregar o sacar algo de todas las páginas.
  • Moin soporta múltiples configuraciones: Personal, CGI, basada en Twisted, con lo cual nos da flexibilidad en los requerimientos del hosting, y nos permite jugar con diferentes configuraciones en caso que tengamos que escalar o arreglar algún tema de performance.
  • Es muy extensible. Hay muchas "macros" estándares. Hay todo un juego de macros populares, que tienen bastante historia y están probadas y siguen el desarrollo de MoinMoin. Y lo que es mejor, las extensiones son muy fáciles de escribir (bah, al menos la API es sumamente sencilla). En caso de querer realizar algo particular, que no esté cubierto por ninguna macro existente, no sería complejo escribir nuestra propia macro.
  • El markup estándar es sencillo de aprender. Pero además, hay parsers para escribir en reStructuredText, coloreo de sintaxis de Python, y la posibilidad de generar un documento DocBook a partir del wiki!!! Eso está buenísimo… se me ocurre que el día de mañana, si necesitamos generar desde PyAr alguna doc formal, podemos escribirla entre todos, y luego generar el DocBook estándar.

Lo único que todavía necesita un poco más de trabajo, es la internacionalización, al menos en castellano. Pero bien podría ser la contribución de PyAr a MoinMoin: Completar la traducción de las páginas de ayuda que faltan, traducir algunos strings de la interfaz que están en inglés, etc.

Estética

Uno de mis mayores prejuicios respecto a MoinMoin era que todos los wikis que había visto, están casi sin personalización, basados en dos o tres "themes" estándar, bastante crudos. Y yo estaba obsesionado con la estética que Garrett LeSage y otros le habían dado a los sitios que mencionaba más arriba, basados en MediaWiki.

Pero después descubrí que esa personalización de MediaWiki no es sencilla, no está documentada… y yo no soy Garrett. Y que es posible personalizar a fondo MoinMoin también. Con esfuerzo, pero es posible.

Ya dimos los primeros pasos, y no fue tan complejo: Crear un nuevo tema, "pyar", basado en el estándar "modern", limpiar el layout, mejorar las fuentes, personalizar un poco los colores. Con el tiempo, será cuestión de ir agregando detalles.

Conclusión

La renovación del portal de PyAr es posible, y está en marcha. Hay pilas de mucha gente para tener un portal mejor, y varias personas se engancharon con la idea, y hasta estuvieron jugando con el portal de prueba.

El feedback recibido hasta ahora fue positivo, a todos les está gustando. MoinMoin está probando ser una mejor alternativa que Zope + Plone para nuestras necesidades, aunque por ahora es casi una hipótesis… habrá que ver, si migramos, como terminan dándose las cosas en la práctica, con el sitio real, y con el tiempo.

Si todo sigue como hasta ahora, en pocos días más estaríamos en condiciones de hacer la migración definitiva. :)