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!

O django-testtols é uma pequena biblioteca Python que criamos na Dekode com o intuito de extender a própria infraestrutura de testes do Django respeitando o seu design original.

Nas listas que participo, este assunto ainda não é levantado com muita frequência. A intenção de divulgar este projeto é promover a discussão e troca de experiências sobre testes de aplicações Django na comunidade. Assim poderemos documentar estratégias e reaproveitar os códigos com o que formos aprendendo.

O fato do django-testtools respeitar a estrutura e a maneira de se escrever testes no Django e ser apenas uma extensão também são fatores importantes para poder guiar a discussão. Gostaria de discutir mais os significados, organização, intenção e valor dos testes do que frameworks e DSLs que não respeitam a verdade material da linguagem. Acredito que o unittest e o Django já fornecem ferramentas úteis para escrevermos testes e desenvolvermos respeitando o TDD. Então, o principal a ser discutido é como fazê-lo de uma maneira sustentável.

Vou continuar a abordar o tema nesse espaço e gostaria de ouvir o que você pensa sobre o assunto. Para ficar por dentro das nossas próximas publicações, mantenha contato pelo Github, Twitter ou Facebook.

Até a próxima!

Este ano, o evento contará com algumas presenças internacionais de peso no mundo Python como Jim Fulton, Steve Holden, Alan Runyan e muitos outros. Além desses também teremos importantes nomes do cenário nacional participando do evento com palestras e treinamentos.

Participei da PythonBrasil[6] no ano passado, em Curitiba, e posso dizer que foi uma excelente experiência. Estar em contato com pessoas que vivem Python seja no trabalho ou seja pelo prazer de programar na linguagem que ama resulta em uma grande troca de conhecimento e você pode sair aprendendo muito. Seja você um ninja na linguagem ou apenas um iniciante.

Para finalizar, este ano, além de participar como ouvinte, tive a honra de ter uma submissão palestra aceita. Na palestra “Testando Aplicações Django: Quando, Como e Onde”, pretendo abordar alguns padrões de escrita de código de teste que aprendi durante meu início no mundo Django na Myfreecomm e torna-se mais sólido agora trabalhando na Dekode. Além disso, também pretendo falar de algumas ferramentas e processos que podem ajudar na escrita dos seus testes.

Então não perca tempo e inscreva-se logo no evento! Nos vemos lá!

Vale dizer que o mongoengine_fuel já suporta alguns dos principais campos que o mongoengine te permite usar. Ainda não estão todos os campos pois eu defini um limite básico para lançá-lo que de era atender as necessidades do meu projeto na Myfreecomm. Como os campos que implementei já combrem os campos utilizados, coloquei no ar.

Espero que vocês tenham gostado e aguardo críticas e sugestões. Como esse foi o meu primeiro projeto de código aberto, aprendi muito com essa experiência e tive que vencer uma série de medos pessoais para conseguir colocar o código no ar. Não cabe nesse post falar sobre isso, já que o foco dele é apresentar a ferramenta. Mas, em breve, farei um post para compartilhar com vocês as experiências e impressões que pude tirar desse processo.

Entretanto, não posso deixar de agradecer ao meu amigo Vanderson Mota pelo incentivo e apoio que me deu ao longo do desenvolvimento do mongoengine_fuel.

O cenário era o seguinte. A app emissora possui uma lógica interna disparar quatro sinais, cada um referente a avaliação resultante. Assim, os que consomem essa app, podem se conectar apenas aos sinais que representem casos relevantes para eles. Poderia ter feito tudo em um único sinal, mas o problema dessa abordagem é que estaríamos jogando a lógica interna dessa primeira app para todas consumidores e tornando-os responsáveis por lidar com ela.

Como a emissão e a recepção do são sinal duas coisas diferentes e inclusive em apps diferentes, resolvi separar os testes nessas duas áreas também. Na app emissora do signal criei um TestCase para ser responsável somente por validar a lógica de emissão do signal que está dentro de uma view. Esse foi o primeiro passo e não tive problema nenhum com ele. O problema veio na hora de testar e criar o código para os receptores do sinal.

Ao conectar os receptores da app consumidora aos seus respectivos sinais, sempre que eu rodava os testes da app que disparava os sinais eles falhavam porque essas funções receptoras, como estavam conectadas, eram executadas sem ter as fixtures do modelo que elas consomem carregadas. Então, o problema era rodar os testes de emissão dos sinais de maneira desacoplada, ou seja, fazer com que os sinais ignorassem as suas conexões.

Então, o que eu fiz foi dar uma olhada no código do Django para entender o funcionamento dos sinais. Basicamente, um sinal mantém uma lista de receivers que são referências para as conexões ao sinal. A cada nova conexão, ele atualiza essa lista e, ao chamar o send, ele vai executando as funções que estão nesses receivers. Então a abordagem que eu tomei foi criar um setUpClass e tearDownClass no TestCase. Assim, no setUpClass eu salvo a lista de receivers do sinal e seto uma lista vazia no lugar e, no tearDownClass, eu recupero essa lista setando o receivers do sinal corretamente. Esse gist do Github mostra o funcionamento:

Não sei se é a solução ideal, mas consegui resolver tranquilamente o meu problema. Entendo que testar sinais envolve testar o fluxo inteiro, entretanto, fazer isso com duas apps separadas iria me gerar acoplamento entre os testes e, além disso, para o teste da app consumidora, eu teria que ter conhecimento do funcionamento interno da app emissora do sinal para saber quem chamar e como chamar para disparar o sinal desejado. Portanto, acho essa solução bem viável.

Vale dizer que os classmethods de setUpClass e tearDownClass estão disponíveis apenas no unittest2 que o Django só incorporou a partir do Django 1.3. Portanto, se você usa o Django 1.2 ou menor, você precisar usar o TestCase do unittest2 para conseguir usar esses classmethods.

Resolvi fazer esse post depois te ter pesquisado na web e não achar nada, a não ser dessa thread do Vinicius Mendes não respondida no django-users.

Até a próxima!

https://spreadsheets.google.com/viewform?hl=pt_BR&formkey=dEk3WUtGdlA2Q3hraXZiWFhKYXJ5b2c6MQ#gid=0

No último pós-dojo, descobri mas uma dessas iniciativas. Dois alunos do curso, a Carol Zamith e o Rafael Toscano, sempre se interessaram sobre segurança da informação. Entretanto, essa é uma área que não é abordada é muito pouco abordada pela universidade. Insatisfeitos com isso, eles resolveram montar um grupo de estudos em Computação Forense para satisfazer a demanda.

O curioso é que o grupo já existe há 6 meses! Eles possuem um blog onde colocam notícias sobre os temas abordados na reunião, temas sobre o domínio e discussões que podem surgir. O link é esse aqui e vale muito a pena conferir o que a galera vem fazendo de perto. Lembrando, esse é um evento aberto a toda comunidade e, se você quer participar, é só para aparecer na sala do Dojo na UFF (230-B) no Bloco D do Campus da Praia Vermelha. Os encontros rolam sempre nas sextas-feiras e começam sempre às 14:00 e vão até a galera ficar esgotada.

Se eu bem conheço essa galera e, pelo que já venho ouvindo das ideias megalomaníacas do Thiago Garcia, esse é apenas o começo de mais um movimento a favor da explanação do conhecimento na UFF. Aguardem, porque ainda mais está por vir dessa galera extremamente enérgica!

PS.: Vale a pena dar uma olhada no post do Thiago falando sobre a experiência dele com o Dojo e como este modificou a sua vida.

Gostei da experiência e, em um dia de Dojo, vi no Gedit do João Felipe um atalhozinho que ele desenvolveu em que ele andava com uma linha para cima e para baixo com as setas do teclado. Ou seja, ele não precisava ficar copiando e colando a linha onde quisesse. Agora, basta ele andar com a linha até a posição que ele quer. Questionado se o Vim podia fazer isso, eu prontamente disse: “Claro!”. Assim, como eu disse que ele tinha esse poder, eu tinha que validar isso de alguma maneira. Questão de honra, né?

Pesquisei no Google por muito pouco tempo, porque eu queria mesmo é desenvolver, e não achei nada que fizesse isso. Então pensei em fazer usando Python e o mesmo módulo que eu já havia feito para criar o do debugger. Fiz e coloquei nesse Gist do Github:

O código não está dos melhores, confesso, mas foi interessante porque achei que seria algo simples e, quando dei por mim, estava com um papel na mão para controlar os índices de maneira correta e não deixar estourar o buffer do Vim.

O código atual funciona para apenas uma linha. Nesses dias, descobri que o do Gedit funciona para múltiplas linhas, então agora a ideia e expandir esse cara, o que que não sei se é possível usando esse módulo e Python porque não olhei a documentação toda ainda. Acho que tem que ser no código do Vim mesmo. Mas, a ideia é a de aceitar que, no modo visual com seleção de linhas, ele mova todas as linhas selecionadas. Quem quiser, obviamente, pode colaborar e ajudar para fazer isso.