Resulta que el proyecto tiene URLs como esta: http://efemerides20.com/4-de-diciembre. Dónde realmente estoy pasando dos variables por la URL: el 4 indicando el día, y ‘diciembre’ indicando el mes. Así que en el archivo routing.yml de Symfony he creado la ruta así:

day:
  url:   /:day-de-:month
  param: { module: efemeride, action: day }
  requirements: { month: \w+, day: \d+ }

Cuando he accedido, me ha saltado error 404 diciéndome que no había niguna ruta que coincidiera con esa URL. EL problema es que por defecto Symfony no entiende los guiones como separadores en la URL, y solo interpreta como tales el punto ‘.’ y la barra ‘/’. Si queremos cambiar esto y que la ruta definida funcione correctamente tenemos que añadir el punto a lo que Symfony entiende como separadores de segmentos en la URL. Para ello hay que modificar el fichero factories.yml de la aplicación en cuestión (en este caso frontend).

En ese fichero (apps/modules/frontend/config/factories.yml) hay un pequeño apartado dedicado al enrutamiento que seguramente y si no lo habéis cambiado pondrá lo siguiente:

  routing:
    class: sfPatternRouting
    param:
      generate_shortest_url:            true
      extra_parameters_as_query_string: true

Pues para hacer que nuestra ruta funcione solo hay que añadir un nuevo parámetro a esa configuración de la siguiente manera en mi caso:

  routing:
    class: sfPatternRouting
    param:
      generate_shortest_url:            true
      extra_parameters_as_query_string: true
      segment_separators: ['/', '.', '-']

Es decir, añadir en el parámetro segment_separators todos los caracteres que querráis permitir como separadores.

Si tienes un servidor Ubuntu con Apache y quieres instalarlo a continuación te describo los pasos que he seguido yo para hacerlo (recuerda que si no estás como usuario ‘root’ tendrás que hacer sudo):

Instalar suvbersion:
apt-get install subversion libapache2-svn

Instalar Trac y el módulo de Python para Apache:
apt-get install libapache2-mod-python libapache2-mod-python-doc trac

Crear la carpeta que hará de ‘Document Root’ para poder acceder al trac via web, por ejemplo:
mkdir /var/www/trac

Si lo quieres proteger, como es mi caso, crea un fichero .htpasswd:
htpasswd -c /var/www/trac/.htpasswd admin

Preparar el Virtual Host:
vi /etc/apache2/sites-available/trac

Y escribir:

<VirtualHost *>
ServerAdmin mymail@domain.com
ServerName trac.domain.com

<Location /projects> #set up Trac handling
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /var/www/trac
PythonOption TracUriRoot /projects

#authentication scheme
AuthType Basic
AuthName "My Tracker"
AuthUserFile /var/www/trac/.htpasswd
Require valid-user

</Location>

ErrorLog /var/log/apache2/trac_error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/trac_access.log combined

</VirtualHost>

Vamos a crear un repositorio SVN para el código:
mkdir /var/lib/svn
mkdir /var/lib/svn/myproject
svnadmin create /var/lib/svn/myproject

Yo lo he preparado para poder tener diferentes tracs, así que estos pasos se pueden repetir:
mkdir /var/www/trac/myproject
trac-admin /var/www/trac/myproject initenv
sudo chown -R www-data:www-data /var/www/trac/myproject

Finalmente reiniciamos Apache:
/etc/init.d/apache2 restart

Y ya podríamos acceder a nuestro trac en este ejemplo en: http://trac.domain.com/projects

Espero que os sirva de ayuda.

Esa inclusión se realiza en el filtro sfCommonFilter, por lo tanto lo primero es crear un filtro que sustituirá a ese y que colocará los javascripts donde nosotros queremos, al final. Lo incluiremos en la carpeta libs/filters y en este caso se llamara myProjectCommonFilter:

<?php
/**
* myProjectCommonFilter Helper
*
* myProjectCommonFilter automatically adds javascripts to the bottom of the page and stylesheets to the top in the sfResponse content.
* This class is based in the sfCommonFilter helper of the symfony package.
*
* @package    symfony
* @subpackage filter
* @author     Alberto Varela <alberto@berriart.com>
* @version    2010-07-07
*/
class myProjectCommonFilter extends sfFilter
{
  /**
  * Executes this filter.
  *
  * @param sfFilterChain $filterChain A sfFilterChain instance
  */
  public function execute($filterChain)
  {
    // execute next filter
    $filterChain->execute();

    // execute this filter only once
    $response = $this->context->getResponse();

    // include stylesheets
    $content = $response->getContent();
    if (false !== ($pos = strpos($content, '</head>')))
    {
      $this->context->getConfiguration()->loadHelpers(array('Tag', 'Asset'));

      if (!sfConfig::get('symfony.asset.stylesheets_included', false))
      {
        $html .= get_stylesheets($response);
      }

      if ($html)
      {
        $response->setContent(substr($content, 0, $pos).$html.substr($content, $pos));
      }
    }

    // include javascripts
    $content = $response->getContent();
    if (false !== ($pos = strpos($content, '</body>')))
    {
      $this->context->getConfiguration()->loadHelpers(array('Tag', 'Asset'));
      $html = '';
      if (!sfConfig::get('symfony.asset.javascripts_included', false))
      {
        $html .= get_javascripts($response);
      }

      if ($html)
      {
        $response->setContent(substr($content, 0, $pos).$html.substr($content, $pos));
      }
    }

    sfConfig::set('symfony.asset.javascripts_included', false);
    sfConfig::set('symfony.asset.stylesheets_included', false);
  }
}

Ahora solo tenemos que decirle a Symfony que queremos utilizar este nuevo filtro en vez del sfCommonFilter y para eso tenemos que modificar el fichero config/filters.yml de nuestra aplicación y cambiar el filtro common:

common:
  class: myProjectCommonFilter

En un principio eso es todo, pero debéis tener cuidado si también escribís código Javascript directamente en la página sin usar ficheros externos. Tened en cuenta que siempre que ese código ‘inline’ necesite utilizar alguna de las librerías externas deberá estar escrito por debajo de las llamadas a éstas y por lo tanto tendréis que modificar el filtro que os he puesto más arriba.

• Firebug: Para mi es hoy en día una herramienta indispensable que me ayuda a depurar mi código Javascript y a solicionar problemas con el CSS entre otras cosas.
• YSlow y Google Page Speed son dos Addons que necesitan del Firebug para funcionar y que te ayudarán a mejorar la velocidad de carga de tu web.
• Web Developer: Una barra de herramientas que tiene multiples utilidades. Desde una regla para medir píxeles sobre el navegador hasta validadores o la posibilidad de desactivar el Javascript o las hojas de estilo.
• Search Status: Herramienta que ofrece información SEO sobre tu web y que prácticamente la uso para poder ver de forma clara los enlaces con ‘nofollow’.
• ColorZilla: Es solo un color picker, un cuenta gotas para poder conocer el valor en código CSS de cualquier color que estés viendo en una web.
• Screengrab: Es una herramienta para hacer capturas de páginas web, ya sean completas o selecciones. Muy útil para hacer documentación o reportar bugs.
• Dummy Lipsum: El nombre lo dice todo, simplemente un generador de ‘Lorem Ipsum’ para cuando necesitemos unos textos de prueba.
• IE NetRenderer: Una manera sencilla de poder ver lo que estamos haciendo en diferentes versiones del Fucking Internet Explorer. Sí, ya sé que hay más maneras de hacer eso incluso usando linux, pero ésta es rápida y en algunos casos no necesito más.
• HostAdmin: Creo que ha sido mi último descubrimiento y ahora no paro de usarlo. Me sirve para cambiar mi fichero /etc/hosts dónde fuerzo los dominios desde el propio Firefox, útil para cambiar entre dev, testing y producción.

Una de las mejores y más conocidas herramientas para diagnosticar problemas y encontrar soluciones al excesivo tiempo de carga de una web es YSLOW. Se trata de una herramienta adicional que se añade al Firebug de Firefox (creada por Yahoo) y que te advierte sobre incumplimientos de sus ‘Buenas prácticas para acelerar la carga de una web‘. Google enseguida recomendó utilizar esa herramienta a los webmasters, pero como tampoco quería ser menos y aunque también sigue recomendando YSLOW, decidió que tenían que hacer la suya propia (Page Speed) y redactar sus propias prácticas recomendadas.

Así que ahora tenemos dos buenas herramientas y dos buenas guías (coinciden en muchos puntos) a utilizar para mejorar la carga de nuestra web. Aquí os pongo algunos de esos consejos que creo que son bastante fáciles de aplicar, pero lo mejor es que leáis las guías con detenimiento:

• Hacer las menos peticiones HTTP posibles. Para ellos se puede por ejemplo unificar diferentes javascripts u hojas de estilo en una sola, o también unificar las imágenes utilizadas en el CSS en una y mostrar la que necesites utilizando la propiedad ‘background’.
• Minimizar los Javascript y CSS. Si utilizas alguna librería externa seguro que tiene su versión minimizada, y si no lo puedes hacer tu mismo usando herramientas como YUI Compressor (también de Yahoo por cierto)
• Añadir una cabecera de control de caché desde tu .htaccess, para que los navegadores de los usuarios nos echen una mano.
• Comprimir con Gzip. Algunos navegadores aceptan el contenido comprimido y los que usamos Apache2 solo tenemos que habilitar el módulo ‘deflate’ y añadir lo siguiente a nuestro .htaccess para conseguirlo.

  # Hacer GZIP de los JS CSS textos
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript

• Poner todo el CSS lo más comprimido posible y a poder ser en un solo fichero en la parte superior de la página, en el head. En cambio el Javascript es mejor ponerlo en el fondo, justo antes de cerrar la etiqueta </body>
• Reducir el número de DNS Lookups. Es decir, el número de dominios que se tienen que resolver al cargar una página. Aunque a veces cuando hay por ejemplo muchas imágenes se recomienda que se carguen desde diferentes dominios para poder descargarlas en paralelo.
• Usar dominios libres de cookies, y servidores ligeros y a ser posible CDNs para servir el contenido estático.
• …

Para los que no conozcan, este plugin de wordpress muestra en el dashboard los perfiles en redes sociales de la gente que comenta en tu blog, y también muestra sus blogs o webs; para lograrlo hace uso de la Social Graph API de Google. Creo que el plugin es una buena manera de poder acercarte más a tus lectores y la verdad es que todavía me siguen llegando trackbacks de gente que lo recomienda como uno de los mejores plugins sociales para WordPress.

Los cambios que he realizado:

• Comprobar compatibilidad con WP 3.0
• Cambiar licencia de GPL a GPL2
• Empezar a usar la clase SimplePie_File del core de WordPress para acceder a la API y así evitar las limitaciones de acceso a webs externas de ciertos hostings
• Permitir internacionalización y añadir castellano como idioma adicional
• Eliminar algunos warnings
• Arreglarlo para permitir la instalación automática desde el administrador de WP por FTP como el resto de plugins

Si nunca lo habéis probado, este es un buen momento

El plugin en el directorio oficial de WordPress:
http://wordpress.org/extend/plugins/meet-your-commenters/

Algunos dirán que lo que digo es una barbaridad, pero me parece una de las mejores herramientas y sobre todo la más ligera. Porque aunque en un principio parezca que es muy light, si sabemos cómo, podemos personalizarla y convertirla en una gran herramienta. Hace tiempo Miquel ya nos dió unos consejitos, pero como se nos ha pasado a Mac, ahora me tengo que buscar la vida :p

Os explico mi configuración y ya me diréis que opináis:

Lo primero es ir a las preferencias (Editar->Preferencias), y adecuaremos unas cuantas cositas:

- Pestaña ‘Ver’:

• Mostrar números de línea
• Resaltar línea actual
• Resaltar pareja del corchete

- Pestaña ‘Editor’:

• Insertar 4 espacios en lugar de tabulaciones
• Activar sangría automática
• Desactivar copia de seguridad, ya que crea archivos con el mismo nombre con el caracter ‘~’ al final, que hace que linux los trate como ocultos y que si los subimos al servidor nos traeran graves problemas de seguridad

Los colores que vienen por defecto para resaltar el código, no me gustan. Yo prefiero el fondo negro, ahorro energia y descanso la vista :p Así que nos vamos a la siguiente pestaña ‘Tipografías y colores’. De los esquemas existentes, tampoco me convencen ninguno, así que lo que hice fue descargarme otro. Aquí podéis descargar colores para Gedit, a mi el esquema que más me gusta y el que uso es el Darkwin. Para instalarlo, descargalo y luego en la pestaña pulsa en el botón ‘Añadir’ y agregalo.

Ahora llega el turno de instalar plugins o complementos para el Gedit. Por defecto trae algunos preinstalados que solo necesitamos activar desde la cuarta pestaña del panel de preferencias. Activaremos los siguientes:

• Herramientas externas – Permite ejecutar comandos o programas externos a Gedit para facilitarnos el trabajo. Más adelante explicaré como configurarlo.
• Panel de examinador de Archivos – Pone a nuestra disposición un panel lateral para examinar y acceder a los archivos de nuestro proyecto (Tecla rápida F9).
• Recortes – Permite insertar ‘recortes’ de código, o estructuras muy utilizadas (loops, ifs,…). Escribe la palabra clave y luego pulsa tabulador, el resto se escribirá solo.
• Sangrar líneas – Permite el sangrado de líneas de manera rápida mediante Ctrl+T.

Además de estos, creo que es una buena opción instalar otro plugin más, pero este no viene por defecto, se llama Symbol Browser. Se trata de un panel lateral que permite la exploración de objetos, funciones, defines,…

Yo os explico como le he instalado en Ubuntu 9.04, pero si necesitáis más información podéis ver este artículo que fue como lo descubrí. Lo primero que hay que hacer es instalar Exuberant Ctags, que es la herramienta ne la que se basa este plugin, luego descargamos el plugin y lo instalamos. No olvides después de instalarlo activarlo en la pestaña ‘Complementos’ como hemos hecho con los anteriores.

sudo apt-get install ctags
cd ~/.gnome2/gedit/
wget http://sourceforge.net/projects/symbol-browser/files/symbol-browser-bin/gedit-symbol-browser-plugin-bin-ubuntu-i386-0.1/gedit-symbol-browser-plugin-bin-ubuntu-i386-0.1.tar.gz/download #La URL puede cambiar al cambiar de versión
tar -xzf gedit-symbol-browser-plugin-bin-ubuntu-i386-0.1.tar.gz

Eso sería todo. Bueno, más bien casi todo. Por último habría que configurar el plugin ‘Herramientas externas’ para poder realizar diferentes tareas, como comprobar la syntaxis de nuestro código, consultar la documentación de PHP, ‘standarizar’ nuestro código con el programa PHP-Beautifer,… Para ver como hacerlo creo que lo mejor es que os paséis por la web de la que he recogido la mayor parte de la info que he puesto en este post, ya que mejor que él seguro que no lo explico: Micah Carrick

<?php

// TLDs válidos sacados de IANA (http://www.iana.org) el 21/07/2009
$validTLDs = array( 'ac', 'ad', 'ae', 'aero', 'af', 'ag', 'ai',
	 'al', 'am', 'an', 'ao', 'aq', 'ar', 'arpa', 'as',
	 'asia', 'at', 'au', 'aw', 'ax', 'az', 'ba', 'bb',
	 'bd', 'be', 'bf', 'bg', 'bh', 'bi', 'biz', 'bj',
	 'bl', 'bm', 'bn', 'bo', 'br', 'bs', 'bt', 'bv',
	 'bw', 'by', 'bz', 'ca', 'cat', 'cc', 'cd', 'cf',
	 'cg', 'ch', 'ci', 'ck', 'cl', 'cm', 'cn', 'co',
	 'com', 'coop', 'cr', 'cu', 'cv', 'cx', 'cy', 'cz',
	 'de', 'dj', 'dk', 'dm', 'do', 'dz', 'ec', 'edu',
	 'ee', 'eg', 'eh', 'er', 'es', 'et', 'eu', 'fi',
	 'fj', 'fk', 'fm', 'fo', 'fr', 'ga', 'gb', 'gd',
	 'ge', 'gf', 'gg', 'gh', 'gi', 'gl', 'gm', 'gn',
	 'gov', 'gp', 'gq', 'gr', 'gs', 'gt', 'gu', 'gw',
	 'gy', 'hk', 'hm', 'hn', 'hr', 'ht', 'hu', 'id',
	 'ie', 'il', 'im', 'in', 'info', 'int', 'io', 'iq',
	 'ir', 'is', 'it', 'je', 'jm', 'jo', 'jobs', 'jp',
	 'ke', 'kg', 'kh', 'ki', 'km', 'kn', 'kp', 'kr', 'kw',
	  'ky', 'kz', 'la', 'lb', 'lc', 'li', 'lk', 'lr',
	  'ls', 'lt', 'lu', 'lv', 'ly', 'ma', 'mc', 'md',
	  'me', 'mf', 'mg', 'mh', 'mil', 'mk', 'ml', 'mm',
	  'mn', 'mo', 'mobi', 'mp', 'mq', 'mr', 'ms', 'mt',
	  'mu', 'museum', 'mv', 'mw', 'mx', 'my', 'mz', 'na',
	  'name', 'nc', 'ne', 'net', 'nf', 'ng', 'ni', 'nl',
	  'no', 'np', 'nr', 'nu', 'nz', 'om', 'org', 'pa',
	  'pe', 'pf', 'pg', 'ph', 'pk', 'pl', 'pm', 'pn',
	  'pr', 'pro', 'ps', 'pt', 'pw', 'py', 'qa', 're',
	  'ro', 'rs', 'ru', 'rw', 'sa', 'sb', 'sc', 'sd',
	  'se', 'sg', 'sh', 'si', 'sj', 'sk', 'sl', 'sm',
	  'sn', 'so', 'sr', 'st', 'su', 'sv', 'sy', 'sz',
	  'tc', 'td', 'tel', 'tf', 'tg', 'th', 'tj', 'tk',
	  'tl', 'tm', 'tn', 'to', 'tp', 'tr', 'travel', 'tt',
	  'tv', 'tw', 'tz', 'ua', 'ug', 'uk', 'um', 'us', 'uy',
	  'uz', 'va', 'vc', 've', 'vg', 'vi', 'vn', 'vu', 'wf',
	  'ws', 'ye', 'yt', 'yu', 'za', 'zm', 'zw'
);

/**
 * Función is_valid_tld
 *
 * Función que comprueba si el TLD de una URL o un email es válido o no
 *
 * @param string $urloremail Email o URL a testear
 * @return boolean Devuelve TRUE si la entrada tiene un TLD válido
 */
function is_valid_tld( $urloremail ) {
	global $validTLDs;

	// Check if is an email
	if( strpos($urloremail, '@') > 0 && strpos($urloremail, '://') === false ) {
		// Is an email, get TLD
		$tld = end( explode('.', $urloremail) );
	}
	else {
		// Is an url, get TLD
		$host = parse_url($urloremail, PHP_URL_HOST);
		$tld = end( explode('.', $host) );
	}

	return in_array($tld, $validTLDs);
}

?>

Pues aprovechando esta salida, y teniendo en cuenta que se me ha ocurrido una semi-idea para la que tal vez pueda usar esta API, he creado una clase en PHP para facilitar su manejo, Minube PHP. Teniendo en cuenta que la idea puede no llegar nada o quedarse aparcada como tantas otras cosas, he creido conveniente publicar la clase para que otros que si vayan a llevar a cabo las suyas se ahorren el trabajo.

Minube PHP: http://www.berriart.com/minube-php/

(Hace más de un mes que no escribía en el blog, soy un poco vago ¿verdad?)

Bueno, pues hace poco que me he enterado que la propia API de Google Maps te permite hacerlo sin muchas complicaciones. Así que por si acaso hay por ahí algún despistadillo como yo que se páis que lo podéis hacer de la siguiente manera (más abajo hay un ejemplo completo):

/* Primero seteamos el centro a cualquier punto */
map.setCenter(new GLatLng(0,0),0);

/* Creamos un objeto vacio GLatLngBounds() */
var bounds = new GLatLngBounds();

/* Por cada uno de los puntos a incluir en el mapa extendemos los límites del objeto */
/* En este caso latlng debería ser un objeto GLatLng */
/* Ejemplo: var latlng = new GLatLng(43, -2); */
bounds.extend(latlng);

/* Cuando hayamos incluido todos los puntos seteamos el centro y el zoom usando el objeto 'bounds' */
map.setZoom(map.getBoundsZoomLevel(bounds));
map.setCenter(bounds.getCenter());

Su modo de empleo se puede ver mejor en el siguiente ejemplo. Aprovechando que hoy se jugará la final de Copa, he creado un pequeño mapita con los puntos de Bilbao donde habrá pantallas gigantes para seguir el partido de mi querido Athletic contra el Barça, el zoom y el centro del mapa se calculan usando el método que he explicado más arriba.

http://www.berriart.com/examples/ajustar-centro-y-zoom-google-maps.html

Y ya puestos, os comento a los twitteros del Athletic que podéis conseguir una camiseta oficial gracias a Bilbao.bi si estos días comentáis la final por Twitter. Para obtener más información seguir el siguiente enlace.

Si estos días no me véis por la internete es que hemos ganado la copa Athletic, beti zurekin!