Uno de los problemas que tienen los UUID es que pueden resultar demasiado largos para algunas aplicaciones. Aquí veremos un método para reducir los clásicos UUID de 36 caracteres a 25.

Supongamos que a cada usuario registrado en nuestro sistema le asignamos un UUID, el cual tenemos que incluir en la url para visualizar su perfil. Esta URL quedaría algo más o menos así:
http://example.com/users/profile/4a3009bd-43f4-4535-ae3e-08a0650df841

Si observamos la composición de un UUID vemos que todos sus caracteres son números hexadecimales (excepto los guiones). Hay muchos caracteres que no están siendo utilizados en esta cadena y si convertimos los números hexadecimales a una base mayor que utilice más caracteres, podríamos reducir la cadena.

PHP tiene una función llamada base_convert que toma tres argumentos: el número a convertir, la base en la que se encuentra dicho número y la base a la cual lo queremos convertir. Si a esta función le pasamos nuestro UUID generado por CakePHP para convertirlo a base 36 (la máxima base que soporta dicha función) y lo pasamos a mayúsculas (sólo para que sea más prolijo), nos queda una cadena de 25 caracteres similar a esta: 4FPTDWER5VQ4G4S408C8O8WO0. La cadena generada sigue siendo única porque el número que representa es el mismo que el UUID original, sólo que está convertido a otra base mayor.

Ahora, para hacer un poco más sencillo el proceso, sería ideal que CakePHP genere automáticamente estos UUID cortos, del mismo modo que los hace con los largos. Si el campo id de una tabla es una cadena de 36 caracteres CHAR(36) o VARCHAR(36), CakePHP genera automáticamente un UUID por cada insert que se hace en la tabla. Con este behavior logramos el mismo comportamiento pero para aquellos campos id que sean cadenas de 25 caracteres. Veamos el código.

<?php

Class ShortUuidBehavior extends ModelBehavior {

	function setup(&$Model, $settings) {
	}

	function beforeSave(&$Model) {
		if(
			empty($Model->data[$Model->alias]['id'])
			and $Model->_schema['id']['length'] == 25
			and $Model->_schema['id']['key'] == 'primary'
			and $Model->_schema['id']['type'] == 'string'
		) {
			$Model->data[$Model->alias]['id'] = $this->_generateShortUUID();
		}
	}

	function _generateShortUUID() {
		$uuid = str_replace('-', '', String::uuid());
		return strtoupper(base_convert($uuid, 16, 36));
	}

}

?>

Este behavior se puede ubicar dentro de app_model.php, ya que sólo afectará a aquellos modelos cuyo id sea una cadena de 25 caracteres.

]]> http://www.plusglobal.com/blog/short-uuid-behavior-para-cakephp/feed/ http://www.plusglobal.com/blog/ejemplos-donde-necesitamos-usar-uuid/ http://www.plusglobal.com/blog/ejemplos-donde-necesitamos-usar-uuid/#comments Fri, 11 Dec 2009 12:05:45 +0000 Mauro http://www.plusglobal.com/?p=905

Hace unos días vimos qué son y cómo se crean los UUID. Ahora vamos a ver algunos ejemplos donde se hace necesario su uso.

Cantidad de registros potencialmente infinita

MySQL puede guardar números enteros positivos hasta un máximo de 18446744073709551615 (referencia). Si bien es un número realmente grande, es posible que para algunos sistemas no sea suficiente, ya que la cantidad de registros esperados puede ser superior. Los UUID en cambio son virtualmente infinitos.

Bases de datos distribuidas

Si una base de datos recibe muchas consultas y el rendimiento del servidor comienza a verse afectado, puede ser una buena solución separar la base de datos en diferentes servidores para reducir la carga. Si una misma tabla está replicada en diferentes servidores las claves autoincrementales ya no pueden ser utilizadas ya que tendríamos identificadores repetidos para diferentes registros.

Coordinación con servicios externos

Tenemos una tabla en la cual almacenamos información sobre vídeos y otra con archivos de audio. En nuestra base de datos sólo guardamos la información relativa a los contenidos (duración, nombre, calidad, etc.). El archivo de audio o vídeo se guarda en un servidor externo por requerimiento del cliente. Este servidor tiene como política que cada archivo que se aloje debe tener un identificador único. Sería muy cómodo para nosotros que el mismo id que usamos para los registros propios en nuestras tablas sea el que usamos para el servidor de archivos, pero nuestra información está en diferentes tablas, así que no podemos usar un id autoincremental ya que tendríamos claves duplicadas de una tabla a la otra.

Esconder información

Un sitio web similar a flickr tiene una base de datos de imágenes que el usuario puede navegar libremente. Cada imagen tiene una página propia y el id de dicha imagen se pasa a través de la url. Un usuario astuto podría notar que estos números son consecutivos y le resultaría relativamente fácil programar un script que descargue todas las imágenes de nuestro sitio, lo cual va en contra de nuestro objetivo ya que queremos que los usuarios naveguen el sitio para descargarlas.

Un cliente que se preocupa mucho por la imagen de su empresa está recibiendo muy pocos pedidos a través de su sitio de comercio electrónico. Cada pedido recibe un identificador numérico autoincremental. El empresario nos plantea que sus clientes se dan cuenta de que vende poco porque pasan las semanas y los números de pedidos avanzan muy lento, dando la imagen de que su empresa no está funcionando. Esto puede parecer irreal, pero nos ha sucedido una vez.

Los formatos de imágenes más populares para el desarrollo web son JPG, GIF y PNG. A continuación veremos las características básicas de cada uno de estos formatos de mapas de bits y en qué situaciones conviene utilizar cada uno.

JPG

Es el formato más utilizado y conocido, lo implementa la mayoría de las cámaras digitales y sitios web.

La principal ventaja del JPG es que permite establecer un porcentaje que determina el peso y la calidad de la imagen.

El método de compresión del JPG se basa en tomar áreas contiguas de una imagen y almacenarlas en conjunto. Esto hace que la diferencia de calidad sea prácticamente imperceptible en fotos con enorme cantidad de colores, pero a la vez genera problemas de visualización si la imagen tiene textos, líneas muy definidas o fondos plenos.

La siguiente imagen está al 50%. Notamos claramente que la foto de la izquierda se ve con calidad aceptable, mientras los fondos plenos de las otras dos imágenes sufren ciertas distorsiones, especialmente en los límites con otros colores.

Ejemplo de JPG. Tamaño del archivo: 30 KB

Más sobre JPG: http://es.wikipedia.org/wiki/Joint_Photographic_Experts_Group

GIF

Los archivos GIF permiten un máximo de 256 colores, así que resulta claro que no son lo ideal para fotos o imágenes muy coloridas. La idea básica detrás del algoritmo de compresión del GIF es almacenar los códigos de color y las posiciones que ocupan dentro de la imagen.

Como ventaja podemos decir que se puede determinar la cantidad de colores máxima de un archivo GIF, logrando de esa manera controlar el peso. También es destacable el hecho de que permite transparencias y animaciones sencillas.

Por sus características este formato es bueno para fondos de color pleno y textos bien definidos.

Aquí están las mismas imágenes de antes guardadas en un archivo GIF de 32 colores. Vemos que en todos los lugares donde hay muchos colores o gradientes la calidad es pobre.

Ejemplo de GIF. Tamaño del archivo: 23 KB

Más sobre GIF: http://es.wikipedia.org/wiki/Graphics_Interchange_Format

PNG

Debido a que el GIF fue hasta hace poco un formato patentado y toda empresa que lo utilizaba debía pagar, se decidió desarrollar un formato que fuera libre y así nació el PNG. El éxito fue rotundo ya que no sólo lograron un formato gratuito sino que mejoraron con creces todas las limitaciones y problemas del GIF, como por ejemplo el soporte para transparencias (que en GIF es bastante limitado) o la abolición del límite en la cantidad de colores.

PNG evolucionó al punto de que permite guardar imágenes con excelente calidad en un mismo archivo donde se encuentran colores plenos y líneas definidas junto con fotos de enorme cantidad de colores.

Sin embargo, el peso de los archivos no es el ideal cuando se trata de imágenes con mucha cantidad de colores, como podemos ver en los ejemplos presentados.

Ejemplo de PNG. Tamaño del archivo: 116 KB

Más sobre PNG: http://es.wikipedia.org/wiki/Portable_Network_Graphics

Conclusiones

PNG sirve para cualquier tipo de imágenes, pero conviene utilizarlo sólo cuando haya fondos plenos y líneas muy definidas, de lo contrario el peso del archivo se elevará demasiado.

GIF sólo se debería utilizar en el caso en que necesitemos animaciones simples, ya que en todos los demás aspectos es ampliamente superado por el PNG.

JPG debe usarse en las imágenes que tienen muchos colores y gradientes, como fotografías reales o ilustraciones muy elaboradas.

Volvemos a mostrar las 3 imágenes juntas así las puedes comparar y notar las diferencias.

JPG

GIF

PNG

Foto por c-reel

En el diseño de sitios de Internet los formatos de imágenes más utilizados siempre fueron mapas de bits. Sin embargo, los primeros que se crearon (el más famoso de ellos es el BMP de Windows) tienen serias desventajas, siendo la principal de ellas el peso de los archivos que hace que sean muy poco prácticas para transferencias vía web.

Un mapa de bits representa cada píxel con un número, y cada número ocupa cierta cantidad de memoria. No pasó mucho tiempo hasta que alguien notó que es altamente probable que en una misma imagen muchos colores se repitan. Por ejemplo, en la foto que ilustra este post, un formato sin compresión guarda el número del color negro tantas veces como píxeles en negro hay en la imagen.

Entonces la idea fue comprimir la imagen: en vez de guardar millones de veces el mismo número representando el mismo color, se guarda el código de color una sola vez junto con información adicional de cómo distribuir o utilizar ese color a lo largo de toda la imagen. De esta manera, el peso de los archivos disminuye enormemente y se pueden transferir por Internet con facilidad.

Pérdida de información

Con el tiempo aparecieron nuevas formas de comprimir las imágenes. Una de las ideas surgidas fue eliminar información que no fuera percibida por el ojo humano y de esa manera hacer más liviano el archivo. Así nacen los algoritmos de compresión con pérdida, ya que la imagen en el nuevo formato tiene menos detalle que la imagen original. Sin embargo, el beneficio que aporta tener un peso del archivo muy inferior, es mucho mayor que el perjuicio de la información que se pierde.

Evolución

Cada vez son más complejos los algoritmos de compresión de imágenes llegando al desarrollo de programas prácticamente imposible de entender para cualquier mortal. Estas técnicas se aplicaron en el video digital, logrando reducir considerablemente el peso de los archivos también en estos formatos.

Igualmente, la idea básica es la misma, reducir el peso de los archivos mediante aplicación de fórmulas matemáticas complejas.

Las metodologías ágiles se están imponiendo con fuerza en la industria del software, y más aún en el desarrollo web. Este libro intenta explicar las bases teóricas de esta nueva forma de trabajo.

La primera mitad de la obra se desperdicia en recopilar y listar enorme cantidad de metodologías, casi todas poco conocidas y tradicionales (es decir, no ágiles), con la idea de que así se comprenderán mejor los métodos ágiles planteados posteriormente.

En la segunda mitad encontramos dos capítulos dedicados exclusivamente al propósito del libro, uno habla sobre Extreme programming y el otro sobre Scrum. Ambos están bastante detallados en sus explicaciones, pero carecen de ejemplos concretos que ayuden al lector a comprender el tema. Sólo cuando se habla de Scrum hay un intento de ejemplo práctico, pero poco satisfactorio.

No voy a negar que después de haberlo leído completo, uno se acerca un poco más a la comprensión cabal de qué son las metodologías ágiles, pero realmente no encuentro que el libro brinde herramientas para comenzar a aplicar inmediatamente.

Un aspecto positivo, es la cantidad de enlaces a websites y blogs relacionados. La sección de bibliografía consultada también es un buen punto de partida para comenzar a estudiar el tema con mayor profundidad.

Ficha técnica

Título: Métodos ágiles
Autor: Sebastián Priolo
Editorial: Users
Publicado: 2009
Idioma: Español
Páginas: 336
ISBN: 978-987-1347-97-1

Es una práctica muy extendida en el diseño de base de datos crear un campo llamado id y determinarlo como clave primaria de la tabla. Generalmente dicho campo es un número entero y autoincremental, es decir, el motor de la base de datos se encarga de incrementar dicho número a medida que se van agregando registros.

Sin embargo, hay algunos casos en los que no es posible utilizar números enteros decimales autoincrementales como clave primaria. Para esos casos existe una solución efectiva y práctica: el identificador único universal.

Un UUID (Universally Unique Identifier) es una sucesión de 5 números hexadecimales separados por guiones. Estos son algunos ejemplos:

4a3000fc-38e0-4e14-8cd4-08a0650df841
4a2ff7d4-dc50-4223-a7f0-08a0650df841
4a301d63-b540-4e7f-a160-08a0650df841

Los UUID tienen características fundamentales que los hacen realmente útiles:

1. Son universalmente únicos

La forma en que se generan hace que sea imposible que haya dos UUID iguales en cualquier sistema que se haga o se haya hecho. Para crear un UUID se tienen en cuenta datos del servidor o equipo que lo genera, números aleatorios y la hora actual en microsegundos. Por lo tanto, para que haya dos UUID iguales tendría que suceder que sean generados por el mismo hardware, dentro del mismo microsegundo y, además, que los números aleatorios elegidos sean iguales. La probabilidad de colisión no es cero, pero casi.

2. El algoritmo de generación es muy rápido

Generar un UUID prácticamente no tiene costo para el rendimiento del sistema. Otros métodos de generación aleatoria de cadenas deben verificar que dicha cadena no haya sido utilizada ya por el sistema, lo que implica lectura en base de datos, posiblemente más de una vez.

3. Está compuesto por números hexadecimales

Esto hace que sean sencillos de almacenar en formato de cadena o binario y también son fáciles de transmitir por Internet o pasar como parámetro por url. Se puede reducir su tamaño llevándolo a base 36 o base 64.

En los comienzos de la computación los ordenadores sólo podían procesar números y texto. Cada letra de un alfabeto tiene su correspondiente número binario que la representa. Con el tiempo y los avances de la informática se encontraron maneras de utilizar esos números para representar imágenes.

A nivel básico, una de las primeras ideas que surgió fue la creación de una imagen que se dibuje punto por punto, uno a continuación del otro (a cada uno de esos puntos lo llamamos píxel). Como el ojo humano no distingue esa separación entre puntos, a la distancia se ve como una imagen completa. Cada uno de esos puntos representa un color y está guardado entro de la imagen como un número.

La foto que aparece en la cabecera es un ejemplo para comprender un poco mejor la idea. Alí vemos un acercamiento a nivel píxel de un fragmento muy pequeño de la imagen.

Además de los números que representan cada color, tenemos otros factores que influyen en la generación de la imagen. Uno de ellos es la cantidad de píxeles que tendrá de ancho y de alto. Otro se refiere al tamaño del número que representa cada color, cuanto mayor es dicho número, más cantidad de colores se pueden representar, pero más pesa el archivo.

En el desarrollo web casi todas las imágenes que se usan son mapas de bits, pero el procesamiento que tienen es un poco más complejo que una simple sucesión de números. En próximos artículos explicaremos las ideas básicas de los formatos de compresión de imágenes y cómo se utilizan estos números para guardar colores.

37signals es una empresa de desarrollo de aplicaciones web responsable de varios productos que revolucionaron el mercado del Project management y se convirtieron en éxito en ventas. Además son los creadores de Ruby on Rails, un framework de desarrollo rápido de aplicaciones web que también trajo importantes avances y aportes al mundo del web development. En este libro 37signals nos da muchos consejos de utilidad para quienes estén interesados en producir y comercializar aplicaciones web.

Pocas veces he leído un libro tan claro y que va directo al punto. Esta gente no se anda con vueltas y dice sus opiniones sin anestesia, incluso con un tono pedante y agresivo, lo cual aporta un condimento aún más atractivo.

Devoré el libro en sólo un fin de semana y disfruté mucho su lectura. No voy a hacer un comentario detallado de sus contenidos porque sería como arruinar una buena película.

Público objetivo

Getting Real está destinado a desarrolladores que se dedican a la producción y comercialización de aplicaciones web. Si bien muchos consejos sirven para mejorar el desarrollo de aplicaciones para terceros, la idea principal es ayudarte a que lances tu propia aplicación web y la comercialices y promociones tú mismo.

En mi opinión, para poder aplicar los conceptos que el libro expresa, se necesita de grupos de trabajo pequeños, altamente capacitados y con talento. Si uno cuenta con un staff que no está lo suficientemente calificado (ya sea por inexperiencia, ineptitud o falta de voluntad) entonces probablemente sea necesario atenerse a las metodologías tradicionales que mantienen a todos controlados.

Conclusión

Si estás dentro del público objetivo del libro, ve ya mismo a leerlo, tienen una versión online gratuita y puedes comprar el PDF.

Ficha técnica

Título: Getting Real
Autor: 37signals
Publicado: 2006
Idioma: Inglés (también hay una versión en español)
Paginas: 193
ISBN: 978-0-578-01281-0

Otras revisiones

• Yet another Getting Real review (Amit Rathore)
• Book review: Getting Real by 37signals (Mads Kristensen)
• Review: Getting Real by 37Signals (Scott Savage)

¿Cómo funciona Internet? ¿Cómo se hace para poner un sitio web on line? ¿Por qué tengo que contratar a una empresa de hosting si yo ya tengo Internet en mi oficina? Estas son algunas de las preguntas que los tus clientes probablemente hagan. Aquí te proponemos una respuesta básica y una explicación simple que tal vez te puede resultar de ayuda.

A nivel básico, el proceso a través del cual se navega un sitio web, es el siguiente:

• El usuario ingresa en una página escribiendo la dirección en su navegador.
• La petición se envía a Internet, se realizan varias consultas de información hasta que se logra dar con la ubicación exacta del servidor que aloja el sitio.
• El servidor tiene instalado un programa que constantemente está “escuchando” las peticiones que le hacen. Dicho programa se encarga de conseguir o generar el contenido que el usuario solicitó.
• El contenido del website llega a nuestro ordenador y es interpretado por el navegador (Internet Explorer, Firefox, etc.).

Entonces ¿Qué es un servidor?

Un servidor es un ordenador como cualquiera (generalmente más potente) que se encuentra las 24 horas del día conectado a Internet esperando que le soliciten mostrar los sitios web que tiene alojados.

Generalmente resulta muy costoso instalar uno mismo un servidor propio, debido a que necesitamos conexiones excelentes (estables y rápidas), mantenimiento del software y su seguridad, equipos potentes, etc. Por ese motivo se suelen contratar empresas de hosting que se ocupan de mantener un servidor funcionando y por un costo realmente accesible alquilan un espacio en él.

Hosting

La palabra hosting es sólo la traducción al inglés de alojamiento. Se suele usar de manera indistinta en nuestro idioma.

¿Qué diferencia hay entre el servidor y mi proveedor de Internet?

El proveedor de Internet (también conocido como ISP) es la empresa que te brinda acceso a Internet desde tu hogar u oficina. Ellos conectan tu equipo con la red y a partir de ese momento puedes navegar por cualquier website.

El servidor, en cambio, es donde estará alojado tu sitio web, un equipo administrado por una empresa (generalmente no es la misma que el proveedor) y que se encuentra siempre conectado a Internet esperando a que alguien visite tu sitio web.

Un lenguaje es un conjunto de elementos y reglas establecidas para comunicarse. El objetivo de los lenguajes de programación es que los programadores podamos comunicarle al ordenador qué es lo que queremos que haga por nosotros.

Las máquinas comprenden un lenguaje binario (compuesto por ceros y unos) y los humanos tenemos formas de comunicarnos muy ricas y variadas. No es posible para un humano comprender el lenguaje máquina, y tampoco es posible para una máquina comprender a la perfección el lenguaje humano (al menos todavía).

Por este motivo es que se crearon los lenguajes de programación, con el objetivo de acercar las diferencias entre lo que las personas y las computadoras son capaces de comprender (a esto se le llama brecha semántica).

En el mundo del desarrollo web los lenguajes de programación más conocidos son PHP, ASP, JSP, Ruby, Perl, Phyton y SQL (del lado del servidor) y Javascript (del lado del cliente).

Qué no es un lenguaje de programación

Hay algunos lenguajes que no son de programación, pero sí son lenguajes, ya que siguen manteniendo el objetivo de comunicar hombre con máquina. Ejemplos de estos lenguajes son HTML y CSS, que sirven para determinar el contenido y la presentación visual de una página web, pero no sirven para hacer programas.

Para que un lenguaje sea considerado de programación, es necesario que nos permita hacer programas con él; lo que incluye, básicamente, asignación de valores en variables, realización de cálculos, evaluación de condiciones y repetición de sentencias (entre otras cosas).