Viagens, opiniões e afins

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.

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:

Depois coloque um arquivo dentro para substituir:

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.

Uma das coisa que me incomodam bastante no meio de informática é que muitos de nós são um tanto radicais. Canso de escutar pessoas dizerem que somente a tecnologia delas  – que elas usam – é a melhor. Em minha humilde opinião, comentários a parte (já escrevi, inclusive, sobre isso), não existe o ideal e a tecnologia mais adequada para o problema.

Como disse antes não quero me ater a discussão do porque não existe uma tecnologia legal e se devemos conhecer mais de uma pois isso, já amplamente abordado inclusive por mim.  Quero apenas rebater um poucos os fanáticos.

Atualmente temos uma clara evolução do uso de duas tecnologias principalmente: Python e Ruby. O Ruby quase exclusivamente impulsionado pelo Rails ( framework de desenvolvimento altamente produtivo de aplicativos web) e python pelo seu poder ( o famoso battery include) e também por alguns de seus frameworks ( Django, Web2Py, Zope, Plone, etc)

Uma coisa que me incomoda um pouco na galera é que por muitas vezes, o pessoal que está chegando agora, vem tomando logo formas de pensar radicais. Um exemplo disso é o discurso mais do que batido que Java é mal.

Gente, sinceramente, Java não é mal. Muito pelo contrário, foi uma grande porta, primeiro passo, para todo esse boom que temos visto. Java, embora não seja  opensource, sempre fomentou o software livre e acabou por criar uma comunidade forte em seu entorno. Essas mesmas comunidades  que são veneradas por  muitos dos que negam o java,  surgiram desse movimento graças ao Java.

O grande problema, da linguagem,  que ela parou no tempo. O que por um bom tempo, sobre somente alguns pontos de vista, ajudou a protegê-la foi o mesmo que a engessou-la. Se ela tivesse se aberto para modificação, mesmo que gradualmente, possivelmente  ainda estaria sendo usada e adorada como antes.

É certo que criar um aplicação em rails é muito mais produtivo do que criá-la em Java ( mesmo com todos os frameworks existentes).  O mesmo vale para o Python em até outros casos.  Então por que estou, aparentemente, defendendo-a? Simples, pois quero mostrar que ainda existe vida após a morte nesse nosso mundo de TI.

Java , para “competir”  com essa galera tem “renascido” com outras formas que permitem sermos mais produtivos.  Um exemplo que gosto muito é o Groovy. O Groovy, senão me engano, foi criado por 2002 ou 2003 como uma linguagem alternativa para rodar dentro da JVM (java virtual machine). Graças ao seu sucesso foi implementada a um especificação para tornar a JVM capaz de entender outras linguagens.

Groovy é um Java melhorada e evoluído para os moldes desses novos paradigmas trazidos por Ruby, Python, etc.  Trouxe uma produtividade maior. Hoje é possível fazer uma aplicação nos moldes de Rails em “Java” /groovy usando o framework Grails.

Outra faceta desse mesmo ponto de vista tem sido o JRuby. JRuby é uma implementação do interpretador do Ruby para a JVM. Assim é possível executar código escrito em Ruby a partir da JVM.

A coisa não para por aí. Basta uma simples busca no google para vermos outros exemplos desse renascimento em outras formas do Java.

E ainda tem a pŕopria linguagem que não para de evoluir e ainda tem o seu espaço. Acredito sinceramente, que existem alguns problemas (requisitos)  os quais a melhor solução seja implementar a solução em Java.

Bom com certeza ainda terão aqueles que dirão que suas linguagens tem as melhores ferramentas. Concordo plenamente. Para mim, falando por exemplo de testes – TDD e BDD,  cucumber, rspec, mocka, should-dsl, lettuce, entre outras são estado da arte. Porém, já encontrei coisas em “Java” (entenda aqui conseguir testar código java, pois tem ferramenta em Groovy por exemplo) que pelo menos chegam perto disso.

Bem a princípio era isso que gostaria de dizer, até a próxima pessoal.

Hoje, o pessoal da pythonOnRio, #horaextra, dojoRio, e muitos outros se encontraram na Myfreecomm para fazermos um Sprint Day para fazermos o site do PythonCampus. O PythonCampus é uma iniciativa da galera de levar uma caravana de pessoas apaixonadas por tecnologia para as universidades para mostrar que é possível transformar a paixão por tecnologia em uma carreira de sucesso.

Essa iniciativa vem desde do ano passado e já percorreu diversas entidades no rio e em outras cidades, sendo um sucesso por onde passa.  Mas sempre sentíamos falta de termos um canal de comunicação, mais precisamente, um site.  Um site onde pudéssemos colocar mais informações sobre essa galera, oque fazemos, como fazemos, como nos contactar, página de eventos, etc.  Tudo isso começa a se tornar possível graças a um dia como hoje.

Nesse dia, várias pessoas se juntaram no escritório da MyFreeComm, no rio de janeiro, em pleno feriado com dia ensolarado e com céu azul, para fazer um sprint de um dia onde o objetivo era fazer o máximo possível para colocar um site para a nossa comunidade no ar.

O primeiro desafio vou descobrir o que fazer. Henrique Bastos orquestrou os trabalhos e durante toda a manhã, promoveu brainstorms, backlog plaining, e outras coisas tão interessante quanto.  Apesar de termos demorado um pouco mais do que eu gostaria, o resultado não poderia ser melhor: começamos nossa tarde com um backlog muito bem definido, como a ideia geral do que queremos para o site e com todos os integrantes vibrando na mesma frequência.

Terminado nossa reunião partimos direto para colocarmos as coisas em prática.  Alguns estavam incrédulos quanto ao fato de conseguirmos entregar o site funcional em apenas um dia.  E foi exatamente isso que aconteceu.

Em breve coloco os links para as fotos do making off.     E para quem duvidou : pythoncampus.org