He tenido el placer de poder asistir a la DjangoCon Europe que tuvo lugar en Amsterdam. En contra de lo que se puede suponer a priori, el viaje a Amsterdam fue de todo menos un viaje de ocio. Con decir que tuve que quedar con un español que vive allí, el futuro compañero de Yaco Danny Navarro, para visitar Amsterdam (bueno sólo ir a ver algunos escaparates, sin comprar nada por supuesto que hay crisis ;)

En fin, que me lo pasé en grande con casi 200 geeks que asistían a la conferencia (cinco de ellos españoles :). Bueno, en realidad sólo me lo empecé a pasar bien a partir del lunes por la tarde, una vez había dado mi charlita de 10 minutos sobre Merengue (transparencias en HTML5 aquí), dentro de charla 3 CMSs in 45 minutes. Hasta entonces sólo había sido un cúmulo de nervios y de trabajo de preparación, debido a mi mal inglés. Menos mal que al parecer salió bien la cosa y a muchos le gustó Merengue.

Con respecto a la primea DjangoCon de 2008, a la que asistí con Marc García, ha habido muchas diferencias. El sitio no era GooglePlex, cierto es, pero también es cierto que... We conquered the Castle! En serio, la gran mayor diferencia que veo es que se nota estos tres años de alto crecimiento de Django y sobre todo tres años de recorrido de muchas empresas, organizaciones e individuos que han ido creciendo alrededor, y todos encantados de su experiencia.

No sabía que sitios como Prezi era Django, así como todas las webs que se están haciendo en Mozilla, como la de addons (código liberado en github), como la famosa que recogía las descargas en tiempo real del FF4. Por ejemplo la de addons recibe más 500 millones de peticiones a su API para la comprobación de nuevos addons y temas similares. También los chicos de bitbucket,org lo hacen todo con Django. Muchas webs e iniciativas exitosas son en Django: djangozoom, ep.io, disqus, etc. etc. En 2008 sólo teníamos un par de referencias como Pownce. Por cierto, allí de nuevo estaba la guapa Djanguera Leah Culver, co-desarrolladora de Pownce (ahora no existe).

Estos tres años han dado además para encontrar un sin fin de código liberado para Django que era el topic de las charlas o se usaban en los proyectos mencionados anteriores. Estos proyectos ni se intuían hace tres años y algunos tampoco los conocíamos antes de las conferencias (estaban en un github perdido). Cito algunos ejemplos:

• Celery, para tareas asíncronas (usado en Yaco con éxito).
• Fiber, un set de funcionalidades de CMS para añadir a tu proyecto Django, presentado por Dennis, una gran persona.
• Django-qunit, para integración de django y qunit, que permiten hacer tests en Javascript. Se pueden ejecutar en varias máquinas usando jstestnet.
• django-cache-machine, basado en el antiguo django-caching, que es una alternativa menos mágica a Johnny-cache.
• django-waffle, para hacer test AB según ciertos flags activos o no.
• django-bleach, para evitar ataques de inyección de Javascript.
• django-queryset-transform, que permite evitar consultas SQL tomando el control del ORM, para cuando el select_related es insuficiente.
• django-nani, para traducción de modelos usando la aproximación en dos tablas, como hacía django-multilingual pero mucho mejor que este último. En merengue se usa django-transmeta, que se basa en una tabla con columnas para cada idioma.
• django-qmixin que permite una personalización elegante de tus managers y querysets.
• django-rest-framework, que parece mejor pensado que django-piston. Es curioso como a la gente no le termina de convencer django-piston y están tomando otros productos, aunque dicen los de bitbucket que van a sacar una mejor versión pronto. El producto que al parecer está más de moda es django-tastypie, que tiene sin duda la mejor documentación de todos.
• kong para testing funcional cuando Selenium se convierte en un cañon para matar moscas (depende de la naturaleza de la web que programes).
• dagny, o como aprovechar el REST para mejorar la estructura y reutilización de tu código. Esta es otra gran alternativa a django-piston pero además te cambia el modelo de como programar. Un modelo elegantísimo.
• etc.

Por otra parte, como ya le pareció a Loren en la PyCon, veo que estamos haciendo las cosas bien, tanto en desarrollo como en despliegue. Para integración continua usan Jenkins, como estamos empezando a usar nosotros. Otros usan bamboo. Para creación de máquinas y mantenimiento usan puppet y chef. Muchos usan la nube para ello.

Aunque todas estuvieron interesantes, voy a destacar algunas charlas especialmente:

• La lightning talk de PyCharm. Es sin duda el mejor IDE Django que hay. Permite autocompletado de todo, incluyendo dentro de las plantillas Django (carga de librerías, expresiones, filtros, ¡todo!). Lo único malo es que tarda mucho en cargar por el análisis que hace al proyecto que carga. Como curiosidad el desarrollador principal es un geek superdotado que entró a la universidad con 15 años (y se arrepiente mucho de ello).
• Muy interesante la charla de compass y less y del responsive web design.
• La charla de django on rails que trata de como aprender del modelo restful de Rails y aplicarlo a Django. El resultado es dagny, mencionado antes.
• La charla de reusable apps using "eicht spaces", me parecío como analizaba el problema del import circular en Django y permitía un diseño de vistas que dejaba mucha mayor reutilización. Permite por ejemplo que puedas extender el modelo de una aplicación en una segunda aplicación que sea el modelo que usa la primera aplicación, pero sin el problema del import circular que es el que saldría si intentaras hacerlo sin un artefacto ingenioso como "eicht spaces".

Otra cosa interesante fue ver a Reinout van Rees escribiendo los artículos de blog de las charlas que iba viendo en tiempo real como si de una taquígrafa se tratara. ¡Very cool!

Por último los Sprints. Fueron en el castillo de De Waag, y la verdad es que pasamos un rato agradable. Yo estuve con Samuel Fuentes, el único de los españoles que se quedó a los sprints. La verdad es que sólo trabajé sprintando en Django unas 5-6 horas, en las cuales metí mano a 3-4 tickets del trac de Django. El resto estuve también ayudando a gente, desarrollando con Merengue, preparando el sprint de la EuroPython, contestando correos, redactando documentación de Yaco, etc.

Al final llegó Danny Navarro y pasamos un buen rato de charla juntos hasta las 1 y pico de la mañana.

En fin, unas conferencias magníficas, la gente estupenda, una organización increíble, pendiente de los asistentes en cada momento, con buena comida (el queso genial), mejor cerveza belga. Eso sí, hay algo que fallo en la DjangoCon Europe... faltó Cal Henderson

Permalink | Leave a comment  »

Today I needed to create an app file for MacOS X with a simple Python script. This is what I learned:

• Use py2app, it's your friend
• After installing py2app with easy_install you need to fix it. Otherwise it may not work for your hardware architecture. See Section 2 of this blog post
• Now, you can safely run python setup.py py2app and you will get a file with the .app extension in the dist directory
• When you install that (copy into your Applications folder) and try to run it you will get this error (open the Console or do a tail -f /var/log/system.log) to see the error:

22/03/11 10:33:21    com.apple.launchd.peruser.502[580]    ([0x0-0x98098].org.pythonmac.unspecified.myscript1613]) Exited with exit code: 255
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]    Traceback (most recent call last):
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]      File "/Applications/xml2rfc.app/Contents/Resources/__boot__.py", line 103, in <module>
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]        _argv_emulation()
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]      File "/Applications/xml2rfc.app/Contents/Resources/__boot__.py", line 101, in _argv_emulation
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]        _get_argvemulator().mainloop()
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]      File "/Applications/xml2rfc.app/Contents/Resources/__boot__.py", line 40, in mainloop
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]        stoptime = Evt.TickCount() + timeout
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]    AttributeError: 'module' object has no attribute 'TickCount'

In order to avoid it you need to use a different Python from your system Python. In my case it only worked with a 32 bits Python like python-2.7.1-macosx10.3.dmg

Once you have the script installed you can run it from the shell in /Applications/myscript/MacOS/myscript.py

For the record, this is my setup.py file:

import sys
from setuptools import setup

mainscript = 'myscript.py'

if sys.platform == 'darwin':
    extra_options = dict(
        setup_requires=['py2app'],
        app=[mainscript],
        # Cross-platform applications generally expect sys.argv to
        # be used for opening files.
        options=dict(py2app=dict(argv_emulation=True)),
        )
elif sys.platform == 'win32':
    extra_options = dict(
        setup_requires=['py2exe'],
        app=[mainscript],
        )
else:
    extra_options = dict(
        # Normally unix-like platforms will use "setup.py install"
        # and install the main script as such
        scripts=[mainscript],
        )

setup(
    name='myscript',
    version='0.1.0',
    **extra_options
)

It's taken from a py2app example

Permalink | Leave a comment  »

La versión 0.8 de Merengue va a centrarse en mayor medida en tener un CMS production ready para grandes portales web, con una carga dinámica importante y un número de peticiones elevados.

Una de las acciones a tomar será compatibilizarlo con la versión 1.3 de Django, ya que, sobre todo a partir de la versión 1.2, se han realizado muchas mejoras en rendimiento, escalabilidad, robustez y seguridad. Así, compatibilizarlo con Django 1.3 (hasta ahora usaba Django 1.1) es una de las mejores formas de preparar Merengue para grandes webs.

Las mejoras que dispondríamos relativas a estas cuestiones serían:

• ORM multidatabase. Con poco esfuerzo puedes tener varias bases de datos configuradas en cluster.
• Caché de plantillas. La página inicial de Merengue, cuando entramos como un usuario autenticado, nada más instalar Merengue, renderiza ni más ni menos que 87 plantillas, pero tenemos casos de proyectos con vistas que renderizan hasta 206 plantillas. Estos números no son habituales en aplicaciones web ad-hoc, pero Merengue es un CMS pluggable de propósito general. El número es tan elevado porque:
  • Merengue renderiza las páginas a partir de elementos pequeños (bloques, acciones, viewlets, etc.) que pueden ser movidos configurados y desactivados por el gestor. Esta flexibilidad casi infinita tiene el inconveniente de renderizar los fragmentos de la página de forma separada, lo cual también es bueno para permitir que los desarrolladores integren sus plugins.
  • Merengue usa bastante la herencia de plantillas, por ejemplo para su sistema de temas (theming) y para los bloques. Por ejemplo cada bloque suele heredar de una plantilla padre que incluye herramientas para gestionarlos, moverlos, configurarlos, etc.
• Protección contra ataques CSRF, para evitar que otras webs hackeadas puedan alterar datos de la nuestra.
• Claves naturales en Fixtures, perfectas para mejorar el deployment. Por ejemplo para exportar automáticamente la configuración de un sitio Merengue (con el tema activo, los bloques, plugins activados, configuración, etc.) e importarlos en otro sitio distinto.
• Uso de Model.objects.only(...), para seleccionar campos sueltos de las tablas, y no tener que cargar toda la tabla completa para cuando listas solo un par de campos en ella. Esto puede ser muy útil por ejemplo para las colecciones, ya que si el gestor define los campos que muestra, ¿para qué tener que obtener todos los demás si nunca van a salir?
• Framework para Logging (1.3), que ya era hora de que se incluyera en este framework. Así evitamos el estar poniendo print y podemos configurarlo para enviar entrada a fichero, email, etc.
• Ficheros estáticos (1.3). En Django 1.3 se distinguen los ficheros subidos por los usuarios de los servidos por el sistema. También hay herramientas de sincronización al directorio que sirve el servidor web usado. Merengue también tiene funcionalidades que equivalen a las de Django (y las superan en algunos casos), con los que habrá que pensar más tranquilamente como unir los caminos.

Pues bien, ya hemos empezado el trabajo de compatibilizarlo con Django 1.3, realizado en una rama aparte de código y las noticias son muy buenas... tan buenas... que puedo decir que tras unas 6 horas de trabajo la tarea está casi concluida. Falta probarlo bien y corregir los problemillas que surjan, pero tras múltiples refactorizaciones, fallitos corregidos, pruebas y pruebas, casi está listo (el trabajo se puede ver en el ticket #1568).

Benchmarkings preliminares

Lo primero que he realizado tras comprobar que funciona bien han sido pruebas de carga simples, comparando Merengue (rama trunk/) + Django 1.1 y Merengue (rama django1.3_compat) + Django 1.3, con y sin caché de plantillas habilitado (usando caché de memoria local).

Aquí los resultados:

• Merengue con Django 1.1:
  
  • Vista con 87 plantillas: 2.85 [#/sec]
  • Vista con 209 plantillas: 1.20 [#/sec]
• Merengue con Django 1.3:
  • Vista con 87 plantillas, sin cache: 2.88 [#/sec]
    
  • Vista con 87 plantillas, CON cache de plantillas: 6.35 [#/sec]
  • Vista con 209 plantillas, sin cache: 1.06 [#/sec]
  • Vista con 209 plantillas, CON cache de plantillas: 6.35 [#/sec]

Conclusiones del benchmark:

• La caché de plantillas aumenta drásticamente el rendimiento de un sitio.
• Cuanto más plantillas renderiza una vista, más se nota el aumento de rendimiento. De hecho en las pruebas se ve que se consiguen los mismos resultados con 87 plantillas y con 206, lo que denota que el tiempo de localizarlas en el sistema de ficheros y compilarlas es mucho más importante que el tiempo de renderizado de las mismas.

Permalink | Leave a comment  »

$ git clone git://github.com/mviera/easyTrac

$ python bootstrap.py

$ ./bin/buildout

$ ./bin/supervisorctl

$ ./bin/supervisorctl start nginx

$ ./bin/supervisorctl stop nginx

$ ./bin/supervisorctl restart nginx

$ ./bin/supervisorct restart all

http://localhost:9000

http://localhost:8080

$ ./bin/trac-admin opt/trac/demo initenv demo sqlite:db/trac.db

$ ./bin/svnadmin create opt/svn/demo

$ ./bin/backup

$ ./bin/restore backups/backup-file.tar.gz

$ ./bin/supervisorctl shutdown

$ rm -rf easyTrac

Permalink | Leave a comment  »

Hoy trabajando en Yaco Sistemas he aprendido algo nuevo sobre cron. Seguramente muchos de los que os moveis entre GNU/Linux y similares, conoceréis el demonio cron.

Cron es un planificador de tareas que nos permite ejecutar una tarea en un momento determinado en el tiempo. La sintaxis para configurar una tarea cron es la siguiente:

.---------------- minuto (0 - 59)
|  .------------- hora (0 - 23)
|  |  .---------- día del mes (1 - 31)
|  |  |  .------- mes (1 - 12)
|  |  |  |  .---- día de la semana (0 - 6) (Domingo=0)
|  |  |  |  |
*  *  *  *  *  comando para ser ejecutado

De esta forma, imaginad que queremos apagar nuestro ordenador los sábados a las 21:30h, configuraríamos una tarea cron de la siguiente forma:

30 21 * * 6 /sbin/shutdown -h now

Podemos planificar tareas para un usuario utilizando el comando crontab:
crontab -l Lista las tareas cron para el usuario actual.
crontab -e Permite configurar una tarea cron para el usuario actual. Se abrirá el editor de texto configurado por defecto en el sistema.
crontab -r Elimina las tareas cron configuradas en el usuario actual.
crontab -v Muestra la última vez que se editó crontab del usuario actual.

La verdad es que no parece una sintaxis muy complicada pero a mi, personalmente, siempre se me olvida.

Como os decía al principio, hoy he descubierto los horarios predefinidos en crontab gracias a ant30. Estos horarios predefinidos son unos valores que se pueden usar para sustituir la sintaxis de las expresiones anteriores. Estos valores predefinidos son:

@yearly Se ejecuta una vez al año. Equivalente a 0 0 1 1 *
@annually (igual que @yearly). Equivalente a 0 0 1 1 *
@monthly Se ejecuta una vez al mes. Equivalente a 0 0 1 * *
@weekly Se ejecuta una vez a la semana. Equivalente a 0 0 * * 0
@daily Se ejecuta una vez al día. Equivalente a 0 0 * * *
@midnight (igual que @daily). Equivalente a 0 0 * * *
@hourly Se ejecuta una vez cada hora. Equivalente a 0 * * * *
@reboot Se ejecuta en el arranque y al reiniciar.

El que yo he utilizado hoy ha sido @reboot que me permite ejecutar un comando cuando arranca el sistema. En mi caso quería que cada vez que se arranque el sistema, se iniciara un servicio desplegado con el usuario en cuestión. Gracias a @reboot no tengo que crear un script en /etc/init.d/ y activarlo en el arranque ;-)

Un saludo!

Permalink | Leave a comment  »

Tras más de 300 tickets cerrados y dos meses de trabajo, se ha publicado la versión 0.6.0-final de Merengue, disponible en Pypi.

Esta versión final supone la corrección de muchos errores, y sin ningun cambio funcional desde la versión 0.6.0-alpha, y pensamos está lista para su uso en webs de producción. Para el que no conozca el proyecto, recomiendo echar un ojo al overview de Merengue y entrar en la web de demostración

Algunos enlaces de interés:

• Página del proyecto
• Web de demostración (usa la versión 0.7.0-alpha)
• Documentación
• Comparativa entre Merengue y otros CMS Django

Gracias a todo el equipo de Merengue, gracias a ellos el proyecto Merengue se ha hecho realidad.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Mi problema en concreto, era que no podía cargar una base de datos postgresql de un sistema con postgis1.3 a un sistema con postgis1.5. Uno de los muchos errores, era que no encontraba la liblwgeom.so.

La solución es usar el script new_postgis_restore.pl. El mismo comando al ejecutarlo sin parámetros, indica los pasos a seguir:

Permalink | Leave a comment  »

La semana pasada, el día 28 de Octubre tuvo lugar el primer laboratorio andaluz de android.

Permalink | Leave a comment  »

Cuántas veces nos ha pasado que nos encontramos trabajando en un proyecto en el que necesitamos instalar paquetes de python y nos damos cuenta de que no podemos continuar porque PyPi está caida.

A mi personalmente me ha ocurrido ya en varias ocasiones, sobre todo realizando despliegues de aplicaciones web de forma automatizada, lo cual es bastante frustrante puesto que no puedes seguir avanzando en tu trabajo.

Hace no mucho conocí una receta de buildout llamada z3c.pypimirror [1] y se me encendió la bombilla. Esta receta nos permite crear un mirror completo o parcial de PyPi.

De modo que este pasado finde busqué un hueco y me puse a trabajar en una configuración buildout llamado pypi-mirror [2] que facilitara la creación de un mirror de PyPi :-)

Para construirnos nuestro propio mirror de PyPi solamente tendremos que seguir unos sencillos pasos:

 1. Descargar el proyecto pypi-mirror

 git clone git://github.com/mviera/pypi-mirror.git

 2. Configurar el fichero buildout.cfg:

• mirror-base: directorio donde se almacenarán los paquetes del mirror.
• url: la URL que utilizaremos para acceder a nuestro mirror.

 3. Resolver las dependencias del instalador.

•  gcc
• GNU make
• libpcre3-dev
• libssl-dev

 4. Ejecutar bootstrap.py para crear el entorno base

 python2.6 bootstrap.py

 5. Ejecutar la instalación

 ./bin/buildout

Al final, y si todo va bien, se nos mostrará las instrucciones a seguir tras finalizar la instalación. En resumen, solamente tendremos que ejecutar el siguiente comando para iniciar la sincronización de nuestro mirror con PyPi:

 ./bin/pypimirror -I -c -v etc/pypi/pypimirror.cfg

Bien, hora de irte de compras con tu novia, si, aunque no te guste, pero creeme esto va a tardar. Aprovecha para plantar un árbol, tomar unas cervezas con los amigos, etc. Actualmente son 17GB de puro python.

Además el instalador configura una tarea cron para mantener actualizado el mirror cada dos horas. Puedes ver la configuración de esta tarea cron de la siguiente forma:

 crontab -l 

Una vez finalizada la sincronización con el mirror. Solamente tendremos que publicar dicho contenido con un servidor web. Como no podria ser menos, el instalador ya ha compilado un servidor Nginx y lo ha configurado por ti. Solamente tendremos que levantar el servicio, y lo haremos de la siguiente forma:

 ./bin/supervisord

Con esto tendremos un servidor Nginx en el puerto 8080 y un servidor Supervisor en el puerto 9000.

Podremos controlar el servidor Nginx a través de la interfaz web de administración de Supervisor accesible en http://localhost:9000, permitiendo el arranque, parada y reinicio del mismo.

Para más información, consultar con la documentación [3] de pypi-mirror.

Espero que os sea de utilidad! Ahora no teneis escusa para crearos vuestro propio mirror de PyPi!

Enjoy!

[1] http://pypi.python.org/pypi/z3c.pypimirror

[2] http://github.com/mviera/pypi-mirror

[3] http://github.com/mviera/pypi-mirror/blob/master/README

Permalink | Leave a comment  »

Hoy me apetece compartir con vosotros un post dedicado a la virtualización de sistemas.

Actualmente en Yaco nos encontramos trabajando e innovando en el campo de la virtualización. Como siempre intentamos apostar por una solución libre y después de probar varias soluciones, nos hemos quedado con una que nos está gustando cada día más.

Se trata de Proxmox VE (Proxmox Virtual Environment). Seguro que algunos ya estais buscando por Google, pero si me permitís, os voy a dar un resumen. Proxmox VE es una plataforma de virtualizacion Open Source fácil de usar que permite crear, administrar, eliminar, migrar, etc; máquinas virtuales KVM y OpenVZ.

La instalación es muy sencilla, ya que es posible descargar un ISO e instalarla como cualquier otra distribución GNU/Linux. Yo diría que aún más sencilla que cualquier otra distro, ya que solo es necesario seguir unos cuantos pasos sencillos (especificar el nombre del host, configuración de red, y poco más) antes de proceder a la instalación. Además esta basada en Debian con lo que a algunos, como yo, se les dibujará una pequeña sonrisa en la cara.

Una vez instalado Proxmox tendremos una máquina Debian particionada con LVM, un kernel con soporte OpenVZ y KVM, herramientas de backup y restauración, y una interfaz web de administración desde la que podremos gestionar el servidor de virtualización.

Una de las funcionalidades que más me han gustado de Proxmox VE ha sido la posibilidad de crear un cluster de virtualización. Esto es, tenemos un nodo principal de almacenamiento y varios nodos de virtualización, es decir, los que ejecutarán las máquinas virtuales. De esta manera, podemos migrar máquinas virtuales de un nodo de virtualización a otro. Pero eso no es todo, es que es posible realizar migraciones en caliente! Y lo mejor de todo es que funciona!

¿Qué es lo que nos falta? Los backups. Todos sabemos que los sysadmin de verdad no hacen backups, pero lloran muy a menudo ;-) Para evitar esto, la propia interfaz de administración nos permite configurar tareas de backups periódicas para nuestras máquinas virtuales. 

Como todo en esta vida, tiene sus ventajas e inconvenientes. La interfaz de administración está escrita en Perl, todo no podía ser bonito, aunque siendo sinceros creo no podemos quejarnos :-)

Personalmente estoy muy contento con Proxmox VE, os invito a que lo proveis porque merece la pena, sobretodo si aún no tienes mucha práctica con virtualización en OpenVZ y KVM. Puede ser una buena forma de ir familiarizándose con el entorno.

Un saludo!

Permalink | Leave a comment  »

Normalmente se puede ejecutar jslint con la ayuda de Rhino u otros intérpretes javascript sin demasiados problemas tal que así:

$ rhino ~/bin/jslint.js fichero.js

Lo complicado es cuando tenemos el javascript dentro de html. Me he hecho un mini snippet para poder hacerlo al vuelo sin necesidad de copiar el cacho de javascript en un fichero externo:

$ cat index.html | python -c "import re, sys; print '\n'.join(re.findall(r'\(.*?)\<\/script\>', sys.stdin.read(), re.DOTALL))" > tmp.js; rhino ~/bin/jslint.js tmp.js; rm tmp.js

Seguramente se pueda hacer con sed o awk pero soy muy torpe con ambos dos.

Permalink | Leave a comment  »

La semana pasada, del 26 al 30 de julio, tuvo lugar la GUADEC, que es la conferencia internacional de desarrolladores de gnome.

En yaco estamos trabajando en evince para hacer el lector de pdf de gnome más accesible, dentro de uno de los proyectos lanzados por el Consorcio Fernando de los Ríos para conseguir que los centros guadalinfo sean más accesibles.

Ya había gente en yaco integrada con la comunidad de gnome, y de echo, antes de entrar a trabajar en yaco yo personalmente estuve en la GUADEC del año pasado, pero concretamente este año ha sido la colaboración desde yaco con el proyecto evince lo que me ha llevado a la conferencia.

La GUADEC realmente comenzaba el miércoles, pero el lunes y el martes tuvieron lugar unas preconferencias. El lunes estuvo allí Félix Ontañon, de emergya, hablando sobre el software libre en Andalucía, el papel del gobierno, etc.

Tuve la oportunidad de compartir opiniones sobre el estado del software libre en administraciones públicas con Félix y con gente de Holanda, que nos comentaban que en Holanda tienen mucho por hacer en lo que respecta al software libre tanto en administraciones públicas como en empresas privadas, porque por lo visto allí no se contempla otra solución a la privativa, y por tanto estaban bastante interesados en cómo se ha conseguido llegar al punto actual en Andalucía.

Por este motivo querían haber llevado a Juan Conde, de la junta de andalucía, pero al final no pudo ser para la guadec, aunque me dijeron que intentarían que fuera pronto para ver si con una opinión desde alguien del gobierno consiguen convencer a alguien o por lo menos que se comiencen a plantear alternativas.

Esta guadec estuvo marcada por el cabio a gnome 3, que estaba planificado para la próxima release de gnome para septiembre. Sin embargo, en esta guadec se anunció el retraso del lanzamiento de gnome 3, principalmente porque hay aplicaciones importantes que todavía no están listas y sobre todo porque gnome-shell no está listo aún, y es el principal cambio desde el punto de vista del usuario que gnome 3 va a ofrecer. Así pues habrá un gnome 2.32 en septiembre y en marzo de 2011 será lanzado gnome 3.

Con este cambio, supongo que muchos de los desarrollos que ya estaban adaptados a gnome 3, sacarán una versión parcheada de 2.30 para la 2.32. Creo que para evince este será el caso, porque se usa funcionalidad nueva de gtk3 y por lo tanto puede que para gnome 2.32 no se incluyan las funcionalidades nuevas que ya están en trunk, como por ejemplo la posibilidad de añadir anotaciones.

Una de las charlas que me pareció bastante interesante fué la de "quién hace gnome", donde se mostraban datos de quienes son los que realmente están detrás de este proyecto de software libre, y cabe destacar que últimamente, los desarrollos más importantes de gnome son realizados por "empresas". Las empresas que más colaboran en gnome a nivel de código son Red Hat, Collabora, Igalia, Intel y Novell.

También es verdad que muchos de los desarrolladores pagados por empresas también dedican mucho de su tiempo libre desarrollando, y que hay muchos desarrolladores voluntarios, pero se puede decir que el peso del desarrollo los llevan empresas, y que hay dinero e intereses comerciales detrás del desarrollo de gnome, y eso es una gran noticia para el software libre.

Otro de los temas que aparecieron en diferentes charlas de la guadec fue la integración del escritorio con la web. Es verdad que hoy en día hay muchas aplicaciones web, y cada día más, y la integración de estas aplicaciones con el escritorio es un tema importante. Por eso, creo que webkit jugará un papel importante en el escritorio.

¿Por qué webkit y no gecko? Una de las razones principales para usar webkit en tus aplicaciones en lugar de gecko es porque es más fácil para el desarrollador. Otra razón, quizás más importante, es que webkit está siendo desarrollado por varias compañias (apple, google, igalia...) lo que permite que las desiciones que se tomen estén relativamente consensuadas y por lo tanto no haya cambios dictatoriales sin una razón objetiva.

Sobre el tema de la accesibilidad no hubo mucho movimiento, sin embargo pude hablar con desarrolladores de gnome que están trabajando en este tema, y supongo que en el hackfest de sevilla (al que espero asistir) podamos hablar más sobre este tema.

Lo que más me ha llamado la atención de estas charlas es que hay gente que ya tiene en cuenta las aplicaciones web, y están trabjando para que el escritorio no se quede obsoleto y se integre correctamente con el nuevo mundo de aplicaciones web que está apareciendo hoy en día. Personalmente, como he trabajado tanto como desarrollador web como de escritorio, este movimiento me llama bastante la atención, porque une dos mundos que parecían completamente desconectados.

Ha sido una gran experiencia asistir a esta GUADEC, y supongo que el año que viene estaré por Berlín, donde se celebrará la siguiente, junto con la akademy, en el llamado Desktop Summit.

Permalink | Leave a comment  »

El concepto de A/B testing, es usado para ver si un diseño de web
alternativo es mejor o peor que el anterior, según estadísticas
recogidas al usuario.

Supongamos el siguiente escenario: tenemos una web de compras on-line y
tenemos dos alternativas de diseño A y B, y queremos saber si cual de
los dos va a hacer incrementar el número de veces que compramos
productos (por ejemplo por ser más fácil).

Los tests A/B lo que hacen es cambiar el diseño a un pequeño porcentaje
de usuarios (p.ej. el 10%), y medir de este 10% quien da más al botón
comprar.

Django-ab es una aplicación Django para conseguir estos tests de forma
transparente (gracias Erny por encontrarlo):

http://github.com/johnboxall/django-ab

En general consiste en:

* Definir en el admin dos variantes para renderizar la plantilla
foo.html (foo1.html y foo2.html).

* Un middleware se encargará de poner en la sesión si está en la
variante A o en la B, según ese 10%.

* Un template loader propio se encargará de renderizar foo1 o foo2
según la variante que se encuentre en la sesión.

* El middleware además se encargará de mirar si el objetivo del
experimento (p.ej. la URL /comprar/) está en la URL de la petición. Si
es así mirará que variante A o B tiene el usuario y anotará la
puntuación a uno o a otro.

No tenemos más que sentarnos a esperar y ver cual de las dos variantes A o B resulta ganadora.

Permalink | Leave a comment  »

http://groups.google.es/group/django-developers/browse_thread/thread/5e39c24f...

Lo veo correctísimo, ya que WSGI va de lujo, con muchas ventajas de
depuración, sin que tenga que ejecutarse en el espacio de usuario del
apache.

Un saludo.

Permalink | Leave a comment  »

Django 1.2 tiene por defecto protección CSRF, que si quieres usarla (en
admin por ejemplo es obligatorio), debes incluir un token CSRF en las
plantillas, tal que así:

Pues bien, hay un snippet para ejecutar un comando que te lo inserte en
todas las plantillas que tengan formularios:

http://charlesleifer.com/blog/quick-shell-command-add-csrf-token/

Permalink | Leave a comment  »

We are very excited and happy to announce our first results on the Evince a11y improvements project! For those of you that don't use GNOME or live under a rock, Evince is the great document viewer application for that desktop. It's a cute application that you probably use every day without even noticing it but it has a big problem with respect to accesibility. Almost all of its UI is accesible except for the main widget where the document is shown, which is where the neat things happen.

This has been a problem for a long time. The first bug report giving a warning about this issue is back from mid 2005 and a few people have tried to fix the problem without too much success. Then a small spanish goverment agency called Consortium Fernando de los Rios for the Knowledge and Information Society decided to found this (and others) project, which basically consist in make the damn thing work!

We are very glad we are working on this project. You can see our first results in the following video:

It shows ORCA (the GNOME screen reader) reading the text of a PDF opened with Evince. As you can see it has multi column layout and still it works great. This is mainly because recent changes in poppler code and it's great for us :-)

Now, don't even think this is done. There is a lot of work to be done and we are doing our best to work as close as we can with upstream people. Carlos Garcia, current Evince maintainer, is helping us a lot. His technical expertise and experience in Evince codebase is really making a difference to us. Thanks Carlos!

We still need to implement more methods of the AtkText interface and put it on the right place on Evince, caching the text and layout information that we get from poppler into Evince so we don't block the UI and everything is fast and smooth.

You can follow our progress in the Github clone that we made of Evince and poppler:

• http://github.com/danigm/poppler
• http://github.com/danigm/evince

Permalink | Leave a comment  »

Universal Edit Button[1] es un plugin de Firefox que detecta si la web
que estás viendo se puede editar y en ese caso te pone un icono de un
lápiz verde en la barra de direcciones. Funciona igual que cuando una
web tiene feeds disponibles y pone el icono naranja para subscribirse.

Lo único que hay que hacer en nuestras webs para soportarlo es añadir
este trozo de HTML en el head:

<link rel="alternate"
  type="application/x-wiki"
  title="Edit this page!"
  href="wiki?edit=WelcomeVisitors"/>

Está especialmente pensado para wikis, pero creo que puede tener sentido
en CMS también.

[1] http://www.universaleditbutton.org/Universal_Edit_Button

Permalink | Leave a comment  »

mviera@leonopteryx:~$ sudo apt-get install synergy quicksynergy

mviera@leonopteryx:~$ quicksynergy

 

mviera@leonopteryx:~$ synergyc -f --name buitre 192.168.11.188

Permalink | Leave a comment  »