Welcome to Django

Localizando nuestras aplicaciones Django

Fox — Tue, 10 Jan 2012 12:37:19 +0000

Como es lógico, una aplicación web localizada tendrá mas visitantes que una que no lo está.

Localizar un proyecto Django es lo más fácil que he visto nunca. No lo digo porque este blog sea de Django, si no porque personalmente me gusta bastante localizar aplicaciones y las alternativas son más complejas de localizar. Sin ir más lejos en .NET aunque no complejo, es mucho más cansino de hacer.

Bueno, mejor verlo en funcionamiento pues hablar es fácil.

Creamos un nuevo proyecto llamado localizacion y una aplicación llamada app.

Hay que configurar un poco el settings.py como hacemos con todos los proyectos nuevos. Me encanta explicar las cosas muy paso por paso, pero la configuración es siempre igual y ya está explicado en mis artículos anteriores, así que por última vez daré un resumen de lo que hay que configurar:

Un parámetro con la ruta del proyecto
Configurar un directorio para ficheros estáticos (aunque no es necesario para este ejemplo)
Configurar un directorio para templates
Configurar una base de datos sqlite3 (Y ejecutar syncdb)
Añadir la aplicación app a la lista de aplicaciones

Si os dais cuenta, en el settings.py hay dos parámetros sobre localización:

# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = True

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale
USE_L10N = True

USE_I18N sirve para activar todo el tema de localización. Sin esto no podremos localizar nada.
USE_L10N nos localiza también las fechas ya que para python las fechas son YYYY/MM/DD y por ejemplo para los alemanes es dd.mm.yyy

Bueno, ya tenemos todo listo para empezar a picar código.

Vamos a crear una vista (/app/views.py):

import datetime
from django.shortcuts import render_to_response
from django.template.context import RequestContext

def home(request):
    message = "This is a message from the views.py"
    date = datetime.date.today()
    return render_to_response("app/home.html", locals(), context_instance=RequestContext(request))

Una vista con tres variables (para las distintas pruebas de localización).

La idea es programar usando variables en inglés, comentarios en inglés y vaya, todo en inglés. Ya luego lo localizais en castellano si queréis.

Vamos a añadir una nueva url al urls.py:

url(r'^$', 'app.views.home'),

Ahora creamos un directorio llamado app dentro del directorio templates que habíamos creado anteriormente y añadimos un fichero llamado home.html:



    
        
        Localization example
    
    
        Message from the template!
        {{ message }}
        Today is {{ date }}

Si ahora ejecutamos la aplicación veremos lo siguiente:

Ok, chachi piruli.

¿Cómo localizamos? Vamos a empezar por la vista.

Todas las cadenas que querramos traducir en los ficheros .py tendrán que pasar por ugettext así que nuestro método home pasará a estar así:

from django.utils.translation import ugettext as _

def home(request):
    message = _("This is a message from the views.py")
    date = datetime.date.today()
    return render_to_response("app/home.html", locals(), context_instance=RequestContext(request))

Hemos cargado ugettext con el nombre de _ (así es más comodo de usar, además creo que es una convención de otros lenguajes).

Ahora simplemente cada cadena la convertimos a una llamada a la función _. Nada más. ¿Fácil eh?

¿Y ahora el template? Pues vamos a modificarlo:

{% load i18n %}


    
        
        {% trans "Localization example" %}
    
    
        {% trans "Message from the template!" %}
        {{ message }}
        {% blocktrans %}Today is {{ date }}{% endblocktrans %}

Cargamos los tags de i18n.

Tenemos el tag trans para traducir cadenas.Luego tenemos blocktrans para traducir bloques, como por ejemplo un bloque que contenga a mitad una variable, así podemos traducir de una vez un bloque con “cadena – variable – cadena” en vez de tener dos trans por separado.

Como es lógico, las variables ya vienen localizadas desde la vista.

Bueno, ¿Cómo sabe Django a que lenguajes quiero localizar?

Abrimos el settings.py y añadimos lo siguiente:

LANGUAGE_CODE = 'en-us'

LANGUAGES = (
    ('en', 'English'),
    ('es', 'Spanish'),
)

Con esto le decimos a Django los lenguajes que queremos.

Bueno, ya solo nos queda ejecutar el siguiente comando en el directorio principal del proyecto, aunque antes tenéis que crear un directorio llamado locale en dicho directorio principal o fallará:

django-admin.py makemessages -l es

Con esto nos crea los directorios y ficheros necesarios para la localización en español.

Tendremos que ejecutar ese comando por cada idioma extra.

Bueno, abrimos el fichero /locale/es/LC_MESSAGES/django.po

Esto es sencillo, por cada msgid hay un msgstr. Así que hay que colocar la traducción de cada msgid en su respectivo msgstr:

#: .\app\views.py:8
msgid "This is a message from the views.py"
msgstr "Esto es un mensaje desde el views.py"

#: .\templates\app\home.html.py:6
msgid "Localization example"
msgstr "Ejemplo de localizacion"

#: .\templates\app\home.html.py:9
msgid "Message from the template!"
msgstr "Mensaje desde el template!"

#: .\templates\app\home.html.py:11
#, python-format
msgid "Today is %(date)s"
msgstr "Hoy es %(date)s"

Vale, ahora solo nos queda compilar el .po para que Django lo entienda.

django-admin.py compilemessages

Vale, si ejecutamos la aplicación ahora pues no vemos ningún cambio. ¿No molaría que usara el idioma del navegador para poner ese idioma por defecto?

Es fácil, solo tenemos que añadir un middleware:

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
)

Aunque parezca el middleware añadido ahi al azar, necesita cumplir 3 cosas:

Tiene que ser de los primeros middleware a añadir.
Pero tiene que aparecer DESPUES de SessionMiddleware y a la vez ANTES de CommonMiddleware.
Si usaramos CacheMiddleware, tendríamos que ponerlo despues de este.

Vale, ahora ejecutamos la aplicación y…

¡Ya está localizada!

Molaría un selector de idioma, ¿no?

Bueno, pues vamos a añadir una url más al views.py:

url(r'^i18n/', include('django.conf.urls.i18n')),

Ahora vamos a añadir un pequeño formulario a app/home.html:


	{% csrf_token %}

Es muy sencillito. Hace un POST enviando como parámetro la url de la página que cargará cuando se cambie el idioma y el idioma en si.

La lista de idiomas que cargará en el select viene del parámetro LANGUAGES del settings.py

Bueno, esto es lo básico en cuanto a localización. Por supuesto hay más chicha, pero con esto podremos empezar a localizar nuestros trabajos.

Os dejo el .zip con el proyecto.

Jugando con django-registration

Fox — Tue, 20 Dec 2011 19:55:00 +0000

Hola, aquí estoy de nuevo con un artículo, y ya vamos a empezar metiendo código y todas esas cosas que nos gustan.

En este artículo vamos a hablar de django-registration. django-registration es una librería para manejar el registro de usuarios (registro, entrar al sistema, salir, cambiar la contraseña…).

Django de por si no tiene ningún sistema de registro de usuarios (aunque implementarlo es trivial), así que se creó esta librería para proporcionar un pequeño sistema de registro bastante sencillo pero a la vez bastante potente.

¿Vamos a ello?

Yo para cada nueva aplicación, aunque sea pequeñita, suelo crear un nuevo virtualenv. Vamos a darle caña:

En mi caso (Windows):

virtualenv --no-site-packages --distribute register
env.py register
pip install django
pip install https://bitbucket.org/ubernostrum/django-registration/get/tip.zip

Tenemos que instalar así django-registration porque la versión que hay en pip es la 0.7 y hay los suficientes cambios en la tip como para usar esa.

Vamos a crear una aplicación de ejemplo:

django-admin.py startproject register
cd register
python manage.py startapp app

Bueno, ya tenemos nuestra aplicación.

En cada nuevo proyecto tenemos que hacer una serie de ajustes. Vamos a empezar creando un directorio llamado templates en el directorio raiz.

Ahora abrimos el settings.py y configuramos la ruta de nuestra aplicación y la base de datos:

CURRENT_PATH = os.path.dirname(__file__)

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'data.db',
    }
}

No os olvideis de importar el módulo os.

Agregamos nuestro directorio de templates:

TEMPLATE_DIRS = (
    os.path.join(CURRENT_PATH, 'templates'),
)

Y por último agregamos nuestra aplicación y la de django-registration:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'app',
    'registration',
)

Bueno, realmente quedan dos ajustes más. Aunque antes de eso explicaré un poco más.

django-registration tiene por defecto un par de back-end. Tiene uno por defecto, el cual no activa la cuenta al registrarnos por lo que nos envía un correo con una url de activación que al hacerle click pues nos activa la cuenta.

Si vamos a usar este back-end necesitamos configurar un par de cosas (settings.py):

ACCOUNT_ACTIVATION_DAYS = 7

EMAIL_HOST = 'servidorsmtp'
EMAIL_HOST_USER = 'usuario'
EMAIL_HOST_PASSWORD = 'contraseña'
EMAIL_USE_TLS = True
EMAIL_PORT = 123

Con lo primero establecemos un periodo de tiempo antes de que nuestra cuenta caduque si no se activa, por ejemplo 7 días. Lo siguiente es la configuración para enviar correos electrónicos.

Si no tenéis ningún servidor de correo a mano, podéis usar un correo de gmail así:

EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'usuario@gmail.com'
EMAIL_HOST_PASSWORD = 'contraseña'
EMAIL_USE_TLS = True
EMAIL_PORT = 587

Si no queréis todo el tema de activación y que al registrarnos nos active la cuenta directamente, podéis usar el back-end llamado simple.

El siguiente paso es configurar el fichero urls.py añadiendo:

(r'^accounts/', include('registration.backends.default.urls')),

Podéis ver que hemos usado el back-end default el cual lleva todo el tema de activación. Es el más complejo de los dos, pero entendiendo este, entiendes el otro.

Antes de empezar a registrar usuarios, django-registration necesita varios templates, vamos a pasar a describirlos:

registration/registration_form.html – Es el template con el formulario de registro.
registration/registration_complete.html – Es el template que aparecerá cuando completemos el registro.
registration/activate.html – Se muestra si la activación falla.
registration/activation_complete.html – Se muestra cuando la cuenta se activa correctamente.

Esos son los templates necesarios para django-registration, aunque necesitamos uno más para poder hacer uso del login:

registration/login.html – Template para la página de login.

Vale, ¿pero qué pasa con logout?

Tenemos dos opciones, o bien creamos un template en:

registration/logout.html o bien nos saltamos el template y hacemos el logout directamente. Para esto tenemos que ir a urls.py y añadir (por encima de la entrada de accounts):

url(r'^accounts/logout/$', 'django.contrib.auth.views.logout', {'next_page': '/'}),

donde next_page es la página que se cargará al hacer logout.

Aparte de esto, necesitamos crear dos ficheros .txt para el correo:

registration/activation_email_subject.txt – Es el asunto del correo.
registration/activation_email.txt – Es el cuerpo del correo.

Bueno, vamos a poner un pequeño ejemplo de cada fichero para que lo veáis:

registration/registration_form.html:




    
    


    
        {% csrf_token %}
        {{ form.as_p }}

Lo suyo sería que los templates heredaran de otro para que todos compartieran el mismo diseño, pero por simplicidad vamos a dejarlo así (de hecho, no vamos ni a usar CSS).

Como véis, este template tiene acceso a un form, que como habéis deducido, es el formulario de registro

registration/registration_complete.html:

Se ha registrado correctamente, se le ha enviado un correo con una url para activar su cuenta.

registration/activate.html:




    
    


    No se ha podido activar su cuenta,
    el código de activación es: {{ activation_key }}

Este template tiene acceso al código de activación.

registration/activation_complete.html:

Gracias, su cuenta se ha activado correctamente.

registration/login.html:




    
    


    
        {% csrf_token %}
        {{ form.as_p }}

Como en el formulario de registro, aqui usamos el formulario de login.

registration/activation_email_subject.txt:

Bienvenido a {{ site }}, por favor active su cuenta antes de {{ expiration_days }} días.

El asunto del correo tiene que ser una sola linea.

registration/activation_email.txt:

Hola, bienvenido a {{ site }}.

Por favor, active su cuenta en: {{ site }}/accounts/activate/{{ activation_key }}

¡Gracias!

Tanto el asunto como el correo en si, tienen acceso a tres variables:

site – El nombre del sitio (se cambia en el panel de administrador, en el apartado Sites).
activation_key – La clave generada automaticamente para activar la cuenta.
expiration_days – Los días que tienes para activar la cuenta antes de que caduque.

Bueno, si tenemos el correo configurado y nos registramos, deberíamos recibir un correo de este tipo:

Hola, bienvenido a example.com.

Por favor, active su cuenta en: example.com/accounts/activate/1cac5be0c509589eed31cef8a4697a0aa329b709

¡Gracias!

Como no he modificado lo de example.com en el panel de administrador pues sale eso como site. Lo normal es cambiarlo al hacer deploy.

Si hacemos un poco de corta pega pues activaremos nuestra cuenta y ya podremos loguearnos.

Al loguearnos recibiremos un hermoso error pues no tenemos ningún contenido en la web.

Para probar vamos a hacer dos cosas:

1º Vamos a ir a settings.py y vamos a colocar el siguiente parámetro:

LOGIN_REDIRECT_URL = "/"

Eso hará que cuando nos logueemos, nos redirija a la página principal.

2º Vamos a crear una página principal.

Empezamos creando un fichero llamado index.html dentro de registration/app:




    
    


    Ha entrado como {{ user.username }}

Creamos una vista en views.py:

from django.shortcuts import render_to_response
from django.template.context import RequestContext

def index(request):
    return render_to_response("app/index.html", locals(), context_instance=RequestContext(request))

y finalmente modificamos el urls.py:

url(r'^$', 'app.views.index'),

Ya está. Ya podemos registrarnos, loguearnos, salirnos, y activar nuestras cuentas.

Aunque no quiero dejarlo aquí. Ahora vamos a explicar como extender esta librería para crear un formulario que tenga campos extras, lo cual es algo muy común.

Entonces, ¿Qué pasa si quiero por ejemplo almacenar ciertos datos con cada usuario?

Empezamos creando un modelo para esos datos, por ejemplo vamos a almacenar la edad y el sexo del usuario.

Pues nos vamos a models.py y creamos un modelo:

from django.contrib.auth.models import User
from django.db import models

class DatosExtra(models.Model):
    user = models.OneToOneField(User)
    edad = models.IntegerField()
    sexo = models.CharField(max_length=9)

Hacemos un syncdb para añadir la nueva tabla.

Ahora necesitamos crear el formulario de registro el cual heredará del ya existente. Para ello creamos un fichero llamado forms.py:

from django import forms
from registration.forms import RegistrationForm

class DatosExtraForm(RegistrationForm):
    edad = forms.IntegerField()
    sexo = forms.ChoiceField(choices=[('masculino', 'masculino'), ('femenino', 'femenino')])

Un formulario sencillito, simplemente le añadimos los dos campos extras y el de sexo como un select lo cual lo hace más cómodo. Como extra, decir que choices acepta una lista de tuplas, cada tupla tiene dos valores, el valor que guardará y el valor que mostrará en el select. En este caso el mismo para ambos.

¿Cómo hacemos que la página de registro lo muestre?

Fácil, la vista de registro acepta un formulario personalizado como parámetro, así que solo tenemos que añadir una nueva url en urls.py (por encima de la de accounts):

url(r'^accounts/register/$', 'registration.views.register',
                {'backend': 'registration.backends.default.DefaultBackend', 'form_class': DatosExtraForm}),

¡Ya sale! Si, pero no lo guarda.

La mejor forma para guardar los cambios es crear nuestro propio back-end. Existe un signal que se lanza cuando se crea el usuario, pero no está preparado para estos casos pues no envia los datos con el para guardar las cosas extras y tirar de request.POST no mola pues no tendríamos acceso a variables del tipo cleaned_data.

Bueno, ¿Cómo lo hacemos?

La forma más facil es copiar el default backend en nuestro proyecto y modificarlo.

Para ello vamos a copiar el directorio default que se encuentra en python/lib/site-packages/registration/backends/. Lo copiamos al directorio principal del proyecto y lo renombramos, no sé, a custom_backend por ejemplo.

Una vez copiado abrimos el __init__.py y le metemos los cambios marcados en negrita:

new_user = RegistrationProfile.objects.create_inactive_user(username, email,
                                                                    password, site)

extra = DatosExtra(user=new_user)
extra.sexo = kwargs['sexo']
extra.edad = kwargs['edad']
extra.save()

signals.user_registered.send(sender=self.__class__,
							 user=new_user,
							 request=request)
return new_user

Recordad importar la clase, además le vamos a cambiar el nombre a la clase de DefaultBackend a CustomBackend.

Esto no hace nada impresionante. Simplemente crea una instancia del modelo con los datos extras los cuales cogemos del diccionario kwargs (El cual viene de la vista y pasa todos los campos del formulario) y guardamos el modelo.

Ahora tenemos que modificar la url que pusimos antes para que use el nuevo back-end quedando así:

url(r'^accounts/register/$', 'registration.views.register',
                {'backend': 'register.custom_backend.CustomBackend', 'form_class': DatosExtraForm}),

Ya está, nuestros nuevos usuarios se registrarán usando datos extras.

Vamos a modificar la vista para que use también los nuevos datos, ¿no?

Abrimos views.py y modificamos el index así:

# Create your views here.
from django.shortcuts import render_to_response
from django.template.context import RequestContext
from app.models import DatosExtra

def index(request):
    if request.user.is_authenticated():
        extra = DatosExtra.objects.get(user=request.user)
    return render_to_response("app/index.html", locals(), context_instance=RequestContext(request))

Ahora vamos a app/index.html:




    
    


    Ha entrado como {{ user.username }}. Tiene {{ extra.edad }} y es de sexo {{ extra.sexo }}

Ya está. Ya podemos registrar usuarios con todos los campos extras que nos hagan falta.

Si queréis más información, siempre os quedará la documentación oficial.

Aquí os subo el proyecto, simplemente tenéis que hacer un syncdb para crear una base de datos y probar. Aunque os recomiendo que lo hagais todo a mano para aprender mejor.

Y nada más, dejad algo de feedback que viene bien para la motivación.

Análisis: PyCharm

Fox — Sun, 27 Nov 2011 19:58:51 +0000

Voy a analizar el IDE PyCharm de Jetbrains.

Jetbrains son los creadores del IntelliJ IDEA, el cual es un IDE de Java y también del maravilloso ReSharper.

Con IntelliJ IDEA han hecho como un conocido autor español hace con sus libros, le ha cambiado tres cosas y con eso han creado 20 IDEs más. Fuera bromas, han creado varios IDEs basados en IntelliJ IDEA y entre ellos está PyCharm.

PyCharm como habéis podido deducir, es un IDE de Python con soporte de Django.

Paso a comentarios muchas de sus features, aunque seguro que olvidaré algunas y otras que todavía no he descubierto.

Antes que nada os dejo una captura del IDE con BCal abierto.

EDITOR

Vamos a empezar con las features del editor de PyCharm:

Coloreado de sintaxis:

El editor ofrece coloreado de sintaxis (personalizable por supuesto) para cualquier lenguaje, ejemplos:

Python:

Para mi gusto, podría ser más completo.

Django Templates:

Javascript:

Para mi gusto, más conseguido que el de Visual Studio.

CSS:

Como véis tiene un coloreado bastante majete. (Aunque claro, también depende del tema que llevéis puesto, ese en concreto se llama Solarized Light)

Zen Coding:

Zen Coding no es algo especial de PyCharm, pero viene incluido de serie y es una maravilla.

¿Para qué sirve? Nos ayuda a escribir código HTML y CSS a la velocidad de la luz…

Vamos a poner un ejemplo… Necesitamos crear un div con un ul que tenga un id=”lista” y 3 li con class=”elemento” que a su vez contengan un div y no sé, un span.

Algo muy típico, pero en vez de escribirlo manualmente, escribimos:

div>ul#lista>li.elemento*3>div+span

pulsamos TAB y se nos convierte en:

Mucho más fácil, ¿no?

En CSS nos simplifica un poco la vida, vamos a ver algunos ejemplos:

bdt:n
bxsh:m
v:h

border-top: none;
-moz-box-shadow: 0 0 0 0 #000;
visibility: hidden;

respectivamente.

En la página de Zen Coding o en las opciones de PyCharm puedes ver la lista de todos los atajos.

Código no usado:

Hay veces que tenemos import sin usar o variables que nunca se han usado. PyCharm nos la muestra en pantalla:

Tenía un import sin usar y ahi me lo ha puesto en gris. También pasa igual con variables:

Diccionarios incluidos:

Yo soy el primero que cuando instalo una aplicación que tiene un diccionario, se lo quito sin pensar. Escribo bastante bien y no suelo tener faltas de ortografía. Por pereza no quité el corrector (es de inglés, aunque parece que se pueden añadir más diccionarios) que trae, pero oye, es de lo más útil.

sin querer puse calendr.html en vez de calendar.html y esto me avisa de que tengo un typo en la palabra. Obviamente se como escribir calendar pero en un lapsus lo puse mal y oye, me ayudó a tener que hacer debug como un tonto.

Soporte i18n por defecto (PyCharm 2+):

Ahora tenemos soporte para i18n por defecto en el IDE:

Si hacemos click en el cuadradito azul nos pregunta el idioma a editar:

Y si le damos al de Aleman:

Nos lleva directamente al .po y a la cadena elegida.

Navegación entre objetos:

Si quieres por ejemplo ir a la definición del formulario que estás usando, puedes hacer CTRL+CLICK:

Lo cual nos llevará directamente a la definición de UserInfoForm.

Podemos ir más allá, por ejemplo:

Si hacemos eso, nos llevará a la definición de la clase Form que está en el código fuente de Django:

Está fenomenal eso.

Avisos varios:

Por ejemplo, si colocamos un anchor tag y lo cerramos sin colocar su correspondiente , el editor nos avisará de que eso puede no ser bueno:

Soporte Python

El soporte de Python es muy bueno, podemos destacar:

Auto completado de código:

El auto completado de código de PyCharm es bastante bueno, ahí van algunos ejemplos:

Auto-import de librerías:

Ya no necesitamos recordar dónde estaban las clases o métodos que queremos usar:

Si en ese caso pulsamos ALT + ENTER (no sé por qué pone ‘Introduzca’) importará directamente el método render_to_response.

Refactorización de código:

Muchas veces nos da consejos de si algún código que tenemos puede escribirse de mejor forma, por ejemplo:

Y si le das a la zona amarilla saldrá un recuadro con distintas opciones, entre ellas la de cambiar el código por otro:

Soporte Django

Para Django también hay cosas chulas, ejemplos:

Atajos para ‘template tags’:

Hay que admitirlo, es un coñazo tener que escribir código como:

{% for palabra in palabras %}

{% endfor %}

PyCharm te ofrece la posibilidad de simplificarlo, sólo tienes que hacer:

for[TAB]

O sea, escribes for pulsas TAB, te situa el cursor a la derecha del in, escribes la colección, pulsas ENTER, te situa para colocar el nombre del elemento, pulsas ENTER y ya te coloca dentro del TAG para escribir el código. Es más fácil probarlo que explicarlo

También hay atajos para block, if, etc. Puedes ver la lista completa en las opciones de PyCharm.

Soporte para diferentes templates (Jinja2, mako y Django) (PyCharm 2+)::

Si no nos gusta el motor de templates que trae Django por defecto, podemos optar por Jinja o bien por Mako.

PyCharm 2 ofrece soporte para estos dos motores, con su coloreado, su auto completado de código…

IDE

Y vamos con la última sección, el IDE.

Poder usar el manage.py desde PyCharm:

Tecnicamente podemos hacer cualquier cosa desde el IDE sin tener que recurrir a la consola. El usar el manage.py es una de ellas.

Desde el menú vamos a Tools > Run manage.py task…

Te saldrá una listas de cosas que puedes hacer:

Si lo que quieres hacer acepta parámetros como startapp nos saldrá un dialogo para introducir los parámetros:

Múltiples intérpretes:

¿Que estamos usando virtualenv? No pasa nada, podemos configurar en PyCharm todos los intérpretes que queramos:

Ahí configuramos los interpretes que tenemos y seleccionamos uno para el IDE (que no para el proyecto), con esto quiero decir que si tenemos un virtualenv que tiene instalado, no sé, django-registration, PyCharm lo verá y podrá ofrecernos su auto completado y todas esas cosas.

Luego para el proyecto en concreto puedes decirle que virtualenv usar para ejecutarse.

Plugins

El sistema de plugins que tiene es muy bueno, y tiene una cantidad bastante maja de plugins. Por defecto tiene muchos puestos:

Puedes ver que la lista de plugins instalada por defecto (a excepción de los dos que puse yo) es bastante grande. Less, Coffescript, Git, etc.

Soporte para sistemas de control de versiones

¿Tenemos un repo en Github? ¿O en Bitbucket? Pues agregamos el plugins si fuera necesario, y en el caso de Bitbucket por ejemplo nos vamos a VCS > Checkout from version control > Bitbucket, metemos nuestros credenciales y nos aparecerá una lista con nuestros repositorios:

Al importar el proyecto no solo lo importaremos, también estará sincronizado con el repositorio y eso nos da mil cosas.

Podemos ver si un fichero ha sido modificado con respecto al repositorio, añadido al proyecto pero no al repositorio, o añadido a ambos pero no sincronizado.

Los colores son:

Negro: Fichero en ambos sitios (repo y proyecto) y sin cambios.
Rojo: Añadido al proyecto pero no al repositorio.
Verde: Añadido a ambos sitios.
Azul: Modificado con respecto al repositorio.

Además podemos ver las diferencias entre ficheros, hacer un pull para traernos los cambios, o casi cualquier cosa que podamos hacer con Tortoise.

Shell Python y Django integradas

En el mismo menú Tools tenemos una shell de Python y una de Django (lo que nos abriría python manage.py shell).

Es otra de las opciones que nos hace no tener que recurrir a una consola si no queremos.

Visor de bases de datos incluido

¿Queremos ver qué tenemos en nuestra base de datos Sqlite?

Fácil, PyCharm al ver que usamos dichas bases de datos, nos ofrecerá la posibilidad de instalar un plugin para tratar con ellas.

Ahí un extracto de lo que sería mi base de datos. También nos deja ver los datos que hay dentro y eso.

Multiples esquemas de atajos

Al instalar PyCharm nos da la posibilidad de seleccionar un esquema de atajos que se adapte más a nuestros gustos. Yo personalmente escojí el de Visual Studio que ya me lo conozco bien

Ejecución y Debug

Y por último, ejecución y debug.

Si le damos a ejecutar, PyCharm lanzará el servidor integrado de Django y bueno, no hace nada especial, nos muestra todas las peticiones que hacemos al servidor y nos muestra las excepciones que se produzcan.

Por otro lado, el debugger es más interesante.

Tiene todo lo que podemos esperar de un debugger, ni más ni menos. La versión 2.0 de PyCharm trae hasta debugger de Javascript.

Lo de siempre, marcamos puntos donde queramos que el código se pare y a analizar los datos:

Conclusión

Pensé que nunca llegaría

PyCharm sin llegar al nivel de Visual Studio, ha hecho que pueda programar en Django sin preocuparme por nada y de hecho tiene cosas que no he visto en Visual Studio, al menos no de forma tan cómoda, como por ejemplo el tema de localización y hasta el coloreado de Javascript es mejor (aunque el autocompletado es algo más simple).

Lo recomiendo 200% y es baratito

Hasta otra.

BCal, el calendario de menstruación

Fox — Sat, 26 Nov 2011 17:31:47 +0000

Hola! Despues de muchas horas de trabajo he conseguido terminar una primera versión de BCal.

¿Qué es BCal? BCal es un calendario de menstruación escrito por supuesto en Django.

Está en inglés, alemán y por supuesto en español.

Si queréis probarlo, id a: http://bcal.foxandxss.net

Si queréis ver su código, id a: https://bitbucket.org/Foxandxss/bcal/wiki/Home

Un saludo.

Organizando ficheros estáticos

Fox — Fri, 18 Nov 2011 18:33:59 +0000

Vamos a hablar un poco de los ficheros estáticos de Django y ver cómo podríamos organizarlos.

Como ya expliqué en el artículo sobre despliegue, tenemos un directorio static en el directorio principal donde colocamos nuestros ficheros estáticos, o sea, los css, javascript, imagenes, etc.

Para las aplicaciones pequeñas esto va de fábula, pero en cuanto la cosa empieza a complicarse un poco, viene bien que nos organicemos un poco.

Como de costumbre, vamos a crear una aplicación de ejemplo para probar.

$ django-admin.py startproject estaticos
$ cd estaticos/
$ python manage.py startapp ejemplo

Ahora bien, en vez de crear un directorio static y otro templates en el directorio principal, vamos a crear los siguientes:

templates_common
static_common

¿Por qué así? Dada la naturaleza de Django, lo interesante sería hacer que las aplicaciones de nuestro proyecto fuesen lo más independiente posibles. Por ejemplo, creo una web y añado una aplicación que sea un visor de Twitter. Estaría de puta madre si pudiera coger esa aplicación tal cual y pegarla en mi proyecto de blog y colocar dicho visor en la barra lateral.

Para lograr este resultado, entre otras cosas, la aplicación deberá contener sus propios ficheros estáticos y sus propios templates, así que tendremos un directorio para los ficheros estáticos comunes de todo el proyecto y otro para los templates comunes.

Luego cada proyecto tendrá sus propios directorios también como veremos luego.

Vamos a darle un poco de amor al settings.py

Empezamos añadiendo una variable para definir la ruta actual del proyecto:

MANAGERS = ADMINS

CURRENT_PATH = os.path.dirname(__file__)

DATABASES = {

No os olvidéis de importar la librería os.

Acto seguido vamos a configurar tres variables (ya creadas de antemano):

STATIC_ROOT = os.path.join(CURRENT_PATH, 'static')

STATICFILES_DIRS = (
    os.path.join(CURRENT_PATH, 'static_common'),
)

TEMPLATE_DIRS = (
    os.path.join(CURRENT_PATH, 'templates_common'),
)

Esto lo explicaré cuando llegue el momento, por ahora creed en mi palabra

También tenemos que añadir nuestra aplicación al fichero:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
    'estaticos.ejemplo',
)

Bueno, ya está listo.

Vamos a crear un template que nos sirva de base para nuestra aplicación (/templates_common/base.html):




    
    Ejemplo de ficheros estáticos


    
        {% block content %}{% endblock %}

Ok, ya tenemos una página base. Vamos a darle algo de color y alegría con css.

Creamos un css (/static_common/css/styles.css):

body {
    background-color: #add8e6;
}

#wrapper {
    width: 960px;
    margin: 0 auto;
    background-color: #ffffff;
    padding: 10px;
}

Lo he creado dentro de un directorio llamado css para organizar mejor los ficheros estáticos. (para los javascript se suele crear uno llamado js).

Bueno, un css simplón.

Vamos a añadirlo a base.html:


    
    Ejemplo de ficheros estáticos
    
    {% block external %}{% endblock %}

Lo de {{ STATIC_URL }} lo explicaré mejor luego, pero básicamente es por si cambiamos la ruta de los ficheros estáticos, para no tener que ir fichero por fichero actualizando las rutas.

Aparte de eso hemos añadido un bloque nuevo. Lo usaremos por si nuestros otros templates necesitan importar sus cosas.

Como el html base y el css de este son cosas comunes de toda la aplicación, los crearemos en los directorios comunes.

Bueno, pues vamos a crear algo de contenido para nuestra aplicación.

Creamos las siguientes directorios:

/templates/ejemplo/
/static/ejemplo/

Los creamos dentro del directorio de nuestra aplicación ejemplo, o sea quedaría así:

~/ejemplo/templates/ejemplo/
~/ejemplo/static/ejemplo/

Aunque suene raro, hay que crear un directorio con el nombre de la aplicación dentro de los directorios static y templates. Luego esto tendrá mas sentido, de verdad.

Bueno, vamos a crear una vista, así que abrimos el views.py de nuestra aplicación y colocamos la siguiente vista:

from django.shortcuts import render_to_response
from django.template.context import RequestContext

def home(request):
    gente = ['Jesus', 'Rosi', 'Alvaro', 'Pol', 'Juan']
    return render_to_response('ejemplo/index.html', locals(), context_instance=RequestContext(request))

Bueno, creamos una lista y la enviamos al template. Nótese que he puesto ‘ejemplo/index.html’. Django ya sabe donde buscar el template (Luego verás el por qué).

Vamos a crear el template (ejemplo/templates/ejemplo/index.html):

{% extends "base.html" %}
{% block external %}
    
{% endblock %}
{% block content %}
    
        Estamos en la aplicación ejemplo
        
            {% for persona in gente %}
                {{ persona }}
            {% endfor %}
        
    
{% endblock %}

Bueno, creamos un div, y mostramos la lista. Además hemos hecho uso del bloque external para cargar un css más que será el css que diseñe nuestra aplicación ejemplo, así cuando movamos la aplicación a otro lado, se llevará los css con el.

Bueno, vamos a crear el css (ejemplo/static/ejemplo/css/styles.css):

#ejemplo {
    width: 500px;
    background-color: #cecece;
    border: 1px solid #030303;
    padding: 5px;
}

#ejemplo ul {
    list-style: none;
}

He creado un directorio llamado css dentro de /ejemplo/static/ejemplo/ como ya hicimos con static_common. Ya se que es un poco lio, pero todo tendrá sentido luego.

Finalmente vamos a modificar urls.py para que esto empiece a andar:

urlpatterns = patterns('',
    url(r'^$', 'ejemplo.views.home'),
)

Vale, vamos a ejecutar la aplicación y vamos a verla.

Uh, qué fea . Bueno, la idea no era la web en sí

Vale, la web funciona, ¿Cual era la idea pues de este post?

El desarrollo en Django es muy bonito, el servidor integrado que tiene hace muuuuuuucha magia, pero cuando desplegamos, la magia se va.

¿De qué magia hablo? Pues del primo de Harry Potter que suspendió la escuela de mágia y ahora se dedica a facilitarnos la vida. Venga no, ahora en serio.

El servidor integrado de Django nos simplifica mucho la vida, muchisimo. Es capaz de encontrar ficheros estáticos fácilmente. ¿Recuerdas STATICFILES_DIRS? Le dice a dicho servidor dónde buscar ficheros estáticos. ¿Recuerdas STATCFILES_FINDERS? Son clases que saben donde buscar más ficheros estáticos, por ejemplo:

‘django.contrib.staticfiles.finders.AppDirectoriesFinder’,

Con esa clase, el servidor busca en los directorios de nuestras aplicaciones para ver si hay más ficheros estáticos.

Con toda esta ayuda, sólo necesitamos arrancar la aplicación y ésta será capaz de encontrar todos los ficheros estáticos por si sola. Ahora bien, toda esa mágia desaparece en cuanto colocamos el DEBUG a False, así que … ¿Ahora qué? ¿Copiamos a mano todo a un directorio? Nah. ¿Recuerdas el parámetro que pusimos al principo de la aplicación?

STATIC_ROOT = os.path.join(CURRENT_PATH, 'static')

Y el ya por defecto:

STATIC_URL = '/static/'

El primero lo que dice es: El directorio de los ficheros estáticos estará en ~/static/ y el segundo no es útil para hacer referencia a dicho directorio en los templates (entre otros sitios) como ya hemos visto antes.

Vale, te sigo, pero… ¿Ese directorio donde está? El que tenemos se llama static_common y ese no es.

Ese directorio es donde pondremos TODOS los ficheros estáticos de nuestro proyecto. ¿A mano? ¿O a máquina?

A maquina a maquina…

Tenemos un comando que nos hace todo el trabajo:

python manage.py collectstatic

Ya está, en nuestro caso nos ha creado algo así:

static
----css
--------styles.css
----ejemplo
--------css
------------styles.css

¿Le veis ahora sentido a los directorios raros? Ahora tenemos un directorio static y está super bien organizado, los estáticos comunes en el directorio principal y los de cada aplicación en su propio directorio.

Simplemente tenemos que decirle a nuestro servidor (Cherokee por ejemplo) que nos sirva ese directorio.

Todo esto es importante también si usais el módulo de admin, puesto que el servidor integrado también encuentra automágicamente los css del admin pero una vez depleguemos pues no estarán. Así que ejecutando collectstatic también copiará a static los css del admin.

Os dejo el source del proyecto por si estáis flojos: Ejemplo.

Si no estáis flojos, dejad un comentario ya de paso

Reseña: Beginning Django E-Commerce

Fox — Sun, 13 Nov 2011 13:17:45 +0000

Vamos con la primera reseña del blog.

Para los que conozcan mi otro blog, me gusta reseñar las cosas que voy leyendo.

Este caso es un poco más especial, porque no he podido terminarlo, ya veréis por qué.

El libro en cuestión es:

Beginning Django E-Commerce

Este libro hace 2 cosas, una muy bien y una bastante regular.

Nos introduce al mundo del E-Commerce y lo hace muy cojonudamente, sin embargo, aunque se supone que es un libro de introducción a Django, esto no lo hace taan bien.

Django tiene una documentación oficial al nivel de MSDN de Microsoft. Es buena a rabiar y encontrarás de todo. El “problema” que tiene la documentación, es que es una referencia, y dejando de lado el pequeño tutorial que tiene (que es muy bueno, pero escaso) pues necesitamos de algún libro para aprender. Al menos yo.

El problema (y esta vez sin comillas) es que hubo un bum de libros hace un tiempo y ahí se quedó la cosa.

Mientras escribo esto, Django va por la versión 1.3 y el libro más moderno se basa en la versión 1.2 (Aunque las malas lenguas dicen que no es 1.2 ni de cerca).

Django es un lenguaje muy vivo y los desarrolladores suelen meter muchas mejoras con las nuevas versiones y cambios. A veces rompen cosas (por un bien mayor) y esto supone que los libros más viejos explican cosas que ya no funcionan de la misma forma.

Este libro está basado en la versión 1.1 de Django lo cual tiene ciertas cosas que ya se hacen de la misma forma y nos hará darle 20 vueltas al asunto hasta que nos demos cuenta que está deprecated o bien modificado en la versión 1.3.

La leyenda cuenta de que existe una página de erratas con toodo documentado, pero es sólo eso, una leyenda. Bueno, al parecer Apress borró todas las erratas y el autor no las guardaba, así que estás solo ante el peligro…

¡Y que peligro! Dejando de lado las cosas que en la versión 1.3 se hacen de otra forma, tiene el mayor numero de typos que he visto en mi vida, y he leido muchos libros. Te vas a estar dando cabezazos contra el teclado cada dos por tres. No sé, en el primer tema te pone una entrada para urls.py y luego en otro snippet ves que la ha puesto de otra forma y tu… ¿Por qué lo ha cambiado? Buena pregunta, estaba mal.

Tiene fallos, fallos, fallos, muchos fallos, errores muy muy tontos que te hacen mirar y remirar el código por si lo has copiado mal, te hacen mirar google por si es algo deprecated pero no, finalmente es un typo como una catedral.

Avanzar por este libro es a veces desesperante porque intentas ejecutar tu aplicación y ves que tienes errores y tienes que buscarte la vida para solucionarlos.

Dejando de lado sus fallos, tiene otro gran problema. No explica.

¿Un libro que no explica? Pues sí, toda una sorpresa. Es curioso, lo relacionado con E-Commerce lo explica muy muy bien, pero todo lo relacionado con Django pues no lo hace.

No es que lance líneas de código sin decir nada, solo es que sus explicaciones son muy simples, te cuenta tres o cuatro cosas sobre esa función y ya está, te quedas a medias.

Te puede hacer escribir un algoritmo de búsqueda o uno para encontrar productos recomendados. Escribir 200 lineas de código y quedarte perdido. Apenas te explica nada y yo he llegado al momento donde escribía código sin saber el por qué y llegado a ese momento, he cerrado el libro y me he dedicado a otra cosa.

De nada vale leer si tus conocimientos no avanzan con el libro, es estúpido y punto.

Por otro lado, por simplificar (vamos a pensar bien), muchas de sus implementaciones son malísimas, código ignora cualquier principio de programación.

Bueno, no todo es malo en este libro. Tiene cosas muy muy buenas.

Explica muuuy bien todo lo relacionado con E-Commerce.

Te explica como montarte un sistema de checkout usando Google checkout, usando tu propio carrito de la compra y pasandoselo a Google Checkout en XML. No sólo te explica como hacerlo, también te explica el por qué deberías de hacerlo para una tienda nueva. Aquí si que va paso a paso desde registrarte en Google Checkout (Usando la sandbox, claro está) hasta poder hacer pedidos en tu tienda y verlos en la web de Google Checkout.

También explica como montarte tu propio sistema de checkout usando Authorize.net como pasarela de pago. También te explica perfectamente como montarlo todo para hacerlo funcionar en tu aplicación. Te enseña algoritmos para comprobar tarjetas de créditos y cosas por el estilo.

Cosas para el E-Commerce las explica muy bien, pero el resto pues no tanto.

Positivo

Todo el tema relacionado con E-Commerce es brillante.
La introduccion a Django, dejado de lado los typos, es buena.

Negativo

Libro desactualizado, tiene muchas cosas deprecated
El editor no hizo un buen trabajo, tiene MUCHOS typos
Muchas de las cosas que hacen tienen una explicación bastante deficiente
El código es muy muy mejorable, y bajo mi opinión, no le costaba mucho mejorarlo

Mi nota final es de 4. Así que vuelva en septiembre, quiero decir, necesitamos una nueva edición quitando todo lo malo.

Entendiendo virtualenv y pip

Fox — Sun, 06 Nov 2011 17:14:21 +0000

Vamos a hablar de estos dos maravillosos paquetes de Python.

¿Qué es pip y qué es virtualenv?

Empezaremos hablando de pip.

pip

pip es un gestor de paquetes de Python, como los gestores que hay para Linux tipo apt-get, pacman, etc.

Para aquellos que esten pensando… ¿No es lo mismo que easy_install? Bueno, pip es su evolución.

Con pip podemos buscar, instalar, actualizar y desinstalar paquetes.

Vale, en mi sistema no está… ¿Cómo lo instalo?

Tenemos varias maneras, si ya tenemos el comando easy_install podemos hacer un:

$ sudo easy_install pip

Siempre podéis tirar de vuestro gestor de paquete de vuestra distro:

$ sudo apt-get install python-pip
$ sudo pacman -S python2-pip

para Ubuntu / Archlinux respectivamente.

Si usais windows y no tenéis easy_install podéis bajar este script y ejecutarlo de la siguiente forma (usando cmd):

python ez_setup.py

Y ya proceder con la instalación igual que en Linux (Obviamente ignorando el $ pues es solo para indicar que estamos en la consola )

Ahora que está instalado, veremos que su uso es muy facilito, con un simple:

$ sudo pip install django

en Linux y:

pip install django

en Windows.

Con eso instalaríamos Django en nuestro sistema.

En concreto, su uso básico (permite hacer cosas más complejas como instalar desde un fichero local o de un sistema de control de versiones) se reduce a:

$ sudo pip search django
$ sudo pip install django
$ sudo pip install --upgrade django
$ sudo pip uninstall django

En el cual, buscaríamos, instalaríamos, actualizaríamos y borraríamos un paquete respectivamente.

Como veis, el uso de pip es bastante sencillo.

Si queréis más información podéis acudir a su documentación oficial que es bastante sencillita de entender.

Si queréis, también podéis consultar via web la lista de paquetes con los que pip trabaja, o sea, en la página de PyPi.

virtualenv

¿Qué es virtualenv y por qué no paran de hablar del el?

Tengo por costumbre dar razones del por qué antes de decir el qué.

Vamos a poner un supuesto caso:

Tenemos nuestro Cherokee funcionando con dos aplicaciones Django a pleno rendimiento y estamos trabajando en nuestra tercera aplicación y vemos un anuncio:

¡Nueva beta de la próxima release de Django y tu… mola, voy a ver los cambios… Viendo esos cambios resulta que ponen algo nuevo que te vendría fenomenal para tu nueva aplicación y decides pues instalar dicha beta y hacer uso de esas cosas nuevas.

Terminas la aplicación, la montas en su servidor y actualizas el Django que tienes ahí instalado para instalar la beta. Pruebas tu nueva aplicación y de fábula pero luego te pones a usar las otras dos que tienes y plaf, revienta.

Te das cuenta que la nueva versión ha roto algo que esa aplicación usa o bien al ser una beta pues tiene un hermoso bug. ¿Ahora qué? Estás en una dificil situación.

O bien vuelves a poner la versión antigua de Django haciendo que tu nueva aplicación no funcione, o bien adaptas la nueva aplicación para la versión antigua o intentas adaptar las viejas a la nueva versión (y si tiene bugs pues va a ser que no).

¿Es un poco putada, no?

Si, la verdad es que sí, por eso los chicos de Django han pensado en una perfecta solución: virtualenv.

¿Qué es virtualenv? virtualenv es un sandbox, vale, parezco la RAE cuando le pides la definición de algo y te da una respuesta que necesita otra definición y así sucesivamente

Un sandbox es un mecanismo de seguridad que se usa para ejecutar programas de forma aislada. Suena un poco raro, así que vamos a “pythonear” esa definición.

virtualenv es un paquete que nos sirve para tener una instalación virtual de Python, o sea, virtualenv es un entorno virtual de Python en el cual tendremos nuestro propio interprete y las librerías que nosotros queramos.

¿Qué significa esto? Pues que para nuestro caso de antes, podemos tener un virtualenv con esa versión beta de Django y hacer que nuestra nueva aplicación use dicho virtualenv y que las otras pues sigan como estaban.

Así que virtualenv nos sirve para tener entornos separados de Python con su conjunto de librerías, y así poder usar nuestras aplicaciones Django con el virtualenv que queramos, sin riesgo de fastidiar a ninguna otra aplicación aunque usemos librerías de dudosa estabilidad

¿Estamos ya emocionados? Pues vamos a instalarlo:

pip install virtualenv

Vemos qué bien nos viene pip

Bueno, esto nos instalará virtualenv como ya hemos deducido y además vendrá con pip instalado también.

Bueno, ¿Cómo lo usamos?

En linux es tan facil como hacer:

$ virtualenv --no-site-packages --distribute prueba
$ cd prueba
$ source bin/activate

Y en windows:

virtualenv --no-site-packages --distribute prueba
cd prueba
cmd.exe /K Scripts\activate.bat

En windows es algo más lioso, pero lo solucionaremos como veremos más adelante.

Con esto creamos un entorno virtual con el nombre prueba, y luego lo activamos.

–no-site-packages sirve para que al crear el nuevo entorno virtual, no se le de acceso a dicho entorno virtual a los paquetes instalados en nuestra instalación normal, o sea, si ya teniamos Django instalados en nuestro Python, no tendremos acceso a el en el virtualenv. Tendríamos que instarlo de nuevo (es la idea).

–distribute es para usar Distribute en vez de Setuptools

Con esto, esa terminal trabajará usando ese virtualenv así que todo lo que hagamos en ella será usando dicho virtualenv. Por ejemplo podemos hacer:

(prueba) $ pip install django

Y esto nos instalará Django en dicho virtualenv.

Si queremos ejecutar nuestra aplicación Django haremos:

(prueba) $ python manage.py runserver

Así nuestro servidor usará nuestro virtualenv prueba para funcionar.

Lo BUENO de virtualenv es que nuestros proyectos y los entornos virtuales NO están vinculados entre ellos, lo que quiere decir que podemos correr nuestra aplicación en una variedad de virtualenv sin tener que modificar nada en nuestra aplicación. Así podremos probar distintas versiones de librerías para ver como nos funcionan y si alguna combinación nos da problemas, simplemente tendremos que borrar el virtualenv y nadie ha visto nada

Usando virtualenv en Cherokee

Bueno, queremos usar también virtualenv en Cherokee, ¿no?

Hay múltiples maneras de hacerlo, pero la más sencilla es editando el fichero uwsgi.xml que tenemos junto a nuestra aplicación, así que por ejemplo, para nuestra aplicación tutocherokee e imaginando que tenemos el virtualenv en /home/web/virtualenvs/prueba/ el fichero quedaría así:


    /srv/http/tutocherokee/
    /srv/http/
	/home/web/virtualenvs/prueba/

La única diferencia ahora es que especificamos la ruta de nuestro virtualenv.

Obviamente tienes que tener un virtualenv instalado y configurado de antemano.

Ya está, nuestra aplicación tutocherokee usará nuestro virtualenv creado para la ocasión.

Helpers de virtualenv para Windows y Linux

Podemos hacer que nuestra vida con virtualenv sea más sencilla de lo que ya es.

Empezaremos con windows:

Bajamos env.py y lo metemos en el directorio script de nuestra instalación python (por ejemplo: C:\Python27\Scripts).

Si ya habéis estado usando Django bajo Windows sabréis que dicha ruta tiene que estar en el PATH de Windows para funcionar.

Vale, env.py es un script que nos ayudará a manejar virtualenv en Windows.

Para empezar lo editamos y colocamos la ruta donde queremos instalar nuestros virtualenv:

DEFAULT_DIR_PATH = "C:\\Django\\virtualenvs\\"

Una vez hecho, simplemente tenemos que usarlo:

env.py -c prueba
env.py prueba
env.py -l
env.py -r prueba

El primero crea un entorno virtual llamado prueba y lo activa, el segundo activa el entorno (que ya debe estar creado), el tercero lista todos los que tenemos y el último borra un entorno.

No necesitamos estar en ningún directorio concreto para usar el script ya que el directorio de trabajo de este, está definido en el script.

Ahora bien, y por cortesía de Juan Riaza (quien me enseñó a usarlo) tenemos virtualenvwrapper, un helper para Linux.

Primero lo instalamos como ya sabemos hacer:

$ sudo pip install virtualenvwrapper

Creamos un directorio para nuestros entornos, por ejemplo:

$ mkdir ~/.virtualenvs

Configuramos el fichero .bashrc:

$ vim ~/.bashrc

Y añadimos:

export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

Tenemos que ver si pip copió virtualenvwrapper.sh en esa ruta, pues en archlinux está en /usr/bin/virtualenvwrapper.sh

Otra cosa a tener en cuenta, es que si usarmos Archlinux, y Python 2, nuestro ejecutable será python2 y no python así que tenemos que:

Abrir virtualenvwrapper.sh:

$ sudo vim /usr/bin/virtualenvwrapper.sh

y buscamos estas líneas y las editamos así:

# Locate the global Python where virtualenvwrapper is installed.
if [ "$VIRTUALENVWRAPPER_PYTHON" = "" ]
then
    VIRTUALENVWRAPPER_PYTHON="$(\which python2)"
fi

Vale, ya tenemos virtualenvwrapper configurado, así que o bien reabrimos el terminal o hacemos:

$ source ~/.bashrc

El uso de virtualenvwrapper es muy sencillo:

$ mkvirtualenv prueba
$ workon prueba
$ deactivate
$ rmvirtualenv prueba

El primero crea el entorno virtual, el segundo lo activa, el tercero lo desactiva y el último lo borra.

Con esto terminamos ya el tema.

Hasta otra

Desplegando nuestra primera aplicación Django en Cherokee

Fox — Tue, 01 Nov 2011 14:43:07 +0000

Para empezar con este blog, vamos a explicar como desplegar nuestra primera aplicación Django en Cherokee con uWSGI.

Vamos a partir desde cero, así que vamos a empezar instalando las distintas cosas.

Instalación de Cherokee y uWSGI

Voy a especificar los pasos para instalar Cherokee y uWSGI en ArchLinux que es la distro que yo uso. Aún así no debería ser muy diferente en Ubuntu por ejemplo.

$ sudo pacman -S cherokee

Con esto tendremos Cherokee.

Para uWSGI tendremos que tirar de AUR, pero no lo hace mucho más complicado:

$ wget https://aur.archlinux.org/packages/uw/uwsgi/uwsgi.tar.gz
$ tar zxvf uwsgi.tar.gz
$ cd uwsgi
$ makepkg
$ sudo pacman -U uwsgi-0.9.9.2-1-i686.pkg.tar.xz

Si os pide alguna dependencia en el makepkg pues se la instalais y santas pascuas. Y como ya habréis imaginado, la versión del paquete puede cambiar cuando leáis esto.

Con esto ya tendríamos lo necesario para empezar.

Configuración de directorios y permisos

Esta es la parte más controvertida del artículo pues cada uno lo hace a su forma y bueno, esta es la mía, puede no ser perfecta ni 100% segura (que no lo sé, la verdad) pero es un buen punto de partida.

Cherokee por defecto funciona usando el user http y el grupo http. Esto significa que los directorios donde tengamos nuestras aplicaciones van a tener que estar bajo este usuario y grupo, o por lo contrario Cherokee no podrá ejecutar dichas aplicaciones y mucho menos, escribir en esos directorios.

Por lo personal, considero que es una buena idea crear un nuevo grupo donde agregaremos a http y en un futuro, a otros usuarios que podamos considerar necesarios para la web (como ftp para subir las cosas aquí).

Vamos a ello:

$ sudo groupadd webgroup
$ sudo usermod -a -G webgroup http

Vale, tenemos nuestro grupo y nuestro usuario. Ahora vamos con los permisos.

$ sudo chown -R http:webgroup /srv/http
$ sudo chmod -R 775 /srv/http

Guay, ya tenemos los permisos puestos para nuestro directorio donde alojaremos nuestras webs.

NOTA: En muchas otras distros, este directorio se llama /var/www/

Bien, lo último que nos queda es decirle a Cherokee que use es grupo.

$ sudo cherokee-admin -b -u

Con esto ejecutaremos el administrador de cherokee.

Con -b hará que el admin pueda ser usado desde fuera de esa red (por si tenemos el servidor en un VPS y queremos acceder al admin desde nuestro pc)
Con -u hará que no nos pida contraseña al entrar (cuidado, pues todo el mundo podría entrar en nuestra config en ese momento)

Bueno, ahora accedemos al admin usando o bien localhost:9090 si lo tenemos en local o ip/dominio:9090 si es remoto.

Una vez en el admin, nos vamos a General -> Permisos y configuramos el nuevo usuario y grupo:

Vale. Le damos a guardar y ya está.

Nuestra aplicación Django

Bueno, vamos a crear un bonito Hello World en Django pues realmente no necesitamos más para este tutorial.

$ django-admin.py startproject tutocherokee
$ cd tutocherokee
$ python manage.py startapp helloworld
$ mkdir static && mkdir -p templates/helloworld

Vale, ya tenemos nuestro proyecto con su aplicación y el directorio para ficheros estáticos y para los templates.

Vamos a empezar configurando el fichero settings.py:

CURRENT_PATH = os.path.abspath(os.path.dirname(__file__).decode('utf-8')).replace('\\', '/')

No os olvideis de hacer un

import os

al principio del fichero.

Como los directorios pueden (y van) a cambiar de nuestra maquina al servidor, pues con esta linea obtendremos la ruta actual correcta estemos donde estemos.

Ahora le diremos donde tenemos nuestro directorio de fichero estáticos:

STATICFILES_DIRS = (
    # Put strings here, like "/home/html/static" or "C:/www/django/static".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
    os.path.join(CURRENT_PATH, 'static'),
)

También el de templates:

TEMPLATE_DIRS = (
    # Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
    os.path.join(CURRENT_PATH, 'templates'),
)

Ambos usan el método join para crear una ruta absoluta de nuestro proyecto y esos directorios.

NOTA: No olvidéis la coma al final, es importante.

Por último en el fichero settings.py, vamos a añadir nuestra aplicación:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'tutocherokee.helloworld',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
)

De nuevo, la comita al final.

Vale, vamos a empezar a con nuestra aplicación:

Abrimos el views.py de nuestra aplicación helloworld y añadimos el siguiente código:

from django.shortcuts import render_to_response
from django.template.context import RequestContext

def home(request):
    nombre = "PyBlog"
    return render_to_response("helloworld/index.html", locals(), context_instance=RequestContext(request))

Estamos creando una nueva función llamada home la cual abrirá un .html (que todavía no hemos creado) pasándole el nombre de este blog.

Vamos a crear el index.html dentro del directorio templates/helloworld:




    
    Hola Mundo


    Hola, {{ nombre }}

Y ahora vamos a configurar el fichero urls.py del proyecto añadiendo una nueva url dentro de urlpatterns:

urlpatterns = patterns('',
    url(r'^$', 'helloworld.views.home'),
)

Lanzamos el servidor:

$ python manage.py runserver

Abrimos la url en nuestro navegador…

Anda, perfecto.

Ahora vamos a añadirle un css

Creamos un fichero llamado styles.css en el directorio static

body {
    background-color: lightblue;
}

Y ahora añadimos el css a nuestro index.html:


    
    
    Hola Mundo

relanzamos el servidor y…:

Vale, ya tenemos nuestra aplicación lista.

Desplegar nuestra aplicación Django a Cherokee

Antes de subir nuestra aplicación al servidor, tenemos que hacer algunos cambios al settings.py aunque en este caso, por ser una aplicación tan básica sólo tendremos que cambiar:

DEBUG = True

por:

DEBUG = False

Hecho. Ahora tenemos que crear un par de ficheros para que uWSGI funcione con nuestra aplicación.

Vamos a crear un fichero en el directorio tutocherokee llamado django_wsgi.py con este código:

import os
import django.core.handlers.wsgi

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
application = django.core.handlers.wsgi.WSGIHandler()

Luego vamos a crear otro en el mismo directorio llamado uwsgi.xml con esto:


    /srv/http/tutocherokee/
    /srv/http/

Necesitamos estos dos ficheros en cada aplicación que vayamos a desplegar a cherokee.

El primero contendrá siempre lo mismo y no necesitaréis tocarlo nunca.

El segundo, contiene 2 rutas. La primera es la ruta absoluta de nuestro proyecto y la segunda la ruta absoluta donde se encuentra dicho proyecto.

El resto no hay que tocarlo, siempre y cuando tengamos estos dos ficheros en el directorio principal del proyecto.

Vale, ahora tenemos que mover el directorio tutocherokee a nuestro directorio del servidor (/var/www o /srv/http si estais en Arch).

Vale, ya tenemos (en mi caso):

/srv/http/tutocherokee

Vamos a darle permisos:

$ sudo chown -R http:webgroup /srv/http/tutocherokee
$ sudo chmod -R 775 /srv/http/tutocherokee

Ya tenemos todo listo. Ahora solo nos queda crear un servidor virtual en Cherokee.

Vamos al admin de Cherokee como ya sabemos hacer y le damos arriba a vServers:

Y luego añadimos un nuevo Servidor Vitual

En la ventana que nos saldrá elegimos Plataformas -> uWSGI:

Y nos va a pedir el fichero de configuración de uWSGI AKA el fichero uwsgi.xml:

Y por último nos va a pedir el nombre del servidor, el cual le damos lo que queramos, la ruta donde tenemos la aplicación y si queremos configurar logs:

Vale, ya tenemos nuestro servidor virtual:

Antes de poder verlo en acción tenemos que dar un último paso.

¿Cómo sabe Cherokee que tu quieres acceder a esa aplicación?

Se lo tenemos que decir, ¿Cómo? Dentro de nuestro nuevo servidor virtual nos vamos a Evaluación del host y lo configuramos de la siguiente manera:

Aquí lo que hacemos es decirle que para acceder a nuestra aplicación lo haga a través de tutocherokee.foxexperiments.com.

Ya solo tenemos que hacer click en Guardar -> Reinicio suave arriba a la derecha.

Ejecutamos nuestra aplicación y…

¿Funciona? Sí, hemos entrado en nuestra aplicación pero… ¿Y mi fondito azul?

Para desplegar una aplicación Django necesitamos hacer 2 cosas:

a) Usar un servidor para desplegar nuestra aplicación. En nuestro caso estamos usando uWSGI
b) Usar otro servidor para desplegar nuestro contenido estático. Por ejemplo Cherokee.

Vale, lo primero está hecho, pero no le hemos dicho a Cherokee que haga nada con dicho contenido estático.

Lo solucionamos rápido.

Nos vamos a nuestro servidor virtual y a la pestaña Comportamiento y hacemos click en Gestión de reglas

Y creamos un nuevo comportamiento:

Lo configuramos de la siguiente forma:

En Directorio Web aparce / por defecto, el cual señala el directorio principal de nuestro proyecto. Como directorio static está en dicho directorio principal, solo tendremos que poner su ruta relativa a dicho directorio, o sea, /static.

Lo añadimos, vamos a la pestaña Gestor de dicho comportamiento y lo dejamos así:

Solo es cambiar el Gestor por Listar y enviar.

Ahora guardamos como siempre y probamos nuestra aplicación:

Voilà, se hizo la magia.

De hecho podéis comprobarlo en:

tutocherokee.foxexperiments.com.

Y nada más, solo mis agradecimientos a mi amigo Pol Cámara que tuvo la paciencia de enseñarme a mi esto que os enseño hoy.

¡Hola Mundo!

Fox — Tue, 01 Nov 2011 14:01:39 +0000

¡Hola a todos!

Bienvenidos a mi blog de Django.

Yo soy Jesús y soy programador tanto de .NET como de Django.

Acabo de empezar el aprendizaje de Django y tengo como costumbre enseñar todo lo que voy aprendiendo por el camino.

Así que lo que podéis esperar de este blog son artículos relacionados con Django y todo lo que se mueve alrededor de éste. Así que también veréis artículos sobre HTML, CSS, Javascript / jQuery, Python, reseñas de libros, etc.

Obviamente al estar empezando en Django hará que mis artículos puedan no ser lo más correctos que podáis encontrar, pero haré que sean lo mejor posible.

Mis artículos suelen ser bastante largos, pero eso hace que sean lo más detallados posibles, lo cual es bueno para aquel que está aprendiendo.

Y nada más, conforme vaya aprendiendo cosas interesantes las iré explayando aquí.

Un saludo.