¿Cómo configurar symfony para usar gettext?

Para configurar symfony para que utilice gettext seguiremos los siguientes pasos:

1) Activamos el módulo I18N modificando el archivo settings.yml:

#apps/<appName>/config/settings.yml
all:
  .settings:
    charset:                utf-8
    i18n:                   on
    standard_helpers:       [ [TUS_HELPERS_ACTIVADOS]..., I18N]

2) Abrimos el archivo factories.yml y añadimos la entrada i18n:

#apps/<appName>/config/factories.yml
all:
  i18n:
    class: sfI18N
    param:
      default_culture:  en_US
      source:           gettext</pre>

3) Crearemos una carpeta i18n dentro de apps//:

apps/<appName>/i18n/<lang>

Donde <lang> será el idioma en dos letras (en, es, fr…) y dentro tendremos los ficheros messages.po y messages.mo.

Ahora podemos utilizar la función __( ‘texto_a_traducir’ ) con doble underscore [ _ ] en lugar del simple utilizado normalmente.

¿Cómo generar automáticamente nuestros ficheros po y mo?

Symfony trae una serie de herramientas que nos permiten generar los archivos po y mo de manera automática. Invocando el comando:

symfony i18n:extract frontend en --auto-save

Se recorrerá todos los archivos php de nuestra aplicación (código y templates) y sacará los textos que encuentre en las funciones __().

También se puede utilizar el mismo comando de la siguiente manera:

symfony i18n:extract frontend en --auto-delete

para eliminar las cadenas de texto que ya no existen.

protected function makeTimeFromSeconds( $total_seconds )
{
    $horas              = floor ( $total_seconds / 3600 );
    $minutes            = ( ( $total_seconds / 60 ) % 60 );
    $seconds            = ( $total_seconds % 60 );

    $time['horas']      = str_pad( $horas, 2, "0", STR_PAD_LEFT );
    $time['minutes']    = str_pad( $minutes, 2, "0", STR_PAD_LEFT );
    $time['seconds']    = str_pad( $seconds, 2, "0", STR_PAD_LEFT );

    $time               = implode( ':', $time );

    return $time;
}

Espero os sea de utilidad.

Cómo pedir variables definidas

Se puede llamar a la función estática get del objeto sfConfig para solicitar cualquier variable definida pasándo dos valores. El primero indica el nombre de la variable solicitada y el segundo, el valor que retornará en caso de no existir dicha variable.

sfConfig::get('sf_config_variable', 'The default value'); // The default is optional

Además de las variables que symfony trea configuradas por defecto, podemos añadir nuestras propias variables. Esto se hace en los archivos app.yml. Tenemos un app.yml global para todas las aplicaciones y módulos de nuestro proyecto localizado en:

/path/to/project/[PROJECT_NAME]/config/app.yml

y otro para cada una de las aplicaciones:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config/app.yml

NOTA! Si existen dos variables con el mismo nombre en el app.yml global y en el de aplicación, este último valor sobreescribirá el valor global.

Para solicitar una variable definida en uno de estos archivos app.yml devemos añadir app_ al nombre de la variable como se muestra en el siguiente ejemplo:

sfConfig::get('app_sf_config_variable');

Si en el archivo app.yml definimos la variable en cascada, como por ejemplo:

all:
  admin:
    email: admin@mail.bla

Deberemos acceder a ella añadiendo los diferentes niveles en la llamada:

sfConfig::get('app_admin_email');
También podemos acceder a los valores configurados en settings.yml añadiendo el prefijo “sf_” al valor que queremos recuperar.

Variables definidas por Symfony Framework

sf_symfony_lib_dir

Path real a la carpeta lib del framework:

/usr/share/php/symfony/symfony12/lib

Project Structure and Layout

sf_root_dir

Path a la raiz del projecto:

/path/to/project/[PROJECT_NAME]

sf_apps_dir

Path a la carpeta “apps” del proyecto:

/path/to/project/[PROJECT_NAME]/apps

sf_lib_dir

Path a la carpeta “lib” del proyecto:

/path/to/project/[PROJECT_NAME]/lib

sf_log_dir

Path a la carpeta “log” del proyecto:

/path/to/project/[PROJECT_NAME]/log

sf_data_dir

Path a la carpeta “data” del proyecto:

/path/to/project/[PROJECT_NAME]/data

sf_config_dir

Path a la carpeta “config” del proyecto:

/path/to/project/[PROJECT_NAME]/config

sf_test_dir

Path a la carpeta “test” del proyecto:

/path/to/project/[PROJECT_NAME]/test/

sf_doc_dir

Path a la carpeta “doc” del proyecto:

/path/to/project/[PROJECT_NAME]/doc

sf_plugins_dir

Path a la carpeta de “plugins” del proyecto:

/path/to/project/[PROJECT_NAME]/plugins

sf_cache_dir

Path a la carpeta “cache” del proyecto:

/path/to/project/[PROJECT_NAME]/cache

sf_web_dir

Path a la carpeta pública “web”:

/path/to/project/[PROJECT_NAME]/web

sf_upload_dir

Path a la carpeta pública de “uploads”:

/path/to/project/[PROJECT_NAME]/web/uploads

Application Information

sf_app

El nombre de la aplicación en la que está el archivo, como por ejemplo “frontend” o “backend”.

sf_environment

Entorno de desarrollo actual como por ejemplo “dev”.

sf_debug

Devuelve el estado actual del modo debug. Puede estar activado “1″ o desactivado “0″.

Application Structure and Layout

sf_app_dir

Path a la carpeta de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]

sf_app_config_dir

Path a la carpeta “config” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config

sf_app_lib_dir

Path a la carpeta “lib” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/lib

sf_app_module_dir

Path a la carpeta “modules” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules

sf_app_template_dir

Path a la carpeta “templates” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/templates

sf_app_i18n_dir

Path a la carpeta “i18n” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/i18n

Cache Structure and Layout

sf_app_base_cache_dir

Path a la carpeta de la aplicación actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]

sf_app_cache_dir

Path a la carpeta de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev

sf_template_cache_dir

Path a la carpeta “template” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/template

sf_i18n_cache_dir

Path a la carpeta “i18n” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/i18n

sf_config_cache_dir

Path a la carpeta “config” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/config

sf_test_cache_dir

Path a la carpeta “test” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/test

sf_module_cache_dir

Path a la carpeta “modules” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/modules

Application Settings

sf_error_404_module

Módulo que ha hecho saltar el error 404.

sf_error_404_action

Acción que ha hecho saltar el error 404.

sf_logging_enabled

Valor boleano que nos indica si el loggin de la web está activo “1″ o no “0″.

sf_escaping_strategy

Valor boleano que indica si la clase sfView está usando Escaping Strategy “1″ o no “0″.

sf_no_script_name

Valor boleano que indica si la aplicación requiere nombre de script.

sf_csrf_secret

La clave CSRF secreta configurada en la aplicación.

También:

Se puede acceder a la información del actual contexto con las siguientes funciones:

sfContext::getInstance()->getActionName();

Devuelve el nombre de la acción actual. También puede llamarse desde los templates con $this->getActionName().

sfContext::getInstance()->getModuleName();

Nombre del módulo actual. También puede llamarse desde los templates con $this->getModuleName().

sfContext::getInstance()->getModuleDirectory();

Path al directorio del módulo actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules/[MODULE_NAME]

Partiendo de un estudio de Yahoo! que dice que el 80% del tiempo de carga de una web corresponde al lado del cliente, podemos seguir una serie de reglas que aumentarán significativamente la percepción de velocidad del usuario.

1. Aumentar el tiempo de expiración de los elementos cacheados que no varían como CSS o JavaScript: Para forzar la carga de los mismos cuando haya cambios, podemos añadir el md5 del contenido del fichero como parámetro, así el navegador lo recargará cuando cambie el hash. Ej: style.css?hash=f9d35dcf65d8f67e288ae2f12fc069f7

2. No colocar código JavaScript o estilos inline: es mejor colocarlos como ficheros externos fácilmente cacheables, de este modo evitaremos descargar todo el html por un cambio de estilo.

3. Reducir el número de ficheros externos: Los navegadores sólo pueden aceptar dos descargas simultaneas de un mismo dominio, si unimos nuestras librerías JavaScript y nuestros CSS en un único archivo evitaremos dilatar innecesariamente el tiempo de descarga.

4. Usar subdominios diferentes para las imágenes y para los elementos estáticos: Conseguiremos así descargar 8 elementos de manera simultánea y reducir la carga de la web. Si además podemos optimizar un apache aparte para servir las imágenes, conseguiremos un mejor rendimiento al servirlas.

5. Compactar los ficheros JavaScript: Existen programas gratuitos como YUI Compressor que comprimen los archivos JavaScript consiguiendo resultados de hasta el 50%.

6. Utilizar compresión en el servidor: Los servidores modernos como Apache son capaces de comprimir la información antes de servirla, posteriormente los navegadores actuales como Explorer o Firefox la descomprimen de manera transparente al usuario.

7. Fomentar el uso de imágenes con muchos sprites: Estas son imágenes grandes que contienen muchas imágenes pequeñas. Según lo comentado en el punto 3 tardaremos mucho menos en descargar una imágen con 50 sprites que 50 sprites de manera individual. Posteriormente utilizaremos CSS para definir la sección de imágen que se mostrará.

8. Mover los CSS al <head>: Navegadores como Explorer no renderizan la web hasta que no tienen todos los CSS, si los colocas en la cabecera podrá empezar antes a mostrar la web.

9. Mover los JavaScript al final de la página: Hasta que un fichero JavaScript no se ha leido completamente el navegador no continua con la carga. Si los movemos al final de la página este se estará cargando cuando el usuario ya está navegando por la web.

10. Evitar llamadas duplicadas a JavaScript y CSS: Si el navegador encuentra un fichero JavaScript para la carga hasta que este se ha leido completamente, si posteriormente vuelve a encontrar una llamada al mismo JS, volverá a parar la carga hasta que se haya leido.

Vía | Optimización aplicaciones PHP

Lo primero que debemos hacer es pensar en que necesitamos para su correcto funcionamiento, así que, manos a la obra.

Como sabemos, una caché es un sistema al que le pasamos un objeto X y él lo almacenará en su sistema de una manera determinada, por lo tanto, necesitaremos una función que dado un identificador único y unos datos, guardará la información. Además de esto, necesitamos indicarle un tiempo de vida (ttl) a esa información cacheada, sino estaremos devolviendo eternamente el valor almacenado.

Un concepto que nos puede resultar interesante es el de caché de grupo. Imaginemos que tenemos un sistema que va cacheando información de nuestra base de datos; tenemos una tabla user y una tabla user_profile y cacheamos los resultados de ambas tablas por separado. Imaginemos también que por temas de LOPD el usuario solicita que eliminemos todos sus datos de nuestras máquinas, así que eliminaremos el registro de la tabla user y user_profile y procederemos a eliminar el cacheo de los datos de cada tabla por separado. Si tuviesemos agrupada la información de usuario, con una única llamada a la función remove y pasándole el identificador de grupo, eliminará la caché de ambas tablas.

A medida que vaya explicando cada función, os pondré el resultado final para que os hagais una idea de como va quedando el código:

    public function save ( $id, $group_id = 'default', $data, $ttl = self::CACHE_TTL )
    {
        if ( $this->caching )
        {
            $this->set_file_routes( $id, $group_id );

            // If the directory don't exists, I create.
            if ( !is_dir ( $this->file_path ) )
            {
                if ( !mkdir ( $this->file_path, 0777, true ) )
                {
                    return false;
                }
            }

            if ( !is_array ( $data ) && !is_object( $data ) )
            {
                $data = array ( $data );
            }

            // Serialize data for caching.
            $data = serialize ( $data );

            // I get a hash to check integrity in the future.
            $hash = md5 ( $data );

            $meta['expiration_time']    = time () + $ttl;
            $meta['integrity']          = $hash;
            $meta['data']               = $data;

            // Serialize meta info to put in a file.
            $data    = serialize ( $meta );

            return file_put_contents ( $this->file, $data, LOCK_EX );
        }

        return false;
    }

A su vez, debemos poder recuperar los objetos almacenados en un futuro, así que también programaremos una función que dado un identificador y un identificador de grupo, devolverá unos datos get($id, $group_id). El tener que pasar el identificador de grupo en esta función es debido a que las rutas de almacenamiento se generan a partir de ambos identificadores.

    public function get ( $id, $group_id = 'default' )
    {
        if ( $this->caching )
        {
            $this->set_file_routes ( $id, $group_id );

            if ( !file_exists ( $this->file ) )
            {
                return false;
            }

            $meta    = file_get_contents ( $this->file_path . $this->file_name );
            $meta    = unserialize ( $meta );

            $check_expiration   = $this->check_expiration ( $meta['expiration_time'] );
            $check_integrity    = $this->check_integrity ( $meta['integrity'], $meta['data'] );

            // Expiration and integrity control.
            if ( $check_expiration && $check_integrity )
            {
                $data = unserialize ( $meta['data'] );

                return $data;
            }
            else
            // Clean the expired or not correct caché.
            {
                $this->remove ( $id, $group_id );

                return false;
            }
        }

        return false;
    }

Como último elemento fundamental, necesitaremos poder borrar unos datos de la caché en caso de que ya no sean válidos porque se han modificado o borrado, así que crearemos una función que dado un identificador y un identificador de grupo, elimine el objeto cacheado. A esta función la llamaremos remove($id, $group_id).

    public function remove( $id, $group_id = 'default', $group_level = false )
    {
        $this->set_file_routes( $id, $group_id );

        // Don't remove the 'default' group
        if ( $group_level && $group_id != 'default' )
        {
            if ( !$this->group_path || empty ( $this->group_path ) )
            {
                return false;
            }

            return $this->del_tree ( $this->group_path );
        }
        // Check that the file exists and delete the file cached folder
        elseif ( $this->file_path && !empty ( $this->file_path ) )
        {
            return $this->del_tree ( $this->file_path );
        }
        else
        {
            return false;
        }
    }

Como sabemos, la caché guarda los objetos durante un tiempo determinado y una vez ha pasado ese tiempo, el objeto se considera inservible, por lo tanto añadiremos una función check_expiration() que nos dirá si el objeto está caducado.

private function check_expiration ( $expiration_time )
{
return ( time() < $expiration_time );
}

¿Qué pasa si cuando estoy almacenando los datos hay un problema de escritura y los datos se almacenan mal? Podría suceder que los datos almacenados esten corruptos, y todas las devoluciones de dicho objeto fueran defectuosas. Para comprobar que los datos guardados no están corruptos, crearemos una función check_integrity().

    private function check_integrity ( $read_hash, $serialized_data )
    {
        $hash = md5 ( $serialized_data );

        return ( $read_hash == $hash );
    }

Además de estas funciones, crearemos varias constantes que definirán los valores de configuración del sistema como pueden ser el tiempo de vida (ttl) de un objeto cacheado por defecto o el directorio en el que se guardará la caché.

    // Path to cache dir.
    const CACHE_DIR = 'cache/';

    // Max. time to life of this cache.
    const CACHE_TTL = '3600';

    // Extension to use in cache files.
    const CACHE_EXT = '.cache';

En el código se llama a las funciones get_status() y set_status() que sirven comprobar si está activo el sistema de cacheo y habilitar/deshabilitar respectivamente. set_file_routes() crea las rutas en las que se almacenará los datos cacheados y get_key() crea hashes a partir de un identificador. Por último, del_tree() nos ayudará a eliminar un directorio de manera recursiva.

    public function get_status ()
    {
        return $this->caching;
    }

    public function set_status ( $status )
    {
        $this->caching = $status;
    }

    private function set_file_routes ( $id, $group_id )
    {
        $key_name    = $this->get_key ( $id );
        $key_group   = $this->get_key ( $group_id );

        $level_one = $key_group;
        $level_two = substr ( $key_name, 0, 4 );

        $this->group_path   = self::CACHE_DIR . $level_one . '/';
        $this->file_path    = self::CACHE_DIR . $level_one . '/' . $level_two . '/';
        $this->file_name    = $key_name . self::CACHE_EXT;
        $this->file         = $this->file_path . $this->file_name;
    }

    private function get_key ( $id )
    {
        return md5 ( $id );
    }

    private function del_tree ($dir)
    {
        if ( empty ( $dir ) )
        {
            return false;
        }

        if ( !file_exists ( $dir ) )
        {
            return true;
        }

        if ( !is_dir ( $dir ) || is_link ( $dir ) )
        {
            return unlink ( $dir );
        }

        foreach ( scandir ( $dir ) as $item )
        {
            if ( $item == '.' || $item == '..' )
            {
                continue;
            }

            if( is_dir ( $dir . $item ) )
            {
                $this->del_tree ( $dir . $item . '/' );
            }
            else
            {
                unlink ( $dir . $item );
            }
        }

        return rmdir ( $dir );
    }

Puedes descargarte el archivo final desde aquí cache.class.php.

Aunque esta caché es perfectamente funcional, este ejercicio nos sirve para entender un poco más el funcionamiento de un sistema de caché. Si queremos implementar uno en nuestra aplicación, os recomiendo mirar CacheLite (si nuestra aplicación es pequeña), APC o Memcached (si nuestra aplicación es grande y/o con servidores balanceados).

¿Qué es un captcha?

Los captcha son esas “molestas” cajas con textos a menudo casi ilegibles que nos encontramos a la hora de registrarnos en una web, insertar un comentario blog…

La función de un captcha es la de asegurarnos que quien está realizando una acción, como las mencionadas anteriormente, sea una persona y no un programa (comunmente llamados bots). Para una máquina, el reconocimiento de textos distorsionados dentro de imágenes es un proceso bastante complejo (aunque no imposible), por lo tanto al colocar este tipo de sistemas en el registro de hotmail, por poner un ejemplo, estaremos eliminando el 99,9% de los registros automáticos por programas que después utilizan la cuenta para enviar spam.

¿Por qué ha comprado Google la empresa ReCaptcha?

Los emprendedores que iniciaron ReCaptcha pensaron que este sistema, además de ser muy útil para webmasters, podría ser también muy útil para que los usuarios del sistema fueran digitalizando poco a poco libros previamente escaneados y pasados por un OCR (software de reconocimiento óptico de caracteres).

Los OCR tienen muy buenos resultados en libros actuales con los caracteres bien definidos, pero en el caso de libros antiguos o en mal estado puede cometer un porcentaje muy elevado de errores:

La idea es mostrar en los sistemas de captcha dos palabras, una conocida que será la encargada de validar correctamente el texto introducido por el usuario, y otra desconocida que el usuario se encargará de traducir.

Google ha visto en este sistema un filón para dar impulso a su macro proyecto Google Books, proyecto que pretende digitalizar y poner a disposición de todos los internautas miles de libros para que puedan ser descargados de manera gratuita.

Hace algún tiempo, os hablaba de la importancia de usar Unit Testing en nuestros desarrollos para tender localizados los posibles errores en cada una de nuestras funciones y, de ese modo, hacer un cambio en cualquier función no nos será crítico, ya que el test nos informará si la función está devolviendo los resultados esperados para cada cualquier.

Pero ¿y si al desarrollar el test me he dejado algún punto por comprobar? A menudo, tener una covertura del 100% resulta complicado debido al error humano, pero una vez detectado un error, debemos solventarlo y modificar el test para que no vuelva a darse ese error, y yendo un poco más allá, ¿por qué no pensar en los posibles errores que puede tener la función que desarrollemos antes de programarla? y ya que los hemos pensado, ¿por qué no realizar el test aunque todavía no hayamos desarrollado la función en questión? Pues precisamente, esa es la idea del Test-Driven Development (TDD a partir de ahora).

En resumen, podemos decir que el TDD es una práctica a la hora de programar que implica el desarrollo del test unitario antes de haber picado una sola línea del código de la función a testear… Pero, ¿qué ventajas tiene? ¿cuál es el workflow de esta práctica?

Ventajas de usar TDD

Generalmente, somos escépticos a la hora de adoptar una nueva práctica como el Unit Testing o más aún, algo que parece tan ilógico como TDD, pues es costoso en tiempo para el programador el desarrollo del test (cuando lo que nos gusta es desarrollar cosas útiles y no aparentemente inútiles como una prueba) e implica tener que pensar un rato antes de desarrollar. Sin embargo, seguir esta forma de programación tiene una serie de ventajas que hacen decantar la balanza a su favor:

1. Código de mayor calidad: El hecho de desarrollar el test antes que la función a ser testeada, nos obliga a pensar en como será la función, ordenarla y ver que errores podrá haber. Esto hará que en el momento de empezar a picar la función, tengamos muy claro que es lo que queremos hacer y como, por tanto, el código será más limpio y concreto.
2. Desacoplo del código: Cuando piensas en como será la función de manera que pueda ser testeada, te ves obligado a separar el bloque central en bloques más pequeños (que también serán testeados). De este modo, una función que podría ser muy compleja, acaba dividida en tres más pequeñas y fáciles de testear.
3. Disminución del tiempo de desarrollo: Independientemente del coste en tiempo de desarrollar el test (pues doy por hecho de que estás convencido de su utilidad y lo desarrollarás igualmente), el desarollo de la función es más rápida porque ya hemos pensado que y como lo vamos a hacer, simplemente hay que picarlo.
4. Disminución del número de líneas: TDD lleva implicita un proceso de refactorizando constante hasta que la función está acabada, gracias a eso, es fácil darnos cuenta que hemos complicado un proceso y lo podemos optimizar.

Workflow

Antes de comenzar el ciclo de trabajo se debe definir una lista de requerimientos. Luego se comienza el siguiente ciclo:

1. Elegir un requerimiento: Se elige de una lista el requrimiento que se cree que nos dará mayor conocimiento del problema y que a la vez sea fácilmente implementable.
2. Escribir una prueba: Se comienza escribiendo una prueba para el requerimiento. Para ello el programador debe entender claramente las especificaciones y los requisitos de la funcionalidad que está por implementar. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces.
3. Verificar que la prueba falla: Si la prueba no falla es porque el requerimiento ya estaba implementado o porque la prueba es errónea.
4. Escribir la implementación: Escribir el código más sencillo que haga que la prueba funcione. Se usa la metáfora “Déjelo simple” (”Keep It Simple, Stupid” (KISS)).
5. Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona correctamente.
6. Eliminación de duplicación: El paso final es la refactorización, que se utilizará principalemente para eliminar código duplicado. Se hacen de a una vez un pequeño cambio y luego se corren las pruebas hasta que funcionen.
7. Actualización de la lista de requerimientos: Se actualiza la lista de requerimientos tachando el requerimiento implementado. Asimismo se agregan requerimientos que se hayan visto como necesarios durante este ciclo y se agregan requerimientos de diseño (P. ej que una funcionalidad esté desacoplada de otra).

Resumiendo en una imágen:

Cada vez que recibimos una llamada, cogemos el listín, realizamos la búsqueda y facilitamos el número encontrado al usuario. Al poco tiempo, nos damos cuenta que la gente suele pedir los teléfonos de los mismos restaurantes y comercios una y otra vez, así que cogemos una libreta pequeña y vamos anotando los números de teléfono que nos solicitan ordenados alfabéticamente para poder acceder a ellos de manera más rápida la próxima vez… felicidades, acabas de crear una caché!

Sin embargo, el uso de una caché tiene un pequeño handicap; imaginemos que nos llama un usuario y nos solicita el teléfono de un comercio. Cogeremos nuestra libreta, lo buscaremos y si no lo encontramos recurriremos al listín, realizaremos la búsqueda en él y facilitaremos el número al usuario. En este momento estamos aumentando ligeramente el tiempo de búsqueda de un número, por ese motivo, la información debe almacenarse en la caché de manera eficiente, y a partir de aquí hay mil teorías sobre como y cuando almacenar la información en una caché.

En resumen y dicho de una manera más técnica un sistema de caché es una zona de memoria en la que se almacenan copias de un objeto original pero al que es mucho más rápido acceder.

La Caché en la programación:

A la hora de construir una aplicación medianamente grande, se hace imprescindible el cachear cierta información para conseguir un rendimiento óptimo. Un sistema de caché correctamente implementado puede reducir el número de servidores y evitar la sobrecarga de las máquinas.

Se pueden utilizar diferentes tipos de caché en función del tipo de datos que queramos guardar. Centrándome en la programación web, podemos encontrar:

• Caché SQL: Para almacenar en memoria el resultado de ciertas consultas recurrentes y poder así descargar la base de datos. MySQL 5.0 Server tiene soporte nativo para este tipo de caché pero se debe activar expresamente.
• Cachéo de Objetos: En este tipo de caché podemos almacenar objetos, arrays, textos, resultados de funciones, resultados de base de datos… Podremos almacenar cualquier tipo de información soportada por el sistema de cacheo e indicarle el tiempo de expiración. Ejemplos de este sistema de caché para PHP son APC (Alternative PHP Cache) o Memcached.
• Cacheo de templates: Puede ser de gran utilidad el cachear los resultados HTML al invocar diferentes URL, por ejemplo, el sistema de templates Smarty integra un sistema de caché que permite devolver el HTML de manera eficiente.

Por qué no debo usar SQLCaché y APC o Memcached?

La caché implementada por MySQL tiene una política en la gestión de su caché muy estricta. Cada vez que hay una escritura en una tabla, elimina toda la caché asociada a dicha tabla y a partir de ese momento, se debe volver a regenerar, por tanto, la entrada de un registro en la tabla implica insertar el registro, regenerar los indices, cachear los datos y por último devolverlos (aumentamos el tiempo de la consulta). Dada esta premisa, podemos extraer la conclusión de que es interesante activar SQLCaché en una base de datos con muchas lecturas y pocas escrituras.

A su vez, implementando un sistema de cacheo como APC o Memcached para almacenar la información devuelta por la base de datos dada una consulta, reduce considerablemente el número de lecturas a base de datos.

Por ese motivo, el tener activados estos dos tipos de caché simultaneamente, no solo no mejora el rendimiento de nuestra aplicación sino que lo empeora.

Es contraproducente usar APC y Memcached de manera simultanea?

APC proporciona dos tipos de cacheo. Por un lado, evita el continuo compilado de un script PHP, pues a pesar de ser un lenguaje interpretado, PHP pasa todo script a un lenguaje entendible por la máquina antes de ejecutarlo ¿por qué recompilar cada vez el script si no ha cambiado desde la última ejecución? A partir de la versión 6 de PHP parece ser que APC estará activado de forma nativa. Por otra parte, podemos almacenar objetos con el uso de las funciones apc_add y apc_store.

Memcached proporciona un servicio web desacoplado y altamente escalable. El 95% del top ten y el 80% del top 50 de Alexa utiliza Memcached precisamente por la facilidad de implementación y de añadir nuevas máquinas para cachear información. APC tiene un rendimiento ligeramente superior, pero si tenemos un sistema con servidores balanceados no podemos compartir la caché entre todas las máquinas porque está vinculada al host, por ese motivo la balanza se ha ido decantando hacia el uso de Memcached.

Si bien, puede ser interesante utilizar una combinación de ambas, APC para el precompilado de nuestro código y Memcached para almacenar la información de base de datos y descargar así nuestro motor de bd.

Ya se ha abierto la venta anticipada de entradas a un precio increiblemente bajo: 25€ un día y 40€ los dos. Puedes adquirir las entradas desde la web oficial.

Según anuncian: “Este año el evento viene cargado de muchas e interesantes novedades: dos días de duración (Viernes y Sábado), distintas actividades entremezcladas (ponencias teóricas, talleres prácticos, concursos de programación, etc.), dos líneas de idioma (español e inglés), nuevos y potentes patrocinadores, más celebridades invitadas, divertidos regalos y mucho más!”

Realmente este año los chicos de PHPBarcelona se han puesto las pilas, pues en el cartel de charlas aparecen nombres tan importantes como Rasmus Lerdorf (Uno de los creadores de PHP), Fabien Potencier (Lead Developer de Symfony), Derick Rethans (XDebug) y Sebastian Bergmann (Creador de PHPUnit).