Cómo obtener los “trend topics” de Twitter usando jQuery

En un artículo anterior expliqué cómo utilizar el API de twitter para obtener los resultados de una búsqueda de una palabra clave (keyword). En esta ocasión he modificado el sencillo script de aquel artículo para realizar una consulta diferente al API de twitter… obtener los 10 “trend topics”.

Decidí realizar esta modificación porque el tema está en boga y he visto inclusive programas o servicios en el Web para realizar esta tarea. Uno de ellos es http://trendsmap.com, el cual incluso muestra los “trend topics” por ubicación geográfica.

Esto último es posible debido a que el API de twitter nos permite obtener “trend topics” por ubicación geográfica. En nuestro caso haremos una búsqueda global y eso es lo que significa el número 1 en el URL del API de twitter que verán en el siguiente script.

En esta ocasión no explicaré el script debido a que es muy similar al anterior. A continuación lo copio.


<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
Listado de los 10 trend topics
<div id="twbox"><ul></ul></div>
<script type='text/javascript'>
  var varSal = "";
  function leerEntradas(jsonptrends) {
		$.each(jsonptrends[0].trends, function(key, val) {
			 varSal += "<li>"+val.name+"</li>";
		});
    $("#twbox ul").html(varSal);
  }
</script>
<script  src="https://api.twitter.com/1/trends/1.json?callback=leerEntradas"></script>

Como siempre he tratado de ser minimalista para propósitos didácticos… al final los dejo con una imagen de ejemplo de la salida. Espero les sirva!

twitter trend topics Cómo obtener los "trend topics" de Twitter usando jQuery Cómo obtener los "trend topics" de Twitter usando jQuery trendtopics2

twitter trend topics

Cambiando las “voces” del motor TTS que viene por omisión en Elastix

Text to Speech Elastix Cambiando las "voces" del motor TTS que viene por omisión en Elastix Cambiando las "voces" del motor TTS que viene por omisión en Elastix tts elastix text to speech

Quienes han usado el motor TTS (text-to-speech) que viene por omisión en Elastix (llamado Festival) habrán notado que las “voces” en español suenan un tanto robotizadas.

Un conjunto de “voces” de mejor calidad se encuentra disponible de manera gratuita gracias al proyecto Guadalinex. Sin embargo, muchos usuarios tienen problemas para instalarlas, así que decidí publicar esta guía muy breve y sencilla.

Lo primero que debemos hacer es instalar los archivos que conforman las voces. Para facilitar este paso, construi unos instaladores RPMs que nos facilitan enormemente el trabajo. Estos instaladores pueden ser descargados de aquí:

http://www.neomano.com/downloads/voces/

El archivo festvox-palpc16k-1.0-2.noarch.rpm instala la voz masculina, llamada Pedro, y el archivo festvox-sflpc16k-1.0-2.noarch.rpm instala la voz femenina, llamada Silvia.

La instalación de estos archivos en nuestro servidor Elastix la podemos realizar con el siguiente comando.

rpm -ivh festvox-palpc16k-1.0-2.noarch.rpm festvox-sflpc16k-1.0-2.noarch.rpm

Luego de esto editamos el archivo /usr/share/festival/languages.scm y modificamos las líneas 93 y 94 de la siguiente forma.

ANTES:

(voice_el_diphone)
(set! male1 voice_el_diphone)

DESPUES:

(voice_JuntaDeAndalucia_es_pa_diphone)
(set! male1 voice_JuntaDeAndalucia_es_pa_diphone)

TEXT2WAVE

Si adicionalmente queremos que el comando text2wave por omisión utilice nuestras voces, tendremos que también modificar el archivo /usr/bin/text2wave y en la línea 46 añadir una que diga:

(voice_JuntaDeAndalucia_es_pa_diphone)

Esto es útil debido a que algunos scripts AGI utilizan el comando text2wave para sintetizar voz.

Sistema de voceo anti-feedback de bajo costo para Elastix

Seguramente muchos usuarios de Elastix han pensado en habilitar un sistema de voceo pero no quieren invertir en esos costosos sistemas basados en IP que pueden llegar a costar cientos o miles de dólares. Lo que algunos no saben es que pueden utilizar la tarjeta de sonido del servidor para este fin.

En las primeras pruebas que hice con mi sistemita noté un problema: una retroalimentación acústica (feedback) bastante molestosa cuando se utiliza un teléfono cercano a los parlantes para vocear. Esto es debido a que el audio que sale de los parlantes se vuelve a introducir por el micrófono del teléfono y esto ocasiona feedback. Más adelante les cuento el truQuito que se me ocurrió para resolver este problema.

En el presente experimento conectaré la salida de la tarjeta de sonido a un pequeño amplificador de audio de aproximadamente 35 Watts RMS que conseguí a un buen precio. A la salida del amplificador conectaré un par de parlantes, de esos que se utilizan para ambientación de exteriores. Todos estos componentes se pueden conseguir por poco más de USD$100.

Sistema de voceo anti-feedback de bajo costo para Elastix Sistema de voceo anti-feedback de bajo costo para Elastix paging system elastix

Lo primero será habilitar el módulo chan_oss que viene con Elastix pero se encuentra deshabilitado por omisión. Habilitarlo es sencillo, abrimos el archivo /etc/Asterisk/modules.conf y comentamos la línea que impide cargar el módulo chan_oss.so. A continuación un fragmento del archivo con la línea comentada.


; Load either OSS or ALSA, not both
; By default, load no console driver
;
noload => chan_alsa.so
;noload => chan_oss.so

Chan_oss es un canal que se conecta con la tarjeta de sonido. Al ser un canal podemos hacer un puente entre una llamada y la tarjeta de sonido.

Lo siguiente será editar el archivo de configuración /etc/asterisk/oss.conf y dejarlo como sigue.

[general]
autoanswer=yes
context=from-internal
overridecontext=yes
extension=s
language=en
playbackonly=yes

Es importante dejar el parámetro autoanswer=yes para que la tarjeta de sonido conteste automáticamente cuando llamamos. El resto de parámetros están bien comentados en el archivo oss.conf que viene por omisión en Elastix.

Finalmente añadimos un nuevo contexto a nuestro plan de marcado para llamar a una extensión de voceo. Este contexto lo añadí en el archivo /etc/asterisk/extensions_custom.conf

[voceo-neomano]
exten => *2011,1,Dial(console/dsp,20,A(beep))
exten => *2011,n,Hangup()

De este modo podemos llamar a la extensión *2011 y cualquier cosa que digamos desde el teléfono, saldrá por la tarjeta de sonido.

Bueno, hasta aquí lo usual. Ahora el truQuito que les prometí 🙂

La idea que se me ocurrió para eliminar el feedback es correr un poQuito la frecuencia del audio que sale por el parlante. De este modo, cada vez que el audio se retroalimente por el teléfono tendrá una frecuencia ligeramente superior evitando que una misma frecuencia predomine a través del sistema.

Esto hasta hace poco era muy dificil, pero desde Asterisk 1.8 contamos con una muy interesante característica que permite hacer un corrimiento de frecuencia o “pitch”. Para realizar esto modifiqué un poco el plan de marcado anterior.

[voceo-neomano]
exten => *2011,1,Set(PITCH_SHIFT(both)=.95)
exten => *2011,n,Dial(console/dsp,20,A(beep))
exten => *2011,n,Hangup()

Como se puede observar hemos configurado un desplazamiento de frecuencia muy pequeño, utilizando la función PITCH_SHIFT. La idea es que casi ni se note. Sin embargo, debería ser suficiente para eliminar el molestoso feedback.

He escogido un valor menor a uno, lo que significa que la voz sonará ligeramente más grave.

Bueno, eso es todo, espero que sea de utilidad.

Micro lector de twitter usando javascript (jQuery)

OJO: Este artículo fue escrito usando el REST API versión 1. Actualmente Twitter tiene disponible el API versión 1.1, por lo que puede ser que en un futuro cercano este ejemplo no funcione. Actualizaré el ejemplo cuando tenga algo de tiempo.

Hace unas semanas me vi en la tarea de escribir un módulo “ligero” para un sitio Web, con el objeto de poder leer una cuenta de twitter vía Javascript. Al final terminamos instalando uno de esos modulitos para WordPress que ya resuelven el tema gráfico de maravilla y mi código terminó tirado en una esquina 🙂

Sin embargo, me puse a retocar el código con el objetivo de dejarlo al mínimo (o casi) y así utilizarlo con fines didácticos. Aquí les dejo el código en cuestión, el cual usa jQuery y lee los tweets de la cuenta @Elastix.


  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js"></script>
  Script de prueba de modulo para Twitter
  <div id="twbox"></div>
  <script type='text/javascript'>
    function leerEntradas(json) {
      var varSal = "<ul>";
      $.each(json.results, function(key, val){
        varSal += "<li>"+val.text+"</li>";
      });
      varSal += "</ul>";
      $("#twbox").html(varSal);
    }
  </script>
  <script src="http://search.twitter.com/search.json?q=from%3AElastix&callback=leerEntradas&rpp=10"></script>

El archivo anterior lo podemos grabar con extensión .html y ver desde cualquier navegador. Debería mostrar los 10 últimos tweets de la cuenta @elastix.

Analicemos un poco el código anterior.

En el BODY de la página Web vemos un DIV con nombre “twbox”. Es este cajón el que llenaremos con el texto de los tweets.

Al final del script veremos que estamos invocando al API de twitter a través del URL http://search.twitter.com/search.json

A este URL le estamos pasando 3 parámetros:

  • El nombre de la cuenta de twitter de la cual queremos obtener los tweets
  • El nombre de la función callback (leerEntradas en nuestro caso) a la cual el API de twitter le pasará los resultados de la búsqueda
  • El número de tweets que queremos que nos devuelva la consulta

La funcion leerEntradas es bastante sencilla y simplemente se barre los resultados y les da un formato de lista simple (Los tags LI). Finalmente la función llena el DIV “twbox” con la lista.

Hay que tener en cuenta que la consulta al API de twitter es una simple búsqueda por el término “elastix”. En realidad no son los tweets del usuario @elastix, por lo que también veremos en los resultados cualquier tweet (no necesariamente de @elastix) que incluya la palabra “elastix” dentro de el.

Sistema de riego controlado por teléfono

Elastix Sprinkler Sistema de riego controlado por teléfono Sistema de riego controlado por teléfono elastix sprinkler

Quién no ha soñado alguna vez con llamar al sistema de riego de su jardín para encenderlo?… Bueno, probablemente casi nadie 🙂

La cosa es que me entró esa idea en la cabeza. No se si sea algo práctico realmente, pero aquí va un artículo que relata con cierto detalle el experimento que hice.

Es importante explicar, antes de continuar, que existen algunas cosas que voy a asumir a partir de ahora, y es que el lector está familiarizado con Elastix, Asterisk, AGI, PHP y Arduino. Además asumiré que también tiene conocimientos básicos de electrónica.

Para aclarar mejor cómo funcionará el sistema dibujé la siguiente figura donde se ilustran los componentes que lo conforman.

Sistema de riego controlado por teléfono Sistema de riego controlado por teléfono elastix automat

Como ilustra la figura anterior hay dos componentes principales que necesitaremos, y son:

  • el servidor Elastix, y
  • la interfaz con la válvula de riego (o interfaz de riego)

El servidor Elastix

Para el servidor Elastix instalé la versión 2.2 RC1. Este servidor es el que me servirá de PBX pues lo conectaré con el mundo exterior mediante una línea telefónica. De este modo puedo llamar por teléfono al servidor Elastix y activar el riego.

Como se puede observar en la figura aterior, en este servidor residirán dos programitas que desarrollé: Un script AGI y un driver de alto nivel (para que se comunique con la interfaz de riego vía USB). Ambos los escribiré en PHP debido a que es un lenguaje muy popular y existe bastante documentación que se puede consultar vía Web; de este modo la explicación es más entendible.

Alguno se puede preguntar por qué no controlo al Arduino directamente desde el script AGI. La respuesta es que preferí tener el driver por separado porque también me servirá para controlar el Arduino desde la interfaz Web que desarrollaré en un futuro próximo. Eso es lo que significa el rectángulo que dice “Interfaz Web” en la figura anterior.

Interfaz de riego

La interfaz de riego es un circuito que por un lado se conecta al servidor Elastix a través de un puerto USB y por el otro se conecta a la válvula de riego. Hay muchas maneras maneras de realizar esta circuitería. En mi caso me decidí por usar una placa Arduino conectada a un relé. Básicamente porque tenía una placa Arduino ociosa y decidí darle algún uso interesante. Esta placa se encuentra conectada a un relé a través de una circuitería sencilla.

En la siguiente figura se muestra la interfaz de riego cuando la planifiqué por primera vez en protoboard (breadboard).


Sistema de riego controlado por teléfono Sistema de riego controlado por teléfono interfaz de riego bb

En la práctica terminé reemplazando el circuito de relé con uno pre-construido que compré para Arduino (con entrada opto-aislada y doble relé) y que en Internet hay un montón a precios razonables.

Lo único que no me gustó mucho del circuito que compré es que tiene lógica negada. Es decir, que cuando la entrada es un HIGH el relé se encuentra apagado, mientras que cuando es un LOW se encuentra encendido. Por eso verán más adelante que el código para el Arduino toma en consideración esta lógica.

La válvula de riego

En mi caso se trata de una válvula marca Rainbird controlada con 24 voltios AC. Nada del otro mundo; tiene dos cables y si los energizamos con 24 VAC la válvula se enciende y el agua pasa a los aspersores.

El protocolo de comunicaciones entre Elastix y la interfaz de riego

El protocolo que utilizaré será lo más sencillo posible. De esta manera le será más fácil al lector entender el código. El protocolo consiste de un solo comando compuesto por un byte. Este byte será interpretado como un número entero por el Arduino y representará el número de minutos que se desea activar el riego. Si deseo interrumpir el riego envío el número 128.

Modificación del plan de marcado de Asterisk

En mi caso particular he configurado el siguiente contexto en el archivo /etc/asterisk/extensions_custom.conf

[sprinkler]
exten => *2222,1,Answer
exten => *2222,n,AGI(sprinkler.agi)
exten => *2222,n,Hangup()

Esto quiere decir que cuando alguien marque el número *2222 le contestará mi script AGI, que por cierto se llama sprinkler.agi.

El script AGI

Aquí también los dejo con el código de mi script AGI. No se olviden de darle los permisos correctos.

#!/usr/bin/php -q
<?php
require_once "phpagi.php";
$agi = new AGI();
$arr_minutos_riego = $agi->get_data('custom/minutosactivos', 20000, 3);
$minutos_riego = $arr_minutos_riego['result'];
$comm = "sudo /opt/sprinkler/driver " . $minutos_riego;
exec($comm, $sal);
$agi->stream_file('custom/riegoconfigurado');
?>

El script anterior lo podemos dividir en dos partes:

  1. Primero le pregunta al llamante por el número de minutos que desea que el sistema de riego permanezca encendido. Esto lo hace mediante la función get_data
  2. Luego invoca al driver y le pasa como parámetro el número de minutos antes obtenido. Esto lo logra /opt/sprinkler/driver

Cabe resaltar que el script anterior utiliza dos archivos de audio que el lector puede grabar a su gusto. Estos archivos los he llamado minutosactivos.wav y riegoconfigurado.wav. En el primer archivo grabé un mensaje parecido al siguiente:

“Por favor, ingrese el número de minutos que desea regar”

Y en el segundo grabé un sencillo mensaje de agradecimiento:

“Gracias por usar el sistema de riego Elastix”

Cabe mencionar que he preferido mantener el script AGI lo más sencillo posible para propósitos didácticos, pero el lector lo puede añadir complejidad y por ejemplo, validar la entrada del usuario, o pedirle que confirme el número de minutos, entre otras cosas.

Driver para comunicación con la interfaz de riego

Bueno, ahora sí veamos de qué está hecho el driver de alto nivel que controla el Arduino vía USB.


#!/usr/bin/php -q
<?php
$arg_segundos = trim($_SERVER['argv'][1]);
$data = chr((int)$arg_segundos);
$fp=fopen("/dev/ttyUSB0", "r+");
$r = fwrite($fp, $data);
fclose($fp);
?>

Nuevamente, he preferido mantener el código anterior al mínimo. Dejo al lector la tarea de añadir validaciones. Por ejemplo, estoy asumiento que el dispositivo ha sido asociado con /dev/ttyUSB0, pero eso puede variar de sistema en sistema.

Código para el Arduino

Ahora sí, el código para el Arduino. Este código se debe cargar en el Arduino para que haga lo que necesitamos.


#include <Time.h>  

int relPin = 2;
int usbnumber = 0;
int active = 0;
time_t timeend = 0;

void setup() {
    pinMode(relPin, OUTPUT);
    digitalWrite(relPin, HIGH);
    Serial.begin(9600);
}

void loop() {
    // Aquí se lee del puerto USB
    if (Serial.available() > 0) {
        usbnumber = Serial.read();
    }

    // 128 es el comando para apagar (interrumpir) la salida del relé
    if(usbnumber==128) {
        active=0;
        digitalWrite(relPin, HIGH);
    }

    if(active==0) {
        // Si el riego estaba inactivo y se recibió un número mayor a cero
        if (usbnumber > 0) {
            active = 1;
            digitalWrite(relPin, LOW);
            timeend = now() + usbnumber*60;
        }
        usbnumber = -128;
    } else {
        // Si se alcanzo el tiempo previsto apago el relé
        if(now()>=timeend) {
            active = 0;
            digitalWrite(relPin, HIGH);
        }
    }
}

Conclusión

Muy aparte de la utilidad para regar un jardín, espero que este proyecto encuentre muchas otras aplicaciones. A final de cuentas se trata de un relé que se activa por un tiempo determinado. Si alguien lo construye o le encuentra alguna otra aplicación práctica, será gratificante ver su comentario por aquí.

Son los vehiculos eléctricos la solución del futuro… o del pasado?

Me encanta coleccionar libros viejos, y si son técnicos mejor. Me he encargado de darles una “segunda vida” a algunos ejemplares que ya estaban a punto de ir a parar al basurero en casa de algunos conocidos míos.

Cuando me aburro de estar leyendo noticias en Internet acerca de “lo último” en tecnología busco los libros viejos. Son un interesante escape, y así me entero de qué fue “lo primero” en tecnología, en los tiempos cuando lo que ahora es viejo fue nuevo!. Y es que da nostalgia sumergerse en esa realidad ya olvidada de los primeros hombres de ciencia, verdaderos héroes, que se proponían llevar a cabo sus ideas o experimentos incluso a costa de sus vidas.

Entre mis ejemplares más preciados se encuentra la Guía Eléctrica de Hawkins de 1927. Me encontraba hojeando alguna de sus páginas cuando me encontré con un apartado que decía “Electric Vehicles” (“Vehículos Eléctricos”). Me causó sorpresa enterarme de lo populares que fueron los autos eléctricos a principios del siglo pasado. Sin embargo, lo que más sorpresa me causó fue enterarme que algunos modelos tenían una autonomía de entre 75 y 100 millas por carga!

La siguiente figura es una foto de una de las páginas de la enciclopedia. Allí se muestra un vehículo de la marca Baker Electric.

son los vehiculos eléctricos la solución del futuro... o del pasado? Son los vehiculos eléctricos la solución del futuro... o del pasado? hawkins4

A continuación una fotografía de este vehículo en la vida real. Bonito, verdad?

carroelectrico son los vehiculos eléctricos la solución del futuro... o del pasado? Son los vehiculos eléctricos la solución del futuro... o del pasado? carroelectrico

Pero Baker Electric no fue la única compañía fabricando autos eléctricos. Existían varias. Una de las más conocidas era Detroit Electric, que construyó varios modelos de vehículos eléctricos a principios del siglo XX. A continuación uno de ellos, el modelo 46, fabricado en 1914.

detroit son los vehiculos eléctricos la solución del futuro... o del pasado? Son los vehiculos eléctricos la solución del futuro... o del pasado? detroit

La misma esposa de Henry Ford poseía un vehículo de Detroit Electric.

Existieron más compañías fabricando vehículos eléctricos. La pregunta entonces es: por qué esta tecnología dejó de ser la más usada? Por qué tuvo que hibernar por tanto tiempo?

Los problemas que nos ha generado la dependencia del petróleo han sido nefastos para la humanidad, pasando por contaminación del aire, derrames de crudo en nuestros océanos y hasta guerras.

Los automóviles eléctricos existían antes que los autos a combustión y seguramente existirán después de ellos. Es en el medio donde la humanidad cometió un grave error.

En la actualidad se habla mucho de que los autos eléctricos son el futuro y que se podrán recargar desde una toma eléctrica común. Muchos los ven como la solución a los problemas inherentes al petróleo. Sin embargo, la gran pregunta que me hago es: No estábamos usando ya este tipo de tecnología en los años 20? Será a lo mejor que la ambición del hombre y el gran negocio del petroleo cegó nuestra creatividad y archivo la idea del vehiculo eléctrico por décadas? El tiempo nos dirá.

¿Qué conozco de VoIP?

Cuántos saben que es VoIP o que es una IPPBX? probablemente muy pocos, sin embargo muchos utilizan un sistema de ese tipo en su empresa o medio ambiente de trabajo. Hace tiempo quise hacer una explicación al respecto y me empujó la pregunta de un amigo de la universidad que me dijo hace poco, “Con qué se come eso!!”

 

Hablar de los conceptos de VoIP quizás sea extenderme mas de lo que quisiera aunque una analogía sería decir que: Skype es una central telefónica que tiene miles de usuarios  donde cada usuario es una extensión que esta conectada a esta central y que en algún momento marca a una extensión (asociada por el nombre del usuario) para llamar a alguien. Todos sabemos que este servicio es posible porque tenemos un enlace de datos o una conexión a internet donde nuestro telefonito skype se mantiene conectado a este servicio de grandes dimensiones.

 

Voz Sobre IP, VoIP o Voz sobre un Protocolo de Internet, no es mas que el proceso por el cual una conversación de voz es transformada en dígitos  que son conducidos a través de miles de caminos existentes en una inmensa nube de datos para llegar a un destino en alguna parte del mundo donde se decodifican para ser nuevamente transformados en ondas mecánicas para poder decir a alguien “Buenos días desde Guayaquil”.  En realidad es mucho mas complicado, sin embargo esta tecnología garantiza que en cualquier lugar donde tengamos acceso a un punto de datos podamos establecer una conexión que nos permita tener comunicación.

 

Esto último es muy importante y muchos de ustedes ya habrán pensado en las infinitas posibilidades que representa, sobre todo en ambientes donde la conexión remota es primordial o donde el acceso sea difícil, o en casos de emergencia y desastres.

 

Retomemos por un momento el ejemplo de Skype, no me equivoco al decir que al menos 1 de cada 6 personas en latinoamerica ha usado ese servicio y ha experimentado aunque sea una vez una llamada de Voz sobre IP, con lo cual confirmamos que miles de millones en el mundo hemos usado VoIP como medio de comunicación. Esa quizás sea la razón por la cual una de las empresas mas poderosas del mundo adquirió Skype por USD$8.500 millones, teniendo así acceso a miles de millones de usuarios en todo el mundo.

 

Esto nos lleva a pensar que el mundo se convertirá en algún momento en una gran central telefónica donde todos tenemos una extensión. No es una locura pensarlo, principalmente por los adelantos tecnológicos que han permitido que la tecnología que permite correr a sistemas VoIP haya cumplido dos condiciones importantes: bajar de costo y distribuirse exponencialmente. De ahí que muy pronto el negocio de las operadoras sean los “Datos”, si usted lo ha escuchado ya, no es una coincidencia.

 

El por qué es importante VoIP actualmente va también de la mano con conceptos como productividad y eficiencia, de ahí que muchas empresas busquen incorporar en sus comunicaciones sistemas basados en esta tecnología, principalmente por la posibilidad de adicionar miles de features que probablemente no tengan que ver con telefonía pero que facilitan el trabajo de la organización en miles de áreas.

 

Cuando entré al proyecto Elastix habiendo trabajado en petróleo, construcción y en la industria metal mecánica, me sorprendió lo complejo que podía ser tratar de entender todos los conceptos de como funciona esta tecnología, sin embargo me sorprendió también ver el sin número de posibilidades existentes en cuanto a funcionalidad y eso me abrió las puertas a un mundo fascinante al cual uno no puede resistir estudiar. Valga la pena decir que Elastix es un proyecto de Comunicaciones Unificadas donde su principal objetivo es establecer VoIP y valga la pena decir también que es un proyecto latinoamericano reconocido mundialmente.

 

Espero haber abierto la duda, o al menos terminar de confundirlos mas. Esto último como broma, lo cierto es que en nuestra vida actual hay muchos momentos en que usamos VoIP y lo interactuamos con otros servicios y otras funcionalidades y lo seguiremos usando hasta que la tecnología invente el “CoT” o Communication over Telepaty.

 

Si quieren conocer mas de VoIP, la telefonía IP y Elastix visiten el siguiente vínculo: http://ur1.ca/4frnc

Snapple, estás seguro de lo de los pinguinos?

Hace algunos años que consumo bebidas Snapple. Suelo abastecerme de “grapeades” cuando voy al supermercado.

Una iniciativa interesante de Snapple es incluir bajo la tapa de sus botellas un relato curioso de estilo muy corto que llaman “real fact” o “hecho real”. Siempre los leo y la mayoría son interesantes. Los tienen numerados y todo.

Alguna vez, hace ya más de un año me topé con uno que me llamó la atención y decía: “The only bird that can swim and not fly is a penguin”. En español “La única ave que puede nadar pero no volar es el pinguino”.

Me llamó mucho la atención porque conozco de al menos otra ave con las mismas características llamada Cormorán de las Galápagos o Flightless Cormorant. No es que sepa mucho de aves, pero vivo cerca de las Galápagos y alguna vez vi al avechucho con mis propios ojos.

Inmediatamente fui a Wikipedia para verificar si se trataba de un error de Snapple y me topé con una página acerca del ave http://en.wikipedia.org/wiki/Flightless_Cormorant

Luego de disipar mis dudas me propuse contactar a Snapple para contarles que su “real fact” no era tan “real” después de todo. Mi preocupación era principalmente que los niños toman estas bebidas y podrían estar desinformándose en lugar de aprender.

Escribí un email a una dirección de Snapple que encontré en su sitio Web y alguien me respondió diciendo que sus “real facts” habían sido realizados por personas con un alto grado de conocimiento. Básicamente eso era todo!

Yo entiendo que las personas de servicio al cliente no tienen por qué conocer que el Cormorán de las Galápagos existe, pero al menos esperaba que el asunto escalara y pudieran cambiar el “real fact” por otro más preciso. A fin de cuentas puede que mucha gente piense ahora que el pinguino es la única ave que puede nadar y no volar!

Ya me había olvidado del asunto cuando ayer vi en el sitio de Snapple un vínculo a algunos “real facts” que han sido retirados: http://www.snapple.com/retired-facts/

Allí aparece el mencionado “#121 The only bird that can swim and not fly is a penguin”, lo cual me causó cierto alivio. Al menos esta información no seguirá propagándose.

Sin embargo, en ningún lugar dice que se trata de una cita errónea. Será que es difícil para Snapple emitir una corrección o será que todavía está seguro de lo de los pinguinos?

Nuestro razonamiento contextual no siempre ayuda

Hace un par de meses estuve de paso en el aeropuerto de Santiago de Chile y mientras esperaba mi vuelo sentado en la sala de embarque noté que alguien, a lo lejos, me hacía de la mano. No supe quién era pero por cortesía respondí levantando también mi mano mientras ponía una cara de “un gusto verlo”, que debe haber lucido más a “quién es usted!?”.

Pasé todo el vuelo de regreso a Guayaquil tratando de descubrir la identidad del personaje. Lo más mortificante era que la cara se me hacía conocida.

Debido a que me encontraba haciendo escala (en tránsito) de un vuelo desde Buenos Aires comencé a barajar la posibilidad de haberlo conocido en dicha ciudad, pero no recordaba nada que me permitiera descubrir su identidad.

Vale la pena mencionar que no es común, al menos para mi, encontrar a un conocido en un aeropuerto de una ciudad lejana así que se me ocurrió que a lo mejor lo conocí en el vuelo de ida, pero de nuevo no pude relacionar la cara con ningún recuerdo.

Supongo que muchos habrán tenido aquella sensación de tener un nombre en la punta de la lengua… Pues así anduve yo durante los días posteriores al viaje, hasta que supongo que inconscientemente decidí rendirme y dejar este asunto para “misterios sin resolver”. Un amigo una vez me dijo que en estas situaciones era mejor no tratar de recordar y que el cerebro se encargaría de acomodar las cosas por si mismo. Nunca me convenció esa teoría pero terminé pensando que era lo mejor en esta situación.

Habrán pasado al menos unas cuatro semanas, cuando una tarde salí de mi casa y vi a mi vecino (que vive a 3 casas de la mía) subiéndose a su vehículo. Inmediatamente lo reconocí, era el sujeto del aeropuerto, mi vecino! Cómo podía ser yo tan tonto para no haberlo reconocido en el aeropuerto!

Luego de la alegría interna de haber finalmente resuelto el acertijo comencé a sentirme algo apenado por haberlo saludado un tanto fríamente en el aeropuerto. Tampoco es que éramos amigos de toda una vida, ni siquiera sabía su nombre; pero al menos lo saludaba cada vez que lo veía y habíamos conversado brevemente en alguna ocasión.

Toda esta situación me llevó a reflexionar acerca de la manera en que funciona nuestra mente cuando trata de reconocer un objeto o un personaje. Parece acertado suponer que las conclusiones a las que llega nuestro cerebro dependen del contexto en el que nos encontramos. Así fue como pude reconocer a mi vecino casi inmediatamente cuando lo vi en mi barrio, pero me fue imposible reconocerlo en el aeropuerto de Santiago.

20110531-123334.jpg Nuestro razonamiento contextual no siempre ayuda Nuestro razonamiento contextual no siempre ayuda 20110531 123334

Recuerdo hace algún tiempo haber leído en una revista acerca de un algoritmo de reconocimiento de voz que utilizaba una técnica similar para incrementar su efectividad. El algoritmo en cuestión trataba de relacionar una conversación con un tópico, dependiendo de las palabras empleadas en la conversación. Previamente el algoritmo había “aprendido” la probabilidad de encontrar una determinada palabra en una conversación dependiendo del tópico.

Por ejemplo, es más probable que escuchemos la palabra “altar” si estamos en una iglesia que si estamos en el estadio viendo un partido de fútbol.

En general parece ser una astuta táctica de nuestro cerebro, pero a mi me quedó claro que no siempre ayuda.