Hay algunas palabras que la gente busca mucho pero que dependiendo del tipo de web que tengas no interesa posicionar. Por ejemplo carlos al parecer se busca mucho en google pero los visitantes que me lleguen por carlos no son realmente visitantes interesantes. Y eso que al parecer las visitas que puede reportar son bastantes:

Pero sí que sirve para una cosa si sales el primero, para poder decirle a la gente que si buscan carlos en google el primer resultado es el tuyo. Da prestigio.

Y aunque Carlos Blanco suele comentar que no le acaba de gustar que le conozcan más por su blog que por las empresas que tiene tengo la impresión que sí le gusta mencionar que sale el primero. Pues mi objetivo es conseguir eso mismo, salir el primero aunque tengo ya muy claro que de momento no lo voy a conseguir, la diferencia de los enlaces e influencia entre él y yo es abismal pero en el intento quiero ver hasta donde puedo llegar.

De momento salgo bastante mal, en la posición 58 buscando en google.es así que por lo menos hay buen margen de mejora aunque hay muchos puestos ocupados por pesos pesados. No tengo muy clara la estrategia a largo plazo pero de momento voy a hacer un pequeño experimento, en lugar de ayudarme con enlaces entrantes con carlos voy a probar a la inversa, poniendo unos cuantos enlaces a páginas bien posicionadas por la keyword carlos:

Blogger o páginas personales bien posicionados:

• Carlos Blanco
• Carlos García Argos
• Fotolog de Carlos Cazurro (me sale en gris con Firefox ???)
• Carlos de MotorPasion
• El diablo en los Detalles
• Carlos Mantero
• Carlos Leopoldo
• Carlos Macias
• Carlos González
• Carlos Capote

Famosos:

• Karlos Arguiñano y Karlos Arguiñano (por duplicado y en las sugerencias de Google)
• Carlos Checa (no me va)
• Carlos Sainz
• Carlos Saura
• Carlos Sastre
• Carlos Herrera
• Carlos Ruiz Zafion

Profesionales varios:

• Carlos Diez
• Carlos Chaouen
• Carlos Giménez
• Carlos Ferrater
• Carlos Vermut
• Carlos Sann
• Carlos Jean
• Carlos Barredo
• Carlos Manzano

De la Wikipedia, que no falte;

• Carlos I de España
• Carlos Slim
• Karlos Arguiñano

Instituciones:

• Universidad Carlos III de Madrid
• Universidad Rey Juan Carlos
• Instituto de Salud Carlos III
• Historia de Carlos V
• Hospital Clínico Sant Carlos
• Hospital Carlos Haya

He separado famosos y profesionales varios y puede ser que alguien me diga, pero si el tío ese que has puesto como profesional es bastante famosos. Vale, puede ser pero yo no lo conozco y la clasificación no pretende ser académica.

Y bueno, me dejo un montón pero es que ya me he cansado, ahora falta esperar a ver cómo influye este post aunque como todos los experimentos SEO al concurrir más variables son siempre complicados de evaluar. Así que no me importa si me empezáis a poner enlaces cómo posesos con el texto carlos , no me enfadaré :P

Actualización

Ahora salgo en la posición 47, una mejoría de 11 puestos lo cual no está mal aunque todavía no es una buena posición. Ahora (26 agosto) el 42.

Se han encontrado varias vulnerabilidades en Drupal 5 y Drupal 6 por lo que es altamente recomendado actualizar.

Como es habitual además de corregir los agujeros de seguridad también se han corregido algunos bugs menores para Drupal 6 y para Drupal 5.

Esto últimamente ya parece Wordpress....

Lokiyo en un comentario de "el rediseño de Drupal.org" nos informa que ya ha sido escogida la empresa que se encargará de hacer el rediseño de Drupal.org: será Mark Boulton Design.

Entre los trabajos más destacables están Coolspotters y Noozz.com. Puedes ver más trabajos en su portfolio. Personalmente me gusta bastante el diseño de Coolspotters, a ver si Drupal.org por fin tiene el aspecto que se merece.

Ged de Drupalweb me lanza el reto de explicar un poco cómo funciona el cron en Drupal. En realidad lo hizo hace unos días pero no lo vi hasta ayer, pero bueno, supongo que más vale tarde que nunca.

Realmente pide saber más sobre el cron y sobre el ping, pero yo he escogido el cron. El ping se lo dejo a Pedro o a Daniel o a quien quiera.

Cómo introducción estaría bien saber que es el cron (de la wikipedia):

En el sistema operativo Unix, cron es un administrador regular de procesos en segundo plano (demonio) que ejecuta programas a intervalos regulares (por ejemplo, cada minuto, día, semana o mes). Los procesos que deben ejecutarse y la hora en la que deben hacerlo se especifican en el archivo crontab.

Cron se podría definir como el "equivalente" a Tareas Programadas de Windows. Los usuarios habilitados para crear su archivo crontab se especifican en el archivo cron.allow. De manera análoga, los que no lo tienen permitido figuran en /etc/cron.d/cron.deny, o /etc/cron.deny, dependiendo de la versión de unix.

Es decir, que es un programa que ejecutará en los intervalos que le digamos un determinado programa. Esto se hace usando el comando crontab -e o desde el panel de control de tu hosting. Lo siguiente es una linea del cron:

30 * * * * /home/carlos/mi_script


Esto hará que cuando lo minutos sean igual a 30, las horas cualquiera, el día cualquiera y el mes cualquiera se ejecuta /home/carlos/mi_script. Es decir, que el primer número indica los minutos, el segundo las horas, el tercero los días, el cuarto los meses y el quinto el día de la semana (me olvidé de este, gracias FeKuLa). Un asterisco vale de comodín o podemos poner más de un valor usando un coma cómo separador. Por ejemplo el siguiente código que ejecutará mi_script cuando los minutos sean 0, 15, 30 o 45, es decir, cada cuarto de hora:

0,15,30,45 * * * * /home/carlos/mi_script


Vale, ¿y ahora cómo unimos esto al cron de Drupal? Es fácil, en Drupal hay un archivo llamado cron.php (curioso el nombre) que es el que hemos de configurar para que el cron lo ejecute, por lo que añadiremos algo así:

0 * * * * wget -O - -q -t 1 http://www.midominio.com/cron.php


Con esto se ejecutará cada hora. Si estás en un hosting compartido es mejor poner un minuto diferente de 0, uno que no sea normal, así cuando se ejecute no habrá otros programas ejecutados por el cron e irá más rápido (o por lo menos no ayudará a sobrecargarse el servidor, algo más habitual de lo normal). Dependiendo de nuestra web tal vez sea necesario que se ejecute más o menos veces. También es posible que wget no esté en el path por lo que habrá que poner la ruta completa, normalmente suele ser /usr/bin/wget.

Recuerda que esta linea no se añade en el cron.php de Drupal, se ha de añadir usando el comando crontab -e (sólo para expertos) o usando tu panel de control de hosting.

Ahora sólo falta por saber que hace el fichero cron.php aunque primero hay que saber lo que es un hook en drupal. En la documentación de Drupal pone (traducido más o menos por mi):

Permite a los módulos interactuar con el núcleo de Drupal.

El sistema de módulos de Drupal esta basado en el concepto de "hooks". Un hook es una función de PHP a la que llamamos foo_bar(), donde "foo" es el nombre del módulo (cuyo nombre de archivo es también foo.module) y "bar" es el nombre del hook. Cada hook tiene una serie de parámetros predefinidos y el tipo de variable que devuelve.

Para ampliar Drupal, un módulo simplemente implementa un hook. Cuando Drupal desea permitir la intervención desde los módulos determina que módulos implementan un hook y ejecuta ese hook en los módulos habilitados que lo implementen.

Ummm, creo que no está demasiado bien explicado o lo he traducido mal. Intentaré explicarlo con mis propias palabras. Un hook no es más que una función de un módulo pero que se llama de una manera especial. Por ejemplo, si estoy haciendo un módulo que se llama carlosrincon y quiero que ese módulo tenga un bloque con mi foto tendré que usar el hook_block por lo que llamaré a mi función carlosrincon_block.

Entonces cuando Drupal quiera ver todos los bloques disponibles mirará de entre todos los módulos habilitados las funciones que se llamen nombremodulo_block y encontrará el mio.

Pues todo esto venía por que existe el hook_cron que cuando el fichero cron.php se ejecuta Drupal busca en todos los módulos que hayan implementado el hook_cron y ejecuta el hook. Así por ejemplo la búsqueda indexa el contenido cada vez que se ejecuta el cron.php por que tiene una función que se llama search_cron()

<?php
function search_cron() {
// We register a shutdown function to ensure that search_total is always up
// to date.
register_shutdown_function('search_update_totals');

// Update word index
foreach (module_list() as $module) {
module_invoke($module, 'update_index');
}
}
?>

Bueno, espero poder haber aclarado las dudas pero si hay alguna más para eso están los comentarios.

Si eres diseñador web o más concretamente maquetador web habrás tenido que lidiar con un buen montón de errores (o bugs) de CSS que te habrán costado un buen rato solucionarlos. A veces (muchas) es por nuestra culpa, normalmente por un error tonto, otras por que lo que queremos hacer se ha de enfocar de otra manera y algunas veces pero las más frustrantes por un bug de un navegador (normalmente IE).

Estas son algunas pautas que uso para poder solucionar más rápidamente estas cosas:

• Maquetar primero con un navegador con buen soporte de estándares, por ejemplo Firefox
• Usar Firebug. Firebug te permite saber la posición que ocupa un elemento, su tamaño, margen, padding, etc y te dice exactamente las propiedades de css que tiene. Además puedes variarlas o desactivarlas directamente sin tener que actualizar. Otro buen plugin es el webdeveloper pero Firebug es mucho más potente. Para IE existe un addon que puede ayudar un poco pero no es para nada similar. También puedes usar Firebug en otros navegadores insertándolo cómo un fichero javascript.
• Asegúrate de que estás modificando atributos de la etiqueta que quieres: Es algo muy obvio pero a veces no funciona lo que estamos buscando simplemente por que no se lo estamos poniendo al sitio adecuado. Además de mirarlo con firebug (y mirar si ese elemento tiene las propiedades adecuadas) también puedes hacer algo muy fácil: añadir una propiedad fácil de ver como un font-size: 3em o un background red. Si hacemos eso y no vemos ningún cambio es que no estamos aplicando las propiedades sobre el elemento deseado. Tal vez esté mal escrito o sea una clase en lugar de un id (o viceversa). Si todo está bien podría ser que la propiedad esté perdiendo frente a otra (siguiente punto)
• CSS wars: Hay definiciones de propiedades que tienen preferencia a otras. Por ejemplo, si defines una propiedad y luego la vuelves a definir tiene preferencia la última. Si le añades !important al final a la primera tendrá preferencia esta. Puedes ver un bonito y divertido PDF sobre esto.
• Cache: Comprueba que el css que está usando tu navegador es el último que has subido, podrías estar mirando la cache. Para que no use la cache y recargue el último css en Firefox has de utilizar shift+F5 y en IE control+F5. Para asegurarte con Firebug puedes ver el css que se está usando, comprueba que los últimos cambios estén ahí.
• El dominio correcto: Tenemos que comprobar que realmente estemos en la web correcta. A veces tenemos la web en local, la web de desarrollo en el servidor y la web final. Es obvio pero a veces me ha pasado tener en el navegador un dominio diferente a la que estoy realmente modificando.
• Comentarios condicionales IE: Usa comentarios condicionales para IE en los que sólo has de poner las correcciones para IE, no todo el css completo. Eso hace que sea más fácil de mantener. Y hazlo al final, una vez ya esté todo hecho para los otros navegadores. Una vez hayas llegado a este paso verás algunos bugs de IE muy divertidos.
• Bugs de IE (o de otros navegadores): IE tiene un montón de bugs aunque no es sólo de IE, los otros navegadores también tienen bugs pero IE gana por goleada.
• Busca en los buscadores: Mira lo que te pasa, intenta describirlo (mejor en inglés) y ves a tu buscador preferido y por "lo que me pasa" IE bug. Normalmente lo mismo que te pasa le habrá pasado antes a otras personas y cómo suelen ser otros desarrolladores lo habrán publicado en internet. Aunque a veces es complicado describir el error igual que el que publicó.
• Divide y vencerás (divide and conquer): El bug suele tener un trigger (un disparador) que hace que ocurra pero no sabemos que es. Para poder encontrarlo si no tenemos la más remota idea un buen método es seleccionar la mitad del css, borrarlo y subirlo. Si el bug todavía está allí es que el trigger está en la parte que no hemos borrado, si desaparece está en la parte borrada. Luego volvemos a hacer lo mismo en la parte que sabemos que está el trigger y seguimos así hasta llegar al trigger en sí. Una vez descubierto podemos intentarlo hacer de otra manera o podemos volver a buscar en google teniendo más datos.
• Ovillo: Por último si ya lo has mirado solicita ayuda en alguna lista de correo o foro de CSS. La lista de correo Ovillo es la mejor para esto en castellano.

¿Vosotros que trucos usáis?

Actualización

En Ovillo Kemie de diseñorama me comenta que ella hizo un post parecido y al leerle me he dado cuenta que me he dejado una de las pautas más importantes: Validar el HTML y el CSS!

Actualización 2

También me olvidé de una pauta bastante útil: una vez que ya estés atascado suele ir muy bien pedir ayuda a otra persona sobretodo por que para que te ayude le tendrás que explicar paso a paso y de forma muy clara cual es el problema. Muchas veces con tan sólo plantear el problema he podido dar con la solución yo mismo con lo que la persona a la que le he pedido ayuda sólo ha tenido que decir "de nada".