Es así como hace algún tiempo llegue a Buildout; una solución aparentemente orientada a Plone, pero que es genérica y fácilmente utilizable con cualquier proyecto python (como Django, mi framework favorito).Para empezar, buildout es un sistema de “construccion” de software/paquetes/asdf que permite especificar las diferentes “partes” que componen un proyecto, como dependencias (python o no), mediante un archivo de configuración. A grandes rasgos busca permitir replicar un entorno en multiples maquinas, de forma automatica, de manera de no tener que estar instalando manualmente dependencias o haciendo malabares como agregar las aplicaciones externas al control de versiones o tener que compilar manualmente librerias, o peor, pedirle al puto señor sysadmin (sry sysadmins, no es su dia, asi que se me permite putearlos) que instale los paquetes.

¿Dije que Buildout genera un entorno aislado para instalar todas esas cosas?

Ahora mostraré como “envolver” un proyecto django para facilitar el depliege; es posible convertirlo en un egg, pero en este ejemplo no lo haré, simplemente porque nunca lo he hecho :]

Obtener Buildout

Aquí hay 2 formas, a mano o usando una herramienta (tambien python) llamada paster; la gracia de usar paster es que genera un template y ahorra mucho tiempo, así que lo haré de esa forma.

Paster esta en los repositorios de Ubuntu, pero es mucho mejor instalarlo usando pip (el gestor de paquetes python :O)

#si no tenemos pip instalado
easy_install pip
pip install paster
pip install fez.djangoskel

Con esto instalamos pip, paster y los templates para proyectos Django en distintas variedades

Ahora para asegurarnos que todo este correctamente instalado

$ paster create --list-templates
Available templates:
  basic_package:             A basic setuptools-enabled package
  django_app:                Template for a basic Django reusable application
  django_buildout:           A plain Django buildout
  django_namespace_app:      Template for a namespaced Django reusable application
  django_namespace_project:  Template for a namespaced Django project
  django_project:            Template for a Django project
  paste_deploy:              A web application deployed through paste.deploy

Crear y configurar el proyecto

El template que nos interesa es django_buildout

$ paster create -t django_buildout directorio

Nos pedirá que ingresemos la version de Django con la que se ha de correr el proyecto, es posible pasar “trunk” para usar la versión de desarrollo, pero dado que es muy inestable lo mejor es casarse desde un principio con una versión.

También nos solicitará un nombre de proyecto; por lo general lo dejo como viene por defecto.

Con esto creamos en “directorio” un esqueleto con una configuración estándar y un proyecto Django, el archivo “settings.py” del esqueleto es levemente distinto al que crea django con el clásico “startproject”, pero no debería influir demasiado.

Dentro del archivo ahora deberiamos tener los archivos:

• bootstrap.py
  • El ejecutable que creara el entorno “aislado” de Buildout.
• buildout.cfg
  • El archivo de configuración por defecto
• devel.cfg
  • Permite agregar modos de configuración extras para desarrollo, si usas aplicaciones como django-debug-toolbar, south, werkzeug junto a django-extensions para depurar, deberias agregarlo aquí como se mostrará después. No es necesario repetir lo que hay en “buildout.cfg” ya que este archivo lo extiende.
• README.txt
  • Un archivo vacío para poner notas sobre la instalación, vale la pena poner algo, para que otras personas puedan usar el proyecto

Luego lo que debemos hacer es modificar el archivo buildout.cfg lo que agregaré son cosas básicas para el funcionamiento sin problemas de django; el archivo debe quedar algo asi.

[buildout]
parts =
   zlib
   PIL
   django

eggs =
   PIL

[zlib]
recipe = hexagonit.recipe.cmmi
url = http://zlib.net/current/zlib.tar.gz
configure-options = --shared

[PIL]
recipe = zc.recipe.egg:custom
egg = PIL
find-links = http://dist.repoze.org
include-dirs = ${zlib:location}/include
library-dirs = ${zlib:location}/lib
rpath = ${zlib:location}/lib

[django]
recipe = djangorecipe
version = 1.2.1
project = project
wsgi=true
settings=production
eggs = ${buildout:eggs}

Vale la pena destacar que la url de zlib que coloque es para descargar siempre la ultima version de la libreria; se puede reemplazar con otra ruta donde estén los fuentes de la versión que necesites. Tambien puedes modificar la versión de django a instalar.

Entender las lineas recipe es fundamental para hacer que Buildout funcione, hexagonit.recipe.cmmi por ejemplo descarga lo que diga la linea url y hace un configure, make, make install (por eso CMMI) por lo que funciona con cualquier fuente; por otro lado zc.recipe.egg simplemente instala huevos python, pero con el sufijo :custom permite especificar la localización de las librerías necesarias para que PIL funcione, de otra manera va a buscar las del sistema que lo mas probable es que no estén (esa es la idea de usar Buildout ¿no?); para mas información es mejor ver la lista de estas y documentacion de cada una y de buildout.

Para agregar una dependencia, digamos por ejemplo que nuestro proyecto usa django-tables para mostrar la información. Entonces vemos si en PyPi (el repo de apps python) esta disponible:

$ pip search django-tables
django-tables             - Render QuerySets as tabular data in Django.

Si  es asi, solo la agregamos a eggs de la seccion buildout (eggs = PIL django-tables). Hay que tener cuidado si no depende de algo mas

En caso de que no esté, pero tiene un repositorio, se puede usar otra receta para obtenerlo y agregar en la seccion django, extra-paths = ${app:location} pero para eso es mejor ver la documentación, puede que a futuro haga un post sobre agregar dependencias desde controles de versiones, para no extender tanto este post.

Lo ultimo es ejecutar bootstrap.py (python bootstrap.py) que creara el entorno y sus carpetas.

En este momento puedes copiar el contenido de tu proyecto (si es que lo tienes) a la carpeta project que hay dentro del directorio, asi como agregar todo al sistema de control de versiones que uses, es conveniente solo agregar al control solo la carpeta de tu proyecto django, los .cfg que editamos y bootstrap.py; es decir, solo lo que había en el template que paster nos creó y tu proyecto;en git yo ocupo un archivo .gitignore como este:

*.pyc
*.pyo
*.swp
*.pyc
bin
develop-eggs
downloads
eggs
parts

De esta manera no agrego accidentalmente archivos que no quiero al repositorio.

Ejecutar buildout

Ahora que ya esta todo listo, lo unico que hay que hacer es ejecutar bin/buildout esto descargara e instalará las dependencias, si deseas usar la configuracion de desarrollo, simplemente usas un argumento

bin/buildout -c devel.cfg

Si modificas buildout.cfg solo necesitas volver a ejecutar bin/buildout

Bueno, eso es todo; cuando tu u otra persona necesite desarrollar o deplegar el proyecto, solo debera correr el bootstrap.py y luego bin/buildout y listo. Además buildout genera un archivo WSGI en bin/django.wsgi por defecto; asi que solo queda configurar el sitio en el servidor web usando ese archivo, que viene con las rutas de las distintas dependencias apuntando al entorno que buildout creó.

Algunas veces es necesario un entrono mas aislado, por lo que puedes usar virtualenv; pero a mi juicio es demasiada paranoia, ya que virtualenv modifica el PATH y entorpece desplegar las aplicaciones, y a cambio no ofrece mucho mas que lo que tenemos con Buildout.

Me quedan pendientes algunas cosas, como poder generar una configuracion de VirtualHost autmáticamente para apache que es bastante util y algunas notas puntuales sobre recetas, espero escribirlas mas adelante para que no se me olviden (razón por la que hago este post, ya que comenzé un proyecto nuevo y olvide muchos detalles xD).

Algunos links utiles (la mayoria mas completos que esta guia rapida):

• http://www.noenieto.com/blog/django-y-buildout
• http://jacobian.org/writing/django-apps-with-buildout/
• http://www.slideshare.net/zerok/django-buildout-en-presentation

Ok.. el tema es bien simple:

1. Antes que nada debes emparejar los audifonos con tu computador; la forma mas simple es usar la aplicación que provee Ubuntu (bluez), es el ícono de bluetooth en el área de notificación
2. Debes instalar algunos paquetes; mas que nada son para configurar pulseaudio (lo siento por aquellos que no lo ocupen, de todas formas es el servidor de audio por defecto en Intrepid), asi que abrimos una consola y ponemos
   sudo aptitude install pulseaudio-utils padevchooser paprefs pavucontrol
   esto instalará unas utilidades de consola para pulseaudio y otras para el entorno gráfico (son gtk+)
3. Para poder utilizar nuestro headset usaremos Alsa; es por esto que debemos obtener la dirección MAC de tus audífonos, para esto debes ponerlos en “modo de emparejamiento” (pairing mode) y en la querida cosola escribimos
   hcitool scan
   esto nos devolverá algo así
   
Scanning ...
00:1E:BA:36:82:15 DR-BT21G
00:1F:E2:E9:CE:F6 Sconfro
00:16:E8:ED:68:E0 K510i

   Esos numeros y letras extraños es la MAC; en mi caso la que importa es el primer resultado
4. Ahora debemos editar un archivo de texto; en la consola (asumiendo que esta en el home del usuario) ejecutamos
   gedit .asoundrc
   o el editor que prefieras, en el archivo debemos agregar el siguiente texto.
   
pcm.headset{
type bluetooth
device [Aqui la MAC del punto anterior, sin los corchetes]
profile "auto"
}

   con esto ALSA sabrá que tenemos una salida de audio bluetooth con esa MAC; donde dice headset puedes poner otro nombre, solo que no sea “bluetooth” u otro nombre reservado de alsa
   guarda y cierra el editor
5. Ahora volvemos a la consola; porque debemos contarle a pulseaudio que tenemos una nueva salida; para esto usamos una de las utilidades que instalamos en el punto 1
   
pactl load-module module-alsa-sink device=headset
pactl load-module module-alsa-source device=headset

   La primera linea le dice a pulseaudio que hay un dispositivo alsa que es una salida de audio (sink); mientras la segunda le dice que hay una entrada, pongo esto porque mis audifonos tienen micrófono, aunque no lo he probado.
   Desafortunadamente esto se debe hacer cada vez que queramos usar nuestros audífonos y hayamos reiniciado el sistema; puedes hacerlo un script y que se ejecute al inicio, si no encuentra el dispositivo simplemente fallará y tendrás que ejecutarlo manualmente. Debe haber alguna forma de que ejecute los comandos al emparejar el dispositivo con el PC, solo que aun no la he descubierto.
   Hasta aqui tenemos todo listo en cuanto a configuración

Hey! esto no funciona, quiero mi dinero de vuelta

Menu pavdevchooser

Aun falta algo que hacer… decir que mande el sonido a los audifonos; hay algunas variantes.. asi que primero hechamos a correr una útil aplicación: “PulseAudio device chooser” (padevchooser en una consola o en el menu Aplicaciones>Sonido y video de gnome); esta corre en el área de notificación. Si le hacemos click izquierdo nos mostrará un menu, por el momento nos interesa el “Manager…”.

En la pestaña devices podemos ver que hay una salida llamada alsa_output.headset (o como le hayas puesto a la salida en alsa); si en el menú de padevchooser vas a default sink>other y pones ese nombre.. bueno todo el audio saldrá por el headset!
Por otra parte si en el menú de padevchooser entramos a “volume control” y tenemos alguna aplicación reproduciendo audio podemos dirigir el stream de esa aplicación en particular a nuestro headset.. práctico ¿no?

Demasiado bueno ¿no?

Si bien funciona de maravilla para lo que yo ocupo hay algunos detalles que están sin resolver:

• Hay que ejecutar los comandos del punto 5 para poder comenzar a utilizar tu headset
• Hay que ingresar el sink manualmente cada reinicio (cuando tenga mas tiempo veré como hacerlo por consola para ponerlo en un script)
• No todas las aplicaciones usan PulseAudio; no he tenido tiempo de probar, pero en teoría algunos juegos no enviarian el audio a los audifonos
• Al apagar los audifonos sin volver el sink a default o con aplicaciones dirigiendo su salida de audio al headset, pulseaudio tiende a caer, otra vez seria trabajo para un script.
• Ya no puedo perder tiempo productivo desenredando el cable de 4 metros de mis antiguos audifonos

Desactivar el touchpad cuando conectas un mouse usb

Es bastante simple; hacemos una regla de udev: Creamos el archivo /etc/udev/rules.d/80-mouse-touchpad.rules, esta es la ruta de ubuntu, uso el número 80 porque segun el readme los 80 son los que ejecutan un programa, y eso es lo que vamos a hacer, puedes poner el nombre que quieras entre el 80 y .rules.
Al interior del archivo ponemos lo siguiente:
ACTION=="add", SUBSYSTEM=="input", ID_CLASS="mouse", RUN+="/usr/bin/synclient touchpadoff=1"
ACTION=="remove", SUBSYSTEM=="input", ID_CLASS="mouse", RUN+="/usr/bin/synclient touchpadoff=0"
y luego guardamos y ¡listo! Básicamente lo que hace es que cada vez que detecta que se conecte un mouse externo se desactive el touchpad y a la inversa cuando se desconecte, usando la utilidad “synclient”

Evitar mover/hacer click/arrastrar mientras escribes

Ok, aún no hemos solucionado el tema de cuando te ves obligado a usar el touchpad.. bueno, hay una pequeña utilidad (un pequeño demonio xD) que nos servirá bastante: syndaemon
Si pones en una consola “syndaemon –help” hay varias opciones con distintos resultados.. pondré solo dos.

syndaemon -i1 -d
Se ignora toda entrada del touchpad hasta que transcurra 1 segundo de presionada una tecla

syndaemon -i1 -t -d
Solo ingora el tapping (el click cuando golpeas suavemente el touchpad) y el scrolling (el de los bordes)

yo uso el primero; la idea es que este comando se ejecute siempre cuando enciendas el laptop; yo lo tengo en la sesion de gnome (Sistema>Preferencias>Sesiones)

Afortunadamente está en los repositorios oficiales; su nombre es compizconfig-settings-manager y se puede instalar con un simple

sudo aptitude install compizconfig-settings-manager

Ahora podremos configurar a gusto compiz fusion con cubos, acuarios, nieve y todo los que se te ocurra.
Durante el beta hubo una aplicación que se llamaba simpe-ccsm que era una version “light” de esta aplicacion, creo que la eliminaron, lo que es bueno ya que era demasiado “light” y no ofrecia muchas opciones lo pongo aqui como anecdota.

Pero el proposito de este post es mas que nada dejar una imagen que hace tiempo encontre en planet gnome

Basicamente es modificar algunas entradas en gconf para enchular el reloj de gnome; hace tiempo andaba buscando algo asi, pero lo que aun no pruebo es poner colores, aunque usando los valores del screenshot se ve bastante mejor que como viene por defecto.

Vean todas las respuestas a ese video; hay hasta una version de 8 bits.

Bonus Track:

Update al parecer la cancion es algún tipo de denuncia contra el trato a los negros (despues de leer la letra), aunque sigue sinedo bastante sin sentido.. lo que si es que el video lleva ya almenos 5 dias y ahora explotó de manera viral

almenos no soy el unico que lo encuentra sin sentido: