Partamos de una tabla en MySQL con el siguiente contenido:

+———–+——-+———+———–+

| cvepedido | total | usuario | status |

+———–+——-+———+———–+

| 1 | 82.65 | 4 | abierta |

| 2 | 11.60 | 7 | abierta |

| 3 | 76.56 | 10 | cerrada |

| 4 | 50.23 | 7 | cerrada |

| 5 | 65.43 | 4 | cancelada |

| 6 | 91.03 | 5 | cancelada |

| 7 | 40.69 | 8 | cancelada |

| 8 | 53.92 | 5 | cancelada |

| 9 | 58.28 | 6 | abierta |

| 10 | 21.96 | 4 | enviada |

| 11 | 92.72 | 7 | enviada |

+———–+——-+———+———–+

De esta tabla lo más importante para nuestro ejemplo serám las columna total y status, pues las usaremos en el siguiente stored procedure:

CREATE PROCEDURE promedioStatus(IN estado varchar(20),OUT promedio float(10,2))

BEGIN

select AVG(total) into promedio from pedidos where status=estado;

END

Este procedimiento, es simple, recibe 2 parámetros uno de entrada y otro de salida, el de entrada es el status que se usará para calcular el promedio del total de los pedidos, promedio que será almacenada en el parametro de entrada “promedio”.

Ahora entramos al Zend Framework 2 usaremos un patrón Table Module con el componente Zend\Db de Zend Framework 2. Lo primero sería colocar la configuración de BD y el adaptador.

<?php
return array(

'db' => array(

'driver' => 'pdo_mysql',

'host' => 'localhost',

'username' => 'xxxx',

'password' => 'xxxxxxxx',

'dbname' => 'xxxxxx'

),

'service_manager' => array(

'factories' => array(

'DbAdapter' => 'Zend\Db\Adapter\AdapterServiceFactory'

)

)

);

Ahora hay que crear la clase para la Tabla

<?php

namespace Application\Model;

use Zend\Db\TableGateway\TableGateway;

use Zend\Db\Adapter\Adapter;

class PedidosTable

{

/**
*
* @var TableGateway
*/

protected $tableGateway;

public function __construct(Adapter $adapter)

{

$this->tableGateway=new TableGateway('pedidos', $adapter);

}

}

Aquí en el constructor recibimos el adaptador de BD y creamos el Objeto TableGateway que estará dentro de una propiedad, desde el podremos llamar cualquier operación de BD y la idea es envolver esas operaciónes, querys y llamadas a store procedures dentro de métodos que describan esas operaciones en terminos de funcionalidad de clase y no funcionalidad de tabla, es decir que digan, insertar, actualizar, borrar, sino, obtener, cambiar, quitar.

Así creamos el siguiente método que ejecuta nuestro stored procedure:

public function obtenerPromedio($status)

{

$sql="CALL promedioStatus('{$status}',@res)";

$statement = $this->tableGateway->getAdapter()->createStatement($sql);

$statement->execute();

$query = $this->tableGateway->getAdapter()->query("select @res as resultado");

$fila=$query->execute();

$resultado=$fila->current();

return $resultado['resultado'];

}

 Dentro de este módulo tomamos el adaptador y creamos una sentencia que llame nuestro store procedure y lo ejecutamos, el resultado se almacenará en la variable @res, luego simplemente hay que hacer un query que seleccione esa variable y hacer un fetch de ese resultado.

 Lo que seguiría sería crear un servicio de esta clase para poder invocarla desde cualquier lugar donde tangamos acceso desde cualquier lugar en el que exista

El componente para el manejo de cache en ZF2, Zend\Cache ha sido completamente reescrito, ahora hace uso de muchísimas interfaces, plugins y clases abstractas. Sin embargo, al igual que su predecesor en ZF1, Zend\Cache sigue contando con soporte para gran número de medios de almacenaje para el caché; por ejemplo Xcache, Memcache, Redis, sistema de archivos, etc.

¿Cómo guarda la información Zend\Cache?

Principalmente a través de los Adapters, estos son quienes se conectan al medio de almacenaje correspondiente, servicio, base de datos, sistema de archivos, etc; su funcionalidad está descrita por algunas interfaces del componente.

Hay algunas clases llamadas capabilities, que indican capacidades de comportamiento del almacenaje. También existen clases Plugins que añaden funcionalidad al adaptador, normalmente cuentan con listeners que escuchan triggers de los adaptadores y tienen que ver más con el tratamiento de los datos o acciones adicionales a las tomadas por los adaptadores.

¿Qué tipo de información puede guardar Zend\Cache?

Zend\Cache tiene una serie de clases Patrón, que describen desde donde se puede guardar la información en caché. Por ejemplo CallbackCache, nos sirve para guardar en caché una respuesta de una función callback, OutputCache nos sirve para guardar un output generado por un script.

Un ejemplo

$cacheSalida = Zend\Cache\PatternFactory::factory(‘output’, array(

   ‘storage’ => ‘memcache’,
));

$cacheSalida->start(‘idCacheSalida’);
echo “Esto se va a guardar en el cache”;

printf(“Esto también”);
$cacheSalida->end();

En el ejemplo anterior, se usa el PatternFactory para “fabricar” un objeto OutputCache que use el adaptador Memcache, ya teniendo toda la salida desde el start hasta el end será guardada por el adaptador en memcache con el identificadir idCacheSalida.

Si queremos hacer  un  respaldo de nuestros datos en Mongo DB tenemos varias opciones, una es utilizar las utilerías Mongodump y Mongorestore. Ambas utilerías están disponibles junto con cualquier instalación de Mongo DB.

Con mongodump podemos hacer un backup de nuestros datos, ya sea conectándonos a un servidor Mongo DB (Mongod o Mongos) y extraer esos datos como un cliente común o accediendo directamente a los archivos de datos en el sistema de archivos. Entonces, tenemos las opciones –host y –port para especificar el servidor y puerto a conectarnos y desde luego, podemos especificar una base de datos y una colección particular que deseamos respaldar con –db (-d) y –collection (-c). Lo que obtendremos serán los archivos BSON (Binary JSON) que contienen los datos. Ejemplo:

mongodump -d dbETW -c myCollection

Muy bien, ya tenemos nuestros datos en BSON, ahora ¿Qué hacemos si queremos restaurarlos?

Pues allí es dónde entra Mongorestore, que su trabajo principal es tomar los archivos BSON,  se contecta a algún servidor Mongo DB (Mongod o Mongos) y guardar los datos. También puede guardar los datos localmente a través del sistema de archivos, las opciones del comando son muy parecidas a las de mongodump, es decir, podemos especificar hosts, puertos, bases de datos, colecciones y demás. Ejemplo:

mongorestore –host 127.51.12.1 –port 3017 /backup/mongodump-2013-01-01

Por último hay que tomar en cuenta si nuestros servidores requieren autenticación, tenemos que especificar usuario y contraseña al conectarnos con estas utilerías tanto al respaldar como al restaurar.

¿Ya has realizados respaldos o restauraciones con alguna de estas herramientas? Cuentános tu experiencia.

PECL es un repositorio de extensiones PHP, de hecho PECL quiere decir PHP Extension Community Library,  es  decir es un lugar donde están las extensiones PHP más comunes y que más son usadas por la comunidad.

Comparte el mismo sistema de empaquetado que su hermana PEAR, sólo que tiene una diferencia grande y fundamental, lo que se guarda en PECL son extensiones PHP, es decir código C que se compila para que  funcione como librería PHP, añadiendo funcionalidad al lenguaje.

Así muchas extensiones comunitarias, antes de llegar a la distribución “normal” de PHP, primero se vuelven conocidas y populares en PECL. Entonces, una extensión escrita por cualquiera necesita cumplir con los requerimientos de PECL, cubrir ciertas necesidades o carencias, documentarla y demás.

Actualmente las 5 extensiones más populares en PECL son:

1      APC

2      memcache

3      imagick

4      timezonedb

5      mongo

¿Cómo instalar una extensión con PECL?

Para instalar una extensión con PECL, solo hay que usar el comando:   pecl install memcache

Esto hará que se descargue el código fuente de la extensión desde el repositorio, se phpizará, se compilará para generar  un archivo .so, que puede ser cargado con la función dl() o añadiendo extension=memcache.so al php.ini.

Con esto ya tendremos funcionando la extensión en nuestro PHP y podremos utilizar su funcionalidad.

Espero que esto les sea de ayuda.

Muchos PHPeros no saben quién o qué es Zend. Otros quizá solo lo relacionan con el Zend Framework o con alguno de sus productos. 

Zend Framework 2 trae consigo una serie de cambios de arquitectura en comparación con Zend Framework 1, lo que en ZF1 era Singletons, en ZF2 son Eventos; lo que en ZF1 es una estructura MVC rígida en ZF2 tenemos los Módulos.

Estos cambios también han impactado la forma en al que se maneja las librerías que antes sólo eran cargadas o registradas por autoloaders y llamadas en cualquier momento, sin tomar en cuenta requerimientos de instanciación,configuración y más.  Ahora en ZF2 tenemos servicios.

¿Qué es un servicio?

Son básicamente librerías, objetos o piezas de funcionalidad que cumple con un propósito concreto como enviar e-mails, loggers,  comunicación con bases de datos o servicios concretos. Una de las características que los diferencía es que un servicio debe tener en cuenta la reutilización que un servicio, tanto que podríamos usarla en cualquier proyecto sea ZF2 o no.

La necesidad de crear un servicio se hace patente cuando esa funcionalidad no se puede colocar ni en el modelo ni en el controlador, es decir, no tiene que ver con el proceso MVC de la aplicación.

Estructura básica de un servicio

El servicio básicamente tiene 2 carpetas:

Library  que contiene la estructura de directorios  con las clases que contienen nuestra funcionalidad, hay que tomar en cuenta que los namespaces de las clases tienen que coincidir con la estructura de directorios a la cual pertenecen.

Tests que contiene los test unitarios (buena práctica) del código funcional, la estructura de directorios y clases en tests debe ser un espejo de lo que hay en library. Además, debe tener un archivo phpunit.xml.dist quien contiene configuraciones para el PHPUnit, un archivo de arranque Bootstrap.php o bootstrap.php que es llamado por PHPUnit para establecer condiciones iniciales de los tests, y por último un archivo para el autoloading, que puede usarse el mecanismo de autoloading de ZF2 u otras herramientas de generación de lo mismo como phpab.

Archivos adicionales del servicio

Si el servicio se va a compartir en Github, se pueden añadir archivos como README, LICENSE,etc.

Si nuestro servicio requiere dependencias puede usarse composer para estleber tales dependencias de una manera más sencilla

Estándares de codificación

Nuestro servicio debe usar estándares de codificación adecuados, el de ZF2 es el siguiente: http://framework.zend.com/wiki/display/ZFDEV2/Coding+Standards.

Documentación

Tenemos que generar documentación adecuada de nuestro servicio, se recomienda ampliamente la generación de la misma a partir de los comentarios en el código con docBlocks y phpDocumentor.

Reutilización y publicación de nuestro servicio

Podemos publicar nuestro servicio en los siguientes sitios

http://packages.zendframework.com

https://packagist.org

http://github.com

Si alguien instala nuestro servicio usando composer, este será colocado en la carpeta vendor y tendrá que ser cargado y usado a través del Service Manager.

Espero que esta guía les sea útil.

Hace apenas unos días, Zend anunció el lanzamiento de la última versión de su IDE, Zend Studio 10.

Esta nueva versión nos ofrece las ya conocidas características de versiones anteriores que nos ayudan a maximizar la productividad, como el PHPUnit, Debugging, perfilado de aplicaciones y Control de versiones(incluyendo Git).

Pero son las nuevas características de esta versión que llaman rápidamente nuestra atención, por ejemplo la posibilidad de crear aplicaciones móviles conectadas a la nube. Así es , desde Zend Studio 10, podemos crear los dos aspectos de una aplicación móvil, el lado cliente generado a partir de HTML y jQuery, y el lado del servidor con web services RESTful creados con PHP y componentes de Zend Framework 2 con la posibilidad de hospedar esto en la nube.

Y ya que hablamos de desarrollar usando la nube, Zend Studio nos da la posibilidad de desplegar nuestro código en “nubes”, que cuentan con stacks de PHP certificados y otras componentes como bases de datos que nos evitan la necesidad de tener que preparar ambientes de desarrollo en máquinas locales u otros servidores, en concreto se trata de la Zend Developer Cloud y la de Red Hat, la OpenShift, ambas gratuitas y abiertas.

Todo esto suena excelente, aunque debo confesar que para un servidor, la característica más atrayente es por mucho la integración del IDE con Zend Framework 2. Y es que el Zend Studio 10 te auxilia muchísimo en el desarrollo de aplicaciones ZF2. Por ejemplo, la creación inicial de la aplicación nos deja ya una estructura muy completa desde la cual podemos empezar a poner nuestro código; además nos ayuda en la creación de módulos, controladores, vistas y otros items del framework. Por si esto fuera poco, cuenta con un localizador de servicios ZF2 con integración a composer, sin mencionar la auto-completación de clases, métodos y namespaces que hace que el desarrollo en ZF2 sea mucho más sencillo.

¿Ya conoces el producto? Cuéntanos que te parecio.

PHPUnit es un framework open source para el desarrollo, orientado a pruebas ó TDD para culquier código PHP. Es decir, es un framework que nos ayuda a probar nuestro código.

Ahora, ¿Por qué probar nuestro código? Bueno, Sebastian Bergmann creador de PHPUnit, dice algo muy cierto, “todos los programadores cometen errores, pero la diferencia entre los buenos programadores y los malos programadores es que los buenos programadores prueban su código para encontrar esos errores lo más pronto posible“. Y es que esperar a que el software falle por sí mismo para después corregirlo es muy costoso, lento y dificíl de corregir.

La propuesta de PHPUnit y otros frameworks para pruebas es crear pequeñas unidades que revisen funcionalidades puntuales del código y probar que funcionen como debe, además de la posibilidad de automatizar estas pruebas para ejecutarlas frecuentemente, tanto como el código cambie.

Así, para probar el código no es suficiente recargar el navegador como loco, hay que definir la funcionalidad del mismo, separarla en unidades y revisar que cada una funcione como se supone.

La vía típica para instalar PHPUnit es a través de PEAR, aunque también algunos IDEs como Zend Studio ya lo traen integrado. Una vez instalado hay que crear los tests, que no es otra cosa que métodos clases en PHP, y ejecutarlos por línea de comando o desde nuestro IDE; así obtendremos un resultado para cada test. Para que una prueba sea exitosa, todos los tests unitarios deben pasar y obtener un alto porcentaje en la cobertura de código.

Crear tests unitarios puede complicarse si nuestro código no es testeable, es decir, no se presta mucho para hacerle pruebas, saber si un código es testeable o no, crear pruebas más efectivas es algo que sólo con la práctica lograremos.

Espero esto les sea de utilidad.
Saludos.

En Zend Framework 2 se introduce un nuevo sistema de manejo de módulos. Si bien ZF1 ya contaba con un sistema modular, éste tenía algunas limitantes como poca flexibilidad, soporte limitado para su reutilización y distribución.

Los módulos en ZF2 son flexibles porque, no tienen que forzosamente estar atados al MVC, pueden contentener sólo servicios, plugins, librerías como Doctrine o controladores, todo eso y más, es decir, no debe de tener un solo uso.

En cuanto a la reutilización y distribución los módulos en ZF2 es extremadamente sencilla, por ejemplo, con el simple hecho de copiar nuestro módulo a otro proyecto y activarlo en el archivo de configuración del mismo ya será tomado en cuenta. Esto permite a los desarrolladores crear módulos comunes y aplicarlos en varios proyectos. Aquí también entra la distribución que puede ser hecha manualmente o a través de Composer, Packagist, GitHub, Pyrus o http://modules.zendframework.com/. También puedes usar modulos que otros programadores o empresas ofrecen.

Los módulos deben de tener un nombre de directorio válido (este nombre también será el namespace), un archivo Module.php y una clase Module dentro de él. Al estar registrado en la configuración el Module Manager de ZF2 buscará la clase y ejecutará los eventos registrados primero de inicialización y si es necesario de ejecución. Entre estos eventos tenemos el ServiceListener,OnBoostrapListener y otros.

Espero que esta introducción les sea útil. Saludos.

Muchas veces, se dice que al codificar se debe reutilizar código, esto es cierto,  pero no quiere decir que necesariamente se tenga que hacer “copy-paste” de ese código. El duplicar o clonar código dentro de un proyecto,  incrementa la dificultad para mantener el mismo aumentando los tiempos y costos.

Sí, al principio es muy simple y rápido hacer “copy-paste” de algunas o muchas líneas de código, pero si luego se detecta un error o se quiere hacer mejoras, la dificultad para lograrlo se multiplicará por el número de veces que se duplicó ese código en el proyecto. Lo ideal para reutilizar código es crear librerías de funciones o clases que sean sencillas y especializadas, de manera que mantenerlas resulte práctico y fácil.

Una herramienta que nos ayuda a detectar código PHP duplicado es phpcpd (Copy/Paste Detector (CPD) for PHP code) , la cuál fue creada por Sebastian Bergmann, el mismo de PHPUnit , y al igual que phploc se instala desde PEAR.

Instalación

Si no has usado el canal PEAR phpunit.de primero debes “descubrirlo”:

pear channel-discover pear.phpunit.de

pear channel-discover components.ez.no

Y ahora sí podemos instalar el phpcpd

pear install phpunit/phpcpd

Corriendo una prueba

/usr/local/zend/bin/phpcpd sigmabol/

phpcpd 1.3.2 by Sebastian Bergmann.

Found 8 exact clones with 550 duplicated lines in 8 files:

– application/controllers/MatrizinternaController.php:8-163

application/controllers/MatrizController.php:7-162

– application/controllers/MatrizinternaController.php:186-240

application/controllers/MatrizController.php:179-233

– library/Bvb/Grid/Deploy/Pdf.php:285-292

library/Bvb/Grid/Deploy/Pdf.php:436-443

– library/Bvb/Grid/Deploy/Print.php:111-120

library/Bvb/Grid/Deploy/Wordx.php:381-390

– library/Bvb/Grid/Deploy/Wordx.php:79-234

library/Bvb/Grid/Deploy/Odt.php:79-234

– library/Bvb/Grid/Deploy/Print.php:111-120

library/Bvb/Grid/Deploy/Odt.php:352-361

– library/Bvb/Grid/Deploy/Wordx.php:79-233

library/Bvb/Grid/Deploy/Ods.php:79-233

– library/Bvb/Grid/Deploy/Print.php:111-118

library/Bvb/Grid/Deploy/Word.php:111-118

3.64% duplicated lines out of 15116 total lines of code.

Time: 1 second, Memory: 22.25Mb

Al correr el comando nos da una salida con los archivos que tienen líneas de código duplicadas, además un porcentaje de líneas duplicadas respecto al total de líneas del proyecto, el tiempo y memoria que tomó hacer la prueba.

Conclusiones

Esta herramienta nos de una buena idea de la forma en la que reutilizamos nuestro código, lo ideal sería que el 0% de nuestro código esté repetido, por supuesto algunas veces esto no será posible y duplicaremos algo de código, pero es bueno mantener esos porcentajes por niveles bajos.

Eso nos ayuda a fomentar buenas prácticas como la creación de librerías comunes y clases extendibles( léase con la facilidad para ser extendidas por clases hijas).

Además phpcpd y las otras herramientas similares pueden ser integradas con servidores de Continuous Integration como Jenkins y phpUnderControl, lo que nos da una visión completa del QA (Quality assurance) en nuestros proyectos PHP.

Saludos.