martes, 30 de octubre de 2007

Patrones de diseño para torpes - 1ª parte

Hoy hablamos de los famosos patrones de diseño o design patterns. Hay montones de libros y artículos sobre el tema, empezando por el famoso libro "Desing Patterns", de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

El caso es que no me acabo de enterar muy bien (a ratos soy un poco lerdo) y me pierdo un poco, así que he decidido explicarme a mí mismo algunos patrones de diseño típicos.



Una de las cosas que no me gustan es que las explicaciones y ejemplos que se proponen en muchos libros o artículos están relacionadas con objetos "sofware". ¿No es acaso la programación orientada a objetos una ayuda para representar o modelizar sistemas u objetos "reales"?

Pues voy a tratar de explicar los patrones de diseño con ejemplos cotidianos, no "software", a ver qué tal me sale.

El patrón "Factory"


Este patrón de diseño es muy útil cuando tenemos que crear (=instanciar) distintos objetos que tienen algo en común (=comparten una interfaz). Ya me he liado con tecnicismos.

Imaginemos que vamos con nuestra cámara de fotos y el coche teledirijido de nuestr@ hij@ a una tienda de electricidad para comprar pilas. El enfoque "sencillo" (=aplicando un patrón de diseño) es decirle al vendedor: "quiero pilas para estos cacharros". El enfoque complicado (=instanciar cada objeto por separado) es decirl: "quiero pilas AAA (de 1,5 V) para la cámara, una pila de petaca de 9V para el mando y pilas AA para el cochecito".

Analicemos el objeto demandado en cuestión: las pilas. ¿Qué caracteriza a una pila? Su voltaje, su tamaño y poco más. Es decir, las pilas tienen una interfaz común, pero son diferentes unas de otras. Si tuviésemos que modelizarlas usando clases tendríamos la clase PilaAAA, PilaPetaca, PilaAA y alguna más.
mi_pilaAAA = new PilaAAA()
mi_pilaPetaca = new PilaPetaca()
mi_pilaAA = new PilaAA()

Cada uno de estos objetos instanciados deberíamos asociarlo a su receptor:
camara_fotos.setPila(mi_pilaAAA)
mando_distancia.setPila(mi_pilaPetaca)
cochecito.setPila(mi_pilaAA)

¿No sería más cómodo tener algo (=el dependiente) que se encargase de darnos las pilas con sólo decirle para qué las queremos?
dependiente = new Dependiente()
camara_fotos.setPila(dependiente.damePilas(this))
mando_distancia.setPila(dependiente.damePilas(this))
cochecito.setPila(dependiente.damePilas(this))

Parece un gran avance, ¿no? Cada objeto cliente (la cámara, el mando a distancia y el cochecito) se despreocupan de saber qué características tienen las pilas que usan. Simplemente le piden pilas al dependiente y listo.
Es tarea del dependiente saber qué tipo de pilas tiene que devolver, y la forma de hacerlo (=implementación) es transparente para el cliente. Hoy puede que el dependiente mire un catálogo, mañana puede que consulte una base de datos y pasado mañana a lo mejor solicita un fichero XML de aparatos y pilas, pero esto no es algo que deba saber el objeto cliente.

Bien, pues simplificando bastante, el patrón "Factory" es esto mismo. Un objeto especializado se encarga de instanciar objetos para clientes, y estos utilizan los métodos que proporciona la interfaz del objeto recibido, pero sin saber nada de las interioridades del objeto, ni siquiera qué tipo de objeto es (=a partir de qué clase está instanciado).

Veamos un ejemplo un poco más "software". Imaginemos que tenemos una clase sencilla en una aplicación de blogs que se dedica a "pintar" en pantalla el título, autor y fecha de publicación de algunos envíos.
Estos envíos pueden estar guardados en una base de datos o provenir de un RSS, por ejemplo.

A la clase cliente (la que "pinta" en pantalla") le da igual el origen de los datos, sólo quiere los datos. Voy a poner un poco de código --utilizaré Python, que me gusta bastante ;-) y me parece muy claro.
class EnviosRSS:
def __init__(self, url_rss):
# Hacemos algo para traer los datos de la url
self.post = lo_que_sea
def dameAutor(self):
return self.post.autor
def dameTitulo(self):
return self.post.titulo
def dameFecha(self):
return self.post.fecha

class EnviosBBDD:
def __init__(self):
# Hacemos algo para traer los datos de la base de datos
self.post = lo_que_sea
def dameAutor(self):
return self.post.autor
def dameTitulo(self):
return self.post.titulo
def dameFecha(self):
return self.post.fecha

class EnviosFactory:
def dameEnvios(self, url=''):
if url == '':
return EnviosBBDD()
else:
return EnviosRSS(url)

# código cliente
factory = EnviosFactory()
envios1 = factory.dameEnvios()
envios2 = factory.dameEnvios('http://davidasorey.net/index.php/feed/rss')
# pintamos los envios
print envios1.dameTitulo()
print envios1.dameAutor()
print envios1.dameFecha()
print envios2.dameTitulo()
print envios2.dameAutor()
print envios2.dameFecha()

Unas notas sobre la terminología "pythonera": los métodos se definen con def, las clases se instancian llamando al nombre de la clase, sin new. El constructor (algo parecido, realmente) es el método __init__. Por últimos, los métodos al definirse siempre deben llevar el self por delante. Realmente Python no es un lenguaje orientado a objetos puro, pero ni falta que le hace ;-)

Para finalizar, muy importante: esto no es una lección magistral. Es mi visión personal del patrón "Factory", que puede ser errónea e incompleta. Se admiten (se ruegan) sugerencias y comentarios.

miércoles, 24 de octubre de 2007

Comparativa de “Frameworks” para PHP

Volvemos con la palabreja de moda: framework. Tras el enorme éxito de Ruby On Rails y otros framework como Trails, Django o TurboGears, el mundillo PHP se ha puesto las pilas y han surgido algunos proyectos similares.

¿Por qué utilizar PHP como lenguaje base para un framework en vez de otros lenguajes con una orientación a objetos más definida o clara como Ruby, Python o Java? [1]

La razón principal, en muchos casos, es la amplia extensión de PHP en los servidores. Prácticamente todos los proveedores suministran planes de hosting con PHP y MySQL. Si no se dispone de un servidor dedicado o especializado, no es habitual poder contar con Ruby, Java o Python para hacer desarrollos.

En mi opinión, los frameworks para PHP con más aceptación son el Zend Framework, CakePHP y Symfony. Mi impresión es que Zend Framework es, sobre todo, una colección de clases, paquetes y herramientas, mientras que CakePHP y Symfony son más del estilo RoR.

Entre CakePHP y Symfony se puede decir que el primero es más sencillo y que el segundo ofrece más características. Sinceramente, la mejor forma de evaluarlos es dedicando unas horas a cada uno, pero no siempre tenemos tiempo para esto. Afortunadamente, he encontrado dos comparativas (en inglés) muy ilustrativas:

[1] PHP 5 ha mejorado mucho en lo que a programación orientada a objetos se refiere. Ya tenemos control de acceso en los métodos, gestión de excepciones, ...

jueves, 18 de octubre de 2007

Virtualización en Mac OSX

Existen numerosas soluciones de virtualización para el Mac OSX, algunas propietarias y otras libres (Parallels, VMware Fusion, Bochs, Qemu, ...)

Actualmente estoy utilizando Qemu. Según la documentación, puede emular a un procesador x86 con una frecuencia de 500 MHz. Más que suficiente para hacer pruebas sin tener que reinicar el equipo con otro OS.

Existe un "front-end" para Mac OSX y Qemu llamado Q. Tiene algunas características muy agradables, como una interfaz bastante amigable, la posibilidad de descargarse imágenes de máquinas virtuales preinstaladas, redimensionamiento de la pantalla automático, un cambio de host a anfitrión rápido, ...

En la siguiente captura se ve un Ubuntu corriendo en modo texto, iniciamos la sesión gráfica (startx), pasamos a pantalla completa y luego cambiamos de anfitrión a host varias veces. El efecto de cubo rotando está bastante conseguido.
[youtube p1b4SMkb-zM nolink]

miércoles, 17 de octubre de 2007

Microsiervos …

Me gusta(ba) mucho leer Microsiervos, pero, cada vez más, me recuerdan a los publireportajes que aparecen a veces en los periódicos simulando ser una noticia ...

viernes, 12 de octubre de 2007

La pesadilla de los “encoding” (2ª parte)

Decíamos en la anterior entrada que cuando un fichero puede codificarse con UTF-8. Existen dos variantes del formato UTF-8: con BOM y sin BOM. BOM son dos bytes (FE FF) al principio de un fichero que, simplificando mucho, indican el orden de los bytes.
Guárdese un fichero codificado en UTF-8 con el BOM y tendrá problemas con la mayoría de sus scripts en PHP o ficheros XML, ya que el fichero realmente no comenzará como "<?php" o "<?xml".

Imaginen ahora el siguiente entorno de trabajo: un servidor web más o menos moderno que sirve los documentos por defecto con la codificación UTF-8, un desarrollador con una estación de trabajo Windows o Linux y un diseñador con la estación de trabajo Mac. Si el desarrollador y el diseñador no vigilan el "encoding" con el que guardan sus ficheros habrá problemas con seguridad. Muchas herramientas de desarrollo y/o diseño Web guardan por defecto los ficheros codificados con ISO-8859-1, otras lo guardan en UTF-8 con BOM.

Por supuesto, existen soluciones, a nivel servidor (ficheros .htaccess con la directiva AddDefaultCharset) y a nivel estación de trabajo utilizando herramientas competentes que puedan lidiar con las diferentes codificaciones.

Esta es la típica página que se ve mal porque el servidor sirve en ISO-8859-1 y el fichero está codificado como UTF-8:
Captura de un navegador mostrando caracteres UTF-8 como Latin-1

Se puede ver cómo los caracteres acentuados (ocupan 2 bytes en Unicode) son interpretados como 2 caracteres sencillos.

En el blog de Juque hay más ejemplos y se amplía más la información.

La conclusión final que obtengo es la siguiente: si no se puede garantizar una uniformidad en las plataformas de trabajo (que todo el mundo trabaje con el mismo "encoding"), lo más seguro es utilizar las entidades HTML de toda la vida (á en vez de á, ñ en vez de ñ, ...)

miércoles, 3 de octubre de 2007

La pesadilla de los “encoding”

Estamos en el año 2007. Internet forma parte de las vidas de muchas personas. Pues, por increíble que parezca, algun@s todavía tenemos que lidiar con problemas cuyo origen se remonta a varias décadas atrás.

Antecedentes: en los años 60 se aprobó un código estándard para la codificación de caracteres alfanuméricos. Era una buena idea, puesto que hasta el momento, cada fabricante usaba más o menos el código que le daba la gana. Con este código, ASCII, se consiguió una cierta estandarización.

La idea era utilizar 7 bits (lo que nos da 2^7 = 128 códigos diferentes) para representar los caracteres y símbolos del lenguaje escrito. Por ejemplo, el 65 (0100 0001 en binario) representaba la letra A (en mayúscula), el 32 (0010 0000 en binario) representaba el espacio en blanco, etc.

Magnífica ocurrencia, si tu idioma es inglés. En seguida l@s europe@s nos dimos cuenta de que este sistema no era muy válido: muchos caracteres no tenían representación: eñes, cedillas (ç), vocales con diversos acentos (á, à, â, ä, ...)

La solución que se encontró fue rápida: ya que un byte tiene 8 bits y el ASCII sólo utiliza 7 (el octavo bit se destinó para control de errores), se decidió utilizar ese octavo bit para ampliar el rango de caracteres disponibles (2^8 = 256). Surgía la codificación ISO-8859.

También parecía una buena idea, pero no resultó ser tan idónea: algunos idiomas necesitaban una ñ, por ejemplo, pero otros necesitaban una ç. Algunos idiomas europeos sólo necesitaban un tipo de acentos, pero otros utilizaban más. El resultado de estas necesidades diferentes fue que no se llegó a una única codificación utilizando 8 bits. La codificación ISO-8859-1 (también llamada Latin-1) sirve para casi todos los idiomas de Europa Occidental, la ISO-8859-15 es una revisión de ésta que incluye el símbolo del euro (€). La codificación ISO-8859-16 (Latin-2) se adapta a idiomas de Europa Oriental.

Por otra parte, otros fabricantes decidieron hacer lo que les pareció con el 8º bit no utilizado. Añadieron nuevos símbolos o caracteres extraños al ASCII estándar. Surgen así diversos "codepages" parcialmente compatibles entre ellos (CP437, Windows-1252, ...) y con ISO-8859

Estas codificaciones extendidas supusieron una mejora, pero no fueron el remedio definitivo. Además de mantenerse ciertas incompatibilidades, no servían para codificar algunos idiomas no alfabéticos (idiomas fonéticos o ideográficos).

La siguiente idea fue Unicode: utilizar 2 byte completos (o más) para representar los caracteres o símbolos. Con 2 bytes (2^16) ya tenemos 65.536 posibilidades o símbolos diferentes. Unicode consigue representar y asignar un código único a prácticamente cualquier símbolo escrito en cualquier idioma humano. Además, mantiene la compatibilidad con ASCII y Latin-1: los 128 primeros caracteres de Unicode se corresponden con la codificación ASCII, y los 128 siguientes (hasta 256) se corresponden con Latin-1.

El problema de Unicode es la transmisión de los datos: es absurdo reservar siempre dos bytes para un carácter cuando la mayor parte de los caracteres Unicode que se pueden transmitir en un momento dado "caben" en un byte. Las diferentes formas de transmitir e interpretar los caracteres Unicode son los famosos UTF, siendo los más utilizados UTF-8 y UTF-16.

Seguiremos con el tema.