Por eso quería traer algunos ejemplos de cómo conseguir lo que necesitamos realizando algunas modificaciones directamente en nuestra plantilla de WordPress.

Uno de los ámbitos que más suelen preocupar y que más tiende a hacer un uso intensivo de plugins es el SEO. Aún no sé si escribiré artículos más avanzados, pero de momento empezaremos por lo básico: título y descripción de las páginas.

¿Qué necesitamos?

Esto no va a ser una clase de SEO, de modo que supondremos que ya sabemos cómo escribir y escoger los textos para las distintas partes de cada página.

Lo que necesitamos es que cada página pueda mostrar un título y una descripción diferentes. Por ejemplo, hay montones de plantillas que utilizan la misma descripción para todas las páginas del blog (la descripción del blog, configurada en Ajustes > Generales) o directamente no ponen descripción en ninguna página salvo la principal.

¿Cómo lo hacemos?

Con el título lo tenemos fácil, sobre todo porque seguramente la plantilla en cuestión ya lo esté haciendo bien (o más o menos bien). Mi método suele ser el siguiente:

<title>
<?php
	if(is_home() or is_front_page())
	{
		$site_name = get_bloginfo('name', 'display');
		echo $site_name;
	}
	else
	{
		wp_title('', True, 'right');
	}
?>
</title>

A veces puede ser suficiente con utilizar la función wp_title, pero en muchos casos aparecerá un título en blanco en la página principal.

Otro modo de hacer lo mismo pero más “elegante” sería añadir un filtro a wp_title:

function filter_wp_title($title)
{
	if(is_home() or is_front_page())
	{
		$site_name = get_bloginfo('name', 'display');
		return $site_name;
	}
	return $title;
}
add_filter('wp_title', 'filter_wp_title');

Pero personalmente prefiero dejar el fichero functions.php lo más limpio posible. Manías.

El resultado de la función wp_title es predecible (títulos de artículos, nombres de categorías…) y suele ser suficiente. En caso de querer algo muy sofisticado y completamente diferente a lo habitual, con las herramientas anteriores se puede hacer casi de todo.

Con la descripción tendremos que ser un poco más creativos. Mi opción favorita para esto son los “campos personalizados” que WordPress permite añadir tanto a los artículos como a las páginas.

Creo un campo personalizado llamado “meta_description” y lo añado en cada nueva página. Para los artículos, el propio WordPress permite añadir un “extracto”, que por alguna razón no se suele utilizar pero puede ser muy útil. WordPress también permite dar descripciones a las categorías.

De modo que para la página principal utilizo la descripción del blog, para las categorías su propia descripción, para los artículos el extracto y para las páginas el campo personalizado “meta_description”.

Todo esto traducido a código sería algo así:

$meta_description = '';
	if(is_home() or is_front_page())
	{
		$meta_description = get_bloginfo('description', 'display');
	}
	elseif(is_single() or is_page())
	{
		if(has_excerpt()) $meta_description = get_the_excerpt();
		else $meta_description = get_post_meta(get_the_ID(), 'meta_description', True);
	}
	elseif(is_category())
	{
		$meta_description = category_description();
	}
	if($meta_description)
	{ 
		$meta_description = strip_tags($meta_description);
		echo '<meta name="description" content="'.$meta_description.'" />'; 
	}

En los artículos sin extracto se intentará utilizar el campo personalizado igual que en las páginas.

¿Y las keywords?

Me sorprende que a estas alturas aún se siga hablando de las “meta keywords” junto con el título y descripción. Simplemente no deberían usarse, al menos no como antes.

Este artículo de Google (de Septiembre de 2009) deja bastante claro que en el mejor de los casos no sirven para nada y en el peor de los casos podría ser perjudicial. Desde el punto e vista de Google, claro.

Hasta la fecha no hay señales de que esto haya cambiado o vaya a cambiar, y personalmente no creo que otros buscadores den algún tipo de valor positivo a esta meta-información.

Digamos que el contenido de tu canvas va cambiando. Si se hace más grande que el canvas pintarás fuera. Si se hace demasiado pequeño se verá ridículo con todo el espacio disponible alrededor. También puede ocurrir que en lugar de variar el tamaño del dibujo, sea el tamaño del canvas lo que cambie.

Hay técnicas básicas para escalar el contenido del canvas mediante CSS, pero sólo son útiles en casos muy concretos y sencillos.

Yo utilizo un método bastante sencillo pero que funciona muy bien:

1. Coloco los elementos dentro del canvas con el tamaño que me convenga.
2. Mantengo una lista de “puntos clave” en el dibujo.
3. Calculo la escala óptima para que todos los puntos clave quepan dentro del canvas manteniendo el dibujo lo más grande posible.
4. Aplico la escala al dibujo.
5. Recoloco el dibujo, pegándolo a la esquina superior izquierda.
6. Cada vez que haya un cambio en el dibujo (o en el tamaño del canvas) habrá que recalcular la escala y mover de nuevo el dibujo a la esquina si es necesario.

Se este modo el dibujo se ve siempre lo más grande posible.

Es importante tener claro que todos los elementos tendrán una doble representación. Por una parte tendremos las coordenadas y medidas “reales” que manejaremos internamente y por otra parte las que utilicemos para pintarlos al aplicar la escala.

¿Por qué dos medidas diferentes?

Supongamos que tenemos una línea que representa una pared que mide 4 metros. Por comodidad decidimos que vamos a tomar como referencia 1px = 1cm, de modo que tenemos una línea de 400px.

Si va recta desde la esquina superior izquierda hacia la derecha, la línea comenzará en las coordenadas (0/0) y terminará en (400/0). Internamente es mejor guardar las líneas como puntos así que nos guardamos esas dos coordenadas como representación de nuestra “pared”.

Pero el canvas que tenemos para dibujar es muy pequeño, digamos que de 200 x 200 píxeles. La escala a aplicar se ve claramente que es 0,5. Sin embargo, sólo aplicamos la escala en el momento de dibujar la línea, sin modificar las coordenadas reales del elemento.

De este modo conservamos los valores reales para otros usos y al mismo tiempo evitamos arrastrar pequeños errores de redondeo, ya que la escala se aplica siempre sobre el valor original en lugar de sobre valores que ya se han escalado anteriormente.

Los puntos clave.

Lo que suelo hacer es guardarme una lista con la posición de cada uno de los puntos que definen los extremos de los objetos. Los dos extremos de una línea, los vértices de un polígono, las 4 esquinas de una imagen…

Normalmente estos puntos sirven también para otros propósitos. Pero si no los necesito para nada más, otra opción es guardar solamente los puntos más extremos del dibujo ya que son los que usaremos para decidir la escala. En este caso tendremos que estar seguros de mantener los puntos actualizados si los elementos se mueven.

La escala.

La función para calcular la escala dependerá de cómo desarrollemos la aplicación, pero en general es muy fácil.

Tenemos que localizar los “bordes” del dibujo, que vienen a ser los valores máximos y mínimos de las coordenadas X e Y. Son 4 valores que delimitan el dibujo y pueden pertenecer a 4 puntos diferentes (el valor mínimo de X y de Y por ejemplo, no tienen por qué ser del mismo punto):

Con los 4 valores encontrados, tendremos dos posibles escalas que calcular. El ancho del dibujo viene marcado por la distancia entre los valores mínimo y máximo de X. La relación entre el ancho del canvas y del dibujo nos da la escala óptima para el eje X, y lo mismo sucede con el alto para el eje Y.

Si no es necesario mantener la relación de aspecto en el dibujo podemos directamente aplicar la escala óptima a cada eje, de lo contrario nos quedaremos con la menor y aplicaremos la misma a los dos.

Por último sólo tenemos que mover todo el contenido del canvas para pegarlo a la esquina superior izquierda. Para ello calculamos la distancia entre la esquina superior izquierda (0/0 si no estamos dejando ningún margen) para ambos ejes y la restamos a la posición de todos los elementos.

En el caso de aplicar la misma escala a ambos ejes seguramente nos sobre espacio a un lado del canvas, así que podemos optar por centrar el dibujo en lugar de moverlo completamente a la esquina.

El código:

Podéis ver un ejemplo en el siguiente enlace: Ejemplo de escala en canvas.

Por comodidad está todo el código en la misma página, basta con ver el código fuente desde el navegador o guardarla y abrirla con un editor de texto.

La interfaz para facilitar los datos de la empresa y la tienda es clara. El problema viene al generar el fichero CSV con los datos de los productos. Ni siquiera queda claro cómo se deben de llamar los campos y terminas a base de prueba y error, corrigiendo poco a poco las cosas que te dicen que están mal, en un castellano que se ve que no es su primer ni su segundo idioma. Al menos esa es mi experiencia con ellos.

Tras preparar un módulo de Prestashop (1.5, pero no creo que haya mucho problema en pasarlo a 1.6) he pensado en compartirlo por si alguien quiere usarlo o adaptarlo a sus necesidades.

Los campos exportados para cada producto son:

• Categoría: El nombre de la categoría principal del producto en la tienda.
• Referencia interna: La referencia del producto en la tienda (no la del proveedor).
• Título: El nombre del producto.
• Descripción: La descripción corta del producto.
• Precio: El precio del producto base, sin contar los atributos.
• URL producto: La URL de la página del producto.
• URL imagen: La URL de la imagen principal del producto.
• Gastos de envío: Modificable en la configuración del módulo.
• Disponibilidad: Todos los productos se marcan como disponibles ya que el módulo solo exporta los productos disponibles.
• Plazo de entrega: Modificable en la configuración del módulo.
• Garantía: Este campo es obligatorio que aparezca, pero lo dejamos siempre vacío.

Es sencillito y se puede ampliar mucho, pero en mi caso es más que suficiente. Si alguien quiere usarlo es posible que necesite hacerle alguna modificación. Está probado con Mercamania, pero debería funcionar tal cual con el resto de servicios de LeGuide (Pikengo, choozen, dooyoo…).

Así es como se ve la pantalla de configuración:

Básicamente lo que hace es crear un CSV al vuelo al acceder a cualquiera de las URLs que aparecen al final, a partir de los parámetros configurados.

Está escrito siguiendo el estándar de codificación de addons.prestashop.com (que es diferente a mi estilo habitual) ya que hice el intento de publicarlo como si lo fuese a vender, para ver si pasaba el análisis técnico que hacen a los módulos (y lo pasó).

El módulo en cuestión lo podéis encontrar en Google Code. Cualquier aportación es bienvenida.

Personalmente he oído todo tipo de comentarios, desde “total, yo no lo actualizaba…” hasta “¿y de dónde saco un crack para el 8?”. Evidentemente, una grandísima cantidad de gente continuará utilizando XP aunque a otros nos parezca una locura.

Si sigues utilizando XP o tienes un padre/amigo/vecino que no quiere o no puede cambiar, lo más recomendable reforzar la seguridad al máximo nivel de paranoia. Nuevas brechas de seguridad no serán parcheadas y es de esperar que un montón de malas personas estén ahí afuera frotándose las manos. De hecho, si somos muy paranoicos, podemos pensar que ya puede haber vulnerabilidades descubiertas hace meses que estén a la espera de comenzar a explotarse.

¿Internet? No, gracias.

El mejor modo de evitar casi cualquier amenaza es anular la conexión del equipo de Internet, pero en la mayoría de los casos no será una opción.

Entonces lo primero es utilizar un navegador que no sea Internet Explorer, ya que IE 10 y 11 no están disponibles para XP. Las opciones claras son Chrome y Firefox, y si la prioridad es la seguridad yo me quedaría con Chrome. Ambos tienen una extensión muy recomendable llamada HTTPS Everywhere para forzar el uso de HTTPS.

Luego viene un clásico que en la realidad no he visto hacer a casi nadie: utilizar cuentas de usuario limitadas. Utiliza una cuenta de administrador cuando tengas que instalar algo o hacer alguna configuración del sistema, pero ya está. Todo el resto del tiempo puedes y debes utilizar una cuenta limitada. Y todas las cuentas deben tener una contraseña, por difícil que resulte convencer a algunos…

El software actualizado siempre.

Lo siguiente que yo haría es asegurarme de que no queda nada instalado que no sea imprescindible y que todo lo instalado esté siempre actualizado (especialmente todo lo relacionado con Adobe y Java, y si puedes vivir con ellos mejor desinstálalos también). Una interesante herramienta puede ser PSI.

Lo mismo ocurre con las extensiones del navegador, cuantas menos mejor y de vez en cuando hay que comprobar que no se queden desactualizadas.

También hay que tener en cuenta que no sólo el sistema operativo deja de tener soporte, sino programas como Microsoft Office 2003 y muchos otros que se pueden sumar. Lo mejor es buscar alternativas para cualquier programa que deje de tener soporte para XP.

El software de seguridad.

Mis elecciones personales son AVG como antivirus, Comodo como Cortafuegos y Malwarebytes de refuerzo. Pero hay muchas opciones y cada uno tendrá sus preferencias.

En cualquier caso siempre vas a estar menos seguro por el simple hecho de utilizar un sistema operativo sin soporte.

Resumiendo.

En general, todo se resume a los consejos de siempre. No hay nada especial que puedas hacer para mantener un Windows XP con cierto nivel de seguridad, más que lo habitual. En mi opinión casi ninguna empresa que necesite tener conexión a Internet en los equipos puede permitirse el riesgo de mantenerlos con XP.

Operaciones sensibles como utilizar la web del banco o realizar compras online, sería mejor realizarlas en otro equipo que tenga un sistema actual. Por lo demás, supongo que ya se verá cómo de factible es seguir utilizando Windows XP a largo plazo. Yo aún me encuentro con Windows 98 más a menudo de lo que me gustaría, de modo que quién sabe…

No existe (que yo sepa) un modo de aumentar el tamaño del array de bits de un filtro Bloom una vez que ya se han empezado a añadir elementos. El modo de implementar un filtro escalable no es ni más ni menos que utilizar más de un filtro a la vez.

Para ello, cada vez que un filtro se llena se crea uno nuevo de mayor capacidad. Los nuevos elementos se van añadiendo al último filtro creado y a la hora de buscar un elemento se busca en todos uno por uno.

La base del filtro escalable es por tanto muy sencilla. La mayor complicación sería escoger el modo de escalar la capacidad de los filtros, es decir, cómo de grande debe ser el nuevo en comparación con el anterior. En su momento me vino a la cabeza la posibilidad de que todos tengan el mismo tamaño e incluso de que fuesen cada vez más pequeños, pero hasta la fecha no se me ha ocurrido ningún extraño caso en el que pueda resultar útil.

Lo normal es utilizar una función lineal o exponencial. Yo he optado por permitir ambas ya que no era ningún esfuerzo pero en la práctica siempre me ha venido mejor la exponencial. Los cálculos son muy sencillos:

# initial_capacity = capacidad del primer filtro
# scale_factor = factor de aumento
# filters = array de filtros, len(filters) es el número de filtros que ya haya
# Función lineal:
capacity = int(initial_capacity * (scale_factor * len(filters)))
# Función exponencial:
capacity = int(initial_capacity * (scale_factor ** len(filters)))

Añadir y buscar elementos también es muy sencillo:

def add(element):
    if filters[-1].is_full():
        # En el ejemplo del artículo anterior, el filtro se creaba pasando como parámetros la capacidad y el margen de error.
        filters.append(BloomFilter(calc_next_capacity(), error_rate))
    filters[-1].add(element)
#
def lookup(string):
    for f in reversed(filters):
        if f.lookup(string): return True
    return False

Lo único destacable es que al buscar es más eficiente recorrer los filtros en orden inverso (del último al primero), ya que de media se tardará menos en encontrar el elemento. Aunque en caso de no encontrarse la búsqueda tardará lo mismo se haga en un sentido u otro.

El código completo comentado se puede ver en Google Code.

Logotipo de Hack, el nuevo lenguaje de programación creado por Facebook y basado en PHP.

Hace poco que Facebook ha liberado su lenguaje de programación Hack, un nombre desafortunado para buscar en Google (prueba a buscar “hack code sample”).

Para echarle un vistazo rápido, el pequeño tutorial (inglés) que han preparado es un modo de empezar. Para empezar a probarlo más en serio se puede instalar una máquina virtual de Vagrant (inglés) con HHVM (inglés). Googleando un poco se encuentran máquinas virtuales ya listas para utilizar.

En docs.hhvm.com está toda la documentación sobre HHVM y Hack. De momento toda la documentación es en inglés, pero supongo que con el tiempo la irán traduciendo.

Ya hay montones de artículos por ahí enumerando las características y novedades del lenguaje (y se pueden leer en la web oficial o en el mismo índice del manual, no hace falta irse más lejos), así que me centraré en dos reflexiones que seguramente estaremos haciendo muchos ahora mismo:

¿Vale la pena aprenderlo y utilizarlo?

Si ya controlas PHP y comprendes los nuevos conceptos añadidos por Hack de trabajar con otros lenguajes, realmente hay poco que aprender salvo algunas reglas más de sintaxis. El resto es como en todos los lenguajes, usarlo lo suficiente como para aprender a “pensar en Hack” para sacarle el máximo partido.

Usarlo o no supongo que depende del punto de vista. Si quieres trabajar en Facebook, ya estás tardando :D. Creo que no se pierde nada por probarlo en una pequeña aplicación, aunque sólo sea por curiosidad. Pero para un proyecto serio me lo tendría que pensar.

Tiene desde luego un punto muy a favor: si Facebook lleva un tiempo utilizándolo, mal no debe funcionar. A esto se añaden todas las mejoras sobre PHP, que a simple vista parecen muy atractivas.

Sin embargo, hay que tener en cuenta un par de cosas. Supongamos que empiezas un proyecto nuevo y decides desarrollarlo con Hack. Supongamos también que dentro de dos años Facebook decide migrar a Python (por decir algo) y abandona el desarrollo de Hack y de HHVM. Como “la comunidad” no retome el proyecto y además lo haga bien (que puede pasar) vas a tener un problema.

También hay que tener en cuenta que HHVM y Hack están creados por Facebook para satisfacer sus necesidades específicas. Estas necesidades pueden coincidir con las tuyas o no.

¿Hack va a sustituir a PHP?

Pues no lo creo, al menos en mucho tiempo.

Supongamos por un momento que Hack es “superior” a PHP en todos los aspectos. Aunque fuese así, es muy difícil que los grandes frameworks y CMS se conviertan y mantengan dos versiones del software (Hack y PHP).

Por otra parte, el grueso de la comunidad de PHP está demasiado acostumbrado a buscar en Google cómo hacer X cosa en PHP y encontrar 40 implementaciones donde elegir. Por mucho que se pueda hablar de las bondades de PHP, su mejor carta es la enorme cantidad de código que ya hay escrito.

También es posible que con el tiempo PHP vaya adoptando características de Hack. Seguramente incluyendo el tipado gradual (la característica estrella de Hack) ya disuadiría a la mayoría de desarrolladores de “pasarse” a Hack, aunque no será lo que se dice una tarea fácil.

Cuando sabes lo que buscas es muy fácil fabricar un listado de URLs que necesitas revisar. Puede incluso ser una sola URL. Sin embargo, cuando necesitas ir detectando sobre la marcha nuevas URLs tienes que guardar un registro de las que ya has visitado. De lo contrario te encontrarás visitando las mismas páginas enlazadas entre sí una y otra vez hasta el fin de los tiempos.

Si sabemos que serán pocas las URLs a visitar, esto no es un gran problema. Simplemente nos guardamos una lista de las que vamos visitando y nos aseguramos de no repetir. El problema está cuando nos enfrentamos a sitios web muy grandes de los que necesitamos revisar una gran cantidad de páginas. Entonces eso de tener la lista de URLs en memoria se convierte rápidamente en una mala idea.

En estos casos, si las URLs en sí son relevantes (es decir, si cada URL es un dato que necesitas guardar por alguna otra razón) seguramente necesites una base de datos. Pero si lo único que necesitas saber es si ya has visitado antes una URL, los filtros Bloom son una opción increíblemente eficiente y rápida.

Bonita historia, pero ¿qué es un filtro Bloom?

No lo voy a explicar en profundidad ya que aparece muy bien explicado en la Wikipedia (inglés), incluyendo muchas referencias interesantes al final del artículo. De modo que comentaré lo más importante.

Las características principales de los filtros Bloom son las siguientes:

• Tiene un cierto margen de error (falsos positivos), calculable y ajustable.
• Al buscar un elemento, un resultado negativo significa que con toda seguridad no está en la lista.
• Un resultado positivo significa que un elemento probablemente está en la lista (debido a la posibilidad de falsos positivos).
• Requiere muy poco espacio en memoria y las consultas son muy rápidas.

El funcionamiento es muy sencillo, para implementarlo necesitaremos:

• Encontrar una implementación ya realizada que nos guste (nos parezca apropiada) y podamos utilizar (licencia), en cuyo caso ya habremos terminado :D.

o

• Una lista de elementos binarios (bit array).
• Una o más funciones de hashing.

En mi caso necesitaba una implementación en Python ya que es el lenguaje que suelo utilizar para las tareas de scraping. La implementación de pybloom la verdad es que no me gustó nada y no encontré ninguna otra que me sirviese. De modo que opté por hacerme la mía.

La elección de la función de hashing es muy importante. El requisito indispensable es que sea uniforme (todos los posibles valores tienen la misma probabilidad de aparecer como resultado) y determinista (un mismo valor de entrada genera siempre el mismo valor de resultado). También es importante, aunque no imprescindible, que sea no criptográfica. Las funciones de hashing criptográficas están muy bien para otros usos, pero son más lentas (este es uno de los principales inconvenientes que le veo a pybloom). No soy ningún experto en hashing, pero leyendo un poco la que más me convence por el momento es MurmurHash3.

Resumiendo, para la implementación en Python utilicé lo siguiente:

# Requiere instalar previamente bitarray y mmh3 (murmurhash3)
# sudo pip install bitarray
# sudo pip install mmh3

from bitarray import bitarray
import mmh3
from math import log, ceil

Añadir un elemento al filtro:

Para añadir un elemento realizaremos varios hashes del mismo. Se pueden utilizar distintas funciones de hashing o una sola función con diferentes semillas. Teniendo ya una función que me gusta y sin saber cuántos hashes diferentes voy a necesitar, me parece más lógico utilizar una sola con diferentes semillas:

# hash_count = número de hashes a realizar.
# size = tamaño del bitarray.
for seed in xrange(hash_count):
	position = mmh3.hash(element, seed) % size
	bit_array[position] = 1
element_count += 1

Los hashes mmh3 son numéricos, de modo que se pueden ajustar al tamaño del bitarray calculando el “módulo” (resto de división) con el operador “%”. El resultado es la posición del bitarray que marcamos a 1.

Buscar un elemento en el filtro:

Buscar un elemento en el filtro es muy parecido, simplemente comprobamos las posiciones que corresponderían al elemento que estamos buscando.

# hash_count = número de hashes a realizar.
# size = tamaño del bitarray.
for seed in xrange(self.hash_count):
	position = mmh3.hash(element, seed) % self.size
	if self.bit_array[position] == 0:
		return False
return True

Imagen extraída de la Wikipedia, donde se muestra la idea básica de un filtro Bloom utilizando 3 hashes para cada elemento.

El tamaño del bitarray y el número de hashes:

La mayoría de implementaciones que encontré eran clases cuyo constructor recibía como parámetros el tamaño del bitarray y el número de hashes a utilizar. Aunque se puede utilizar de esta manera, en la práctica creo que es mucho más cómodo especificar lo que realmente me importa: el número de elementos que quiero guardar y el margen de error que estoy dispuesto a permitir.

Para esto es necesario calcular el tamaño del bitarray y el número de hashes necesarios para poder almacenar el número de elementos que queremos con un margen de error menor o igual al especificado. Las fórmulas y su explicación se pueden ver también en la Wikipedia, pero escritas en Python serían algo así:

# capacity = número de elementos a guardar.
# error_rate = tasa de error, entre 0 (0%) y 1 (100%). Por ejemplo, 0.01 sería un 1%.
def calc_size():
	return int(ceil(- (float(capacity) * log(float(error_rate))) / (log(2))**2))

# Para calcular el número de hashes tenemos que haber calculado primero el tamaño del bitarray.
# size = tamaño del bitarray.
def calc_hash_count():
	return int(ceil((float(size) / float(capacity)) * log(2)))

Utilizo la función “ceil” para asegurarme de que se cumplen los requisitos (redondeando hacia arriba).

Uniones e intersecciones:

Algo que no he visto hasta la fecha en ninguna implementación de filtros Bloom, al menos en Python, son las operaciones de unión e intersección entre dos filtros (desde el punto de vista de teoría de conjuntos). Son increíblemente fáciles de implementar y en concreto la unión de filtros me ha resultado bastante útil.

Las intersecciones también pueden ser útiles, pero en mi caso (pocos o ningún elemento en común) los resultados no me han parecido lo bastante fiables.

Más abajo en el código final de la clase se puede ver la implementación de estas dos operaciones, pero es tan sencillo como realizar las operaciones a nivel de bit AND (&) y OR (|) entre los dos bitarray.

Mi implementación:

Esta es la clase que me hice. No es la que uso actualmente ya que más tarde hice un filtro Bloom escalable, más avanzado, que detallaré en otro artículo ya que este me está quedando más grande de lo que esperaba.

Los filtros Bloom tienen una infinidad de utilidades. Cabe destacar que esta clase fue creada específicamente para cubrir mis necesidades, por lo que hay algunas decisiones de implementación (como permitir añadir más elementos aunque el filtro esté al máximo de capacidad o devolver un valor vacío si no se puede realizar una unión) que pueden no ser buenas en otros contextos.

#!/usr/bin/python
# -*- coding: utf-8 -*-
#

# Requires bitarray and mmh3 (murmurhash3)
# sudo pip install bitarray
# sudo pip install mmh3

from bitarray import bitarray
import mmh3
from math import log, ceil

class BloomFilter:

        def __init__(self, capacity, error_rate):
                if not capacity > 0: raise ValueError("capacity must be > 0")
                if not (0 < error_rate < 1): raise ValueError("error_rate must be between 0 and 1.")
capacity.
                self.capacity = capacity
                self.element_count = 0
                self.error_rate = error_rate
                self.size = self.calc_size()
                self.hash_count = self.calc_hash_count()
                self.bit_array = bitarray(self.size)
                self.bit_array.setall(0)

        def add(self, element):
                for seed in xrange(self.hash_count):
                        position = mmh3.hash(element, seed) % self.size
                        self.bit_array[position] = 1
                self.element_count += 1

        def lookup(self, element):
                for seed in xrange(self.hash_count):
                        position = mmh3.hash(element, seed) % self.size
                        if self.bit_array[position] == 0:
                                return False
                return True

        def union(self, b):
                if self.size != b.size: return None
                if self.hash_count != b.hash_count: return None
                result = BloomFilter(self.capacity, self.error_rate)
                result.bit_array = self.bit_array | b.bit_array
                result.element_count = self.element_count + b.element_count
                return result

        def intersection(self, b):
                if self.size != b.size: return None
                if self.hash_count != b.hash_count: return None
                result = BloomFilter(self.capacity, self.error_rate)
                result.bit_array = self.bit_array & b.bit_array
                result.element_count = result.calc_element_count()
                return result

        def is_full(self):
                if self.element_count < self.capacity: return False
                else: return True

        def calc_size(self):
                return int(ceil(- (float(self.capacity) * log(float(self.error_rate))) / (log(2))**2))

        def calc_hash_count(self):
                return int(ceil((float(self.size) / float(self.capacity)) * log(2)))

        def calc_error_rate(self, use_capacity = False):
                if use_capacity: n = float(self.capacity)
                else: n = float(self.element_count)
                return (1.0 - (1.0 - 1.0 / float(self.size)) ** (float(self.hash_count) * n)) ** float(self.hash_count)

        def calc_element_count(self):
                x = float(self.bit_array.count())
                return int(ceil(- (float(self.size) * log(1.0 - (x / float(self.size)))) / float(self.hash_count)))

        def __contains__(self, string):
                return self.lookup(string)

El código completo comentado, incluyendo la versión escalable, está alojado en Google Code.

Se trata básicamente de crear un controlador para cada jugador y asignarle un personaje. Luego se van asignando eventos de pulsación de teclas (sólo teclas de momento) a funciones que afectarán a dicho personaje.

Sobre la gestión de colisiones…, menudas locuras he estado haciendo, hasta que me dí cuenta de que estaba cometiendo un error que parece ser (por lo que he leído luego en otros sitios) muy típico de novatos en esto de la programación de videojuegos: comprobar la colisión después de haber movido al personaje en lugar de hacerlo antes. En otras palabras, yo me preguntaba “¿ha chocado?” cuando lo que debería preguntarme es “¿chocaría?”. Cuando caí en la cuenta fue muy rápido de implementar.

Como siempre, me queda el consuelo de que no volveré a caer en un error de ese estilo.

Por último, he estado pensando en la cantidad de información que voy a tener que guardar sobre los mapas. Cuando empiece a pensar en un juego “de verdad” tendré que almacenar mucho más que el propio escenario: necesitaré los objetos y personajes no jugadores (NPC’s) que aparezcan en él, las coordenadas donde aparecerán, las acciones que realizarán… En fin, que toca pensar en bases de datos.

Antes creo que voy a tratar de implementar el “scrolling” de los mapas para poder mover a los personajes por mapas que excedan la resolución de la pantalla. Después comenzaré a pensar en el modelo de datos.

La principal diferencia entre los distintos tipos de personajes va a ser el movimiento. De momento voy a distinguir entre el movimiento tipo puzzle (el personaje se mueve tile por tile, no puede parar de moverse entre dos tiles) y el movimiento normal (el personaje se mueve “libremente”, sin la restricción anterior). He comenzado por implementar el movimiento normal ya que el movimiento tipo puzzle será un caso especial de éste.

El problema vendría al realizar juegos de plataformas, en los que el personaje sólo se mueve de izquierda a derecha y además “salta”. Éste caso lo voy a dejar para más adelante, tengo que estudiar cómo implementar el tema de la “gravedad”.

Por otra parte he creado una clase Player para el caso especial del jugador. He hecho algunas pruebas de movimiento, de animación e incluso de cambios de velocidad (para andar y correr, por ejemplo). Ya ayer subí los avances del proyecto. Para la prueba uso las flechas del teclado para mover al personaje y la tecla Z para “correr”.

Lo siguiente que quiero hacer es buscar alguna manera un poco más elegante de implementar el control del personaje y comenzar con la gestión de colisiones.

En principio he pensado en un escenario compuesto por una imagen de fondo y un mapa de tres capas basado en tiles. ¿Por qué tres capas? Pues porque las usaré para representar lo que está por detrás de los personajes, lo que está al mismo nivel y lo que está por delante. Combinado con un fondo creo que se pueden crear mapas decentes para casi cualquier tipo de juego.

En realidad voy a utilizar una cuarta capa para las colisiones con el escenario, que no se dibujará en pantalla ya que servirá para saber por qué partes del escenario no se pueden mover los personajes. Al principio pensé en considerar que el personaje colisionaría con todo lo que estuviese en la capa intermedia (supuestamente a su mismo nivel), pero creo que va a ser útil tenerlo por separado.

Existen bastantes herramientas para generar mapas basados en tiles, como Tile Mapper, Mappy o Tiled. Como no voy a meterme en mapas muy complejos y Tiled me ha gustado bastante, me quedo con él. En su wiki se explica el formato que utiliza y en Razón Artificial hay un buen ejemplo de cómo usarlo, entre otros artículos y tutoriales muy interesantes.

En cuanto al código, ya he subido la primera versión de las clases que gestionarán los mapas. Al proyecto le he llamado Paige y cualquiera queda invitado a colaborar.

Comento brevemente su estructura:

• La clase Map es la que se encarga de cargar los mapas y dibujar en pantalla el fondo y las distintas capas.
• La clase Tileset carga las imágenes de los tileset y las “trocea” para obtener la tabla de tiles individuales, además de dibujar tiles en la pantalla.
• La clase Layer carga las capas del mapa y las dibuja en pantalla.

También he subido unas imágenes y un mapa de prueba para ir viendo los resultados. De momento el mapa debe ser del mismo tamaño que la pantalla, más adelante trataré el tema del “scrolling”. El siguiente paso será el personaje.