Recientemente he estado comentando sobre Zend Framework. Este proyecto se ha convertido en muy poco tiempo en algo muy importante para el desarrollo de aplicaciones web, y creo que seguirá creciendo en calidad y cantidad de features.

Pero hace unas semanas comencé un proyecto con una base de datos con muchas tablas, que requiere de un sistema de administración completo. A esta altura, lo que menos me gusta de desarrollar aplicationes web es el trabajo monótono y repetitivo de crear listas y forms para un backend. El Zend Framework todavia no tiene todos los utilitarios para la generación de código, ya sea de objetos relacionados con el modelo (las tablas) o menos aún la generación automática de un sistema de administración de dicha información.

El framework Symfony si lo tiene. Por este motivo, estas ultimas semanas estuve introduciendome a dicho proyecto, que por cierto, tiene una madurez y una calidad considerable, no por nada Yahoo lo eligió para alguno de sus sistemas.

Gracias a esto, ire comentando alguna de mis experiencias con Symfony, algunas serán muy basicas y otras no tanto. Espero sus comentarios.

Recientemente hemos visto como se han incrementado los ataques a instalaciones de phpMyAdmin.

En los logs de nuestros servers aparecen entradas como las siguientes:

De esto se desprenden las siguientes recomendaciones:
- Es importantisimo mantener actualizada la versión de phpMyAdmin para corregir problemas de seguridad.
- Igualmente importante es instalar la aplicación en un directorio con un nombre y ubicación no convencional, de esta forma, si llegara a descubrirse un nuevo problema, la instalación no será fácilmente accesible.
- De ser posible, es conveniente asegurar el directorio completo con autenticación de Apache utilizando AuthType, AuthName, etc.

Recientemente comencé un proyecto en el cual es necesario conectarse a un servidor remoto que provee un web service mediante SOAP.

Hace tiempo que no utilizaba SOAP, la última vez fue hace various años y el soporte de SOAP en PHP era bastante limitado. Debido al paso del tiempo, imaginé que ahora tendría mejor suerte y la experiencia sería mucho mejor y sin problemas.

Empecé a buscar qué opciones tenía para consumir el web service. Debido a que últimamente he estado utilizando el Zend Framework, lo primero que hice fue chequear si este disponía de librerías, con el resultado sorpresivo de que sólo tiene un cliente de XML-RPC.

Mi próximo paso fue revisar el manual de PHP, y la extensión SOAP aparecío como la solución a mi búsqueda.

El web service me ofrecía un WSDL, un documento XML que provee la definición de datos y métodos a utilizar. Idealmente, esto tiene que ser mapeado a una serie de clases en PHP con las mismas propiedades y métodos (esto se llama proxy). Un utilitario llamado wsdl2php me permitió generar todo el código PHP de una forma considerablemente rápida y sin problemas, aunque tuve que hacer algunas modificaciones menores en el código resultante para que todo funcione a gusto.

La extensión SOAP de PHP funcionó muy bien enviando datos simples, pero me topé con un problema al querer enviar un array de objetos. Diversos errores volvían de las llamadas al servidor. Seguí los consejos de la página del manual de PHP de utilizar SoapVar para generar el encoding necesario, pero sin un resultado positivo.

Como método de prueba y error, decidí probar la librería de SOAP de PEAR.

Luego de seguir las instrucciones de instalación, las cuales fueron bastante simples, me encontré con otro tipo de errores provenientes del servidor.

A este punto, me preguntaba si el problema estaba en el lado del servidor, por lo que cree un pequeño programa en  C# y .NET con Visual Studio. Este cliente SOAP funcionó de primera en cuestión de minutos !

Pude obtener el XML generado por .NET apuntando el cliente a un script
PHP que guardaba en un log el contenido del request via POST. Esto me
permitió comparar el XML generado por PHP y ver las diferencias, que
por cierto eran considerables.

Luego de buscar y comentar el problema con un colega, me comentó que estaba utilizando NuSoap. Esta es una de las primeras (sino la primera) de las librerías para crear servidores y clientes SOAP en PHP. En mi búsqueda inicial, la había encontrado, pero al ver que las últimas noticias en el sitio eran de 2004, imaginé que el proyecto había sido descontinuado y no estaría a la altura de las necesidades. Luego de mirar un poco mejor, descubrí que la última versión había sido editada en Noviembre de 2007, por lo que decidí a probar, otra vez.

Los primeros intentos también me dieron algunos errores, pero esta vez el XML era muy parecido a lo que debía ser aceptado por el servidor.

La clave fue preparar los parámetros a enviar de la siguiente forma:

 $param = array(’in0′ => new soapval( ‘AuthenticationInfo’, ”, $authinfo ),       
                        ‘in1′ => array( new soapval( ‘ContactInfo’, ”, $contact ) ) );      
 $result = $client->call(’addContacts’,$param );

En resumen, lo que parecería algo simple y fácil de hacer (como lo fue con C# y .NET), fue más complicado de lo esperado. Es notorio que luego de tantos años, el soporte de PHP sigue siendo deficiente, y que una librería que no es mantenida de manera activa haya dado los mejores resultados, el único resultado positivo.

Pido disculpas si no he dado suficientes ejemplos, o mensajes de error, espero poder comentar detalladamente cuando tenga más tiempo, si por lo pronto tienen alguna pregunta al respecto, no duden en contactarse mediante comentarios o via el foro de PHPes.

Hay muchas formas para convertir estructuras de datos como arrays y objetos a XML.

Convertir estos datos a XML facilita la transmisión de datos a través de sistemas heterogéneos, y es utilizado en web services, SOAP, Xml-Rpc, Ajax y demas tecnologías.

Una de las mejores opciones para convertir arrays y objetos es utilizar XML_Serializer de Pear. Pear es un repositorio muy completo de clases con distintas funcionalidades.

Con PHP 5, pear se instala por defecto. En un sistema Linux, generalmente se encuentra en /usr/local/php (si PHP es compilado desde el código fuente), o en /usr/share/pear si PHP fue instalado via RPM.

Para instalar XML_Serializer y sus dependencias estos son los pasos a ejecutar en la linea de comando del shell:

$ pear install XML_Util
$ pear install XML_Parser
$ pear install channel://pear.php.net/XML_Serializer-0.18.0

Una vez instalado, ya puede ser utilizado en un script, de la siguiente manera:

<?php

// Set error reporting to ignore notices

error_reporting(E_ALL ^ E_NOTICE);

// Include XML_Serializer

require_once ‘XML/Serializer.php’;

// Some data to transform

$palette = array(’red’, ‘green’, ‘blue’);

// An array of serializer options

$serializer_options = array (

   ’addDecl’ => TRUE,

   ’encoding’ => ‘ISO-8859-1′,

   ’indent’ => ‘  ’,

   ’rootName’ => ‘palette’,

   ’defaultTagName’ => ‘color’,

);

// Instantiate the serializer with the options

$Serializer = new XML_Serializer($serializer_options);

// Serialize the data structure

$status = $Serializer->serialize($palette);

// Check whether serialization worked

if (PEAR::isError($status)) {

   die($status->getMessage());

}

// Display the XML document

header(’Content-type: text/xml’);

echo $Serializer->getSerializedData();
?>

El resultado sería el siguiente:

<?xml version="1.0" encoding="ISO-8859-1"?>
<palette>
 <color>red</color>
 <color>green</color>
 <color>blue</color>
</palette>

(ejemplos obtenidos de Sitepoint)

Así como esto funciona con arrays, tambien funciona con objetos y sus propiedades.

Para aquellos que utilizan IIS y Windows como servidor web, llegan buenas noticias desde Microsoft.

El anuncio de que FastCGI fue incorporado a IIS6 significa que PHP ahora puede ser instalado utilizando esta interface, que en el mundo Unix ya es usada con mucho éxito por su flexibilidad y rapidez.

Me gustaría saber la experiencia de usuarios de FastCGI en IIS.

Más información de PHP sobre Windows aquí.

El mercado de editores para PHP está creciendo. Hasta hace poco, sólo habia unos pocos suficientemente buenos para nombralos.

Con el crecimiento de la complejidad de las aplicaciones web, ya no es productivo utilizar editores de texto, ya que es necesario poder hacer ‘debugging’, poniendo ‘breakpoints’. Otra gran utilidad es el profiling, que permite encontrar puntos en los cuales los programas consumen más tiempo y recursos.

Zend Studio fue uno de los precursores en este rubro. Recientemente fue puesto en disponibilidad la versión beta del plugin para Eclipse, un IDE que permite utilizar distintos lenguajes de programación instalando plugins.
Otro de los editores que han estado en el mercado por un buen tiempo es el ActiveState IDE, que recientemente cambió su nombre a Komodo IDE.
Tanto Zend Studio como Komodo IDE son versiones comerciales con un precio cercano a los $300 dolares.
Recientemente, apareció un nuevo jugador en este ámbito. A diferencia de los mencionados anteriormente, el Aptana IDE es open-source y tiene mucho futuro, bienvenido sea! La lista de ‘features’ es importante: soporte para Javascript, CSS, Adobe AIR, Ajax, SFTP, y muchas más.
Me gustaría saber que IDEs utilizan, asique no sean timidos y comenten!

El uso de PHP en sitios importantes y con alto tráfico sigue creciendo, lo que demuestra la madurez del lenguaje y plataforma, y los buenos resultados que estos otorgan.

A la impresionante lista de sitios (Yahoo, Skype, Techcrunch, ZDNet entre otros) se suma de.li.cio.us, un sitio para compatir bookmarks.

de.li.cio.us utilizará el framework Symfony que es utilizado por Yahoo en varios de sus sitios.

Más información.

Por fín! En el cumpleaños nro. 3 de PHP 4 el equipo de desarrollo de PHP anunció que no habrá más desarrollo de PHP 4 a partir del primer día de 2008. Se anunció también que sólo habrá nuevas versiones si se descubren problemas de seguridad críticos, y se analizará caso por caso.

Este anuncio marca un punto final al ciclo de vida de PHP 4, y forza a los desarrolladores a asegurarse que sus aplicaciones corren sin problemas en PHP 5, algo que vengo comentando desde hace rato.

Excelente noticia!

Qué opinan?

Como mencioné hace unas entradas en este blog, una preocupación importante es el hecho de que PHP 5 no ha reemplazado la versión 4. Un grupo de personas creo www.gophp5.org para promover el cambio.

Pasen el dato a quien pueda estar interesado.

Alexey Zakhlestin escribió en su blog acerca de su proyecto, “Application server in PHP“.

Quiere crear un servidor de aplicaciones para PHP, donde objectos puedan residir en memoria para no tener que crearlos en cada instancia. Parece muy interesante y habrá que estar al tanto del desarrollo.

En el blog también hay un comentario que hace mención a un proyecto similar, SRM (Script Running Machine).

Hace tiempo que venía buscando algo asi pero mi búsqueda no había arrojado resultados.