Presentación sobre seguridad en Zend Framework [PDF]

• Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
• El desarrollo de software es inherentemente diferente de las ciencias naturales tales como las física, por lo que sus métricas son muchas menos precisas para capturar lo que deben describir.
• La frase más citada del libre es «No puedes controlar lo que no puedes medir». Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
• Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
• Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
• ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.
• Estoy llegando gradualmente a la conclusión que el momento de la ingeniería del software vino y se marchó.
• En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
• El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.
• El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Respecto a éstas críticas, básicamente estoy de acuerdo. Respecto al propio artículo de Galli, dejaré aquí mi opinión:

• Yo también creo que muchas veces se utilizan las palabras “Ingeniería del software” de forma patética…
• Sí creo que las prácticas tradicionales de hace 40 años están muertas. Pero no creo que pensar que esas prácticas están muertas sea algo revolucionario.. La mayoría de los gurús actuales abrazan los “métodos ágiles” y estos son la corriente principal. Tampoco creo que los métodos ágiles sean la panacea, pero si creo que son un enorme avance para el desarrollo de software.
• No creo que exista ninguna incompatibilidad entre hacer software libre y utilizar métodos ágiles. Y, sino, mira el Zend Framework, por ejemplo: es software libre pero utiliza muchos de los conceptos de programación extrema como Test Driven Development o Continuous Integration, y utiliza métricas como Code Coverage, etc.
• Utilizar el kernel de Linux como ejemplo es un poco tendencioso. No creo que haya muchos proyectos de sofware que se le parezcan, y no creo que podamos cogerlo como paradigma de cómo desarrollar software.
• Y respecto a “cómo desarrollar software”, estamos ante el problema de siempre: ¿Qué software? No es lo mismo programar un misil tierra aire, el World of Warcraft, la página web de una PYME o un software bancario…

No creo que nadie dude hoy en día de que los métodos clásicos de desarrollo importados de la ingeniería clásica no se ajustan al desarrollo de software. Esto no es nada polémico. Tampoco creo que nadie dude del éxito del software libre a través de proyectos como el Kernel de Linux y otros muchos. Pero también creo que se ha demostrado la eficacia de las llamadas metodologías ágiles, de ciertas métricas como Code Coverage, etc.

Actualización, dos opiniones más que interesantes al hilo del mismo artículo de Coding Horror:

• Juan Palacio hablando del tema.
• Joserra hablando del tema.

• Crear un sólo archivo (sin comprimir, o comprimido en ZIP, por ejemplo) que incluya en su interior toda la aplicación PHP y los recursos necesarios (imágenes, etc).
• Éste archivo contendrá en u interior un Stub. Un Stub es un pequeño programa que se ejecutará inicialmente cada vez que se llame a PHAR, sirve para inicializarlo y dirigirlo, por ejemplo, a un index.php.
• El PHAR puede no ser una aplicación en si misma, que se autoejecute. Puede ser que sea una librería a cuyas clases queramos acceder. Para ello se podrá hacer utilizado la habitual función “include”.
• PHAR incluye su propia API para crear los archivos, editarlos y trabajar con ellos.

Un tutorial completo sobre PHAR aquí.

Actualización:

Dejo aquí un tutorial de cómo convertir todo el Zend Framework en un PHAR y usarlo.

• Zend_Rest_Route, Zend_Rest_Controller, y Zend_Controller_Plugin_PutHandler, podrán proveer de servicios RESTful mediante MVC.
• Zend_Feed_Reader, proveerá un API para generar RSS y Atom, extensiones para cada formato y cacheo. Artículo concreto sobre Zend_Feed_Reader.
• Zend_Queue y Zend_Service_Amazon_Sqs, que son dos servicios de Amazon para mensajería y sistema de colas para procesos asíncronos.
• Zend_Db_Table. No será necesario extenderla para utilizarla. Podrás cargar la definición de la tabla que quieras usar vía constructor.
• Zend_PDF: soporte para procesado de anotaciones y mejoras en el rendimiento.
• Zend_Dojo, soporte para custom build.
• Zend_Ldap: multiples mejoras.
• Zend_Log_Writer_Syslog: un writer para tu log de sistema.
• Nuevos view helpers.

Actualización: al parecer Zend Framework 1.9 será la primera versión de ZF que será totalmente compatible con PHP 5.3!

Recordemos también que comienza la cuenta atrás para la llegada de Zend Framework 2.0

Los principales frameworks de pruebas unitarias en PHP:

• phpUnit.
• SimpleTest.
• phpt

Comparartivas:

• phpt versus phpUnit.
• SimpleTest versus phpunit.
• SimpleTest versuss phpunit 2.

Pruebas funcionales:

• Zend_Test, extensión e phpUnit para probar el MVC del Zend Framework.
• Acceptance test in php with Selenium.

Integración continua:

• phpUnderControl
• Bamboo
• Rephlux
• Xinc

Extra point:

• phpSpec: Behaviour Driven Development (BDD) en PHP.
• Mock Objects in phpUnit.
• Mockery: an independent Mock and Stub framework for PHP.
• Pruebas unitarias mutantes.
• Pruebas unitarias y base de datos.

Mi elección es phpUnit. Y es que pese a que es verdad que su mecanismo para Mock Objects es peor que el de SimpleTest, y que escribir pruebas es más pesado que en phpT, es el framework de pruebas unitarias en PHP que elige Zend Framework (y su Zend_Test) y su creador (Sebastian Bergmann) es el que más activamente está desarrollando extensiones para base de datos, etc… así que, si todavía tienen puntos débiles, con el tiempo será el aceptado por todo el mundo. Además,  Bergmann es el principal promotor de phpUnderControl, el framework de integración continua que hemos decidido utilizar David y yo (ya explicaremos más ampliamente en su momento el por qué).

Si éste artículo te interesa pero no tienes muy claro qué es la inyección de dependencias, qué ventajas tiene y qué es un container, ataca a éste artículo de Martin Fowler y a éste sobre Zend Framework.

El problema para mí con ésta solución está en dos cosas:

• si utilizas un container de esa manera estás consiguiendo anular todas las ventajas de la inyección de dependencias: esto es, tus clases estarán ligadas al container, y el container a tu código, con lo cuál pierdes toda ventaja, y todo ello habiendo tenido que escribir una gran cantidad de código (menos que sin el container, eso es verdad).
• esta solución puede ser necesaria sólo si se hace un uso MUY repetido de LA MISMA configuración, en caso contrario acabarías replicando código a mansalva.
• el uso de XML para la configuración. Precisamente los DSL (Domain Specific Languages) internos (aquellos que utilizan el propio lenguaje para escribirse, en éste caso PHP) han demostrado ser mucho más eficaces que aquellos que utilizan XML´s externos (cualquier programador de Java podrá contar miles de experiencias codificando XML´s infinitos e infernales).

Dicho esto dejo aquí una idea más sencilla y que me ha gustado más: un simple constructor de clases sin XML.

• Zend_Application para simplificar el bootstraping.
• Zend_Tool, una utilidad de linea de comandos que sirve para crear y mantener tu estructura de directorios.
• Componentes para Amazon EC2 y S3.
• Zend_Navigation, una utilidad para generar tus menús, sitemaps, bradcrumbs, etc.

Además traerá abundantes validaciones y filtros preconstruidos y otras mejoras a componentes como Zend_Pdf, etc… personalmente lo que más hecho de menos es un mayor desarrollo de la integración que se ofrece entre ZF y jQuery, que creo que todavía se puede mejorar y simplificar bastante.

Más en el sitio original de la noticia.

En el ejemplo que expongo a continuación, queremos generar una tabla de checkbox para puntuar del 1 al 3 (malo, regular, bueno) una serie de conceptos. Como veréis, la manera de hacerlo es sobreescribiendo el método render, aunque necesitaremos un poco más de código para hacerlo funcionar todo.

Por supuesto, éste ejemplo podría complicarse infinitamente, si se quisiera mezclar el render por defecto, con un render personalizado. Y, cuidado, ésta técnica es algo sucia y sólo debería utilizarse cuando la posibilidad de crear nuestros propios Zend_Form_Elements o Zend_Form_Decorators es demasiado costosa o insuficiente.

 
<?php
 
class MyForm extends Zend_Form{
 
    protected $valores = array();
 
    function __construct(){
 
     /*
     Aquí se declararían los elementos del zend form que se van a utilizar, sus tipos, valores, validaciones, etc...
     Éste Zend Form se va a utilizar como cualquier otro formulario. Aprovecharemos la posibilidad de validarlo desde en controller, etc..
     Lo único que cambia es que cuando invoquemos render() no se generará de manera regular, sino de la manera que a nosotros nos plazca.
     */
 
    }//construct
 
    //sobreescribimos el  método setDefaults, que Zend_Form llama cuando se van a introducir valores por defecto en el formulario.
    // setDefaults también es llamado desde el método populate del Zend_Form.    
    public function setDefaults(array $values){
 
        // guardamos en "valores" la lista de valores de los campos 
       //del formulario, para luego poder utilizarlos en el método render()
        $this->valores = $values; 
        parent::setDefaults();
 
    }//setDefaults
 
    function render(Zend_View_Interface $view = null){
 
        return "<table>
                  <thead>
                         <tr>
                               <th></th>
                               <th>Malo</th>
                                <th>Regular</th>
                                <th>Bueno</th>
                         </tr>
                  </head>
                  <tbody>
                    <tr>
                           <td>Concepto 1 </td>
                           <td>
                                  <input ".(($this->valores['concepto1'] == 1)?'checked':'')."  type="radio" name = "concepto1" value = "1"/>
                           </td>
                           <td>
                                  <input ".(($this->valores['concepto1'] == 1)?'checked':'')." type="radio" name = "concepto1" value = "2"/>
                           </td>
                           <td>
                                  <input ".(($this->valores['concepto1'] == 1)?'checked':'')." type="radio" name = "concepto1" value = "3"/>
                           </td>
                    </tr>
                    <tr>
                           <td>Concepto 2 </td>
                           <td>
                                  <input ".(($this->valores['concepto2'] == 1)?'checked':'')." type="radio" name = "concepto2" value = "1"/>
                           </td>
                           <td>
                                  <input ".(($this->valores['concepto2'] == 1)?'checked':'')." type="radio" name = "concepto2" value = "2"/>
                           </td>
                           <td>
                                  <input ".(($this->valores['concepto2'] == 1)?'checked':'')." type="radio" name = "concepto2" value = "3"/>
                           </td>
                    </tr>
                    <tr>
                           <td>Concepto 3 </td>
                           <td>
                                  <input ".(($this->valores['concepto3'] == 1)?'checked':'')." type="radio" name = "concepto3" value = "1"/>
                           </td>
                           <td>
                                  <input ".(($this->valores['concepto3'] == 1)?'checked':'')." type="radio" name = "concepto3" value = "2"/>
                           </td>
                           <td>
                                  <input ".(($this->valores['concepto3'] == 1)?'checked':'')." type="radio" name = "concepto3" value = "3"/>
                           </td>
                    </tr>
            </tbody>
            </table>
";
 
 
    }//render
 
} // MyForm
 
?>