PHP Senior

Encuesta: "¿me volví monotemático?"

A veces pasa que un "blog técnico" toma una "dirección técnica" porque su autor orientó sus esfuerzos hacia un objetivo concreto, como en mi caso, ultimamente hacia Zend Framework y proyectos relacionados (bajo el nombre de "surforce").

Muchas veces esto segmenta demasiado a los lectores, algunos pueden estar de acuerdo, otros no, por consiguiente se crea un ambiente de inconformidad con la temática tratada.

Me gustaría entonces saber qué opinan al respecto, por eso he habilitado una encuesta en el cuadro superior derecho y de paso agregué algunos temas como opciones. También pueden sugerir en los comentarios de este post (pero agradecería que igual votaran como tema "otros", así hacemos un seguimiento "gráfico").

Estadísticas de PHPSenior - Abril 2008

La verdad que no sigo mucho las estadísticas más que para tener una idea del perfil de los lectores y de donde me referencian (así poder a su vez comentar en sus sitios).

Lo que me sorprende en lo personal es cómo va pasando el tiempo y mi país de origen (Uruguay) va quedando cada vez más fuera de la estadística, hasta casi desaparecer ;-)

Si a alguien le interesan estos datos, aquí se los comparto.

"¿La empresa cuenta con framework propio?"

Esta pregunta me la he hecho mentalmente todas las veces que alguien me respondió "¿qué framework usan para desarrollar en tú empresa?" y no hay mejor resumen de lo que pienso en la siguiente respuesta del post "Cinco preguntas para tu próxima entrevista de trabajo si te gusta el software":

"Si por cualquier razón la respuesta es "tenemos un framework propio", mal pinta la cosa. De hecho, hasta me atrevería a ser radical y decir que es hora de huir de ahí como del demonio. A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas "porque Spring o JSF no se ajustan a los requisitos de la empresa".

El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda. De aceptar esto, tocará trabajar con tecnologías probablemente obsoletas, tocará corregir bugs que no estarían ahí de utilizar algo probado, o tocará "mejorar" el framework con cosas que ya están implementadas en otras librerías. Un framework propio, puede ser resultado de una mala elección, o quizás de una elección forzada debido a que el producto se creó hace muchos años.

La respuesta ideal dependerá de lo que quiere hacer el desarrollador o del lenguaje, pero a cualquiera que se mantenga un poco al día le será fácil detectar nombres clave. En Java, Spring, Hibernate, JSF, WebWork, Seam, o incluso EJBs serían respuestas válidas. Struts, mmmmm, ok, todavía hay mucho Struts por ahí y siempre será mejor que un framework web propio. En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente."

Sin palabras, 100% de acuerdo.

Si desarrollas PHP, no me vuelvas a decir "no, en la empresa usamos un framework propio" ;-)))

PD: fuera de broma, antes también era "purista" y quería hacer "todo yo", pero luego te das cuenta que estás perdiendo tiempo en poder realmente resolver problemas importantes y desarrollar o terminar de desarrollar sistemas, dejar funcionando verdaderos proyectos. Los usuarios, tus usuarios, no verán realmente qué framework usas, pero sí, que tu aplicación funcione, por lo cual, apóyate en herramientas hechas y probadas.

¡Nueva versión de surforce-cms!

El proyecto surforce-cms fue uno de los primeros que inicié para empezar a aprender el uso de Zend Framework en situaciones reales, y de paso, compartir información con otros colegas que querían particiar en su desarrollo al más clásico estilo "software libre" (todos salimos beneficiados).

Con el tiempo han surgido nuevas necesidades de "orden" para poder iniciar nuevos proyectos a partir de la experiencia acumulada, por lo que aparecieron surforce-base, surforce-modules y surforce-library. El paso siguiente es "migrar" los proyectos más antiguos a esta nueva estructura, así poder fácilmente alimentarse con el reuso de módulos y de la librería de surforce.

Bien, todo esto lleva trabajo y tiempo ;-), pero por lo menos ahora surforce-cms está mucho más claro y ordenado como para poder entenderlo y/o basarse en él para crear un propio sitio que requiera estas funcionalidades (en sí este no es un producto para usuarios finales, pero sí es muy útil para desarrolladores con intención de dar sus primeros pasos en Zend).

Copio los comentarios que agregué en los commits del repositorio:

"Nueva versión que hace un salto importante hacia la estructura planteada en surforce-base:

- uso de controllers genéricos
- Zend_Layout

Reestructura funcional

- Se terminan de mover casi todos los admins a un módulo "admin", simplificando los controllers

- Se agrega la funcionalidad de "sitios" o subsitios, también se puede usar como "secciones". Todo el cms discrimina según el sitio/sección, es decir, hay noticias para el sitio1 y sitio2, indistintamente.

Nota:
- Se incluye la librería surforce-library porque sufrió cambios para este proyecto, una vez que se actualiza con el svn original, será borrada de este repo."

El paso siguiente es terminar de actualizar desde surforce-cms la librería surforce-library y los módulos a surforce-modules, para finalmente reordenar en módulos con todo su MVC dentro.

Aún quedan detalles por revisar y corregir, pero creo que es un buen "proyecto ejemplo" para hacer pruebas.

Ya actualicé el sitio de pruebas que está en http://cms.surforce.com y pueden ingresar con el usuario "admin" y clave "admin" ;-)

Nota: de la versión anterior a esta hubieron demasiados cambios estructurales, por consiguiente borré los fuentes y volví a subirlos... no sé si les funcionará un update sobre una versión vieja (aunque en teoría sí), y a su vez hubieron cambios en la base de datos, por consiguiente hay que reconstruirla del dump que se encuentra en el directorio "sql".

PD: no te olvides visitar el wiki de surforce, que ahí están documentados muchos tips sobre los sistemas y sobre cómo instalarlos.

No eres un desarrollador Senior si no sabes lo que son las SPL ;-)

Hace más de un dos años, haciendo una consulta a mi colega mexicano Christopher Valderrama (alias GatorV), en el intercambio me dice "¿y por qué no usás las SPL?" (¿?). Atónito, me pregunté "¿será alguna libería para instalar?" ;-), pero no, ocultas casi en el manual estaban las "Standard PHP Library", con muy poca documentación.

Desde ahí es que empecé a usar el DirectoryIterator para recorrer fácilmente una estructura de directorios de forma recursiva con solo:

1  
<?php
2  foreach (
3       new RecursiveIteratorIterator(
4        new RecursiveDirectoryIterator(
5        DATA,
6        RecursiveDirectoryIterator::KEY_AS_PATHNAME),
7       RecursiveIteratorIterator::CHILD_FIRST
8       ) as $directory => $info){
9  
10       if ($this->isFileDat($info)) {
11            $this->procesarDir($directory);
12       }
13  }
14  ?>

Parece algo complejo, pero probando este código e imprimiendo los valores verás como puedes recorrer su contenido.

Todo esto viene al caso del artículo "5 funcionalidades de PHP que no se puede ignorar", donde entre ellas se habla de la "SPL".

Indudablemente hay mucho para aprender, pero está todo en los manuales. Si te crees "Senior" (no me cuento, me considero eterno alumno), no lo creas hasta por lo menos haber usado alguna vez estas 5 funcionalidades. ;-)

Surforce-base: primera versión con Zend_Layout

Hacer un rato actualicé el repositorio svn del proyecto surforce-base con la inclusión del manejo de "layout" (diseño) provista por Zend_Layout. Anteriormente teníamos que en cada vista de todos los módulos de nuestro sistema incluir indefectiblemente el código para el cabezal en la parte superior y el pié en la parte inferior.

Algo así:

1  
<?php echo $this->render('header.phtml'); ?>
2  <?php echo $this->render('menu.phtml'); ?>
3  
4  <div id="noticias">
5  
6     Hola, son el index de Noticias, 
7     si quieres ingresar al admin debes ir a 
8     <a href="<?php echo $this->baseUrl ?>
9        /noticias/admin/">Admin</a>
10  </div>
11  
12  <?php echo $this->render('footer.phtml'); ?>

De ahora en más, simplemente hay que poner el contenido de la vista sin los renders de "header" ni "footer".

El detalle más importante de todo esto es que en el modelo anterior, si tuviéramos que cambiar la estructura base del sitio -por ejemplo- cambiar de lugar el cabezal, el pie, o agregar un menú, o cambiarlo de lado, hay que modificar todas las vistas para hacerlo.

De esta nueva forma todo el esqueleto del sitio se encuentra en el layout.phtml, ubicado al mismo nivel que el código del cabezal y el pie (/html/scripts) y contendrá el siguiente código:

1  
<?php echo $this->render('header.phtml'); ?>
2  <?php echo $this->render('menu.phtml'); ?>
3  
4  <?php echo $this->layout()->content; ?>
5  
6  <?php echo $this->render('footer.phtml'); ?>

Y lo único que hubo que agregar fue en el bootstrap (index.php) algo como esto:

1  
<?php
2  
3  /**
4   * Zend_Layout
5   */
6  define('APP_PATH', realpath('.'));
7  
8  Zend_Layout::startMvc(array(
9      'layoutPath' => APP_PATH . '/html/scripts'
10  ));
11  
12  $view = Zend_Layout::getMvcInstance()->getView();
13  ?> 
14

Y listo, luego hay que sacar en todos los módulos las referencias al cabezal y pie para que este no se repita, ya que quedó definido en el "layout".

Más información en el proyecto en el cual pueden bajar sus fuentes y probarlo, y hasta ver las diferencias consultando el log del SVN.

Fuente: Introduction to Zend_Layout (updated for ZF 1.5!)

Actualización (24/04/2008):

PHP&Beers Buenos Aires

Me avisan que este jueves se va a realizar en Palermo (Argentina) la primer "PHP&Beers" con el fin de juntarse desarrolladores y conocerse.

La dirección exacta es:

"Cervecería Antares (Armenia 1447, Palermo), el Jueves 24 de Abril, a las 19:30 horas."

¿Para cuando una PHP&Beers en Uruguay? ;-)

PD: nosotros hicimos una, pero fue con alumnos de mi curso de PHP5 de ORT, que luego quedamos que deberíamos hacer una regular para todos los desarrolladores PHP en general (algo que todavía no se dio).

Zend: "¡¿donde está mi helper?! ¡¿cómo lo llamo?!"

Estuve un rato teniendo problemas con un helper que había creado y que lo colocaba en el -supuesto- lugar que debía estar y la vista que lo usaba no lo encontraba.

Nota: aviso, "todo", está en el manual, lamentablemente (así que hay que leerlo ;-) )

En la sección sobre "Zend_View", en particular el punto "42.1.4. Utility Accessors", fue bastante revelador, ya que nos da las herramientas para comprender cómo el sistema registra los nombres y las ubicaciones de los helpers y poder revisar si estamos cometiendo algún error de sintaxis o de conceptos.

Aquí algunos métodos que podemos usar desde una vista:

getScriptPath($script): nos retorna el camino a partir del nombre de un scripts

getScriptPaths(): nos retorna todos los caminos de los scripts registrados.

getHelperPath($helper): el camino de un helper dado a partir del nombre de la clase

getHelperPaths(): todas las rutas registradas para los helpers

Estos métodos nos permiten hacer un "debug" de nuestro sistema y ver donde nuestro MVC encuentra o debería encontrar los helpers, muy útil para controlar que estemos haciendo las cosas bien.

Estando dentro de la vista podemos hacer

1  
<?php 
2  
3  var_dump(  $this->getHelperPaths() );
4  
5  ?> 
6

Y nos tira la lista de rutas que tiene definido para buscar los helpers

1  
<?php 
2  
3  array(4) {
4    [0]=>
5    array(2) {
6      ["prefix"]=>
7      string(7) "Helper_"
8      ["dir"]=>
9  
10      string(32) ".\library\Zsurforce\View\Helper\"
11    }
12    [1]=>
13    array(2) {
14      ["prefix"]=>
15      string(8) "_Helper_"
16      ["dir"]=>
17      string(15) ".htmlhelpers"
18  
19    }
20    [2]=>
21    array(2) {
22      ["prefix"]=>
23      string(25) "Estadisticas_View_Helper_"
24      ["dir"]=>
25      string(41) ".application\estadisticas\views\helpers"
26  
27    }
28    [3]=>
29    array(2) {
30      ["prefix"]=>
31      string(17) "Zend_View_Helper_"
32      ["dir"]=>
33      string(57) "C:\xampp\htdocs\admin\library\Zend\View\Helper"
34  
35    }
36  }
37  
38  ?>

Varias deducciones interesantes:

Que está por defecto buscando en "html\helpers" (algo que no sabía)

Que no hace falta decirle dentro de la vista correspondiente donde buscar sus helpers, ya que lo hace solo: \application\estadisticas\views\helpers\ (yo estoy probando dentro de la vista del módulo estadísticas)

No veo la ruta hacia los helpers de surforce-library

Tomando en cuenta esto último, agregué en el init del controller genérico de surforce-library:

1  
<?php
2  $this->view->addHelperPath('./library/Zsurforce/View/Helper/', 
'Helper');
3  ?>

Si volvemos a ejecutar la vista, ahora nos dice:

1  
<?php 
2  
3  array(4) {
4    [0]=>
5    array(2) {
6      ["prefix"]=>
7      string(7) "Helper_"
8      ["dir"]=>
9  
10      string(32) ".\library\Zsurforce\View\Helper\"
11    }
12    [1]=>
13    array(2) {
14      ["prefix"]=>
15      string(8) "_Helper_"
16      ["dir"]=>
17      string(15) ".htmlhelpers"
18  
19    }
20    [2]=>
21    array(2) {
22      ["prefix"]=>
23      string(25) "Estadisticas_View_Helper_"
24      ["dir"]=>
25      string(41) ".application\estadisticas\views\helpers"
26  
27    }
28    [3]=>
29    array(2) {
30      ["prefix"]=>
31      string(17) "Zend_View_Helper_"
32      ["dir"]=>
33      string(57) "C:\xampp\htdocs\admin\library\Zend\View\Helper"
34  
35    }
36  }
37  ?>

Ya aparece la ruta hacia los helpers de surforce-library.

Otra cosa interesante, que ya me permitió corregir varios problemas al definir los helpers fue el nombre de los mismos con la ruta para encontrarlos. En algunos casos había creado una clase Helper con solo el nombre de la clase y en otra con el nombre con la ruta completa para ubicarlos, pero en varios estaban mal. Si vemos el array, uno de los elementos es "prefix" y justamente, es el nombre "prefijo" que debería tener la clase de nuestro helper ;-)

Por ejemplo, si nuestro helper está en el módulo estadísticas, debemos llamarlo:

class Estadisticas_View_Helper_GoogleChart

Pero si está en surforce library solo "Helper"

class Helper_GoogleChart

¿Interesante dato, no?

Nota: al final cambié el nombre del prefijo de solo "Helper" al que debería corresponder de acuerdo a la ubicación dentro de la estructura de directorios de Zend, así que la clase pasaría a llamarse Zsurforce_View_Helper_GoogleChart.

Esta es la línea que lo define en el init() del controller:

1  
<?php 
2  
3  $this->view->addHelperPath('./library/Zsurforce/View/Helper/', 
'Zsurforce_View_Helper');
4  
5  ?>

Por último, estaba probando el método "getHelperPath" que nos dice donde está ubicado el helper que consultamos, y en todos los casos anteriores no daba información, pero cuando arreglé las rutas, ya devolvía la información correcta.

1  
<?php
2  echo $this->getHelperPath('googleChart');
3  ?>

Creo que con esta explicación ahora queda un poco más claro cómo encontrarlos. ;-)

Gráficas a través de Google Chart API

Hace poco empecé a probar la API de Google Chart, un nuevo servicio web disponible que nos permite a través de una url y una serie de parámetros obtener -sin instalar nada- un gráfico que puede ser embebido en nuestro sitio web.

Lo estoy usando para desarrollos internos, y la verdad que simplifica bastante el trabajo al evitar muchos problemas, desde instalar herramientas, librerías, configuración, curva de aprendizaje, etc.

Ejecutar las primeras pruebas que aparecen en la documentación puede dar la impresión que todo es muy sencillo, pero cuando queremos obtener algo que se ajuste exactamente a nuestras necesidades es casi seguro que pasaremos algunas horas de "prueba y error" hasta lograr entener todos los parámetros y cómo cambian de acuerdo al tipo de gráfico.

Es un servicio gratuito y no tiene límites, aunque hay que avisar en caso de superar los "250,000 API calls per day".

Aquí un ejemplo de una url donde simplemente hay que pasar parámetros con los valores necesarios. Esta misma url la podemos agregar dentro de un <IMG> y como el resultado es una imágen .PNG, automáticamente la podemos tener embebida en nuestro sitio:

Lo bueno es que también puedo de forma muy simple enviar el link por mail a un usuario a partir de la url generada con los datos de mi sistema.

Aquí les dejo un ejemplo:

1  
<?php
2  
3  foreach( $this->ventas as $venta ){
4     $dia[] = $venta['dia'];
5     $cant[] = $venta['cantidad'];
6  }
7  
8  $chx = implode( "|", $dia );
9  $chd = implode( ",", $cant );
10  
11  $pars = array(
12     "http://chart.apis.google.com/chart?chs=1000x300",
13     "cht=ls",
14     "chxt=x,y",
15     "chds=1,100",
16     "chxl=0:|" . $chx . "|1:|0|50mil|100mil|150mil|200mil",
17     "chtt=Ventas por Dia",
18     "chd=t:" . $chd,
19     "chm=D,C6D9FD,1,0,8|D,4D89F9,0,0,4",
20     "chg=20,50,1,0"
21  );
22  
23  $url = implode( "&", $pars );
24  
25  ?>
26  <table border=1 align="center">
27   <tr>
28    <td>
29     <img src="<?php echo $url ?>" alt="Ventas por Dia"/>
30    </td>
31   </tr>
32  </table>
33  
34

Tal vez no sea lo mejor para todos los contextos, pero lo bueno es que usamos una herramienta de Google que está probada y tiene un respaldo de calidad detrás, como así también nos libera de tener que instalar librerías en nuestro servidor, ancho de banda y tiempo de procesador para generar los gráficos.

Por el momento me está siendo muy útil ;-)

Artículo recomendado: "Modelando con ArgoUML aplicaciones en PHP"

El otro día llegué por accidente a este artículo donde el autor nos explica cómo funciona ArgoUML: una herramienta libre que nos permite diseñar diagramas UML y que a su vez podemos tranformarlos a código PHP (entre otros lenguajes).

Al final del artículo comentan, algo que también vi y que es lo único que no me terminó de convencer, es que el código generado es bastante "sobrecargado" en el sentido que agrega líneas que sirven solo para la herramienta Argo, por lo cual no nos aportan nada a la hora de desarrollar.

De todas formas, es una buena herramienta para hacer diagramas (la he usado en mis clases de PHP5) y una opción cuando queremos generar código automático. Tal vez se podría investigar cuan complejo es modificar el módulo de PHP para que el código sea un poco más "limpio".

Entradas populares