XHProf: alternativa a XDebug desarrollada por Facebook

ByLuis

XHProf es una librería de PHP desarrollada por Facebook y liberada en marzo de 2009 que nos facilita el debug en nuestras aplicaciones.

Los datos que devuelve son muy interesantes:

  • Número de llamadas de una función a otra
  • Tiempo de ejecución de una función cuando es llamada desde otra
  • Tiempo de CPU de una función cuando es llamada desde otra
  • Diferencia en el uso de memoria de PHP en una función cuando es llamada desde otra

Una alternativa a XDebug muy interesante.

XHProf

Similar Posts

Tratar imagen para romper reCAPTCHA con PHP

ByLuis

Para aquellos que usan JDownloader (y Windows) les gustará la noticia de que ha salido un plugin para romper reCAPTCHA, que aunque está en versión beta, rompe bastantes códigos.

Para hacerlo, realiza varias técnicas para convertir la imagen en una que pueda ser leída por un OCR, y lo curioso de todo esto es que está realizado en PHP y pasado a C++ con HIPHOP de Facebook.

El código lo podéis ver en el PDF que viene en el plugin.

reCAPTCHA ausgehebelt / antirecaptcha

Más internacionalización mediante PHP

ByLuis

La internacionalización es un tema del que ya he hablado con anterioridad, pero para mí es algo fundamental, quizás sea por la cantidad de proyectos en los que he trabajado que necesitaban de esta funcionalidad, a veces, para mi gusto, mal tratada.
En el anterior artículo ya hablamos de arrays asociativos, un array con clave el código del texto que deseamos traducir (un buen uso sería el mismo texto en el idioma inicial), y con valor el texto traducido. Debería haber un texto para cada idioma y luego al inicio de la aplicación una asignación del array correspondiente para el idioma.
En el artículo que comentamos nos explican cómo realizarlo mediante el uso de la funciones gettext, una interfaz de programación NLS, y el uso de ficheros PO (un fichero de texto plano que contiene el texto original y el traducido).
Sobre este método me da que pensar sobre su rendimiento. PHP al ser interpretado, todo lo que se meta, se lee y se interpreta. Si no se usa caché para los php, es mejor no introducir código innecesario en nuestros scripts. Según parece, el array asociativo con las traducciones se leerá completo en cada ejecución, cuando en algunos casos no será necesario traducir ni la mitad de las palabras.
En algunos proyectos el diccionario era bastante extenso, por lo que me planteo posibles soluciones para optimizar el código. Una posibilidad es dividir en diccionario por grupos independientes, pero este método hace que gestionar los diccionarios sea una labor más complicada. La otra solución es una carga inicial en cada script de las palabras estrictamente necesarias, habría que evaluar si el tiempo de carga de las palabras necesarias (para lo cual es necesario una operación inicial) es inferior al tiempo de carga completo (tan solo leer e interpretar). ¿Qué pensáis vosotros?
Give your web app international appeal

Añadir class a la lista de categorías descriptivo en WordPress

ByLuis

Uno de las cosas que no me gustan de WordPress es la costumbre de añadir las clases a los elementos basados en el ID del mismo y no en su slug. Esto ocurre en todo, pero en este caso es con la lista de categorías generadas por wp_list_categories, devolviendo un HTML parecido a este:

  • Mi categor&iactute;a

    • Si queremos indicar estilos específicos para estas categorías, por ejemplo para añadir un icono a cada categoría, no nos sirve el class basado en ID, porque nos encontramos con que dependiendo de cuando se genere esta categoría, habrá que cambiar el css, siendo más lógico obtener un código como este:

  • Mi categor&iactute;a

    • Para poder conseguir esto, deberíamos añadir en nuestro functions.php lo siguiente.

    
add_filter('wp_list_categories', 'mete_slug_en_class', 10, 2);
function mete_slug_en_class($output, $args) {
  return preg_replace_callback('#]+)class="([^"]+)"([^>]*)>]+)>([^<]+)<\/a>#', function($m) {
    return ''.$m[5].'';
  }, $output);
}

    Mejora el rendimiento de PHP

    ByLuis

    Unos consejos interesantes sobre cómo mejorar el rendimiento de tus páginas cuando usas PHP.

    • Caché de objetos: cada vez que llamas a una página se llama al compilador y se vuelve a procesar, aunque no haya cambiado. Si se cachean los objetos de PHP (parecido a lo que ocurre con JSP), la primera vez se compilaría y la siguiente se usaría la compilada. Una herramienta gratuita que nos permite realizarlo es Turck MMCache for PHP
    • Sistema de plantillas: se trata de una caché de contenido. Es útil cuando existe datos estáticos que se muestran más de una vez y no se quiere que se recargue. Los sistemas de caché también proveen una separación entre código y HTML, que no solo mejorará el rendimiento, sino que además hará más sencilla una futura actualización. La mayoría de los sistemas de plantillas para PHP está disponibles aquí: Smarty Templates, Pear Templates y PHP savant.
    • Sistema distribuido de caché de objetos: se trata de tener la mayoría de la BD en memoria, usando para ello memcached. Claro, que esto realmente puede ser poco útil en sitios que no tengan un elevado número de visitas.
    • Variables de PHP que se deben usar:
      variables_order = ‘GPC’
      register_argc_argv = ‘Off’
      register_globals = ‘Off’ (también útil para temas de seguridad)
      always_populate_raw_post_data = ‘Off’
      magic_quotes_gpc = ‘Off’
      A parte de desactivar los logs de errores, consumen tiempo y recursos y a parte si tienes un error no muestras información que quizás no quieras.
    • Comprensión de salida: mediante PHP, comprimimos la salida usando el formato zip. En esta posibilidad no estoy del todo de acuerdo, porque los recursos que se utilizan en la compresión pueden ser superiores a los que se usan para enviar la página, como ya indicamos en otra ocasión.

    Fast PHP

    Vía / dzone

    Nueva versión de XDebug

    ByLuis

    xdebug.pngXDebug acaba de sacar una nueva versión. Para aquellos que no lo conozcan, se trata de una extensión que permite depurar tus scripts PHP debido a la cantidad de información que ofrece:

    • Trazas, con parámetros que admiten funciones definidas por el usuario, muestra el nombre de la función, del archivo y el número de línea.
    • Asignación de memoria.
    • Protección contra recursividad infinita.

    La nueva versión ofrece muchas mejoras y nuevas funcionalidades: mejoras en las trazas, enviar las trazas a ficheros, depuración remota y una documentación reescrita.

    XDebug

    Vía / PHPDeveloper.org

    Laboratorio: publicar en Twitter mediante CURL

    ByLuis

    Para mí, uno de los mayores fracasos de Twitter es su API, una limitación de su uso increíble para algo que le podría dar mucho juego a la aplicación. Ahora mismo no sé en cuánto está el límite, pero la posibilidad de realizar una aplicación basada en Twitter es una pesadilla.

    Para aquellos que no quieran sufrir lo que hemos sufrido con TwitterPoster (los espacios en blanco es porque la gente actualiza su imagen y no podemos recuperar la de todos los usuarios por el límite en el API de Twitter), les recomiendo usar Twitter mediante CURL.

    Os paso un script sencillito que he realizado:

    <?php
// Primer hacemos login
$url ="https://twitter.com/sessions";
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
// Por si tienen limitación por navegador
curl_setopt($ch, curlOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)");
// Poned una ruta para las cookies
curl_setopt ($ch, CURLOPT_COOKIEJAR, '/temp/');
curl_setopt ($ch, CURLOPT_COOKIEFILE, '/temp/');
curl_setopt ($ch, CURLOPT_POSTFIELDS, "username_or_email=[usuario]&password=[contraseña]");
// Para que funcione el https
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, curlOPT_SSL_VERIFYHOST, 2);
curl_exec ($ch);
// Cargamos el home, porque Twitter añade dos campos ocultos para poder publicar por web
$url ="http://twitter.com/home";
curl_setopt($ch, CURLOPT_URL, $url);
$result = curl_exec ($ch);
// Recuperamos los campos ocultos
preg_match('//', $result, $match);
$authenticity_token = $match[1];
preg_match('//', $result, $match);
$siv = $match[1];
// Insertamos el texto
$res = $url ="http://twitter.com/status/update";
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_POSTFIELDS, 'siv='.$siv.'&authenticity_token='.$auth.'&status=[texto]');
curl_exec ($ch);
curl_close ($ch);
unset($ch);
?>

    ¿Qué fallo tiene este script? pues que si cambian el HTML (campos de formulario, …) o las URLs deja de funcionar, pero al menos no tenemos limitaciones. Eso sí, es más costoso para sus servidores y para los nuestros, porque en vez de hacer una llamada, hacemos 3, y en nuestro caso, a parte parseamos una página para obtener dos campos ocultos.