These are the steps I followed to upload my existing local git repository to a new Bitbucket repository while keeping the whole commit history. You can use this simple steps to move your source code to GitHub, Beanstalk or any other repository you like, commands are just the same. I put as example Bitbucket because you can have unlimited private repositories for free.

How to do it...

• Register to bitbucket for free, add your SSH key, and create an empty repo.
• Add your public key to your account under Account > SSH keys (this is just pasting the content after a cat ~/.ssh/id_rsa.pub, write ssh-keygen if you don't have one)
• Then you have an URL for cloning like this: git@bitbucket.org:your_user/your_repo.git
• Then go to the folder where your repo is:
  cd /path/to/my/repo
• Then upload it to Bitbucket:
  git push --mirror git@bitbucket.org:youruser/your_repo.git

That's it, with this you will be able to keep the whole log history, as shown in the sample picture

Me tienen contento!

Hace muchísimo que deberían haber incluído la versión de PHP 5.3 en los paquetes php por defecto de CentOS, pero parece que se van a quedar con la 5.2 hasta el fin de los tiempos. Ofrecen la versión 5.3 como un paquete separado (php53), lo que implica desinstalar PHP y librerías asociadas para reinstalar la 5.3 con este paquete distinto (incompatible con el anterior claro).

Así que, no pudiéndome aguantar más y con mono de namespaces, funciones lambda y toda la pesca, he migrado mi CentOS 5.5 a la 5.7 (esto no viene al caso ahora ni es necesario, via yum update.) y luego PHP a la 5.3 utilizando un repo externo. Para ello me he servido del repositorio REMI. Si no lo tienes para instalarlo sólo hay que hacer:

cd /etc/yum.repos.d/
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

Y para disfrutar de la 5.3:

yum --enablerepo=remi update php

Si no tienes aún PHP instalado entonces usa "install" en vez de "update".

Ale! Todo listo.

If you are a Vim user, chances are that you also work with several machines, and you spread the same configuration over them.

I do share my vim configurations between Windows, Mac and Linux and store the same configuration for all the environments in my Dropbox folder. The idea is to have a central place where I can manage all my Vim installations, and then link it. Easy as that.

I synchronize .vimrc and .vim using Dropbox, but many other forms are possible, such as Ubuntuone, Sugarsync or any other cloud service you might have. And even a GIT/SVN/Mercurial/whatever repository based storage that you update from time to time.

How it works?

Put all your vimrc and vimfiles in a centralized place. I use:

~/Dropbbox/DotFiles/vimrc [the plain text configuration file]
~/Dropbbox/DotFiles/vimfiles [the directory]

Then in every machine, I have the ~/.vimrc (_vimrc in windows' gvim) with a single line, referencing the configuration stored in the dropbox folder. I could directly link the file, but sometimes you may want to add a couple more of lines specific to a machine. The content of the ~/.vimrc file is just:

source ~/Dropbbox/DotFiles/vimrc
# Additional stuff specific to the machine here...

This will include the vimrc stored in my Dropbox folder. Finally, I just create a symbolic link to the vimfiles folder:

ln -s  ~/Dropbbox/DotFiles/vimfiles ~/.vim

Now, apply this steps to all machines you have, and whenever you change your .vimrc or install a new plugin will be available to all your installations.

When I created my gmail account, there was a counter giving you everyday more space. They "sold us" the product as if you never had to delete email again. By looking at that counter it seemed that by now I should have more than a Terabyte of data, truth is that after many years I have less than 8GB. Although it's a lot of space for the email, if you have automatic notifications, reports, and so on... it's easy to see how you are fastly approaching to the limit.

So, from time to time, it is needed to clean up a little bit your GMAIL account. At least for old reports and automatic emails which may not have sense anymore.

I usually delete some of this nonsense emails by typing in the search box:

label:Label_to_delete before:2011/1/31

Instead of "Label_to_delete" write a "secure" label you want to clean. I say secure because if you label your email with vague rules it is possible that you delete something you shouldn't.

When the search results appear, select the checkbox to check them all, and then click on the link that selects all the items matching that search. With this you will be able to delete thousands of undesired emails in a couple of clicks. 

The search box of Gmail is very powerful. If you are used to code, you'll find how easy is to add conditions. A very simple example of that would be:

label:CRONS after:2011/01/01 AND before:2011/02/01 AND from:root AND !has:attachment

Translation: Delete emails coming from CRONS in January coming from root user and without any attachment.

Give it a try!

Esta es una de aquellas cosas que uno hace una y otra vez y al final pierde 10 minutos intentando recordar los comandos o buscando la información.

Para conectar a un servidor remoto por SSH sin usuario ni contraseña todo lo que hace falta es compartir una clave entre cliente y servidor. Los pasos son "mu" sencillos:

1. Asegurarse que la carpeta .ssh existe en el servidor al que nos queremos conectar
2. Crear una clave RSA pública en la máquina cliente (la que se conecta):
   

   ssh-keygen -t rsa

   Cuando se te pida por un password, dale al enter sin poner ninguno (este es el propósito del artículo, sin passwords)
3. Copiar la clave pública en el servidor:
   

   scp ~/.ssh/id_rsa.pub usuario@servidor.com:.ssh/authorized_keys2

   
   Puedes omitir la parte usuario@ si te conectas con el mismo usuario.

Y esto es todo amigos. En la siguiente conexión por SSH ya no se pedirá de nuevo el password.

Importante:

A partir de este momento, si alguien robara la clave pública que has guardado en ~/.ssh/id_rsa tendría acceso completo a tu servidor. Más vale que la protejas bien :)

Si dejas un password en la autenticación RSA puede ser una buena idea desactivar en el servidor el acceso SSH vía login/password y dejar sólo autenticación por clave.

Existe una utilidad llamada "tree" en Windows y Linux que sirve para ver un listado de directorio en un formato ASCII un poco más agradable a la vista. Si no quieres bajarte los MacPorts para esta pequeña utilidad lo más fácil es crear un script de una línea y enlazarlo en /bin para poder llamarlo directamente.

El comando en cuestión es este:

find . -print | sed -e 's;[^/]*/;|--;g;s;--|; |;g'

Ahora, para utilizarlo a troche y moche basta con pegar su contenido en un fichero en cualquier ubicación. Por ejemplo, en mi carpeta de usuario de scripts (/Users/alombarte/scripts/tree.sh):

#!/bin/bash
find . -print | sed -e 's;[^/]*/;|--;g;s;--|; |;g'

Y entonces, para poder escribir allí donde queramos el comando tree hacemos un enlace simbólico:

sudo ln -s /Users/alombarte/scripts/tree.sh /bin/tree

Un ejemplo de la salida es este:

|--a1
| |--a11
| | |--fichero_en_a11.txt
| |--fichero_en_a1.txt
|--a2
| |--a21

Así de simple :)

I do store a lot of statistical data in Redis, storing information on what users do and behave every day, week, month and so on... But storing a huge amount of data in memory has a little drawback: memory is cheap and fast, but is finite.

From time to time (e.g: cron job) I need to clean up the house because there is too much memory filled that is no longer interesting to keep it. Maybe you are thinking now, why this guy is not setting an EXPIRATION date? Well, I do.

Problem is that with early versions of Redis after the expiration time a KEY won't be really deleted from memory until the next access to the key, which never might happen. There is also a random process that deletes keys and there was a change of behaviour regarding expiration in Redis 2.2,  read more on expiration here.

In my case, I do store keys using human-readable dates as part of the key name, which I need to delete by pattern. To make it more graphical with a similar example, imagine you are storing user behavior in keys named like:

ub:2011-08-18:id-tracked-page...

Decomposing the elements:

• ub: user-behavior alias
• 2011-08-18: Stores all the events for August 18th
• id-tracked-page: Name or code of the page I want to track (e.g: home)
• ... more constraints could be added

Then, I am not interested in last month's data (July) regarding user behaviour so I can trigger in the terminal the following command:

redis-cli -n 0 KEYS ub:2011-07-* | xargs redis-cli -n 0 DEL

This deletes all the redis keys based on this pattern.

The output would produce something like:

$ redis-cli -n 0 KEYS ub:2011-07-* | xargs redis-cli -n 0 DEL
(integer) 188
(integer) 175
(integer) 191
(integer) 186
(integer) 153

You should notice that there is a -n 0 in the command indicating to trigger the command in the DATABASE 0. Since I do have many databases in a single server (multiple database support will be removed soon) I do always specify it. If you use a single database, just drop the "-n 0".

Also, you might need to surround by quotes the pattern part if contains spaces or other unfriendly chars.

Hope this helps