Me gustaría compartir una entrada del blog de desarrolladores del NYT en la que hablan de cómo afrontaron las retransmisiones en directo de los partidos del Mundial:
http://open.blogs.nytimes.com/2010/07/13/behind-the-scenes-of-a-live-world-cup/
Se pueden leer algunas ideas interesantes.
Finalizando el proyecto de migración de los blogs a WordPress, ya en la fase de prueba de funcionalidades, me di cuenta de que, al dar de alta una entrada, WordPress permite por defecto muy pocas etiquetas HTML. Así que tenía la necesidad de permitir al menos las que incrustan vídeo, ya que son muy usadas.
WordPress usa TinyMCE en la parte cliente como editor “Rich-text”. ¿Pero en servidor, cómo hace la validación?
Pues lo hace mediante la librería KSES.
KSES se configura de forma muy parecida a TinyMCE. En un array definimos cuáles son las etiquetas permitidas, los atributos de dichas etiquetas e, incluso, los valores permitidos para dichos atributos. De esta forma, permite un filtrado mucho más potente que la función strip_tags de PHP.
Al final he optado por usar el plugin Extend KSES, que implementa la librería KSES y proporciona toda la funcionalidad que necesitaba.
Leyendo información sobre algunos de los temas que salieron en la reunión de ayer (PHPDoc, guías de estilo, etc.), he estado leyendo sobre los hooks de Subversion.
Los hooks son scripts que se pueden lanzar automáticamente en la ocurrencia de ciertos eventos: start-commit, pre-commit, post-commit, etc.
Nosotros no los estamos usando, pero podríamos automatizar algunas tareas, como avisar por email cuando alguien sube cambios al repositorio, comprobar que el PHP que subimos es sintácticamente correcto, que cumple ciertas reglas de dependencia o lo que hablábamos de limpiar y chequear nuestro código antes de subirlo. Incluso pasar una batería de pruebas.
Podéis encontrar algo más de información en estas páginas:
Rendera es una aplicación online mediante la cual, sin necesidad de instalar nada, podemos escribir código HTML5, CSS3 y Javascript (con soporte para jQuery) y ver cómo queda en tiempo real.
Es una buena opción para hacer pruebas rápidas. Además, la página incluye algunos ejemplos que nos pueden servir de inspiración.
Lógicamente, los resultados dependerán del navegador que estemos utilizando. No todos ellos dan soporte a todas las funcionalidades de estas nuevas versiones de los estándares.
Vía wwwhat’snew.
Lo ideal, cuando necesitamos obtener datos de un proveedor, es acceder a un servicio web que nos los proporcione en algún formato estructurado (XML, JSON o similar). Lamentablemente, no siempre disponemos de este servicio, pero sí que es posible que podamos obtener la información en alguna página web, en formato HTML.
Para ello, lo que tenemos que hacer es interpretar el HTML, extrayendo los datos que nos interesen. En nuestra ayuda viene una librería como PHP Simple HTML DOM, que nos permite realizar esta función de manera sencilla, empleando selectores como los de jQuery.
La pega (que no debería ser tal): sólo funciona con PHP 5 en adelante.
Por descontado, nuestro parser estará íntimamente ligado al código HTML de la página. Cualquier mínimo cambio puede dejar nuestro script inutilizable. Pero al construirlo con esta librería, como las reglas de selección son bastante claras, es fácil adaptarlo.
La salida de un script PHP lo normal es que sea en la salida estándar, que es donde se vuelca la información para que sea recogida por el cliente de turno. Esto suele hacerse mediante las sentencias echo y print que siempre imprimen en la salida estándar, pero ¿y si quiero enviar un mensaje a la salida de error?.
Cuando programamos nuestros scripts de linea de comandos surge la cuestión de necesitar trabajar con el resto de canales de entrada y salida que define el sistema. De los canales definidos en el sistema como salida tenemos dos, la salida estándar (stdout) y la salida de errores (stderr). Son dos canales distintos por donde se puede volcar la salida de un script, y por lo tanto nos puede interesar poder especificar porque canal quiero mandar la información. Lógicamente la salida estándar será para los mensajes de proceso y la de error para mensajes que indiquen un comportamiento anómalo al proceso.
Para esto PHP define una serie de secuencias de entrada y salida para poder utilizar con las funciones de tratamiento de ficheros, y que nos permite tratar información sobre los canales del sistema. Sobre los canales de salida que nos interesan están php://stdout y php://stderr que son los que ofrecen acceso al canal de salida estándar y de error respectivamente. Estos canales están definidos en unas constantes (STDOUT y STDERR) que definen el descriptor de cada canal, y que permiten trabajar con ellos usando directamente las funciones de escritura…
fwrite(STDOUT, "Conectando a servidor");
fwrite(STDERR, "ERROR: No se pudo acceder al recurso");
Al utilizar la constante STDERR como descriptor de fichero en la función de escritura, todos los mensajes que se escriban saldrán por el canal de error.
Así en nuestro scripts podremos diferenciar este canal…
php -q script.php 2> /var/log/script/script_php.error.log
Para ejecutar un script de PHP podemos tener el intérprete compilado de dos formas diferentes: CGI y CLI
PHP actúa como si fuera un script de linea de comando. Es la versión que se tiene en el entorno de desarrollo, y sería la opción más adecuada para lanzar los scripts que se programan como tareas en el sistema.
No tiene asociada ninguna excepción sobre lo que hemos visto.
Integrado en los entornos de test y producción.
Usado antiguamente (y puede que actualmente) como el interprete que se configuraba en los servidores web para poder integrar PHP. Esta versión esta más orientada a ejecutar scripts en un entorno web, y no desde linea de comando como suelen ser nuestro caso. Es por esto que existen diferencias con la versión CLI y en este caso con los descriptores de ficheros.
No existen las constantes que representan los canales de salida STDOUT y STDERR, y por lo tanto hay que realizar la escritura de otra manera…
$fd_err = fopen("php://stderr","w"):
fwrite($fd_err, "ERROR: No se pudo acceder al recurso");
… para poder trabajar con la secuencia de error.
Para no tener que escribir código diferente entre las versiones se puede definir las constantes para que el trabajo sea igual y quede como si no hubiera diferencia…
if(!defined('STDERR')) define('STDERR', fopen("php://stderr","w"));
fwrite(STDERR, "ERROR: No se pudo acceder al recurso");
… así, si la constante no está definida se creara, y nuestro código quedaría igual para los diferentes entornos.
