Sebastián Barría

Esta es otra historia de monos bastante interesante, que también da bastante que pensar…

Un grupo de monos estaba molestando constantemente a unos aldeanos en África. Bajaban de los árboles, robaban su comida y luego se escapaban.

Ante la impotencia, a uno de los aldeanos se le ocurrió la genial idea de poner al medio de la aldea una jarra de greda de cuello muy delgado, donde sólo cabía la mano del mono. Dentro de la jarra echó unos cuantos manís (asegurándose de que los monos lo vieran) y se sentó a esperar.

Al poco rato comenzaron a bajar los monos con la intención de robarse el maní. El primer mono se acercó y metió la mano. Tomó el maní y al intentar sacar la mano empuñada se quedó atrapado. Ambicioso, el mono no podía soltar el maní e intentaba escapar infructuosamente. El aldeano atrapó al mono, y sucesivamente fue atrapando a los demás monos que quedaban atrapados.

Primero que nada, quiero aclarar que por bases de datos “grandes” me refiero a aquellas que tienen más de 100.000 filas.

Una base de datos muy grande puede generar bastantes problemas, como por ejemplo que un sitio se demore una eternidad en cargar o incluso que deje de responder. Pero el problema no es la base de datos ni el motor. Dicen que cuando hay que trabajar con grandes cantidades de datos debe dejar de usarse MySQL y usar SQL, pero finalmente una base de datos MySQL puede funcionar tan bien como una SQL si está bien configurada.

En base a mi experiencia, realmente lo complicado de las bases de datos grandes no son la cantidad de filas que tengan, sino la cantidad de datos que deben cruzarse.

Voy a poner un ejemplo práctico. Yo tengo una base de datos que tiene 3 tablas:

ciudades: 2.650.000 filas
regiones: 3850 filas
paises: 250 filas

Una de las formas más eficientes de mejorar las consultas son los “índices”, para lo cual se debe definir (idealmente) un largo y que columna se indexará. Lo que hacen los índices es generar una especie de “libro” donde tomará los X primeros caracteres de cada palabra de la columna definida y los agrupará (indexará). De esta forma, cuando yo busque algo, el sistema buscará en su índice primero y verá cuales son los que cumplen con esas caracteríscticas y luego irá a consultar esos datos (de esa manera no busca en toda la base de datos, sino en los que dice el índice).

Otra manera es utilizando LIMIT. Si estamos consultando algo que sabemos que retornará 1 sólo dato (por ejemplo cuando buscamos algo por ID), al ponerle LIMIT 1 se reducen considerablemente los tiempos. Esto es lógico pues al consultar dentro de 2.650.000 filas, si el sistema encuentra el dato en la fila n°4 (por ejemplo), al no tener un “LIMIT”, continuará consultando hasta el final de la base de datos. Por el contrario, si tiene el LIMIT, dejará de consultar apenas obtenga la cantidad de resultados especificada.

Otra cosa a considerar es que a utilizar LIKE (‘%xxx%’), el largo del string xxx influye mucho en los tiempos de respuesta. Por ejemplo, si busco (en la base de datos de las ciudades) alguna que contenga “%s%”, la consulta tarda 0,0022 seg. Si busco alguna que contenga “%santiago de %”, la consulta tarda 3,877.

Y finalmente el GRAN problema es cuando se cruzan datos. La tabla paises tiene 3 datos: ID, nombre, region. La región es un ID que va asociado al ID de la tabla regiones (de ahí sacaré los nombres de cada región). Y la región pertenece a un país, cuyo nombre está en la tabla de paises (ID, nombre pais).

Si quiero pedir el nombre de la ciudad, el nombre de la región y el nombre del país de todas las ciudades que comiencen con “santiag%”, tendría una consulta como la siguiente:

SELECT ciudad.nombre, region.nombre, pais.nombre FROM ciudades, regiones, paises WHERE ciudad.nombre LIKE ("santiag%") AND ciudad.region=region.id AND region.pais=pais.id

Esta consulta, al tener que cruzar datos entre tablas demorará mucho tiempo, ya que obligaremos al motor de base de datos a tener en memoria los nombres de todas las ciudades, regiones y países y hacerlos coincidir. Mientras más WHERE apliquemos, más lenta se tornará la consulta.

¿Qué hacemos en casos como este, en que la consulta demore por ejemplo 35 segundos?… claramente no podemos dejar esperando a nuestros clientes todo ese rato. Para casos como estos, la solución es tan simple como hacer 3 consultas a la base de datos:

1. Primero, se consulta el listado de paises y se guarda en un array asociativo, donde el Key sea el ID del pais y el valor sea el Nombre del pais.
2. Luego se hace lo mismo con las regiones
3. Finalmente se hace la consulta SOLAMENTE de las ciudades que partan con “santiag%”. Sin cruce de datos ni nada.

Entonces, cuando queramos mostrar los datos del pais y la región haremos algo como: <? echo $regiones[ID_CIUDAD]; ?>, <? echo $paises[ID_CIUDAD]; ?>, lo cual mostraría en pantalla algo como “Región Metropoitana, Chile”.

Esta manera, en algunos casos es mucho más eficiente que esperar 35 segundos por consulta, ya que como son 3 consultas simples, demorarían menos de 0,5 seg. cada una.

Estas son algunas formas de optimizar las consultas a la base de datos. Aunque se diga lo contrario por ahí, SI es posible manejar millones de datos en MySQL sin tener problemas de tiempos de respuesta. Sólo basta con configurar y optimizar las consultas.

El siguiente es una función desarrollada en PHP para convertir colores hexadecimales (colores Web) en su color equivalente en escala de grises.

Ojo que esto NO ES para convertir imágenes a grayscale, sino que para convertir los colores (tipo #ffcc00) a su equivalente en escala de grises.

function grayscale($color,$antecesor="#"){
    $coloresWeb=array("0","1","2","3","4","5","6","7","8","9","a","b","c","d","e","f");

    $color=strtolower(str_replace("#","",$color));
    if(strlen($color)==3){ $color=$color[0].$color[0].$color[1].$color[1].$color[2].$color[2]; }

    $posiciones=array(
        array_search($color[0],$coloresWeb,true),
        array_search($color[1],$coloresWeb,true),
        array_search($color[2],$coloresWeb,true),
        array_search($color[3],$coloresWeb,true),
        array_search($color[4],$coloresWeb,true),
        array_search($color[5],$coloresWeb,true)
    );

    $total=0;
    foreach($posiciones as $posicion){
        $total+=$posicion;
    }

    $promedio=0;
    if($total){
        $promedio=$coloresWeb[round($total/6)];
    }

    return $antecesor.$promedio.$promedio.$promedio.$promedio.$promedio.$promedio;
}

Como siempre, todos los comentarios son bienvenidos…

Este es un artículo que redacté para la revista Carrusel
El siguiente es el texto que fue publicado en la revista

Imagino que a muchos de ustedes les sucederá que al desarrollar un sitio hay que poner las palabras claves, idealmente, diferentes en cada página, lo cual es un trabajo de lo más aburrido (y que probablemente al final no hacen)… yo tampoco, por supuesto.

PEOR AÚN!!!… están desarrollando un sitio que lo va a administrar uno de sus clientes, que poco y nada sabe de Internet… osea que las posibilidades de que el sitio vaya a tener keywords son infinitamente nulas!!!

Pues bien… para quienes trabajan “como hombres”, machos y vikingos de la Web (es decir, sin sistemas como WordPress, Joomla o cualquier otro que use plugins para salvarle la vida al programador), les dejo este código PHP  (script, snippet o como quieran llamarlo) hecho por mi para auto-generar una cierta cantidad de palabras claves (keywords) basado en algún texto que se le envíe (idealmente el cuerpo de la página en cuestión). Es IDEAL para generar meta keywords, por ejemplo.

Odio los comentarios en los códigos PHP (al menos nunca he visto uno realmente útil), asique no los voy a poner… sólo les dejaré el código “pelado”, a lo mero macho.

function keywords($texto,$cantidad=20){
$keywords=array();
$palabrasNoConsideradas="que,qué,cuán,cuan,los,las,una,unos,unas,donde,dónde,como,cómo,cuando,porque,por,para,según,sin,con,mas,más,pero,del";
$palabrasNoConsideradas=explode(",",$palabrasNoConsideradas);

$texto=strip_tags(html_entity_decode($texto,ENT_NOQUOTES,"UTF-8"));
$texto=preg_replace(array('/\s+/'),' ',$texto);
$texto=preg_replace(array('/\r/', '/\n/','/[¿!¡;,:\.\?#@()"]/'),'',$texto);
$texto=explode(" ",$texto);
$palabras=array();
foreach($texto as $palabra){
if(ctype_upper($palabra) and count($keywords)<$cantidad and !in_array($palabra,$keywords)){ array_push($keywords,$palabra); } //las palabras en mayúscula son keywords automáticamente
else{
if(strlen($palabra)>2 and !in_array($palabra,$palabrasNoConsideradas)){
if($palabras[$palabra]){ $palabras[$palabra]++; }
else{ $palabras[$palabra]=1; }
}
}
}
arsort($palabras);
$palabras=array_keys(array_slice($palabras,0,$cantidad-count($keywords)));
$keywords=array_merge($palabras,$keywords);

return implode(",",$keywords);
}

Voilá!… cualquier mejora o comentario, por favor háganmelo llegar. Gracias!

PD: se habrán dado cuenta que insinué que los que usan WordPress no son “machos vikingos” y casualmente este sitio está hecho con WordPress… bueno, es sólo una coincidencia… jajaja.

Les contaré una historia que me encanta, pues da bastante para pensar sobre el comportamiento de la raza humana.

En un experimento se metieron cinco monos en una habitación. En el centro de la misma ubicaron una escalera, y en lo alto, unos plátanos. Cuando uno de los monos subía por la escalera para acceder a los plátanos, los cinetíficos rociaban al resto de los monos con un chorro de agua fría. Al cabo de un tiempo, los monos asimilaron la conexión entre el uso de la escalera y el chorro de agua fría, de modo que cuando uno de ellos se aventuraba a subir en busca de un plátano, el resto de monos se lo impedía con violencia. Al final, e incluso ante la tentación del alimento, ningún mono se atrevía a subir por la escalera.

En ese momento, los científicos sacaron a uno de los cinco monos iniciales e introdujeron uno nuevo en la habitación.

El mono nuevo, naturalmente, trepó por la escalera en busca de los plátanos. En cuanto los demás observaron sus intenciones, se abalanzaron sobre él y lo bajaron a golpes antes de que el chorro de agua fría hiciera su aparición. Después de repetirse la experiencia varias veces, al final el nuevo mono comprendió que era mejor para su integridad renunciar a ascender por la escalera.

Los científicos sustituyeron otra vez a uno de los monos del grupo inicial. Posteriormente se repitió el proceso con el tercer, cuarto y quinto mono, hasta que llegó un momento en que todos los monos del experimento inicial habían sido sustituidos.

En ese momento, los científicos se encontraron con algo sorprendente. Ninguno de los monos que había en la habitación había recibido nunca el chorro de agua fría, sin embargo, ninguno se atrevía a trepar para tomar un plátano.

Si hubieran podido preguntar a los primates por qué no subían para alcanzar el alimento, probablemente la respuesta hubiera sido “No lo sé. Esto siempre ha sido así”.

Este post es en parte para realizar una comparativa entre Mootools y jQuery. Ambas son librerías de javascript que permiten hacer cosas como animar objetos, seleccionar elementos, etc. en cada página donde se ejecuten, es decir que en la práctica lo que hacen es entregarnos funciones pre-hechas para realizar las tareas de javascript y así permitir, entre otras cosas, simplicarnos la vida y compatibilizar los navegadores. Ambas sirven para lo mismo y de hecho funcionan de manera bastante similar.

Muchas personas no conocen Mootools y, como generalmente ven más sitios o ejemplos hechos en jQuery creen que “es mejor”, pero a mi juicio Mootools es mucho mejor que jQuery. De hecho, NUNCA he visto algo que se pueda hacer en jQuery y que no se pueda hacer en Mootools (por favor si alguien sabe de algo que lo publique acá), y en teoría no tendría porqué jQuery ser mejor que Mootools en ese sentido si ambos están basados únicamente en lo que permite hacer javascript.

El gran plus de jQuery: su documentación

Me he encontrado que cuando quiero buscar algo relacionado a jQuery me es bastante fácil encontrar una solución o ejemplos, a diferencia de Mootools, que su documentación es bastante pobre (sólo lo justo y necesario). Además de eso, mootools tiene unos ejemplos online muy antiguos (de la versión 1.1) y para las últimas versiones ofrecen descargar los ejemplos o revisar su funcionalidad en una interfaz llamada jsFiddle, en la cual también se encuentran ejemplos de las demás librerías como YUI o prototype.

Por su parte jQuery ofrece cosas mucho más simples como jQueryUI o su listado de plugins, los cuales ofrecen ejemplos bastante claros, concretos y simples. Quizás por eso es tan popular jQuery, porque es mucho más fácil encontrar una librería que se ajuste a las necesidades de algún proyecto, la cual puedes implementar incluso con poco conocimiento. De todas formas Mootools no se queda atrás y ofrece Mootools Forge (que en la práctica es un repositorio de plugins) y existen sitios como JOURMOLY que tiene muchos ejemplos realmente útilies y que le “salvan el pellejo”.

El gran plus de Mootools: su funcionalidad

Vamos directo con un ejemplo: cuando tengo un link y quiero que al hacer click haga submit a un formulario simplemente pongo lo siguiente en mootools:

$('id_del_formulario').submit();

En jQuery esto no funciona. Es algo complejo de explicarselo a humanos (yo no soy programador de profesión asique tampoco me gusta explicar las cosas como programador), pero en resumidas cuentas, mootools permite seleccionar un objeto con $ y eso al final es lo mismo que decir document.getElementById. En jQuery, al usar el $ el objeto se convierte en un objeto de jQuery y si quiero hacer un submit tengo que usar una función interna que trae jQuery para dichos efectos. Al ser un objeto de jQuery aparentemente no puede interactuar con todas las funciones básicas de javascript, y eso a la larga es confuso.

NOTA: puede ser que en las últimas versiones de jQuery esto ya no suceda. Me tocó hace tiempo hacer algo como esto y últimamente no me ha tocado desarrollar en jQuery, asique si estoy mal avísenme.

Lo importante es que Mootools es más flexible en ese sentido. Es bastante fácil de implementar y tiene métodos muy simples. Como es obvio, también, hay cosas que son más simples en jQuery, asique creo que en ese sentido es mejor que cada uno decida.

Mi opinión personal

Por mi parte recomiendo Mootools. Personalmente no me gusta jQuery (es como escoger entre WordPress o Joomla, entre los cuales prefiero WordPress), y encuentro que es un poco más engorroso de entender y programar.

Personalmente uso un archivo que pesa 213k pero que contiene TODO Mootools (ya que hay un Mootools “básico” y un “core” que tiene más funcionalidades) y con eso puedo hacer todo lo que quiera en cualquier sitio. Como los .js se cargan una sola vez y luego se toman del caché el impacto que esto produce es imperceptible y además de esa manera no se llama a n archivos (como sucede en jQuery, donde se carga la base y luego se van cargando librerías para efectos, desplegables, carruseles, etc.), sino que se carga sólo 1, lo cual optimiza bastante la carga de la página.

Con esto inicio el debate por si alguien se quiere sumar…

Muchas veces planificamos y creamos bases de datos en las cuales tendremos que almacenar varios datos, pero en la práctica no sabemos la cantidad real de caracteres que tendrá cada uno. En ese caso generalmente ponemos un valor cualquiera con el que nos aseguremos que va a caber la información.

Por ejemplo, si hacemos una aplicacación que se conecte con twitter, vamos a recibir ciertos datos que vienen en una enorme cadena de texto, pero la pregunta es: ¿cuántos caracteres recibiremos?… si no sabemos le pondremos algo así como 255, y probablemente estemos ocupando espacio adicional en el base de datos.

Bueno… a mi me pasó eso… y voy a compartir la información que investigué y que deduje para que se les haga más fácil la tarea XD.

ID = 10 caracteres (hablando de ID’s numéricos con auto-increment y “unsigned”)
Email =256 caracteres (64 antes de la @, y un máximo de 256)
Passwords = 32 caracteres si se almacenan en formato MD5 (recomendado)
Nombres = 100 (generalmente con eso alcanza… sino se puede ocupar un varchar de 255 o un tinytext)
ID de Facebook =64 caracteres (pues cambiaron hace poco el largo de la cadena en vista de que tienen muchos registrados)
Twitter Oauth Token = 50 caracteres
Twitter Oauth Token Secret = 50 caracteres
Twitter Username = 15 caracteres
RUT (chileno) = 12 caracteres (si se almacena con puntos y guión) o 9 caracteres (si se almacena sin puntos ni guión, que es lo más óptimo)
URL = Se supone que no hay un largo máximo definido, sin embargo leí por ahí que IE6 acepta un máximo de 2047 caracteres si la escribo en el navegador… raro, pero en verdad no sabría que largo (maxlength) recomendar. De todas formas yo generalmente pongo 255 ó 500 caracteres… DUDO que alguien tenga un sitio web con más qu eso (los 2047 caracteres probablemente se apliquen a un post en un blog, pero no a la URL de un sitio personal).

BuenoHay muchos otros tipos de datos, y por supuesto que pueden preguntar en los comentarios o aportar si tienen otros datos.

Una vez, para hacer un Wallpaper para http://www.larojamundial.com tuve que vectorizar el logo de la Selección Chilena de fútbol, ya que no lo pude encontrar googleando.

Acá se los dejo por si a alguien le sirve.

[DESCARGAR EN FORMATO FH11]
[DESCARGAR EN FORMATO PNG]

Era viernes en la mañana cuando me llama @rdeguerra y me dice “perro! Tengo una idea”. Me la explicó y me gustó, asique me puse manos a la obra aunque en ese minuto lo que menos tenía era tiempo.
El sitio permite escribir un mensaje en español y traducirlo al japonés (usando la API de Google translate) para después enviarlo vía twitter mencionando la cuenta de @earthquake_jp y el hashtag #msgJapon.
El sitio dio excelentes resultados y fue mencionado en muchos lugares.
Una excelente idea ejecutada en tiempo récord.

Visítenlo en

http://www.tumensajeajapon.com