Es realmente sencillo y he tenido he podido comprobar (conmigo y con otros) como la eficacia de este método es elevadísima. Hay que seguir unos sencillos pasos:

1. Conseguir un patito de goma, preferiblemente variedad baño
2. Colocar el patito cerca nuestra, en el escritorio por ejemplo e informarle que vais a ver un poco de código, a ver si está de acuerdo.
3. Explicar al pato qué es lo que se supone que hace el código y tras esto, entrar en detalle explicándolo línea a línea.
4. En algún momento le dirás al patito lo que se supone que es lo siguiente a hacer y te darás cuenta que eso no es lo que realmente está haciendo tu código. El pato se mantendrá sentado serenamente, contento de saber que te ha ayudado en tu tarea.

Existen variantes al patito de goma, como otro tipo de peluches y objetos, pero su efectividad no está tan demostrada como con el patito de goma.

1. Crear un fichero hosts en tu ordenador (o usar el que ya tienes en /etc/hosts)
2. Remontar el emulador y copiar el fichero anterior

La necesidad de remontar viene porque si no, el dispositivo está como sólo lectura y por lo tanto es imposible escribir nada en él.

Supongamos que tenemos partimos de nuestro /etc/hosts, iríamos al directorio donde tenemos las tools del SDK y teclearíamos:

adb remount
adb push /etc/hosts /system/etc/

También es posible coger el fichero hosts que tiene el emulador (por ejemplo, copiandolo a nuestro directorio /tmp):

adb push /system/etc/hosts /tmp

¿Y en qué casos nos puede hacer falta? Bueno, yo en concreto lo he necesitado cuando estaba desarrollando una aplicación que se alimentaba de un webservice. Realizaba el desarrollo del webservice en paralelo y por lo tanto no estaba (todavía) en la máquina de producción. De esta forma, gracias al fichero hosts obligaba al emulador a buscar en mi entorno de desarrollo en vez de ir al de producción, haciendo que la aplicación tuviese un comportamiento transparente, en código, sobre dónde atacar.

El truco está en hacer un echo del valor y asegurarnos en la llamada de la función que se asigna a una variable. Es decir, nuestra función sería:

function retorna_texto {
    echo -n "este es el valor a retornar"
}

Y la llamada:

VALOR=$( retorna_texto )

Ahora en ${VALOR} tendremos el texto tal y como queríamos

Antes de ponerlo en un repositorio público como por ejemplo github, hay que cambiar esto y lo haremos de una forma muy sencilla usando git filter-branch. Este comando nos permite hacer multitud de diferentes cambios sobre todas las ramas en el proyecto y, entre otras cosas, cambiar estos dos datos que nos hacen falta.

Supongamos que los datos que queremos poner son:

• Usuario: Tatai
• E-mail: tatai@example.com

Entonces, el comando que tenemos que usar es:

git filter-branch --env-filter 'export GIT_AUTHOR_NAME="Tatai";GIT_AUTHOR_EMAIL="tatai@example.com"'

Tras ejecutar el comando, veremos como se reescriben todos los commits.

En caso de querer cambiar únicamente ciertos commits y no todos, podemos añadir al final del comando el intervalo, por ejemplo, para los 10 últimos commits: HEAD~10..HEAD

Para poder conseguir esto, supongamos que tienes estos datos:

• Cuenta personal
  • Usuario: usuario_casa
  • Fichero de clave: ~/.ssh/casa
• Cuenta trabajo
  • Usuario: usuario_trabajo
  • Fichero de clave: ~/.ssh/trabajo

Lo que habría que hacer es tener un fichero de configuración ssh (recordemos que está en ~/.ssh/config) de la siguiente forma:

Host github
    HostName github.com
    User usuario_casa
    IdentityFile ~/.ssh/casa

Host github-trabajo
    HostName github.com
    User usuario_trabajo
    IdentityFile ~/.ssh/trabajo

La diferencia es sutil: cambia el valor que ponemos en Host (los espacios o tabulaciones son opcionales, yo los uso para dar un poco más de orden).

Con esto, tenemos que cambiar la dirección con la que nos conectaremos con la cuenta de trabajo. Si por ejemplo, para añadir el repositorio remoto usamos:

git remote add origin git@github.com:usuario_trabajo/proyecto.git

Ahora deberemos poner:

git remote add origin git@github-trabajo:usuario_trabajo/proyecto.git

Es decir, ssh se encargará automáticamente de hacer el cambio por nosotros y, de esta forma, no tendremos problemas decidiendo con qué usuario debe conectar o no, está todo en el fichero de configuración

• Dirección: punto.de.entrada.al.servidor.com
• Usuario: miusuario
• Puerto 12345
• Fichero de clave: /home/user/.ssh/fichero.clave

El chorizo comando que nos hace falta es:

ssh punto.de.entrada.al.servidor.com -l miusuario -p 12345 -i /home/user/.ssh/fichero.clave

Casi nada

Bien, hay una forma de acortarlo un poco. El truco está en configurar todos estos parámetros en un fichero. Este fichero lo podemos encontrar en nuestra cuenta de usuario, concretamente en ~/.ssh/config. Este fichero por defecto viene vacío pero, siguiendo con el ejemplo escribimos estas líneas en su interior:

Host     miservidor
HostName punto.de.entrada.al.servidor.com
User     miusuario
Port     1234
IdentityFile /home/user/.ssh/fichero.clave

Con este simple gesto, ahora podemos cambiar el comando ssh anterior por:

ssh miservidor

Casi nada la diferencia

Si investigas un poco el man de ssh_config seguro que encuentras muchas cosas de utilidad. Más adelante daré otro truco relacionado con este.

P. P: y como bien te recomendaría un administrador de sistemas, si encima añades el hostname a tu /etc/hosts, irá “volado”! Se ahorrará la resolución DNS

Enlaces:

• Usar pares de claves para acceder a los servidores de forma sencilla, cómoda y… segura
• man ssh_config

git checkout-index -a -f --prefix=/path/export/

Importante: no olvides la última barra (slash).

Y ahora la breve explicación. checkout-index crea una copia de los fichero en el index a donde le indiques, pero sin sobreescribir, algo que evitaremos con la opción -f. Con la opción -a le indicamos que copie todos los ficheros en el index y con –prefix indicamos un prefijo que queremos que añada a todos los ficheros que extraiga (es decir, poniendo un path, es un truco para decirle que lo extraiga en otro lugar y con el mismo nombre, de aquí que tengamos que poner la última barra).

Es una forma sencilla y necesitas de tu copia local en el mismo servidor, algo que me gustaría evitar, pero de momento, tiraremos con esta opción.

cat /dev/urandom | tr -dc "a-zA-Z0-9-_\.\!\$\?" | fold -w 10 | head -n 1

Ok, explicación:

• /dev/urandom: fuente aleatorio de información
• tr -dc “a-zA-Z0-9-_\.\!\$\?”: elimina cualquier caracter que no sea una letra, un dígito o alguno de los símbolos – _ . ! $ ?
• fold -w 10: obliga a que el tamaño sea de 10 caracteres
• head -n 1: mostrar una contraseña

Así pues, si quieres que tu contraseña tenga x caracteres, cambia el 10 del comando fold por ese valor y si quieres obtener más de una contraseña, indicalo cambiando el 1 de head por tantas como quieras. Por supuesto, si quieres cambiar los caracteres válidos, modifica la expresión de tr.

Bueno, una de los últimos problemas que me he encontrado ha sido cómo obtener un DOMDocument de un DOMNode ya que quería usar XPath a partir de dicho DOMNode, algo que no es posible si no es DOMDocument.

La verdad es que no he encontrado mucha información ni algo bonito para presentar. Sólo tengo esto, que por lo menos me ha servido (he preferido no pararme a medir el consumo de memoria o de proceso por miedo a querer descartar la idea y perder todavía más tiempo, jeje):

$doc = new DOMDocument();
$doc->loadXML($node->ownerDocument->saveXML($node))

El “truco” es tan sencillo como como crear un nuevo DOMDocument en el que importamos (vía método loadXML) el nodo a través del código XML que genera. Este código se obtiene con la propiedad ownerDocument del DOMNode (que nos retorna el DOMDocument) y sobre el que podemos llamar a saveXML, método que expulsa el XML del elemento que le indiquemos, en este caso, nuestro DOMNode.

Básicamente consiste en sacar el path completo donde se encuentra un ejecutable en nuestro sistema. Si queremos, por ejemplo, buscar donde está el comando ls, escribimos:

$ which ls

o bien

$ whereis ls

El resultado de ambos es muy parecido: /bin/ls

¿Dónde está la diferencia? Pues which acepta por ejemplo el parámetro -a con el que se muestran todas las coincidencias (no únicamente la primera) o el parámetro -p que retorna 1 si ha encontrado el ejecutable o 0 si no (útil para scripts).

Mucho ojo, estos dos comandos únicamente buscan en aquellos paths definidos en $PATH. Si necesitas buscar fuera de los paths las dos opciones más comunes son:

$ locate ls

O más “a lo bruto”:

$ find / -name 'ls' -type f

Hay que tener en cuenta que locate requiere que se haya indexado el contenido en el disco duro. Por esto, es posible que alguna vez os haya ocurrido que el ejecutable no aparecía, quizás ejecutásteis el comando demasiado pronto.