Samir MamudeSimplicidade é a maior forma de sofisticação

Bom como último post do ano, gostaria de explicar o que aconteceu comigo em 2009 no qual passei por várias situações boas e ruins tanto na vida pessoal como profissional. Acredito que foi um ano de muito aprendizado e algumas conquistas, vamos lá.

(Janeiro até Abril)

No início de 2009 pra variar já comecei na correria pois ainda prestava serviços para ArizonaBay, uma empresa americana localizada em São Francisco, CA. Foi minha melhor experiência de aprendizado profissional, pois melhorei meu inglês e trabalhei com pessoas incríveis. Fico eternamente grato pela oportunidade.

Em Março, tive a oportunidade de ver novamente o show do Morbid Angel que é uma das minhas bandas favoritas de Metal e não podia perder aquele show por nada.

Continuando….pra minha “sorte”, tive um problema muito grave de saúde e tive que ser operado as pressas, pois corri sério risco de morte. O problema foi que eu sempre sofri com problemas de estômago e crises de gastrite, juntando ao stress do trabalho, minha situação foi se agravando até  que cheguei a ponto de ser internado. Após uma série de exames meu médico constatou que eu estava com micro perfurações no intestino e precisava ser operado imediamente. O resultado da biopsia constatou a Síndrome de Crohn, uma doença causada principalmente por problemas emocionais. Enfim depois da cirurgia passei 8 meses de tratamento com anti-bióticos e hoje me recuperei totalmente, graças a Deus

No início de Abril com o início da crise mundial, a empresa resolveu fazer cortes e lógico os primeiros a serem dispensando foram os brasileiros, mas todo mundo saiu numa boa e sem problemas.

(Maio até Setembro)

Consegui outro trabalho e desta vez para uma agência de Miami Beach chamada Hoodiny, essa empresa tem como seu principal produto o Cyloop que é uma rede social voltado para música. Foi um projeto legal onde aprendi sobre como utilizar Cucumber e Rspec, melhorei meus conhecimentos sobre teste de software.

No geral a experiência de trabalhar para esta empresa foi razoável, pois eu comecei a perceber que estava se afastando e perdendo cada vez mais meu interesse por Rails como expliquei neste post. Terminado meu contrato, resolvi mudar o rumo da minha empresa e começar a andar pelas próprias pernas, por mais que prestação de serviço seja algo mais fácil de arrumar e ganhar dinheiro de forma mais rápida, não era o que eu pretendia futuramente.

(Outubro até Dezembro)

Em Outubro tive a oportunidade de ir na Rails Summit e conhecer amigos de trabalho, meu interesse no evento foi para assistir  as palestras voltadas exclusivamente para empreendedorismo como a do Vinícius Teles, que sem dúvida foi a melhor na minha opinião.

Também consegui fechar o primeiro projeto para minha empresa, no momento o que posso comentar é que se trata de um projeto voltado para oficinas mecânicas e acho que vai agregar muita qualidade e agilidade  ao cliente final. Como já havia comentado, resolvi de vez mudar para Python e Django, após 3 meses de projeto, o que posso constatar é que Python está resolvendo meus problemas muito diferente de toda a frescura do “Opinionated Software” como o Ruby on Rails é. Eu sei que meu comentário pode ser ofensivo para as pessoas que adoram a linguagem e o framework, mas eu não me vejo mais trabalhando com esse framework por uma série de razões. Simplesmente não serve pra mim!

E pra finalizar em Dezembro completei 30 anos, to ficando velho urgh……

Finalizando…

No mais eu gostaria de desejar um Feliz Natal com muita saúde, paz e felicidades a todos os amigos que conheço e que 2010 seja um ano de repleta conquistas e vitórias.

Boas festas

Essa é uma questão comum que ja vi lista #django-brasil onde muitos desenvolvedores ficam na dúvida para escolher a melhor opção de criar sistemas usando o Django. Fazer tudo no “braço” mesmo criando suas próprias views, htmls, rotas, etc…tudo para ter a melhor flexibilidade possível. Ou como segunda opção usar o próprio admin e aprender como customizar quando necessário.

Antes de iniciar o projeto que ando trabalhando, testei muitas opções de frameworks. Queria algo que pudesse agilizar ao máximo meu trabalho, porque convenhamos, ficar fazendo tela de CRUD alem de ser um trabalho maçante, propenso a erros, é um verdadeiro pé no saco! Nessa época como ainda estava ligado muito no Rails, tentei algumas opções, mas tudo me levava a fazer o CRUD na mão. Voltei novamente a pesquisar opções em Python, nessa época eu já até conhecia bem o admin do Django, mas tinha um certo receio do tipo, “esse negócio vai me deixar na mão”, mas foi puro engano, vou explicar adiante.

Continuando minha pesquisa, conheci o framework “cola” Pylons, na primeira vez fiquei impressionado, extremamente versátil e muito parecido com Rails, mas após alguns testes percebi que não tinha experiência o suficiente para usar essa ferramenta, acho que esse framework é para quem tem um conhecimento avançado em Python e não é meu caso.

Também testei o web2py, outro framework interessante e ágil para projetos pequenos, mas acho que a forma de trabalhar nele é muito estranha, você edita o código no próprio navegador como se fosse seu próprio IDE e assim por diante. Mas o que realmente me incomodou é que ele segue uma linha contrária do Python onde não existe importação de módulos como é de costume. E como tudo no Python é explícito e sem “mágicas”, deixei essa opção de lado e acabei voltando para o Django novamente usando o Admin.

A primeira coisa que recomendo antes de se aventurar a criar um sistema usando o Admin é, saiba bem como usar a Orientação a Objetos do Python e porque isso? No início tive a sensação do Admin ser aquele código “engessado” onde você fica amarrado e sem ter muito o que fazer. Mas com o tempo fui percebendo que você pode sobreescrever qualquer método da biblioteca padrão e customizar da maneira de achar necessário, vamos a um pequeno exemplo.

O sistema que estou criando, cada cliente possui seu sub-dominio e essa informação não pode ser editada como é por padrão, então imagine o seguinte trecho de código.

# models.py
class Cliente(models.Models):
    dominio = models.CharField(max_length=50)
    nome_fantasia = models.CharField(max_length=100)
    plano_acesso = models.ForeignKey('PlanoAcesso')

# forms.py
class ClienteAdminForm(forms.ModelForm):
    def __init__(self, *args, **kwargs):
        super(ClienteAdminForm, self).__init__(*args, **kwargs)
        instance = getattr(self, 'instance', None)
        if instance and instance.id:
            self.fields['dominio'].widget.attrs['readonly'] = True
            self.fields['dominio'].help_text = 'Acesso: http://%s.dominio.com.br:8090' % instance.dominio

# admin.py
class ClienteAdmin(admin.ModelAdmin):
    form = ClienteAdminForm
    fields = ('dominio','nome_fantasia',...,)
register.admin.site(Cliente, ClienteAdmin)

Observando bem o código, o que fiz ali foi sobreescrever o formulário padrão da classe ClienteAdmin pela classe ClienteAdminForm e no construtor dessa classe eu verifico se o objeto está no modo de edição e travo o campo domínio como “readonly”. Isso é apenas uma pequena amostra do que é possível fazer, o Django é flexível o suficiente de acordo com sua necessidade.

Outra coisa muito interessante é que podemos trabalhar com herança nos templates sem ter a necessidade de modificar o arquivo original do admin, basta criar um novo arquivo com o mesmo nome e herdar do padrão, por exemplo. Na minha lista de clientes, eu quero somar o total do valor dos planos de acessos.

Primeiro mudo o comportamento padrão do método changelist_view:

# admin.py
def changelist_view(self, request, extra_context={}):
   soma = PlanoAcesso.objects.all().aggregate(Sum('valor'))
   try:
      extra_context['soma'] = ("R$ %2.2f" % soma['valor__sum']).replace('.',',')
   except:
      extra_context['soma'] = "R$ 0,00"
   return super(ClienteAdmin, self).changelist_view(request, extra_context)

Para criar o template vamos supor que essa aplicação seja chamada de clientes, dentro dessa pasta crie outra pasta chamada templates e dentro dela outra chamada admin, novamente dentro da pasta admin crie a pasta clientes e dentro de clientes cria a última pasta cliente, achou confuso?

Nessa última pasta, crie o arquivo change_list.html com o seguinte conteúdo.

{% extends "admin/change_list.html" %}
{% block result_list %}
    {{ block.super }}
    Total: {{ soma }}
{% endblock result_list %}

Se você observar, temos a listagem original porque no html chamamos a variável {{ block.super }} para herdar do template original e logo abaixo nosso conteúdo customizável, muito legal não?

Para finalizar, acho que ficou claro que podemos usar sim o Admin para criação de sistemas complexos e customizá-lo ao máximo, basta saber usar a ferramenta corretamente e sem gambiarras.