Estos proveedores, a través de Internet, acceden al detalle del proyecto y rellenan los precios para cada uno de los elementos del mismo: 2.000 poyaques a 15 lerus/unidad, 1.500 filostros a 200 lerus/cuartoymitá, etc.

El gerente del cliente ha decidido que no. Que eso es complicarle la vida a los proveedores y que mejor seguir con el tradicional sistema de coger el teléfono y llamar a los susodichos. Como única mejora, admite que se puedan mandar emails pidiendo los presupuestos.

Este es el tipo de “mejoras” que sólo se toman en España.

Publicado en faq-mac.com.

But if you’re writing your own application you’ll need to handle those characters by yourself. Twitter send them encoded as Unicode, so it’s easy to process them using PCRE… if your installation of PCRE is compiled with full Unicode support.

So, the first step is to check your configuration. This snippet will tell you if PCRE supports Unicode.

if (@preg_match('/\pL/u', 'a') == 1) {
    echo "PCRE unicode support is turned on.";
} else {
    echo "PCRE unicode support is turned off.";
}

The solution varies from distro to distro. Here you’ll find the way to get Unicode support on Centos.

And now for a simple function to linkify the tweets.

/**

    * Linkify function with support for utf-8 characters.
    *
    * @param $text is the raw text of the tweet
    * @return the same tweet with links, users and hashtags linkified
    *
    */

function procesaTwit($text) {
    return preg_replace(array(
            '@(https?://([-\w\.]+)+(/([\w/_\.\-]*(\?\S+)?(#\S+)?)?)?)@',
            '/@(\w+)/',
            '/#([\d\w\pL]+)/',
        ),

        array( '<a href="$1" target="_blank">$1</a>',
                '<a href="http://twitter.com/$1">@$1</a>'
                '<a href="http://twitter.com/#!/search?q=%23$1">#$1</a>'
        ),

        $text);
}

That’s all you need to properly linkify tweets with Unicode characters.

El problema es que, generalmente, esta gente no sabe de lo que habla o sólo sabe lo que ha escuchado de otros que cobran por decir que saben. El mundo de la cancamusa tiende a retroalimentarse. Es una Sociedad de Elogios Mutuos donde nadie va a confesar que no tiene ninguna solución (aunque las venda).

Mi amigo Juán Díaz Díaz (que no cobra por decir que sabe, si no que sabe) lleva meses en su particular #twitterquest, cubriendo eventos, añadiendo followers y examinando métricas y resultados de los distintos experimentos que va realizando con herramientas tanto públicas como home-made. Actualmente tiene 42k followers. Los que cobran por decir que saben niegan que eso sea útil.

Aunque las coberturas que realiza de cada evento, comentando o simplemente retransmitiendo lo que dicen los ponentes, lleguen a más de un millón de impresiones (p. ej., 2.4M con 70 twits sobre el CongresoSMM). O que esté en el puesto número 7 de la élite twittera en Catalunya o el 23 a nivel nacional. Resultados que esos mismos que cobran por decir que saben ni siquiera sueñan con tener, ni para sus clientes ni, mucho menos, para ellos mismos.

El problema es que no entienden que las reglas han cambiado. No se trata de que alguien vea a un famoso recomendando un producto o un servicio. Como dice Juan, la audiencia es importante porque tu NO sabes quien es un prospecto. y si lo sabes ya vas a por el.

Y claro que parte de esos 42k followers, o de los millones que puede llegar a leer los mensajes reenviados por esos usuarios, incluyen ruido y bots, pero si no contactas con la masa no tienes factor de amplificacion. Nunca sabes cuándo una parte de la masa se va a interesar por tu mensaje y para tener efecto amplificado tienes que tener mucho donde ir cebando.

Mientras tanto los que cobran por decir que saben siguen diciendo que el tamaño no importa.

Cuando buscamos algo en un libro de referencia físico vamos al índice donde encontramos las palabras o conceptos que el autor piensa que son importantes en el ámbito de aplicación del libro, agrupándolas en ocasiones. Por ejemplo, en un libro de JavaScript:

object constants, 109, 110
Object constructor
creating objects, 41
factory pattern and, 148
toString() method, 48
usage considerations, 41, 42

Es decir, el autor o el editor han recogido los términos que consideran más relevantes. Un trabajo complicado y espeso.

Se supone que en un ebook no es preciso utilizar esos índices, porque tenemos un buscador. Pero… esa herramienta busca por palabras, no por conceptos. En la página 41 del libro citado más arriba no aparace “usage considerations”, pero cuando revisamos el índice para saber más sobre el constructor de un objeto nos viene bien saber que en esas dos páginas se hacen algunas consideraciones sobre el uso del mismo. En resumen, ese índice que nos parece innecesario porque tenemos buscador si que tiene utilidad.

Pero nuevamente, crear ese índice es un proceso largo y tedioso. Que tiene otra desventaja. Refleja lo que el autor, que es el que sabe del tema, considera importante sobre la materia tratada en el libro. Lo suficiente como para merecer una entrada en el índice. Pero un lector puede encontrar que en ese mismo libro hay un dato interesante que no aparece reflejado en el índice por la razón que sea.

Si el lector acude a menudo al libro en cuestión (como hacemos muchos con muchos libros) le viene bien poder acceder rápidamente al punto o puntos en cuestión. En los ebooks actuales se recurre a marcar dichos puntos y anotar. Imagino que, incluso permitirán buscar por las anotaciones de los puntos de lectura insertados (estoy hablando ahora sólo en plan teórico, no pienso levantarme a coger el Kindle).

Pero… ¿no sería más útil que el lector pudiese ir creando o ampliando el índice del libro utilizando las búsquedas que ha realizado como base? Por supuesto que no todas las búsquedas que se hacen en un libro electrónico son válidas o relevantes. Como tampoco lo son todas las búsquedas que hacemos en el índice de un libro en papel. Se puede añadir un botón al listado de resultado de una búsqueda donde “nombrar” dicha búsqueda y añadirla a nuestro índice.

Y, poniendonos 2.0, ¿qué nos impide añadir otro botón que envíe nuestra entrada del índice a un repositorio donde otros lectores del libro puedan aprovecharse de nuestra búsqueda?

Y se aplica a todos los ámbitos, técnicos o no. El problema viene cuando te toca lidiar con dos tipos de personajes: el que piensa que lo que está empeñado en hacer/implementar/arreglar es una buena idea y el buenrollista profesional, también conocido como “a quién se le va ocurrir lanzar un ataque contra nuestra web, si somos guenos”?

En otros universos paralelos es costumbre escuchar a alguien con una cierta experiencia y entender que no dice las cosas por aburrimiento. En apaña lo normal es que los que acaban de salir de un curso rápido de naderías hagan lo contrario de lo que se les ordena o se salten todos los mecanismos/protocolos/devolucionesdefunción de seguridad “porque es aburrido y así es más rápido”. O directamente pregunten “por qué hay que comprobar que el cliente está conectado a la base de datos si ya he llamado a la función de conexión?”.

Así que con el tiempo eres el borde negativo que no se alegra cuando alguien envía un email a una startup diciendo “estupendo lo que habeis creado. me gusta mucho. ¿cuándo puede mi técnico hablar con el vuestro para que lo cambieis para que haga lo que a mí me interesa?”.

El problema son los filtros que se han añadido al router. Que se desactivan fácilmente, cuando se sabe que existe.

Sólo hay que acceder a la dirección del router (típicamente 192.168.1.1) pot telnet.

La opción de los filtros es la 21

Los filtros pueden variar en tu configuración. En el router anterior no existian ni el 11 ni el 12

El filtro WebSet2 es el "culpable".

En Active cambia el valor a No.

Un par de horas de dolor de cabeza resueltas en un minuto. Cuando se sabe dónde buscar.

Hace unos meses sufrí, indirectamente, a ese mismo departamento de producto en cierto ministerio de cuyo nombre prefiero no acordarme. Pongamos, para simplificar, que se llama Mordor: un edificio poblado por tribus de orcoficinistas cordialmente enfrentados (del buenrollismo de funcionario hablaremos otro día).

Hallábame, a la sazón, en el susodicho Mordor redimiendo condena y alicatando el baño de ejecutivos. El problema estaba en que los que debían decidir el tipo, tamaño y color de los azulejos no sólo no ocultaban su desconocimiento sobre lo más básico: si poner los azulejos pareados o al tresbolillo, porque no es buena idea alicatar con pladur… sino que no tenían muy claro quien era el experto-barra-responsable (en un ministerio siempre ha de haber un jefe o jefa de negociado que alivie el penoso trabajo de responsabilizarse de una decisión) que había de determinar la forma, color y sabor de los susodichos azulejos.

Así se dieron casos surrealistas como el de la, en principio, sencilla pregunta sobre si los azulejos debían ser rojo chillón o amarillo fosforito que devino en ameno conciliábulo al que se fueron añadiendo el encargado de la masa, luego el aparejador, el constructor (que es de producto, pero parece que menos)… para determinar que eso sólo lo podía decidir otra individua del anteriormente citado negociado de producto. Momento memorable cuando el constructor dijo “eso está en el briefing, seguro”; después de descifrar el citado briefing (alias PowerPoint) el discurso cambió a “está en el briefing de los que están pintando los trasteros, seguro”. ¡Ah, la seguridad de los expertos!

Hubo, en ese mismo proyecto, otros momentos memorables, como el apasionado speech de esa persona a quien podemos únicamente identificar como la grávida, echando balones fuera (“pero al final esto lo tiene que decidir la jefa de negociado”) ante el sufriente diseñador del primer párrafo, alardeando de sus múltiples desconocimientos mientras ofendía a todos aquellos que tenían que sacar adelante sus indecisiones… O simplemente tirar adelante con un trabajo del que no había ni documentación ni definición ni perrito que le ladre.

Qué sería de las empresas sin estos divertidos departamentos que deciden sin saber, que encargan (y pagan sospechosamente bien) diseños que nunca se implementarán y que están, en definitiva, por encima de esos pequeños detalles como decidir de qué color tienen que encenderse los azulejos cuando el que entra en el baño de ejecutivos es el jefe de la Horda o el mismo Sauron.

Finalmente la condena fue redimida, el baño fue alicatado y hubo gran regocijo (por mi parte). Posteriormente corrieron rumores de que iban a levantar los azulejos para poner las cañerías. Que estaban en el briefing, seguro. Y se sigue sin saber si los azulejos deben ir en filas o al tresbolillo.

The solution can be divided in three parts:

1. how to know in which language we must show the page,

2. how to render the “structure” of the pages and

3. how to get the content of the pages.

In this entry I’ll show how to code, in PHP, the fist part of the solution.

The code is simple. We want to change the language of the page at user’s request AND store the language settings in the client, so the next time our page is loaded it will automagically show the language selected by the user in his/her last visit.

// tipically you define the root of your globals in a confif file
// it's define here for completeness...
define('VAR_ROOT', 'MY_PAGE_');

// the language by default
$strDefLanguage = 'es';

// an array of allowed values for strLan
// HINT: whenever possible check any user input with a list
// 		of 'legal' values.
$arrLanguages = array('en', 'es', 'fr', 'de', 'ca');

/**
  * this function returns the language for our application.
  *
  * @param an string that, optionally, contains the language to switch to.
  * @returns the language in use right now for our app
*/
function getLanguage($strLan = '') {

    if($strLan != '' && in_array($strLan, $arrLanguages)) {
        $_SESSION[VAR_ROOT . 'LANG'] = $strLan;
        setcookie(VAR_ROOT . 'LANG', $strLan, time() + 60 * 60 * 24 * 30);
    }
    return (isset($_SESSION[VAR_ROOT . 'LANG']) ? $_SESSION[VAR_ROOT . 'LANG'] :
           (isset($_COOKIE[VAR_ROOT . 'LANG']) ? $_COOKIE[VAR_ROOT . 'LANG'] :
           $strDefLanguage));
}

Note that this function goes against the principle of simple responsability. Sometimes we sacrifice this kind of things for speed and functionality. It’s not bad. Neither good.

Anyway, you’ll call this function on each of your pages, before starting to render the structure or to read the data from the database.

<?php
// you MUST start a session for this to work.
session_start();

// your includes go here
require_once('someconfig.php');    // like this one...

// now you read the language
// we're setting the language to the lan parameter
// only if it exists.
// otherwise we just get the current language.
$strLang = getLanguage(isset($_GET['lan']) ? $_GET['lan'] : '');

// you can now read your literals file
// remember that strLang has a known, filtered, value
// so this is safe
require_once('lan' . $strLang . '.php');

// or instanciate your database class
$objNotes = new notesClass($strLang);

In next entries I’ll describe in more detail the other two parts.

In Twitter the user can slide a twit to show some controls that relate to that twit.  Jorge wanted to imitate this behaviour. After a fast search I explained him how to “bind” some JavaScript to the touchmove and touchend events. This morning, remembering the question I tried to code some fast example implementing a similar functionality.

Basically the user initiates an slide on an element of the list. When the element has been slided past a point it opens completely, revealing the controls beneath.

Thankfully I found here an example on how to mimic the sliding using both touch events and CSS transforms. This sample, in turn, referred to this other. Based on their code I managed to get mine working in a couple of hours. You can point your iPhone to http://www.forcen.com/tests/slide/ to see it in action. For simplicity all of the css, javascript and html are on the same page. The only external dependency is jQuery.

The markup

The HTML for this example is simple:

Each item is contained into a div, that will be the element that is slided.

<ul id="items">
    <li>
        <div id="2323232">
            <strong>first entry</strong><br />An example
        </div>
    </li>
    <li>
        <div id="2454532">
            <strong>second entry</strong><br />of how to imitate
        </div>
    </li>
</ul>

I only have a control bar that will be moved into place when the user starts a move over an entry. The holder is for keeping the  control bar hidden:

The Event Handlers

Now the JavaScript: At load time I bind the touch events to the code that will handle the movement of the item.

The touchstart event is generated when the user touchs on an item. Using jQuery bind it to all div elements with class “content”. The called function will not only initiate the controls bar but it’ll also close any open element whenever the user touchs on any element of the list.

$('div.content').bind(
    'touchstart',

    // whenever the user starts a touch event
    // on this kind of element...
    function(event) {

        // I close any open slider...
        hideControls();

        // and move the controls behind
        // the element touched by the user.
        setControls(event.target);

        // right now, the element is "closed"
        isOpen = false;
);

While the user is moving the element Safari will call this code:

$('div.content').bind(
    'touchmove',
    function(event) {
            // jQuery will send me the element
            // affected by the event
        var el = event.target,
            // this is a jQuery event object, so in order
            // to get the touch parameters I need to
            // access the originalEvent param.
            touch = event.originalEvent.touches[0],
            curX = touch.pageX - this.offsetLeft - 25;

        // we don't want the Safari's standard
        // behaviour for this kind of event.
        event.preventDefault();

        // we're near the left, do nothing.
        if(curX <= 0) { return; }

        // user's moved the element past a point,
        // so I make it slide completely to the left
        if(curX > 150) {
            showControls(el);

            // now the element is open.
            // the touchend handler needs to know it.
            isOpen = true;
            return;
        }
        // otherwise I move the element
        // to follow the user's gesture
         el.style.webkitTransform = 'translateX(' + curX + 'px)';
    }
);

Finally, the touchend event will be send when the user lift ups the finger. This event will be sent regardless of the point where’s the user’s stopped the gesture. And regardless of our code moving the element out of the viewport. So we need to know if the element is “open” or not.

$('div.content').bind(
    'touchend',
     function() {
        // only if our code hasn't been called...
        if(!isOpen) {
            // we move the element back to left.
            doSlide(this, 0);
         }
   }
);

This is just an example function that will be called when the user touchs the mail icon on the tools bar.

$('#boton3').click(doMail)

The Slider Code

The functions that show or hide the controls are, finally, fairly simple. They only need to move the controls bar behind another object and apply a simple CSS transition.

Why a transition instead of a jQuery animation?. In iPhone the CSS transitions are handled bu the GPU, so they are more swift and “natural”. Note the this transitions will not be as smooth on Android’s version of WebKit. Even, in some versions of Android there’ll be no animations at all.

// this function perfoms the sliding of the element
// using CSS3 transforms.
function doSlide(el, numPos) {
    el.style.webkitTransition = '-webkit-transform 0.3s ease-in';
    el.style.webkitTransform = 'translateX(' + numPos + 'px)';
}

// this function is called on touchstart.
// it "moves" the controls bar into the <li>
// that contains the <div> touched by the user.
function setControls(elDIV) {
    $(elDIV).closest('li').append($('#controls'));
}

// this just slides the element away to the right
function showControls(elDIV) {
    // I'm gonna need the refnum of the entry for
    // the functions called from the controls bar.
    numCurItem = elDIV.id;
    // slide the div way out to the right...
    doSlide(elDIV, ($(elDIV).outerWidth(true) + 50));
    // and store the currently open div in a var.
    elContent = elDIV;
}

// here we slide the "open" element back to the left
function hideControls() {
    if(elContent != null) {
        doSlide(elContent, 0);
        elContent = null;
    }
}

Conclusion

So, this is what happens when you mix coders and beer and laughs. You learn some interesting things and get cred points in the process. You can use a similar effect in a desktop web app, by implementing a draggable object like in the css-tricks.com sample.

BTW, the icons are from IconDock.