Compartilhar prints com Django

Webprint

Algum tempo, desenvolvi um site com Django para compartilhar prints, motivado pela falta de praticidade do envio e visualização dos mesmo por email ou jabber. Seu código está disponível no meu GitHub. Não irei abordar como desenvolver um aplicativo Django neste post, porém vou deixar o link do tutorial da documentação oficial que é muito bom e da para se ter uma ideia inicial do seu potencial e praticidade, infelizmente apenas em inglês (https://docs.djangoproject.com/en/1.6/intro/tutorial01/, esse link é da versão 1.6, a mais atual na data de publicação deste post, porém é só procurar por tutorial na página principal da documentação de qualquer versão).

O meu objetivo aqui é mostrar o motivo de inicialmente ter gostado do Django, passado um tempo longe e posteriormente reconhecer o seu potencial. A primeira vez que tive contato com o desenvolvimento no mesmo foi maravilhoso e ver como as coisas eram práticas. Acesso ao banco de dados, formulários, templates, tudo era bem interessante e organizado.

Apesar das coisas serem práticas e ter um conhecimento razoável de Python na época, passava muito tempo pesquisando a documentação e sentindo que estava escrevendo uma coisa diferente de Python, apesar de ser a mesma linguagem. A falta de uma IDE com recursos avançados pode ter tido seu peso nisso. Porém não entender como era o seu fluxo com o HTTP e funcionamento com os middlewares do WSGI (que eu não tinha a menor ideia do que era na época) deixavam as coisas obscuras. Para quem veio de programação web com PHP e sem a utilização de um framework, acabei não gostando muito.

Tempo depois conheci o Bottle, por ser extremamente minimalista tive a impressão de voltar a programar da forma que tinha com o PHP. Como ele é extremamente simples (apenas um arquivo .py) e funcionar corretamente no Python 3 virou meu padrão de pensamento e tive a impressão de realmente programar para a web em Python.

Porém nem tudo é simples, utilizando-o diariamente no trabalho notei que passava muito tempo escrevendo código para acessar o banco, que logo foi adotado um ORM, porém para formulários continuava extremamente lendo e tedioso o trabalho, para minha surpresa não encontrei nenhum framework para resolver este problema. Voltei a olhar para o Django quando tive um tempo e lá estava uma solução para esse problema.

Ainda não desenvolvi nada grande com Django, porém hoje acho ele realmente completo para a tarefa, talvez não seja o melhor, mas é o que eu conheço (Python também tem mais frameworks web que palavras reservadas mesmo) e cumpre seu papel. Novamente fiquei surpreso ao perceber que o tempo que eu passava fazendo as coisas no Django e a forma como ele recomenda fazer as coisas era o que estava buscando hoje. Sim, ele também tem pilhas inclusas, ORM, formulários, autenticação e controle de permissão, tudo o que eu queria e iria precisar, ele já possuía.

O que aprendi com tudo isso é que sempre vale a pena aprender como um framework funciona e organiza o código de sua aplicação. Mesmo que não vai ser utilizado, essa ideia pode ser reaproveitada e se funciona é válido, mesmo que você odeie o resto dele, e quem sabe num futuro vir a ser adotado. Rails está na minha lista de coisas a aprender, embora ainda não conheça Ruby.

Anúncios

Comente

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s