Como não achei nada na internet que fosse resumido e focado para a autenticação com o Facebook utilizando essa app, resolvi fazer esse post para compartilhar a experiência. Então vou fazer um passo-a-passo aqui do que tive que fazer para completar a integração (que foi bem simples, diga-se de passagem).

Passo 1: READ THE DOCS!

Mesmo sendo algo simples e utilizando uma app para fazer a autenticação, você ainda tem a obrigação de ler a documentação do que trata a autenticação com o Facebook. Não adianta nada usar uma lib sem saber o que ela resolve por baixo dos panos. Aconselho a ler, pelo menos, a página que fala do fluxo da autenticação e da lista de permissões adicionais.

Passo 2: Configurar o seu projeto com o django-social-auth

Essa parte é muito simples. Tudo que você precisa fazer é instalar a app e configurá-la. Para instalar a app e as suas dependências, basta executar:

pip install django-social-auth

Depois disso, só precisamos configurar o settings.py e o urls.py da seguinte maneira:

Passo 3: Colocar o link no template

A configuração acima é tudo que você precisava para uma autenticação básica. Aconselho fortemente a ler o código da app para entender o que ela faz com os modelos por baixo dos panos. Agora é só colocar a url correta no template com a linha abaixo e correr para o abraço:

<a href=”{% url socialauth_begin ‘facebook’ %}”>Login com o Facebook</a>

Level Bônus: Recuperando dados extras do usuário

Como eu falei, o processo acima lida com uma autenticação básica. Mas, como fazer se precisarmos de mais dados do usuário como, por exemplo, sua cidade ou o seu aniversário? Se você leu a documentação do Facebook, vai ver que é só adicionar alguns valores na querystring da sua requisição de autenticação. (Aqui vale um parênteses: o Facebook não manda o email do usuário no pacote de dados básicos)

O django-social-auth viabiliza isso através de uma variável no settings e com o uso da sua estrutura de pipeline. O seu pipeline é composto por funções que são executadas no final do processo de autenticação e o mesmo é extensível. Portanto, você pode escrever sua função para fazer algo específico – no nosso caso salvar o aniversário e a cidade natal do usuário – e colocá-la no pipeline de funções executáveis. Para isso precisaríamos apenas adicionar algo parecido com isso ao nosso projeto:

Conclusão

Achei a app bem bacana e fácil de usar e configurar. Achei ela bem pensada e versátil (existe autenticação com 1000 redes sociais e afins). O único ponto que não gostei muito foi a maneira com que ela lida com falhas. A maioria da exceções são capturadas e não são tratadas ou geram notificações para os admins. Apenas mostram na tela uma mensagem falando que algo de errado aconteceu.

Para quem quer utilizá-la, digo que vale muito a pena dar uma navegada pelo seu código para ficar mais familiarizado com a app e ver se ela realmente tem o potencial necessário para atender as suas necessidades.

Até a próxima!

Para deixarmos claro, slider são aquelas interações que já estamos acostumados a ver e que fazem transições percorrendo imagem por imagem em uma lista de imagens a serem apresentadas. O carregamento das imagens preguiçoso, conhecido como lazyload, é uma técnica em que as imagens só são carregadas quando o usuário deseja vê-las. Isso é útil para tornar a página mais leve diminuindo o número de requisições iniciais que o browser precisa fazer para renderizar a página.

O script que junta essas duas ideias foi resultado de uma adaptação de um código que faz de um slider simples junto ao conceito desse plugin e do código do Pedro Menezes para fazer lazyload de imagens utilizando a jQuery. Além disso, ainda faço um controle de exibição dos botões que fazem a interação de próxima e anterior com o slider. Então, o resultado desse trabalho foi esse – vale dizer que não sou grande conhecedor de Javascript e jQuery:



Para ver um exemplo bem simples do funcionamento do script, você pode acessar esse link do JsFiddle e clicar no botão “Run” na parte superior esquerda. Não conhecia  essa ferramenta e achei muito legal para validar pequenas lógicas com Javascript e jQuery. Valeu Morada!

Estou começando a me interessar mais sobre desenvolvimento em frontend e, principalmente, por jQuery e Javascript.  Portanto, espero que tenhamos novos  posts sobre o assunto em breve. Até a próxima, para nossa alegria!

Facilidade com testes de aceitação

O Django 1.4 adiciona uma classe chamada LiveServerTestCase que tem o intuito de simular a aplicação e a suas integrações, com o banco por exemplo, para que se possa fazer testes de aceitação. Ela facilita a combinação com outras ferramentas comumente utilizadas nesse tipo de teste como o Selenium, por exemplo. Acho bom esse tipo de feature ser fornecida pelo framework porque torna mais fácil e convidativo a escrita de testes durante o processo de desenvolvimento.

Método prefetch_related

Essa parece uma alteração simples, mas de todas foi a que eu mais gostei. Antes já existia o select_releated que possibilitava queries únicas para recuperar um objeto e seus relacionamentos de chave estrangeira. Entretanto, quando tínhamos um relacionamento de muitos para muitos, por exemplo, isso não era possível. Esse método resolve essa questão e acaba por resolver um grande problema de performance quando esse tipo de relacionamento entre tabelas do banco tinha que ser trabalhado no Django.

Improvements do admin

Já precisei personalizar o admin além do que o framework fornece e não rolou. Curiosamente foi para fazer exatamente algo que a nova opção list_filter. Além disso, foram adicionados métodos que tornaram o ModelAdmin ainda mais poderoso e fácil de customizar como o get_list_display_links e o save_related.

Assignment tag

Essa tag é a única feature que, confesso, nunca tive necessidade real de utilizar. Mas me pareceu tão óbvio e fácil que teve que entrar nessa lista. Ela é bem interessante, mas fiquei um pouco de orelha em pé… Digo isso porque ela te dá um poder legalzinho e ela aumenta bem a possibilidade de fazer com que lógica da aplicação vaze para o template. Mas, é aquela coisa: grandes poderes, grandes responsabilidades.

Esses quatro pontos foram os que mais me chamaram a atenção por, com exceção do último, terem sido problemas que eu já enfrentei de alguma maneira. Vale dizer que ainda existem outras features bem bacanas como novos métodos para manipular o banco de dados ou o novo form wizard.

Sobre as minor features, segue uma listinha das que eu também curti mais:

• Uma nova classe de testes mais leve
• Uso de elif nos templates
• Parâmetro  –clear para o comando collectstatic
• Método distinct do queryset aceitando parâmetros com os campos das tabelas

Participem da discussão colocando os pontos que vocês mais gostaram dessa nova release nos comentários! Até a próxima!

A ideia foi o “Uma História Por Dia”, uma aplicação com que os usuários interajem construindo uma história criando frases associadas a imagens da web. Simples assim. O site foi concebido depois de uma conversa com o Miguel Nóbrega sobre interação randômica em alguns sites aliado a algumas aplicações de bots do Rafael Polo que pega um pouco dessa dinâmica também.

O mais interessante foi conseguir fazer todo o planejamento do projeto, desenvolvimento, layout e deploy em menos de 2 dias de trabalho. Confesso que conseguimos isso porque utilizamos algumas ferramentas e técnicas que viablizaram esse ciclo de desenvolvimento. E é sobre elas que vou falar agora.

Bom planning

O primeiro passo que garantiu um desenvolvimento rápido foi um planejamento bem elaborado. Focamos em qual era o MVP e criamos tópicos com tarefas bem definidas que refletiam os passos que deveriam ser implementados para que aquele tópico pudesse declarado como pronto. Percebemos que esse momento nos deu vários alertas prévias de problemas que enfrentamos depois. Assim, com os alertas, as soluções puderam ser pensadas com calma.

Dev Power up

No desenvolvimento tivemos o gitflow e o Django como fiés aliados. O primeiro nos permitiu utilizar um workflow do git bem estruturado e rápido. Isso parece bobo, mas você se sente muito mais leve para desenvolver sem ter que ficar com medo de lidar com merges a cada pull ou push.

Já o Django nos ajudou com dois pontos. Os testes podem ser considerados o primeiro, já que o Luciano nunca tinha desenvolvido com TDD. Não é necessário dizer que ele ficou impressionado em como desenvolver dessa maneira economiza
tempo de debug mais a frente, entre outros benefícios. Além dos testes, fizemos uso extensivo das class-based generic views do Django. Todas as views ficaram muito simples e de fácil e rápida customização. Isso nos permitiu experimentar muito mais por não termos a barreira de lidar com muito código para criar algo.

Para agilizar o layout, tarefa que nos tomou mais tempo, utilizamos o já famoso Bootstrap do Twitter. Pegamos ele como base e adicionamos novos estilos para deixar a página de um jeito que achamos mais bonito. Mas, a parte de containers e grid foram uma mão na roda!

Decolagem rápida

Por último, para o deploy, utilizamos o Heroku que já disponibilizou suporte Python faz um tempinho. Foi quase inacreditável preparar a máquina e colocar a aplicação no ar em menos de 30 minutos e com nem uma dúzia de comandos. Muito simples mesmo.

A avaliação final da experiência é que criar algo pequeno, validar uma ideia ou desenvolver um MVP hoje em dia é muito simples e rápido. Tentarei reproduzir ao máximo algumas das decisões que tomamos para projetos futuros, principalmente
em relação as class-based views.

E para não terminar sem um jabá, participe do “Uma História Por Dia”. Porque quem conta um conto, aumenta um ponto!

PS.: Agradecimentos à minha namorada, Paula Paiva, que deu várias ideias e dicas para estruturarmos a interface e interação do sistema.

Update >>> O projeto é aberto e qualquer pessoa pode contribuir com o código que está nesse repositório do Gtihub.

Faz um tempo e alguns amigos meus me pediram dicas sobre o Vim e ajuda para começar a utilizar e aprender a manipular melhor o editor. Para isso, eu sempre passava o endereço do meu repositório com meus arquivos de configuração e explicava o que eu utilizava. Como já me cansei de fazer isso, resolvi fazer esse post para mostrar o que eu uso com mais frequência quando estou trabalhando com o Vim.

1 – NerdTree Plugin

Esse eu acredito que seja um must-have do Vim. Basicamente você ganha o poder de visualizar a árvore de arquivos a partir do diretório que você está. Isso é bom porque você pode fazer busca de arquivos, navegar por diretórios e abrir arquivos de maneira mais rápida. Você pode instalá-lo seguindo essas instruções. A única coisa de diferente que fiz foi mudar o mapeamento da exibição da árvore.

2 – Code Fold

Eu me confundo muito quando tem muito código em um arquivo e eu só preciso trabalhar em uma parte dele. Para resolver esse problema utilizo uma função que faz esconde o código respeitando a sua identação. Acredito que essa seja a função que eu mais utilize do meu vimrc. Para utilizá-la, é só copiar essa parte de código para o seu vimrc e utilizar espaço quando fora do modo de edição.

3 – Tab completion

Existem ferramentas mais eficientes para fazer o tab completion de linguagens, mas eu gosto da função que utilizo exatamente por ela não ser guiada por nenhuma linguagem de programação. Basicamente ele utiliza o que já foi escrito no próprio arquivo para fazer avaliações de possíveis complementos, ou seja, ele assume que o que você vai utilizar, provavelmente já foi escrito. Acho essa abordagem bem interessante porque limita bastante o número de possibilidades e
evita listas gigantescas de alternativas. O código para essa função está aqui.

4 – Closetag

Esse é um script simples que faz um map para fechar tags HTML automaticamente. Assim, depois de criar o conteúdo de uma tag, apenas faço um CONTROL + _ e essa tag está fechada. Parece bobo, mas é uma mão na roda! Para utilizar é só colocar essas linhas no seu vimrc e copiar esse arquivo para o diretório .vim/scripts/.

5 – Ipython Debugger instantâneo

O último item da lista é a função Python que fiz como experimento para inserir e remover breakpoints para fazer debug de código Python. Já fiz um post falando sobre essas funções, então se quiserem saber como utilizar é só olhar lá.

Esses são os 5 pontos que mais utilizo. Ainda existem outras coisas, mas esses são os que utilizo praticamente todo dia que abro o Vim para trabalhar. Como bonus vale dar uma olhada nos mapeamentos de teclado para de navegação e manuseio de mais de uma janela que utilizo dentro do Vim.

Se você está começando, também aconselho o post Aprenda Vim Progressivamente que é original do Yann Esposito, mas que o Tarsis Azevedo fez uma ótima tradução.

Compartilhe nos comentários os seus plugins e maneiras de utilizar o Vim que eu não compartilhei nesse texto para iniciarmos uma rica discussão! Até a próxima!

Para quem não sabe, planets são aqueles agregadores que respeitam algum tópico. Por exemplo, temos o do Django ou o do Ubuntu, que agregam blogs de desenvolvedores ou pessoas que fazem parte das comunidades.

É aí que entra o Planet Venus. Ele é basicamente uma grande refatoração do projeto Planet 2.0. Apesar de ser bem simples de utilizar, é bom a gente fazer um passo-a-passo. Para instalar basta executar:

$ sudo apt-get install planet-venus

Após a instalação podemos utilizar o comando planet. Então, para criarmos o nosso exemplo inicial basta executarmos:

$ planet --create exemplo

$ cd exemplo

Foi criado um diretório chamado exemplo que contém um arquivo chamado planet.ini e um diretório theme que contém um arquivo de configuração para os temas utilizados. Teoricamente, você já tem um planet em mãos, basta somente mudar os arquivos de configuração para deixá-los da maneira que você desejar. Ele já é bem estruturado, simples de entender e é alterar os valores desejados ou adicionar novos feeds.

O que achei muito interessante do Planet Venus é que, caso você tenha o Django instalado na máquina, você pode usar a linguagem de templates do Django para editar a exibição dos posts. Para fazer isso, você pode copiar o exemplo que o projeto já fornece com o comando:

$ cp /usr/share/planet-venus/theme/django/index.html.dj theme/

Após copiar, você deve editar o arquivo theme/config.ini deixando-o com o seguinte conteúdo:

[Planet]

template_files: index.html.dj

Vale a pena dar uma olhada nos templates base que o projeto já fornece. Por exemplo, além do layout Django e em HTML, ele já disponibiliza templates para feeds RSS. Após deixarmos o template do jeito que esperamos, é só coletar os posts. Para isso basta executar o seguinte comando:

$ planet planet.ini

Com isso, serão criados dois diretórios que foram definidos no arquivo de configuração planet.ini, nas variáveis output_dir e cache_directory. O primeiro diretório armazena o que foi gerado após a agregação e o segundo faz cache para posts que o planet consultou.

Como ele não possui nada para trabalhar em background ou algo do tipo uma solução para conseguir atualizar o seu planet frequentemente pode ser adicionar o comando de atualização colocado acima ao contrab.

Seguindo esses passos você já tem um planet pronto e configurado. Caso queira torná-lo acessível na web, você pode utilizar o Nginx ou o Apache para servir os arquivos estáticos gerados pelo Planet Venus.

Crie seu planet com seus blogs favoritos e compartilhe suas impressões do Planet Venus aqui nos comentários! Até a próxima!

Esse é um assunto que todos que vão ao Dojo aqui do Rio sempre debatem e foi uma experiência muito prazerosa e coletiva escrever essa monografia. O melhor de tudo foi ver a sala da defesa lotada com a galera que frequenta os Dojos. Me senti honrado em ver toda aquela galera que admiro muito parando um segundinho para me ouvir e me apoiar nesse momento tão importante como foi o final da faculdade.

Então, sem mais delongas, vocês podem baixar a monografia nesse link do MediaFire. Espero que gostem e, como sempre, críticas e sugestões são bem-vindas!

PS.: Ainda continuo na dívida do vídeo da defesa. =)

O jogo é bem no estilo de Guitar Hero, mas usando uma guitarra como controle e baseado em uma temática diferente! O jogo não tem um modo de história e nem um personagem bonitinho. A principal interação do jogo é você aprender a tocar novas músicas para poder fazer shows em palcos cada vez mais maneiros! Além disso, existem mini games e exercícios específicos para você aperfeiçoar técnicas para tocar guitarra. Vejam o vídeo do gameplay para sentirem melhor o que ele é:

O mais interessante do jogo é que ele traz o conceito de gamificação para o ensino de guitarra. Mas não se limita a só dar achievements para o jogador. O jogo se destaca em dois pontos que estão diretamente associados à questão do feedback, essencial para o aprendizado.

O primeiro ponto é que o feedback é em tempo real! Não sou muito fã do Guitar Hero e um dos motivos é porque não parece que você está tocando a música. Quando você erra, a guitarra simplesmente para de tocar e você não consegue saber o que você fez. No Rocksmith, você ouve quando está fazendo merda algo errado. Ou seja, o jogo não esconde o seu erro e o mostra para você, fazendo com que você sinta o impacto que ele causa.

O outro ponto é que o jogo é inteligente e respeita o tempo de aprendizado do jogador. Não existem opções de pré-configuradas de dificuldade, o clássico trio easy, medium e hard. Então, no Rocksmith, não é você que deve se adequar à dificuldade, mas sim o contrário – a complexidade do jogo se encaixa na sua experiência com o instrumento. Ao longo do tempo, a dificuldade das músicas vão aumentando respeitando a sua curva de aprendizado.

Por esses dois pontos, acho que essa abordagem vai além da visão comum de gamificação. Nâo enxergo essa prática como simplesmente dar bônus para o jogador: assim você o trata como um bebê. Colocar a gamificação no ensino não é uma questão de recompensas, mas sim de acompanhamento – enxergar os passos do aluno e criar um ambiente em que ele possa avançar sem que ele encare isso como uma tarefa.

Se você puder viver essa experiência, vale muito à pena. Ah, cabe dizer também que é muito divertido jogar o multiplayer com 2 guitarras! Compre o jogo, faça o seu show e dê a sua opinião sobre o assunto aqui nos comentários!

PS.: Para saber mais sobre gamificação vale a pena dar uma olhada nesses slides.

As dúvidas surgiram durante o curso Python Para Quem Sabe Python do Luciano Ramalho. O curso é excelente e estou vendo vários conceitos mais internos do Python em que eu nunca tive a oportunidade de me aprofundar. Durante a primeira aula, foi mostrado a list comprehension e a comparação com um laço for normal focando na legibilidade do código. Depois disso, perguntei sobre a performance e o pessoal deu a ideia implementarmos um profile para medirmos essa questão e experimentarmos nós mesmos esse processo.

O João Dubas, que também está no curso, começou com uma abordagem em que me baseei e fiz um fork. Na minha medição, quis comparar alguns cenários, sendo eles:

1. Somente o filter de uma lista;
2. Somente o map para uma lista;
3. Filter e map para uma lista;

Para cada um desses cenários existiam 3 implementações – uma com o laço for normal, uma com list comprehension e outra utilizando as funções map e filter do Python. A ideia desse post é compartilhar, sem nenhuma pretensão científica, os resultados que obtive. Então, segue o output:

***** FILTER PROFILING *****
                              fn min        mean       max      
        filter_with_normal_for() 0.35435510 0.35819454 0.36282516
filter_with_list_comprehension() 0.30340981 0.31135285 0.32254100
       filter_with_filter_func() 0.21948600 0.22835863 0.26977205

***** MAP PROFILING *****
                           fn min        mean       max      
        map_with_normal_for() 0.36617208 0.37257178 0.39629292
map_with_list_comprehension() 0.29344010 0.29665232 0.30447888
          map_with_map_func() 0.28689599 0.29024918 0.30203104

***** MAP + FILTER PROFILING *****
                                 fn min        mean       max      
        mapfilter_with_normal_for() 0.46366715 0.47172487 0.48409891
mapfilter_with_list_comprehension() 0.42643499 0.42990112 0.43452096
    mapfilter_with_mapfilter_func() 0.36422396 0.36758418 0.38192511

Se os cenários que eu escrevi estiverem corretos e não ter comido nenhuma mosca com algum detalhe, em todos os cenários as list comprehension se mostraram a segunda melhor solução, perdendo para a utilização das funções bultins do Python. No segundo cenário, ela ficou bem próxima da implementação utilizando o map. Isso dá para supor que a diferença de performance ficou a cargo do filter e não no map. Em todos os casos a solução normal utilizando o laço for é a menos performática.

Como disse, essa medição não teve nenhum pretexto científico e foi apenas uma maneira divertida de fomentar uma discussão muito interessante na lista da turma do PPQSP sobre o valor da performance do código em detrimento da sua legibilidade. Eu também sou da escola do Luciano Ramalho ao gostar das list comprehensions por elas deixarem claras quais as intenções do código. Mas também compreendo que podem existir casos em que esse tipo de preocupação com performance existem, apesar de não achá-los comuns. Portanto, primeiro escrevo o código bonito para depois otimizá-lo se necessário!

O código que eu fiz para fazer essa medição está nesse repositório do Github e você pode executar o script na sua máquina para ver quais os seus resultados executando os comandos abaixo:

$ wget https://raw.github.com/berinhard/ppqsp/master/class_0/for_profiler.py
$ python for_profiler.py

Espero que vocês se divirtam fazendo as medições e sintam-se a vontade para compartilhar os resultados aqui nos comentários!

Para mim aquele papel com palavras impressas ganha valor quando penso nas pessoas e nas histórias que tive com elas e que moldaram quem sou para escrever o que escrevi. Então, sem fazer média, considero a parte dos agradecimentos como a parte mais importante e é exatamente ela que quero compartilhar aqui:

Agradecimentos

Gostaria de agradecer:

A minha avó, Dona Adélia, por me ajudar durante esses 5

morando sozinho me alimentando com os seus deliciosos quitutes congelados;

 

Ao meu pai, Henrique, por ser um exemplo e, acima de tudo, um ídolo para mim;

 

A minha mãe, Marcia, por sempre se preocupar, me aconselhar e

me dar tudo o que precisei para me tornar o profissional que sou hoje;

 

Aos meus irmãos, Eduardo e Thiago, pelos anos juntos,

históras dividas no apartamento e exemplo de união;

 

A minha namorada, Paula, que ainda que tão longe

se manteve perto sempre me ajudando a olhar para frente;

 

A toda a minha família sempre presente na minha vida;

 

Aos amigos da faculdade, especialmente o João Luis e o Gabriel,

irmãos para mim, por esses anos em que, juntos, dividimos sucessos e fracassos;

 

Aos amigos de Friburgo, especialmente o Wanderson, o Fernando e

o Luis Felipe, por todas histórias que tivemos

e por, mesmo depois de sair da cidade, continuarmos juntos;

 

Aos amigos Flávio, Thiago, Henrique e Luciano, companheiros

na Dekode e que deram a motivação final para esse projeto;

 

Aos novos amigos Gerardo, Elias, João Felipe e Luisão, que acolheram

o Coding Dojo da UFF e hoje seguem com ele;

 

A todas as pessoas que já participaram do Coding Dojo da UFF,

este que por várias vezes enxerguei como um filho;

 

A todos os que já estiveram no Pós-Dojo da UFF pelas

excelentes conversas e noites divertidas;

 

As comunidades do Rio de Janeiro e, principalmente,

à DojoRio porque se não fossem vocês nada do que escrevi existiria;

 

Por último, ao Álvaro, ao Henrique e ao Vinícius. Obrigado pelas pílulas vermelhas.

 

Novamente, muito obrigado à todos!