Los usuarios de Ubuntu, pueden encontrarse con un problema al hacer una llamada a la función setlocale() encargada de asignar el idioma correcto para, por ejemplo, llamar a la función getText() y que recoja las traducciones en el idioma correcto.

El problema está en que únicamente podemos cargar los idiomas que están presentes en el sistema operativo y si intentamos cargar uno diferente, setlocale() nos devolverá siempre false.

Podemos saber los idiomas cargados en el sistema operativo mediante el comando:

locale -a

Esto nos devolverá un listado similar a este:

C
en_GB.utf8
en_IN
en_NG
en_US.utf8
POSIX

Si estámos intentando cargar el idioma es_ES (como era mi caso), le resultará imposible… la solución, instalar los idiomas que necesitamos lanzando el comando:

apt-get install language-pack-es-base

Posteriormente, reiniciaremos Apache:

/etc/init.d/apache2 reload

Y le indicaremos a nuestro programa que cargue el idioma con el mismo nombre que lo encontramos en nuestro sistema, es decir, en mi caso:

setlocale( LC_MESSAGES, “es_ES.UTF8″ );

Y con esto conseguiremos que nuestro programa quede internacionalizado de manera correcta.

Una sencilla función que dado un número de segundos, nos devuelve el tiempo en formato hh:mm:ss

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.

Aquí os dejo algo de información sobre como solicitar variables de configuración en symfony además de un listado muy útil con todas las variables que Symfony trae predefinidas.

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]

Manuel Aguilar publicó una magnífica presentación sobre cómo optimizar aplicaciones Web dada en la PHP Barcelona Conference 2008 y he considerado interesante recopilar a modo de resumen las ideas más importantes de ese artículo, en cualquier caso, recomiendo la lectura del mismo para recoger toda su esencia y ampliar información.

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

Hace unos días, os comentaba que es una caché y como entenderla en el marco de la programación web. Para seguir con el aprendizaje de este sistema, he desarrollado una pequeña clase que permite cachear información (strings, arrays, resultados de base de datos, objetos…) en nuestra máquina y descongestionar así el motor de base de datos, por poner un ejemplo.

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).

Vamos a ver que es una caché con un ejemplo muy ilustrativo que leí hace algún tiempo. Supongamos que estamos trabajando en una centralita que facilita números de teléfono de un pueblo relativamente pequeño; para ello, tenemos un listín telefónico común con todos los teléfonos del pais.

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.

Después del éxito obtenido la pasada edición, el grupo PHPBarcelona ha vuelto a organizar una conferencia para este año. El lugar de encuentro será el CitiLab de Cornellà los días 30 y 31 de Octubre.

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).

Veo en el blog Distro-Geek una viñeta que define a la perfección el modus operandi de muchas empresas a la hora de diseñar una aplicación… lamentablemente, esto pasa más frecuentemente de lo recetado por el médico.

Code golf es un adictivo pasatiempos para programadores en el que el objetivo es conseguir una solución a un sencillo problema con el menor número de teclas picadas al programarlo (o lo que es lo mismo el archivo con menor peso en bytes es el que gana).

En la web se plantean diferentes retos y a partir de ahí se van marcando los mejores resultados a medida que los usuarios van subiendo sus scripts. Puedes subir tu mini-programa en uno de los siguientes lenguajes: PERL, PHP, Phyton o Ruby.

Si teneis dudas sobre probar este pasatiempos, os doy un ejemplo del tipo de programas que suelen pedir:

Home On The Range

Diseñar un programa simple que dada una ristra de números, sustituya las secuencias numéricas seguidas por el primer y último número de la secuencia separadas por un guión. Dicho así suena complicado, pero es sencillo si vemos un ejemplo de la salida por pantalla:

• “1 2 3″ => “1-3.”
• “1 2 3 5 7 8″ => “1-3, 5, 7-8.”
• “1 3 4 5 7″ => “1, 3-5, 7.”

Además de un entretenido juego, Code Golf nos sirve de entrenamiento para optimizar nuestro código a la hora de trabajar en nuestros desarrollos profesionales.

Probádlo y juzgad.

Los desarrolladores del motor de PHP llevan ya varios meses trabajando en la versión 6. De momento no parece que vaya a ver la luz en breve, pues acaban de liberar la versión 5.3 para postergar en la medida de lo posible la aparición de la nueva versión. En cualquier caso, es interesante estar al día e ir preparando nuestros desarrollos actuales para las posibles incompatibilidades con la nueva versión.

Recientemente preguntaban a Zeev Suraski, co-fundador de Zend Technologies Inc. sobre la versión 6 de PHP de la que se lleva algún tiempo hablando pero que parece que no acaba de ver la luz. En la entrevista, Zeev nos comentaba:

PHP6 es un proyecto mucho más difícil que PHP4 y 5 principalmente por dos razones:

• La cantidad de código PHP que hay afuera, es tan inmensa.
• Cada pequeña incompatibilidad que uno introduce se convierte en un horrible dolor de cabeza para mucha gente. Y combinado con la principal cosa que queremos hacer con PHP6, que es la introducción de soporte nativo para Unicode, es imposible no introducir una cantidad significativa de incompatibilidades en el lenguaje. No sé cómo va a resultar esto, estoy siendo completamente honesto.

Según su prespuesta, parecía lógico preguntarle sobre como de complicada se prevé que sea la migración de una plataforma PHP5 actual a la nueva versión:

La migración de la versión 4 a la versión 5 fue bastante exitosa. Tomó algunos años, pero hoy PHP5 ya es mucho más popular de lo que la versión 4 jamás lo fue. Hemos tomado la decisión de no apurar la transición, así que actualmente nos hemos concentrando en PHP 5.3.

En esta versión que ya ha visto la luz, hemos agregado algunas de las características que originalmente estaban planeadas para PHP6, como por ejemplo, los espacios de nombres (namespaces). Probablemente pase bastante tiempo antes de que PHP6 seará liberado.

¿Qué novedades introduce PHP6?

El 11 de Noviembre del 2005 el núcleo central de desarrolladores de PHP se encontraron en París para decidir el camino que iva a tomar PHP6. Los principales cambios que se plantearon implementar son:

• Unicode: Es el cambio más relevante en esta nueva versión. En PHP5 se puede activar Unicode bajo petición, pero en este caso, se dispara el consumo de recursos debido a que PHP tiene que almacenar todas las variantes de funciones, métodos y clases tanto en Unicode como en no-Unicode en la tabla de símbolos.
• Register Globals eliminadas: Cualquier variable global registrada que aparezca en el código nos devolverá un error E_CORE_ERROR y un enlace a la documentación en la que se detalla porqué es contraproducente utilizarlo. Para la versión actual 5.3 ya han sido marcadas como deprecated.
• Magic Quotes eliminadas: El bajo rendimiento de magic_quotes, magic_quotes_sybase y magic_quotes_gpc ha provocado la decisión de colocarlas como deprecated en la versión actual 5.3 y de eliminarlas definitivamente para la versión 6.
• Modo seguro eliminado: La razón es que aparentemente daba una idea errónea de que hacía a PHP seguro, cuando en realidad no mejoraba en nada la seguridad, si bien, open_basedir se conservará.
• ‘var’ y ‘public’ tendrán el mismo significado: Con PHP6 una variable ‘var’ va a considerarse ‘public’ adquiriendo idéntico significado. Desaparecerá el warning mostrado al usarlo aunque tengamos configurado  el nivel de error como E_STRICT.
• Return by Reference devolverá un error: Tanto $foo =& new StdClass() como function &foo producirán ahora un error E_STRICT.
• Compatibilidad zend.ze1 eliminada: ze1 intentó conservar el viejo comportamiento de PHP4, pero aparentemente “ni siquiera funciona al 100%”, así que será eliminado por completo y dará un error E_CORE_ERROR si se detecta.
• Se abandona el soporte de Freetype1 y GD1: Bibliotecas totalmente obsoletas y que no tiene sentido seguir manteniendo.
• FastCGI siemper activado: El código de FastCGI será renovado y estará siempre disponible para la CGI SAPI, no podrá ser desactivado.
• Register Long Arrays eliminado: En PHP6 sólo $_POST y $_GET serán aceptados, HTTP_*_VARS va a devolver un error.
• Las extensiones XMLReader y XMLWriter movidas: Se moverán al núcleo de distribución y permanecerán activas por defecto.
• Extensión ereg eliminada: La introducción de las librerías ICU (necesarias para el tema de Unicode) han motivado el movimiento de la extensión ereg a PECL y por lo tanto será eliminada de PHP. A partir de ese momento se deberán usar la nueva extensión de expresiones basadas en ICU.
• Fileinfo por defecto: La extensión Fileinfo se verá desplazada al núcleo de la distribución y estará activada por defecto.

Si bien, a pesar de que parece que la línea seguída por los desarrolladores es esta que se comenta en el artículo, no se podría asegurar al 100% que la versión 6 definitiva incorpore todos los cambios mencionados o no aparezca algun otro importante no descrito.

Vía | Maestrosdelweb.com