Etiqueta: how to

Como usar GIT tras no haber seguido el flujo de trabajo idóneo

GIT es una herramienta genial cuando eres un desarrollador disciplinado y sigues el flujo de trabajo recomendado:


$ git checkout -b nuevaFuncionalidad
... programar
$ git add -u # añadimos automaticamente todos los ficheros indexados que han sido modificados
$ git add fichero # añadimos los no indexados
$ git commit -m "Mensaje del commit"
... más commits
$ git checkout master
$ git pull --rebase
$ git checkout nuevaFuncionalidad
$ git rebase master
... (solucionar posibles conflictos)
$ git checkout master
$ git rebase nuevaFuncionalidad
$ git push

Pero si hay algo que me gusta, y aquí se nota que es una herramienta hecha por desarrolladores para desarrolladores, es lo bien que se comporta cuando no eres tan disciplinado o has metido la pata. Vayamos con un ejemplo (casi) real que se inicia con un viaje en tren Coruña – Vigo.

El estado del repositorio al empezar era este:


# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: config/text_en.properties
# modified: config/text_es.properties
# modified: config/text_gl.properties
# new file: src/es/udc/cartolab/gvsig/tocextra/ReloadVectorialDBLayerTocMenuEntry.java
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/

Se trata de la extensión para gvSIG, extTOCextra desarrollada inicialmente por Javi y liberada por Cartolab como parte del proyecto gvSIG-EIEL. Como vemos en algún momento del pasado se hizo un commit directamente sobre master que no se subió al repositorio y tenemos cuatro ficheros preparados para hacer un commit que todavía no se ha hecho.

En el viaje de vuelta Vigo – Coruña, nuestro desarrollador se pone a acabar lo que había empezado a la ida, hace un git status y se encuentra que el estado del repositorio es este:

# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: config/text_en.properties
# modified: config/text_es.properties
# modified: config/text_gl.properties
# new file: src/es/udc/cartolab/gvsig/tocextra/ReloadVectorialDBLayerTocMenuEntry.java
#
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: .classpath
# modified: config/text_es.properties
# modified: src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
# src/es/udc/cartolab/gvsig/tocextra/preferences/

A base de memoria y git diff sabemos que:

  • El commit ya realizado y los archivos preparados para hacer commit constituyen una nueva funcionalidad (funcionalidad 1) que no nos interesa subir al repo por ahora
  • La modificación del .classpath y parte de lo modificado en TocExtraExtension son una pequeña refactorización que tiene sentido en si misma y que nos interesa subir como un commit separado del resto
  • El nuevo paqueta es.udc.cartolab.gvsig.tocextra.preferences, y los cambios ShowActivesTocMenuEntry, text_es.properties, y parte de los de TocExtraExtension son parte de una nueva funcionalidad (funcionalidad 2) que se empezó a programar y que todavía no está terminada. Así que nos interesa tenerla en una rama disinta de master para poder seguir trabajando sobre ella.

A la vista de esto nuestro objetivo será:

  • Tener una nueva rama con la funcionalidad 1 conservando la diferencia entre el commit ya realizado y el que tenemos preparado.
  • Una rama nueva con la refactorización en un sólo commit para luego traérnosla a master (tras haber sincronizado master con el repo) y subirla
  • Una rama nueva con la funcionalidad 2 en tantos commits como queramos para seguir trabajando.

Para conseguirlo tenemos muchos caminos alternativos, provemos uno en el que usemos distintos comandos que nos permitan ver la potencialidad de git.

Acabamos el commit que tenemos preparado

$ git commit -m "i18n for ReloadVectorialDBLayerTocMenuEntry"

Ocultamos temporalmente los cambios que nos quedan para que no nos molesten, creamos una nueva rama para la funcionalidad 1, y limpiamos el master.


$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: .classpath
# modified: config/text_es.properties
# modified: src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
# src/es/udc/cartolab/gvsig/tocextra/preferences/
$ git stash
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
# src/es/udc/cartolab/gvsig/tocextra/preferences/

$ git checkout -b reloadDBLayers
$ git checkout master
$ git reset -hard HEAD^^ # Devolvemos la rama master al estado que tenía hace dos commits, es decir, eliminamos los cambios en local

Creamos una nueva rama para la refactorización y deshacemos la ocultación


$ git checkout -b refactor
Switched to a new branch 'refactor'
$ git stash apply
Auto-merging .classpath
CONFLICT (content): Merge conflict in .classpath
Auto-merging config/text_es.properties
CONFLICT (content): Merge conflict in config/text_es.properties
$ git st
# On branch refactor
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
#
# Unmerged paths:
# (use "git reset HEAD ..." to unstage)
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both modified: config/text_es.properties
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
# src/es/udc/cartolab/gvsig/tocextra/preferences/

Ups, el stash apply nos ha provocado un conflicto. ¿Por qué?. Tómate 15 sg para pensarlo y luego sigue leyendo…

En el commit que teniamos sin hacer había modificaciones sobre text_es.properties, cuando lo comiteamos dejamos algunas modificaciones sobre ese archivo que estaban basadas en los cambios comiteados. Como la rama «refactor» la creamos a partir de un master limpio, sin esas modificaciones cuando ejecutamos stash apply ese fichero se encuentra en un estado distinto al esperado y se produce un conflicto que no es capaz de resolver automáticamente. Si hubieramos creado la rama refactor a partir de la rama reloadDBLayers el conflicto no se hubiera producido, pero en esa rama hay cambios que no nos interesan por lo que no podemos hacer esto.

Tras la solución del conflicto el estado de repo es este:

# On branch refactor
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: .classpath
# modified: config/text_es.properties
# modified: src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
# src/es/udc/cartolab/gvsig/tocextra/preferences/
# no changes added to commit (use "git add" and/or "git commit -a")

Separar los cambios realizados sobre TocExtraExtension.java

Como los cambios de la refactorización para el archivo TocExtraExtension.java están mezclados con los de la funcionalidad 2, usaremos la opción –patch de git add para separarlos separarlos. Esto nos permitirá escoger que cambios (hunks) de un archivo queremos preparar para comitear en lugar de añadir todo el archivo.

$ git add -i src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
$ git status
# On branch refactor
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
#
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: .classpath
# modified: config/text_es.properties
# modified: src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
# src/es/udc/cartolab/gvsig/tocextra/preferences/
$ git add .classpath
$ git commit -m "Small refactor"
[refactor 715b4da] Small refactor
1 files changed, 18 insertions(+), 14 deletions(-)

Como se puede ver, hemos hecho commit de sólo una parte de los cambios realizados en TocExtraExtension. Los cambios que quedan son todos los de la funcionalidad 2, así que los comiteamos a una nueva rama

$ git checkout -b newFeature
M config/text_es.properties
M src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
M src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
Switched to a new branch 'newFeature'
$ git add -u
$ git add src/es/udc/cartolab/gvsig/tocextra/preferences/
$ git status
# On branch newFeature
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: config/text_es.properties
# modified: src/es/udc/cartolab/gvsig/tocextra/ShowActivesTocMenuEntry.java
# modified: src/es/udc/cartolab/gvsig/tocextra/TocExtraExtension.java
# new file: src/es/udc/cartolab/gvsig/tocextra/preferences/TOCExtraPreferencesPage.java
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bin/
$ git commit -m "WIP. new feature"
[newFeature eea0ced] WIP. new feature
4 files changed, 137 insertions(+), 13 deletions(-)
create mode 100644 src/es/udc/cartolab/gvsig/tocextra/preferences/TOCExtraPreferencesPage.java

Subimos al repositorio la refactorización


$ git checkout master
$ git pull --rebase
$ git checkout refactor
$ git rebase master
$ git checkout master
$ git merge refactor
$ git push
$ git branch -D refactor
$ git checkout newFeature # para seguir trabajando

Parece complicado, pero en realidad es más difícil de leer que de escribir una vez coges un poco de costumbre.

Incrementar el límite de tamaño de subida de ficheros en WordPress

Cuando monta una WordPress Network el límite de tamaño de los ficheros que los distintos blogs/usuarios pueden subir mediante wordpress está fijado a 1500 KB y el máximo total de ficheros subidos está limitado a 10MB.

Para aumentar estos valores hay que ir a Administrador del sitio -> Ajustes y modificar los valores de Site upload space y Max upload file size. De paso podemos activar la posibilidad de que los usuarios suban fotos, vídeos y música. Por defecto está activada la opción de subir ficheros en general, pero al activar estos checkboxes esos tipos de ficheros serán tratados de forma especial.

Si al aumentar el Max upload file size seguimos teniendo limitaciones a la subida de ficheros seguramente es un límite impuesto por php.Para modificarlo habría que tocar el fichero php.ini, modificando estos valores. Por desgracia ese fichero sólo estará accesible cuando tengamos acceso a todos los parámetros del servidor y raramente en un hosting compartido. Pero siempre hay opciones …

  1. Si tu proveedor de hosting es Dreamhost lo primero que debes hacer es activar para tu dominio php 5.3.
  2. Independientemente de tu proveedor si tienes php 5.3 puedes modificar de formal local la configuración.
  3. Añadir al fichero phprc creado en el paso anterior las opciones que nos interesen.

Como escoger el permalink en WordPress

Escribí este texto en Mayo de 2009, pero tantas vueltas quería darle para que quedara perfecto, que al final nunca llego a ver la luz. He aprovechado la salida de la nueva versión de WordPress para comprobar si aún tenía vigencia, y a pesar de que parece que se va a solucionar en breve por ahora este post sigue siendo correcto.. Así que sin darle más vueltas ahí va. Un batiburrillo de conocimientos sobre posicionamiento en buscadores (SEO), rendimiento de wordpress y permalinks.

Como optimizar las url para el posicionamiento en buscadores

Lo primero que debes saber sobre optimizar las url para el posicionamiento en buscadores es que no debes obsesionarte con ello. Los criterios que usan los motores de búsqueda (SE, de sus siglas en inglés) son secretos (y seguramente cambiantes), por tanto la mayor parte de la información se basa en especulaciones. El valor que los SE asignan a la url se dice que no es demasiado. De todas formas los criterios que desarrollo aquí no están sólo escritos pensando en el SEO (Optimizar el posicionamiento en buscadores) si no en la comodidad para el lector y el CT (click through, que el usuario haga click en un enlace que aparece en una página de búsqueda o anuncio). Dicho esto, las recomendaciones más generales que se suelen dar son:

  • Cuanto más corta sea la url sin que se pierda el sentido mejor. Por ello es buena idea eliminar el www del principio de las url.
  • Usa – para separar las palabras, por ejemplo si tu artículo va sobre «Para La caza de ballenas en el ártico» la url debería ser más o menos así http://midominio.com/parar-caza-ballenas-artico y no parar_caza_ballenas_artico.
  • Elimina de la url toda información superflua (artículos, posesivos, …) y deja sólo las palabras clave. Por ejemplo la url de un artículo titulado «Descubre las maravillas del gran continente africano» podría ser «descubrir-africa»
  • Pon las páginas más importantes en la raíz del dominio y trata de estructurar el resto de una forma lógica. Por ejemplo: midominio.com/ecologia/caza-ballenas-artico y midominio.com/viajes/descubrir-africa y midominio.com/hazte-socio. O si tus artículos son muy basados en fechas midominio.com/2009/04/caza-ballenas-artico
  • Ten cuidado a la hora de repetir títulos. Si haces una serie de artículos «Como Bloguear I», «Como Bloguear II», … y las url son demasiado parecidos los buscadores podrían pensar que estas haciendo spam y penalizarte (no estoy seguro de esto). Así que podrias optar por títulos y url del estilo «Escoger un titulo para el post (como bloguear I)» «escoger-titulo-post-bloguear-i», «El cuerpo del artículo (como bloguear II)» «cuerpo-articulo-bloguear-ii».
  • Por supuesto no pueden existir dos url exactamente iguales. Por ejemplo en WordPress si una url (permalink) coincide con otra (aunque hayas editado el permalink a mano) -2 es añadido automaticamente. Otros CMS pueden funcionar de otra forma así que ten cuidado.
  • Hay quien dice que las url que terminan en / posicionan mejor pero suponen un mayor gasto de ancho de banda. Matt Cutts dice que mejor dejar las extensiones (es decir url que acaben en .htm) aunque no por motivos de posicionamiento. Yo prefiero dejarlas sin la extensión y sin la /
  • Si quieres que google news te indexe uno de los requisitos es que existan al menos tres digitos al final de cada url, por ejemplo caza-ballenas-456. Aunque hay que valorar la confusión que puede introducir para el lector el que haya números en la url

Como aplicar estas reglas a WordPress.

Pasar de la teoría a la práctica no siempre es fácil y exige establecer compromisos. Veamos que sucede en wordpres.

En la instalación por defecto de wordpress a los nuevos artículos que escribamos se les asignará una url del tipo midominio.com/?p=123. Pero podemos hacer que esta url, permalink en la jerga de wp, tenga una forma más bonita y acorde a las reglas que ya hemos descrito.

La estructura de los permalinks se cambia a través del menú de «Opciones» del panel de control de wp. En este artículo comentan como se modifican los permalinks y que hacer si ya tenemos artículos escritos con la vieja estructura. Esto es importante, si cambiamos los permalinks en un blog ya en uso, las url de nuestros post cambiarán, de modo que los enlaces a nuestro blog pasarán a apuntar a direcciones inexistentes. Esto es solucionable mediante reglas 301 de redireccionado, pero este tema esta fuera del alcance de este artículo.

En los permalinks de wp generalmente usaremos una estructura a medida. Los códigos más usados son para generar esta estructura son:

  • %postname%: Una versión saneada del título del artículo. Si el título es ¿Como cazar ballenas? el permalink será como-cazar-ballenas
  • %year%: Los cuatro digitos del año de la fecha de publicación del post.
  • %month%: Dos digitos para el mes
  • %post_id%: El identificador único de cada post. A cada post se le asigna un número distinto que jamas se repite.
  • %categorie%: La categoría que hemos asignado a la entrada. Si le hemos asignado más de una es la que tenga un ID más bajo.

Para cambiar los permalinks tan sólo debemos combinar los códigos que acabo de explicar y darle a actualizar. Esta es la parte fácil, decidir cual es la mejor estructura para nuestro caso algo más complicado.

Hasta ahora la mayoría de artículos escritos sobre los permalinks de wordpress te recomendaban usar la estructura /%categorie%/%postname%/ o bien directamente /%postname%/. Pero una discusión de enero de 2009 en las listas de correos de wordpress muy bien resumida en este artículo advierte de que estas dos estructuras puede dar problemas de rendimiento. Los artículos sobre seo escritos con anterioridad a esa fecha están incompletos porque no tienen en cuenta este factor.

Rendimiento vs Posicionamiento

Este problema de rendimiento lo dividiremos en dos para explicarlo, aunque en el fondo son el mismo:

  • Cuando el permalink contiene cadenas de texto (midominio.com/seo/wordpress-permalinks) wordpress tiene que hacer más accesos a la base de datos (querys) y más operaciones que cuando el permalink sólo contiene números (midominio.com/7405). Esto no es muy grave en la mayoría de casos, pero a medida que añadimos plugins, widgets y tenemos más visitas si puede convertirse en un problema. Sobre todo si usamos algún tipo de hosting compartido que limite el uso de cpu, querys por segundo u otro tipo de restricciones. La solución o minimización de este problema está en instalar algún plugin de cache.
  • La segunda parte del problema, algo más grave se produce cuando la estructura del permalink comienza por una cadena en lugar de por un número. Es decir una estructura tipo midominio.com/seo/wodpress-permalinks sufriría ambos problemas mientras que una del tipo midominio.com/2009/seo-wordpress-permalinks sólo sufriría el primero. Si además de empezar por una cadena tenemos muchas páginas (no posts) y adjuntos (del orden de miles) el número de reglas que wordpress tiene que almacenar en la base de datos crece exponencialmente y con la forma en la que se hace actualmente además de ralentizar mucho la carga de las páginas e incrementar los querys puede acceder que no podamos acceder a la base de datos de forma manual (operaciones de copia de seguridad, …). Este problema podría solucionarse en futuras versiones de wordpress (en el momento de escribir publicar este post estamos en la versión 3.0).

Dicho todo esto, hay que recalcar que no deberíamos preocuparnos en exceso, porque hasta ahora los reportes de este tipo de problemas han sido muy pocos. Pasemos entonces a ver los pros y contras de las estructuras más típicas.

  • /%categorie%/%postname%/. Una de las favoritas si sólo consideramos aspectos SEO y no de rendimiento. Buena estructura porque añadimos keywords a través de la categoría y resulta más ordenado lo que es bueno para las SE y para el usuario. En el punto negativo antes de ponernos a escribir debemos tratar de pensar bien las categorías y no borrar o modificar categorías que ya hayamos usado. En definitiva nosotros mismos debemos ser ordenados y tener las cosas claras. Hay que tener cuidado si editamos el post en no cambiar las categorías porque podriamos cambiar la url. (Sucederá cuando la nueva categoría que añadamos tenga un id inferior a la actual). Si usamos categorías anidadas ambas se incluyen en la url (/blogging/wp/titulo). Esto genera estructura pero aleja a las páginas de la raíz y disminuye el rendimiento. El uso de esta estructura podría llegar a generar graves problemas de rendimiento
  • /%postname%/ o /%postname% o /%postname%.html. La otra favorita de los expertos en SEO. Hay quien dice que Google concede más importancia a los archivos que cuelgan de la raíz, pero hay quien dice que tener todo en la raíz es malo porque no da importancia a unas cosas sobre otras y google prefiere el empleo de url más estructuradas. Por otro lado hay quien dice que google concede más importancia cuando las direcciones acaban en /, otros dicen que da más importancia a las páginas estáticas y por tanto conviene usar el .html. Dado que el algoritmo de clasificación es secreto debes optar por lo que crear que resulta menos confuso para los lectores, que en mi opinión es /%postname
  • /%year%/%month%/%postname%. Esta es la estructura más usada, pero no la más recomendable. Incluír la fecha añade algo de información contextual a la url. Es la mejor opción, tanto en rendimiento como en SEO, si tu página está muy basada en eventos temporales, o públicas a menudo. El problema está, en que si escribes artículos genéricos, que es lo más habitual, puede dar la impresión de quedar desfasados cuando pasa cierto tiempo. Si escribimos mucho es buena idea para aportar información extra al lector. Lo malo es que se suelen crear muchos subdirectorios lo que no gusta a las SE. Aunque se podría usar algo tipo /%year%/%postname%/ solamente. Añade información a los lectores, que de un vistazo ven la época en que se escribió el post. Téngase en cuenta que esto es bueno para los lectores pero malo para el blog, porque muchos no entrarán si ven que la fecha es antigua. Empezar la url con números es lo más eficiente en cuanto a escalabilidad y tiempo de carga de la página.
  • /%postid%/posname%. Mismas consideraciones que la anterior respecto a rendimiento y SEO. Si escribes poco o artículos muy genéricos posiblemente sea mejor esta.

En resumen,

  1. Cuando creas un nuevo blog lo primero que tienes que hacer es ir a Opciones->Permalinks y modificar la estructura por defecto.
  2. Si tu blog es muy basado en eventos temporales en la casilla de «custom» escribe /%year%/%month%/%postname%
  3. Si tu blog va a tener mucho tráfico o muchas páginas (del orden de miles) en la casilla «custom» escribe: /%postid%/%postname%
  4. En caso contrario (este es el caso más habitual) escribe /%postname%

Por que este blog usa otra estructura

Este blog incumple las conclusiones anteriores y usa la estructura /%postname%/%postid% esto es por dos motivos:

  • Incluír números como el último punto de la url no limita demasiado el CT, la gente lee el dominio y a continuación las keywords, cuando llega a los números simplemente deja de leer, con lo que no hay una ruptura visual a la hora de asociar las keywords al dominio y se refuerza el branding.
  • El segundo motivo es la creencia de que en un futuro cercano salga algún plugin para wordpress que interprete los permalinks de otra forma. Si en lugar de empezar a leer la url por la derecha, se empezara por la izquierda esta estructura sería de las más eficientes en cuanto a rendimiento.

Copia de seguridad de un blog en WordPress

Resulta conveniente realizar con regularidad una copia de seguridad de la información que tengamos en nuestro blog. Este backup deberíamos hacerlo como mínimo antes de una actualización importante del blog, por ejemplo antes de migrar de WordPress 2.x a la versión 3.

Hacer un backup de wordpress consiste en dos cosas:

  • Copiar los ficheros (imágenes, temas, …)
  • Copiar los artículos y configuraciones (la base de datos)

Existen algunos plugins que pueden ayudarnos en estas tareas, pero si no tienes tirria a la línea de comandos en este artículo se describe un método rápido y eficiente para hacer la copia. El único requisito es que nuestro proveedor de hosting nos proporcione acceso por ssh, que es lo más habitual. Para ahorrarnos meter la clave ssh cada vez que hagamos la copia podemos subirla al servidor en este artículo se explica como crearla y subirla pero en resumen consiste en ejecutar estos dos comandos (o sólo el segundo si ya tenemos una clave creada)
ssh-keygen -b 4096 -t rsa
ssh-copy-id usuario@servidor

El primer paso será hacer un volcado de la base de datos a un fichero en el servidor:

ssh usuario@servidor "mysqldump --opt --user=USUARIO_BD -p --host=URL_BD NOMBRE_BD > /ruta/fichero_a_guardar"

Por ejemplo
ssh fpuga@dreamhost.com "mysqldump --opt --user=fpuga_bd -p --host=localhost conocimientoabierto_bd_wordpress > conocimientoabierto/base_datos.sql"

La opción -p significa que nos preguntará cual es la clave de la base de datos por consola. Podemos indicarla directamente haciendo –pasword=CLAVE. Esto puede ser útil si metemos estas sentencias en un script pero deberiamos tener el script a buen recaudo para que no puedan ver nuestra clave.

El fichero sql donde se volcará la base de datos podríamos comprimirlo, pero con la estrategia que vamos a usar es mejor dejarlo en texto plano. El proceso de comprimir tiene un consumo elevado de cpu (algunos hosting limitan la cpu que se consume) y en el siguiente paso nos bajaremos el fichero por rsync.

rsync lo que hace es buscar las diferencias entre lo que tengamos en el servidor y lo que tengamos en nuestro disco duro, y sólo se baja lo que varíe. Si hubiéramos comprimido en el paso anterior la base de datos tendría que bajarse el fichero entero pero al estar en formato texto se bajará sólo la diferencia lo que resulta óptimo tanto en gasto de cpu como en ancho de banda consumida. La copia de los ficheros del servidor a nuestro disco duro, consistirá entonces en ejecutar:

rsync -av --delete usuario@servidor:ruta_remota $RUTA_LOCAL

por ejemplo:

rsync -av --delete fpuga@dreamhost.com:conocimientoabierto/ /home/fpuga/backup/conocimientoabierto

La opción delete hace que se borren los archivos locales que ya han sido borrados del servidor remoto. Puede ser peligrosa así que cuidado. La ruta local donde se copien los archivos debe existir previamente. Fijaos en que cuando se pone la ruta remota después de los dos puntos no se inicia con / porque sólo queremos indicar una ruta relativa.

Por último borraremos del servidor el fichero de volcado de la base de datos
ssh usuario@servidor "rm /ruta/fichero_a_guardar"

Y para no teclear tanto podemos crearnos un script muy sencillito. Llega con que cambies los valores de las variables por los de tu servidor.

Antes de escribir el script estuve leyendo sobre algunos plugins pero ninguno se adaptaba a mis necesidades, de todas formas estas referencias puede venirte bien si prefieres usar otro sistema:

Primeros pasos para configurar git

Git es el sistema de control de versiones (SCV) que se está imponiendo en el mundo del software libre. Todo programador que se precie debe aprender a usar un SCV y dado que git puede operar también sobre repositorios svn te recomiendo encarecidamente que lo pruebes. Una de las ventajas de git es que es increíblemente configurable. En este artículo encontraras como realizar esa primera configuración para que sea más cómodo trabajar con git.

La configuración global de git se guarda en el home del usuario en archivo llamado .gitconfig. Además dentro de cada repositorio existe un archivo config dentro del directorio .git donde podemos usar unas configuraciones distintas a las globales o añadir parámetros nuevos. La configuración que deseemos la podemos escribir directamente en esos archivos o usar el comando git config.

Indicamos a git quien somos

git config --global user.name "Francisco Puga"
git config --global user.email "fran.puga@gmail.com"

Esto generará en el fichero .gitconfig dos nuevas líneas como las que siguen:

[user]
email = fran.puga@gmail.com
name = Francisco Puga

Si quisiéramos configurar nuestro correo electrónico para un repositorio concreto ejecutaríamos git config sin la opción de –global dentro del directorio que contiene el repositorio.

Colorear la salida

A continuación añadiremos unas líneas al fichero de configuración global (o mediante ordenes como git config –global color.ui auto) para que nos coloree la salida por pantalla

[color]
ui = auto
diff = auto
status = auto
branch = auto

Con añadir esas líneas empezaríamos a usar los colores por defecto pero estos son personalizables como se puede ver en estos enlaces.

Si tras activar los colores ves algo de basura en la salida añade a ~.bashrc la línea:
LESS=-R

Ignorar ciertos ficheros

Cuando trabajamos en un proyecto puede haber ciertos directorios, ficheros resultantes de la compilación, … que queremos que git no indexe y no nos aparezcan al hacer un estatus. Para ignorar ciertos ficheros tenemos varios métodos:

Si lo que queremos es una configuración global para todos nuestros repositorios añadiremos en el .gitconfig la directiva excludesfile con la ruta completa a un archivo de texto donde definiremos las rutas a ignorar. Por ejemplo en mi caso:

[core]
excludesfile = "/home/fpuga/.gitignore"

Y el contenido de ~.gitignore es

*.[oa]
*.lo
*.la
*.gmo
semantic.cache
*~
*.pyc

Si lo que queremos es definir un patrón de exclusión para un repositorio concreto lo haremos en el fichero .git/info/exclude.

La tercera opción es crear un fichero .gitignore dentro algún directorio de nuestro repositorios. Este fichero debería usarse no para las configuraciones personales si no para las de todo el grupo de trabajo. Es decir .gitignore es un fichero que podría subirse al repositorio de modo que todo el equipo de desarrollo comparta esa configuración. La particularidad de .gitignore es que no tiene que colocarse en la raíz del repositorio si no que puede colocarse en algún subdirectorio, así, si en el mismo repositorio tenemos varios proyectos, cada uno en un directorio podemos aplicar configuraciones distintas a cada proyecto.

Para teclear menos

Los comando de git suelen ser nombres bastante largos y en algunos hay que incluir ademas varios parámetros. Para que tengamos que teclear menos git permite configurar alias. La sección alias de mi .gitconfig es la siguiente:

[alias]
unstage = reset HEAD
st = status
rma = ls-files --deleted | xargs git rm
co = checkout
com = checkout master

5.- Programas por defecto que se usan. Se puede configurar el programa que se empleará para editar el mensaje de commit (por ejemplo emacs en lugar de vi) y el paginador que se usa para ver el log (por ejemplo most en lugar de less)

Si bien en el caso del editor es más lógico configurar la variable de entorno global EDITOR=emacs en nuestro .bash_profile, también podemos configurarlo en exlusiva para git con algo como esto

[core]
editor=emacs
pager=moss

Evitar meter las claves

Si a los repositorios git que tenemos se accede mediante ssh, cosa bastante habitual, tendremos que teclear nuestra contraseña cada vez que bajemos o subamos algo al repo. Para evitarlo podemos copiar nuestra clave pública al repositorio remoto. Haciendo esto, cuando queramos trabajar contra el repo, este automáticamente se encargará que nuestra clave privada se corresponde a la clave pública que hemos subido y nos dará acceso.

El proceso es tan sencillo como, crear una nueva clave si todavía no lo hemos hecho:

ssh-keygen -b 4096 -t rsa

Si usamos una passphrase nos la preguntarán sólo la primera vez de la sesión que la clave sea usada. Se trata de una contraseña para permitir al sistema acceder a nuestra clave privada, no tiene nada que ver con el servidor remoto.

Una vez tengamos nuestra clave ssh, debemos copiarla al servidor, para ello existe un comando especial que hace todo por nosotros

ssh-copy-id @servidor

Sincronizar el perfil o los marcadores de Firefox mediante dropbox

Cuando de manera habitual usas más de un ordenador mantener la misma configuración en ambos acaba siendo problemático. Una de las cosas que más echo de menos desde que he dejado de usar mi portátil personal en el trabajo es poder sincronizar los marcadores de Firefox.

En el cielo o en la tierra

Tal y como yo lo veo hay dos clasificaciones en las que se podrían englobar los métodos para la sincronización:

  • Usar un servicio web como delicious pensado para trabajar exclusivamente con los marcadores.
  • Usar alguna herramienta de sincronización de ficheros como DropBox.

El depender en exclusiva de un servicio web no es una opción que me tiente demasiado, así que no hablaremos de ella. DropBox en cambio, es una mezcla de servicio web y rsync sencillo, donde los ficheros no sólo se guardan en un servidor externo si no también en el nuestro, de modo que podemos abandonarlo cuando queramos a coste casi cero, de hecho, montar un sistema casero que substituya a DropBox no es muy complicado.

Diferentes implementaciones con Dropbox

Decidido que usaremos DropBox tenemos varias formas concretas de implementar el sistema:

La última me parece la mejor porque nos ahorramos el crear un nuevo perfil, simplemente movemos su ubicación y usamos herramientas propias de firefox para colocar el directorio del perfil dentro de DropBox en lugar del truquillo de los enlaces simbólicos.

Decidido el método, los pasos previos

En todo caso antes de usar uno de estos tres métodos deberías:

  1. Hacer una copia de seguridad de tu perfil
  2. Modificar donde se guarda la cache del navegador. La cache son un montón de archivitos que se guardan mientras navegas para acceder más rápido a páginas ya visitadas, que no tienen ningún interés para la sincronización y que sólo te harán perder ancho de banda y cpu si intentas sincronizarlos. Para cambiar la ubicación, abre firefox y teclea about:config en la barra de direcciones. A continuación busca la clave browser.cache.disk.parent_directory. Si no existe créala como de tipo «cadena». El valor que debe contener es el nuevo directorio que usará como cache, asegúrate de que existe en todos los ordenadores que vayas a usar, yo uso /var/tmp. Cierra el navegador , borra el directorio Cache dentro de tu perfil y vuelve a abrir el navegador. Asegúrate de que en /tmp se ha creado un nuevo directorio Cache.

Mi método casi-preferido

Hecha la preconfiguración podríamos hacer lo que se dice por ejemplo en robzand:

  1. Copia el directorio que contiene tu perfil a DropBox
  2. Edita el fichero profile.ini (está en la misma carpeta que tu directorio de perfil). Pon un cero en IsRelative, y en Path pon la ruta completa a tu perfil dentro de DropBox, que seguramente será algo como /home/[tu_usuario]/DropBox/4f45s.default
  3. Espera a que sincronice, abre el navegador y comprueba que todo funciona correctamente.
  4. Ve a otro pc y espera a que sincronice. Edita el fichero profile.ini, pon un cero en IsRelative y pon en Path la ruta al perfil que acaba de ser sincronizado. (Ten en cuenta que a no ser que tengas el mismo nombre de usuario en ambos ordenadores la ruta será distinta)

Los incovenientes

Al compartir el perfil también se comparten:

  • Las extensiones. Si usas diferentes versiones de firefox puede que alguna de las extensiones te de problemas.
  • Las cookies y las claves. Las cookies permiten que las páginas web te recuerden de modo que no tengas que escribir tu contraseña cada vez que entras. Si almacenamos tanto las cookies como las claves en un servicio externo como DropBox y alguien lo crackea, toda nuestra vida en la red será vulnerable.
  • Cada vez que abras una página el contenido de tu perfil cambia, con lo que dropbox empezará a sincronizar, y habrá un gasto elevado de cpu y ancho de banda.

Estos problemas nos llevan a reflexionar si la comodidad que tiene el perfil compartido compensa el riesgo o a preguntarnos si realmente necesitamos compartir todo el perfil, o nos llega con los marcadores.

Mi método preferido

Por tanto, si lo único que quieres es compartir los marcadores, que es en general lo mejor desde mi punto de vista, lo único que hay que hacer es:

  1. Mover el archivo places.sqlite dentro del perfil de tu ordenador principal a DropBox
  2. Crear un enlace simbólico desde el archivo en DropBox a tu perfil. El comando sería algo así:
    ln -s [ruta a places.sqlite dentro de dropbox] $HOME/.mozilla/firefox//places.sqlite
  3. Esperar a que sincronice y abrir firefox para comprobar que todo es correcto
  4. En el resto de ordenadores borrar el archivo places.sqlite de dentro del perfil y hacer el enlace simbólico desde el que está en Dropbox.

Cifrar una partición o disco duro externo en GNU/Linux

A pesar de que soy un firme defensor de los asistentes gráficos, creo que ciertas cosillas, sobre todo las relativas a la seguridad y que llega con hacer una vez en la vida es conveniente aprender a hacerlas «de verdad». Una de esas cosas para las que merece la pena remangarse es aprender a cifrar o encriptar (sic) particiones o discos duros completos. Las instrucciones que voy a dar a continuación están pensadas para cifrar una partición en dispositivo externo pero también valdrían para una interna. Si lo que queremos es cifrar /home quedarían algunas cosas más por hacer que lo que aquí se describe. Por poner las cosas un poco en contexto, la idea de fondo de esta receta es que tengo un disco duro externo con varias particiones. En dos de ellas, cifradas ambas, hago copia de seguridad de un portátil y un sobremesa. La tercera es un almacen de archivos multimedia, música y vídeos obtenidos de gente que los compartía de forma no delictiva a través de internet.

Comprobaciones previas

  • Saber el nombre del dispositivo que equivale a la partición que queremos cifrar, este nombre acostumbra ser del tipo /dev/sdb1 si se trata de una partición o /dev/sdb si es todo el disco. A partir de ahora me referiré a este nombre como $PARTICION. El contenido de esa partición lo perderemos por completo. Podemos identicarlo ejecutando en una consola fdisk -l
  • Desmontar la partición sobre la que vayamos a trabajar umount $PARTICION
  • Instalar (en el raro caso de que todavía no lo esté) el paquete cryptsetup.

Comprobar que no hay errores en el disco

A continuación comprobaremos que la partición que vamos a cifrar no tiene errores físicos. Esta operación y la siguiente de rellenar con valores aleatorios el disco pueden tardar varias horas y no son estrictamente necesarias, pero yo recomiendo ejecutarlas.
badblocks -s -w $PARTICION -b $TAMAÑO_BLOQUE

Para saber cual es el tamaño de bloque en nuestra partición podemos usar el comando:
tune2fs -l /dev/sda5 | grep -i 'Block size'

Una forma de acelerar el proceso de chequeo de errores es usar el parámetro -t random. Por defecto lo que hace badblocks es llenar todos los bytes del disco duro con aa, 55, ff, 00. Primero escribe el primer patrón (aa) y luego comprueba que todos los bytes valen aa, a continuación hace lo mismo con el segundo patrón,… Con -t random da una sóla pasada donde el patrón usado es aleatorio. Es menos fiable pero más rápido. Tampoco es mala idea hacerlo si estamos más o menos seguros de que el disco está bien y nos vamos a saltar el paso de llenar el disco con valores aleatorios.

Aleatorizar el disco

Si somos un poco paranoicos lo que debemos hacer a continuación es llenar la partición con valores aleatorios, lo que nos protegerá de ciertos ataques criptográficos. Hay varias formas de hacer esto, a mayor nivel de paranoia más lento será. Yo lo hago con este comando:
shred -n 1 -v $PARTICION

El parámetro -n $numero define el número de pasadas que haremos, el valor por defecto es 3, pero con 1 es suficiente. Hay quien sugiere usar mejor el comando:
dd if=/dev/random of=$PARTICIÓN bs=$TAMAÑO_BLOQUE

Mientras que shred trabaja con datos pseudo-aleatorios (tomados de /dev/urandom) los que se usan con esta otra opción son realmente aleatorios, pero el tiempo que tarda en finalizar se multiplica.

Por otro lado prefiero usar shred a dd if=/dev/urandom of=%PARTICION bs=$TAMAÑO_BLOQUE (que es otra instrucción que se ve habitualmente por ahí en los how-to) porque con shred nos va informando del progreso del proceso y es una herramienta específica para este tipo de tareas.

Cifrar la partición

El siguiente paso consiste en indicar al sistema operativo el tipo de cifrado y contraseña queremos emplear para ese dispositivo.
cryptsetup -c aes -h sha256 -y -s 256 luksFormat $PARTICION

  • -c aes indica que vamos a usar como algoritmo de cifrado AES que es el más extendido. Otra buena opción sería Twofish.
  • -s 256: que el tamaño de la clave sean 256 bits que es más que suficiente. A mayor tamaño más seguridad pero mayor perdida de rendimiento
  • -h sha256: que use como algoritmo de hash SHA-256.

Si este comando nos da un error del tipo

Check kernel for support for the aes-cbc-plain cipher spec and verify that /dev/sdb6 contains at least 258 sectors

es seguramente porque no tenemos cargado el módulo dm-crypt. Para cargarlo ahora mismo ejecutamos
modprobe dm-crypt

Para hacer que se cargue automáticamente cada vez que arrancamos el ordenador añadimos al archivo /etc/modules una línea que contenga unicamente el módulo a cargar, en este caso
dm-crypt

Ahora debemos comprobar si podemos acceder al volumen cifrado
cryptsetup luksOpen $PARTICION $NOMBRE

Este comando es algo así como decirle al kernel que el volumen virtual descifrado, correspondiente al volumen físico cifrado $PARTICION va a ser /dev/mapper/$NOMBRE. Este comando no es equivalente a montar la partición, es más bien inventarnos una especie de interfaz hardware para acceder a nuestros datos descifrados.

Creamos un nuevo sistema de archivos en la partición

Si todo ha ido bien ahora debemos formatear la partición, yo uso el sistema de archivos ext4.
mkfs.ext4 [-L $ETIQUETA] -m 1 /dev/mapper/$NOMBRE

  • -L $ETIQUETA: Asigna a esa partición un determinado nombre. Yo uso esta opción sobre todo cuando se trata de dispositivos externos, ya que cuando conectemos el dispositivo este se montará automáticamente como /media/$ETIQUETA, si no tiene etiqueta será simplemente /media/disk. Hay que tratar de usar un identificador que sea difícil que se repita, para poder asegurarnos que no hay otro dispositivo montado con el mismo nombre yo por ejemplo uso el estilo fpuga_backup
  • -m 1: Es para reservar un 1% del disco duro para el superusuario en lugar del 5% por defecto. Es útil dejar siempre algo pero 5 es demasiado

Para cerrar el volumen descifrado y que no se puede acceder a él con la clave haremos
cryptsetup luksClose /dev/mapper/$NOMBRE

Trabajar con el disco cifrado

Con los pasos dados hasta aquí ya tenemos listo nuestro volumen cifrado, la cuestión ahora es ¿como empezar a meter datos en él?. Primero descifraremos el disco (metiendo la clave), creándose automáticamente un volumen virtual descifrado y luego montaremos el volumen, esto lo hacemos con los comandos:
cryptsetup luksOpen $PARTICION $NOMBRE
mount /dev/mapper/$NOMBRE $PTO_MONTAJE

En el caso de que sea un partición interna es conveniente que definamos sus propiedades de montaje en /etc/fstab. En el caso de ser una externa es bastante sencillo, ya que al conectar el dispositivo automáticamente nos saldrá una ventana de diálogo preguntándonos la clave. Al introducirla, si hemos definido una etiqueta para la partición está se montará en /media/$ETIQUETA.

Para desmontar la partición y cerrar el volumen descifrado podemos hacer click con el botón derecho sobre la partición y darle a desmontar o bien ejecutar los comandos:
umount $PTO_MONTAJE && cryptsetup luksClose /dev/mapper/$NOMBRE

Referencias

Como ocultar la dirección de correo para combatir el spam

Algo que tenía pendiente desde hace ya demasiado era poner una dirección de correo electrónico de contacto en el blog. Todas las guías sobre blogging hablan de la importancia de incluirlo y resulta lógico el permitir que tus lectores contacten contigo en privado pero hasta ahora, más que nada por vagancia, no me había decidido a hacerlo.

Antes de colocar la dirección tienes que pensar que tipo de blog tienes y el uso que le quieras dar, dependiendo de esto puedes colocar tu dirección de correo habitual o bien crear una a propósito. Independientemente de lo que decidas debes saber que cada vez que publicas tu dirección en algún sitio estás creando una nueva fuente de entrada de spam. Los spammers tienen robots que se dedican a rastrear las páginas web en busca de direcciones de correo-e para añadirlas a sus bases de datos y enviarte (todavía más) spam. Si bien los filtros anti-spam funcionan bastante bien hay una opción sencilla para evitar que los robots puedan reconocer la direcciones de correo, lo único que hay que hacer es convertir tu dirección de correo en una imagen. Yo conozco tres servicios web que hacen esto automáticamente:

  1. Hide Text
  2. Nexodyne
  3. Safe Mail

Los tres servicios funcionan igual, introduces tu dirección de correo en el formulario, ajustas alguna opción del tamaño de letra y color del texto y le das a siguiente. Los tres se comprometen a no vender nunca tu dirección y a alojar la imagen de forma indefinida en sus servidores para poder servirla desde su servidor. En el primero de ellos da la opción de borrar la imagen una vez creada, para que no este alojada más en su servidor. En los tres tienes la opción de descargar la imagen para alojarla en tu propio hosting.

Si quieres usarlos simplemente prueba como queda la imagen con unos y con otros y escoge el que más te guste. Luego te recomiendo que la descargues (y si usas Hide Text la borres) y la subas a tu hosting. Es mejor servirla desde tu hosting para minimizar dependencia de terceros y porque el consumo de ancho de banda va a ser muy escaso. Desde ese momento, suponiendo que la imagen esté por ejemplo en http://conocimientoabierto.es/img/correo-e.png, para incluirla en un comentario en un blog debes usar la etiqueta html img, quedaría así

Si quieres puedes probar como queda dejando un comentario en esta entrada o escribiéndome a mi correo <img src=»http://conocimientoabierto.es/img/correo-e.png»>

Si quieres puedes probar como queda dejando un comentario en esta entrada o escribiéndome a mi correo

Por supuesto, en lugar de usar estos servicios puedes arrancar el gimp (o el paint si todavía usas Windows) y crearla la imagen tu mismo porque es muy sencillo. Esta es la mejor opción desde mi punto de vista.

Problemas:

  • La opción de pinchar con el botón para que automáticamente se abra el cliente de correo desaparece.
  • No se puede copiar y pegar la dirección, lo que es un pequeño incordio.
  • La imagen que uses, tamaño, colores, … puede romper la maquetación de la página donde la uses

Existe una técnica más sencilla que la de usar imágenes consistente simplemente en ofuscar tu dirección de correo usando texto en lugar de símbolos de modo que no sea reconocida por los bots. Por ejemplo en lugar de mail_falso@hosting_falso.no usa:

  1. mail_falso <at> hosting_falso <dot> no
  2. mail_falsoANTISPAM@hosting_falso.no
  3. mail_falso <ARROBA> hosting_falso.no
  4. o alguna combinación

Si usas este método te recomiendo emplear la tercera opción, puesto que hay mucha gente que puede no reconocer el texto <at&gt como sinónimo de arroba o entender que el texto ANTISPAM no forma parte de la dirección real. Desconozco hasta que punto la opción de ofuscar la dirección es válida, dado que a los spammers no creo que les cueste mucho reprogramar su software para reconocer este tipo de truquillos, pero en principio me parece que esto es más cómodo para el usuario que usar imágenes.

Como siempre la decisión última dependerá del uso que cada uno vaya a darle. Yo personalmente, he decidido pasar de usar imágenes, el spam está ahí y el volumen de tráfico que te va a evitar usar imágenes no creo que compense la incomodidad para el usuario o para ti al tener que usar etiquetas html/bbcode para introducir tu correo en lugar de escribir el texto directamente.

Otro día seguiremos con algunas técnicas sencillas para no tener que dar nuestra dirección real cuando nos registramos en un foro o una de esas páginas que apenas vamos a usar un par de veces. Subscríbete a mi RSS para estar al día.

Como usar FeedBurner para servir nuestro feed

Feedburner es un servicio web propiedad de Google que se encarga de redistribuir nuestros feeds. Es algo así como si feedburner se subscribiera al feed que proporcionamos desde nuestro blog, luego volviera a distribuirlo y nosotros indicamos a nuestros lectores que se conecten a través de esa segunda versión de nuestro feed y no a través del que proporcionamos directamente en el blog. La ventaja de esto es que ahorramos ancho de banda y que Feedburner puede proporcionarnos estadísticas interesantes de los lectores. La parte mala es que pasamos a tener cierta dependencia de un servicio externo y una disminución de la privacidad puesto que google pasa a poder recolectar información sobre nuestros lectores.

Feedburner estuvo de modo hace un par de años cuando el ancho de banda era un bien escaso y las empresas de hosting eran caras, en la actualidad no resulta en general necesario. Desde mi punto de vista el único motivo para usarlo sería por el de las estadísticas, tu debes valorar si la información que proporciona compensa el ceder datos a google.

Si te decides a usarlo, una forma de minimizar el impacto de la dependencia externa es activar la característica My Brand, en este artículo se explica como activar FeedBurner con My Brand para nuestro blog.

Antes de continuar, debes tener presente dos cosas

  • Para poder usar My Brand tienes que añadir un registro CNAME a las dns de tus dominios, mira en las páginas de ayuda de tu hosting como hacerlo. Generalmente se encuentra en el apartado Dominios o «Gestión de DNS» y es fácil, pero es bueno que mires como hacerlo antes de meterte en faena
  • Las direcciones que se indican aquí para los feeds por defecto de wordpress del tipo dominio.com/feed y dominio.com/comments/feed son sólo válidas si tenemos activados los permalinks de wordpress. Si no los tienes activados deberás usar la dirección dominio.com?feed=rss2 y dominio.com/wp-commentsrss2.php. Si los permalinks están customizados también puedes usar el otro tipo de dirección pero es mejor usar la customizada.

Pasos para servir nuestro feed a través de Feedburner

Entramos en feedburner.com con nuestra cuenta de gmail. Si no tenemos una podemos crear una cuenta de google allí mismo.

En el formulario que aparece en mitad de la página escribimos la dirección de nuestro blog (en el ejemplo usamos la página www.marinerosbouzas.com, y pulsamos en siguiente [Imagen 1, puedes pinchar sobre las imágenes para ampliarlas]. Dejamos seleccionado el usar rss en lugar de atom (esto no importa) y pulsamos siguiente.

En esta pantalla [Imagen 2] escogemos un título para el feed, generalmente el nombre del blog. Feed address es la dirección desde la que serviremos nuestro rss a partir de ahora así que es bueno que escojamos algo fácil y significativo, por ejemplo feeds.feedburner.com/tudominio.

Por defecto feedburner contabiliza la cantidad de usuarios subscritos a nuestros feeds. En las siguientes pantallas tenemos la opción de activar el clickthrougs, es decir contabilizar el número de veces que los lectores acceden a nuestra web por pinchar en el feed. Yo no lo activo por que significa que feedburner añadirá un código html algo intrusivo en nuestros feeds para poder trazar lo que hacen nuestros lectores. Hay más opciones pero las que están por defecto suelen ser adecuadas para la mayoría

Si además del feed de los posts, queremos que el de los comentarios se sirva también a través de feedburner volveremos al inicio e introduciremos la dirección http://tudominio.com/comments/feed, en este caso http://marinerosbouzas.com/comments/feed, y en la siguiente pantalla escogemos como feed address feeds2.feedburner.com/comentarios_tudominio (en este caso feeds2.feedburner.com/comentarios_marinerosbouzas) y como feed title «Comentarios para tudominio» por ejemplo [Imagen 3].

A partir de ahora nuestros lectores podrán acceder a nuestro feed a través de http://feeds.feedburner.com/tudominio y a través de http://tudominio.com/feed. Esta última dirección es, por ahora, el valor por defecto que obtendrá alguien que introduzca en su lector de feeds la dirección de nuestro blog. Para hacer que por defecto se sirva el feed a través de feedburner debemos hacer algunos cambios en la plantilla del blog o instalar un plugin. Pero antes de entrar en esto activaremos la característica My brand.

Pasos para activar My Brand

La opción de My Brand permite que la dirección del feed que servimos a través de feedburner sea del estilo http://feed.tudominio.com/tudominio en lugar de http://feeds.feedburner.com/tudominio. Lo bueno de esto es que si alguna vez feedburner quiebra, se vuelve de pago o deja de satisfacernos nuestros lectores estarán subscritos a una dirección sobre la que tenemos el control y no a una externa.

Para activar My Brand pulsamos en My account y después en My brand. Debemos localizar una línea que pone algo parecido a [Imagen 4]

feeds CNAME XXXXX.feedproxy.ghs.google.com

Crearemos un registro CNANE en nuestro hosting que apunte a esa dirección: XXXXX.feedproxy.ghs.google.com (el valor de las XXX dependerán de cada caso)

De vuelta en la página de configuración de my brand introducimos el valor feeds.tudominio.com (en nuestro caso feeds.marinerosbouzas.com, nótese que no hay que poner el http:// delante) en el campo que aparece en el punto 2 de la imagen 4 y le damos a activar. Por supuesto en lugar de feeds podemos usar el subdominio que queramos.

Con esto hemos activado la dirección feeds.tudominio.com/tudominio para servir el feed de nuestro blog a través de feedburner pero manteniendo la dirección de subscripción bajo nuestro control. Si también servimos los comentarios a través de feedburner estos estarán, sin necesidad de tocar nada más en feeds.tudominio.com/tudominio_comentarios

Modificar nuestro tema para servir por defecto los nuevos feeds

El último paso, es indicar a la gente que accede a tu blog que no quieres que se subscriban a través del feed propio de wordpress si no a través del proporcionado por feedburner. Es posible hacer esto a través de un plugin como FeedSmith, pero si quieres hacerlo a mano tampoco es muy complicado, tan sólo tienes que editar el tema que usas y modificar un par de líneas para hacer referencia a las nuevas direcciones de los feeds. En general tendrás que hacer las modificaciones en dos lugares distintos:

  • Entre las etiquetas < header > que suelen estar en el archivo header.php debes localizar las etiquetas < link > que hagan referencia a los feed y cambiar el valor de href por las nuevas direcciones. Esto es lo que hace que cuando un lector de feeds intente descubrir por si mismo el feed de tu blog lo resuelva correctamente
  • El segundo cambio será necesario cuando en algún sitio del tema indiquemos la dirección directa para subscribirse.

Pasos para el tema default de wordpress

En concreto, particularizando para el tema por defecto que viene con wordpress lo que habría que hacer es:

  • Abrir con un editor de textos el archivo wp-content/themes/default/header.php y buscar las líneas:

    <link rel=»alternate» type=»application/rss+xml» title=»<?php printf(__(‘%s RSS Feed’, ‘kubrick’), get_bloginfo(‘name’)); ?>» href=»<?php bloginfo(‘rss2_url’); ?>» />
    <link rel=»alternate» type=»application/atom+xml» title=»<?php printf(__(‘%s Atom Feed’, ‘kubrick’), get_bloginfo(‘name’)); ?>» href=»<?php bloginfo(‘atom_url’); ?>» />

  • Borrar la segunda, la que pone algo de atom y substituir el texto que está en rojo en la primera por http://feeds.tudominio.com/tudominio
  • En el archivo wp-content/themes/default/footer.php buscar la línea

    <a href=»<?php bloginfo(‘rss2_url’); ?>«>RSS das Entradas</a> &amp; <a href=»<?php bloginfo(‘comments_rss2_url’); ?>«>RSS dos Comentarios</a>.

  • Substituir lo que está en rojo en la primera por http://feeds.tudominio.com/tudominio. Si también estas haciéndolo para los comentarios substituye también lo que está en rojo en la segunda línea por http://feeds.tudominio.com/tudominio_comentarios.