Django Utilidades :: Marinho Brandao

Aprendendo Django no Planeta Terra

Acabo de colocar no ar o site Aprendendo Django no Planeta Terra [1].

Quem tem me acompanhado com uma certa regularidade sabe que eu valorizo muito a imagem, mas tenho evoluído nesse sentido.

Após mais de 2 anos usando o Django em projetos profissionais e brincadeiras pessoas, e participando da comunidade brasileira, especialmente, uma coisa se tornou muito clara pra mim: é preciso dar um passo mais ousado.

Eu cheguei a escrever um livro quase completo há 1 ano atrás e não gostei do resultado. Alguns amigos apontaram o que eu já sentia: o conteúdo estava burocrático e pesado, e precisava de um certo pragmatismo (obrigado Andrews).

Então, este é um livro eletrônico voltado para o iniciante. São capítulos curtos, liberados quase que diariamente, bem ilustrados e com uma linguagem que segue a história de um alienígena, me inspirando na série do Guia do Mochileiro das Galáxias.

É a história de um alienígena e seus dois amigos terráqueos, que estão aprendendo Django e se divertindo muito com isso. À medida que a história se desenrola, o framework é desmistificado e a pessoa vai aprendendo como resolver problemas e fazer boas sacadas no seu dia-a-dia.

Sou muito grato ao Luciano Ramalho [3], Guilherme Semente [4] e Felippe Nardi pelas dicas, ao João Matheus por suas ilustrações e ao Miltinho Brandão [2] pelas idéias, ouvido e amizade de sempre. E claro, não somente eles, todo o restante da comunidade brasileira [5], da World News Network [6] e dos desenvolvedores do Django Project [7].

Links relacionados

[1]	http://www.aprendendodjango.com/

[2]	http://miltonweb.wordpress.com/

[3]	http://ramalho.org/

[4]	http://semente.taurinus.org/

[5]	http://www.djangobrasil.org/

[6]	http://wnnetworks.com/

[7]	http://www.djangoproject.com/

Django-plus: para que serve? (parte 2)

Template Filters de comparação

Continuando a explanação sobre os recursos disponíveis no django-plus [1], eu gostaria somente de esclarecer um pouco mais sobre as template filters que disponibilizei no artigo anterior [2].

Vamos tomar a template filter is_equal como melhor exemplo.

O sistema de templates do Django disponibiliza apenas um meio para se fazer comparativo de igualdade, assim:

{% ifequal user.username 'marinho' %}
    exibe ou faz alguma coisa
{% endifequal %}

Notou a limitação? Não? Imagine que você precise colocar ali um simples AND, ou um OR. Não é possível ou no máximo é doloroso. Mas com a template tag {% if %} é possível, portanto, será nesse momento que você fará uso da template filter is_equal, assim:

{% load djangoplus_tags %}

{% if user.username|is_equal:'marinho' and user.is_staff %}
    exibe ou faz alguma coisa
{% endif %}

Compreendeu? Agora siga a mesma linha de raciocínio para as template filters is_not_equal (diferente), is_lt (menor que), is_lte (menor ou igual), is_gt (maior que), is_gte (maior ou igual) e in_list (na lista).

Agora, com as coisas esclarecidas, vamos adiante.

Model Info

Hoje vamos falar especificamente do pacote de funcionalidades model_info. Para que ele serve?

Bom, quando você quer criar um admin para uma classe de modelo, como você faz? Assim:

class AdminPessoa(ModelAdmin):
    fields = ('nome','idade',)

admin.site.register(Pessoa, AdminPessoa)

Simples né? Sim, muito. E para formulários de inclusão/alteração? Assim:

class FormPessoa(ModelForm):
    class Meta:
        model = Pessoa

Sim, isso é suficiente para seu formulário funcionar bem para a classe de model. Simples assim.

Agora, e quando você precisa listar os registros de uma queryset ou exibir as informações de um deles?

Bom, aí é aquela coisa: você vai carregar o objeto ou a lista de objetos e vai tratar campo por campo no template. Quando for necessário mais de uma vez, você vai criar um template e incluí-lo nos demais, para evitar repetição de código. Para quem se acostumou com as mágicas acima, esse processo é doloroso ou no mínimo entediante.

Então, para isso servem as classes e template tags do Model Info do django-plus.

Vamos a um exemplo de exibição de dados de um objeto de uma classe Pessoa:

views.py

from django.shortcuts import get_object_or_404, render_to_response
from models import Pessoa

def detalhes_da_pessoa(request, pessoa_id):
    pessoa = get_object_or_404(Pessoa, id=pessoa_id)
    return render_to_response('detalhes_da_pessoa.html', locals())

info.py

from djangoplus.model_info import ModelInfo
from models import Pessoa

class InfoPessoa(ModelInfo):
    class Meta:
        model = Pessoa

detalhes_da_pessoa.html (template)

{% load djangoplus_tags %}

<table class="info">
    {% model_info_for_object 'minha_aplicacao.info.InfoPessoa' pessoa %}
</table>

Absurdamente simples, não? Neste caso, não importa se sua classe Pessoa possua 2 ou 50 campos, eles serão todos (à exceção de ManyToManyField) listados comportadamente na tabela informada e funcionará bem.

Vamos fazer uma listagem? Ok, vamos lá:

views.py (acrescente as linhas ao fim do arquivo)

def lista_de_pessoas(request):
    pessoas = Pessoa.objects.all()
    return render_to_response('lista_de_pessoas.html', locals())

info.py (acrescente as linhas ao fim do arquivo)

from djangoplus.model_info import ModelList

class ListPessoa(ModelList):
    class Meta:
        model = Pessoa

lista_de_pessoas.html (template)

{% load djangoplus_tags %}

<table class="list">
    {% model_info_for_list 'minha_aplicacao.info.ListPessoa' pessoas %}
</table>

Da mesma forma, será exibida uma lista dos objetos da queryset pessoas, e se a classe Pessoa possuir o método get_absolute_url declarado, serão exibidos também ícones para edição e exclusão, seguindo as convenções comuns "{{ objeto.get_absolute_url }}edit/" e "{{ objeto.get_absolute_url }}delete/", respectivamente.

Mas é só isso? Para funcionar o básico, sim, mas aquela subclasse "Meta" permite diversas outras formas de customização.

Vamos falar primeiramente da classe ModelInfo:

fields - lista dos campos a serem exibidos;
exclude - lista dos campos a não serem exibidos (não é muito inteligente usar o fields e o exclude ao mesmo tempo);
show_if_none - informe True ou False para mostrar campos com valor None ou não;
show_if_empty - informe True ou False para mostrar campos com valor vazio ou não;
auto_urlize - informe True ou False para transformar URLs em links;
auto_linebreaks - informe True ou False para mostrar quebras de linha em campos do tipo TextField;
list_display_links - lista dos campos que serão exibidos como link para a página do objeto (raramente usada);
fieldsets - lista de fieldsets. Segue o mesmo padrão do fieldsets do Admin;
row_template (default: '<tr><th>%s</th><td>%s</td></tr>') - permite que você informe o formato para exibir cada campo e seu referido valor;
fieldset_title_template (default: '<h3>%s</h3>') - permite que você informe o formato para exibir o título da fieldset;
show_fieldset_title - informe True ou False para exibir os títulos de fieldsets ou não;

Bacana não? Agora vamos para a classe ModelList:

fields - lista dos campos a serem exibidos;
exclude - lista dos campos a não serem exibidos (não é muito inteligente usar o fields e o exclude ao mesmo tempo;
show_if_none - informe True ou False para mostrar campos com valor None ou não;
show_if_empty - informe True ou False para mostrar campos com valor vazio ou não;
auto_urlize - informe True ou False para transformar URLs em links;
auto_linebreaks - informe True ou False para mostrar quebras de linha em campos do tipo TextField;
list_display_links - lista dos campos que serão exibidos como link para a página do objeto (raramente usada);
td_template (default: '<td>%s</td>') - formato para exibir cada célula da tabela;
th_template (default: '<th>%s</th>') - formato para exibir cada célula do cabeçalho da tabela;
tr_template (default: '<tr>%s</tr>') - formato para exibir cada linha da tabela;
thead_template (default: '<thead><tr>%s</tr></thead>') - formato para exibir o cabeçalho da tabela;
tbody_template (default: '<tbody>%s</tbody>') - formato para exibir o corpo de dados da tabela;
icon_edit_template (default: '<a href="%(edit_url)s" title="Edit this"><img src="%(media_url)simg/admin/icon_changelink.gif" alt="Edit"/></a>') - formato para exibir o ícone de edição (informe vazio para não ser exibido);
icon_delete_template (default: '<a href="%(delete_url)s" title="Delete this"><img src="%(media_url)simg/admin/icon_deletelink.gif" alt="Edit"/></a>') - formato para exibir o ícone de exclusão (informe vazio para não ser exibido);
group_template (default: '<tr><td colspan="%(cols)s" class="group"><h3>%(display)s</h3></td></tr>') - formato para agrupamentos;
groups - lista dos campos pelos quais os registros serão agrupados;

Ufa! Mais poderoso e flexível do que pensava, não? Mas ainda tem mais.

Tanto na classe ModelInfo quanto na ModelList, é possível informar métodos seguindo as sintaxes e regras abaixo:

get_CAMPO_display(self, f_name) - retorna um título customizado para o campo em questão;
get_CAMPO_value(self, f_name, instance) - retorna um valor customizado e/ou tratado para o campo em questão. Isso lhe permite declarar campos calculados ou que são parte de uma instância diferente da instância que está sendo carregada. O campo em questão deve ser informado no atributo "fields" da subclasse META ou ao menos ser parte da classe e não estar no atributo "exclude";
render_buttons_cell(self, instance, edit_url=None, delete_url=None) - caso sobrecarregue este campo, é possível mudar o padrão das URLs de edição e exclusão do objeto;

Por fim, a classe ModelInfo permite que também ser declarada diretamente na view e ser chamada para cada campo solitariamente, assim:

views.py

from django.shortcuts import get_object_or_404, render_to_response
from models import Pessoa
from info import InfoPessoa

def detalhes_da_pessoa(request, pessoa_id):
    pessoa = get_object_or_404(Pessoa, id=pessoa_id)
    info_pessoa = InfoPessoa(pessoa)
    return render_to_response('detalhes_da_pessoa.html', locals())

detalhes_da_pessoa.html (template)

{% load djangoplus_tags %}
{{ info_pessoa.nome }}

Gostou? E algo semelhante pode ser feito com a classe ModelList, que é iterável:

views.py (acrescente as linhas ao fim do arquivo)

from info import ListPessoa

def lista_de_pessoas(request):
    pessoas = Pessoa.objects.all()
    lista_pessoas = ListPessoa(pessoas)

    return render_to_response('lista_de_pessoas.html', locals())

lista_de_pessoas.html (template)

{% load djangoplus_tags %}

<table class="list">
    {% for pessoa in lista_pessoas %}
    <tr><td>{{ pessoa }}</td></tr>
    {% endfor %}
</table>

Bom, é isso aí, espero que ajude. Eu ganho um bom temp usando esses recursos, acho que podem ser úteis para você também ;)

Links relacionados

Django-plus: para que serve?

O django-plus foi uma biblioteca criada com o propósito de oferecer alguns recursos - criados por mim ou não, os códigos contidos nele que não são meus, recebem as devidas indicações ao autor - úteis que não faziam parte do core do Django.

Porque isso? Porque o Django possui uma política de coesão que evita que ele vire um cara gordão cheio de coisas, mas que existem coisas que realmente ajudam bastante em certas tarefas, mas que não justificam a criação de uma aplicação plugável.

Para adicionar a django-plus a seu projeto, você precisa fazer o download em [2] ou ainda em [6] e adicionar ao projeto como uma aplicação qualquer.

Seguem abaixo os recursos da django-plus.

JSONField

Tipo de campo que armazena listas ou dicionários em formato JSON bastante interessante. Foi criado pleo usuário deadwisdom que o colocou no Django Snippets [1].

Exemplo de uso

from djangoplus.fieldtypes import JSONField
class Produto(models.Model):
    nome = models.CharField(max_length=50)
    lista = JSONField(blank=True)

este campo aceitará listas, dicionários e outros valores serializáveis.

SectionedForm

Baseando num snippet que criei [3], trata-se de uma classe de form que permite dividir o form em fieldsets (da mesma forma que você pode fazer no Admin, por exemplo.

Exemplo de uso

from djangoplus.forms import SectionedForm
class FormProduto(SectionedForm, forms.ModelForm):
    class Meta:
        model = Produto
        fields = ('nome', 'referecia', 'categorias', 'lista',)
    fieldsets = (
        (None, ('nome','referencia',)),
        (_('Outras Informacoes'), ('categorias','lista',)),
    )

quando o form for utilizando no template, em forma forma convencional, ele será divido em duas seções, uma sem título e outra chamada "Outras Informacoes". A divisão será feita por um elemento H3, mas você pode customizar isso adicionando o atributo "fieldset_template", exemplo

class FormProduto(SectionedForm, forms.ModelForm):
    class Meta:
        model = Produto
        fields = ('nome', 'referecia', 'categorias', 'lista',)
        fieldset_template = '<h2 id="section_%(section)s">%(title)s</h2>'

usando o id gerado por ele (veja o HTML gerado para saber qual), você pode exibir ou ocultar uma seção usando JavaScript.

para mim tem sido muito útil, pois é realmente chato ter formulários longos sem nenhuma divisão ou ter que informar campo por campo por causa delas.

Proteção anti-robôs para e-mails, URLs e outras informações

Baseado no snippet que criei em [4].

Sabe aquela coisa que alguns sites fazem para proteger um e-mail contra spam? exemplo "mari...@gmail.com".

Pois é, essa proteção é para isso. Na verdade eu precisa de uma proteção que valesse para todo tipo de informações, então ao invés de fazer o mesmo com o e-mail (adicionar as reticencias), ele exibe uma frase do tipo "informação confidencial, clique aqui para se certificar de que não é um robô". Aí ele vai para uma página com capcha e tudo resolvido.

Como usar

Adicione o middleware 'djangoplus.middleware.ProtectAntiRobotsMiddleware'

No template onde deseja ocultar uma informação, acrescente

{% load djangoplus_tags %}

{% protectantirobots %}
  <a href="mailto: {{ office.email }}">{{ office.email }}</a>
{% endprotectantirobots %}

FakeSessionCookieMiddleware

Criado por Dan Fairs e disponível em [5] este middleware aceita que seja informada a sessão através de um parâmetro na URL. É bastante útil para a criação de integração com Flesh, Ajax, Google Gadgets, Facebook F8, etc.

Para usá-lo, acrescente-o como middleware ao seu projeto 'djangoplus.middleware.FakeSessionCookieMiddleware'

render_to_json

Como o nome indica, funciona de forma semelhante à shortcut render_to_response, mas se destina a responder em formato JSON.

Exemplo de uso

    from django.utils import simplejson
    from djangoplus.shortcuts import render_to_json

    def json_view(request):
        ret = {'nome': 'Tarsila', 'idade': 2}
        return render_to_json(simplejson.dumps(ret))

render_to_mail

Da mesma forma que a supracitade, renderiza, só que enviando um e-mail. É ainda mais útil para se enviar e-mails do tipo HTML.

Como usar

Se deseja usar formato texto plano, declare a setting
```
DEFAULT_EMAIL_CONTENT_SUBTYPE = 'plain'
```

Para enviar um e-mail a partir de uma template, use um código como este

from djangoplus.shortcuts import render_to_mail
return render_to_mail(
    'central/usuarios/mensagem.html',
    locals(),
    subject='Titulo da mensagem',
    recipient_list=['marinho@marinhobrandao.com'],
    )

DynamicTemplate

Trata-se de um template dinâmico, que é manipulado através do Admin e pode ser acrescentado a um outro template através da template {% dynamic_template %}.

É um recurso poderoso, que pode ser utilizado em grupos, quando todos os templates de um grupo em comum são adicionados em lote.

Como usar

Vá até seu Admin, procure a seção "Djangoplus" e clique na opção "Dynamic templates" e adicione seu template dinâmico;

Em seu template, adicione uma template tag assim

{% load djangoplus_tags %}
{% dynamic_template slug-do-template %}
{% dynamic_template group grupo-do-template %}

Template filters

E por falar em template tags, o django-plus possui muitos template filters, úteis ou não para o seu caso

{{ numero|multiple_of:3 }} - retorna True se "numero" é multiplo de "3"
{{ valor|in_list:lista }} - retorna True se "valor" está contido em "lista"
{{ valor|is_equal:outro_valor }} - retorna True se "valor" é igual a "outro_valor"
{{ valor|is_not_equal:outro_valor }} - retorna True se "valor" não é igual a "outro_valor"
{{ valor|is_lt:outro_valor }} - retorna True se "valor" é menor que "outro_valor"
{{ valor|is_lte:outro_valor }} - retorna True se "valor" é menor ou igual a "outro_valor"
{{ valor|is_gt:outro_valor }} - retorna True se "valor" é maior que "outro_valor"
{{ valor|is_gte:outro_valor }} - retorna True se "valor" é maior ou igual a "outro_valor"
{{ numero|is_day_of:data }} - retorna True se "numero" é o dia de uma "data"
{{ numero|is_month_of:data }} - retorna True se "numero" é o mês de uma "data"
{{ numero|is_year_of:data }} - retorna True se "numero" é o ano de uma "data"
{{ numero|is_hour_of:data }} - retorna True se "numero" é a hora de uma "data"
{{ numero|is_minute_of:data }} - retorna True se "numero" é o minuto de uma "data"
{{ numero|is_second_of:data }} - retorna True se "numero" é o segundo de uma "data"
{{ data|dec_year:numero }} - decrementa "numero" de anos de uma "data"
{{ data|dec_month:numero }} - decrementa "numero" de meses de uma "data"
{{ data|inc_year:numero }} - incrementa "numero" de anos de uma "data"
{{ data|inc_month:numero }} - incrementa "numero" de meses de uma "data"
{{ lista|list_as_text }} - faz exatamente o mesmo que a template filter join faz hoje (na época da criação ela não existia)
{{ lista|list_as_text:atributo }} - faz o mesmo que acima, porém é baseado no atributo informado
{{ lista|list_as_links:atributo }} - faz o mesmo que a template filter list_as_text, entretanto, monta um link para cada uma delas
{{ variavel|startswith:outro_valor }} - retorna True se a string contida em "variavel" inicia com a contida em "outro_valor"
{{ variavel|endswith:outro_valor }} - retorna True se a string contida em "variavel" termina com a contida em "outro_valor"
{{ queryset|order_by:"campo1,campo2" }} - efetua a ordenação de uma queryset

Bom, há ainda alguns widgets, generic views, utilidades para Google Maps API e e o mais importante Model Info (para objeto e para listagem), que equivale ao ModelForm, porém exibe somente as informações para visualização. Entretanto, por hoje vamos ficar por aqui, logo eu publico a segunda parte :)

Oportunidade de trabalho para desenvolvedor Django

O Sérgio Oliveira publicou a seguinte oportunidade de trabalho:

A Interzone Entertainment está em busca de mais um membro para o seu time brasileiro de desenvolvedores web. No momento o time esta envolvido na integração do game Interzone Futebol com a página web http://www.interzonefutebol.com.br (Django).
Conhecimentos requeridos:

Python

Linux

SVN

Javascript

HTML/CSS (W3C standards)

SQL

Inglês (para leitura)

Conhecimentos desejados:

Django

Pylons

ORMs

JQuery

WSGI

PHP

Postgres

Shell Script

Inglês fluente

Sobre a Interzone Games: http://www.interzoneentertainment.com/about/

Interessados enviem o cv para sergio.campos@interzonegames.com com o assunto "Web/Python"

DjangoStack - fácil para o iniciante aprender Django

Muitas pessoas vêm para o Django de diversoss outros frameworks. Outras não passaram por outros frameworks, mas já possuem alguma (ou muita) experiência com o universo do Linux, Python e Software Livre.

Entretanto, há um grupo cada vez maior de pessoas que estão conhecendo o Django a partir do nada, ou partindo de linguagens de paradigma muito diferente, como Delphi, Visual Basic, Java ou PHP.

Essas pessoas são muito bem-vindas ao framework, mas muitas vezes começam sem uma definição clara de como a coisa funciona no geral, e normalmente o que elas mais enfrentam é uma quantidade muito grande de quebra de paradigmas e novidades, o que acaba deixando qualquer um sem um chao firme onde pisar.

É por isso que resolvi fazer esse tutorial sobre iniciar no Django, usando DjangoStack.

Bitnami DjangoStack

O Bitnami é projeto que viabiliza instaladores passo-a-passo completos para algumas ferramentas.

Lembra-se do conceito de "LAMP" (Linux + Apache + MySQL + PHP)? Pois é, em cima dessa idéia, surgiram diversas variantes: o WAMP por exemplo, é um dos mais populares.

O DjangoStack é a mesma idéia do LAMP; você pega um só instalador, executa, ele abre uma janela e passo por passo você instala e configura seu primeiro projeto em Django, incluindo todo o ambiente que precisa para aprender e desenvolver: Python, Apache, MySQL e SQLite.

Download e versões disponíves

Primeiro de tudo, é preciso baixar o instalador. Ele está disponível para Linux, Windows e MacOSX (plataformas Intel e PowerPC). Portanto, vá até a página de download e escolha a versão desejada:

http://bitnami.org/stack/djangostack

Obs: Devido à procura ser maior em torno do Windows, este tutorial será feito usando o Windows como base.

Instalação

Após fazer o download (em torno de 38MB), execute o arquivo de instalação.

Na janela exibida, clique em "Next" para continuar (mantendo os valores padrão) ate que a seguinte pergunta seja feita:

"Please configure your Django project"

Informe "meu_projeto". Deixe o SQLite marcado como banco de dados do projeto e siga adiante.

Na janela a seguir, apenas clique no botão "Next" para iniciar a cópia de arquivos.

Obs: numa próxima vez você poderá informar com mais calma os valores da configuração, modificando de acordo com sua preferência. Entretanto, este tutorial e feito com base nos valores padrão.

Ao final da instalação, o Apache e o MySQL serão iniciados e a página inicial será exibida no seu navegador padrão.

A janela exibida pelo navegador mostrará uma introdução e um link no meio, em letras garrafais: "Access Your Project".

Clique no link para visualizar seu projeto em Django rodando pela primeira vez.

Primeiro projeto

Se achou tudo fácil demais até aqui, não fique em dúvida, o Django é fácil mesmo, mas agora começa a parte divertida.

Abra agora no Explorer o caminho de instalação do DjangoStack ("C:\Arquivos de programas\BitNami DjangoStack").

Com a janela aberta, abra a pasta "projects" e em seguida "meu_projeto". Os arquivos contidos nessa pasta são os arquivos criados para o seu projeto.

A primeira aplicação

Agora vamos criar uma pequena aplicação de Anotações.

Crie uma pasta chamada "anotacoes" e dentro dela os arquivos vazios: "__init__.py" e "models.py".

Agora abra o arquivo "models.py" para edição (pode ser no Bloco de Notas ou em algum outro editor de texto de sua preferencia) e dentro, digite as seguintes linhas:

from datetime import datetime
from django.db import models

class Anotacao(models.Model):
    titulo = models.CharField(max_length=50)
    texto = models.TextField()
    data_hora = models.DateTimeField(default=datetime.now, blank=True)

    def __unicode__(self):
        return self.titulo

Configurando as settings do projeto

Agora na pasta superior - a do projeto - edite o arquivo "settings.py", e acrescente as seguintes linhas no início do arquivo:

import os
PROJECT_ROOT_PATH = os.path.dirname(__file__)

Localize a setting "DATABASE_NAME" e modifique para ficar desta forma:

DATABASE_NAME=os.path.join(PROJECT_ROOT_PATH,'meu_projeto.db')

Localize a setting "ADMIN_MEDIA_PREFIX" e modifique para ficar desta forma:

ADMIN_MEDIA_PREFIX = '/admin_media/'

Agora por fim, localize a setting "INSTALLED_APPS" e modifique para ficar desta forma:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.admin',
    'anotacoes',
)

Configurando as URLs do projeto

Após fechar e salvar, edite na mesma pasta o arquivo "urls.py", e modifique para ficar desta forma:

from django.conf.urls.defaults import *

from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    (r'^admin/(.*)', admin.site.root),
)

Modificações feitas, agora precisamos criar o banco de dados, mas pra isso, será preciso fazer algumas coisas antes.

Ajustando o ambiente de desenvolvimento

Quando se instala o Python no Windows, este deve ser adicionado à variável de ambiente PATH para que o comando "python" seja encontrado de qualquer caminho. Portanto, pressione as teclas "bandeira+Pause" para acessar a janela de "Propriedades do Sistema", e vá até a aba "Avançado", clicando no botão "Variáveis de Ambiente".

Na caixa "Variáveis do sistema", localize o item "Path" e clique duas vezes. Será exibida outra janela, e no campo "Valor da variável", adicione ao final "C:\Arquivos de programas\BitNami DjangoStack\python". Feche todas as janelas clicando em "Ok".

Gerando o banco de dados

Pronto, agora voltemos à janela do Explorer, posicionado na pasta do projeto. Vamos criar ali um batch para a geração do banco de dados.

Crie um arquivo chamado "criar_banco_de_dados.bat" e digite dentro as seguintes linhas:

python manage.py syncdb
pause

Feche o arquivo salvando e clique duas vezes sobre ele.

Uma janela do DOS será exibida gerando as tabelas no banco de dados. Responda as perguntas assim:

Would you like to create one now? (yes/no): yes
Username: admin
E-mail address: seu_email@dominio.com
Password: 1
Password (again): 1

Configurando o Apache

Agora é necessário ajustar as configurações do Apache para que seu ambiente de desenvolvimento possa executar o que precisa.

Na janela do explorer, vá até a pasta "C:\Arquivos de programas\BitNami DjangoStack\apps\django\conf" e edite o arquivo "django.conf" modificando para ficar desta forma:

<location '/'>
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    PythonPath "['C:\Arquivos de programas\BitNami DjangoStack/projects/', 'C:\Arquivos de programas\BitNami DjangoStack/projects/meu_projeto'] + sys.path"
    SetEnv DJANGO_SETTINGS_MODULE meu_projeto.settings
    PythonDebug On
</location>

Alias /admin_media "C:\Arquivos de programas\BitNami DjangoStack\apps\django\django\contrib\admin\media"

<Location "/admin_media">
    SetHandler None
</Location>

Por motivos de performance, um projeto feito em Django não aplica as modificações recebidas automaticamente. É preciso reiniciar o Apache para que elas façam efeito.

O DjangoStack não ativa o ApacheMonitor na inicialização do Windows. Portanto, é preciso que você faça isso.

Na janela do explorer, vá até a pasta "C:\Arquivos de programas\BitNami DjangoStack\apache2\bin" e clique duas vezes no arquivo executável "ApacheMonitor.exe". Será exibido um novo ícone na bandeja, ao lado do relógio do Windows.

Obs: é recomendável que você crie um atalho do ApacheMonitor para iniciar automaticamente com o Windows, pois assim terá menos trabalho quando precisar reiniciar o Apache.

Agora clique sobre o ícone da bandeja, selecione o serviço do Apache e escolha a opção "Restart" para reiniciar o apache.

Após aguardar alguns segundos, vá até o seu navegador e carregue a URL: "http://localhost/admin/". O usuário é "admin", e a senha é "1".

Criando Aplicações Plugáveis

Nos dias 18, 19 e 20 de setembro, estive na PyCon Brasil, participando das palestras excelentes que foram apresentadas por diversas pessoas-chave em assuntos relacionados direta ou indiretamente ao Python, Django, Pylons, TurboGears, Plone, Google App Engine, Zope e outros.

No sábado, fiz a apresentação da palestra "Django: Criando Aplicações Plugáveis" quando falei sobre a criação de aplicações reusáveis para Django.

Segue abaixo o documento dos slides. O Scribd permite ainda que você faça download em formato PDF. Para isso, basta logar

Django - criando aplicações plugáveis - Upload a Document to Scribd

Lançada a versão 1.0 alpha 2

Atenção: este artigo foi escrito para ser lançado no blog da DjangoBrasil [8] porém, por motivos técnicos, ele está sendo publicado aqui e será republicado lá dentro de algumas horas.

"Fantástica" é a palavra mais apropriada para esta última release, lançada ao final do dia desta sexta-feira.

A nova release, mais um passo da fiel agenda rumo à versão 1.0 final foi anunciada [1] com 4 novidades de tirar o fôlego, além das centenas de correções e ajustes efetuadas ao longo das últimas duas semanas:

Signals refactoring

O sistema de signals foi redesenhado em sua totalidade, o que rendeu um resultado assombroso de 90% de melhora na performance. A forma de escrever signals agora mudou, e também mudou - ainda que permaneça suportando a forma antiga - a forma de conectar funções a signals. Veja mais detalhes em [2] .

Fica aqui uma atenção especial sobre o django-tagging, django-ads, djapian e outras aplicações plugáveis que fazem uso de signals próprios.

GeoDjango

O branch para fazer o Django suportar GIS [3] foi finalizado e inserido ao trunk, destacado pela contrib django.gis. Essa novidade possibilita a criação de soluções baseadas em bancos de dados geográficos usando Django, o que dá um poder realmente grande ao framework.

Armazenamento de arquivos extensível

Esta novidade pode ser vista com detalhes em [4]. Agora é possível se criar backends para tratar o armazenamento de campos baseados em arquivo - especialmente FileField e ImageField - o que agora possibilita o armazenamento em banco de dados, locais remotos e em servidores de cloud computing de uma forma mais conceitualmente correta, sem necessitar de armazenamentos temporários com transferências.

Aqui vale um cuidado especial e bons testes antes de migrar seu site ou sistema em produção, é provável que necessite de ajustes.

Compatibilidade com Jython

A novidade também recente [5] da versão 2.5 do Jython e os ajustes feitos no Django para esta release agora permitem rodar um projeto baseado em Django usando a Java Virtual Machine e explorar assim sua robustez.

Outra melhoria conquistada nesta release é a de performance no suporte à internacionalização, que foi ajustado e otimizado. Diversas observações de incompatibilidade surgidas das últimas novidades podem ser encontradas em [6].

Continuamos em grade expectativa para a versão 1.0-final e sempre muito gratos à equipe de desenvolvedores [7], testadores e lançadores de tickets.

Links relacionados

[1]	http://www.djangoproject.com/documentation/release_notes_1.0_alpha_2/

[2]	http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Signalrefactoring

[3]	http://geodjango.org/

[4]	http://www.djangoproject.com/documentation/files/

[5]	http://fwierzbicki.blogspot.com/2008/07/jython-25-alpha-released.html

[6]	http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

[7]	http://code.djangoproject.com/browser/django/trunk/AUTHORS

[8]	http://djangobrasil.org/

Qual é a melhor IDE para Django?

Há tempos que venho mantendo o IMHO ligado a 100% quando este assunto é tocado por alguém pessoalmente ou na comunidade, mas enfim, resolvi tira-lo do OFF para este artigo, já que a sensação na realidade é de saco cheio com esse assunto.

Longe de querer evangelizar pessoas a usarem o gVim [1] (veja também a lista de editores para Python [2]), a minha intenção aqui é alertar quanto à ilusão que se tem com IDEs e editores, focando em seus recursos preguiçosos no lugar de em suas ferramentas para produtividade real.

Há uma visão distorcida generalizada quanto à palavra produtividade. A máxima foi evoluída por ferramentas consideradas "produtivas", como Delphi, Visual Basic, Access e outras ferramentas menos populares onde a competição sempre foi oferecer mais e mais recursos prontos, movimentos de mouse, ferramentas visuais e code-templates.

Ocorre que à época que essas ferramentas foram criadas as alternativas eram Clipper, DataFlex, FoxPro e até mesmo Cobol, e na febre do marketing da mudança do ambiente console para ambiente gráfico, foi criada a ilusão de que tudo que é visual é mais rápido e produtivo que em modo texto.

Doce ilusão.

Uma ferramenta como o Delphi, com milhares de itens no menu e seus complementos é tão fácil de operar quanto o painel colorido e piscante de um Boeing 747 na cabina do piloto. E o pior: o avião está caindo.

Obviamente, não há comparações entre uma ferramenta exageradamente visual a alguns recursos de editor. Mas a premissa é a mesma, com dosagens diferentes.

Mas vamos supor que você goste de autocomplete, um dos recursos mais cosiderados quando se procura um editor.

A cada vez que você precisar digitar um import, basta digitar os primeiros caracteres e o editor irá exibir uma caixa de seleção com alternativas com o mesmo prefixo e você irá escolher uma das opções.

Isso reserva pelo menos quatro reflexões (reserve pelo menos 1 minuto para cada ponto abaixo):

A quantidade de vezes que você pressionou uma tecla é realmente menor que a necessária para digitar a expressão manualmente?

O trabalho de levar o braço até o mouse de forma a escolher a opção desejada é realmente menor que o trabalho de digitar a expressão manualmente?

Se fosse em uma situação em um editor sem esses recursos (no servidor, por exemplo), você conseguiria digitar essa expressão sem dificuldade?

A memória, processador e leitura no HD de forma a indexar, localizar e exibir as alternativas é tão curta que compense a espera?

Refletiu?

Agora leia este meu caso: todas as vezes que eu precisava escrever um signal, eu copiava o bloco de codigo com uma linha de comentário, 2 imports e algumas linhas com um signal qualquer de algum arquivo já pronto e fazia as modificações. Consequência: eu nunca sabia fazer isso sozinho, eu não me lembrava da lógica de funcionamento dos signals, e simplismente não sabia onde no código do framework estariam os signals de models, o que atrapalhava meu raciocínio sobre como os signals funcionam.

Tomei a seguinte medida: parei de fazer isso, nas primeiras vezes eu escrevi algumas coisas erradas mas fui acertando mais e mais até isso se tornar uma tarefa rotineira e então eu consegui ter uma visão ampla de como os signals funcionam e como eles estão modularizados.

Parece bobo, mas é assim mesmo que funciona. E cá entre nós: você acha mesmo que procurar um arquivo, abrí-lo e copiar um bloco de codigo semelhante ao que eu precisava era mais produtivo e mais rápido do que digitar manualmente?

DRY fala das coisas que devem ser feitas de forma reutilizável, não do seu hábito em copiar essas coisas e espalhar códigos semelhantes e mal pensados pela aplicação. E DRY também não se trata de ter preguiça de pensar, na verdade DRY existe para distribuir as coisas de forma clara de forma que você possa pensar mais amplamente, mas sem se esquecer da essência.

Agora, para finalizar: qual é o editor ou IDE ideal para se trabalhar com Django?

Isso - claro - vai depender de seu gosto pessoal, mas ao instalá-lo, desabilite todos os recursos criados para preguiçosos e use o que ele tem de melhor: teclas de atalho, abas, buscas por regex, integrações com software de versionamento e o que mais tiver. Faz bem para você.

E também não é demais ressaltar: com um raciocínio rápido e bom conhecimento em profundidade, sua produtividade estará relacionada à rapidez que você consegue criar a solução e não na rapidez que consegue escrever uma gambiarra ;)

[1]	http://www.vim.org/

[2]	http://www.pythonbrasil.com.br/moin.cgi/IdesPython

Oportunidade de trabalho em Barueri-SP

O Rudá enviou a seguinte mensagem:

Oportunidade de trabalho para programador(a) trainee Python

Segue os detalhes de vaga

Conhecimentos Necessários: Python, HTML, CSS, JavaScript, SQL

Conhecimentos Desejáveis: Django, Zope, Plone, PostgreSQL, MSSQL Server, Linux

Empresa: Mondial Eletrodomésticos (www.mondialline.com.br)

Local de trabalho: Alphaville, Barueri - SP

Carga horária: de 6 a 8 hs.

Salário variando de R$ 1.500,00 à 2.500,00, dependendo da carga horária e do conhecimento do candidato.

Foco de trabalho: análise de requisitos e desenvolvimento de aplicação web gerencial para extração de relatórios de faturamento/produção/custos.

Obs: a vaga inicialmente é temporária (4 a 6 mêses) mas existe chance de efetivação

Interessados favor enviar CV com pretensão salarial para: ruda em mondialline ponto com ponto br

Oportunidade de trabalho em Fortaleza

O Nicholas enviou o seguinte anúncio:

a gNial está contratando 1 (um) programador para atuar em Fortaleza-Ceará que possua os seguintes conhecimentos:
* Python
* Django
* XML
Desejável:
* FreeSwitch
Salário de acordo com o perfil.

Favor enviar currículo para nicholas em gnial ponto com ponto br

Veja também

http://gnial.com.br/

Agora com domínio novo

Before all, an english resume: my apologizes for the recent duplicates of entries in Django Community site. This ocurred because I changed the permalinks to slugs (they was id-based) and now I changed the domain. But I promise this won't happen again for the near time :)

Bom, quem assina os feeds do blog (algo em torno de 50 pessoas diretamente, mais os assinantes do Django Brasil Planeta e do Django Community) deve ter notado uma anomalia nos últimos dias.

Por duas vezes, os artigos tiveram seus permalinks alterados (a primeira vez por conta dos slugs e a segunda por conta do domínio), e como o permalink é a chave única para os leitores RSS, isso fez com que os últimos 20 artigos fossem contados como novos.

Acontece que agora estou de domínio novo: http://marinhobrandao.com/ e isto causou o rebuliço pela segunda vez. Então ficam aqui meu sincero pedido de desculpas pelo ocorrido e também o pedido para que anote o novo endereço.

Todas as URLs do antigo endereço estão apontadas para as respectivas no novo endereço, com redirect permanente de código 301, portanto, tudo continua funcionando normalmente, mas é recomendável utilizar o novo endereço :)

Lançada a versão 1.0 alpha

Ontem ao fim do dia foi anunciada a versão 1.0 alpha [1], que é o primeiro passo para a release 1.0 final, a ser lançada em setembro, na DjangoCon.

A maior parte das features da versão 1.0 tem sido utilizada há meses (algumas há anos) através da versão trunk, pois havia muito tempo que a versão 0.96 foi liberada e a maior parte dos desenvolvedores usam a versão do trunk em produção.

O que podemos destacar nesta versão

Suporte a Unicode - a versão anterior não era 100% unicode, o que gerava algumas dificuldades na implantação e distorções entre máquina de desenvolvimento e servidor em produção. Essa feature mudou definitivamente o nosso trabalho pois a partir do momento em que ela foi liberada no trunk, deixamos de nos preocupar com codificação de caracteres e o trabalho passou a render mais.
Escape como default nas variáveis no template - esta feature fez uma diferença fundamental na segurança das aplicações, uma inversão pequena que melhorou bastante os resultados dos projetos.
ORM refatorado com heranças de modelo - há 2 ou 3 meses essa feature foi liberada, possibilitando trabalhar com heranças de classes de modelo, tanto de forma abstrata quanto de forma distribuída em tabelas, isso possibilita que você tenha classes de modelo que são baseadas em outras e seus dados são exibidos de forma transparente.
Admin baseado em NewForms - a última grande novidade, liberada no último sábado foi o merge do branch newforms-admin, que traz consigo todo o Admin refatorado para ser modular e compatível com NewForms. Assim, todo o acoplamento entre classes de modelo e admin foi removido e foi definido um módulo admin.py para conter as classes e definições da aplicação para o Admin. Com o novo admin é possível trabalhar de forma muito mais profissional com sistemas diversos, customizar sua interface de administração do site, adicionar recursos de Ajax, etc.

As próximas versões a serem lançadas na programação da 1.0 serão: 1.0 beta 1, 1.0 beta 2, 1.0 RC 1, 1.0 RC 2 e finalmente, a 1.0 final, prevista para o dia 2 de setembro, na DjangoCon.

Vantagens da versão 1.0

A versão 1.0 é anciosamente esperada pois com o crescimento exorbitante do framework neste último ano fez com que ele ultrapassasse a fronteira técnica, chegando até os diretores de tecnologia, empresários e grandes empresas. Desta forma, uma versão padrão vai permitir uma melhor profissionalização do uso do framework, tanto no uso do Google App Engin [2] quanto no treinamento de profissionais, edição de livros, redação de cursos, etc.

Links relacionados

[1]	http://www.djangoproject.com/documentation/release_notes_1.0_alpha/

[2]	http://code.google.com/appengine/

Load balancing e Cache com MySQL Proxy

Que tal aprender uma nova linguagem enquanto faz uma boa tarefa para melhorar a escalabilidade do banco de dados?

Bom, foi isso que eu fiz hoje durante quase todo o dia. Descobri no início do dia que Lua é a linguagem de script do MySQL Proxy e mergulhei pra fazer duas coisas bastante interessantes: Load Balancing e Cache de resultados.

Load Balancing

Eu conheço 3 formas de fazer load balancing com MySQL:

MySQL Cluster [1]

MySQL Proxy [2]

MySQL Master/Slave [3]

Mas na verdade não conhecia em profundidade nenhum deles, apenas uma idéia superficial.

No final de semana testei o Master/Slave. Parece ser o mais poderoso dentre os três métodos, mas usá-lo no Django significa mexer em boa parte do código do ORM. Não é a minha intenção. Cheguei a construir um backend pra isso, em cima do backend do MySQL, e até descobri que havia outro semelhante [4]. Mas nem o meu backend improvisado, nem o do Ivan Sagalaev me seduziram: muito limitado e cheio de falhas de design.

Pois bem, o MySQL Cluster também me desanimou depois que eu li diversos depoimentos contrários [5].

Sobrou o MySQL Proxy.

MySQL Proxy

Este é um software um tanto recente da MySQL, que basicamente faz a ponte entre o(s) servidor(es) de MySQL e a sua aplicação. É vantajoso pois é independente de linguagem ou framework: você desenha as regras e o que vem depois delas pouco importa, funciona da mesma forma.

Não quero explicar como instala e usa este software, portanto vou me limitar ao script que montei para fazer load balancing. Não foi devidamente testado e em algumas situações foi exibido o erro (1105, '#07000(proxy) all backends are down'), portanto, antes de ir migrando seu servidor, faça muitos testes e verifique mais detalhes.

O script, feito em Lua, ficou assim

function connect_server()
    local num = tonumber(os.date("%S")) % 2
    proxy.connection.backend_ndx = num + 1
    print("Using " .. proxy.backends[proxy.connection.backend_ndx].address)
end

Salve o arquivo como load_balancing.lua e execute da seguinte forma:

mysql-proxy \
    --proxy-lua-script=load_balancing.lua \
    --proxy-backend-addresses=127.0.0.1:3306 \
    --proxy-backend-addresses=vs2:3306

O parâmetro --proxy-backend-addresses pode ser repetido quantas vezes quiser, um para cada réplica do MySQL, quanto mais réplicas, mais poderoso é o seu "cluster".

Os hosts "127.0.0.1" e "vs2" são respectivamente, minha máquina e uma máquina virtual rodando no vmware-server, portanto, use os IPs ou hostnames conforme a sua realidade.

Ele não suporta master/slave (não encontrei nada na documentação que orientasse como fazer nesse caso), portanto foi necessário configurar os hosts como master/master, que você pode ver como fazer em [6]

O funcionamento é assim: nos segundos pares as conexões são repassadas ao servidor 1, e nas ímpares as conexões são repassadas para o servidor 2. Se houvessem 10 servidores, o módulo de 2 (local num = tonumber(os.date("%S")) % 2) seria feito com 10 (local num = tonumber(os.date("%S")) % 10) e o comando de chamada do mysql-proxy teria 10 vezes o parâmetro --proxy-backend-addresses. Simples né?

Cache em memória

Bom, eu já havia feito o mesmo tipo de coisa hackeando a QuerySet e criando o método .cache() [7], que me ajudou muito. Esta solução que eu criei hoje pode ser considerado inferior à anterior por oferecer menos granularidade e funcionar somente com MySQL, mas caso você não queira modificar o código original do Django, esta pode ser uma boa alternativa para você.

Este segundo script funciona da seguinte forma: quando uma consulta do tipo SELECT é feita ao banco de dados, seu resultado é armazenado em um servidor Memcached, com tempo de expiração definido por pattern (cada pattern, ou seja, cada modelo de SELECT pode possuir um tempo de expiração diferente) e se uma cosulta idêntica for requisitada dentro do tempo de expiração, o servidor de cache será consultado, ao invés do banco de dados.

Bacana né?

Então lá vai

-- Packages required
require("Memcached") -- http://luamemcached.luaforge.net/
require("json")      -- http://www.chipmunkav.com/downloads/Json.lua

-- Connect to memcached server
local conn = Memcached.Connect('localhost', 11211)

-- Default expire time for cache items
local default_expire_time = 30

-- Prefix for cache keys
local key_prefix = 'mysql-proxy-'

-- Patterns to define expiration time for different types of queries.
-- More details in: http://lua-users.org/wiki/PatternsTutorial
local patterns_expire_time = {
    {'^%s*select .+from .*auth_user', 150},
    {'^%s*select', default_expire_time},
}

-- Converts a string to valid key
function encode_key(str)
    return key_prefix .. string.gsub(str, ' ', '-')
end

-- Converts a resultset to JSON. This can't be done by
-- Json library directly because it's a userdata datatype
-- instance
function resultset_to_str(resultset)
    local rfields = resultset.fields
    local rrows = resultset.rows

    local fields = {}
    local rows = {}
    local pos = 1

    -- Rows
    for row in rrows do
        rows[pos] = row
        pos = pos + 1
    end

    -- Fields
    pos = 1
    for i = 0, #rfields do
        if rfields[i] then
            fields[pos] = {
                type = rfields[i].type,
                name = rfields[i].name,
            }
        end

        pos = pos + 1
    end

    return Json.Encode({
        fields = fields,
        rows = rows,
    })
end

-- Callback called before request database server
function read_query(packet)
    if string.byte(packet) == proxy.COM_QUERY then
        local sql = string.sub(packet, 2)

        if string.match(string.lower(sql), '^%s*select') then
            -- Transform to valid key string
            local key = encode_key(sql)

            -- Gets from cache
            local rset = conn:get(key)

            -- If not found in cache, requests from database server
            if rset == nil then
                proxy.queries:append(1, packet)
                return proxy.PROXY_SEND_QUERY
            end

            -- Print out
            print('from cache', key)

            -- Json -> table
            rset = Json.Decode(rset)

            -- Todo: check for error returns
            proxy.response.type = proxy.MYSQLD_PACKET_OK
            proxy.response.resultset = rset

            return proxy.PROXY_SEND_RESULT
        end
    end
end

-- Callback called after request to database server
function read_query_result(inj)
    local res = resultset_to_str(inj.resultset)
    local sql = string.lower(string.sub(inj.query, 2))
    local key = encode_key(sql)
    local expire_time = default_expire_time

    -- Looks at patterns for respective expire time
    for i = 0, #patterns_expire_time do
        if patterns_expire_time[i] and string.match(sql, patterns_expire_time[i][1]) then
            expire_time = patterns_expire_time[i][2]
            break
        end
    end

    -- Saves to cache
    conn:set(key, res, expire_time)
end

Lá no início, as linhas que definem local conn e local patterns_expire_time devem ser ajustadas à sua realidade (endereço do servidor e patterns). Para saber como definir expressões regulares em Lua veja em [8] (é um pouquinho diferente do convencional).

Este script depende de dois pacotes externos à linguagem: json.lua [9] e Memcached.lua [10], que por sua vez depende do LuaSocket [11].

No Ubuntu, quando se instala o pacote mysql-proxy a lib da Lua 5.0 é instalada também, mas acontece que os pacotes que eu citei acima - especialmente o LuaSocket - não funcionam corretamente com a versão 5.0.

A solução foi instalar a versão 5.1 em paralelo (o LuaSocket possui um pacote no Ubuntu chamado liblua5.1-socket2) e eliminar a pasta antiga de bibliotecas da versão 5.0 (/usr/share/lua/50/), criando um symlink da versão 5.1 (/usr/share/lua/5.1/) com o mesmo nome.

Ainda foi necessário definir a seguinte variável de ambiente

export LUA_INIT=@/usr/share/lua/50/compat-5.1.lua

Por fim, para dar vida ao script, basta executar

mysql-proxy \
    --proxy-lua-script=cached_queries.lua \
    --proxy-backend-addresses=127.0.0.1:3306

Ao executar este comando, será aberta a porta 4040 que deve ser setada na setting DATABASE_PORT. Caso queira saber como sobrepor a porta 3306, veja em [19].

Uma observação importante: o MySQL possui um bug [12] (ou sei lá o que é) que obriga conexões para "localhost" serem via porta 3306, isso vale tanto para o client quanto para o pacote MySQLdb do Python. Você faz uma conexão para a porta 1365465321 ou qualquer outra e ele aponta para 3306. Portanto, ao usar a porta 4040, mude a setting DATABASE_HOST para "127.0.0.1" caso esteja usando "localhost".

No script acima há ainda uma séria limitação quanto ao tamanho da SELECT. Caso ela tenha mais que 245 caracteres, você terá um erro de tamanho da chave no cache. A solução é converter a expressão SELECT com MD5, SHA ou outor algorítimo que crie uma string única em cima de uma SELECT complexa. Eu não consegui fazer isso ainda, mas recomendo expressamente que faça esse ajuste eu espere que eu o faça antes de colocar em um servidor de produção.

Para mais detalhes sobre MySQL Proxy, veja em [13], [14], [15] e [16]

Para mais detalhes sobre Lua, veja em [17] e [18].

É isso aí... artigo feito no fim da noite tem quer ser rápido assim. Dúvidas, é só falar :)

PS: apesar de serem muito úteis para quem usa Django, todas essas configurações são compatíveis com qualquer linguagem ou sistema operacional, e com versões igual ou acima de 5.1 do MySQL.

PS2: agradeço ao Javier Guerra e David Given pelos esclarecimentos sobre a arquitetura da Lua e ao Giuseppe Maxia pelo bom tutorial [19] que desenvolvou sobre MySQL Proxy

PS3: essa foi a primeira vez na vida que escrevi algo em Lua, por favor, sinta-se à vontade para apontar eventuais falhas

Atualização: removendo a variável de ambiente LUA_INIT, o mysql-proxy rodou normalmente sobre a versão 5.1.

Links relacionados

[1]	http://dev.mysql.com/downloads/cluster/index.html

[2]	http://forge.mysql.com/wiki/MySQL_Proxy

[3]	http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-replication-connection.html

[4]	http://softwaremaniacs.org/soft/mysql_cluster/en/

[5]	http://blog.globoi.com/producao/2008/04/16/brasileiros-na-mysql-conference/

[6]	http://www.howtoforge.org/mysql_master_master_replication

[7]	http://marinho.webdoisonline.com/blog/p/metodo-cache-para-queryset_158/

[8]	http://lua-users.org/wiki/PatternsTutorial

[9]	http://www.chipmunkav.com/downloads/Json.lua

[10]	http://luamemcached.luaforge.net/

[11]	http://www.tecgraf.puc-rio.br/~diego/professional/luasocket/

[12]	https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/241802

[13]	http://del.icio.us/marinho/mysql+escalabilidade

[14]	http://dev.mysql.com/doc/refman/5.1/en/mysql-proxy.html

[15]	http://dev.mysql.com/doc/refman/5.1/en/mysql-proxy-scripting.html

[16]	http://classdump.org/articles/2008/02/14/mysql-proxy-enhancements

[17]	http://www.lua.org/manual/5.1/pt/

[18]	http://lua-users.org/wiki/TutorialDirectory

[19]	(1, 2) http://dev.mysql.com/tech-resources/articles/proxy-gettingstarted.html

Migrando do mod_python para o mod_wsgi

Já faz alguns meses que eu queria fazer alguns testes com o mod_wsgi, a alternativa ao mod_python que vem sendo cada vez mais comentada e sugerida na comunidade Django.

Ontem eu aproveitei o dia tranquilo pra unir o útil ao agradável e colocar isso em prática.

O que é WSGI?

Vamos "começar do começo": WSGI é mais simples do que parece, trata-se de uma interface definida pela PEP 333 [1] para intermediar a comunicação entre servidores web e frameworks Python. Ela surgiu pela necessidade qualquer um de nós nota com um pouco tempo: Python tem quilos de frameworksmuitas delas excelentes, e às vezes o mod_python parece ser um ornitorrinco em um ninho de coelhos quando implantamos alguns sites. É esquisito.

Mudando para o mod_wsgi

Para usar o WSGI puramente, é bastante simples, vamos fazer um pequeno script para ilustrar

def application(environ, start_response):
    status_code = '200 OK'
    headers = [('Content-Type', 'text/html')]

    start_response(status_code, headers)

    return ['So testando!']

from paste import httpserver
httpserver.serve(application, port='8000')

Ao executar este script minúsculo e carregar em seu navegador a URL "http://localhost:8000", será exibido "So testando". Simples não? Veja

$ python my_app.py
serving on http://127.0.0.1:8000

No Django, a coisa exige só um pouco mais de detalhes, mas nada complexo. Como já explanado há poucos dias pelo Eric, da Metaphormedia, em [2], é recomendável que se crie dentro de seu projeto uma pasta "apache" com um script dentro chamado "django.wsgi" - estes nomes são escolha sua, mas eles têm sido usados por mais de uma referência. Com o conteúdo abaixo (modificado segundo as suas necessidades)

#!/usr/bin/env python
import os, sys

sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)+'/../'))

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

E configure seu apache, removendo o código que implementa o mod_python e adicionando o seguinte

WSGIScriptAlias / /caminho/do/seu/projeto/apache/django.wsgi

Agora, para funcionar, é preciso que seu sistema operacional tenha o mod_wsgi instalado. No Ubuntu/Debian você instala com o seguinte comando

$ sudo apt-get install libapache2-mod-wsgi

Pronto, ao reiniciar o Apache, seu projeto estará lá, bonitão, rodando através do WSGI :)

Porque mod_wsgi?

Bom, essa deve ser a pergunta que você deve estar se fazendo. Se o mod_python sempre foi a alternativa recomendada e funciona bem, porque mudar para o mod_wsgi?

O mod_wsgi tem se comportado mais escalável que o mod_python. Por escalabilidade, entende-se a capacidade de um site de suportar o crescimento de uso sem perder a performance ou travar.

Ao ajustar um servidor para usar o mod_wsgi, pude notar essas diferenças. Elas não são tão grandes que se possa perceber com um simples teste com Apache Bench. É necessário forçar para notar a diferença, que tem sido até 10% superior.

Esse servidor que usei para fazer esses testes é uma VM (em Xen) com 512MB de RAM, rodando em um amd64, numa rede bastante estável, em Londres, enquanto que o Apache Bench foi executado em minha máquina.

Veja abaixo como os dois modos se comportaram:

Para compreender a legenda, o número após o "n" trata-se da quantidade de requisições enviadas e o número após o "c" trata-se da quantidade de requisições concorrentes, ou seja, "n1000c5" equivale a "1000 requisições enviadas de 5 em 5).

Tempo de resposta por requisição

Requisições por segundo

Load de 1 minuto

Load de 5 minutos

RSS / Memória real ocupada

Percentual da CPU

Conclusões

Todos os números apresentados acima não podem ser tomados como base exata para comparação, por alguns motivos, como a influência que o teste anterior efetua no subsequente, a oscilação da internet e a influência de outros processos.

Eu fiz questão de usar um servidor em produção onde está sendo servido um outro sistema da empresa, que mesmo que não estivesse em seu horário de pico, era usado normalmente por alguns usuários.

Há ainda toda a questão de controvérsias em torno do uso real da CPU e da memória.

Mas dá pra notar uma realidade clara: o mod_swgi se mostra mais vantajoso em memória e tempo de resposta. Não esqueçamos que 200 requisições concorrentes para um VPS com 512MB de RAM é uma senhora carga, equivalente a alguns milhões de pageviews por mês.

No teste de 2000 requisições a 200 concorrentes, ficou visível que a configuração de MaxRequestsPerChild (de 1000) entrou em cena e fez diferença no desempenho, tanto para segurar a carga quando para mudar um pouco a evolução do desempenho.

Por fim, devo avisar que no teste seguinte, de 5000 requisições a 200 concorrentes, o Apache caiu antes de completar 3000, em 3 tentativas.

Mais detalhes sobre o WSGI podem ser encontrados em [4], [5] e [6]

Links relacionados

[1]	http://www.python.org/dev/peps/pep-0333/

[2]	http://www.ericholscher.com/blog/2008/jul/8/setting-django-and-mod_wsgi/

[3]	http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

[4]	http://www.slideshare.net/hdiogenes/wsgi-a-resposta-para-a-questo-definitiva-sobre-python-a-web-e-tudo-mais-368429?src=embed

[5]	http://en.wikipedia.org/wiki/Wsgi

[6]	http://www.wsgi.org/wsgi/

[7]	http://del.icio.us/marinho/wsgi

Entrevista com Jacob Kaplan-Moss

Esse é um cara que eu admiro pela simplicidade e capacidade de liderança que demonstra a cada dia onde eu tenho a oportunidade de acompanhar.

Esta é a minha primeira entrevista e eu queria tirar minhas principais dúvidas envolvendo necessidades de grandes portais e sistemas corporativos, além de saber um pouco mais sobre as novidades mais quentes dos últimos mêses: Django Foundation, DjangoCon e versão 1.0.

Segue abaixo a gostosa conversa que tive com Jacob Kaplan-Moss, que poderia ter se extendido por mais um bom tempo, se não fosse a necessidade de parar por aí :)

Espero que gostem.

Marinho: bom, como eu disse, sou brasileiro, e o Brasil já tem muitos djangonautas, muita gente usando (o Django) para soluções corporativas e algumas grandes empresas começando a usá-lo em alguns projetos em fase inicial... a comunidade está crescendo e nós muito felizes :) então, minhas perguntas são relacionadas à nossa realidade.

e antes de tudo, eu gostaria de deixar você sabendo que meu inglês não é dos melhores, então, tenha paciência comigo :)

Jacob: Seu inglês está legal, não se preocupe!

É muito legal ouvir sobre o Django sendo usado ao redor do mundo; me faz realmente feliz.

Marinho: Eu noto :) você me respondeu com uma disponibilidade bacana, você parece ser um cara com boas habilidades em liderança. Ao longo da história do Django, você teve alguma situação nas relações pessoais que te desafiou?

Digo: uma situação quando você perdeu a paciência ou uma discussão ruim...

Jacob: Yeah, certamente aconteceu!

Marinho: as recentes surpresas (para nós) como a DjangoCon [5] e a Django Foundation [4] tiveram algum desses desafios?

Jacob: Nós tentamos realmente manter um tom amigável (ou ao menos educado), mas... às vezes há pessoas que são realmente difíceis de se lidar.

Marinho: Eu sei um pouco disso, e liderar uma grande comunidade não é uma tarefa fácil

Jacob: Há uma ótima palestra que Ben Collins-Sussman [1] e Brian Fitzpatrick [2] dão, chamada "How Open Source Projects Survive Poisonous People" ("Como Projetos de Código Aberto Sobrevivem a Pessoas Diabólicas") [3] cheio de bons conselhos -- as lições que eles dão têm salvado meu traseiro algumas vezes.

Marinho: legal, eu vou tirar um tempo pra assistí-lo...

agora sobre a Django Foundation [4]:

O que podemos esperar dela para os próximos anos? Que tipos de ações?

Jacob: Nós realmente não pensamos que haverá um grande avanço, honestamente. Nossa principal meta é ter um corpo "oficial" que pode representar o Django e ajudar financeiramente. Como a maioria das coisas em torno do Django, nós vamos esperar para ver o que a comunidade quer que façamos.

A grosso modo, nós vamos bancar os sprints de desenvolvedores e reuniões para ajudar o Django 1.0 a sair no tempo (certo).

Marinho: Podemos esperar por uma certificação ou algo semelhante?

Jacob: Você quer dizer algum tipo de "certificação para desenvolvedor" oficial do Django?

Marinho: sim

Jacob: Nós não temos planos para isso por agora... não parece ser algo que nós queremos nos envolver, mas como eu disse antes, se isso for algo que a comunidade realmente quer, é claro que vamos tentar ajudar.

Marinho: A comunidade de Python não gosta de certificações, mas muitas empresas gostam... é algo que as faz se sentir mais seguras

Jacob: Yeah, eu entendo... é só algo que não é muito comum no Open Source em geral; não estou certo de como isso funciona.

Marinho: sim, eu concordo.

e sobre a DjangoCon [5], que mais detalhes podemos ter a respeito? Vocês já tem alguma data?

Jacob: Nós estamos só finalizando alguns detalhes, e devo estar pronto pra anunciá-los talvez hoje, talvez na segunda.

Marinho: ótimo :)

agora sobre o ORM e novas funções...

Você tem alguma idéia de quando poderemos ter suporte a SGBDOO (bancos de dados orientados a objetos), especialmente BigTable, Amazon SimpleDB e ZoDB? Quão difícil isso seria pra fazer?

Jacob: Isso realmente é algo que eu venho pensando muito ultimamente -- repentinamente há todo um punhado desses bancos de dados não-relacionais saindo, seria fascinante suportá-los.

Eu penso realmente que nem tudo seria aquela dificuldade, no entanto você deve se lembrar que nenhum desses DBs realmente suportam joins ou outras características relacionais, então você nunca poderia mesmo só mudar o DATABASE_ENGINE da mesma forma e esperar que sua aplicação funcione.

Marinho: sim, isso é o que eu estava pensando...

E sobre suporte (aos recursos de) master/slave [6] do MySQL e conexões com múltiplos bancos de dados?

Jacob: Eu não sou de todo familiar com o MySQL, então eu provavelmente sou a pessoa errada a se perguntar sobre ele. Para múltiplas conexões, há um bom trabalho sendo feito na área; ele não estará na (versão) 1.0 por causa do tempo, mas estou esperançoso de que nós teremos em breve.

Marinho: Entendi... essa (minha) pergunta é porque a maioria dos grandes sites, como o Flickr, YouTube, Slashdot e outros costumam adotar o armazenamento de dados em muitos (e às vezes aleatórios) servidores de banco de dados.

Agora sobre o uso do Django e o futuro...

Um ou dois anos atrás, você pensava sobre o Django sendo usado como framework para se criar softwares corporativos como ERPs, BIs, CRMs, Billing (Vendas) e outros softwares para uso em empresas, especialmente não relacionados ao gerenciamento de conteúdo?

Jacob: Quando nós lançamentos a primeira release do Django, nós nunca esperávamos que ela seria largamente usado como é (hoje). Nós pensamos que talvez alguns outros publicadores online se interessariam, e talvez nós pegássemos alguma relevância na comunidade (que usa) Python na web. Nós nunca pensamos que o Django seria usado em muitos lugares (redes sociais, software corporativo/empresarial, vendas online...)

Marinho: e agora como você sente quando vê que dia-após-dia mais pessoas usam-no em tipos totalmente diferentes de soluções? Surpreso? :)

Jacob: Surpreso, sim, mas principalmente feliz. É realmente ótimo, e todos os diferentes usos confirmam que o Django realmente funciona bem.

Isto é, tendo todas essas pessoas com diferentes necessidades confirmando que nós não nos prendemos a um nicho em particular.

Marinho: sim, é verdade... Eu acho que você se sente orgulhoso quando sabe que grandes players como Google e Yandex [7] estão usando-o :)

Jacob: Exatamente -- é realmente bacana.

Marinho: O que você considera que serão os grandes desafios para o framework nos próximos anos?

Jacob: Eu acho que nosso grande desafio é lidar com nosso próprio sucesso. Nós aguardamos muito tempo para soltar a 1.0, principalmente porque nós não compreendemos quão grandes nós ficamos -- com uma pequena comunidade, você pode arriscar a se sujar. Agora que nós somos realmente um projeto de grandes proporções, nós precisamos formalizar mais o nosso fluxo de trabalho: versões planejadas e regulares, divisão mais explícita e delegação de responsabilidades, etc.

Nós também precisamos estar dispostos para uma inevitável oposição quando ela vier. Como um grande projeto você inevitavelmente terá eventualmente pessoas que simplismente te odeiam, e lidar com o lado baixo do sucesso pode ser desagradável. Eu tenho acompanhado com cuidado como a comunidade de Rails segurou a carga de "Rails não escala!" e "Rails não é seguro!" neste último ano; eles realmente fizeram um grande trabalho ouvindo as vozes racionais e ignorando as pessoas que estavam só para contrariar.

Nós vamos certamente ter "controvérsias" como essas no futuro; nós precisamos de ter certeza que nós podemos segurar isso profissionalmente.

Marinho: Eu entendo, agora o Django vive uma nova realidade, diferente de antes

Jacob: Exatamente. Nós temos que prestar atenção em como nossa comunidade se desenvolve e aceita nossa liderança ao seu encontro.

Marinho: sim, é verdade... bom, indo para o fim: o que mais você pode nos dizer? Algo quente? Alguma novidade que não sabemos?

Jacob: Hmm... nós fazemos a maioria das coisas publicamente -- a fundação e a conferência são realmente as únicas duas exceções -- então eu não acho que há algo "em segredo" por agora. A próxima grande coisa para nós é o Django 1.0 Alpha que está saindo em uma semana -- que será um grande marco, e nós precisaremos de grande ajuda para testá-la até que a (versão) 1.0 final esteja melhor possível.

Marinho: o.O ótimo, essa é uma grande novidade para a comunidade :)

bom, eu agradeço por tudo, lhe parabenizo pelo sucesso e pela boa conversa, eu sou um orgulhoso e grato djangonauta e quero ajudar sempre que puder.

Jacob: Obrigado

Links relacionados

[1]	http://www.red-bean.com/sussman/

[2]	http://www.red-bean.com/fitz/

[3]	http://vivixvideo.com/videos/ource-projects-survive-poisonous-people-and-you-can-too/

[4]	(1, 2) http://www.djangoproject.com/foundation/

[5]	(1, 2) http://www.ericholscher.com/blog/2008/jul/7/djangocon-2008/

[6]	http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-replication-connection.html

[7]	http://kuda.yandex.ru/