Mi rincón en Internet

Hay veces que tenemos problemas en un servidor de producción y tenemos que mantenerlo en pie sea como sea hasta que encontramos una solución.

Se me ocurrió que, si miraba en el log de apache y buscaba la cadena típica que deja el PHP (o lo que esté fastidiando) cuando se “estropea”, podría automatizar el reinicio del servidor hasta que diese con el problema. En mi caso, el mod_php5 hacía que el Apache se muriese con un “segmentation fault”.

Éste es mi sencillo “script”:

LINEAS=20
TOPE=18
CADENA="exit signal Segmentation fault"
REINICIAR="service httpd restart"
FICHREPORTE="/root/resultadosReinicios.log"
FICHLOG="/var/log/httpd/error_log"
NUMLINEASCHUNGAS=`tail --lines=$LINEAS $FICHLOG | grep "$CADENA" | wc -l`
 
if [ $NUMLINEASCHUNGAS -gt $TOPE ]; then
         $REINICIAR
         echo `date` ": se ha reiniciado el apache." >> $FICHREPORTE
         cat <<EOF | sendmail -t 
From: `hostname`
To: mi@direccion.correo
Subject: Acabo de reiniciar el Apache
 
Hola, soy el script que monitoriza el Apache de `hostname` y lo acabo de reiniciar.
EOF
 
fi

La finalidad de este script es poderte ir a dormir y al menos estar tranquilo durante la noche sin que el teléfono suene
En distros de la “familia Debian” se reiniciaría el Apache con un /etc/init.d/apache2 restart

Hace un tiempo comentaba los problemas que surgían cuando se trabaja con diferentes “encoding”.
Lo más seguro hoy en día es trabajar con el mismo “encoding” en todas las capas y sistemas: bases de datos, ficheros php, plantillas html, ficheros js, configuración del servidor web, …
Lo malo es que no siempre esto es posible. Muchas veces tenemos que integrar contenidos o hacer que dos sistemas diferentes interaccionen y cada uno puede estar configurado de diferente manera.
Para estas tareas de conversión, existen muchas herramientas y funciones. Por ejemplo, en PHP tenemos la función iconv(). Es muy sencilla de utilizar:

string iconv ( string $in_charset , string $out_charset , string $str )

El problema que surge a menudo es cuando estamos pasando de un encoding más “rico” (p. ej., UTF-8) a otro más restringido en caracteres (p. ej., ISO-8859-1). Si se aplica la función sin más, se nos puede cortar la cadena que estamos convirtiendo cuando se encuentra con un carácter extraño al “encoding” de destino (las famosas “comillas tipográficas” de los procesadores de texto, por ejemplo, dan muchos problemas).
Afortunadamente, la función iconv() está preparada para estos casos. Si se utiliza el parámetro $out_charset con la cadena //TRANSLIT, los caracteres problemáticos pueden ser convertidos a un carácter similar en el “encoding” final:

$txtFinal = iconv("UTF-8", "ISO-8859-1//TRANSLIT", $txtOriginal);

¿A qué desarrollador web no le ha pasado alguna vez tener algo que no funciona, probar mil cosas y luego darse cuenta que era un error o fallo trivial? Para tirarse de los pelos, ¿verdad? Voy a relatar algunos.

• ¿Por qué no entra por el if?
  Este es típico: un if que controla una sóla condición. Ejemplo en PHP, pero aplicable a cualquier lenguaje -excepto Python

  loQueSea();
  if ($varControl)
      hazAlgo();
  otraCosa();

  Al cabo de un rato piensas que  si entra por el if, además debes cambiar otra variable y escribes:

  loQueSea();
  if ($varControl)
      hazAlgo();
      $otraVarControl = true;
  otraCosa();

  Y nunca consigues que otraVarControl se quede a true. ¿Qué pasa aquí? Fácil: no hemos puesto llaves al if.
  Conclusión: aunque el if sólo controle una sentencia, mejor con llaves siempre. Al final siempre va a haber más de una sentencia bajo ese if:

  loQueSea();
  if ($varControl) {
     hazAlgo();
     $otraVarControl = true;
  }
  otraCosa();

• ¡No pilla los cambios!
  Es la típica llamada de un cliente (o un jefe): ¡me has dicho que cambiaste el XXX y no lo veo, sigue como antes!
  Nuestro XXX puede ser un fichero .js, un .css, una imagen o cualquier otro tipo de recurso que estamos seguros que hemos actualizado y que aún así, nos dicen que no lo ven.
  A los desarrolladores web no nos gustan mucho las cachés, ni proxies, etc, y además nos conocemos todos los típicos trucos para hacer un refresco completo de la página, pero nuestros jefes, clientes y usuarios sí que utilizan cachés (en el navegador, en su proxy). Además no se saben esos “mágicos” atajos de teclado que utilizamos sistemáticamente (Ctrl-Shift-R, Ctrl-F5 en IE) para ver cómo va nuestro trabajo en el navegador.
  Solución: forzar el refresco. Supongamos el siguiente HTML que incluye un .js sobre el cual hemos hecho cambios importantes:
  <html>
  <head>
  <script src=”fichero.js” type=”text/javascript”></script>
  …
  Subimos el fichero actualizado al hosting o servidor de producción, hacemos la llamada o enviamos el correo de rigor (”oye, ya está hecho”) y al rato tenemos el típico “yo lo veo como antes”.
  Nuestro fallo: presuponer que el entorno del usuario es el mismo que el nuestro. Puede que esté navegando a través de un proxy (suelen guardar en caché los elementos que le solicitan), su navegador puede estar configurado para que también “cacheé” algunos recursos, etc.
  La solución más fácil es añadir un “query string” a la llamada al recurso. Esto nos garantiza que será tratado como un fichero diferente y cargado de nuevo:
  <html>
  <head>
  <script src=”fichero.js?version=1″ type=”text/javascript”></script>
  …
  
  Nos da igual cuál es esta “query string”, simplemente lo que queremos es que todos los proxies, navegadores y demás clientes entiendan que es un recurso diferente. Este truco es válido para CSS, imágenes, swf. Por ejemplo, en la regla CSS:

  div.cabecera {background-image: http://mi.servidor.com/img/fondo.png?r=1}

  Si se tiene todo el trabajo integrado en un sistema de control de versiones, es muy útil configurar nuestro “deploy” para que este “parámetro” tome siempre el número de versión. Si estamos desarrollando la aplicación todavía, el truco infalible para que el navegador siempre lea los recursos como “nuevos” es hacer las llamadas así en nuestro fichero .php:

  <html>
  <head>
  <script src=”fichero.js?version=<? echo time() ?>” type=”text/javascript”></script>
  <link href=”fichero.css?version=<? echo time() ?>”  rel=”stylesheet” type=”text/css” />
  

• Página en blanco, no se ve nada. ¿Qué falla?
  Este típico error suele pasar cuando PHP está configurado para no mostrar ningún error (lo más recomendable en producción). Las soluciones son dos:
  • Editar el php.ini y cambiar el ajuste “display_errors” (nada recomendable).
  • Escribir la siguiente instrucción para saltarnos este ajuste para un “script” en concreto:

    <?php
        ini_set('display_errors', 1);
        // Sigue nuestro script

    La función ini_set() permite ajustar parámetros de configuración para un script determinado. Es muy útil cuando algo falla y no vemos dónde.

• Los usuarios de mi aplicación no pueden hacer “login”, o unos acceden al perfil del otro.
  Este es un error bastante insidioso y puede tener diferentes orígenes. Hay que conocer cómo maneja PHP las sesiones: PHP asigna al usuario una ‘cookie’ única con el identificador de sesión. En el servidor se guardan ficheros de sesiones en un directorio, un fichero para cada sesión ‘asignada’ a un usuario. Problemas potenciales:
  • El usuario no está aceptando cookies: en este caso es imposible que PHP asocie una sesión y sus datos con un usuario. Se puede configurar para que PHP mande el identificador de sesión en la URL, pero no es nada recomendable. Se puede comprobar si el usuario acepta cookies intentando enviarle una y leyéndola a continuación. Si no la tenemos, sacamos una advertencia al usuario.
  • El directorio del servidor donde se guardan las cookies no está accesible (problemas de permisos, falta de espacio, etc).
  • Si tenemos una configuración con balanceo de carga (varios servidores atendiendo a la misma URL) tenemos que asegurarnos que una vez que un usuario ‘entra’ por un servidor, sigue siempre en el mismo servidor. Otra solución es guardar las sesiones en una base de datos en vez de almacenarlas como ficheros.

Hay muchísimos más fallos tontos que nos podemos encontrar, pero éstas son algunas de las que más tiempo me han hecho perder

No me lo puedo creer, pero no he encontrado un motor de búsqueda que funcione para consultar las funciones de PHP desde Firefox.

El único que he encontrado (https://addons.mozilla.org/en-US/firefox/addon/8984) no sé porqué no lo puedo instalar (tengo cuenta en addons.mozilla.org).

No he sabido buscar, puede que sea un poco torpe; así que he hecho un copia-pega de uno de los que tenía instalados y retocando un par de parámetros, ya tengo el mío.
Está en esta dirección: http://davidasorey.net/static/php-manual-search.xml

Para utilizarlo, sólo hay que salvar el fichero xml en nuestro directorio “Profile”/searchplugins de Firefox y listo.

Un día de estos lo subiré a addons.mozilla.org

Cuando uno se enfrenta con un desarrollo web que debe atender miles de visitas diarias uno de los mayores problemas es el rendimiento o la velocidad con la que se cargan las páginas.

Si el lenguaje de programación que usamos es PHP existen herramientas que aceleran en gran medida la ejecución del código. Las que más conozco son eAccelerator y XCache.

Estos optimizadores de código funcionan “precompilando” los scripts en PHP a una especie de “bytecode” que se ejecuta mucho más rápido que la interpretación directa del script. La mejora es espectacular.

He instalado eAccelerator en un servidor de producción y realmente se nota mucho el aumento de velocidad. No puedo valorar XCache ya que no lo he usado más que para hacer alguna prueba que otra.