Fork me on GitHub

Viagens, opiniões e afins

by Andre Fonseca


Confie na sua intuição e não seja teimoso.

Hoje o post é mais filosófico do que técnico. Quero mostrar para a seguinte mensagem: “Confie nos seus instintos.. eles podem te poupar um bom tempo”.

Estou trabalhando num projeto onde estou usando o Django/Python. Excelente produto. Isso mesmo produto. Acredito sinceramente que o Django é um excelente produto que a gente customiza para as nossa necessidades. Diferente dele, o Rails por exemplo é mais um conjunto de ferramentas que a gente usa para fazer nosso produto.

Bom dito isso, e voltando ao tema, estou fazendo um projeto com o Django. Não sou um profundo conhecedor dele. Estou bem longe disso, a cada dia que passa vejo que tem mais coisas. A quantidade de “moles” que e as dúvidas simples me provam isso.  Uma das coisas que acredita seja “killer” nele é o fato de dar um admin muito bom e relativamente simples de customizar. RELATIVAMENTE simples.

Em um post anterior mostrei, de forma bem superficial, como você pode alterar a forma que ele montar seus forms ou listagem. A princípio basta que sobrescreva seus templates padrão seguindo um padrão e tudo funcionará como mágica. Porém, se quiser customizar o fluxo dele… Ah ! aí começa toda a dificuldade.

O Django tem um fluxo bem definido para suas ações de CRUD e isso para muitos dos caso é o suficiente. Mas se tiver um bom designer em seu time e ele te peça algo relativamente simples: Quero que esse form abre dentro e um popin (lightbox) e que ao salvar atualize a listagem e caso tenha erro mostre erro e mensagem na cortina (alert), além disso eu quero poder abrir esse form em outra listagem e o comportamento será outro.  Ufa !!! Aí a brincadeira começa a ficar séria

Bom, não adianta temos recurso infinitos a nosso dispor se a gente não sabe usar.  Partindo desse pressuposto, pedi ajuda para meus amigos que são especialista no Django. E eles me disseram para insistir em usar o ModelAdmin do Django. Segui esse caminho, mesmo minha intuição dizendo para esquecer isso e fazer tudo do zero (usar uma view).

Foram 6 dias brigando com as coisa e no final não consegui avançar mais que alguns milimetros em direção a entrega. Resolvi confiar na minha opinião e fiz tudo com view. Foram 4 dias para fechar tudo. Ainda faltam alguns detalhes que fogem o escopo original.

Por isso, como disse, confie na sua intuição (entenda aqui na sua experiência, no seu “sentimento” em relação ao problema).  Sempre peça ajuda a alguém, pesquise… Não seja teimoso só por ser… Seja crítico e saiba escolher os seus caminhos.

 

 

Published by Andre, on dezembro 8th, 2011 at 10:28 am. Filled under: agil,python Tags: , , , No Comments

Customizando a renderização do template de form do admin do Django

Esse post é daqueles da série para nunca mais esquecer.  No projeto que estou atualmente, precisei customizar a forma que o Admin do Django montar os formulários de CRUD para um determinado modelo. Antes de mais nada vamos a uma breve introdução.

Django é framework feito em python para a criação de webapps. Sua grande feature é a facilidade de construir sistemas com pouco trabalho. Isso se dá pela sua filosofia de coisas plugáveis e de ter praticamente, se sua app se encaixar no modelo CDA e CMS, tudo pronto bastando ativar as coisas (gestão de usuário, CRUDs dos modelos,  sistema de permissão, etc.)

Sinceramente isso é maravilhoso se você não fugir muito da formato que já mencionei antes. Caso precise de ir mais além ou então precisa modificar um pouco as coisas do que se espera que elas sejam, a coisa ganha uma complexidade. Mas calma… Também não é nenhuma ciência de foguete… Com um simples passo a passo, é simples mudar a cara de um formulário, listagem ,etc.

Voltando a minha história,  nesse projeto tive que fazer um CRUD onde a tela fugia um pouco do padrão de formulários:  forma dos campos, layouts, etc.  Para resolver isso procurei pelo google como fazer para customizar o template do admin para usar um meu e não o default da app.  Para quem já trabalha com Django sabe, que nem precisava dessa busca do google, pois não existe melhor site de documentação do que do Django.

Partindo para a documentação do Django, consegui fazer o que queria e achei alguns passos e truques que quero compartilhar com vocês.

A receita é bem simples:

Primeiro você deve criar dentro da sua app uma pasta onde ficará o template do form que irá substituir do admin:

minha_app/templates/admin/minha_app/meu_modelo/

 

Depois coloque um arquivo dentro para substituir:

minha_app/templates/admin/minha_app/meu_modelo/change_form.html

 

Com isso, o Django passará a usar esse arquivo para renderizar o form de criação e alterado do seu modelo. Além disso você tem que ter o form o e model admin definidos. Veja a documentação para mais detalhes.

Agora vão as dicas com os pulos do gato:

1. O Django tem a estranha a mania de tentar resolver as coisas ao invés de mostrar os erros. Assim, caso seu template tenha algum erro ele irá usar o template dele para montar e não te mostrará nada. Uma forma de forçar o erro é de alterar o caminho do template no seu form e assim ele não fará o chain e não esconderá o erro.

2. Caso queira mudar todos os forms, coloque o template na raiz do projeto e não da app.

Published by Andre, on novembro 25th, 2011 at 6:38 pm. Filled under: django Tags: , , No Comments

Bilbiotecas, frameworks, etc para MVC no Javascript

Escrevi um tempo atrás um artigo onde falava sobre MVC no javascript. Só para recapitular, MVC é um pattern que visa a separação da lógica de apresentação, controle e modelo de um sistema. Como uso cada vez maior de javascript em nossas páginas (front ends) fica evidente que precisamos buscar melhorar a estrutura de nossos códigos para que fica fácil evoluir, entender e manutenciar.

No artigo passado apresentei o conceito e mostrei, bem superficialmente, o que é e como fazer isso. A idéia é aprofundar mais no assunto e mostrar bibliotecas que vão facilitar nossa missão.

Primeira coisa que gostaria de abordar é Orientação a Objeto. A maioria dos desenvolvedores que conheço – de javascript (alguns só de jquery) – parecem desconhecer que a linguagem tem esse recurso e quão ele é poderoso. Tudo bem que o mecanismo não é dos mais simples de entender e implementar (prototype) mas existe e funciona.

Eu, pessoalmente, gosto muito de colocar a minhas lógicas em classes. Isso me ajuda muito a definir as relações e as interações entre as camadas, atores, modelos, etc.

A primeira dica que fica, para a questão de classes em Javascript, e que existem algumas bibliotecas que facilitam (bastante) a tarefa de criar classes e definir seus métodos. Um catálogo delas é o MicroJS.

Existem outras opções mais extensas ( Prototype, Mootools, etc) mas acredito que elas tenham mais do que precisa.

Um pequena brecha para falar uma coisa: hoje penso que tem gente baixando um monte de JS e só usando 10% que é a parte que realmente precisa. Isso vou deixar para falar em outro post.

Agora imagina que você irá implementar uma interface toda estática, cuja o conteúdo será populado e gerenciado através do Javascript. Se acha que isso é só um exemplo, veja o tempo Real de futebol ou cobertura do Rock in Rio (cobertura de eventos da globo.com). Imagina como seria a complexidade do código para implementar tal cenário.

Você tem diversos elementos e interações na página, ciclos de vida, paginações, animações, requisições, eventos, etc. Se você fizer isso, só com funções, sem separar nada, o código se tornará um inferno – mal escrito, e impossível de dar manutenção.

Se resolver isso com classes, mesmo assim terá um monte de código que com o tempo se tornará inviável. Embora seja um caminho.

Por fim, você pode optar por algum framework que permita separar tudo e promova suas interações de forma simples. Um bom exemplo disso é a BackBone.js . Ele permite que você separe, já disse isso, muito bem as responsabilidades e torna fácil as interações.

Num próximo artigo vamos entrar em mais detalhe sobre o backbone.

Referências:

[1] http://pt.wikipedia.org/wiki/MVC – Model-view-controller (MVC)
[2] http://microjs.com/ – Catálogo de MicroJS.
[3] http://mootools.net/ – Página do Mootools
[4] http://www.prototypejs.org/ – Biblioteca Prototype
[5] http://www.slideshare.net/leobalter/javascript-sexy-com-jquery-underscore-e-backbone – Apresentação do BackBone.js
[6] http://documentcloud.github.com/backbone/ – Pagina do BackBone.js

Published by Andre, on outubro 27th, 2011 at 9:10 am. Filled under: tutoriais Tags: , , , No Comments

Python Decorators

A um bom tempo atrás (dezembro de 2009) escrevi um artigo sobre “decorators” em Python. O texto foi inspirado num post no blog do pessoal da Artima( mais precisamente do Bruce Eckel) que falava sobre o assunto.

De lá para cá, apareceram mais artigos e o uso de decorators ganhou bastante força em bibliotecas, frameworks, etc. Diante disso, e de diversos pedidos que recebo, resolvi re-visitar o assunto.

No wiki do Python, a definição de decorator, é de uma forma que temos para alterar um comportamento de um função ou métodos dentro de um código. Seria como se pudéssemos adicionar ou até alterar a lógica sem sermos muitos intrusivos.

Um bom exemplo seria o decorator classmethod. Veja abaixo:

class OlaMundo(object):

    def metodo1(self):
        print "Ola Mundo"

Na classe acima, para usarmos o método “metodo1″, precisamos de uma instância de OlaMundo.

olaMundo = OlaMundo()
olaMundo.metodo1()
OlaMundo.metodo1(olaMundo)

Para transformar o metodo1 ou escrever um metodo2 que pertença a classe e não a uma instância, você tem que fazer:

class OlaMundo(object):

    def metodo1(self):
        print "Ola Mundo"

metodo1 = classmethod(metodo1)

Já o decorator, como uma macro em C, tornar o código mais legível e faz essa “mágica” para a gente:

class OlaMundo(object):
    @classmethod
    def metodo1(self):
        print "Ola Mundo"

O que são os Decorators e como funciona:

Os decorators do Python são como macros ( já disse isso) que quanto o interpretador os encontra os substitui por um estrutura que foi definida. No caso do classmethod ele “substitui” pela a chamada original.

Claro que a definição acima é simplista, mas ajuda a entender.

Nos aprofundando mais, ele é semelhante ao with do Python. Ele é uma classe que no seu init recebe o objeto a qual foi associado e um método call (ele é um Callable). Esse método call é chamado e ai você pode fazer algo.

class MeuDecorador(object):
   
    def __init__(self, function):
        self.f = function
   
    def __call__(self):
        print "Ola Mundo"
@MeuDecorador
def funcao():
    print "algo assim"

funcao()

O código acima mostra bem (execute-o) como funciona um decorator. No meu caso, eu simplesmente coloquei um print. Mas no método eu posso abrir um conexão, colocar um log, medir tempo, colocar numa, fila, emitir um sinal, adicionar o método como callback numa evento, etc.

Para que servem e por que usar:

Decorators não trazem nenhum grande novidade a linguagem (está desde a versão 2.2 se não me engano), mas alteram e melhoram a sintaxe de nossos códigos facilitando a compreensão do que está acontecendo ali.

Referência.
[1] http://wiki.python.org/moin/PythonDecorators
[2] http://www.tocadoelfo.com.br/2009/10/python-decorators-uma-introducao.html
[3] http://devlog.waltercruz.com/python_decorators
[4] http://www.ibm.com/developerworks/linux/library/l-cpdecor/index.html
[5] http://wiki.python.org/moin/PythonDecoratorLibrary

Published by Andre, on outubro 25th, 2011 at 8:38 am. Filled under: atualidades,django,python Tags: , , , No Comments