viernes, 11 de diciembre de 2015

PHP 7.0.0 liberado

Acaba de hacerse oficial el lanzamiento de PHP 7.0.0. La nueva versión del lenguaje incluye numerosas mejoras y sobre todo un aumento de rendimiento considerable. Algunas de las nuevas características de PHP 7 son:

  • Tipo de retorno en las funciones: Por fin se podrá declarar que devuelve una función o método. Esta es una característica que siempre he echado en falta en PHP. Sobre todo cuando se diseñan interfaces o clases abstractas, poder indicar que debe devolver un método es algo muy útil. Ejemplos.
  • Declaración de tipos escalares: Se trata de poder definit el tipo de una variable para int, float, string y bool. Esto es útil por ejemplo para definir los parámetros de una función o método. También se definen dos niveles de exigencia: normal y estricto. El segundo se controla mediante la directiva declare(strict_types=1); (en la primera línea del script) e implica un control estricto de los tipos escalares provocando errores de tipo E_RECOVERABLE_ERROR en caso de incumplimiento. Ejemplos.
  • Nuevo operador ?? (coalesce): El operador de doble interrogación ?? permite devolver un valor específico si una variable no está definida. Por ejemplo $username = $_GET('username') ?? null; sería equivalente a $username = isset($_GET('username')) ? $_GET('username') : null;. Ejemplos.
  • Nuevo operador de comparación <=> (spaceship): La operación $a <=> $b devuelve 0 si $a y $b son iguales; devuelve -1 si $a es menor que $b; y devuelve 1 si $a es mayor que $b. Es decir lo mismo que strcmp() pero no limitado a strings. Funciona con variables de tipo int, float, string, array e incluso object. Ejemplos.
  • Sintaxis uniforme de variables: Se ha añadido soporte completo a construcciones de variables complejas, pero con consistencia. Por ejemplo [$obj1, $obj2][0]->prop, $foo->bar()(), (function() { ... })(), "string"->toLower(), etc. Ejemplos.
  • Solución de errores históricos.

Enlaces

miércoles, 2 de diciembre de 2015

Ya está aquí Symfony 3

SensioLabs ha anunciado esta semana la liberación de dos nuevas versiones del popular framework Symfony: La 2.8, que es la última versión de Symfony 2 y cuenta con soporte extendido; y la esperada versión 3.0 que inaugura la tercera iteración del framework PHP.

La versión 2.8 cuenta con retrocompatibilidad con las anteriores versiones de Symfon 2, mientras que la versión 3.0 elimina todas las funciones obsoletas (deprecated) que se han ido sustituyendo en las sucesivas versiones de Symfony 2. Es decir en esencia las versiones 2.8 y 3.0 de Symfony son idénticas excepto que la versión 2.8 mantiene la retrocompatibilidad con las versiones anteriores mientras que la 3.0 no lo hace.

La liberación de las nuevas versión hace que actualmente haya cinco versiones de Symfony con soporte:

Versión LTS Liberación Soporte bugs Soporte seguridad
2.3 x MAY-2013 MAY-2016 MAY-2017
2.6 NOV-2014 JUL-2015 ENE-2016
2.7 x MAY-2015 MAY-2018 MAY-2019
2.8 x NOV-2015 NOV-2018 NOV-2019
3.0 NOV-2015 JUL-2016 ENE-2017

La siguiente versión LTS (Long Time Suport) de Symfony está previsto que sea la 3.3 y la fecha prevista para su liberación es Mayo de 2017. Por ello si hay que empezar un proyecto nuevo con Symfony lo recomendable por ahora es usar la versión 2.8 que tiene 5 años de soporte, teniendo cuidado de no usar funciones obsoletas de Symfony 2 de forma que en el futuro sea factible realizar la migración a Symfony 3.

Enlaces

jueves, 19 de noviembre de 2015

¿Como evitar bloqueos de sesión en PHP?

PHP

Por defecto PHP escribe los datos de la sesión en un fichero en disco. La función session_start() bloquea el fichero de la sesión de forma que nadie más puede leerlo. Ese bloqueo durará hasta que se acaba la ejecución del script o hasta que se libere manualmente usando alguna de las siguientes funciones: session_abort(), session_commit(), session_destroy() o session_write_close().

El problema

La mayoría de los programadores inician la sesión al principio del script, pero la dejan abierta hasta el final. Eso en entornos con múltiples peticiones sobre la misma sesión (por ejemplo con mucho AJAX) es posible que acabe causando un cuello de botella en momentos putuales. En el momento que una petición tarde demasiado en responder (debido por ejemplo a una query complicada) las demás peticiones no podrán acceder al fichero de sesión que estará bloqueado con el resultado de un tiempo de respuesta significativamente elevado. Pero sólo en momentos puntuales.

La solución

Lo más fácil es liberar el fichero de sesión justo después del session_start(). Los datos de sesión seguirán disponibles para lectura a través de la variable superglobal $_SESSION, pero no se podrá encribir nada en la sesión.

<?php
// Start the session
session_start();

// Session is open to read/write ops
$_SESSION['latestRequestTime'] = time();

// Close the session
session_write_close();

// Now session is read-only
$user = $_SESSION['userNAme'];

Alternativas

Si no es posible cerrar la sesión justo después de abrirla (por ejemplo porque haya que escribir datos después de obtenerlos y/o procesarlos) hay algunas alternativas que pueden utilizarse: Guardar la sesión en una base de datos MySQL, ya que el motor de base de datos no bloquea la sesión, o bien guardar la sesión en algún sistema de caché como Redis, Memcache, etc.

Enlaces

jueves, 22 de octubre de 2015

Evitando el consumo excesivo de memoria con Doctrine y Symfony2

Doctrine es el ORM que utiliza el framework Symfony2. Es un producto muy completo, con muchas opciones, pero tiene un pequeño problema cuando se manejan grandes cantidades de información.


El problema

He tenido un problema con un script que mantiene sincronizadas dos bases de datos (una MySQL y otra PostgreSQL, en servidores remotos, aunque no venga al caso). Se trata de un comando de consola de Symfony2 que se ejecuta periódicamente a través de un cron. Llevaba meses funcionando bien hasta que de repente:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1454 bytes).

Vi el problema enseguida: La cantidad de datos a sincronizar ha crecido últimamente; Así que rediseñé el algoritmo para que funcionase con bloques de 500 registros en lugar de tratar de golpe todos los registros.

Pero eso no solucionó el problema.


La solución

Podría haber puesto el sufrido ini_set("memory_limit", -1) pero eso sólo haría que el proceso gastase más y más memoria del sistema. El recolector de basura de PHP no libera los objetos mientras haya referencias apuntando a los mismos y Doctrine internamente mantiene esas referencias a no ser que se liberen manualmente.

Para ello el EntityManager de Doctrine en Symfony2 cuenta con un par de funciones: detach y clear. Veamos un ejemplo:

$em = $this->getDoctrine()->getManager();
$entities = $em->getRepository('...')->findBy(array('...'));
foreach ($entities as $entity) {
    $entity->doSomething();
    // (....)
    $em->detach($entity);
    unset($entity);
}
$em->clear();

La instrucción detach desvincula una entidad del EntityManager; es decir elimina cualquier referencia a la entidad. Los cambios realizados en la entidad, incluyendo su borrado, no se sincronizarán con la base de datos posteriormente a la desvinculación. Por su parte clear desvincula de golpe todas las entidades cargadas en el EntityManager.


Referencias

miércoles, 8 de abril de 2015

¿Como poner en producción un proyecto Symfony 2?

Symfony 2 es uno de los frameworks MVC basados en lenguaje PHP que más de moda están en los últimos tiempos. La documentación oficial de Symfony 2 es muy extensa, pero se hecha en falta una sección dedicada sobre como poner en producción un proyecto ya terminado (o una beta) en un servidor real. Lo que llamamos desplegar el proyecto (del inglés deploy).

Los requisitos de Symfony 2 no son demasiado elevados: Basta un servidor web como Apache o Nginx y PHP 5.3.3 o superior (aunque se recomienda PHP superior a 5.3.16). Siempre es recomendable aunque no obligatorio que sea un servidor dedicado sobre el que tengamos acceso root. Es perfectamente posible desplegar un proyecto Symfony 2 en un servidor compartido aunque eso sí: es necesario tener acceso al shell del servidor (vía SSH típicamente). Symfony 2 no puede desplegarse simplemente subiendo los archivos por FTP.


Conceptos previos

Cualquier proyecto Symfony 2 está compuesto por una carpeta de código fuente del proyecto (src), una carpeta de librerías externas entre las que se incluye el propio framework (vendors), una carpeta de configuración y recursos globales (app) y una carpeta frontal (web). Todas ellas son necesarias, pero no todas tienen la misma importancia.

Carpetas de un proyecto Symfony

  • app: Esta carpeta contiene la configuración del proyecto (subcarpeta app/config), pero también los recursos comunes (subcarpeta app/Resources), los logs (subcarpeta app/logs) y también la cache (subcarpeta app/cache), que es donde se crean una serie de clases autogeneradas que aceleran la ejecución del proyecto (es algo similar a tener código compilado sólo que sigue siendo PHP). En la carpeta app también está la consola que es un componente necesario para instalar el proyecto.
  • src: Esta carpeta contiene el código fuente del proyecto. Internamente el código se divide en bundles y cada bundle puede tener controladores, entidades, vistas, recursos, etc.
  • vendor: Esta carpeta contiene el código fuente de las librerías externas y bundles que usa el proyecto. Se trata de código es open-source que sus creadores ponen a disposición de los programadores para desarrollar sus propios proyectos.
  • web: Esta carpeta contiene el controlador frontal de Symfony 2 (programa app.php). Un proyecto Symfony 2 puede tener más de un controlador frontal, según los distintos entornos de ejecución que se definan: app_dev.php, app_test.php, etc. A la hora de ponerlo en explotación bastaría con el controlador frontal del entorno de producción producción. En la carpeta web también se copian automáticamente los assets del proyecto (imágenes, CSS, JS, etc.)

Entornos de un proyecto Symfony

Dentro de un único proyecto Symfony 2 se pueden definir diversos entornos; típicamente son tres, aunque pueden ser más: desarrollo (dev), pruebas (test) y producción (prod). El primero se usa para desarrollar en proyecto, el segundo es para pasar los test unitarios y funcionales y el tercero es para probar el proyecto tal y como debe funcionar en explotación.

Ojo: Nunca han que confundir los entornos de Symfony (dev, test, prod) con los entornos de una organización. Son cosas distintos. A la hora de poner en producción un proyecto Symfony 2 en un servidor real sólo tendremos en cuenta el entorno de producción. Los demás deben descartarse.

Cada entorno Symfony 2 tiene archivos de configuración diferentes en la carpeta app/config:

  • config.yml: Archivo de configuración común para todos los entornos.
  • config_dev.yml: Archivo de configuración del entorno de desarrollo de Symfony 2. Modifica la configuración de config.yml para el entorno dev. Permite por ejemplo evitar que se envíen mails al ejecutar los test.
  • config_test.yml: Archivo de configuración del entorno Symfony 2 de pruebas unitarias.
  • config_prod.yml: Archivo de configuración específico del entorno de producción.

Además del archivo de configuración puede haber otros archivos con configuración adicional:

  • security.yml: Configuración de la seguridad del proyecto Symfony 2.
  • routing.yml: Configuración de las rutas del proyecto Symfony 2.
  • routing_dev.yml, routing_test.yml, … rutas adicionales por entornos.

Por último existen dos archivos de configuración adicionales:

  • parameters.yml: Este archivo contiene la configuración dependiente de la instalación y es el único archivo que debería variar de un servidor a otro. Sirve por ejemplo para indicar la base de datos a usar, el servidor del API, el servidor de correo, etc. NUNCA debería distribuirse este archivo en una puesta en explotación.
  • parameters.yml.dist: Indica los valores por defecto del archivo “parameters.yml” y es usado por “composer.phar” para crear este último.

Por cada entorno Symfony 2 también habrá un controlador frontal en la carpeta web. Es decir que además del controlador app.php podremos tener app_dev.php y app_test.php. Si por ejemplo creamos un archivo config_beta.yml automáticamente se creará un controlador app_beta.php.

Herramientas

  • composer.phar: Herramienta para resolver dependencias en un proyecto PHP. Usado por Symfony 2 para instalar los vendor y para preparar los entornos.
  • app/console.php: Herramienta interna de Symfony 2 que permite limpiar la cache, instalar los assets y muchas más cosas.

Punto de partida

Para poner en producción un proyecto Symfony 2 hay dos puntos de partida:

  1. Partir de un repositorio (GIT, SVN, etc.)
  2. Partir de código fuente con los vendor.

Permisos

Debido a que es necesario que las carpetas app/cache y app/logs tengan permiso de escritura se recomienda que el usuario Linux que realice la instalación sea el mismo del servidor web (apache, nginx, etc). Si esto no fuera posible debería modificarse el propietario de todos los archivos de esas carpetas como paso final de la instalación o bien dar permisos de escritura sobre esas carpetas. Si esto no se hace no funcionará el proyecto.


Partiendo de un repositorio (GIT, SVN, etc.)

Pasos a seguir

  1. Copiar el proyecto desde el repositorio.
  2. Instalar los vendor.
    php composer.phar install
  3. Borrar controladores frontales y archivos de configuración sobrantes.
    rm -f app/config/*_dev.yml
    rm -f app/config/*_test.yml
    rm -f web/app_dev.yml
    rm -f web/app_test.yml
    (...)
  4. Copiar el archivo app/config/parameters.yml específico de esta instalación.
  5. Limpiar e inicializar la cache de Symfony 2.
    php app/console -e=prod cache:clear
  6. Instalar los assets del entorno de producción.
    php app/console assets:install web --symlink
    php app/console -e=prod assetic:dump
  7. Opcionalmente cambiar el propietario de las carpetas cache y logs.
    chown -R nginx:nginx app/cache
    chown -R nginx:nginx app/logs
  8. Opcionalmente dar permisos de escritura a las carpetas cache y logs.
    chmod -R a+w app/cache
    chmod -R a+w app/logs

Partiendo del código fuente completo (incluido vendor).

Lo normal es que un proyecto Symfony 2 se despliegue desde un repositorio de fuentes (GIT, SVN, etc), pero en ocasiones esto no es posible. En ese caso habrá que subir manualmente el código fuente al servidor, incluyendo la carpeta vendor.

Pasos a seguir

  1. Copiar todo el proyecto Symfony 2 a la carpeta de destino.
  2. Borrar las carpetas de “cache” y “logs”.
    rm -rf app/cache/*
    rm -rf app/logs/*
  3. Borrar controladores frontales y archivos de configuración sobrantes.
    rm -f app/config/*_dev.yml
    rm -f app/config/*_test.yml
    rm -f web/app_dev.yml
    rm -f web/app_test.yml
    (...)
  4. Copiar el archivo app/config/parameters.yml específico de esta instalación.
  5. Limpiar e inicializar la cache de Symfony 2.
    php app/console -e=prod cache:clear
  6. Instalar los assets del entorno de producción.
    php app/console assets:install web --symlink
    php app/console -e=prod assetic:dump
  7. Opcionalmente cambiar el propietario de las carpetas cache y logs.
    chown -R nginx:nginx app/cache
    chown -R nginx:nginx app/logs
  8. Opcionalmente dar permisos de escritura a las carpetas cache y logs.
    chmod -R a+w app/cache
    chmod -R a+w app/logs

miércoles, 7 de enero de 2015

Introducción a MongoDB

MongoDB es una de las bases de datos NoSQL más utilizada. Es un producto open-source, multiplataforma y está escrito en C++, pero su uso es similar al del lenguaje Javascript (objetos JSON), como veremos más adelante.

Una base da detos NoSQL como MongoDB funciona de forma muy distinta a una clásica base de datos relacional: No hay tablas sino colecciones, no hay registros sino documentos, no hay atributos sino campos y como característica más importante: no hay relaciones. Al menos no las hay en el sentido de las bases de datos relacionales, aunque se pueden simular. Tampoco hay SQL. Podría decirse que MongoDB es una base de datos orientada a objetos, ya que los "documentos" de MongoBD son muy similares los "objetos" de por ejemplo Javascript. Tan similares que la interacción con MongoDB se realiza a través JSON (JavaScript Object Notation).

Por ejemplo:

db.books.find({ author: 'George R. R. Martin' });

Una de las principales características de MongoDB, al igual que de otras bases de datos NoSQL, es que los documentos no tienen por que ser homogéneos. Esto quiere decir que dos documentos de la misma colección pueden tener campos diferentes.

Por ejemplo:

db.books.insert({ name: 'A Game of Thrones', author: 'George R. R. Martin' });
db.books.insert({ name: 'A Clash of Kings', year: 1988 });

En este ejemplo ambos documentos tienen distintos campos, estando en la misma colección, pero ambos son válidos en MogoDB. Incluso es posible que dos documentos tengan el mismo campo con distinto tipo. Por ejemplo author podrís ser un string en un documento y un array en otro.


Principales ventajas

  • Rapidez en las consultas.
  • Enorme flexibilidad.
  • Indexación por cualquier campo.
  • Soporta replicación y balanceo de carga.
  • Es multiplataforma: linux, Mac OS X, Windows, ...
  • Tiene drivers para la mayoría de lenguajes de programación: C, C++, PHP, Java, .Net, etc.

Principales inconvenientes

  • Carece de relaciones.
  • No soporta transacciones.

Referencias