Migrando para o Django-1.2.1

Finalmente uma nova postagem sobre django! Estava precisando, não é mesmo? Bem, esses dias estive migrando uma aplicação do django-1.1 para o novíssimo, brilhante e cheiroso django-1.2.x, que saiu a poucos dias.

Para quem não sabe, o django é um framework de desenvolvimento web escrito em python muito popular atualmente. Em sua nova versão, com suporte a múltiplos bancos de dados e outros mimos, ele trás uma série de melhorias de segurança e arquitetura que tornam a atualização para a nova versão bastante atrativa.

As mudanças da versão 1.1 para 1.2 não tiveram um impacto muito grande no processo de desenvolvimento, mas, mesmo assim, a migração pode ser um tanto problemática caso seu projeto tenha muitas modificações suas. Aqui vão algumas dicas para quem pensa em migrar:

1. Admin já tem o jquery;
Nessa versão do django, o admin já importa o jquery por padrão (p/ changelist, add e edit), por isso, você pode utilizá-lo sem precisar importar o mesmo na classe Media do seu ModelAdmin. Para utilizar o jquery do django, você pode criar um alias assim:

var $ = django.jQuery; // alias para o jquery do django

ou assim:

(function($) {
// aqui vai seu código
})(django.jQuery);

Simples, não? O código acima é necessário pois o django.admin procura ser compatível com outras bibliotecas javascript que você pode estar utilizando como o mootools.

2. Atualize a configuração do seu banco.
Na nova versão, o tão pedido e necessário suporte a mais de um banco de dados está, finalmente, funcionando. Isso significa que você não está mais limitado a apenas uma base de dados. Por conta disso, a configuração do banco de dados no settings.py mudou. Agora, no lugar de definir apenas um banco, você deve definir um dicionário de bancos, onde o banco chamado default será o banco principal. No settings, sua configuração do banco deve ficar, mais ou menos assim:

DATABASES = { # dicionário de bancos reconhecidos
'default': {
'NAME': 'nome_do_banco',
# agora o nome da biblioteca de acesso é por extenso
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'USER': 'seu_usuario',
'PASSWORD': 'senha'
},# definindo um segundo banco
'users': {
'NAME': 'user_data',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'priv4te'
}
}

3. Atualize o admin_media
Essa dica é bem básica, mas vale lembrar. Ao atualizar para o django-1.2.x lembre-se de atualizar o caminho para os arquivos estáticos do django.admin. Se você não fizer isso, algumas coisas podem(vão!) quebrar.

4. Certifique-se de que nenhum app quebrou
Alguns aplicativos muito úteis disponíveis na internet simplesmente quebram com o django-1.2.x. Por isso, tenha certeza (testes!) de que nenhum aplicativo quebrou após a atualização.

5. Defina rotas!
Se você estiver utilizando mais de um banco de dados, certifique-se de que você definiu rotas para eles. Rotas, no django, são uma forma fácil de especificar em qual banco está cada modelo. Neste link você encontra informações de como escrever suas rotas.

6. Atualize seu TEMPLATE_CONTEXT_PROCESSORS
Na nova versão do django, os context_processors padrão mudaram. O django.core.context_processors.auth agora está em  django.contrib.auth.context_processors.auth e um novo context processor (django.contrib.messages.context_processors.messages) foi adicionado. Caso você tenha modificado o TEMPLATE_CONTEXT_PROCESSORS padrão do settings, certifique-se que os context processors acima estão definidos corretamente. Veja um exemplo:

("django.contrib.auth.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
"django.contrib.messages.context_processors.messages")

Fim ^^. Existem outros problemas que podem ocorrer, como com quem utiliza o aplicativo crsf, por exemplo, mas essa parte aí já é com vocês. Mas estão avisados ; ). Abraço!

PyDev+Eclipse+Django=bom!

Senhores, esses dias tive a boa idéia de instalar 1gb adicional de memória em meu humilde notebook. Esta feliz decisão me proporcionou mais resultados práticos do que esperava. Além de um computador mais rápido e sem "travadinhas", uma série de programas que eu não utilizava devido ao seu consumo insaciável de memória agora passaram a ser excelentes opções para mim. E quando eu falo de programas, eu me refiro a ferramentas de desenvolvimento.

Sempre gostei de testar IDE's de todo gênero. Escritas em Python, Java, C/C++, etc. O eclipse, feito em Java, é uma delas. Na época, eu queria usar o PyDev com o eclipse para desenvolver meus aplicativos, incluindo aplicativos django. Acontece que, com apenas 1Gb de memória, utilizar o eclipse era lento e tedioso. O tempo passou, adiquiri meu novo gigabyte e as coisas melhoraram. A IDE está rápida e rodando perfeitamente. Devido a este fato maravilhoso, resolvi escrever essa postagem explicando como integrar o eclipse, pydev e django, para o desenvolvimento rápido e prátivo de aplicativos.

O eclipse é conhecido de muita gente. IDE rápida, multiplataforma, escrita em Java e acompanhada de uma infinidade de plugins, ela te permite desenvolver em várias tecnologias de forma prática. Dentre essas tecnologias, está o python. Munido do plugin PyDev, que pode instalado fácilmente pelo gerenciador de plugins, como descrito na página do mesmo, é possível escrever código python com highlight e codecompletition, suporte a projetos, edição de arquivos tipicamente web (css, html, xml, etc) dentre outras funcionalidades. Até aqui, tudo bem. O grande (táh, médio...) segredo está em criar e gerir projetos django com facilidade. Como se faz isso? Fácil! 

Para criar e gerir um projeto Django com o eclipse, inicie um projeto django qualquer (django-admin startproject) e através do menu:

File => New -> Project

crie um projeto simples. Em "Use default location", aponte para o diretório do projeto django que você criou e conclua. Certifique-se que o pydev está instalado (a url do update manager é: http://pydev.org/updates) e configurado (window=>preferences->interpreter python) e mude o perfil para pydev.

Mude para o perfil do pydev clicando no ícone acima, em destaque.

Na coluna a esquerda, onde está o seu projeto, clique com o botão direito e vá na opção properties.

Nela, vá na opção Run/Debug Settings e adicione uma configuração do tipo Python Run. É aqui onde ocorre a mágica. Nesta tela você irá configurar os comandos para iniciar o servidor local do django e a sincronia do banco. Outros comandos podem ser adicionados também.

Basicamente você vai configurar o caminho para seu projeto, o caminho para o arquivo manage.py e os argumentos na tela de argumentos. Algo assim, funciona:

Você pode mudar runserver por syncdb ou outro comando.

Clique no botão de run (o verde com um triângulo, perto do menu) e adicione seus comandos prediletos. No meu caso, RunServer e SyncDB podem ser encontrados lá. 

Bem, basicamente, é isso. Adicione também o plugin de edição de HTML/CSS/ETC e seja feliz! ; )

dica:  em "Main module" utilize ${project_loc}/manage.py ao invés de workspace_loc.

Como tornar seu projeto django mais rápido!

Hoje a postagem é direcionada para quem já sabe django e quer melhorar o desempenho de uma aplicação sua. Existem diversas formas de se melhorar o desempenho geral de uma aplicação Django, entretanto, vou falar de duas técnicas bastante simples e eficazes. 

Quando se fala em melhorar o desempenho de uma aplicação, desenvolvedores com background em outras linguagens e frameworks logo pensam em adicionar cache e "melhorar o sql" das consultas. Em Django, esta não é uma forma eficiente de fazer as coisas. 

O fato de nem todo site necessitar de cache e do cache, às vezes, não poder ser usado, por possibilitar retornar dados previamente carregados quando a última informação do banco deve ser mostrada sempre, são argumentos pertinentes contra o uso de cache. Quanto a melhorar o SQL, em Django, que possui um ORM poderoso, responsável por cuidar de todo o SQL gerado, esse se torna uma melhoria que muitas vezes terá impacto imperceptível. Se você não estiver bastante conciente sobre os acessos mais comuns ao seu site e sobre a complexidade de suas querys, outras formas mais simples de melhoramento podem ser adicionadas ao seu projeto.

Evite usar locals()

No Django, normalmente, cada view é uma função responsável por receber uma requisição e retornar uma resposta adequada. A forma mais usual de retornar essas respostas é através da função render_to_response, que se encarrega de carregar o arquivo com o template Django, populá-lo com os dados de um dicionário e retorná-lo utilizando o mimetype adequado. O problema aqui está na forma como o render_to_response pode ser usado.  Vejamos a assinatura do método:

render_to_response(template[, dictionary][, context_instance][, mimetype])

Assinatura simples, com poucos argumentos. template é o nome do arquivo (html, por exemplo) que será renderizado, enquanto dictionary é um dicionário com todas as variáveis que serão disponibilizadas no template. O problema ocorre quando, para o argumento dictionary, é usado o resultado do método locals(), que retorna todas as variáveis locais. Isso ocasiona que, ao invés de usar apenas as variáveis pertinentes na renderização do template, tudo que estiver como variável local também será fornecido como argumento, tornando a busca de valores das variáveis menos eficiente e diminuindo a qualidade do código. Então, primeira regra, não use o locals no render_to_response. 

Utilize o middleware Gzip

A utilização do middleware Gzip é uma das formas mais fáceis e rápidas de melhorar o desempenho geral de um projeto django. A integração deste middleware no seu projeto fará com que os dados enviados ao navegador do usuário sejam compactados com gzip antes de ser enviados. Isso permite diminuir o tráfico geral de dados consideravelmente. Como adicionar o middleware gzip a um projeto é muito fácil, ele é a melhor forma de melhorar o desempenho de um projeto rápidamente. 

Para adicioná-lo a um projeto, edite o arquivo settings.py adicionado:

'django.middleware.gzip.GZipMiddleware',

ao seu dicionário MIDDLEWARE_CLASSES.

Além destas duas dicas simples, outras formas de melhorar o desempenho do seu site são:

• utilizar o wsgi em detrimento ao mod_python
• servir o conteúdo estático do seu site diretamente pelo servidor
• não utilizar o método len() em querysets sem necessidade

Bem senhores, é isso. Espero ter ajudado. Abraço e comentem!

Adicionando robots.txt no seu projeto Django

O robots.txt é um arquivo na raíz do seu site que informa os robôs da internet (as maquininhas responsáveis por indexar seu site em sistemas como o do google ou yahoo) o que pode ou não ser indexado. Ele é particularmente interessante ao se trabalhar em ambientes de teste disponíveis na internet ou quando não se quer alguma página específica disponível a todos. 

Em miúdos, o robots.txt é bastante útil, entretanto, sua integração ótima no Django é um pouco cabeluda. "Por quê?" Você perguntaria. Muito simples meu caro Watson, projetos Django, normalmente, utilizam uma pasta especial para servir todo o seu conteúdo estático, e essa pasta especial, normalmente, é acessada por um caminho ou path diferente da raíz. Isso quer dizer que quando um robô indexador procura o robots.txt em meusite.com/robots.txt, ele não o achará, pois o mesmo está, provavelmente, em media/robots.txt.

Para resolver esse problema, existe uma série de abordagens, como criar uma view que sirva o arquivo, por exemplo. Uma abordagem mais interessante e eficiente é utilizar o mod_rewrite do Apache nesse trabalho. O código ficaria assim:

RewriteEngine On
RewriteRule ^robots\.txt$ /media/robots.txt [L] 

(contribuição de Dave Dash)

"/media/" no caso, é o caminho para os arquivos estáticos do seu site. Estou postando essa solução (simples para quem conhece Apache) porque achei bem interessante e me tomou alguns minutos de pesquisa.

No mais, é isso. Abraço a todos!

Django Snippets - Soluções em Django

Senhores, hoje a postagem será de utilidade pública. Resolvi falar sobre esse excelente (com ressalvas) repositório de códigos para Django, prontos para serem usados.

Para quem não sabe, o Django é um excelente framework de desenvolvimento para web com python. Ele te permite criar aplicações seguras e robustas em pouco tempo. Mesmo o Django sendo "super cool", seu código é bastante enxuto, de várias maneiras. Os desenvolvedores escolheram por adicionar "pouca" coisa ao código padrão do framework, permitindo que houvesse poucas dependências. Assim, se você quer algo diferente, você tem que fazer. "Você" entre aspas! Caso você conheça o django snippets, poderá utilizar soluções bastante interessantes desenvolvidas por diversas pessoas de todo o mundo.

O funcionamento do django snippets é bem simples, existe o site de snippets onde as pessoas vão e postam suas soluções, que são tornadas públicas. Caso alguém encontre um problema na sua solução, elas podem, por exemplo, sugerir uma mudança. Infelizmente, o site não permite buscas das formas usuais. Basicamente, se você quer procurar um snippet, você deve usar o google ou procurar, página por página, na lista de snippets disponível.

Como exemplo de snippets legais que você pode usar tem o snippet de recaptcha que te permite adicionar um captcha a um formulário de busca, por exemplo, sem grandes problemas. snippet

Ou código legal é este que te permite criar objetos de paginação que tornam bastante fácil criar o Look&Feel do digg no seu site. Eu, particularmente, o utilizado no django-forumbr.

Existe uma infinidade de outros snippets que podem lhe agradar. Sugiro doar 15minutos do seu tempo, um dia desses, para averiguar o repositório do Django Snippets. No mais, é isso. Abração, senhores!

DjangoCMS2 - O primeiro Killer App do Django!!!

A muito tempo que os desenvolvedores que utilizam Django como framework Web reclamam da falta de aplicativos CMS de qualidade para integração em seus projetos. Enquanto outras plataformas possuem soluções poderosas como é o caso do Wordpress, no Django, caso o desenvolvedor não quisesse se sujeitar a aplicativos bugados ou aquém de suas necessidades, era obrigado a escrever seu próprio aplicativo CMS, o que não é lá tão trivial.

Outra solução, bem menos elegante, consiste em utilizar o aplicativo que vem junto com o django, chamado flatpages, que permite criar páginas simples em html. Algo bem aquém do que seria elegante.

Devido a isso, venho, a muito tempo, olhando sites de todo gênero em busca de uma solução CMS para django que fosse fácil e prática. O DjangoCMS sempre me pareceu um projeto promissor e ativo, nesse sentido, mas, as versões que eue testava sempre apresentavam muitos bugs. Não eram versões finais, é verdade, mas mesmo assim estavam longe de ser algo utilizável.

Hoje, ao acordar, me deparo com a notícia que o django-cms não era mais uma versão alpha, nem beta, nem RC, era sua versão final, o que me compeliu, rapidamente, a testá-lo. Quão grande foi minha surpresa quando vislumbrei suas funcionalidades e praticidade. Em minutos, com uma pequena ajudinha da lista (#django-cms no FreeNode) consegui colocar em pé o aplicativo.

Tendo todo o seu sistema de conteúdo baseado plugins e utilizando placeholders para definir onde cada plugin deve ficar, essa solução me agradou muito. Os desenvolvedores tendo feito todo um trabalho de integração com o admin, que é a interface padrão de edição da ferramenta, deixou tudo agradável e intuitivo.

Ao meu ver, o django-cms2 (ou django-cms) é a melhor solução em CMS para o Django no momento. Aconselhado! Abraço!

ps: para quem não sabe, killer app é um aplicativo tão bom que os aplicativos concorrentes se tornam obsoletos rapidamente.

Pyflakes, Python, Django, TDD e mão na massa!

Bem, anteontem resolvi que vou dar mais enfase ao desenvolvimento TDD. Essa minha pequena decisão tem por meta assegurar maior qualidade nos meus softwares e menores dores de cabeça num futuro próximo =D.

A decisão de passar a desenvolver sempre pensando no TDD não veio por acaso. Eu gosto muito de criar aplicativos, deixar eles encostados, e depois voltar e dar um gás neles. Essa minha prática me fez perceber algumas características de manutenabilidade e de qualidade que eu preciso sempre atentar. Entre elas, o fato de que eu não estava criando testes nesses meus aplicativos pessoais, e quando eu voltava e adicionava ou modificava alguma assinatura, eu acabava quebrando alguma coisa. Não que tenha sido difícil rastrear quaisquer dos erros, mesmo sem debug, mas mesmo assim, era algo que estava me fazendo falta.

Em uma rápida busca, achei no blog do marinho essa ótima postagem sobre o tema. Só vi a introdução ainda, por falta de tempo, entretanto, pretendo lê-la com muito carinho esses dias. Para quem não sabe, TDD significa Test DrivenDevelopment, ou, em português, programação orientada a testes, que é uma forma de se desenvolver onde se escreve o teste de uma funcionalidade antes de escrever a mesma. Essa abordagem tem vantagens visíveis, como citado no artigo do Marinho, principalmente no que diz respeito a qualidade de código, onde você sempre pode garantir um certo comportamento do seu código baseado nos testes dele.

De qualquer maneira, ainda no escopo de manutenção, revisão e atualização de aplicativos, acabei achando esse ótimo programa que me permite checar alguns aspectos do meu código, como erros, importações nunca utilizadas e má formatação. O nome o bixin é o pyflakes. Mesmo havendo opções mais completas, como o pylint ou pychecker, o que me atraiu no pyflakes foi a sua simplicidade. Ando utilizando ele com frequência e aconselho a todos que queiram dar uma "limpada" em seu código antes de colocá-lo em produção.

Para finalizar, como não poderia deixar de ser, gostaria de informar aos djangonautas de plantão que a versão 1.1 do framework já está disponível. Houve algumas mudanças de compatibilidade entre as versões 1.0 e 1.1, entretanto, a maioria das pessoas não terá problemas. Eu, pelo menos, fiz a migração do meu aplicativo sem mudar uma linha de código sequer. = D

No mais, é isso. Usem o pyflakes, usem o django, usem o python e codifiquem usando TDD ; )

Padrões de projeto com Django

Para quem não sabe, Django é o framework web mais maduro atualmente disponível para python. Ele é rápido, robusto, e elegante, entretanto, é muito comum as pessoas codificarem com ele da forma que desejam. Às vezes isso é algo bom, às vezes não. Pensando nisso, resolvi citar aqui algums padrões que utilizo no desenvolvimento de meus projetos e aplicativos, para aqueles que estão começando e gostariam de saber como estruturar um projeto Django de forma legível e extensível. Enjoy!

Receitas

1. Desenvola seu projeto utilizando um aplicativo para cada parte do projeto. Projetos que possuem poucos aplicativos "entupidos" de código devem ser evitados.
   
   
2. Sempre que utilizar um aplicativo de terceiros, dê uma olhada no código do mesmo. Esta á uma excelente forma de enteder como funciona e como tirar melhor proveito do mesmo.
   
   
   
3. Evite criar dependência entre os aplicativos, sempre que possível. Ou seja, não importe código de outros aplicativos do seu projeto caso não seja necessário.
   
   
   
4. Não tenha medo de utilizar aplicativos que já vem com o próprio Django, como o flatpages, para páginas ordinárias.
   
   
   
5. Se você deseja criar páginas específicas para um determinado projeto, mas que não parecem "encaixar" em nenhum dos aplicativos, você pode criar um aplicativo chamado website, e colocar o código esdrúxulo nela. Também muito útil para colocar tags e filtros customizados.
   
   
   
6. Não tenha receio de criar tags e filtros específicos para o seu projeto. Tags são especialmente úteis para criar comportamentos semelhantes em todas as páginas de um projeto.
   
   
   
7. Inicie cada um dos seus arquivos .py definindo o encoding do seu código com a seguinte:
   

   # -*- coding:utf-8 -*-

   Essa pequena linha vai lhe evitar muitas dores de cabeça com unicode.
   
   
   
8. Reescreva o método __unicode__ de cada um dos seus modelos definidos.
   
   
9. Ao definir uma url no seu urls.py, procure sempre fazê-lo utilizando o atalho url, e defina um nome fictício para sua url. Isso torna a codificação e mudanças no código bem mais fáceis. Exemplo:
   # bom!
   url("^shop/$", shop.index, name="shop.home"),
   # ruim...
   ("^forum/$", forum.index)
   
   
10. Mantenha os templates de cada aplicativo dentro de uma pasta templates no próprio aplicativo.
    
    
11. O projeto deve ter uma pasta principal chamada templates, onde páginas como base.html(página raiz extendida por outras páginas do aplicativo), 404.html e 500.html devem estar presentes.
    
    
    
12. Criar uma página form.html dentro da pasta padrão templates do projeto é uma forma útil de se manter um padrão entre os seus formulários. Por exemplo, quando você quiser mostrar um formulário para o usuário, basta retornar o formulário na resposta da requisição e "incluir" a página form.html no seu template. Apenas tome cuidado para não fazê-lo de forma imprudente, a tag include do Django não é um grande exemplo de eficiência.
    
    
    
13. Caso precise criar configurações para um aplicativo específico do projeto, não jogue essas configurações diretamente no settings.py. O settings.py já é um arquivo bem grande por sí só, e novas variáveis devem ser evitadas, ali. Uma abordagem muito interessante é criar um arquivo app_settings.py no seu aplicativo e colocar as configurações do aplicativo lá. Uma solução interessante para quem, ainda assim, quiser colocar as configurações dos aplicativos no settings.py é a seguinte: importe o settings.py no seu app_settings.py e tente configurar as variáveis do seu app_settings através de variáveis do settings.py da seguinte forma:
    

from django.conf import settings
# note que primeiro eu checo se a variavel esta definida no settings
# caso contrário, eu utilizo o valor definido no app_settings
ITEMS_PER_PAGE = getattr(settings, "ITEMS_PER_PAGE", 16)

Por enquanto, é só. rsrsrs, essa é a forma que eu trabalho, e espero que vocês gostem. Abraço!

Como separar o models do seu aplicativo em vários arquivos

Bem, para você que conhece o framework django, sabe que os aplicativos normalmente possuem um arquivo models.py onde você coloca todos os modelos do aplicativo que serão mapeados em tabelas do banco de dados.

Bem, essa abordagem é otima até um certo ponto. Ela permite centralizar o local onde seus modelos ficarão, permitindo que você faça edições no modelo de uma forma bastante prática, entretanto, dependendo da quantidade de modelos, pode ficar um tanto difícil manter o rastro do que está definido lá dentro.

Digamos que você tem mais de 20 modelos definidos dentro de um único arquivo modes.py, controlar esse pequeno monstrinho pode ficar complicado! Para resolver isso, em Django, é muito fácil.

Crie uma pasta chamada models, logo abaixo do seu aplicativo(NÃO FALEI PROJETO, FALEI APLICATIVO!!), remova o seu models.py, jogue seus arquivos .py que possuem os modelos que você quer, lá dentro, preencha o atributo app_label da classe Meta de cada um dos modelos, e depois importe os modelos que serão utilizados pelo aplicativo em um arquivo __init__.py localizado na pasta recém criada models.

Rrsrsrs, difícil? Vamos por passos:

• criar pasta models
• remover o models.py
• adicionar os arquivos .py com os modelos do seu aplicativo à pasta models
• definir o app_label ao Meta de cada modelo
• importar os modelos em um arquivo __init__.py criado dentro da pasta models

Voalá! Modelos organizados em arquivos separados! Agora, não sejamos brutos e desconhecedores da filosofia python a ponto de colocar cada modelo em um .py diferente, ok? Isso faz sentido EM JAVA, em python, isso seria uma brutalidade, quissá uma ignorância.

Abraço a todos e espero ter ajudado!

Fatos históricos devem ser celebrados!!!

Bem, vocês sabem que não é qualquer coisa que entra no meu blog(haha!), rsrsrs, mas hoje, o negócio é diferente. Há um fato histórico a ser comemorado, e um moribundo a ser lamentado.

Primeiro, às boas notícias.
Certa vez, o homem pisou na Lua...
Certa vez, a camisinha feminina foi descoberta...
Certa vez, a linguagem python foi criada...
E é nesse contexto, de fatos históricos que influenciaram diretamente na história da humanidade que venho anunciar outro fato histórico! Algo que revolucionará a entidade virtual conhecida como WEB. Um marco na história do homem. Comparável à descoberta da roda.

O FRAMEWORK DE DESENVOLVIMENTO WEB DJANGO CHEGA A SUA VERSÃO 1.0 COM MUITO LOUVOR, ESTABILIDADE E PYTHON >: D

Isso mesmo negada; depois de vários anos de desenvolvimento, cuidado e carinho, o melhor framework de desenvolvimento web chega à sua primeira versão estável e madura. Interessados em conhecer céu http, o melhor do python para desenvolvimento web, confiram o bixinho aqui
http://www.djangoproject.com/download/

Python na veia!!! >=D

Ok. Agora a notícia rum. Um dos ícones pop do brega brasileiro acaba de nos deixar...Waldick Soriano morreu ontem e talz de uma doença aí. De qualquer forma, ele deve estar tomando uma e cantando brega em um lugar melhor!

Configurando seu ambiente Django!

Facin negada! Aqui será ensinado como criar um ambiente django simples mas extremamente funcional. Sugiro a utilização do sistema Ubuntu7.10, ok?

Primeiro, abram um terminal e digitem:
sudo apt-get install subversion python-imaging python-yaml python-psycopg2

O sistema vai baixar uns pacotinhos maneiros que provavelmente você irá precisar mais cedo ou mais tarde.

Acabou? Vamos criar uma pastinha maneira para os projetos e baixar o django do repositório. Digitem:
cd # <- manda você para a pasta home, caso não esteja
mkdir Projetos # <- cria uma pasta de projetos
mkdir temp # <- pasta para arquivos temporários. Todo mundo precisa.
cd temp svn co http://code.djangoproject.com/svn/django/trunk/ # <- baixando o django
cd trunk
sudo python setup.py install # <- instala o django

Pronto, agora vamos pegar nossa IDE Django super-cool com sugar on top! entrem no site http://www.openkomodo.com/ , baixem a ide komodo-edit, instalem a bixinha(tem um INSTALL com as instruções) e pronto. Agora vamos configurar nossa komodo-edit. Abram o painel edit->preferences->Fonts and Colors, selecionem o Scheme Dark e mudem as fonts para Purisa. Sugiro também colocarem todas as fontes em negrito. Fica lindão!

Pois é, é isso. No mais, criem alguns templates que facilita pakas. Abraço!

Entre campanhas e novidades Google-fenomenais!!

Primeiro, gostaria de falar do meu contento com o Google por lançar seu mais novo projeto, que tem como alvo, os desenvolvedores de softwares online. Mais especificamente, os desenvolvedores Django!!! \ö/ !!!

Seguinte, o Google lançou o projeto AppEngine em período de testes, para que qualquer desenvolvedor python interessado possa desenvolver seu site/sistema e fazer o deploy pelo próprio google. Vantagens? Você já fez um deploy de aplicativo web não cgi na sua vida? Foi doloroso? Pois é, o Google também acha, e é por isso que eles criaram esse projeto. Além de fornecer 500mb de espaço para qualquer conta cadastrada(para a hospedagem), e uma quantidade de tráfego brutal, eles oferecem uma api e uma interface que permite fazer o deploy super fácil dos seus aplicativos. Eu ainda não testei, mas aconselho a todos os desenvolvedores python que entrem na waitlist por uma continha.

Rrsrsrs, o mais engraçado é que, dia desses, havia uma discussão no grupo do Django(primeiro framework suportado pelo AppEngine) da necessidade de um local para deploy gratuito de projetos django. O rails tinha e nós não tinhamos!!! HAHAHA! Se f****** kkkkk! Aiai, como essas coisas são engraçadas. Acho que vou criar um tópico sobre chover dinheiro, ver se alguma coisa acontece...

Certo, felicidade à parte, gostaria de falar de duas campanhas, primeiro, esta aqui sobre a Campanha Feminina Contra a Viadagem :
Rsrsrsr, tirando o lado preconceituoso da coisa, essa foi uma mensagem bastante engraçada que uma amiga me mostrou. Ela me mostrou, galera, não enviou. Mulher ainda é a única opção do cardápio e bastante apreciada!

Agora, falar de um caso sério. Hoje, passeando pela minha faculdade, ví um cartaz sobre a campanha em favor da Maconha. Quase fico deprimido ver que mentes universitárias ainda são capazes de apoiar o uso de entorpecentes desse genero. Isso é coisa de "Playboy de Merda", como diria o capitão nascimento...

Minha amiga estava discutindo a viabilidade do uso da maconha para acalentar a galera com dores fortes(glaucoma) e num sei oq, mas não sei não. Aposto que a galera que vai para essa passeata, apoiar a legalização desse entorpecente que movimenta um comércio ilegal que acaba com a vida de muita gente, não estão morrendo nem se lascando de dor. Para quem quiser conferir essa ode à decadência, o "evento" vai ocorrer na Ponte Metálica(conhecido ponto de uso da droga), dia 4 de maio.

Abraço a todos e tudo de bom ö/
ps: Pras mina, um cheiro ö/!

Frase do Dia
autor: Destemido Líder

No nordeste não falta água, falta é competência para armazena-la.

A ajuda vem de onde você menos espera! - Ide`s Django

Quem aqui desenvolve com Django levante a mão!!( ö/! ) rsrsrs, seguinte, desenvolver com django é legal, na verdade, desenvolver com python em geral é uma experiência satisfatória, BUT, a medida que você vai desenvolvendo, começa a sentir falta de ferramentas poderosas para auxiliar no seu trabalho. Escrever uma classe em python é muito fácil, mas se tivesse um jeito de escrever uma classe apertando um botão, ou dois, seria bem mais fácil, não é mesmo? E quanto a trabalhar com frameworks? Alguns frameworks usam componentes do tipo "receita", que tem uma estrutura mais ou menos definida para te dar aquela funcionalidade que faz valer o seu contra-cheque no fim do mês. Quando a linguagem é uma obra de arte, vc precisa também usar uma obra de arte para trabalhar com ela, não é mesmo?
Está certo, voltando ao começo do post, você é um desenvolvedor django que quer uma IDE ninja, com diversos recursos, e super-leve para desenvolver( se possível, com debug ). Qual escolher? Bem, o google é mãe, pai, e namorada tarada de todo mundo! Rrsrsrs, pau pra toda obra. Dando uma googlada básica, você vai achar algumas opções, comentários de algumas pessoas, etc. Se você não tem paciência para sair lendo todas as respostas do google, e quer uma solução para ontem, continue lendo, vou falar de algumas IDE's com as quais eu tenho experiência.

WingIDE
A WingIde é o carro de luxo das IDE para python, E, a bixinha vem com suporte a django. Além de ter code-completation de primeira, interface amigável, gerenciamento de projetos, ser leve, escrita em python, ela tem debug para django! Isso mesmo, que tal debugar seu site in lócuo? Beleza não é mesmo? Na minha opinião é a melhor IDE do mercado para desenvolvimento web com python. Quem gostou, saiba que ela é paga e o cabra precisa comprar sua licensa pela internet ou direto nos EUA. Nada prático.

Imagem da bixinha:

Komodo Edit
Komodo edit é uma ide gratuita, bastante completa e com recursos interessantes. Ela aceita gerenciamento de projetos, possui highlight para os tipos de arquivos mais comuns, code-completation, aceita a criação de templates do usuário e plugins, e está em desenvolvimento constante. Uma desvantagem que eu vejo no KomodoEdit é a falta de um debug legal(não achei, pelo menos) e uma interface de projetos mais amigável, nada muito preucupante, entretanto.
Eu a considero uma excelente opção gratuita, e é rapidinha a bixinha, não deixa a desejar em velocidade ;).

Imagem da ide:

Gedit
Muitas pessoas dizem que o Gedit é a ide da vez! Meu amigo Andrews Medina disse que não passa aperto utilizando o gedit, que é o editor de texto padrão do ambiente gnome. Ele possui highlight para praticamente qualquer formato, aceita plugins, navegação de arquivos, console acoplado, te deixa navegar pelo código(navegação baseada nas estruturas, tipo class, def, essas coisas), é super rápido, SUPER MESMO, e bonito. Uma das desvantagens que eu vejo nele é a falta de debug e gerenciamento de projetos. Também não achei o code-completation lá essas coisas. Entretanto, se o seu sistema é bem...modesto, ou quando você precisar de uma ferramenta de edição rápida, o gedit é uma excelente escolha!

Imagem do bixinho:


ps: esse post está incompleto. Rrsrsrs, depois coloco o resto das ide's aqui. Abraço.
ps2: faltam a Anjuta, SPE e Eric.

Fazendo deploy do Django no Ubuntu

Rrsrsrs, nada como levar um chute nos rins enquanto se está pegando fogo, não é mesmo? Nada! rsrsrs tenta fazer um deploy dos novos frameworks web, NA MÃO, aquela coisa toda New Age, aí sim vocês vão saber o que é dor! Rsrrsrs, sim, eu odiei meu deploy aqui, e é por isso que eu me sinto na obrigação (i)moral de compartilhar um pouco da sapiência que me foi compenetrada goela abaixo.

Seguinte, essa postagem vai cobrir como se faz um deploy em uma distribuição ubuntu Gutsy recém instalada. É provável que os mesmos passos funcionem para o Feisty, mas como eu não estou a fim de pôr minha mão hoje, fica como foi dito.

Ok, você, cidadão de bem, com seu ubuntu server ou ubuntu normal instalado na máquina. Agora, o que fazer? Instale o django. Para instalar o django do trunk(versão mais atual) faça:

svn co http://code.djangoproject.com/svn/django/trunk/

Note que você deve ter o pacote subversion instalado
Abra um console, vá até a pasta do do trunk que foi criada na sua máquina e digite:

sudo python setup.py install

Pronto. Doeu? Ainda não.

Próximo passo, caso não tenha o apache2 instalado, digite o seguinte comando no terminal:

sugo apt-get install apache2

O apt-get se encarregará de instalar e configurar(na medida do possível) seu apache.
Cheque pelo seu navegador se o apache2 está de pé acessando a url: http://localhost/
Abriu alguma coisa diferente de uma tela de erro? Enão está tudo certo.

Próximo passo! Intalando o mod-python. A configuração recomendada pelo site do django para fazer um deploy é através do mod_python. Existem outras formas, mas como eu fiz com essa, vcs tb vão fazer >:D Comando básico, no console:

sudo apt-get install libapache2-mod-python

Sim sim, dá trabalho, é a vida. rsrsrs, se conforme ou corte os pulsos.

PRÓXIMO PASSO!!! Agora vamos fazer um esqueminha que eu tive que fazer aqui, com relação às permissões dos arquivos.
O problema é o seguinte, você quer que o apache sirva seu site, só que o apache não tem permissão para "servir" conteúdo que não esteja em algum canto que ele mande(possa ver, executar, etc). Eu, particularmente, gosto de manter meus projetos em uma pasta no meu usuário, talvez tenha sido isso que me deu mais trabalho, MAS, como coisa fácil não tem graça, fiz do jeito que eu gostava e talz.
De qualquer forma, para a configuração que eu acabei de falar, você vai precisar fazer um pouco de malabarismo com as permissões. Primeiro, crie um grupo django_prj:

groupadd django_prj
agora vamos adicionar o usuário www-data(que é o usuário que roda o apache para você) ao nosso grupo:

adduser www-data django_prj
Pronto, agora tudo que alguém do grupo django_prj pode fazer, nosso usuário www-data também pode. Vamos dar permissões de gente grande ao grupo. Primeiro vamos adicionar a pasta onde ficam os nossos projetos django ao grupo:

chgrp -R django_prj pasta_dos_projetos
Note o comando -R. Esse comando faz com que a pasta_dos_projetos e as sub-pastas dentro dela, e arquivos, pertençam ao grupo django_prj

Por fim, adicionando as permissões necessárias(leitura e execução)ao grupo:

chmod g+r pasta -R
Rsrrsrs. Acabou? Nada!Vamos agora configurar o apache.

Pelo console, vá até a pasta onde ficam os arquivos de configuração do apache:

cd /etc/apache

Agora, em sites-avaiable criem um arquivo com o nome do seu projeto. Comando sugerido:

sudo touch nome_do_projeto

Editem este novo arquivo com as seguintes configurações (ref:pyman):



SetHandler python-program
PythonPath "['/home/seuusuario/projetos/'] + sys.path"
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE meuprojeto.settings
PythonDebug On



Acima, está a configuração de referência que eu peguei lá do blog do Andrews(link acima), só que eu gostaria de fazer uma pequena sugestão. Caso você faça referências em seu projeto a aplicativos sem especificar o caminho todo, algo como:
from forum import models
ao invés de
from projeto.forum import models
seu python path deve ficar assim:

PythonPath "['/home/seuusuario/projetos/','/home/seuusuario/projetos/projeto/'] + sys.path"

Dessa forma, seu site não quebra por problema de referência e talz. Algo como seu projeto não achar os aplicativos instalados.

Pronto, ufa...acabou? NADA! Rsrsrsrs, deixa de moleza rapaz(moça). Mostre que vc é cabra macho(rsrsr, não conheço equivalente feminino) e continue!

Agora, na linha de comando, vamos habilitar a configuração que acabamos de fazer:

sudo a2ensite nome_do_projeto

Assim, próxima vez que o apache carregar as configurações, seu projeto vai subir junto. Agora, basta fazer o apache recarregar os projetos. Comando:

sudo /etc/init.d/apache2 reload

Rsrsrs, se não aparecer nenhuma tela de erro, falta só configurar o servidor de email, o servidor de javascript/css/images e mais uma ou outra coisinha. Para tais configurações, sinto muito, mas, google negada! Meus dedos aqui já estão pedindo arrego. rsrsrs

Espero ter sido, no mínimo útil. Abraço a todos, e, lembrem-se: essa luta toda é só no começo :D! Depois fica mais fácil de fazer deploy.

As respostas que nem todo mundo entende!

Seguinte meu povo, essa foi uma semana demasiado corrida para minha pessoa. Trabalhos aqui, documentos para levar para lá, pessoas sumidas aparecendo, pessoas aparecidas desaparecendo...
Rrsrsrs, mas nada que um bom sushi não cure!

Falando em sushi, eu gostaria de fazer uma indicação de sushi-house. Por incrível que pareça, a indicação não se deve à qualidade excepcional do sushi de lá, mas sim ao conjunto! É, o "melhor não é sempre o melhor", o melhor, às vezes é o que é bom em tudo. Me justifico já. De qualquer forma, o nome do estabelecimento é Wasabi, fica em fortaleza, em frente ao Viva la vaca, outro estabelecimento ninja que frequento.

Bem, o Wasabi é um restaurante de comida típicamente japonesa(bem, quase tudo...) possuidor de um rodízio memorável! Fui-me ao local levado por minha irmã, que queria conhecer o estabelecimento. Rodízio de sushi por 19,90, eu não ia dizer não, correto?

Chegando lá, estacionamento vazio(já fiquei cismado), mas tudo bem. Perguntei ao garçon como era o rodízio, e fui informado que eu poderia comer quaisquer das comidas que estivessem nos balcões, incluso espetinhos fritos na hora, frios, e sobremesa! :D Fui ao ataque. Sushi de camarão, hot, sushi de morango, yakisoba, peixe ao molho agridoce...comi o que tinha pela frente. Tudo estava bom, nada excepcional.

Nisso, era comendo e fitando a sobremesa que estava no balcão bem em frente a minha mesa, essa composta por gelatina, bolo de chocolate, pudim, mousse de maracujá e uma espécie de bolo de coco. A sobremesa sim, era muito boa! Terrific! No fim das contas, comi bem e paguei 26 reais. É caro, vejam vocês, mas comparado com outros restaurantes do gênero, estava no preço.
Pois é, aprovei e recomendo.

De qualquer forma, vamos ao fato que dá título à esta postagem! Ontem, em mais um episódeo de insônea( maldito acometimento que me persegue ), tive um momento de iluminação!
Quando o cara não dorme, alguns devem saber, o cara fica pensando. Nem sempre sai algo de útil, mas às vezes sai. Eu acredito ter descoberto a forma perfeita para explicar a uma mulher, o porquê de um homem achar bonito duas mulheres se beijando(duas mulheres bonitas, é claro!).

Que homem nunca foi perguntado por uma fêmea curiosa o motivo pelo qual ele achava bonito ver um pornô em que duas mulheres "cheias de saúde" se atracavam filme adentro. É difícil dar uma resposta satisfatória para uma mulher sobre algo do gênero, por que não é um pensamento natural para elas. Pois é, na noite de ontem, em meu momento de epifania, descobri como executar tal proeza! A resposta é bastante simples, basta fazer uma analogia!

Diga assim: "Se você visse dois chocolates, um em cima do outro, você não iria querer comer os dois?"

Rrrsrsrs, bem simples, não é? Em um próximo post, vou falar de um fato científico informado a mim por meu amigo Nícolas. Rrsrsrs, bastante importante para o futuro da humanidade.

De qualquer forma, gostaria de dizer também que estive trabalhando em um podcast com um amigo, um DJedi(TM) , rsrs, assim que nem eu( ou não, rsrsr, vai saber! ). De qualquer forma, esse podcast deve estar saindo ou no final deste mês ou do próximo. Não sei ao certo devido a problemas de horários que vivemos tendo. Mas garanto que será bastante interessante. Vamos falar de um problema que acomete a maioria dos programadores da atualidade, e de um evento super legal que ninguém(ou quase ninguém) está sabendo.

Abraço a todos!

Direto da Espanha!!

Rrsrsrs, a informação, pq minha pessoa, não sai do Ceará nem querendo! ^^
Seguinte, falando com um amigo meu, ele me confidenciou um fato muito importate. Vamos ver se vocês concordam comigo. Pergunto: Como se chama a "Espanhola" na Espanha? Espanhola minha gente, naum tow me referindo à pessoa rsrsrs. De qualquer forma, diz aí, como se chama? Lá eles chamam de "cubana"! rsrsrs, interessante não? Gostaria de saber as raízes desse apelido diferente. Mas, se vocês pensarem bem, cuba é conhecido por fazer charuto e ter bom médico. Ignorando a parte medicinal da coisa, vamos para os charutos. Lá, os charutos são feitos de forma artezanal, onde os trabalhadores, no nosso caso, as mulheres, ficam com o fumo nas pernas, sabe. É lá que o bichin é enrolado. Rrsrsrs, nunca chega até a área mais fofinha das fêmeas. Elas ficam com o fumo entre as pernas! Rrsrsrs; Aí faz vc pensar...o apelido então naum se justifica. Bla bla bla. De qualquer forma, essa informação em muito enriqueceu o meu dia.

Como não poderia deixar de faltar, Momento Carlito!
Momento Carlito : Dê dinheiro mas não dê confiânça.

Pq num é todo mundo que sabe usar confiança direito ; )

Então, vamos ao que interessa! Seguinte, hoje tenho um truque super legal com o Django, o framework WEB do Chuck Norris! Minha pessoa, enquanto codificando um aplicativo que precisava de um fórum, me deparei com a tarefa de implementar um contador de mensagens, tópicos, etc. Algo como: Criou um tópico, aumenta o contador do Fórum. Pois é, ao invés de fazer essa "árdua", quase brutal tarefa, na view, resolvi fazer via signals. Para quem não sabe o que é o sistema de signals do django, saiba que é como se fosse um disparador de eventos. Quando vc executa uma ação no modelo, um evento é disparado. Aí, se vc atrelar um conjunto de ações ao trigger do evento, vc pode fazer algumas mágicas bem legais. Ok, chega de lenga lenga. É hora do EXEEEEEMPLOOOOO!!!!


from django.db.models import signals
from django.dispatch import dispatcher
#importando o dispatcher e o signals

# use esta assinatura de método para ser feliz!
# instance é o objeto que chamou o evento
# sender é a classe do infeliz
# signal é o sinal enviado
# o resto é o de sempre
def topico_post_save(sender, instance, signal, *args, **kwargs):
if kwargs['created']:
# checa se o objeto esta sendo criado
instance.algo.contador += 1
instance.algo.save()
# ligando a ação ao evento
# primeiro argumento é o método
# o segundo é o evento a ser escutad
# o terceiro é a classe que manda o evento
dispatcher.connect(topico_post_save, signal=signals.post_save, sender=CLASSE)


Pronto, sempre que vc criar uma CLASSE, o contador de 'algo' vai ser atualizado. Bonitin, neh?

Ah sim, para quem não conhece, Chuck Norris

Design Patterns com Django ^^, e outras dicas

Olá! Hoje é um dia especial.
- "Especial por quê?" - diz o Joãozinho!
- Pirralho lazarento, especial porque a figura de minha pessoa vai falar um pouquinho sobre decisões de design que eu uso em meus aplicativos, assim como um ou dois truques legais, que eu també uso.
De qualquer forma, melhor começar com o pé direito, não é mesmo? Então vamos lá a um momento angelical (depois eu explico o por que do nome disso ^^).

Momento Angelical
Frase do Dia: Quem não escuta conselho, escuta "coitado!".
E assim falou a nossa filósofa cafúcia ^^.

Profundo não? Uma verdadeira tigela de mingal! Rrsrsrs, mas tem um fundo de verdade nisso aí. De qualquer forma, não sei já falei de Django para as vossas ilustres pessoas. Se já falei, "aleluia!" estou produtivo. Se não, se pergunte, caso você seja um desenvolvedor, se pergunte no âmago de seu ser por quê diabos vc não sabe do que estou falando! Um absurdo, criatura! Django é o framework WEB escrito em python mais quente do momento(quem falar em Plone/Zope, leva pedrada pela falta de cortesia). Leva padrões de desenvolvimento como DRY, KISS, MVT(C?), Ajax, Json, ORM, OO, e um monte de siglas de gente grande bem a sério. Esse post é PARA QUEM JÁ CONHECE DJANGO!!!.

Oh My God, they killed Kenny! You bastards! rsrsrs Pois é, esse é um post para público específico e especificado. Depois coloco um tuto aqui, mas esse depois não é agora.
De qualquer forma, eu vou falar de uma solução legal que pode ser acoplada no seu aplicativo django, e uma sugestão de organização de projeto. Algo que eu faço aqui e me agrada.

A solução facila criar decoradores que aceitam argumentos de uma forma fácil. A grande ironia da coisa é que se usa um decorador para fazê-lo. Vou logo avisando que essa solução não é minha e eu não lembro de onde peguei. De qualquer forma, se alguém achar o link e quiser postar aqui, está bem vindo.

A solução consiste em se criar este pequeno decorador:

decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda func: decorator(func, *args, **kwargs)

Eu acho uma solução legal. Veja, na pior das hipóteses, funciona a contento! Eis aqui um exemplo de utilização:


@decorator_with_args
def notify_admin(view,message):
def some_func(request, *args, **kwargs):
pass #... envia a mensagem ou coisa do genero
return some_func


Esse decorador tem me evitado muito ninjutsu pythoniano.

Quanto a solução de design, estou meio sonolento, e por isso, vou ser bem direto. Ela consiste em criar um aplicativo controle, um aplicativo accounts e um package _lib para todo projeto que você fizer(dependendo das suas necessidades). O primeiro consiste em ser um aplicativo para "coisas". Você coloca views que não se encaixam em outros aplicativos nele. Inclusive, views que, por serem bem específicas, não merecem um aplicativo só para elas. Colocar templateTags e filters nesse aplicativo facilita as coisas, assim como o UserProfile(profile do usuário) e UserData(dados extras do usuário, como endereço, etc. Tenha-o linkado no Profile), que também "devem" ficar nele. O accounts é basicamente o que ele diz que é, serve para o usuário bulir na sua conta. Eu tenho criado gosto por ter um app desses nos meus projetos. Ele facilita bastante as coisas. Um negócio que fica legal também é criar um sistema de mensagens entre usuários nesse app. Dá para linkar tudo no mesmo canto; bastante prático.
Por ultimo, o _lib. Nele eu coloco bibliotecas/funções/classes que devam ser compartilhadas entre todos os aplicativos. Definir errorLists customizados nele, por exemplo, fica bem legal.

Rsrsrs, é, cansei...ops, Acabei! :D! Espero que este post tenha ficado interessante, ou não >: D. Rrsrsr, intelegível, pronto! Espero que tenha ficado intelegível! ^^ Abraço a todos.