Esta sencilla pero potente aplicación permite al usuario ahorrarse batería y molestias evitando que el dispositivo apague su pantalla y se bloquee.

Gracias a esto, se puede configurar el tiempo de iluminación de la pantalla al mínimo y una vez se cumpla DimScreen reducirá al mínimo el brillo y mantendrá la pantalla en reposo, con lo que se evita perder la página se estaba leyendo, la conversación que estabas manteniendo, etc.

También ayudará a conservar los maltrechos botones de encendido/apagado que en algunos dispositivos son tan delicados.

Desde su sede en San Fernando de Henares (Madrid) dirigen su negocio de artes gráficas en el que son especialistas en trabajos de impresión de gran formato.

Su nueva web, además de ser completamente dinámica, incluye un área para facilitar la comunicación y los procesos de trabajo con sus clientes, permitiéndoles solicitar presupuestos, ver el progreso de sus trabajos, enviar ficheros mediante formularios, arrastrando los archivos desde el ordenador al navegador, mediante Dropbox o mediante cuentas de FTP. Todo ello automatizado para facilitar al máximo el desarrollo de su actividad.

El sitio ha sido desarrollado teniendo en cuenta las nuevas tendencias en diseño fluido y se adapta a cada dispositivo en el que se consulta, ya sea PC de sobremesa, tablet o móvil.

Django incorpora unas grandes herramientas para traducir los sitios a diversos idiomas, pero hay un pequeño pero: todo debe estar en el mismo idioma base y luego incorporar las traducciones necesarias.

Esto lo he descubierto después de estar unas pocas de horas rebuscando por qué había algunos formularios y cadenas que no se mostraban correctamente en inglés y sólo aparecían en español.
La clave estaba en que los formularios eran parte de una aplicación antigua que había incluido en  el proyecto (ya sabes, don’t repeat yourself) y estaban integramente en español. Así que he tenido que pasarlo a inglés y crear el archivo de traducciones a español como para el resto de aplicaciones.

Así, ver la web en una pantalla de gran tamaño como puede ser la de un ordenador o un televisor mostraba la versión normal extendida, mientras que había otras versiones con imágenes de menor tamaño o con el contenido en una única columna en lugar de dividirlo en 2 para netbooks y por último versiones especialmente reducidas para facilitar la navegación en smartphones y no utilizar muchos datos.

Pero me quedaba la espinita de que realmente no le daba la opción al usuario de ver la versión “completa” si así lo quería, y no quería seguir así, de modo que en el proyecto que tengo entre manos actualmente he utilizado dos herramientas estupendas para esto:

• django-mobile
• Sass y compass

De Sass ya hablé un poco en una entrada anterior, pero gracias a @TheSassWay sigo alucinando con lo potente que es. La base de Sass es que permite crear ficheros con reglas a partir de otros ficheros más pequeños a los que se llama partials.

Un fichero full.scss puede ser así:

@import "partials/more";
@import "partials/global";
@import "partials/default";
@import "partials/tablet";
@import "partials/mobile";
@import "partials/wide-mobile";
@import "partials/high-px-ratio";

Y otro fichero desktop.scss ser así:

@import "partials/more";
@import "partials/global";
@import "partials/default";

{% if flavour != 'full' %}
    <a href="?flavour=full">Ver versión estándar</a>
{% else %}
    <a href="?flavour=mobile">Ver versión móvil</a>
{% endif %}

{% if flavour == "full" %}
    <link rel="stylesheet" type='text/css' href="{{ STATIC_URL }}css/desktop.css?v=2">
{% else %}
    <link rel="stylesheet" type='text/css' href="{{ STATIC_URL }}css/full.css?v=2">
{% endif %}

{% load thumbnail %}

<div id="work_list">
    {% for work in object_list %}
            <div class="work">
            <a href="{{ work.get_absolute_url }}">
                {% if flavour == "mobile" %}
                    {% thumbnail work.main_image "240x160" crop="center" as img %}
                    <img src="{{ img.url }}" alt="{{ work.name }}" height="{{ img.height }}" width="{{ img.width }}" />
                    {% endthumbnail %}
                {% else %}{% if flavour == "tablet" %}
                    {% thumbnail work.main_image "640x426" crop="center" as img %}
                    <img src="{{ img.url }}" alt="{{ work.name }}" height="{{ img.height }}" width="{{ img.width }}" />
                    {% endthumbnail %}
                {% else %}
                    {% thumbnail work.main_image "1024x682" crop="center" as img %}
                    <img src="{{ img.url }}" alt="{{ work.name }}" height="{{ img.height }}" width="{{ img.width }}" />
                    {% endthumbnail %}
                {% endif %}{% endif %}
            </a>
            <a class="product" href="{{ work.product.get_absolute_url }}">{{ work.product }}</a>
            </div>
    {% endfor %}
</div>

Habitualmente lo que hago es encender el pc remotamente con Wol Wake On Lan Wan y luego accedo normalmente por ssh, pero esta vez no había manera. Lo intenté varias veces, comprobé que Dyndns.org tenía la IP a la que apuntaba actualizada y nada, no pude encenderlo ni acceder. Al final resolví lo que necesitaba de otra forma pero el asunto me dejó con la mosca detrás de la oreja.

Hace un momento me he puesto a mirar y ya he descubierto lo que ha ocurrido: la semana pasada reinicié el router

Por lo visto al hacerlo se resetea la tabla ARP del router, que cuando vuelve a encender ni la mantiene ni la restaura, así que el pc no podía responder a las llamadas de despertador porque no se las pasaba el router. Para volver a dejar la entrada permanente en el router, hay que acceder a él por telnet y hacer:

arp add IP.DEL.PC DIR.ECC.ION.MAC

Al entrar en la administración web del router, en Device Info, ARP, se ve que la entrada para esa IP ha cambiado de Complete a Permanent, así que sólo queda acordarse de volver a realizar el cambio tras cada reinicio.

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

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:

1. 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.
2. Revisar que se han creado todas las aplicaciones y que se han añadido todas con sus rutas a la web en el panel.
3. …
4. Profit!

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.

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+)