Actualizar la versión de Antroid de un HTC Tattoo (II parte)

Posted: marzo 18th, 2012 | Author: | Filed under: Sin categoría | Tags: , , , , , | 2 Comments »

Las consideraciones generales sobre como actualizar las puedes leer en la primera parte de este artículo.

Las principales instrucciones que yo he seguido han sido la de los propios desarrolladores de la ROM que he instalado. Lo cuento un poco más detallado. Deberías seguir las instrucciones de esa guía, lo que aquí escribo son más bien posibles problemas y es complementario a lo que allí pone.

Los pasos a seguir

  1. Instalar jdk y android sdk. El único componente que hace falta es “SDK Platform tools” que es lo que contiene el comando adb.
  2. Enciende el GPS. A veces no lo detecta si lo tienes apagado y deja de funcionar. Y recuerda que las operaciones que hagamos a partir de ahora con el teléfono deben hacerse con la opción “depuración” activada (En tu teléfono, ajustes -> aplicaciones -> desarrollo)
  3. Rootear el dispositivo. Con el sistema proporcionado con Cyanogenmod yo conseguí acceso de Root (es cuando el prompt se convierte en #) pero no conseguí instalar el comando “su” para poder convertirse en root de forma sencilla. Así que cada vez que necesitaba acceso de root (cuando en los tutoriales se menciona usar “su“, tenía que ejecutar los comandos que se indican en el punto 5 y 6  de la parte de rooting). Un par de avisos:
    • Si parece que se queda colgado pulsa intro para ver si aparece el prompt
    • Si no consegues hacerlo, habilita la opción de instalar software desde fuentes no fiables y prueba a instalar alguna aplicación como UniversalAndroot. Recuerda que puedes instalar aplicaciones con adb usando adb install aplicación.apk
  4. Haz copia de seguridad con una aplicación como Titanium Backup o Mybackup … instalables desde el Market.
  5. Instala el recovery. A mi la versión de ClockModRecovery que está enlazada en las instrucciones me dió problemas. Descargué otra versión distinta de algún sitio que no recuerdo, y al que llegué buscando el error que me daba al intentar instalarlo.
  6. Apaga el teléfono y vuelve a encenderlo en modo recovery: botón de encendido + botón teléfono (verde/descolgar) + botón casa (home)
  7. Ve a la opción de “backup and restore” y haz un backup. Dejará en un directorio de la SD clockwordmod/backup/fecha una copia de seguridad de tu ROM actual y tus datos. Enciende el teléfono en modo normal y copia esa carpeta al pc.
  8. Llegamos al punto de no retorno. Si todavía quieres segir, enciende en modo Recovery y ejecuta las siguientes acciones:
    • Wipe de datos
    • Wipe de caché
    • Wipe de Dalvik Caché (en “Advanced”)
    • Format / System (en “mounts and storage)
    • Factory Reset
  9. Sube al teléfono la ROM y las google apps. Como ROM yo emplee un nightly build con buenas críticas en los foros. Recuerda que puedes subirlas a la SD del teléfono con adb push <nombre_de_fichero> /sdcard.
  10. Enciende en modo recovery y en instalar zip escoge primero la rom y luego las google apps. Escoge reboot y cruza los dedos.

La primera vez a mi me tardó en arrancar unos 3 o 4 minutos así que paciencia. Comprueba que todo funciona, GPS, Wifi, llamar etc … y listo. Acuerdate de configurar la red preferida, el punto de acceso, …

En caso de problemas con la batería

Espera a haber hecho un par de recargas completas. Si tras eso sigue habiendo problemas:

  1. Cargala al 100% y déjala todavía un rato más
  2. Sin desconectar el teléfono se enciende en modo recovery
  3. Se hace un wipe de la batería
  4. Apágalo y desconectalo
  5. Enciende el teléfono, y no lo apagues ni lo reinicies hasta que la batería se descargue totalmente por si sóla

Por otro lado, la ROM de Cyanogen viene con un launcher llamado ADW Launcher. Alguna gente opina que el que menos batería gasta es “Launcher Pro”. Pero esto parece ser más bien para gustos.

Y una cosa que no me ha quedado clara es si la ROM de Cyanogen por defecto hace overclock del procesador, es decir como si hiciera girar más rápido al reloj que marca al ritmo que debe funcionar el procesado (que no tiene nada que ver con la hora). Esto gasta batería y puede controlarse con una aplicación llamada SetUP. Si bajas la frecuencia el teléfono será menos responsivo pero disminuirá el consumo de batería.

El resultado


Actualizar la versión de Antroid de un HTC Tattoo (I parte)

Posted: febrero 26th, 2012 | Author: | Filed under: Sin categoría | Tags: , , , , , | 2 Comments »

Hay muchos foros y tutoriales explicando como actualizar la versión de Android de un teléfono HTC Tattoo. Este es (la primera parte de) el mio. Aunque antes de continuar leyendo deberías saber que todo lo escrito aquí proviene de lo aprendendido en apenas un fin de semana así que puede ser incorrecto.

Los HTC Tattoo vienen con una de las primeras versiones de Android que salió al mercado, la 1.6. Esto impide usar alguna de las aplicaciones actuales más conocidas (leáse Whatsapp), tiene problemillas con el bluetooth, …

El principal desarrollador de Android es Google. Los fabricantes de teléfonos colaboran en el desarrollo de Android y además hacen algunas adaptaciones propias para sus propios teléfonos. Las compañías de servicio telefónico, tampoco acostumbran a quedar tranquilas con la versión que desarrolla el fabricante y empaquetan su propio software en el teléfono, a veces es simplemente cambiar la pantalla de inicio, a veces cambios más profundos como substituír el Market de Google por uno propio.

En el caso del Tatto ni el fabricante del teléfono ni la compañía que lo distribuye están interesados en sacar una actualización a versiones más modernas de Android; y aquí es donde entra en juego la scene. Como Android es (semi) libre hay equipos de programadores que lo modifican y adaptan para sus propias necesidades y publican esas modificaciones de forma gratuita. Entre estas modificaciones está el reescribir los drivers necesarios para que teléfonos antiguos puedan ejecutar versiones de Android modernas. Estos programadores acostumbran a especializarse en modelos o marcas específicas de teléfonos. También es habitual que haya quien re-empaquete el código que desarrollan equipos más o menos consagrados. Los de cyanogenmod por ejemplo tienen el código en github y hay quien se dedica a publicar snapshots de los binarios de ese código y a hacer modificiones

Yendo a lo que nos ocupa que es actualizar el Tattoo hay que tener claros varios conceptos:

  • Versión de Android que queremos actualizar. Recomendable la 2.3 por ser la más en uso en estos momentos
  • Se denomina ROM al paquete de software binario que contiene el sistema operativo que vamos a instalar. Por problemas de copyright las ROM no vienen con las aplicaciones de Google (Market, sincronización de contactos, …) que deben ser instaladas a parte. El desarrollador de la ROM suele recomendar cuales son las gapps (google applications) que funcionan sobre su ROM.
  • Para instalar la ROM (flashear el teléfono) es necesario un sistema intermedio, al que se denomina recovery. El recovery es una especie de sistema operativo muy básico que nos permite hacer un borrado (wipe) de distintas partes del teléfono, instalar la ROM, hacer copia de seguridad de nuestra ROM y datos actuales, … Por supuesto hay un montón de recovery distintos, y en función de la ROM que queramos instalar usaremos uno u otro, generalmente el desarrollador de la ROM recomienda uno.
  • GoldCard. Debo decir que no he acabado de entender para que vale esto. Recomiendan hacerlo, porque permite recuperar un teléfono que se queda en modo ladrillo (brick), pero yo sigo sin verlo claro. Por lo que he visto me da la impresión de que la goldcard no tiene nada que ver con el teléfono, si no con la SD.
  • Rootear el teléfono. Android es un sistema operativo basado en linux. Tiene por tanto particiones (algunas de las cuales se montan por defecto en sólo lectura), permisos, … A conseguir acceso de root, se lo llama rootear el teléfono.
  • Android SDK. Google proporciona lo que se llama un SDK (Software Development Kit). Son un conjunto de aplicaciones que ayudan en las tareas de desarrollo y depuración de software para teléfonos Android. En este caso lo que más nos interesará es el comando “adb” que permite desde el pc abrir una shell (tipo ssh) en el teléfono, subir archivos al teléfono, …

Como siempre hay un montón de tutoriales distintos de como actualizar el teléfono, y como siempre, no te valdrá con seguir ninguno de ellos al pie de la letra, si no que siempre pasará algo y tendrás que acabar combnándolos. Dejo aquí los que yo he leido:

En la segunda parte, voy al grano de como lo hice yo.


Taller de gvSIG-EIEL en Valencia. Método 2

Posted: noviembre 29th, 2011 | Author: | Filed under: General | Tags: , , , , | 5 Comments »

Como comentábamos en la anterior entrada hemos creado un fichero .iso que podéis “quemar” en un pendrive de al menos 4GB para seguir el taller de gvSIG-EIEL. Podéis descargar el .iso desde este enlace.

Tras quemarla podréis arrancar vuestro ordenador desde el PC configurando en la BIOS que arranque en primer lugar desde ahí. Se trata de una versión de ubuntu con gvSIG-EIEL y una base de datos PostGIS con datos de prueba, todo preinstalado.

Para quemar el pendrive podéis seguir estas instrucciones. para linux o para windows.

El usuario por defecto es “custom” sin clave. Para conectar a la base de datos usaremos:

  • servidor: localhost
  • usuario: user
  • clave: user
  • puerto: 5432
  • esquema: eiel_map_municipal
El fichero .iso también debería poder ser ejecutado desde una máquina virtual.
Si tenéis algún problema dejad un comentario o comentádnoslo antes del taller. Estaremos todos los días por las jornadas.

Maquetación de múltiples ficheros de texto usando LibreOffice

Posted: octubre 6th, 2011 | Author: | Filed under: General | Tags: , , , , | No Comments »

Cartolab está colaborando con Ingeniería Sin Fronteras en un proyecto financiado por la Xunta de Galicia para la elaboración de materiales para un curso de Sistemas de Información Geográfica y Cooperación al Desarrollo. En la elaboración del curso tenemos la suerte de colaborar también con iCarto y con el Laborate. Además el SIGTE se encarga de revisar el trabajo y poner la plataforma de teleformación. Gracias a todos ellos por hacer posible este artículo.

Maquetar múltiples ficheros con LibreOffice

Uno de los puntos que defendemos en el curso es de la importancia del uso de software libre en los proyectos de cooperación, y por coherencia, tratamos en la medida de los posible de emplear unicamente herramientas libres para elaborar los contenidos. Nos encontramos por tanto con un equipo de alrededor de 9 personas en varias instituciones distintas editando cerca de 20 ficheros de texto distintos con LibreOffice, lo cual entre otras cosas genera el problema de obtener al final una maquetación coherente. Está claro que existen soluciones más imaginativas por ejemplo usar latex con git como repositorio de información pero en ciertos contextos esto es simplemente imposible.

Cuando queremos que un documento de texto tenga un formato consistente empleamos estilos, cuando necesitamos un formato consistente en múltiples ficheros empleamos plantillas.

Que es una plantilla y como se crea

Apurando la definición se podría decir que una plantilla no es más que un documento de texto de LibreOffice con extensión .ott en lugar de .odt en el que se han definido los estilos del documento, las cabeceras, ciertos textos, … El truco está en que cuando creamos un nuevo documento a partir de una plantilla este documento se queda en cierta manera vinculado a la plantilla. Por tanto cuando modifiquemos la plantilla se modificarán los documentos asociados.

Al menos esa es la teoría en realidad hay algunos handicaps:
– No todo lo modificado en la plantilla se actualiza en los documentos. Los estilos si que son actualizados pero textos que podamos tener por las páginas por ejemplo una portada no se actualizan. Aunque hay una extensión que lo arregla.
– La actualización no es automática. Cuando abrimos el documento vinculado, si la plantilla ha cambiado nos pregunta si queremos actualizar los estilos, no se actualizan por si mismos.
– Las plantillas pueden ser compartidas pero no es lo más cómodo del mundo.
– Una precaución que habría que tener es que en general no debemos modificar el estilo en el documento. Debemos: Cerrar el documento, modificar la plantilla y volver a abrir el documento para que se actualicen.

A pesar de estos handicaps el disponer de plantillas para los documentos corporativos de tu empresa puede acabar ahorrándote mucho tiempo.

  • Para crear una plantilla lo más fácil es crear un nuevo documento de texto y luego Archivo -> Plantilla -> Guardar.
  • Para crear un documento a partir de una plantilla Archivo -> Nuevo -> Plantillas de documentos.
  • Para editar una plantilla, desde cualquier documento, Archivo -> Plantilla -> Administrar, seleccionamos la que nos interese y en botón desplegable llamado Comandos le damos a editar. Para guardarla usamos el mismo procedimiento que para crear una nueva (Archivo -> Plantilla -> Guardar) pero seleccionando la ya existente para que la sobreescriba.

Compartir la plantilla

Compartir la plantilla no es del todo necesario. Si una persona tiene la plantilla en su ordenador y maqueta todos los documentos, aunque el resto no tengan la plantilla cada documento individual si que conservará los atributos de los estilos. Por tanto se puede continuar editando el documento usando los estilos predefinidos. Pero no podrá crear nuevos estilos o modificarlos porque creará inconsistencias. Tendrá que solicitar a quien tiene la plantilla que la modifique y abra todos los documentos para que estos se actualicen.

Si no disponemos de la plantilla en nuestro ordenador tampoco podremos crear nuevos documentos a partir de la plantilla. Una solución por supuesto es mandarla por correo-e cada vez que haya un cambio, pero existe un método algo más sofisticado.

En nuestro caso concreto empleamos DropBox (nadie es perfecto) para compartir los materiales del curso, de modo que podemos dejar la propia plantilla en una carpeta compartida. La persona que crea la plantilla la exporta (Archivo -> Plantilla -> Administrar, seleccionamos la que queremos y en el botón de Comandos->Exportar).

LibreOffice nos da la oportunidad de importar plantillas (misma secuencia de menus que para exportar) pero si hacemos esto creará una copia local de la plantilla y las modificaciones en el original no se verán reflejadas. Lo que debemos hacer es decirle que consideré la carpeta que nosotros queramos como una carpeta válida de plantillas. Para ello:

Herramientas -> Opciones -> Rutas -> Marcamos plantillas, le damos a editar, agregamos como ruta nueva la de nuestra carpeta compartida y la seleccionamos.

Por desgracia, la cosa no iba a ser tan fácil, las plantillas que pueda haber en esa carpeta no son reconocidas automáticamente y ni no vale con importalas así que hay que hacer un pequeño truco.

  1. Configuramos la ruta a la carpeta compartida si no lo hemos hecho todavía
  2. Cortamos y pegamos en otro sitio la plantilla que está en la carpeta compartida. Es importante por tanto que no haya en en la carpeta de plantillas una que ya tenga el nombre que vamos a usar, si no LibreOffice le asignará otro distinto y el fichero compartido tendrá un nombre distinto por tanto.
  3. Abrimos mediante doble click el fichero que contiene la plantilla y guardamos la plantilla a partir de él (Archivo -> plantilla -> guardar). De nombre le pondremos el que hayamos acordado con el resto de gente respetando mayúsculas etc … Muy importante respetar escrupulosamente el nombre
  4. Con eso estaría listo. Ya tendriamos esa plantilla disponible en nuestro sistema y cada vez que la modificáramos estaríamos tocando el fichero compartido de modo que se le actualizaría a los demás.

En próximos artículos seguiremos contando algunos trucos de los estilos que podemos usar a la hora de hacer la plantilla el uso de campos, …


Como carga gvSIG las extensiones

Posted: septiembre 2nd, 2011 | Author: | Filed under: General | Tags: , , , | 4 Comments »

En la línea abierta por Andrés de “Como gvSIG hace xxx” os presento un artículo que explica como se gestiona la carga de las extensiones en gvSIG. Antes de nada debo agradecer a Cartolab cederme tiempo para poder escribirlo.

Lo que sucede cuando lanzamos gvSIG es que la máquina virtual de java ejecuta el método main() de la clase Launcher de andami, el framework que sostiene el sistema de ventanas y plugins de gvSIG.

A efectos de este artículo sobre la carga de extensiones podemos decir que ese método main() es el responsable de lo siguiente:

  1. Procesar los parámetros que se le pasan por línea de comandos
  2. Cargar los plugins
  3. Cargar las clases de los plugins
  4. Recuperar la configuración persistida de los plugins
  5. Inicializar las extensiones
  6. Cargar menus y toolbars
  7. Hacer la postinicialización de las extensiones

1.- Procesar los parámetros que se le pasan por línea de comandos

Lo más habitual es que la orden que ejecute el sistema operativo (quitando los parametros que se pasan a la jvm) sea algo parecido a:

$ java com.iver.andami.Launcher gvSIG gvSIG/extensiones “$@”

donde la parte en negrita serían los parámetros que pasamos al main(). En concreto ese segundo parámetro gvSIG/extensiones es el que está definiendo donde está la carpeta de plugins de gvSIG, como ruta relativa desde donde se encuentra el fichero andami.jar.

Es decir, que si bien el directorio de extensiones suele estar en un punto predefinido nosotros podriamos escoger otra ubicación.

2.- Carga de los plugins

Procesados los parámetros de entrada la aplicación recorre todos los directorios contenidos en la carpeta de plugins. Si dentro del directorio existe un fichero de nombre “config.xml” lo parsea y en caso de ser correcto añade el par [“nombre del directorio”, objeto PluginConfig] al campo de la clase Launcher

private static HashMap pluginsConfig = new HashMap();

Donde PluginConfig es una clase que se encarga de mantener toda la información que aportan los ficheros config.xml.

Lo más interesante de esta fase es entender que el orden en que se recorren los directorios, y por tanto el orden en que luego se inicializarán las extensiones, es aleatorio, o en realidad es el orden que devuelve el método lisFiles() de la clase File de Java, que especifica en su documentación que el orden en se devuelven los ficheros no está asegurado y supongo, dependerá de la implementación concreta de la máquina virtual y del sistema operativo que se emplee.

Hay que aclarar que en este contexto, un plugin, es igual a un directorio contenido dentro del directorio de extensiones/plugins definido como parámetro.

3.- Carga de las clases de los plugins

Lo siguiente que intenta hacer es indexar todas las clases de todos los plugins. Para ello recorre pluginsConfig, solicitando el valor de la etiqueta del config <libraries library-dir=”VALOR” />. Lo más habitual es que ese VALOR sea “./”, es decir el propio directorio del plugin. Para cada plugin mantiene un objeto PluginClassLoader que basicamente contiene un índice de todos ficheros .class que están dentro de los ficheros .zip o .jar que están en ese library-dir.

Para cada plugin se crea un objeto PluginServices que a su vez mantiene la instancia del PluginClassLoader que le corresponde. Esos PluginServices se almacenan en el campo

private static HashMap pluginsServices= new HashMap();

de la clase Launcher.

Hay que tener en cuenta que a la hora de cargar las clases de un plugin, si en el config se ha definido que depende de otro mediante una etiquetacarga la clases de la dependencia (de forma recursiva) antes que el nuestro. Por tanto, en pluginsServices los plugins se reordenan respecto a pluginsConfig poniendo los plugins de los que se depende antes. Se mantiene también una variable pluginsOrdered con el nombre de los plugins en el mismo orden que pluginsServices

4.- Persistencia de los plugins

Se actualiza el andamiConfig que contiene una lista (el fichero andami-config.xml habitualmente) que persiste con todos los plugins presentes el directorio de plugins.

Luego se recupera de disco la configuración persistida de los plugins en el fichero plugins-persistance.xml, y se setea esa configuración en el PluginServices asociado a cada plugin.

5.- Inicialización de las Extensiones

Es en esta fase cuando salen por consola los mensajes de:

Initializing extensions from “Nombre_del_plugin” (para cada plugin)

y

Initializing “Nombre_de_la_Extension” … (para cada extensión)

Se recorre pluginsOrdered, y para cada plugin se crea una instancia de cada extensión (en el orden que se define en el config del plugin) y se llama a su método initialize(). Además se almacena esas instancia en el campo de Launcher:

private static ArrayList extensions=new ArrayList();

Por el medio crea también un objeto ExtensionDecorator que nos da un control adicional sobre las extensiones pero esto no nos interesa a los efectos de este artículo.

6.- Menus y Toolbars

Se cargarn los menus y los toolbars definidos por los plugins a través de los métodos installPluginsMenus() y installPluginsControls().

7.- Post-inicialización de las extensiones

Se va llamando al método postInitialize de cada extensión en el orden en que aparecen en el array extensions. Con este paso finalizaría el proceso de carga.

Una cosa que no he investigado a fondo pero que intuyo que es así, es que en algún momento de este proceso se asocian las instancias del array extensions a los menús y botones del toolbar. De este modo las extensiones (clases que heredan de extension y aparecen en los config) se comportan como una especie de singleton, porque gvSIG siempre la recupera de ese array de extensiones, y cuando el desarrollador externo llama a PluginServices.getExtension(Class) la está recuperando de ahí también (del ExtensionDecorator del que hablamos antes en realidad, pero la idea es la misma)

Esto explica también porque cuando recompilamos nuestro código, si cambiamos algo en la clase de la extensión debemos cerrar y abrir gvSIG. La instancia de la extensión se crea durante la carga de gvSIG y se mantiene hasta que cerramos gvSIG, y por tanto no es “recargada” de los nuevos .class

Me quedan un par de dudas que quedan para estudiar para próximos posts o para quien se anime a escribir más artículos de la serie de “Como hace gvSIG XXX”:

  • Al parecer existe una extension del tipo ExclusiveUIExtension a la que se hace referencia en Launcher.initializeExclusiveUIExtension() que no tengo muy claro como funciona
  • Estaría bien explicar en detalle el comportamiento de los ExtensionDecorator
  • Estaría bien explicar detalladamente el proceso de creación y ubicación de los menús y toolbars
  • Algunas partes del código son un poco liosas. Tengo algunas ideas de como refactorizarlo así que si alguien se anima que pregunte

Preparar un ordenador con Windows para asistir al curso de OpenLayers.

Posted: mayo 19th, 2011 | Author: | Filed under: General | Tags: , , , , , , , | 5 Comments »

Un par de instrucciones rápidas para el curso de OpenLayers que habrá mañana en la Escuela de Caminos en Coruña impulsado por xeoinquedos, No te asustes por el texto es mucho más fácil de lo que parece. En resumen baja los archivos que se enlazan en este post y haz doble click sobre ellos :) Los enlaces son para Windows de 32bits, si usas 64 deja un comentario y te ayudamos.

1.- Instalar Apache.

La forma más sencilla es descargar Xampp desde esta dirección [1] e instalarlo haciendo doble click. Las opciones que trae por defecto son adecuadas para la mayoría de los equipos.

Para lanzar Apache ejecuta el acceso directo que aparece en tu escritorio y luego pulsa en el botón “Start” que está a la derecha de Apache. Si salta un mensaje del antivirus pulsa en desbloquear. Para comprobar que funciona abre un navegador y escribe en la barra de direcciones http://localhost

Si se abre una página naranja ya lo tienes :)

Si tienes algún problema, tienes instrucciones más detalladas en este enlace [3]

2.- Instalar un intérprete de Python

Descarga python 2.7.1 para windows desde este enlace [2]. Instálalo mediante doble click, las opciones por defecto son una vez más adecuadas para la mayoría de los equipos.

3.- Instalar python como módulo cgi para Apache.

Descárgate este fichero [4] y cópialo dentro de la carpeta c:xamppapachemodules. Cámbiale el nombre de mod_wsgi-win32-ap22py27-3.3.so a mod_wsgi.so

A continuación abre con el WordPad el fichero c:xamppapacheconfighttpd.conf Localiza el conjunto de líneas que empiezan por el texto LoadModule y añade al final

LoadModule wsgi_module modules/mod_wsgi.so

Salva el fichero y vuelve a probar si funciona Apache.

4.- Firebug.

Lo mejor es que traigas instalado un navegador como firefox con el complemento firebug. Para instalar firebug simplemente pincha en este enlace [5] desde firefox y sigue las instrucciones.

Si usas firefox 3.6 debes descargar la versión 1.6, si usas firefox 4 debes usar la 1.7 preferiblemente. Para saber que versión de firefox tienes instalada pincha en Ayuda -> Acerca de

Aviso: En este momento la página de firebug parece caida así que si no funciona prueba con este otro enlace [8]

5.- Editor de texto

Con el bloc de notas o el WordPad es suficiente para lo que vamos a hacer pero si quieres instalar uno más potente puedes probar notepad++ [9]

6.- Copia el archivo proxy.cgi que se proporciona en los materiales del curso al directorio c:xamppcgi-bin

Y listo. Como es habitual en estas cosas, esto más difícil de escribir que de hacer.

Por último agradecer a Micho, Xurxo, Gracia, Cartolab y la Escuela de Caminos, sin los que esté curso no sería posible.


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

Posted: mayo 15th, 2011 | Author: | Filed under: General | Tags: , , , | 1 Comment »

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

Posted: marzo 12th, 2011 | Author: | Filed under: General | Tags: , , , | 2 Comments »

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

Posted: julio 10th, 2010 | Author: | Filed under: General | Tags: , , , , , | 1 Comment »

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

Posted: julio 3rd, 2010 | Author: | Filed under: General | Tags: , , , , , , | No Comments »

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 &gt; /ruta/fichero_a_guardar"

Por ejemplo

ssh fpuga@dreamhost.com "mysqldump --opt --user=fpuga_bd -p --host=localhost conocimientoabierto_bd_wordpress &gt; 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: