Git Cheatsheet

Este post es un poco agridulce. Mi intención era hacer varios posts con tutoriales sobre como usar GIT. La verdad es que he tenido muy poco tiempo.

Así que como no he podido cumplir con mi promesa de hacer los tutoriales por lo menos tengo esto. Encontré un post que resume mas o menos el uso regular de git. La verdad que estos son los comandos que uso diariamente.

Simple daily git workflow
Cheatsheet Download

Published
Categorized as Default

Como Programar Facebook Apps LOCALMENTE

Lo mas que odiaba de programar aplicaciones de Facebook era que tenia que “setiar” un repositorio en un server con unos “hooks” para que cada vez que hiciera commit desde mi laptop, los cambios se reflejaran en el servidor. La verdad es que esto funciona pero después de una sesión de unas cuantas horas se vuelve agotador. Mas aun cuando solo estas probando cambios simples.

Durante FOWA Miami 2010, en el workshop de Facebook me hablaron de una forma de hacer un ssh tunnel con un servidor. Basicamente la idea es que desde tu laptop o ambiente de programación te conectas via ssh a un servidor publico y re-diriges un puerto remoto a un puerto local en tu maquina. Después de un poco de “trial and error” logré ponerlo a funcionar y es bastante sencillo.

  1. Debes conectarte al servidor que vas a usar de intermediario (example.com) y editar el archivo que se llama /etc/sshd_config. Busca la linea que dice #GatewayPorts no y remueve el # y cambia a yes. Debe quedar GatewayPorts yes. Ahora restart el servicio de ssh, service sshd restart.
  2. En tu maquina local entra el siguiente comando ssh -gNR 8080:localhost:8888 [email protected]. Este comando lo que hace es crear un “reverse ssh tunnel”. En otras palabras nos conectamos al server example.com usando el usuario user y le decimos que todos los requests que lleguen al puerto 8080 los enviemos al puerto 8888 de la maquina que inicia la conexión, en este caso nuestra maquina local.

Listo eso es todo ahora todos los requests que lleguen a example.com:8080 van a llegar a nuestra computadora local. Una vez acabemos con el development presionamos ctrl+c y se acabó el tunel.

Recursos

http://bit.ly/auqVoK
http://bit.ly/9dmC5y

Published
Categorized as Default

Python N00b

Hace mas de dos años he estado interesado en aprender Python. Este lenguaje se caracteriza por ser fácil de escribir y sobre todo fácil de leer. Tiene la capacidad de mezclar poder con friendliness.

Hace poco menos de un mes decidí que ya era tiempo de añadir esta herramienta a mi arsenal así que me compré unos cuantos libros y desde entonces he estado sumergido en el mundo de Python. He aprendido sobre Guido van Rossum, Jython, Pyjamas, IronPython, PyPy, unladen-swallow, Python 3000, Beautiful Soup, Tornado y muchas otras personas, tecnologías y herramientas que nunca hubiera conocido en otras circunstancias.

De esta experiencia aprendí mucho. Primero que saber programar no tiene nada que ver con lenguajes de programación. Saber programar es una destreza completamente separada del lenguaje que se conozca y que la noción de que se es mejor programador con un lenguaje que con otro es una falacia. La realidad es que se es mejor programador con mas práctica y el ejercicio de aprender un nuevo lenguaje es un gran ejercicio. Como resultado cuando se aprende un nuevo lenguaje se es mejor programador.

En mi caso personal Python me enseño a tratar de ser mas económico en la cantidad de código que uso, a ser mas conciso. Ahora cuando escribo JavaScript o PHP en el día a día uso las cosas nuevas que he aprendido al estar expuesto a Python.

Finalmente quiero decir que Python me parece una herramienta súper poderosa. Es un lenguaje muy utilizado y con una comunidad vibrante de desarrollares produciendo todo tipo de packages. En las pocas semanas que llevo aprendiendo y practicando me he dado cuenta que hay un package para casi cada cosa que se me ocurre. Además he descubierto un proyecto que se llama PyObjC que es un puente entre Python y Objective-C / Cocoa, lo que permite escribir aplicaciones nativas para Mac OS X usando solo Python. Un ejemplo de una aplicación escrita de esta manera es Checkout, un sistema de POS. Pienso que mi primer proyecto será una aplicación para mac escrita en Python.

Mas adelante hablaré un poco sobre los libros que compré cuales son buenos y cuales malos.

Quiero saber tu experiencia aprendiendo nuevos lenguajes de programación, si sabes Python y que te gusta o no de este lenguaje. Deja un comentario abajo.

Published
Categorized as Default

Como usar screen en *nix

Screen es una herramienta del command line en sistemas *nix lo que incluye a Mac OS X. Esta herramienta permite crear pantallas virtuales de las que podemos conectarnos y desconectarnos sin interrumpir los procesos que estas realizan.

Referencia Rápida

Comando Descripción
> screen -S nombredesesion Crea una nueva sesión de screen
> screen -r nombredesesion Abre una session anterior
> screen -ls Muestra una lista de todas las sesiones abiertas
control + a d Cierra (detach) screen guardando la sesión activa
control + a c Crea una nueva ventana dentro de la sesión
control + a “ Muestra una lista de las ventanas de un screen
control + a A Permite cambiar los títulos de las ventanas
control + a ? Muestra todos los comandos disponibles
control + a | Divide la pantalla verticalmente
control + a S Divida la pantalla horizontalmente
control + a tab Cambia entre las divisiones
> exit Cierra la ventana activa dentro de screen

Cuantas veces has estado conectado vía SSH haciendo una operación complicada en un servidor y pierdes la conexión, “Connection Closed”. Si estuvieras usando screen en ese servidor podrías restablecer la conexión SSH y conectarte nuevamente a la pantalla que estabas usando con screen y seguir donde mismo te quedaste.

Para ser mas claro screen permite hacer una especie de tab el cual puedes cerrar y abrir cuantas veces quieras.
Aquí los pasos necesarios para manejar este caso simple. Abre tu terminal y corre screen.

> screen -S nombresesion

Screen te recibe con un mensaje de bienvenida. Esto se puede remover alterando las preferencias de screen, pero esto está fuera de lo que pretendo cubrir en este tutorial.

Ya tienes un screen creado. Aquí puede hacer cualquier operación que comunmente corres en tu terminal. Cuando quieres desconectarte sin cerrar la sesión debes presionar

control + a y luego la letra d

Esto te devolverá a la sesión principal de tu terminal y te dirá que el screen ha sido desconectado (detached).

Para ver que screens tienes corriendo entra

> screen -ls

Esto debe producir una lista de los screens que estan abiertos. Para reconectarte a un screen solo copia el nombre de la sesión.

> screen -r nombresesion

Listo ya estas de vuelta al screen que dejaste abierto. Para crear una nueva ventana dentro de la sesión:

control + a y luego c

Para ver una lista de las ventanas que tienes disponibles haces:

control + a y luego

Para cambiar rápidamente entre ventanas haces control + a y los números del 0 – 9.

Finalmente para control + a y luego ? para ver todos los comandos diponibles.

Para cerrar finalmente ese screen y terminar la sesión usa el acostumbrado

> exit

La aplicación screen puede hacer muchas cosas mas, esto es solo la superficie. Espero mas adelante poder tocar un poco mas en profundidad sobre este tema, pero en realidad esto es lo que uso con mas frecuencia.

Como siempre si ves algún error o sabes alguna forma de mejorar este tutorial no dudes en dejar tu comentario.

Git: Introducción (en Español)

Finalmente tengo un poco de tiempo para actualizar el blog. Estos últimos meses han estado llenos de cambios y cosas nuevas que mas adelante tocaré en un post dedicado a ese tema. Hoy quiero compartir un poco sobre sistemas de control de versiones y específicamente sobre Git. Este post servirá como una introducción a una serie de tutoriales (muy simples) sobre Git que estaré publicando en las próximas semanas.

Git es un sistema de control de versiones (SCM). Este tipo de sistema, como el nombre sugiere, permite llevar un control de revisiones de documentos dentro de un proyecto. Así cada vez que un archivo cambia este sistema se da cuenta de esos cambios y genera una nueva versión. Esto permite mantener un historial de todos los cambios que se han hecho y de ser necesario llevar a un archivo o todo el proyecto a un estado anterior (antes de introducir un bug) entre otros beneficios.

La verdad es que siempre he leído sobre SCM pero no fue hasta hace solo dos años que empecé a usar uno. Mi primera elección fue Subversion (SVN). En ese momento la decisión fue fácil. Había estado mirando unas cuantas descripciones de empleo de algunas compañías (solo por curiosidad) y en ese momento todas requerían conocimiento en SVN.

Bueno: SVN es un SCM muy poderoso y comúnmente usado. Hay mucha documentación y es bastante fácil de manejar en el día a día. Una vez queda configurado y funcionando no hay que tocarlo.

Malo: SVN es un sistema centralizado (lento), la configuración inicial puede ser un poco tediosa y guarda folders (.svn) en todos los directorios de tu proyecto. Esto ultimo me molesta por razones mas estéticas que otra cosa. Es muy fácil librarse de estos archivos con un simple svn export.

Para que uso un SCM
Mi trabajo se centra en aplicaciones web. Trabajo todo el tiempo con CodeIgniter y jQuery. Esas son mis dos herramientas principales. Regularmente trabajo solo en pequeños proyectos y en ocasiones trabajo en proyectos mucho mas grandes (s3mer) con varios developers. En mi experiencia he encontrado que tanto en proyectos individuales como en proyectos en equipo usar un sistema de SCM me ayuda mucho.

He tomado la costumbre de crear un repositorio para cada proyecto en el que trabajo. Cada vez que completo una tarea hago un commit y añado buenos comentarios para mas adelante poder identificar esa revisión. Esto me ha salvado la vida un par de veces cuando por ejemplo hago cambios en varios archivos y esto inserta un problema inesperado, simplemente vuelvo a una versión anterior y listo.

En proyectos con varios developers es muy obvia la necesidad de un SCM. Si tienes a varias personas alterando los mismos archivos constantemente es inevitable que en algún momento esos cambios van a  ser a un mismo archivo y un buen SCM ayuda a resolver esos problemas sin perder el tiempo de los developers.

Otra forma en que usar un SCM me ha ayudado es en el momento de deploy una aplicación al web. Lo que hago es que pongo en el servidor publico un working copy del proyecto así cada vez que hago un cambio en el proyecto es muy fácil actualizar la copia que está en el site publico. Esto ha sido especialmente importante al momento de trabajar aplicaciones para Facebook (FB) porque mi código (FBML Canvas Page) debe estar online para que los servidores de FB puedan llegar a ellos y presentarlos dentro de su site. Usando un SCM se puede configurar lo que se llaman hooks. Estos son acciones que se ejecutan en momentos específicos durante la operación de un SCM. Para desarrollos de FB casi siempre hago un post-commit hook esto es una acción que se ejecuta luego de un commit. En esta acción pongo un script que se conecta a mi servidor publico y actualiza la copia que está ahí. De esta manera cada vez que hago un cambio en el código solo tengo que hacer un commit en mi maquina y los cambios llegan automáticamente al site público.

¿Porque Git?
Cuando primero escuché de Git fue cuando me enteré que el proyecto Ruby on Rails lo estaba usando para manejar su código. Esto llamó rápidamente mi atención porque en ese momento estaba aprendiendo sobre Rails. Definitivamente el que proyectos como RoR, Linux Kernel, Perl, Gnome, Android, Fedora, Debian, Wine y otros estén usando este SCM tiene mucho que ver con mis deseos de probarlo. Pero la razón real detrás de porque me cambié de SVN a Git es la velocidad.

Ya no tengo que esperar por nada. Todo pasa muy rápido porque pasa en mi computadora sin necesidad de ir a un servidor hasta cuando yo le diga que tiene que hacerlo. Todos los cambios y todas las versiones están en mi maquina. En cualquier momento puedo hacer un checkout de otro branch sin necesidad de estar conectado al internet.

Otra razón es el tamaño de los repositorios. Por alguna razón Git es muy eficiente al momento de guardar las revisiones. Todos los proyectos que moví de SVN a Git ocupan menos espacio en mi disco duro.

Bueno: Descentralizado, rápido, fácil de usar, bueno para proyectos individuales, configuración muy sencilla.

Malo: La documentación que he encontrado no es muy buena.

Git me ayuda a principalmente a en mis proyectos individuales. Es muy fácil crear un repositorio nuevo, añadir archivos y empezar a trabajar. Cada cierto tiempo haces un commit nuevo y listo ya tus cambios están seguros.

Durante las próximas semanas estaré añadiendo unos posts sobre como usar Git. Espero en estos posts poder explicar mas claramente las ventajas de Git. Los posts serán tipo tutorial, para que puedan hacer un poco de copy/paste para empezar con sus proyectos.

Seguir a Tutorial 1 >>

Published
Categorized as Default

Como crear los “keys” para “ssh login” automático

Para los que bregamos con paginas web y desarrollo de aplicaciones basadas en tecnología web, el hacer ssh (remote login) a un servidor en el web es cosa de todos los días.Vía ssh tenemos control absoluto de esos servidores remotos y nos permite usar herramientas como SVN o Git para desplegar (deploy) nuestras aplicaciones o web sites.

El problema es que si uno esta conectando a varios servidores muchas veces al día y cada uno de estos tiene un password diferente, la cosa se vuelve complicada. Tengo una aplicación que me ayuda a recordar los passwords pero estoy cansado de copiar y pegar el mismo password 10 veces al día.

La solución a este problema es usar un ssh key. Cuando tienes un ssh key configurado no tienes que entrar el password cada vez que te conectas a un servidor que tiene tu “public key”. Para entender mejor un public key es como una cerradura en una puerta y el private key es la llave que lo abre. Puedes poner la misma cerradura a muchas puertas (servidores) y usar la misma llave para entrar a todas.

Para entender más fácilmente (suponiendo que sabes trabajar con ssh):

  • Tienes que crear un Public y un Private key
  • Debes guardar el private key como si tu vida dependiera de ello
  • Debes enviar el public key a todos los servidores o computadoras que te quires conectar

1. En tu computadora personal (Mac OS X / Linux) debes crear el Private y Public key. Esto es muy fácil, simplemente abre el terminal y entra:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Luego de entrado este comando te preguntará por un nombre para la pareja de “keys”. En este caso para dejar el nombre “default” solo presionamos enter en el tecalado. Esto produce tanto el Public (id_rsa) como el Private key (id_rsa.pub). Luego te preguntará por un “passphrase” para el que puedes poner lo que quieras, pero debes recordarlo. Los dos files (id_rsa y id_rsa.pub) se crearán en el directorio .ssh dentro del home folder.

2. Haz un backup de estos dos files. Son muy importantes y si alguien tiene acceso a ellos también tendrá acceso a todos los servidores o computadoras que usen esa pareja de llaves.

3. Ahora vamos a enviar el public key (id_rsa.pub) o la cerradura de la puerta al servidor donde queremos conectarnos. Para esto hay que usar scp que es un comando que funciona como cp (copy) pero permite hacer la copia a una computadora remota o de una computadora remota. Para usar scp necesitamos darle el nombre del file que queremos copiar (id_rsa.pub) luego el nombre de usuario nuestro en el servidor donde queremos enviar el file (usuario) luego (@), luego el domain del servidor, luego (:) y finalmente el directorio donde queremos guardar el file.

cd ~/.ssh
scp id_rsa.pub [email protected]:~/.ssh/

Una vez copiado el file al directorio ~/.ssh es necesario hacer login al servidor remoto via ssh para decirle que use este file cuando se este tratando de hacer un login desde nuestra computadora personal.

ssh [email protected]

Verifica que el directorio .ssh tiene permisos 700. Si no haces:

chmod 700 .ssh/
cd ~/.ssh

Ahora hay que crear un file para guardar los keys que este servidor acepta.

touch authorized_keys
chmod 600 authorized_keys

Ahora hay que poner nuestro Public key en este file.

cat id_rsa.pub >> authorized_keys

Listo ahora debemos volver a nuestra computadora personal. Si todo salió bien el servidor debería permitirte conectarte sin pedir ningún password mas allá del passphrase que usaste al principio para genera los keys. De este momento en adelante podrás conectarte al servidor remoto usando solamente:

ssh [email protected]

Espero que este pequeño tutorial ayude a alguien. Aquí les dejo el enlace al mejor articulo que encontré sobre el tema.

Published
Categorized as Default