Visualizando a atividade de seu repositório git com gource

Já pensou em preparar uma animação/visualização do repositório de um projeto? Já fiz isso algumas vezes, em especial no final de um projeto. Acho que isso ajuda a colocar em perspectiva todo o trabalho feito nos últimos meses ou anos. É muito comum perdermos a noção do todo após os momentos finais de ajustes, implantação (quem ainda faz isso?), etc.

Gource é uma ferramenta de código livre que é capaz de gerar animações do histórico de um repositório de controle de versão (Git, SVN, Mercurial e Bazaar). A primeira vez que usei Gource foi pelos idos de 2010 e desde lá muita coisa mudou.

A ideia deste post é fazer um breve tutorial de como usar Gource (+ ffmpeg) para gerar (e gravar em vídeo) uma visualização da evolução de um repositório com o passar do tempo.

Gerando a animação

Uma vez instalado corretamente*, basta executar o Gource e seus parâmetros na raiz do repositório (a sua cópia local, claro):

gource

Pronto, é isso, você já deve ver uma janela com o timelapse do seu projeto. Mas convenhamos que essa versão default é bem simples. Vamos incrementar:

gource -s 0.5 --start-date '2017-08-25' -f --key --highlight-users --user-image-dir avatars -a 1 -logo logo.png -1920x1080

Este monte de parâmetros não chega a ser metade dos possíveis, mas já é um bom começo. Uma curta explicação de cada um deles:

-s {tempo} Tempo de vídeo por dia de projeto(em segundos)
-a {tempo} Tempo máximo (em segundos) sem atividade no projeto (achata os dias inativos)
-f Exibe em modo tela-cheia
-o {arquivo/stream} Saída para arquivo/stream (formato ppm)
-logo {logo.png} Logo do projeto
-{w}x{h} Largura (w) e altura (h) do video em pixels
--Title {‘titulo’} Título do projeto
--start-date {‘yyyy-mm-dd’} Data de início da visualização
--user-image-dir {dir} Pasta com imagens dos usuários (“Nome Sobrenome.png/jpg”)
--key Exibe legenda de extensão de arquivos
--highlight-users Nome de usuários sempre visível

A saída deve ficar parecida com esta que fiz do Tretas Lendárias, um joguinho de código livre que fizemos para o Jogabilijam 2:

Para aproveitar que mostrei este vídeo, vou deixar um tutorial bônus de como utilizar o ffmpeg** para gravar tais vídeos.

Gravando saída usando ffmpeg

Para gravar em vídeo a visualização gerada pelo Gource, é preciso primeiro direcionar a saída do comando para o output padrão, utilizando o parâmetro -o. Utilizando esta saída como entrada para o comando ffmpeg (utilizando o recurso de pipeline do shell), é possível gravar tudo em um arquivo de vídeo:

gource -s 0.5 --start-date '2017-08-25' -f --key --highlight-users --user-image-dir avatars -a 1 -logo logo.png -1920x1080 -o - | ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -crf 1 -threads 0 -bf 0 saida.mp4

Não vou entrar no mérito dos parâmetros do ffmpeg neste post, basta dizer que ele irá gravar a saída em FullHD com 60 quadros por segundo. Se sua máquina não for rápida, deve demorar um pouco, mas o resultado é de excelente qualidade.

Acho que é isso, bom proveito :)

* Procure por instruções na sua distribuição, para quem usa mac/homebrew, dá para instalar com brew install gource.
** Mais uma vez, procure por instruções de como instalar o ffmpeg com os codecs de sua escolha.

 

SOAP vs REST?

Este post surgiu como uma resposta em uma discussão bastante interessante no grupo de telegram PyBR e a versão mais rudimentar dele foi escrita em um gist. Um membro pediu indicação de uma biblioteca Python para lidar com Web Services que utilizavam SOAP como protocolo, outros membros questionaram a razão dos serviços não estarem implementados em RESTful, e por fim alguém falou que SOAP era um jeito ultrapassado de implementar Web Services. Como faz algum tempo que eu não lido com SOAP, logo imaginei que algo havia surgido neste meio-tempo para substituí-lo.

Mas não, ele se referia à RESTful Web Services como um substituto do SOAP. A verdade é que sequer faz muito sentido fazer uma comparação entre REST e SOAP, visto que o primeiro é um padrão arquitetural, o segundo um protocolo. Acho que faz mais sentido fazermos uma comparação entre HTTP (seguindo REST ao pé da letra ou não) e SOAP.

Para a maioria dos casos que encontro hoje em dia, implementar uma API pública utilizando HTTP faz muito mais sentido, tanto pela flexibilidade de poder usar XML ou JSON, quanto pela simplicidade da operação. Mas quando eu acho que SOAP vale a pena ou é a escolha “certa”?

Modelagem de negócio

A maioria das APIs têm foco em entidades e operações básicas nessas entidades (ex.: entidade Cliente e operações de inserir (PUT), alterar (POST), buscar (GET), etc…). Você começa a ter problemas em manter sua modelagem (endpoints, coerência interna, etc) de forma consistente quando suas operações não tem uma entidade clara, ou fogem muito do padrão CRUD que os métodos HTTP “impõem”. Tenho certeza que todos podemos imaginar exemplos disso, aplicados à nossa realidade. Eu já tive, por exemplo, que fazer um serviço/endpoint para migração opcional de dados de um sistema antigo para um novo, sob demanda de certos usuários. Como eu represento isso bem apontando para uma entidade e uma única operação/método HTTP?

Protocolo de transporte

Você sempre pode usar HTTP/HTTPS? Quando não, SOAP é independente de protocolo de transporte e resolve essa para você.

Tratamento de erro

SOAP possui tratamento de erro embutido. É possível que algumas libs ou frameworks para RESTful web services hoje em dia também possuam, se não for o caso e você não quiser/tiver tempo de implementar sua própria camada de confiabilidade, SOAP é uma boa escolha. Há também garantia de transporte/entrega, independente do protocolo de transporte.

Operações com estado

O título da seção já é bem descritivo. SOAP preconiza e suporta interações stateful, simular/garantir algo parecido com APIs RESTful utilizando HTTP/S não é simples, e filosoficamente, nem deve ser feito, para ser direto.

Autenticação

Embora não seja difícil implementar autenticação em serviços RESTful, não há o conceito de sessão, portanto, é muito complicado implementar autenticações consistentes que fujam do padrão token/passcode ou que usem aquele OAuth by google/facebook. É muito comum, por exemplo, precisarmos aproveitar o Enterprise Single Sign-On (SSO) que uma empresa já use internamente, para autenticar o uso de web services.

Conclusão

Amo RESTful APIs + HTTP/S e vou protegê-los. Odeio SOAP e ter que lidar com XML. Adoraria que todos esses problemas sumissem, mas é pouco realista. A verdade é que um não surgiu para substituir o outro, mas sim para simplificar a implementação e consumo de Web Services em determinados casos. O prêmio de consolação? Implementar estes serviços com SOAP, hoje, é muito mais simples que nas épocas das primeiras versões do JAX-WS e frameworks similares. Não dói tanto quanto parece.

Recomendações de podcasts – Computação e afins

Semana passada listei os meus podcasts preferidos de história, política e outras humanidades. Chegou a vez dos podcasts de exatas e da terra, incluindo computação, estatística e ciências pedantes em geral.

Segue a lista em ordem alfabética:

Data skeptic

Apresentado por um estatístico e uma cientista da computação, este podcast aborda temas atuais sobre ceticismo e ciência de dados. Alguns episódios são sobre projetos com destaque na mídia, com entrevistas e cerca de 1 hora de conteúdo, enquanto outros são sobre conceitos fundamentais de ciências de dados e estatística (conhecidos como episódios “mini”), com cerca de 15 minutos de duração.

FLOSS weekly

Free Libre Open Source Sofware (FLOSS) Weekly é um podcast comandado por Randal Schwartz sobre software livre. Toda semana um desenvolvedor ou representante de um projeto open-source diferente é entrevistado. É uma excelente maneira de conhecer novos projetos ou saber mais sobre o funcionamento interno de projetos conhecidos.

Fronteiras da ciência

Criado como programa para a rádio universitária da UFRGS, o Fronteiras da ciência se propunha a abordar as diferenças entre ciência e pseudociência. Com o tempo isto foi mudando, e hoje os professores do departamento de física da federal do Rio Grande do Sul se dedicam a entrevistar pesquisadores sobre suas áreas de pesquisa. Temas de ciência clássica, história da ciência e utilidade pública se misturam. Por ser um programa de rádio, o tempo é contado, e cada episódio tem em torno de 30 minutos, o que termina condensando muito a informação. As áreas de conhecimento não variam muito, ficando mais na física e biologia que em qualquer outra coisa.

Hanselminutes

Scott Hanselman é um programador, professor e ex-evangelista da Microsoft, portanto quem ganha a vida com .NET já deve conhecê-lo de outros carnavais. Em Hanselminutes, ele se dedica a entrevistar personalidades do mundo do software, o que inclui programadores, gerentes, empreendedores e todo o resto da fauna. Raramente a conversa fica técnica demais e geralmente é focada em aspectos sociais da tecnologia em questão ou de carreira.

Herding code

Um podcast de entrevista com desenvolvedores de software dos mais diversos estratos e funções. Baseados em Oslo, os apresentadores conversam com professores, pesquisadores e autores de livros, diretamente de eventos acadêmicos do norte da Europa. Como os programas dependem da ocorrência dos eventos, a frequência é irregular e é comum termos hiatos de alguns meses. Mais um caso de podcast que vale a pena assinar no feed e esperar.

Linear digressions

Comandado por Katie Malone e Ben Jaffe, este podcast discorre sobre as questões mais atuais sobre aprendizagem de máquina e ciência de dados. De todos os podcasts que já ouvi sobre o assunto, este é, de longe, o que tem o pessoal mais qualificado para discutir aspectos técnicos da área. Você não vai encontrar discussões ou explicações sobre o conceitos básicos de aprendizagem de máquina, portanto, não é indicado para quem já tem alguma familiaridade com o assunto.

Partially derivative

Eu nem sei quantos apresentadores esse programa tem, mas são muitos. O podcast discute notícias da área de ciência de dados e dá dicas de cervejas artesanais. Os episódios são agradáveis e bem estruturados, mas o programa em si não tem nada de especial. É uma boa referência para se manter atualizado.

Talking machines

Um filho da sociologia com a computação, este podcast discute os aspectos humanos do aprendizado de máquina. Questões como algoritmos racistas, exclusão tecnológica e questões éticas em grandes massas de dados são discutidos com frequência e propriedade. Talvez este seja um podcast importante não apenas para os estudantes, professores e profissionais de ciências de dados, mas para interessados em tecnologia em geral.

The changelog

Uma proposta muito parecida com o FLOSS Weekly. Um podcast semanal com um projeto open-source diferente em cada episódio. Termino gostando um pouco menos deste por conta da natureza dos projetos abordados. Uma parte significativa é sobre desenvolvimento web, coisa que eu sou incapaz de me importar menos.

Ubuntu podcast

Antigo Ubuntu UK podcast, este programa fala de atualidades do mundo Linux, com foco, obviamente, na distribuição Ubuntu e suas distros derivadas. Conta com apresentadores que trabalham com aspectos importantes do sistema operacional e em empresas/projetos de peso (IBM, Canonical, Linux Mint, etc). Falam com um inglês ao mesmo tempo britânico e diverso. Bom para ficar atualizado e treinar o ouvido com os diversos sotaques da terra da rainha.

É isso. Antigamente eu costumava ouvir muitos dos podcasts da Jupiter Broadcasting, como o Linux Action Show e o Coder Radio. O problema é que estes podcasts estão recheados de opiniões fortes sem muito embasamento. Isto é uma praga que assola o conteúdo opinativo sobre tecnologia: a preferência quase religiosa a certas empresas e tecnologias, assim como a demonização de outras. Depois que a adolescência acaba, isso começa a cansar.

Minha primeira semana na Nokia Store

Há algumas semanas, eu me perguntava como se diferenciavam as lojas de aplicativos das mais diversas plataformas móveis. Alguns dados como quantidade, qualidade e preço médio de aplicativos são bastante conhecidos do público consumidor, bem como dos desenvolvedores. Mas e quanto ao processo de publicar um novo app? Controle de qualidade? Tempo gasto? Custo de associação? E o acompanhamento do desempenho da aplicação lançada?

Com um novo projeto J2ME no horizonte, precisava encontrar um jeito de conhecer a tecnologia (que nunca tinha trabalhado antes) e aproveitei para responder minhas dúvidas sobre o processo de publicação de mais uma loja, a Nokia Store para S40 e Symbian.

Numa bela sexta-feira, fim do expediente, vi uma notícia no Hacker News sobre um certo site que havia liberado (quase) todas as bandeiras do mundo em formato PNG sob licença Creative Commons. Essa foi a oportunidade. Em 1 hora (sem contar melhorias e correções nas semanas posteriores) junto com um colega de trabalho, uma aplicação foi produzida. Trata-se de um simples quiz sobre bandeiras de países, utilizando Canvas e tratamentos de eventos um pouco menos básicos do J2ME. Embora simples, a aplicação ficou razoavelmente divertida, rola até hoje uma competição pelo maior placar aqui no trabalho. Também aproveitei para testar uma nova plataforma de Ads lançada pela Nokia (http://nax.nokia.com)

Não há muito o que comentar sobre o processo de publicação, já que ela não difere muito dos outros. Algumas vantagens são o preço (1 euro para associação) e o controle de qualidade, que chegou ao cúmulo de reportar que o About/Help não estava adequado para publicação, mostrando que além dos processos automatizados de teste, uma pessoa realmente abriu o aplicativo e testou. Mas não estou aqui exatamente para fazer um comparativo entre lojas ou convencer ninguém a publicar na Nokia Store (embora você realmente deveria, os 60 milhões de Ashas espalhados por aí estão esperando :D). Gostaria, na verdade, de mostrar algumas estatísticas que colhi na primeira semana de disponibilidade do aplicativo na loja:

Total de downloads: 6245
Total de países: 117

Ranking dos países (5 primeiros):

Número de downloads

País Downloads
Índia 927
Tailândia 570
Rússia 493
Brasil 444
Filipinas 348

Impressões de Anúncios

País Impressões
Índia 803
Rússia 578
Tailândia 396
Brasil 393
Paquistão 289

Anúncios clicados

País Clicks
Índia 17
Tailândia 17
Rússia 15
Indonésia 13
Brasil 8

CTR (http://en.wikipedia.org/wiki/Click-through_rate)

País Clicks Percentual
Bielorrúsia 2 50%
Líbia 2 28.57%
Quênia 1 25%
Iraque 3 20%
Kuwait 1 20%

CTR dos mais impressos

País Percentual
Tailândia 4.3%
Rússia 2.6%
Índia 2.1%
Brasil 2%
Paquistão 1.4%

Anúncios mais lucrativos por CTR

País Montante
África do Sul US$ 0.43
Tailândia US$ 0.39
Brasil US$ 0.30
Rússia US$ 0.15
Paquistão US$ 0.12

Algo que salta os olhos é como a plataforma é especialmente forte no BRIC. Lançar o aplicativo em inglês foi muito importante para ter visibilidade no mercado indiano, que lidera quase todos os rankings do aplicativo. A liderança da Índia, na verdade, só tem se acentuado a cada semana que passou depois da primeira, sendo responsável hoje por mais da metade do total de downloads do aplicativo. Quem sabe a próxima brincadeira com o S40 já saia com suporte a Hindi desde a primeira versão ;)

Torne-se um fazedor. Não pergunte-me como…

Nos últimos tempos tenho refletido com mais frequência sobre minha profissão. Eu, como muitos de minha geração, resolvi estudar computação por gostar de jogos, e sonhava um dia poder fazê-los. Essa ideia/lembrança é ponto chave na conclusão que tenho chegado nos últimos tempos.

Um jogo é um produto, um fim, uma solução. Fazê-lo era o que importava, não os meios para isso. Mas algo se perdeu no meio do caminho… eu aprendi a programar.

É um mundo fascinante, com uma quantidade brutal de detalhes, onde horas de esforço oriundo de meses ou anos de estudos produz resultados encantadores. Quase tão encantador quanto o produto desse ofício, é o ofício em si.

Visite qualquer cafezinho de uma empresa com programadores e verá. Eles estarão debatendo sobre linguagens, paradigmas, gerenciamento de memória, boas práticas, bla, bla, bla. Entra um rapaz do departamento jurídico, faz um comentário sobre “festa x” ou “jogo do Flamengo” e o assunto se mantém por 10 segundos, antes de voltar para “linguagens funcionais são mais adequadas que as imperativas para projetos do tipo y” ou “garbage colletors são uma porcaria”, e o pobre rapaz volta para sua sala. É quase como a vingança dos nerds, se não fosse patético.

Não, não acho que é mais legal falar sobre o show do Exaltasamba ou sobre a goleada do Real sobre o Barça, nem acho que aspectos técnicos são assunto proibido ou desagradáveis. Só acho que passo tempo demais discutindo problemas que não vou resolver, pois eles não são… bem… problemas. São nunances, características das FERRAMENTAS que utilizamos para resolver problemas de verdade. Ferramentas são coisas que usamos para fazer as coisas que importam. Ou você imagina um pedreiro filosofando sobre o cinzel?

“Mas se ninguém se preocupasse com essas coisas, não teríamos as ferramentas que temos hoje para trabalhar!”

Certamente. A diferença é que para as pessoas que constróem essas ferramentas, elas são o problema, não a ferramenta. Se você constrói as ferramentas, esse texto não é para você. A moral da história é: Foco no problema.

Argumentar por que Java agora é mais rápido que C++ para cálculos de transformadas de Fourier, ou vice-versa, tem a mesma utilidade para você quanto para os criadores das respectivas linguagens: Nenhuma. O problema é outro.

As gotas d’água

Hoje conversando com meu amigo Zanoni, comecei um monólogo idiota sobre como Design Patterns são inúteis no meu trabalho atual, mas como são importantes para certos tipos de projeto. Devo ter falado por 30 minutos, antes de perceber que um build que deveria resolver meu real problema já deveria estar me esperando.

Ao chegar em casa, me deparei com um comentário da Anna no Google+, e resolvi prolongar o tema nos comentários, emitindo a minha toda-poderosa opinião. Devo ter perdido pouco mais de 1 hora entre escrever e revisar o texto que postei. Sabe o que é mais engraçado? Não tem a mínima importância para ela nem para mim. Sequer vai melhorar nossa quarta-feira, quando ela ler.

Depois de longa e conturbada reflexão, decidi mudar esse aspecto de minha vida. O processo vai ser longo, mas pretendo focar mais nos resultados concretos das coisas que eu resolva fazer. Tornar isso público no blog aumenta a pressão, e é isso que preciso agora. O primeiro passo vai ser reverter os vícios que a educação de nível superior me presenteou.

Afinal, como diz uma certa empresa de telefonia, “It’s not the technology, it’s what you do with it”.

Também quer se tornar um fazedor? Não pergunte-me como, acabei de tomar essa decisão!

Vivendo no browser – Semana 0

Lendo algumas notícias no Google+, me deparei com um depoimento de Linus Torvalds sobre a atualização que seu Chromebook havia recebido nos últimos dias. Eu suspeitava que Chromebook nada mais era que um netbook que rodava Chrome OS, e era isso mesmo. Também percebi que há tempos não acompanhava o progresso do sistema operacional, e resolvi conferir.

Ainda me incomoda a ideia de ter um sistema operacional que é pouco mais que um browser. Um ótimo browser, mas ainda assim, um interpretador de HTML+CSS+JS glorificado. Deixei o assunto de lado por alguns minutos, quando me deparei com uma notícia no Hacker News sobre o lançamento de um cliente SSH… para o Chrome. Opa! Foi aí que reparei na quantidade absurda de apps que a Chrome Web Store recebeu nos últimos meses, enquanto estive distraído com outras coisas.

Isso me fez pensar que para um usuário comum, que usa o computador apenas para lazer e editar-documentos-planilhas-ver-powerpoint-com-musica, o Chrome OS pode ser uma boa pedida. Chegou a hora de testar. Como a ideia de gastar  250 Obamas em um Chromebook apenas por curiosidade me pareceu indigesta, resolvi pegar o caminho mais barato e rápido. Consultando alguns tópicos no Quora, me certifiquei que o Chrome que roda no Chrome OS é o mesmo dos demais sistemas operacionais, e a compatibilidade de apps e extensões só é ferida quando o programa em questão utiliza alguma funcionalidade do sistema operacional¹.

Pois bem! Resolvi começar uma série de posts semanais, relatando minha experiência em viver uma vida quase totalmente em um browser. O que isso significa? Toda e qualquer aplicação desktop que utilizo, deve ser substituída por algo equivalente em forma de Chrome App. Claro que não vou poder realizar todas as atividades de meu trabalho nele, visto que certas coisas que faço são muito específicas e dependem de plataformas e compiladores específicos. Para tornar todo o experimento mais intenso, vou realizá-lo em todos os computadores que utilizo (tanto em casa quanto no trabalho), com exceção do Asus Transformer, visto que as extensões do Chrome ainda não são compatíveis com o Chrome Beta for Android, e no Lumia 710, por não ter uma versão do browser.

Lista de SOs:

  • Windows 7 64-bits
  • Windows XP 32-bits
  • Ubuntu 11.10
  • Ubuntu 12.04
¹ A extensão IE Tab, por exemplo, só funciona no Chrome sendo executado em ambiente Windows, já que necessita que o Internet Explorer esteja instalado.