Os dejo la secuencia de fotos con el making of de la funda.

También os dejo los planos en vectorial por si alguno se anima. Estos planos se han mejorado tras la primera funda. Mi madre ya está deseando hacer más para mejorar el resultado.

Nota: la inspiración original es esta. Me gustó tanto que fui a comprarmela pero en aquel momento no tenían en stock así que me puse manos a la obra y seguí el principio punki del “do it yourself”.

Parece que este problema no existe en el mundo Windows ya que las actualizaciones son mucho menos frecuentes y la gente del DNIe puede permitirse el lujo de distribuir un binario que funcionará durante al menos 3 o 4 años que es lo que suele durar una versión de este sistema operativo, frente a los 6-8 meses que duran las distribuciones de Linux. Es justo admitir que no es fácil seguir el ritmo de evolución de una distribución Linux pero también hay que recordar que este problema desaparecería si el código en cuestión fuera libre y se distribuyeran las fuentes listas para compilar con cualquier versión de las librerías implicadas.

Bueno, basta de quejas y vamos a lo que interesa, a hacer que funcione.

Lo primero es descargarnos los binarios para Fedora 10 que es lo más reciente que hay en la página de la policia. En este punto debemos sentirnos afortunados de ser usuarios de una de las tres distribuciones de Linux soportadas: Debian, Ubuntu y Fedora. La verdad, no sé como lo hará la gente de Gentoo, Suse, Mandriva, o Arch, por citar algunas de las más populares.

Desempaquetamos el tar y obtenemos dos paquetes rpm:

• opensc-0.11.7-7.fc10.i386.rpm
• opensc-dnie-1.4.6-2.fc10.i386.rpm

Al intentar instalar el primero tendremos un error de dependencias:

[root@ticotico ~]# rpm -Uvh --force opensc-0.11.7-7.fc10.i386.rpm
error: Error de dependencias:
libcrypto.so.7 se necesita para opensc-0.11.7-7.fc10.i386
libltdl.so.3 se necesita para opensc-0.11.7-7.fc10.i386

Y lo que está ocurriendo aquí es que las librerías libcrypto (paquete openssl) y libtdl (paquete libtool-ltdl) instaladas en mi sistema son más recientes que esas. Ahora nos toca forzar la instalación de opensc-0.11.7 aún sabiendo que es peor que opensc 0.11.8 que es la versión que ofrece Fedora 11, ya que la versión 0.11.7 tiene vulnerabilidades de seguridad. Los chicos del DNIe dicen que no liberan el código porque sería inseguro hacerlo así pero no actualizan su paquete haciendo que tengamos que usar librerías con fallos de seguridad. Una vez más, la seguridad por oscuridad triunfa. Un driver para atarnos a todos al reino de las sombras.

No nos desviemos, tras desinstalar nuestro querido opensc-0.11.8 de Fedora 11 instalaremos la versión 0.11.7:

[root@ticotico ~]# yum remove opensc
[root@ticotico ~]# rpm -Uvh --nodeps opensc-0.11.7-7.fc10.i386.rpm
Preparando...               ########################################### [100%]
   1:opensc                 ########################################### [100%]

Ahora bien, ahora tenemos que arreglar a mano el problema de las dependencias. Rezaremos para que las nuevas versiones de libcrypto y libtdll sean compatibles hacia atras. Con el comando ldd vemos si opensc tiene sus dependencias disponibles:

[root@ticotico ~]# ldd /usr/bin/opensc-tool
linux-gate.so.1 =>  (0x00525000)
libopensc.so.2 => /usr/lib/libopensc.so.2 (0x00dd8000)
libcrypto.so.7 => not found
libopenct.so.1 => /usr/lib/libopenct.so.1 (0x00d19000)
libz.so.1 => /lib/libz.so.1 (0x00318000)
libltdl.so.3 => not found
libdl.so.2 => /lib/libdl.so.2 (0x002f4000)
libscconf.so.2 => /usr/lib/libscconf.so.2 (0x00496000)
libpthread.so.0 => /lib/libpthread.so.0 (0x002fb000)
libc.so.6 => /lib/libc.so.6 (0x00157000)
/lib/ld-linux.so.2 (0x0012f000)
libcrypto.so.7 => not found
libltdl.so.3 => not found

Como era de esperar no encuentra ni libcrypto ni libtdl. Hacemos enlaces simbólicos para facilitarle la tarea:

[root@ticotico ~]# cd /usr/lib
[root@ticotico lib]# ln -s libltdl.so.7 libltdl.so.3
[root@ticotico lib]# ln -s libcrypto.so.8 libcrypto.so.7

Probamos otra vez con ldd:

[root@ticotico lib]# ldd /usr/bin/opensc-tool
linux-gate.so.1 =>  (0x009d2000)
libopensc.so.2 => /usr/lib/libopensc.so.2 (0x00670000)
libcrypto.so.7 => /usr/lib/libcrypto.so.7 (0x05e96000)
libopenct.so.1 => /usr/lib/libopenct.so.1 (0x00b19000)
libz.so.1 => /lib/libz.so.1 (0x00318000)
libltdl.so.3 => /usr/lib/libltdl.so.3 (0x063ea000)
libdl.so.2 => /lib/libdl.so.2 (0x002f4000)
libscconf.so.2 => /usr/lib/libscconf.so.2 (0x00897000)
libpthread.so.0 => /lib/libpthread.so.0 (0x002fb000)
libc.so.6 => /lib/libc.so.6 (0x00157000)
/lib/ld-linux.so.2 (0x0012f000)

Ahora ya podemos instalar el paquete del DNIe y hacerlo funcionar según las instrucciones oficiales:

[root@ticotico ~]# rpm -Uvh opensc-dnie-1.4.6-2.fc10.i386.rpm
Preparando...               ########################################### [100%]
   1:opensc-dnie            ########################################### [100%]

Ahora ya sólo nos queda validar el certificado en la página de pruebas: http://www.dnielectronico.es/como_utilizar_el_dnie/verificar.html

Actualización 29 Octubre 2009

Después de todo el follón para tener funcionando el DNIe que tuve ayer resulta que los certificados digitales que hay dentro me han caducado desde hace 4 meses. Parece que los certificados tienen una validez de 30 meses mientras que la tarjeta en sí vale para 4 años. No me preguntéis por qué, yo tampoco lo entiendo.

Así que tras haber despotricado sobre el driver del DNIe me parece justo alabar el proceso de renovación de los certificados porque aquí sí que creo que han hecho un estupendo trabajo los responsables del DNIe. He ido a la comisaría  más cercana de mi casa, en Sevilla, y aunque no estaba abierta al público aún (eran las 7:40 de la mañna) un policía bastante amable me ha preguntado que qué quería y tras explicarle lo de la renovación de los certificados del DNIe me ha dejado pasar para que lo hiciera yo mismo con un quiosco diseñado para tal fin. Una vez en el quiosco la experiencia de usuario ha sido magnífica y tras poner el dedo en el lector de huellas me ha renovado los dos certificados sin problema. Ha tardado un poco pero bueno, más vale lento pero que sea fiable y no pete. Mi satisfacción se debe por tanto a:

1. Un estupendo trabajo con el quiosco tanto hardware como software.
2. Un funcionario amable (el policia, en este caso) que me pregunta qué necesito y me permite usar un servicio aunque no haya comenzado el horario de atención al público.
3. Una ausencia total de espera, en parte debido a la hora, pero también a que se elimina la intervención de funcionarios para esta tarea.
4. Un ahorro para la administración pública al no necesitar de funcionarios para renovar estos certificados.

• when you have rotated labels
• when you have pie charts
• for the y axis tick labels

And that’s why I didn’t add his patch to pycha. When developing the library I always try to make it as orthogonal and predictable as possible, so if a feature is added and it should work in all places where it makes sense. Users that send me patches are not usually concerned about edge cases but that’s my work as the library author and maintainer.

But the real point is that Simon raised a real issue with Pycha that I was worried about since the very beginning: right now the user has to adjust the padding options to make sure that tick labels and other things are kept inside the surface. Clearly this is suboptimal and for automatically computed charts without human intervention it can be a real issue.

So let me explain how pycha uses its real state space right now. First, the user tells the library how big the rendering surface is going to be: let’s call these parameters surface_width and surface_height. Then there are these padding options: padding.top, padding.bottom, padding.left and padding.right. Let’s see it in the following figure:

Now we have a padding area and a chart area. The chart area is where pycha draws the chart. The axis (when used) are drawn in the boundary of the chart area and the tick labels and axis titles are drawn in the padding rectangle. Other things like the chart title and the legend are also drawn in that rectangle. You can see it in the next figure where the chart area has a blue background:

Now, I want to change this and make Pycha automatically compute all its elements so the padding is actually that, blank space. Optimally Pycha should not draw anything into the padding rectangle. Well, there maybe some exceptions, see the end of this post for more information about them. So let’s define some new areas:

The goal is to make Pycha compute all these areas automatically so the chart area is reduced to accomodate all the other things the library draws in the surface without cluttering the padding area. This is a big change and it won’t happen for 0.5.2 but I’ll try to have it for the 0.6.0 release. Obviously this is a backwards incompatible change and new charts rendered with the same options will look smaller. Maybe I’ll set the default values for the padding options to zero to minimize the update impact.

The way Pycha will compute these areas is actually pretty similar than the way graphical toolkits like Gtk+, Tk, Qt, Swing, GWT do it when using layout containers where the widgets are placed in. There is a layout phase where the area’s dimensions are negociated and calculated and then there is a rendering phase when the elements/widgets are actually drawn. For bar and line charts this may look overkill but for other charts like pie charts is really the only sane way to do it.

The legend is a special case and I’m still not sure about positioning it using ‘absolute’ coordinates or give it its own area that is taken into account for the layout algorithm.

Let me show you my broken pixel.

But before I’ll give you a small explanation of what the method does. Its class has a list of collectors, where each collector is a callable that return a generator of photos . The method collect the photos of all collectors until a maximum is reached, then it return the photos using an auxiliar method that does its own job postprocesing the list of photos.

Example carrusel

Here is my initial version:

    def collect_photos1(self, destination):
        n_photos_collected = 0
        for collector in self.collectors:
            for photo_info in collector(destination):
                self.add_photo(photo_info)
                n_photos_collected += 1
                if n_photos_collected > self.max:
                    return self.get_photos()

        return self.get_photos()

As you can see, no rocket science so far. It’s just a nested for loop that iterates over all the photos until we get as many as we want. The rotten pixel is the return self.get_photos() line. It is bad because it’s duplicated, one in the finished condition and one at the end of the method. There are two problems with that duplication:

• The first one is a practical problem. What if, in the future, the get_photos aux method need to receive a parameter. We need to update the call to that method, but as we have two calls there is a chance that we forget to update one of them. If we had only one the error probability of an update would be lower.
• The second problem is a theorical one. We are using a nested for loop to iterate over a list of lists of photos but we do not know in advance how long those lists are and how many loop body we are going to iterate.

My second version is basically the same as the first but instead of duplicating the return self.get_photos line we are duplicating the break condition. Now, if we add a parameter to the get_photos method we will have to update just one call. But if we want to add another condition to stop collecting photos we will have to update two if statements. In other words, this version is pretty much the same.

    def collect_photos2(self, destination):
        n_photos_collected = 0
        for collector in self.collectors:
            for photo_info in collector(destination):
                self.add_photo(photo_info)
                n_photos_collected += 1
                if n_photos_collected > self.max:
                    break
            if n_photos_collected > self.max:
                break

        return self.get_photos()

Then I tried to convert the for loops into while loops since basic computer science tell us that a while loop is the choice to make when the number of iterations is unknown. So this version does not have the previous two problems and it’s easier to maintain. Nevertheless, it introduces another problem: it’s harder to read and to understand.

    def collect_photos3(self, destination):
        n_photos_collected = 0
        need_more_photos = True
        collectors_iterator = iter(self.collectors)
        while need_more_photos and collectors_iterator.has_next():
            collector = collectors_iterator.next()

            photos_iterator = collector(destination)
            while need_more_photos and photos_iterator.has_next():
                photo_info = photos_iterator.next()
                self.add_photo(photo_info)
                n_photos_collected += 1

                if n_photos_collected > self.max:
                    need_more_photos = False

        return self.get_photos()

Version 4 is a crazy one. It tries to simulate to goto statement in Python. Everybody will tell you the goto statement is evil and well, most of the times, it is. But sometimes it has no good replacement like this one where we want to stop two nested loops with a statement. Too bad Python does not have a goto statement

    def collect_photos4(self, destination):
        n_photos_collected = 0
        try:
            for collector in self.collectors:
                for photo_info in collector(destination):
                    self.add_photo(photo_info)
                    n_photos_collected += 1
                    if n_photos_collected > self.max:
                        raise TypeError('goto')

        except TypeError:
            pass

        return self.get_photos()

Now, what if we separate the two problems this method is trying to solve: iterating over the photos and adding to our result set. Doing so we can write a simple generator that gives us a photo at a time and then a while loop that check there are more photos in this generator and we actually want them. I like this version more than any of the previous one but still, the while loop is not very readable.

    def collect_photos5(self, destination):
        def photos_fetcher():
            for collector in self.collectors:
                for photo in collector(destination):
                    yield photo

        n_photos_collected = 0
        photos_iterator = photos_fetcher()
        while n_photos_collected < self.max and photos_iterator.has_next():
            photo_info = photos_iterator.next()
            self.add_photo(photo_info)
            n_photos_collected += 1

        return self.get_photos()

And then, the last version. I decided to add the stop condition logic into the generator and as it is a nested function I can put a return statement to exit from the two nested loops. Then the main loop can be a for loop without the boilerplate management code that the while loop needed.

    def collect_photos6(self, destination):
        def photos_fetcher(max_photos):
            n_photos_collected = 0
            for collector in self.collectors:
                for photo in collector(destination):
                    if n_photos_collected > max_photos:
                        return
                    yield photo
                    n_photos_collected += 1

        for photo_info in photos_fetcher(self.max):
            self.add_photo(photo_info)

        return self.get_photos()

What version do you like most?

This time we will try to combine both aproaches to get the best of both worlds.

The interface definitions do not change:

    >>> from zope.interface import Interface, Attribute
    >>> class IPerson(Interface):
    ...     name = Attribute("Name")
    ...
    >>> class ISecretAgent(IPerson):
    ...     passcode = Attribute("Passcode")
    ...
    >>> class ITeacher(IPerson):
    ...     school = Attribute("School")

Neither the Person class:

    >>> from zope.interface import implements
    >>> from zope.interface.verify import verifyClass
    >>> from lazr.delegates import delegates
    >>> from storm.locals import Store, Storm, Unicode, Int, Proxy, Reference
    >>> class Person(Storm):
    ...     implements(IPerson)
    ...
    ...     __storm_table__ = "person"
    ...
    ...     id = Int(allow_none=False, primary=True)
    ...     name = Unicode()
    ...     person_type = Int(allow_none=False)
    ...     _person = None
    ...
    ...     def __init__(self, store, name, person_class, **kwargs):
    ...         self.name = name
    ...         self.person_type = person_class.person_type
    ...         store.add(self)
    ...         self._person = person_class(self, **kwargs)
    ...
    ...     @property
    ...     def person(self):
    ...         if self._person is None:
    ...             assert self.id is not None
    ...             person_class = BasePerson.get_class(self.person_type)
    ...             self._person = Store.of(self).get(person_class, self.id)
    ...         return self._person
    ...
    >>> verifyClass(IPerson, Person)
    True

Now, the real magic is in the metaclass. We use it not only to register our subclasses (so the Person.person property can find them) but to automatically store the attributes we needed to set manually in our previous version: the person_id and person attributes and a proxy object for each Person attribute. It’s like we are reimplementing inheritance in Python but not really

    >>> from storm.properties import PropertyPublisherMeta
    >>> class PersonType(PropertyPublisherMeta):
    ...     def __init__(self, name, bases, dict):
    ...         if hasattr(self, '__storm_table__'):
    ...             # this need to be done before calling the superclass
    ...             # otherwise Storm will cry about not having a primary key
    ...             self.person_id = Int(allow_none=False, primary=True)
    ...
    ...         super(PersonType, self).__init__(name, bases, dict)
    ...
    ...         if not hasattr(self, '_person_types_registry'):
    ...             self._person_types_registry = {}
    ...         elif hasattr(self, '__storm_table__'):
    ...             key = len(self._person_types_registry)
    ...             self._person_types_registry[key] = self
    ...             self.person_type = key
    ...
    ...             self.person = Reference(self.person_id, Person.id)
    ...             self._add_proxy_properties()
    ...
    ...     def _add_proxy_properties(self):
    ...         for name in IPerson:
    ...             if not hasattr(self, name):
    ...                 remote_attr = getattr(Person, name)
    ...                 setattr(self, name, Proxy(self.person, remote_attr))
    ...
    ...     def get_class(self, person_type):
    ...         return self._person_types_registry[person_type]

Not our BasePerson is really simple

    >>> class BasePerson(Storm):
    ...     __metaclass__ = PersonType
    ...
    ...     def __init__(self, person):
    ...         self.person = person

And so are the subclasses. No repetition, so it is less prone to mistakes

    >>> class SecretAgent(BasePerson):
    ...     implements(ISecretAgent)
    ...
    ...     __storm_table__ = "secret_agent"
    ...     passcode = Unicode()
    ...
    ...     def __init__(self, person, passcode=None):
    ...         super(SecretAgent, self).__init__(person)
    ...         self.passcode = passcode
    ...
    >>> verifyClass(ISecretAgent, SecretAgent)
    True
    >>> class Teacher(BasePerson):
    ...     implements(ITeacher)
    ...
    ...     __storm_table__ = "teacher"
    ...     school = Unicode()
    ...
    ...     def __init__(self, person, school=None):
    ...         super(Teacher, self).__init__(person)
    ...         self.school = school
    ...
    >>> verifyClass(ITeacher, Teacher)
    True

Let’s make sure our queries work as expected:

    >>> from storm.locals import create_database
    >>> database = create_database("sqlite:")
    >>> store = Store(database)
    >>> result = store.execute("""
    ...     CREATE TABLE person (
    ...         id INTEGER PRIMARY KEY,
    ...         person_type INTEGER NOT NULL,
    ...         name TEXT NOT NULL)
    ... """)
    >>> result = store.execute("""
    ...     CREATE TABLE secret_agent (
    ...         person_id INTEGER PRIMARY KEY,
    ...         passcode TEXT)
    ... """)
    >>> result = store.execute("""
    ...     CREATE TABLE teacher (
    ...         person_id INTEGER PRIMARY KEY,
    ...         school TEXT)
    ... """)
    ...
    >>> secret_agent = Person(store, u"James Bond",
    ...                        SecretAgent, passcode=u"007")
    >>> ISecretAgent.providedBy(secret_agent.person)
    True
    >>> teacher = Person(store, u"Albus Dumbledore",
    ...                  Teacher, school=u"Hogwarts")
    >>> ITeacher.providedBy(teacher.person)
    True
    >>> store.commit()
    >>> del secret_agent
    >>> del teacher
    >>> store.rollback()
    >>> secret_agent = store.find(SecretAgent).one()
    >>> secret_agent.name, secret_agent.passcode
    (u'James Bond', u'007')
    >>> teacher = store.find(Teacher).one()
    >>> teacher.name, teacher.school
    (u'Albus Dumbledore', u'Hogwarts')
    >>> secret_agent = store.find(SecretAgent, SecretAgent.name==u'James Bond').one()
    >>> secret_agent.passcode
    u'007'
    >>> teacher = store.find(Teacher, Teacher.school==u'Hogwarts').one()
    >>> teacher.name
    u'Albus Dumbledore'

So we made it by using a metaclass that automatically generate a bunch of attributes.

    secret_agent = store.find(SecretAgent, SecretAgent.name==u'James Bond').one()

The reason is that the expresion SecretAgent.name would resolve to a Passthrough lazr.delegates object that Storm does not know how to handle.

This time we will try to fix this problem using a manually generated version of our classes using storm’s Proxy objects.

The interface definitions do not change:

    >>> from zope.interface import Interface, Attribute
    >>> class IPerson(Interface):
    ...     name = Attribute("Name")
    ...
    >>> class ISecretAgent(IPerson):
    ...     passcode = Attribute("Passcode")
    ...
    >>> class ITeacher(IPerson):
    ...     school = Attribute("School")

Neither the Person class:

    >>> from zope.interface import implements
    >>> from zope.interface.verify import verifyClass
    >>> from lazr.delegates import delegates
    >>> from storm.locals import Store, Storm, Unicode, Int, Proxy, Reference
    >>> class Person(Storm):
    ...     implements(IPerson)
    ...
    ...     __storm_table__ = "person"
    ...
    ...     id = Int(allow_none=False, primary=True)
    ...     name = Unicode()
    ...     person_type = Int(allow_none=False)
    ...     _person = None
    ...
    ...     def __init__(self, store, name, person_class, **kwargs):
    ...         self.name = name
    ...         self.person_type = person_class.person_type
    ...         store.add(self)
    ...         self._person = person_class(self, **kwargs)
    ...
    ...     @property
    ...     def person(self):
    ...         if self._person is None:
    ...             assert self.id is not None
    ...             person_class = BasePerson.get_class(self.person_type)
    ...             self._person = Store.of(self).get(person_class, self.id)
    ...         return self._person
    >>> verifyClass(IPerson, Person)
    True

Neither our custom metaclass:

    >>> from storm.properties import PropertyPublisherMeta
    >>> class PersonType(PropertyPublisherMeta):
    ...     def __init__(self, name, bases, dict):
    ...         super(PersonType, self).__init__(name, bases, dict)
    ...         if not hasattr(self, '_person_types_registry'):
    ...             self._person_types_registry = {}
    ...         elif hasattr(self, '__storm_table__'):
    ...             key = len(self._person_types_registry)
    ...             self._person_types_registry[key] = self
    ...             self.person_type = key
    ...
    ...     def get_class(self, person_type):
    ...         return self._person_types_registry[person_type]

Here start the changes. Our BasePerson class does not have the delegates call and does not define the person_id attribute and person reference.

    >>> class BasePerson(Storm):
    ...     __metaclass__ = PersonType
    ...
    ...     def __init__(self, person):
    ...         self.person = person

Instead we define the person_id and person reference in each subclass and also we define each attribute of the Person base class as a proxy to the related attribute of the person reference.

    >>> class SecretAgent(BasePerson):
    ...     implements(ISecretAgent)
    ...
    ...     __storm_table__ = "secret_agent"
    ...     passcode = Unicode()
    ...     person_id = Int(allow_none=False, primary=True)
    ...     person = Reference(person_id, Person.id)
    ...     name = Proxy(person, Person.name)
    ...
    ...     def __init__(self, person, passcode=None):
    ...         super(SecretAgent, self).__init__(person)
    ...         self.passcode = passcode
    >>> verifyClass(ISecretAgent, SecretAgent)
    True

We do it again for the Teacher class:

    >>> class Teacher(BasePerson):
    ...     implements(ITeacher)
    ...
    ...     __storm_table__ = "teacher"
    ...     school = Unicode()
    ...     person_id = Int(allow_none=False, primary=True)
    ...     person = Reference(person_id, Person.id)
    ...     name = Proxy(person, Person.name)
    ...
    ...     def __init__(self, person, school=None):
    ...         super(Teacher, self).__init__(person)
    ...         self.school = school
    >>> verifyClass(ITeacher, Teacher)
    True

Time to test the database storage:

    >>> from storm.locals import create_database
    >>> database = create_database("sqlite:")
    >>> store = Store(database)
    >>> result = store.execute("""
    ...     CREATE TABLE person (
    ...         id INTEGER PRIMARY KEY,
    ...         person_type INTEGER NOT NULL,
    ...         name TEXT NOT NULL)
    ... """)
    >>> result = store.execute("""
    ...     CREATE TABLE secret_agent (
    ...         person_id INTEGER PRIMARY KEY,
    ...         passcode TEXT)
    ... """)
    >>> result = store.execute("""
    ...     CREATE TABLE teacher (
    ...         person_id INTEGER PRIMARY KEY,
    ...         school TEXT)
    ... """)
    >>> secret_agent = Person(store, u"James Bond",
    ...                        SecretAgent, passcode=u"007")
    >>> ISecretAgent.providedBy(secret_agent.person)
    True
    >>> teacher = Person(store, u"Albus Dumbledore",
    ...                  Teacher, school=u"Hogwarts")
    >>> ITeacher.providedBy(teacher.person)
    True
    >>> store.commit()

And what’s more important, all this changes should make possible to do the query with the subclass:

    >>> del secret_agent
    >>> del teacher
    >>> store.rollback()
    >>> secret_agent = store.find(SecretAgent).one()
    >>> secret_agent.name, secret_agent.passcode
    (u'James Bond', u'007')
    >>> teacher = store.find(Teacher).one()
    >>> teacher.name, teacher.school
    (u'Albus Dumbledore', u'Hogwarts')
    >>> secret_agent = store.find(SecretAgent, SecretAgent.name==u'James Bond').one()
    >>> secret_agent.passcode
    u'007'

We have improved the power of the pattern but now it is much more verbose to write each subclass since we need to repeat a lot of things. Note that we can not move the definition of the person_id and person attributes to the BasePerson aux class because Storm will tell us that it lacks the __storm_table__ attribute. In other words: storm does not allow attributes in abstract classes.

One pattern to accomplish this is the infoheritance pattern described in the
Storm documentation. I’ll show you here a slightly modified version of this
pattern that uses the package lazr.delegates to make the user code easier by
hiding the fact that we are using composition to model inheritance.

So let’s start with some interface definition showing our model hierarchy:

    >>> from zope.interface import Interface, Attribute
    >>> class IPerson(Interface):
    ...     name = Attribute("Name")
    ...
    >>> class ISecretAgent(IPerson):
    ...     passcode = Attribute("Passcode")
    ...
    >>> class ITeacher(IPerson):
    ...     school = Attribute("School")

No rocket science so far. Let’s write now the implementation of the
IPerson interface. This will be our abstract base class. Pay special
attention to the person property which dynamically retrieve the subclass
instance by using composition.

    >>> from zope.interface import implements
    >>> from zope.interface.verify import verifyClass
    >>> from lazr.delegates import delegates
    >>> from storm.locals import Store, Storm, Unicode, Int, Reference
    >>> class Person(Storm):
    ...     implements(IPerson)
    ...
    ...     __storm_table__ = "person"
    ...
    ...     id = Int(allow_none=False, primary=True)
    ...     name = Unicode()
    ...     person_type = Int(allow_none=False)
    ...     _person = None
    ...
    ...     def __init__(self, store, name, person_class, **kwargs):
    ...         self.name = name
    ...         self.person_type = person_class.person_type
    ...         store.add(self)
    ...         self._person = person_class(self, **kwargs)
    ...
    ...     @property
    ...     def person(self):
    ...         if self._person is None:
    ...             assert self.id is not None
    ...             person_class = BasePerson.get_class(self.person_type)
    ...             self._person = Store.of(self).get(person_class, self.id)
    ...         return self._person
    >>> verifyClass(IPerson, Person)
    True

We will also use a custom metaclass (based on Storm metaclass) so it will
automatically register our subclasses. This is necessary for the dynamic
person property of the Person class where we map integer (stored in the
database) to classes (stored in the source code).

    >>> from storm.properties import PropertyPublisherMeta
    >>> class PersonType(PropertyPublisherMeta):
    ...     def __init__(self, name, bases, dict):
    ...         super(PersonType, self).__init__(name, bases, dict)
    ...         if not hasattr(self, '_person_types_registry'):
    ...             self._person_types_registry = {}
    ...         elif hasattr(self, '__storm_table__'):
    ...             key = len(self._person_types_registry)
    ...             self._person_types_registry[key] = self
    ...             self.person_type = key
    ...
    ...     def get_class(self, person_type):
    ...         return self._person_types_registry[person_type]

Now we define a convenience base class for our subclasses. Remember that
the subclasses don’t really inherit from the Person class because we
are using composition. This is where the lazr.delegates.delegates function
comes to rescue. By saying that we delegate the implementation of the
IPerson interface to the ‘person’ attribute, the instances of these subclasses
will look like they really are subclasses of Person, not just from BasePerson.

    >>> class BasePerson(Storm):
    ...     __metaclass__ = PersonType
    ...     delegates(IPerson, "person")
    ...
    ...     person_id = Int(allow_none=False, primary=True)
    ...     person = Reference(person_id, "Person.id")
    ...
    ...     def __init__(self, person):
    ...         self.person = person
    ...
    >>> class SecretAgent(BasePerson):
    ...     implements(ISecretAgent)
    ...
    ...     __storm_table__ = "secret_agent"
    ...     passcode = Unicode()
    ...
    ...     def __init__(self, person, passcode=None):
    ...         super(SecretAgent, self).__init__(person)
    ...         self.passcode = passcode

Here is the magic: we have an interface hierarchy and a different
hierarchy for the classes implementing them. But it’s all transparent
and our classes implement the full hierarchy:

    >>> verifyClass(ISecretAgent, SecretAgent)
    True
    >>> class Teacher(BasePerson):
    ...     implements(ITeacher)
    ...
    ...     __storm_table__ = "teacher"
    ...     school = Unicode()
    ...
    ...     def __init__(self, person, school=None):
    ...         super(Teacher, self).__init__(person)
    ...         self.school = school
    ...
    >>> verifyClass(ITeacher, Teacher)
    True

Now let’s try storing the objects in the database. We will use a
sqlite in memory database for this example.

    >>> from storm.locals import create_database
    >>> database = create_database("sqlite:")
    >>> store = Store(database)
    >>> result = store.execute("""
    ...     CREATE TABLE person (
    ...         id INTEGER PRIMARY KEY,
    ...         person_type INTEGER NOT NULL,
    ...         name TEXT NOT NULL)
    ... """)
    >>> result = store.execute("""
    ...     CREATE TABLE secret_agent (
    ...         person_id INTEGER PRIMARY KEY,
    ...         passcode TEXT)
    ... """)
    >>> result = store.execute("""
    ...     CREATE TABLE teacher (
    ...         person_id INTEGER PRIMARY KEY,
    ...         school TEXT)
    ... """)
    >>> secret_agent = Person(store, u"James Bond",
    ...                        SecretAgent, passcode=u"007")
    >>> ISecretAgent.providedBy(secret_agent.person)
    True
    >>> teacher = Person(store, u"Albus Dumbledore",
    ...                  Teacher, school=u"Hogwarts")
    >>> ITeacher.providedBy(teacher.person)
    True
    >>> store.commit()

The objects are now saved in the database. Let’s destroy them and
retrieve them back using some queries:

    >>> del secret_agent
    >>> del teacher
    >>> store.rollback()
    >>> secret_agent = store.find(SecretAgent).one()
    >>> secret_agent.name, secret_agent.passcode
    (u'James Bond', u'007')
    >>> teacher = store.find(Teacher).one()
    >>> teacher.name, teacher.school
    (u'Albus Dumbledore', u'Hogwarts')

The great thing is that we can write teacher.name without having to
write teacher.person.name (which also works by the way) effectively
hiding the implementation detail of composition.

Just one final note: Bear in mind that you should not have very deep
hierarchies or you may get a lot of JOINs and a slow application.

You can download a couple of files to test this on your own computer. You just need storm 0.14 and lazr.delegates 1.0, both of which can be installed with easy_install:

• Doctests
• Test runner

Nokia 6234

A continuación escribo las opciones que he tenido que configurar en el móvil para conseguirlo. Espero que la nomenclatura se entienda.

Configuración: Configuración: Ajustes config. personal: Opciones: Añadir nuevo: Internet

  Nombre de cuenta: Internet Simyo
  Página de inicio: http://www.google.com
  Nombre de usuario:
  Contraseña:
  Usar pto. acceso preferido: No
  Conf. de punto de acceso:

    Proxy: Activado
    Dirección de proxy: 217.18.32.181
    Puerto de proxy: 8080
    Portador de datos: Paquetes de datos
    Configuración portador:

      Pto. acceso paquts. datos: gprs-service.com
      Tipo de red: IPv4
      Tipo de autentificación: Normal
      Nombre de usuario:
      Contraseña: 

Internet: Configuración: Ajustes de configuración:

  Configuración: Configuración personal
  Cuenta: Internet Simyo
  Mostrar ventana terminal: No

Para el que esté pensando que eso de internet desde un móvil normalito no tiene mucho sentido pues sí y no. Está claro que cualquier parecido entre navegar con un ordenador y un móvil como el mío es pura coincidencia, pero eso no quiere decir que la posibilidad de ver tu correo en Gmail desde tu móvil no sea útil o también, la posibilidad de sincronizar tus contactos entre el móvil, el ordenador, tu cuenta google, etc. usando servicios como scheduleworld.com

Las tarifas de mi proveedor las podeis consultar en su web y la verdad es que me parecen bastante razonables. Por ahora estoy contento con Simyo no sólo por que me resulta más barato que mi anterior proveedor, si no porque es infinitamente más transparente y claro que los demás y al menos tienes la sensación de que estás pagando por lo que usas, no por lo que ellos quieren.

El siguiente paso ha sido conectar mi Nokia N800 al teléfono vía Bluetooth y usar la conexión a internet del teléfono para navegar desde el otro cacharro. Esto ya se va pareciendo mucho más a navegar a la vieja usanza gracias a la pantalla de 800 pixeles de ancho que tiene el N800.

Nokia N800

Si mi portátil tuviera Bluetooth, también podría conectarme a internet desde cualquier sitio, pero fui tan listo al comprarlo que desactive esa opción pensando que nunca la usaría. Ahora puedo pedir esa ampliación e instalarla yo mismo o comprar un pequeño dongle usb y hacer lo mismo.

mencoder Fringe-S01E06.avi -o Fringe-S01E06-n800.avi -oac mp3lame -lavcopts acodec=libmp3lame:abitrate=96 -ovc lavc -lavcopts vcodec=mpeg4:autoaspect:vbitrate=600:vpass=1:turbo -vf scale=400:240 -ffourcc DIVX -idx

Update: add these options to embed subtitles:

-sub Fringe-S01E06.srt -subcp latin5 -subfont-text-scale 4

You will need a subfont.ttf font file in ~/.mplayer/

Nota para posibles visitantes a Londres: im-pres-cin-di-ble la Oyster card para viajar por el metro. Sale muchísimo más barata que ir a pagando a pelo y luego está el efecto molón de ir pasando la cartera por los lectores de tarjetas sin necesidad de sacar la tarjeta. Al final le cogimos el truco y parecíamos londinenses, bueno eso de cuello para abajo, de cuello para arriba era muy difícil ocultar que en realidad somos de londonelzaidin ya que la cara de empanaos y turistas la llevamos a todas partes. Igual que Dos Flores.

De las cosas que vimos, que no fueron pocas (a Ana incluso se le rompieron los zapatos de tanto andar) nos quedamos sin duda con el museo de Historia Natural. Impresionante tanto el continente como el contenido. No tan popular como la Tate o el Museo Británico pero para flipaos de los bichos como nosotros igual o más interesante.

Mención especial de nuestro viaje fue el encuentro con nuestro más querido Tripulante, que hizo de anfitrión excepcional y nos enseño todo el Soho (el barrio) mostrándonos tanto los sitios más típicos como algunos restaurantes con las tres bes. Un día toco italiano y otro día griego. Muy mediterráneo, sí, pero mejor no preguntéis por la comida inglesa: es casi inexistente si la buscas en restaurantes y por algo será.

En fín, un viaje muy típico pero también muy recomendable. Si aún no has estado en Londres, no tienes excusa ahora que está a tiro de piedra con compañias low cost. Más fotos en el Flickr de Ana.

También han sido mis vacaciones más largas desde que empecé en Sicem haya por el 2003. Quince días de vacaciones y quince en paro. El lunes empiezo en Yaco y la verdad, tengo bastantes ganas de empezar y cambiar un poco de aires.