Como ya he dicho hay gente que todavía usa el bloc de notas (o sus equivalentes en Linux, incluyendo vi o Emacs) y algún “avanzado” ha descubierto Notepad++ o Ultraedit (probablemente crackeado, que todavía no conozco a nadie que haya pagado por él).
Yo soy algo más pijo y prefiero un entorno “integrado” donde poder ver todo a primera vista, tener arbolitos con mis objetos categorizados y poder navegar con comodidad entre los, habitualmente, cientos de objetos con los que suelo trabajar. Y lo más importante, necesito, o mejor, me es imprescindible el poder depurar el código, porque no siempre un fichero de log te da todo lo que necesitas.
Yo para todo esto uso Eclipse PDT, que es una especialización de Eclipse para trabajar con PHP. Es lo que YO uso y lo que yo recomiendo a quien me pregunta. Este entorno cubre por completo mis necesidades y además, para los que hemos trabajado con Java, es un entorno casi “de facto” por la cantidad de plugins útiles que tiene para nuestro trabajo diario.
Si a alguien le interesan otros entornos, como Zend Studio o similares, no voy a hablar de ellos aquí.
Instalar Eclipse no tiene demasiado secreto:
- En Windows es bajarse un fichero y descomprimirlo (doy por supuesto que se tiene la máquina virtual de Java).
- En Linux suele estar en los repositorios de programas y si no, habrá que buscar ayuda en la web de eclipse o preguntando a papá Google.
Si ya se tiene un Eclipse instalado podría actualizarse para que maneje PHP. En la web de Eclipse nos lo explican de manera bastante sencilla: http://wiki.eclipse.org/PDT/Installation
Cuando hayamos acabado ya podremos acceder a nuestra nueva instalación de Eclipse y editar ficheros como tontos.
 | |
| Entorno Eclipse |
xdebug - depurador y más
xdebug es una pequeña maravilla para PHP que nos va a permitir (entre otras cosas):
- Depurar código PHP (depuración remota).
- Realizar profiling del código ejecutado.
- Realizar Code coverage del código, muy útil para el test unitario.
Instalar xdebug es relativamente sencillo y en este enlace de Zend lo explican paso a paso: http://devzone.zend.com/article/2803-Introducing-xdebug.
Para Linux la manera más sencilla es instalando a través de PECL que es algo así como un macro repositorio de cosas útiles.
Para instalar PECL en ubuntu y similares se han de tener instaladas PEAR y las herramientas de desarrollo de php, tal como explican en este enlace: how to install PECL extensions.
Realmente debería instalarse con los comandos:
sudo apt-get install php-pearEn Windows hay que tener cuidado ya que se ha de saber con qué versión de Visual C++ ha sido compilada nuestra versión de PHP y si tenemos o no una versión Thread Safe. Para evitarnos problemas en esta página se puede pegar lo que nos devuelve phpInfo y sabremos qué versión descargar: Find xdebug binary
sudo apt-get install php5-dev
sudo pecl install xdebug
Tras instalarlo habría que activarlo y configurarlo y para ello hay que editar el fichero php.ini. Su ubicación depende del sistema operativo y el servidor LAMP/WAMP usado.
- Si se usa Wampserver en Windows se puede acceder a él a través del panel de control.
- En Linux suele estar en el directorio /etc/php5/apache2 o alguno similar y si no siempre se puede localizar utilizando estos comandos:
sudo updatedbUna vez editado el fichero php.ini habrá que agregar una línea similar a la siguiente (cambiar las rutas por las que correspondan a la ubicación de la librería xdebug):
sudo locate php.ini
Windows:
zend_extension_ts="c:\php\ext\php_xdebug-2.0.1-5.2.1.dll"Linux:
zend_extension="/usr/lib/apache2/modules/xdebug.so"
Yo suelo ubicarla al final de la definición de las extensiones porque justo después agrego la configuración de xdebug.
Existen varios parámetros que se pueden configurar (agregar las líneas indicadas en el php.ini, tras las anteriores), aunque yo, personalmente, sólo suelo incluir los siguientes en una instalación básica:
[xdebug]Esto nos permite depuración remota desde localhost para el puerto 9000. Todas las opciones de configuración están explicadas en la documentación de xdebug así que sólo me pararé cuando alguna me parezca importante.
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
En mi caso, dado que uso ciertos servicios que trabajan en el puerto 9000 suelo tener que cambiar el parámetro xdebug.remote_port a otro puerto.
Ahora ya deberíamos tneer preparado el entorno para depurar y para ello reiniciamos Apache:
Linux
sudo service apache2 restart (o su equivalente en otras distribuciones)Windows
Desde el panel de control de WampServer o el que sea.
Al ejecutar http://localhost/info.php (que espero que no se haya borrado) se deberá obtener algo similar a lo mostrado en la figura:
 |
| phpInfo + xdebug |
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
Y deberá existir una sección xdebug donde se podrán ver todos los parámetros de configuración de la extensión.
Si el servidor no arrancase habría que examinar los logs de Apache y PHP para averiguar qué extensión está fallando y buscar ayuda en internet. Los errores que me he encontrado yo han sido, casi siempre, librerías de versiones erróneas.
Depurando con Eclipse
Llegamos a la parte útil y donde comenzaremos a ver la potencia de xdebug: depurando.
En este artículo podemos ver los pormenores de configuración del entorno de depuración, que no es que sea nada del otro mundo: Debugging PHP Applications with xdebug
La secuencia de pasos está bastante clara y, conociendo un poco Eclipse, se puede averiguar dónde cambiar ciertas opciones de configuración.
Por ejemplo, podemos cambiar el depurador o cambiar sus opciones (en el caso de que se cambie el puerto, por ejemplo). O eliminar el check que viene marcado por defecto siempre de “Break at first line” que con proyectos grandes puede hacerse pesado.
Todo eso puede hacerse desde la opción PHP de la ventana de preferencias de Eclipse:
Para averiguar qué efecto causa cada cosa se puede recurrir al clásico “trastear”. No estoy yo para hacer manuales pormenorizados de todo. Si hubiese problemas, internet es una gran fuente de información y casi seguro que los errores que tenemos le han sucedido a alguien ya.
El caso es que ya deberíamos haber acabado de configurar Eclipse para que pueda depurar remotamente así que vamos a crear un fichero de prueba llamado simple.php y rellenarlo con este código:
<?phpOdio hacer programas de ejemplo así que me he lucido bastante poco con éste. Tampoco es que la calidad vaya a variar mucho en el futuro por muchas críticas que reciba, así que en este caso toca aguantarse con lo que hay.
class Pakito {
public function show($message) {
$result = 'Este es el mensaje: '.$message;
echo $result;
}
}
$clase = new Pakito(); // Agregar punto de parada aquí
$clase->show('Chorrada de prueba');
?>
Primero deberíamos poner un punto de parada en la línea que he indicado y eso se hace desde dentro de Eclipse. Deberías saberlo ya: doble click en la zona sombreada del editor de ficheros.
El siguiente paso es lanzar la depuración en sí: botón derecho sobre el fichero (en el árbol de ficheros) y seleccionar la opción de “Debug as” y “PHP Web Page”.
Y si todo va bien (que debería) se abrirá la perspectiva de depuración PHP de Eclipse y el depurador se nos parará en el breakpoint indicado en nuestro chorriprograma (o en la primera línea si es que no hemos quitado el check).
Se puede ver que disponemos de las habituales herramientas de depuración de Eclipse, incluidas la pila de llamada y las variables. Como curiosidad se pueden acceder a las variables internas del servidor (por ejemplo $SERVER, $REQUEST o $COOKIES). ¡Semos todopoderosos!
Supongo que llegar a este punto no debería haber dado demasiados problemas. Lo que pudiera surgir probablemente sería alguna mala configuración de rutas (por ejemplo la ruta hacia el ejecutable de php) o de puertos. De todas formas: siempre nos quedará internet.
xdebug es una herramienta tremendamente potente de depuración y, aunque hablaré de ello en detalle más adelante, aquí van un par de enlaces, además de los presentes en la documentación oficial, para saborear sus posibilidades de Profiling (mucho cuidado porque se come el disco en un visto y no visto) y Code Coverage.
En unión con PHPUnit es una herramienta my efectiva para el TDD.
En futuros posts ampliaré la parte de Code Coverage con PHPUnit y Phing, el equivalente de ANT para PHP.
Salut!
No hay comentarios:
Publicar un comentario