En ocasiones nos toca respaldar gran cantidad de información de un equipo a otro y una de las maneras más cómodas de hacerlo es a través de la red. Para esta tarea usaremos Rsync que, al igual que netcat, son unas navajas suizas en lo que a red se refiere. Rsync, entre otras cosas, nos permite sincronizar directorios a través de la red y de esa forma lo usaremos para enviar nuestros archivos de un equipo a otro.

Comando y parámetros

Lo primero que necesitamos es acceso vía SSH al equipo remoto. Puede ser por clave pública o con usuario y contraseña. Luego nos ubicamos en la carpeta que queremos respaldar y ejecutamos el comando: $ rsync -ravz archivo_a_respaldar usuario@IP:directorio_destino Donde:
  • r: recorre los directorios de manera recursiva
  • a: conserva los atributos de los archivos (usuario, permisos, etc)
  • v: imprime información en pantalla
  • z: comprime los datos antes de enviar
Luego de la autenticación comenzará la copia de los archivos. Es importante resaltar que en el directorio_destino debemos colocar la ruta absoluta a la carpeta.

Copiar un archivo

Supongamos que queremos respaldar el archivo backup.tar.gz en un equipo remoto con IP 192.168.0.3, el usuario es satanas y el directorio destino es el home del usuario, el comando nos quedaría así:
$ rsync -avz backup.tar.gz satanas@192.168.0.3:~
El símbolo ~ puede sustituirse por la ruta absoluta /home/satanas.

Copiar un directorio y todos sus subdirectorios

Ahora supongamos que queremos respaldar el directorio /tmp/music en el mismo equipo anterior pero ahora el destino es la carpeta /home/satanas/musica, el comando nos quedaría así: $ rsync -ravz /tmp/music satanas@192.168.0.3:/home/satanas/musica

Con esta receta podremos pasar nuestro respaldo de archivos de un equipo a otro sin mucho inconveniente. Espero que les sirva

Leer más

Singleton es un patrón de diseño cuya función es evitar que un objeto pueda ser instanciado más de una vez. En este post traigo una receta simple para implementar el patrón singleton en Python.

En esta implementación utilizaremos un archivo de bloqueo (lock file) para indicar si la aplicación está en ejecución o no. Python cuenta con el módulo fcntl que nos proporciona una interfaz bastante cómoda para el control de archivos pero está disponible solo para Linux/Unix, eso implica que debemos usar medidas alternativas para Windows.

Detectar SO e importar módulos

Lo primero que debemos hacer es detectar el sistema operativo y ejecutar los import correspondientes para cada caso. Usaremos además el módulo tempfile para generar el lock file como un archivo temporal del sistema.
#!/usr/bin/python2
# -*- coding: utf-8 -*-

import os
import sys
import tempfile

OS = None
if sys.platform.startswith('linux'):
OS = 'linux'
import fcntl
elif sys.platform.startswith('win32'):
OS = 'windows'


Definir la clase Singleton

Después de detectar el sistema operativo definimos la clase Singleton. Básicamente, esta clase será la encargada de crear el lock file al inicio o generar una advertencia y termina la ejecución en caso de que el archivo ya exista (es decir, que ya existe una instancia de la aplicación en ejecución).
class Singleton:
def __init__(self):
# Variable para almacenar el file descriptor
self.fd = None
# Ruta para el lock file en la carpeta temporal del sistema
self.filepath = os.path.abspath(os.path.join(tempfile.gettempdir(),
'myapp.pid'))

if OS == 'linux':
# Para el caso de linux usamos el módulo fcntl para crear el archivo
# y bloquearlo automáticamente. Si la operación falla es porque el
# archivo ya existe y está bloqueado.
self.fd = open(self.filepath, 'w')
try:
fcntl.lockf(self.fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
except IOError:
self.__exit()
elif OS == 'windows':
try:
# Para el caso windows simplemente creamos el archivo "a mano",
# pero verificamos primero si el archivo existe e intentamos
# removerlo (para casos en que la ejecución previa haya sido
# interrumpida)
if os.path.exists(self.filepath):
os.unlink(self.filepath)
self.fd = os.open(self.filepath, os.O_CREAT|os.O_EXCL|os.O_RDWR)
except OSError, err:
if err.errno == 13:
self.__exit()

def __del__(self):
# Para el caso de windows también debemos destruir el archivo "a mano"
# al finalizar la ejecución del programa.
if OS == 'windows':
if self.fd:
os.close(self.fd)
os.unlink(self.filepath)

def __exit(self):
print 'Ya hay una instancia en ejecución. Saliendo'
sys.exit(-1)
En el __init__ se observa que creamos una variable para almacenar el file descriptor (fd), luego generamos una ruta para el lock file. Posteriormente creamos un lock file con el módulo fcntl (en el caso linux) o creamos un archivo regular (para el caso windows). Adicionalmente, en el caso windows necesitamos hacernos cargo del archivo al finalizar la ejecución, para eso sobreescribimos el método __del__ y colocamos nuestro código. Adicionalmente tenemos la función __exit(), que es la encargada de detener la ejecución del programa de forma elegante.

Clase de pruebas

Con los pasos anteriores tenemos lista nuestra implementación simple del patrón singleton. Ahora, ¿Cómo la usamos? Creamos una clase (por ejemplo MyApp) que herede de singleton y ponemos un bucle infinito para que se mantenga haciendo "algo".
class MyApp(Singleton):
def __init__(self):
Singleton.__init__(self)
print 'Ejecutando MyApp'
# Creamos un bucle infinito solo para mantener la aplicación en
# ejecución
while 1:
continue


¿Cómo se vería nuestro script?

El código completo de nuestro script se vería así:
#!/usr/bin/python2
# -*- coding: utf-8 -*-

import os
import sys
import tempfile

OS = None
if sys.platform.startswith('linux'):
OS = 'linux'
import fcntl
elif sys.platform.startswith('win32'):
OS = 'windows'

class Singleton:
def __init__(self):
# Variable para almacenar el file descriptor
self.fd = None
# Ruta para el lock file en la carpeta temporal del sistema
self.filepath = os.path.abspath(os.path.join(tempfile.gettempdir(),
'myapp.pid'))

if OS == 'linux':
# Para el caso de linux usamos el módulo fcntl para crear el archivo
# y bloquearlo automáticamente. Si la operación falla es porque el
# archivo ya existe y está bloqueado.
self.fd = open(self.filepath, 'w')
try:
fcntl.lockf(self.fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
except IOError:
self.__exit()
elif OS == 'windows':
try:
# Para el caso windows simplemente creamos el archivo "a mano",
# pero verificamos primero si el archivo existe e intentamos
# removerlo (para casos en que la ejecución previa haya sido
# interrumpida)
if os.path.exists(self.filepath):
os.unlink(self.filepath)
self.fd = os.open(self.filepath, os.O_CREAT|os.O_EXCL|os.O_RDWR)
except OSError, err:
if err.errno == 13:
self.__exit()

def __del__(self):
# Para el caso de windows también debemos destruir el archivo "a mano"
# al finalizar la ejecución del programa.
if OS == 'windows':
if self.fd:
os.close(self.fd)
os.unlink(self.filepath)

def __exit(self):
print 'Ya hay una instancia en ejecución. Saliendo'
sys.exit(-1)

class MyApp(Singleton):
def __init__(self):
Singleton.__init__(self)
print 'Ejecutando MyApp'
# Creamos un bucle infinito solo para mantener la aplicación en
# ejecución
while 1:
continue

if __name__ == '__main__':
app = MyApp()


Probando el singleton

Para probarlo abrimos un terminal, nos colocamos en la carpeta donde esté ubicado nuestro script y lo ejecutamos por primera vez. Eso nos dará como resultado algo como:
$ python myapp.py 
Ejecutando MyApp


Abrimos una terminal nueva (sin cerrar la terminal anterior) e intentamos ejecutar la aplicación por segunda vez. Eso nos devolverá:
$ python myapp.py 
Ya hay una instancia en ejecución. Saliendo
¡Y voilá! Logramos que un script de Python pueda ser ejecutado una sola vez.

Hay implementaciones más complejas que almacenan el ID del proceso dentro del lock file y cada vez que se intenta ejecutar una nueva instancia se lee el ID y se verifica que realmente exista un proceso en ejecución con ese identificador. Pero como dije al principio, esta es una receta simple, así que as implementaciones más complejas las dejamos como tareas para el lector ;)

Leer más

En la entrega anterior expliqué como instalar el ambiente de desarrollo para trabajar con Android. Ahora explicaré algunos fundamentos necesarios para poder entrar en calor.

Podemos decir que Android está compuesto por varias capas (muy al estilo del modelo OSI).

Esas capas las podemos diferenciar en 5 grupos:

  • Capa 1 - Kernel: La base de Android es sólida como una roca. Claro, esa base es el kernel Linux. Android usa Linux para manejar todo lo relacionado con el hardware (drivers), gestionar la memoria, los procesos y muchas otras tareas operativas. Sin embargo nuestra aplicación nunca tocará el kernel.
  • Capa 2 - Librerías nativas: La siguiente capa que se ubica por encima del kernel son las librerías nativas. Allí tenemos una serie de herramientas que vienen precompiladas por el fabricante y que nos permiten manejar desde renderizado web hasta bases de datos.
  • Capa 3 - Núcleo: Sobre ésta capa tenemos el núcleo de Android. Allí reside la máquina virtual Dalvik y las librerías de la plataforma.
  • Capa 4 - Framework para aplicaciones: Más arriba está el conjunto de herramientas que nos permite crear y manejar las aplicaciones, notificaciones, recursos y muchas otras cosas.
  • Capa 5 - Aplicaciones: Y por último tenemos la capa de aplicaciones, aquí es donde se encuentran los widgets y todas las aplicaciones que tienen contacto con el usuario.

Ya conocemos un poco mejor la arquitectura de Android, ahora veamos con qué contamos para desarrollar. Parte del framework para aplicaciones son los componentes. Estuadiaremos los más importantes por el momento, ellos son:

  • Activities: Los activities (o actividades) son las interfaces que permiten al usuario interactuar con la aplicación. Generalmente una aplicación está compuesta de muchas actividades. Una actividad puede ser mostrar la lista de contactos y otra puede ser enviar mensajes de texto
  • Intents: Un intent (o como se diría en español, una "intención") no es más que una acción. En Android todas las acciones se manejan con intenciones ;)
  • Services: Es una tarea que se ejecuta en segundo plano, sin interfaz gráfica y sin interacción directa con el usuario. Podemos pensar en el ejemplo típico: un reproductor de música. A todos nos gusta que la música siga sonando incluso si dejamos de ver el reprouctor para pasarnos al navegador web. Eso es un servicio
  • Content Providers: Es un contenedor que permite agrupar un conjunto de datos de una aplicación y ponerlos a disposición de otras aplicaciones. Podemos verlo como una manera de compartir información global entre aplicaciones

Por último vamos a mencionar las fases del ciclo de vida de una aplicación.

Lo primero que debemos entender es que (a diferencia de un sistema operativo de escritorio) en Android una aplicación no está casada con un proceso. En Android existe una sola aplicación que obtiene el foco y se presenta frente al usuario. Mientras ésta aplicación se encuentra en el frente, las demás aplicaciones entran en estados de pausa, detención o incluso, si la memoria es escasa, Android puede llegar a cerrarlas para liberar recursos y sin estar mediando muchas palabras.

Pero no se asusten, si la aplicación es "asesinada" por Android su estado se almacena para que pueda recuperarse cuando el usuario la ejecute nuevamente. Es en este ínterin de cerrar y abrir aplicaciones en que se liberan los procesos. Debemos ver a un proceso como un simple contenedor desechable para las aplicaciones, no más. Siempre ten presente éste comportamiento al momento de diseñar tus aplicaciones.

El ciclo de vida de una aplicación lo podemos ver en la siguiente imagen.


A continuación describo brevemente cada una de sus fases:

  • onCreate(): Se ejecuta la primera vez que la aplicación se muestra. Aquí se pueden realizar toda la inicialización estática (conexiones a bases de datos, creación de interfaces, etc). Recibe un parámetro que puede contener el estado anterior de la aplicación (si fue almacenado correctamente)
  • onStart(): Se ejecuta justo antes de que la aplicación se haga visible al usuario
  • onRestart(): Llamado justo después que la aplicación ha sido detenida. Justo antes de comenzar de nuevo
  • onResume(): Se llamará cuando la aplicación esté lista para interactuar con el usuario. Acá se pueden inicializar cosas como música y animaciones
  • onPause(): Se ejecuta justo antes de que la aplicación pase a segundo plano porque otra aplicación ha sido ejecutada. Este método puede ser lo último que vea tu aplicación antes de morir, pues Android puede matar una aplicación pausado sin previo aviso. Es por eso que este es un buen lugar para guardar el estado de tu aplicación.
  • onStop(): Es llamado cuando la aplicación ya no es visible al usuario y no se necesitará por un rato. Tal como se indicó en el punto anterior, este método es posible que ni siquiera se ejecute
  • onDestroy(): Se llama justo después que la aplicación es destruida. Acá debes hacer el sepelio y esas cosas. Tal como se indicó en el punto anterior, este método es posible que ni siquiera se ejecute

Con toda ésta base teórica podemos decir que estamos listos para empezar a escribir el código de nuestra primera aplicación. Ese será el tema de la próxima entrega.

Para más información sobre éste tema puedes consultar la documentación oficial de Android

¿Cómo desarrollar para Android? - Parte I

Leer más



Actualmente me he visto en la necesidad de crear aplicaciones para Android y como no había incursionado en ese mundo, he decidido hacer una serie de artículos para documentar todo el proceso.

En ésta primera entrega explicaré los pasos que seguí para poner a punto el entorno de desarrollo. Debo resaltar que las recetas están hechas para Debian GNU/Linux, sin embargo puedes adaptarla a tu distro favorita con unos leves ajustes.

Para los que no están familiarizados con mis tutoriales les recuerdo que todas las instrucciones que comiencen con el caracter $ se ejecutan como usuario normal y las que comiencen con # se ejecutan como superusuario (root), por ejemplo:

$ ls -l (instrucción ejecutada como usuario)
# aptitude update (instrucción ejecutada como root)


Dicho esto comenzamos.

Instalar dependencias


Lo primero que debemos hacer es instalar los paquetes necesarios para el desarrollo, que básicamente son: la máquina virtual de Java (JRE) y el entorno de desarrollo (JDK). En una distribución Debian GNU/Linux bastaría con:

# aptitude update
# aptitude install sun-java6-jdk sun-java6-jre
# aptitude remove gcj-jdk


Si se dan cuenta usamos las implementaciones de SUN y removimos cualquier posible instalación del compilador GNU de Java (gcj) pues en la documentación oficial nos dicen que gcj NO es compatible con Android.

Para más información sobre los requerimientos del sistema visita: http://developer.android.com/sdk/requirements.html

Luego que instalamos los paquetes nos aseguramos de que el sistema seleccione las opciones correctas por defecto de cada ejecutable, pare eso usamos:

# update-alternatives --config javac
# update-alternatives --config java


Y en ambos casos, seleccionamos las opciones de SUN.

Instalar Ant


Ant es una herramienta que nos permite construir aplicaciones Java. En nuestro caso, nos permitirá compilar y construir archivos .apk (los instalables en Android) a partir de nuestro código fuente.

Nos vamos a la página de descargas de Ant, descargamos uno de los archivos comprimidos que se encuentran en la sección "Current Release of Ant" y lo descomprimimos en una carpeta de nuestra preferencia. En mi caso lo hice en /opt y me quedó la carpeta: /opt/apache-ant-1.8.1.

Instalar el Android SDK


Bueno, teniendo las herramientas y dependencias listas, vamos a instalar el entorno de desarrollo de Android. Nos vamos a la página del SDK de Android y descargamos la versión que corresponda a nuestra plataforma. Al igual que con Ant, descomprimimos el archivo en la carpeta de nuestra preferencia. Ésta vez también lo descomprimí en /opt, quedando en la carpeta: /opt/android-sdk-linux_x86.

Ahora editamos el archivo ~/.bashrc para agregar la ruta de los binarios al PATH del sistema y establecer las variables de entorno ANT_HOME y JAVA_HOME. Eso lo logramos agregando las siguientes líneas:

export PATH=${PATH}:/opt/android-sdk-linux_x86/tools
export PATH=${PATH}:/opt/apache-ant-1.8.1/bin
export ANT_HOME=/opt/apache-ant-1.8.1
export JAVA_HOME=/usr/lib/jvm/java-6-sun/jre


Recuerda cambiar las rutas de esas variables por las rutas donde se encuentran tus binarios. Si no sabes muy bien hacía dónde debe apuntar JAVA_HOME puedes ejecutar el comando:

# find / -name "tools.jar" | grep sun

Y entonces agrega la ruta que te arroje.

Nota: Debes cerrar las terminales abiertas y volverlas a abrir para que los cambios en las rutas surtan efecto.

Instalar plataformas de Android


¿Plataformas? ¿De qué me hablas? - Seguramente te estarás haciendo esas preguntas. Las plataformas son las "versiones" de Android disponibles (por ejemplo Android 1.6, Android 2.2) y necesitamos al menos una para poder compilar la aplicación y configurar un Android Virtual Device (AVD) para probarla.

Esto es muy simple, basta con abrir una terminal y ejecutar:

$ android

Nos aparecerá una aplicación (AVD Manager) como la que se muestra a continuación y allí nos vamos a la sección Available Packages, actualizamos el repositorio y seleccionamos la(s) plataforma(s) que deseamos instalar.


Finalmente creamos un nuevo dispositivo virtual en la sección Virtual Device. Hacemos clic en el botón New..., le asignamos un nombre, seleccionamos una plataforma y hacemos clic en Create AVD.


Para probar nuestro flamante dispositivo lo seleccionamos y hacemos clic en Start.... Luego clic en Launch y al cabo de unos segundos tendremos el emulador corriendo una instancia de Android :)


Desarrollo


Ahora viene la parte divertida, crear la aplicación. En las próximas entregas estaré hablando sobre el desarrollo, por los momentos pueden jugar creando un Hello World y pueden leer sobre cómo desarrollar con Eclipse y cómo desarrollar con otros IDEs

Compilar y construir el ejecutable


Luego de que tengamos nuestra aplicación lista debemos crear el instalador. Eso es tan simple como navegar hasta la carpeta raíz del proyecto (código fuente) y ejecutar:

$ ant debug

Si nuestro proyecto se llama "HelloAndroid" esto generará un archivo HelloAndroid-debug.apk y ese será nuestro instalador.

Probar en el emulador


Finalmente, una de las partes más esperadas. ¿Cómo se verá nuestra aplicación en un dispositivo? Pues fácil, en una consola ejecutamos:

$ android

E iniciamos nuestro dispositivo virtual. Luego que el dispositivo esté funcionando ejecutamos en otra consola:

$ adb install /ruta/de/nuestro/instalador/HelloAndroid-debug.apk

Y con eso enviaremos la aplicación al dispositivo. La buscamos en el menú y voilá! A jugar :D

Espero que les haya sido de utilidad éste tutorial. Próximamente seguiré documentando mis travesías en el mundo de Android. Cambio y fuera.

Leer más

Lo primero que debo aclarar antes de empezar éste post es que la forma de reproducir música con éstas herramientas es completamente diferente a la tradicional. Si no te interesa reproducir música como un verdadero geek entonces huye y busca otras aplicaciones, éstas no son para tí.

Si eres valiente, continuemos entonces. MPD es un demonio (o sea un servicio) para reproducir música, corre en segundo plano y no tiene interfaz gráfica. De hecho se inicia como cualquier otro servicio de tu equipo (red, hal, udev, etc).

¿Cómo demonios hago para interactuar con él? te preguntarás. Sencillo, está basado en una arquitectura cliente-servidor así que existen aplicaciones que se comunican con él (clientes) y que te permiten manejarlo. Ahí es donde entra Sonata y compañía.

Lo primero que debemos hacer es instalar las dependencias:

# aptitude install mpd mpc sonata

Yo instalaré 2 clientes, Sonata y MPC, porque quiero controlar la reproducción vía SSH desde mi celular xD (sí, sí, muy geek... pero me gusta la comodidad)

Luego vamos a nuestro directorio personal, creamos la carpeta .mpd y dentro de ésta creamos dos carpetas más, playlists y music

$ cd ~
$ mkdir -p .mpd/playlists
$ mkdir -p .mpd/music


Dentro de la carpeta .mpd creamos los archivos mpd.db, mpd.log y mpd.error

$ touch .mpd/mpd.db
$ touch .mpd/mpd.log
$ touch .mpd/mpd.error


Ahora, por cada carpeta de música que tengamos en nuestro sistema creamos un enlace simbólico dentro de music:

$ ln -s /ruta/de_la/carpeta1 .mpd/music
$ ln -s /ruta/de_la/carpeta2 .mpd/music
...


Luego (como root) editamos el archivo de configuración del MPD en /etc/mpd.conf y modificamos las siguientes opciones:

music_directory     /home/tu_usuario/.mpd/music
playlist_directory /home/tu_usuario/.mpd/playlists
db_file /home/tu_usuario/.mpd/mpd.db
log_file /home/tu_usuario/.mpd/mpd.log
error_file /home/tu_usuario/.mpd/mpd.error


Comentamos la línea de usuario para evitar problemas con los permisos:

#user             "mpd"


Y buscamos el apartado de audio y lo configuramos para ALSA o para PulseAudio:

ALSA:
audio_output {
type "alsa"
name "My ALSA Device"
}


PulseAudio:
audio_output {
type "pulse"
name "My PulseAudio Device"
}


Establecemos un mezclador por software descomentando la siguiente línea:

mixer_type "software"

Y voilá! Luego reiniciamos el servicio y creamos la base de datos de tags:

# /etc/init.d/mpd restart --create-db

Ahora desde Sonata (o desde mpc) agregamos las canciones que queramos a la lista y empezamos a disfrutar. Es tan genial ésta combinación que podemos cerrar el Sonata e incluso hasta la sesión gráfica y la música seguirá sonando.

Nos quedará algo tan mínimo como esto:


O en su versión extendida:


Y con unas agradables notificaciones:


Díganme... ¿No es una maravilla? Bueno de aquí en adelante los dejo para que experimenten y se enamoren.

Leer más