septiembre 26, 2011 at 9:51 am | Blog, Django, Sass, virtualenv | No comment
Guía breve para instalar y configurar Django + Compass bajo un entorno virtual en Archlinux.
En primer lugar me parece una herramienta indisplensable VirtualEnv y la utilidad virtualenvwrapper, que nos permitirá tener nuestros entornos de desarrollo separados para cada proyecto. Por lo tanto lo primero es instalarlo:
sudo pacman -Sy python-virtualenvwrapper
Una vez descargado e instalado, vamos a configurar el entorno creando la carpeta ~/.envs y añadiendo a nuestro ~/.bashrc las líneas
export WORKON_HOME=~/.envs
source /usr/bin/virtualenvwrapper.sh
Refresca la terminal (source ~/.bashrc) y ya podemos empezar a utilizar nuestros entornos separados. Fácil ¿no?
Vamos a crear un primer entorno:
mkvirtualenv -p /usr/bin/python2.7 --no-site-packages nombre
El parámetro -p nos permitirá indicarle qué versión de Python debe usarse, útil si tienes versiones más antiguas en servidores en producción que no puedes actualizar y debes instalar el entorno de desarrollo con las mismas características. El otro parámetro –no-site-packages indica al entorno que no utilice el directorio site-packages general del sistema operativo. Con eso tendremos entornos limpios y verdaderamente independientes. Por último se le indica el nombre del entorno.
Hecho eso nos movemos a nuestro entorno simplemente con:
workon nombre
Ya está. Si te fijas, el prompt habrá cambiado a algo parecido a (nombre)usuario@maquina ~ $, el (nombre) denota que estamos dentro del entorno virtual. Vamos a empezar a instalar programas:
pip install django hg+https://bitbucket.org/slafs/django-compass
Añadimos django-compass a nuestras INSTALLED_APPS y para utilizar compass y poder generar nuestro css a partir de SASS vamos a instalar ruby
sudo pacman -S ruby
Y configurarlo para que instale las gemas en el directorio de nuestro entorno virtual, añadiendo al archivo ~/.envs/postactivate las líneas:
export GEM_HOME=$VIRTUAL_ENV/gems
export GEM_PATH=""
A continuación, salimos y volvemos a entrar al entorno para que tenga en cuenta los últimos cambios: esto se hace con los comandos “deactivate” y “workon nombre” de nuevo. Y ya podemos instalar las gemas compass y compass-less-plugins (que me parece un maravilloso framework para poder obtener diseños “responsivos”)
gem install compass compass-less-plugin
Hay un problemilla con compass-less-plugin y es que creo que no se registra correctamente, así que vamos a ~/.envs/nombre/gems/compass-(version)/frameworks y creamos la carpeta less, dentro de ella pegamos las carpetas stylesheets y templates de ~/.envs/nombre/gems/compass-less-plugin-(version).
Y ahora tenemos que configurar compass para que trabaje en las carpetas que queramos:
~/.envs/nombre/gems/bin/compass create -r less estilos --using less
mv estilos/sass sass
mv estilos/config.rb config.rb
rm -rf estilos
Abre config.rb y adáptalo a la configuración particular de tu proyecto. Configuraremos también el settings.py de nuestro proyecto añadiendo algo como:
COMPASS_INPUT = os.path.join(SITE_ROOT, 'static_media', 'sass') # adáptalo
COMPASS_OUTPUT = os.path.join(SITE_ROOT, 'static_media', 'css') # adáptalo
COMPASS_STYLE = 'compact'
COMPASS_EXECUTABLE = '/home/javi/.envs/nombre/gems/bin/compass'
Por último, sólo queda arrancar el servidor de pruebas y poner compass en modo vigilante para compilar los cambios que hagamos a los archivos .scss automáticamente:
En una terminal: python manage.py runserver
En otra: python manage.py compass watch
Fuentes:
Este artículo se basa en la estupenda exposición “Responsive web design with Django, Compass and the Less framework“, de Idan Gazit en la DjangoCon 2011
septiembre 24, 2011 at 9:36 am | Blog, Django | No comment
Vamos con uno de esos problemas estúpidos que te hacen perder una cantidad de tiempo impresionante. Ahora mismo llevaba desde las 8 intentando resolver un problema relacionado con el estupendo FeinCMS y es que cuando cambiaba en settings.py el atributo DEBUG a False se producía un error 500 al intentar acceder a los archivos estáticos y me mostraba la plantilla estándar de error 500 de apache.
Casualmente, existía un problema con FeinCMS y mod_wsgi que hacía que se debieran realizar ciertos ajustes en servidores de producción al cambiar DEBUG = False y es a mensajes referentes a ese problema a los que he ido a parar primero, así que me he tirado buena parte del principio de la mañana probando a cambiar el orden de aplicaciones en INSTALLED_APPS, a precargar módulos en el urls.py base, a modificar el archivo de configuración de wsgi, y varias ocurrencias más, sin embargo, todo seguía igual: intentaba acceder a los estáticos y obtenía un error 500.
El problema realmente era que estaba viendo el error pero no me estaba parando a entenderlo. El error en cuestión era:
VariableDoesNotExist: Failed lookup for key [feincms_page] in (variables de entorno variadas)
Claro, hacía referencia a feincms_page y yo piqué y seguí buscando el error por ahí, pero el problema era más enrevesado.
Como estaba cansado de revisar los logs en el servidor, se me ocurrió que podía modificar la plantilla de errores 500 para que mostrara el error cada vez, y esto hizo que se me encendiese por fin la bombilla ¿por qué estaba viendo la plantilla por defecto de Apache si yo tenía una plantilla “bonita” para los errores 404 y 500? Abrí las plantillas y ahí estaba la primera parte del problema: estaba extendiendo otra plantilla que usaba un templatetag al que se le pasaba una variable feincms_page. Cambié la plantilla de base y ahora sí aparecían mis plantillas de error.
Pero seguía siendo extraño. Ahora no recibía un error 500, sino un 404 cuando intentaba acceder a los estáticos. ¿Estamos locos ahora o qué? Si los estáticos no los debería servir Apache sino NGINX O_o?
A revisar la configuración del settings para MEDIA_URL, STATIC_URL y ADMIN_MEDIA_PREFIX (extrañamente, media y admin funcionaban correctamente). Pues no, todo está bien. Vamos a ver TEMPLATE_CONTEXT a ver si he incluído ‘django.core.context_processors.static’; sí, si que está.
Ya no se me ocurría qué más hacer. Rastreé por el servidor a ver si las carpetas y enlaces simbólicos estaban bien… todo correcto.
Por último decido ir al panel de control de Webfaction a ver si hay algún problema en cómo tengo configurada la web y ¡Zas! en toda la boca: no había añadido a la web la aplicación static ni la ruta desde la que se servía, por eso al intentar acceder a los estáticos me respondía Apache y no intentaba servir los estáticos, sino páginas del cms U_U.
Pongo la captura como ejemplo de configuración de sitio en Webfaction: una aplicación django + 3 aplicaciones symbolic_link a static content only que apuntan a los medios de django admin y a los estáticos y media propios de nuestro proyecto:
Así que:
- Revisar las plantillas más básicas, como la base.html y las de error si se muestran las páginas de error estándar de Apache en lugar de las tuyas.
- Revisar que se han creado todas las aplicaciones y que se han añadido todas con sus rutas a la web en el panel.
- …
- Profit!
septiembre 14, 2011 at 5:29 pm | Blog, Destacados, Trabajo | No comment
Desarrollado especialmente para Juan Carlos Girón distribuidor y proveedor de artículos de joyería.
La aplicación permite gestionar artículos, imprimir etiquetas con códigos de barra, leer dichas etiquetas para preparar facturas y gestionar clientes, facturas y albaranes.
agosto 3, 2011 at 2:55 pm | Blog, Destacados, Trabajo | No comment
Tienda online para Joyería Relojería Gómez.
Con dos tiendas físicas en Azuaga y Don Benito directamente desde la web pueden ofrecer sus productos a toda España.
La tienda incluye carro de compra, posibilidad de elegir diferentes direcciones y métodos de envío para varios artículos, pasarela de pagos (Paypal, Transferencia bancaria y tarjetas de crédito), cuentas de usuario/clientes y contenido social (Facebook, Twitter y Google+)
julio 1, 2011 at 12:58 pm | Blog, Destacados, Trabajo | No comment
Página de información y reservas para rutas turísticas, desplazamientos y excursiones en Helicóptero en la provincia de Granada.