Segue para o conteúdo

Artigos marcados como ‘python’

2
jul

Interface Admin do Django: um baita quebra-galho.

Já faz algum tempo que nós aqui na Triveos estamos usando Django e Python. Também tenho apresentado palestras e ministrado cursos de Django em vários lugares. Temos até mesmo um curso online de Python e Django à venda em um site desenvolvido em Django.

A Interface Admin do Django

A Interface Admin do Django

Todos os programadores Django adoram falar sobre um dos grandes diferenciais desse framework: A Interface Admin.

Realmente, só quem desenvolve aplicações Web a bastante tempo e perdeu tempo precioso fazendo “telinhas de cadastro” sabe como essa tarefa é chata e pouco desafiadora. E todos que desenvolvem com Django agradecem a existência dessa funcionalidade.

A interface Admin do Django é prática, fácil de ser usada, e bonitinha. Uma mão na roda. Um baita quebra-galho. Até mesmo… mágica! A diferença entre um projeto entregue e um projeto atrasado.

Mas isso termina por aqui.

A interface de Admin do Django tem uma função clara: administrar o sistema. Tanto que ela foi feita para ser acessada só por usuários do “staff“.

Ela foi feita para que os desenvolvedores do site não percam tempo fazendo cadastros “bobinhos” que precisam ser mantidos só pelos funcionários da empresa.

O Django nasceu no mercado editorial e o primeiro projeto desenvolvido nele foi um gerenciador de conteúdo (CMS). A interface de Admin do Django servia (serve?) para que os editores, jornalistas, autores, etc. inserissem conteúdo nos sites dos jornais do grupo The World Company.

A interface Admin não foi feita para você desenvolver toda a sua aplicação nela. Ela é muito poderosa e até faz algumas coisas além de permitir somente a inclusão, visualização, alteração, e exclusão de conteúdo. Ela permite ordenar registros, efetuar buscas, definir ações, etc. Mas paramos por aí.

Funcionalidades mais elaboradas ou que precisam ser acessadas por pessoas que não fazem parte do “staff” continuam tendo o seu desenvolvimento necessário.

No site Ludeos, que foi desenvolvido em Django, a interface Admin ainda é usada para verificar os pagamentos dos cursos, e na manutenção das lojas e produtos. O fato do Django oferecer essa funcionalidade pra gente fez a diferença entre um projeto “atrasado” e um projeto “no ar”.

Mas o uso da interface Admin é um fator limitante para o nosso uso do sistema. Fica claro que, para que o projeto evolua, será necessário tirar algumas dessas funcionalidades da interface de Admin.

Em resumo: usem a interface Admin, mas saibam que em determinado momento ela pode limitar as suas ações e, nestes casos, Django oferece outras alternativas pra te ajudar a deixar a interface Admin: Generic Views. Falaremos sobre elas em outra oportunidade.

8
jun

Django-ZODB 0.2rc1 lançado

Post rápido pra anunciar que hoje eu subi o módulo django-zodb-0.2rc1 no PyPI. Publiquei essa versão para que outros pythonistas que usam Django e/ou ZODB possam colaborar com o projeto.

A ajuda que preciso com maior urgência é para corrigir os meus erros de inglês na documentação (deve ter toneladas deles no README.rst) e completá-la (removendo os XXX). Consertando os bugs que forem aparecendo e finalizando a documentação eu já lanço a versão 0.2final. Modificações que mudem a API só entram nessa versão se forem pra corrigir erros de design.

Novas funcionalidades podem ser incorporadas em um branch separado. O projeto está hospedado no github, portanto, isso é fácil de se fazer. Tem uma mini-lista de coisas que ainda faltam ser feitas no fim do arquivo README.

Layout provisório do site do projeto Django-ZODB

Layout provisório do site do projeto Django-ZODB

Já tenho um template pronto para o site do projeto mas não poderei trabalhar nisso nos próximos dias. Se alguém quiser mexer nisso é só falar comigo.

25
abr

Trabalhando com Python e Django à moda Osvaldo

Esse post está aqui para ser usado por mim como referência futura mas, como pode ser útil para outras pessoas vou deixá-lo público aqui no blog.

Software

Trabalhei muito tempo com Linux (e alguns outros Unices) e de três anos pra cá sou mais um Apple Fanboy que usa o excelente OS X. Mas acho que boa parte das dicas aqui ainda são úteis para usuários de Linux.

  • Terminal.app – Porque Mac é máquina pra ‘macho’ :D
  • bash – Pesadão, bloat, mas não consegui me habituar com outro. É o default do OS X.
  • Vim – Esse é o editor pra tudo. É difícil de aprender a usar mas é um F1. Depois que aprendemos a lidar com ele a gente voa. Uso a versão texto que acompanha o OS X.
  • TextMate – Esse eu uso para o desenvolvimento ‘pesado’. Dá pra usar o Vim pra isso também. Mas dependendo do meu humor eu escolho o TextMate para algumas coisas.
  • Rudix – O OS X não vem com tudo mas você encontra o que falta no Rudix.
  • Git – Uso o git pros meus projetos mas também tenho o Mercurial, Bazaar, Subversion, … instalados para contribuir com outros projetos open-source
  • virtualenv – ter um ambiente isolado para cada projeto Python onde você trabalha é muito legal. Já escrevi sobre o virtualenv aqui.
  • pylint e pyflakes – Analisadores estáticos de código.

Diretórios básicos

  • $HOME/
    • Work – Diretório onde os projetos em que trabalho ficam.
    • bin – Diretório com scripts, binários estáticos, etc. Esse diretório fica no $PATH

Configuração

Sempre que eu falar sobre um arquivo de configuração específico você pode encontrá-lo no endereço: http://github.com/osantana/personal.

Os arquivos ‘.’ (ponto)

.profile

  • Configurar 3 aliases: mv='mv -i' e cp='cp -i' pra evitar acidentes com arquivos sendo sobrescritos e ls='ls -G' para habilitar cores no comando ls.
  • Configurações genéricas para cores no terminal
  • Definir o vim como EDITOR padrão.
  • Definir LANG e LC_CTYPE como en_US.UTF-8 para que o Mercurial e alguns outros softwares funcionem corretamente.
  • Adicionar o diretório $HOME/bin ao $PATH. Nesse diretório eu jogo todos aqueles programinhas utilitários usados no dia a dia.
  • Configurações Python:
  • Configuração Java: export JAVA_HOME="/Library/Java/Home"
  • Configuração Ruby: adicionar $HOME/.gem/ruby/1.8/bin ao $PATH
  • Eu uso virtualenv em todos os meus projetos então crio duas funções para ativar os ambientes e entrar nos diretórios desses projetos: 
    # Uso: p nome_do_projeto
p() {
    cd ~/Work/$1*
    [ -f bin/activate ] && source bin/activate
}
 
# Uso: c
c() {
    [ -d "$VIRTUAL_ENV" ] && cd $VIRTUAL_ENV
}

.gitconfig

[user]
	name = Osvaldo Santana
	email = osantana na triveos.com
[color]
	status = auto
	diff = auto
	branch = auto
	ui = auto
	grep = auto
[alias]
	st = status
	ci = commit
	co = checkout
[merge]
	tool = opendiff
[core]
	legacyheaders = false
	excludesfile = /Users/osantana/.gitignore
    whitespace = trailing-space,space-before-tab
[apply]
    whitespace = fix
[repack]
	usedeltabaseoffset = true
[git-tmbundle]
	gitx-path = /Application/GitX.app/
[mergetool "opendiff"]
	cmd = opendiff
	trustExitCode = true
[clean]
	requireForce = false

.gitignore

.DS_Store
*.py[co]
*.tmproj
*~
*.swp*

.inputrc

Eu uso o modo vi também no console. Neste arquivo fica essa configuração e mais umas outras que deixam o comportamento do prompt do Mac mais parecido com o do Linux.

Já falei sobre essas configurações aqui no blog. Use por conta e risco.

.pylintrc

As configurações que eu uso para análise estática do código que eu produzo. Eu rodo o pylint antes de fazer o commit do meu código. Durante o desenvolvimento eu uso somente o pyflakes que é mais simples e rápido mas faz uma análise mais superficial do código. Eu costumava usar o pep8.py mas já faz um tempo que o aposentei.

.pystartup.py

Script executado pelo interpretador Python ao entrar no modo interativo. Eu configuro o ‘auto-completion’ do prompt interativo do Python, gravo o histórico de comandos, etc.

Infelizmente ele não funciona com o Python padrão do Mac porque o mesmo não é compilado com a biblioteca readline. Mas no Linux ele (deve) funcionar certinho.

.vimrc

Esse é o meu famoso arquivo .vimrc. Ele não tem nada de muito especial.

Outros arquivos

Existem outros arquivos mas, nestes casos, eles contém informações privativas e não faria sentido colocar aqui pra vocês :)

Criando e Usando um projeto Python (com Django)

Para exemplificar vamos criar um projeto “pythonologia”:

~ $ cd ~/Work
Work $ virtualenv --no-site-package pythonologia
New python executable in pythonologia/bin/python
Installing setuptools............done.
Work $ p pythonologia
(pythonologia) pythonologia $ easy_install django
(pythonologia) pythonologia $ django-admin.py pythonologia
(pythonologia) pythonologia $ cd pythonologia
(pythonologia) pythonologia $ git init
(pythonologia) pythonologia $ git add *.py
(pythonologia) pythonologia $ git commit -m "Initial commit"

Projeto criado e a estrutura de diretórios vai ficar mais ou menos assim:

~/Work/pythonologia
       |____ pythonologia
       |     |____ app_django1
       |      \___ app_django2
       |____ bin
       |____ include
        \___ lib
             \____ python2.6
                   |____ distutils
                    \____ site-packages

Os arquivos que não são mantidos no repositório Git ficam no diretório ~/Work/pythonologia ou em um diretório ~/Work/pythonologia/files. O arquivo de projeto do Textmate, por exemplo, fica em ~/Work/pythonologia/pythonologia.tmproj.

Eu também crio um link simbólico ~/Work/pythonologia/django -> ~/Work/pythonologia/lib/pythonX.X/site-package/Django-1.1.1-py2.6.egg/django para dar uma ‘espiada’ no código do Django quando necessário.

Quando eu quero trabalhar num outro projeto eu faço:

(pythonologia) pythonologia $ deactivate
pythonologia $ p outro_projeto
(outro_projeto) outro_projeto $

Eu estou num diretório qualquer e quero voltar para o diretório raiz do projeto basta fazer:

(pythonologia) ~ $ c
(pythonologia) pythonologia $
« Artigos Anteriores