Dica rápida: configurar retools para usar redis em local fora do padrão

Sabe aquela besteirinha que te faz perder um tempão? Esta é uma delas.
O pacote retools fornece diversas ferramentas baseadas no Redis como filas de mensagens e cache. Que são as funcionalidades que tenho usado. Porém, ele procura pelo redis em seu local padrão: localhost:6379.
Isso me fez perder um tempão ao tentar montar um ambiente de testes em

Docker: não importava as alterações nas configurações, continuava o mesmo erro. Até ver no log que o erro era no retools e não no framework, perdi um bocado de tempo.
Ele ter uma configuração simples por padrão é uma boa, mas pode levar a erros bobos como este. Para resolver, é só fazer isto:

import redis
from retools import global_connection


global_connection.redis = redis.Redis(host='myhost', port=6379)

Para mais detalhes dos parâmetros, é só clicar aqui e ir direto para a documentação do Redis-py. ;)

Por hoje é só isso.

Aumente o número de acessos a seu site - Sistemas de busca

Vamos explicar o básico para que seu site ganhe bastante com o uso de sistema de buscas. Como sabemos, os sistemas de buscas aumentam a visibilidade do seu site ao indexá-lo e exibir nos resultados de buscas. Porém, eles utilizam diversos critérios para definir quais sites são mais relevantes para a busca, ou seja, quanto mais relevante seu site, maiores as chances de aparecer na primeira página de resultados das buscas.

Quais são os critérios usados para definir essa relevância? Eles variam muito de um sistema para outro, mas sempre funcionam em torno de um conjunto de pontos chaves. Que, vamos resumir todos dentro de visibilidade. Um conceito importantíssimo, pois um site com grande visibilidade, da forma que abordamos aqui, será muito visitado por si só através da famosa propaganda boca a boca.

Sites com vários idiomas em Django - Rosetta

Já faz algum tempo que entrei em contato com um pacote chamado Rosetta. Mas não mexi com ele. Fiz tudo que precisava no sistema e ficou esquecido lá. Só agora que fui trabalhar com ele de novo. E o achei que interessante.

Como o nome sugere, o Rosetta serve para tradução em vários idiomas. Como ele faz a tradução? Ele gerencia os arquivos de tradução do django. O que deixa tudo muito mais organizado e fácil de traduzir, pois tudo que você vai precisar fazer é preencher os campos para tradução no admin do Rosetta. Bem mais simples que lidar diretamente com os arquivos de idioma do Django, não é mesmo?

Antes de usarmos o Rosetta, precisamos gerar os arquivos de tradução do Django. Isso pode ser feito automaticamente. Primeiro, temos que configurar algumas coisas no settings.py. Pra começar temos que ativar o módulo i18n, que é o módulo de internacionalização do Django. Pelo que notei até na versão 1.4 do Django já vem ativado, caso não, ative-o no seu settings.py:

USE_I18N = True

O editor de textos Vim - Básico

O Vim é um editor de texto extremamente poderoso e muito utilizado. Para quem não o conhece, sua aparência não promete grande coisa. Mas as aparências enganam. Ele possui uma infinidade de funções e é extremamente eficiente uma vez que você aprenda a usá-lo. Chega a ser comparado com IDEs poderosas como Eclipse e NetBeans.

O maior problema do vim é aprender a usá-lo. O início do aprendizado sobre o uso do vim é penoso. Pois tudo depende de linhas de comando. Não há balõezinhos com mensagens de ajuda, nem menus, nem nada disso. Por isso, vamos disponibilizar aqui mais um material para tentar fazer com que o aprender a usá-lo se torne algo mais fácil.

O grande foco do Vim é ser extremamente eficiente e acelerar a velocidade de trabalho do desenvolvedor/editor que o usa. Por isso, ele toma em conta todos os menores detalhes possíveis para que você não tenha que tirar suas mãos do lugar. Algo que, para quem está acostumado com usar o mouse para quase tudo, é quase inconcebível. Na época da faculdade eu via um sujeito ou outro praticando vim/vi e pensava comigo: "Tontos masoquistas!". Hoje vejo que tinham razão. O Vim é difícil, mas vale a pena.

Versionamento, parte 2

Como prometido, segue a parte dois do post sobre versionamento.

Sistemas de versionamento

Eu disse que haviam várias ferramentas disponíveis, e por causa disso, não me estenderei demais nessa parte, mas citarei as principais com as quais eu já tive alguma experiência.

As ferramentas distinguem-se entre dois grandes grupos. As ferramentas de versionamento centralizadas e aquelas distribuídas. No final, todas acabam possuindo um servidor central para disponibilizar os arquivos do projeto, mas existe uma diferença sutil na utilização desse servidor.

Nas ferramentas centralizadas, o servidor é o mais importante. Todas as modificações são feitas com relação a ele. Sem acesso ao servidor, simplesmente não há como trabalhar, a não ser realizando modificações locais e depois enviando tudo de uma vez para o servidor quando esse estiver disponível.

Nas ferramentas distribuídas, o foco está nos programadores. O servidor é apenas um ponto de junção para todos os membros do projeto, mas o projeto pode continuar a evoluir em ele. Os programadores podem realizar commits locais caso o servidor não esteja disponível e depois enviar todos os commits de uma vez. A diferença aqui é que, enquanto no caso anterior todas as modificações formaram um único commit, e nesse caso cada modificação gerou o seu próprio commit com seu próprio comentário, tornando muito mais fácil rastrear as modificações e realizar um futuro merge do projeto.

Só para esclarecer, as boas práticas de versionamento determinam que um commit é uma unidade lógica de trabalho. Ele pode representar uma correção de um erro, uma funcionalidade nova ou uma melhoria. Ele também não está restrito a um único arquivo.

Um merge é a incorporação de commits no projeto principal. Quanto mais fragmentado e melhor separado os commits, mas fácil será juntá-los ao projeto principal.

Centralizadas: CVS e SVN

O modelo de versionamento centralizado foi o primeiro que surgiu, junto com as primeiras ferramentas. Desse grupo, vale a pena destacar o CVS e o SVN.

CVS ou Concurrent Version System (Sistema de Versões Concorrentes) foi um dos primeiros a surgir, já não é o melhor que existe, mas ainda está em funcionamento em muitos lugares, talvez pela simplicidade, talvez por ter chegado primeiro e muitos estarem acostumados com ele, além de existir extensões e plugins para inúmeras ferramentas de desenvolvimento, que incorporam o CVS dentro da ferramenta.

O sucessor do CVS é o SVN ou Subversion. Ele trabalha no mesmo princípio do CVS mas traz muitas melhorias. Atualmente é um dos principais sistemas de versionamento que exite e inclusive possui diversos sites fornecendo hospedagem gratuitas para projetos usando o SVN, como o google. A maioria dos sites que fornecem hospedagem gratuita fazem isso apenas para projetos de software livres mas há alguns que permitem desenvolvimento privado, como o Project Locker.

Distribuídas: Mercurial, git, etc

Dentre os modelos distribuídos, posso citar o Mercurial, GIT ou Bazaar como os principais. No caso do GIT, além do Project Locker, existem serviços como o Git Hub e o Gitorious que também permitem o cadastro de projetos que sejam livres.

Recentemente tenho trabalhado com o Mercurial e tenho tido boas experiências. Uso o serviço Bitbucket que permite projetos tanto livres como privados. Em sua última atualziação, o Bitbucket também passou a oferecer hospedagem para progetos em GIT.

Além do suporte de versionamento esses sites costumam também disponibilizar uma wiki e uma página especial para reportar bugs para o seu projeto.

Algumas dicas

Você não precisa usar as ferramentas de versionamento no terminal (apesar de que, com a prática, vai parecer mais simples). No caso do SVN no windows você pode usar o TortoiseSVN, que cria no menu do windows explorer um menu para realizar as tarefas de versionamento.

No caso do Mercurial existe o TortoiseHg, tanto para Windows, Linux ou Mac, que também é uma ferramenta visual. Se você está usando alguma IDE, é bem possível que existam plugins para ela que facilitem o uso de versionamento.

Para o GIT, no windows, existe a possibilidade de usar o TortoiseGit.

É possível versionar qualquer tipo de arquivo. Imagens, binários, documentos além dos arquivos de código fonte. O problema é que a ferramenta só consegue calcular as alterações entre duas versões em arquivos de texto puros, como os códigos fontes. Ao versionar um arquivo que não é um texto puro, a ferramenta verá que a data de modificação do arquivo é maior que a data da ultima versão, então ele substitui a versão anterior pela mais nova. Na prática, ele está só criando novas cópias, o que não é um uso muito inteligente de espaço no servidor, mas quebra um bom galho.

Conclusões

Versionar é mais importante do que parece. Infelizmente, só sentimos falta dele quando surgem os problemas. Através do versionamento fica mais fácil controlar as mudanças, distribuir patches e trabalhar de forma colaborativa. A prática do versionamento já está bem madura no mundo e é possível encontrar diversas ferramentas e tecnologias para atender as mais diversas necessidades.

Mesmo sem o uso de alguma ferramenta própria, também é recomendável adotar o uso de versões no nome dos arquivos, principalmente se eles podem mudar e você vai distribuí-los. Por exemplo, você tem o trabalho_de_historia.odt no seu computador e vai enviá-lo para o seu grupo para esse avaliar o resultado. Haverão sugestões você mudará algumas coisas, alguém mudará algumas coisas e, no final, você precisa mandar o trabalho pra professora e você tem três arquivos trabalho_de_historia.odt espalhados no seu computador, um na pasta downloads, um na documents e um na sua pasta de trabalhos. Qual é o mais recente para você entregar a professora?

A dica é use um nome como trabalho_de_historia_v1.odt no seu documento e incremente esse valor sempre que o arquivo for alterado, dessa forma, pelo nome do arquivo, você sempre saberá qual é o mais recente.

Att,

Versionamento, parte 1

Olá leitores se é que ainda existem do LeGauss!

Estou arrependido de ter deixado o Tiago e o Gabriel transformarem o LeGaus em um blog de matemática e vou compensar isso com um post sobre versionamento, o que é versão e como podemos usá-las no nosso dia a dia.

Introdução

Vou falar agora sobre um assunto de extrema importância e que é subestimado durante a graduação. Mesmo no curso de computação da USP, só ouvi falar disso uma única vez em cinco anos de curso. Tive que aprender sobre versionamento nas minhas atividades extracurriculares por minha própria conta.

Mas, apesar de ignorado pelo meio acadêmico, o versionamento está presente em todo o resto do mundo do software. Na verdade, não existe desenvolvimento de software sem o uso do versionamento. Mas o que é versionamento?

Como o próprio nome sugere, versionar significa colocar sob versão. Por exemplo, versão 1.0, 2.3.5 ou Beta. Basicamente, cada um adota um determinado padrão para a nomenclatura das suas versões, mas todos funcionam da mesma maneira. Quando os programas sofrem alterações recebem uma nova versão que reflete isso e cada versão é única durante a vida de um software.

A distribuição Ubuntu, por exemplo, adota o ano e mês de lançamento para compor a versão, ou seja, o Ubuntu 10.10 tem esse nome porque foi lançado em outubro de 2010. Outras pessoas gostam de adotar o padrão de três números 1.1.1, onde, da esquerda para a direita significa grande, media e pequenas modificações. Ainda existem umas versões especiais, como Alpha, que representa um software ainda em fase de desenvolvimento, Beta, que significa que um programa está em fase de testes finais ou RC (Release Candidate - Candidato a lançamento), que se assemelha à Beta, é um software maduro aguardando uma homologação para ser lançado oficialmente.

Mas o que é, de fato, versionar???

Versionamento é usado para se rastrear as modificações que um software sofre ao longo do tempo. Dessa forma, é possível saber se estamos com a versão mais atual, ou senão, qual update realizar. Cada versão nova pode corrigir bugs, adicionar novas funcionalidades ou melhorar o desempenho, por isso é importante manter tudo atualizado (com algumas exceções).

Se você está trabalhando em um ambiente controlado que integra diversas tecnologias, você só pode fazer o update do seu software depois de um estudo sobre o impacto disso no seu ambiente de trabalho. Por exemplo, pode ser que um dos seus software passe a salvar os arquivos de forma diferente e você importava esses arquivos com outra ferramenta que só lê esses arquivos na versão anterior, então neste caso, um update da primeira ferramenta não pode ser executado.

O versionamento é feito armazenando-se as pequenas modificações sofridas pelo software. Dessa forma é possível recuperar os diferentes estados do software ao longo do tempo. Isso é importante quando queremos passar adiante as modificações, pois não se precisa fornecer todo o software novamente, mas somente as modificações que ocorreram desde a última atualização, resultando em um arquivo muito menor e um processo de atualização mais rápido.

Você também tem a liberdade de voltar à versões anteriores e seguir uma linha de desenvolvimento diferente, também conhecido como fork de um projeto.

O que versionar?

Desenvolver um software envolve muitos elementos, então, quais deles devem ser colocados sob versionamento? No mínimo, você versiona o código fonte, ou o diretório onde encontra-se o projeto. Também versiona-se qualquer documentação sobre o projeto e qualquer arquivo extra que seja distribuído junto com o software.

Alias, você também pode versionar documentos e outros tipos de arquivos pessoais. Somente tome cuidado com o versionamento de binários, que é um pouco diferente de arquivos de texto.

Por que versionar?

Você deve estar se perguntando, o que isso importaria para você, que não trabalha em um grande projeto ou coisa assim?

Se você trabalha em algum programa, mesmo que pequeno, mas em parceria com outras pessoas ou apenas gostaria de compartilhar seus resultados já é possível colher as vantagens do versionamento, pois essas ferramentas também possuem mecanismos para otimizar o trabalho em equipe e facilitar o trabalho simultâneo de várias pessoas em um mesmo programa. Compartilhar os arquivos e suas modificações usando um gerenciador de versionamento é bem simples.

Versionar também é uma boa forma de backup, já que o código fonte e outros arquivos ficam em um servidor, e você pode sincronizar a pasta do projeto de onde quiser. Apesar que:

VERSIONAMENTO NÃO É BACKUP

Não use o versionamento simplesmente como uma forma de backup, existem ferramentas e técnicas bem melhores para isso.

Vamos considerar um exemplo

Vamos inventar um cenário onde fiquem mais claras as vantagens do versionamento.

Vamos supor que você esteja fazendo um programa que calcule números primos, como por exemplo, uma implementação do Crivo de Eratostenes. Porém, você não está fazendo esse programa sozinho, você conta com a ajuda de um amigo que vai te ajudar com algumas partes do programa.

Assim, o desenvolvimento de dará da seguinte forma, você vai fazer umas funções e ele fará outras (não necessariamente ao mesmo tempo) e vocês juntarão as duas partes. Para tanto, existem os seguinte métodos:

Método tradicional

Se você não está familiarizado com versionamento, o que é o mais provável, você certamente optará por este método.

Você começa a desenvolver o programa, então envia por e-mail o código fonte para o seu amigo para que ele continue a desenvolver. Ele envia para você de volta o arquivo mais completo, e isso se segue por um tempo.

O problema começa quando ambos começar a depurar seus respectivos código e enviar as correções um para o outro. Isso é feito enviando o seu código inteiro para o seu amigo e, como ele provavelmente terá um código diferente do seu, vai precisar caçar e implementar as mudanças na mão, e o mesmo vale para você.

Na maior parte do tempo, os programas serão bem diferentes um do outro, e a caixa de e-mail ficará lotada de arquivos fontes e se tornará bem complicado distinguir entre as versões, afinal "quando foi que você me enviou a aquela correção mesmo? Com que assunto estava o e-mail?".

Método tradicional - compacto

O método compacto parece mais atrativo mas é ainda pior. Ao invés de se enviar o código fonte inteiro, envia-se somente a função que foi modificada no próprio corpo do e-mail e indica-se onde substituí-la no código. Fica ainda pior de rastrear a evolução do software e saber quais alterações precisar ser feitas ou não.

Método tradicional - hardcore linux

Se você é um usuário linux, existem algumas facilidades para se enviar modificações em um arquivo texto. Você pode criar um arquivo contendo somente as modificações que ocorreram usando o comando diff e gerando um arquivo de patch.

Esse arquivo contém todas as modificações para transformar um arquivo em outro, ou seja, da última versão que você enviou ao seu amigo para a versão que você está agora. Por conseqüência, esse arquivo é menor que o fonte. O patch pode ser aplicado usando-se o comando patch, que aplica automaticamente todas as modificações e faz com que o arquivo fique na última versão.

Apesar disso, esse modo ainda possui problemas de rastreabilidade de modificações do código fonte. Antes de começar a modificar o arquivo, você tem que manualmente aplicar o patch para garantir compatibilidade com o projeto e ambos devem ter uma versão de referência separadas no computador nas quais devem aplicar os patchs seus e do seu amigo. 

Método com versionamento

E finalmente o método com versionamento. Primeiramente, é escolhida uma das diversas ferramentas disponíveis. Então é criado um repositório em um servidor com os arquivos do projeto. Esse servidor será quem fará o controle da versão e distribuirá as versões entre os membros do projeto.

Cada um que for trabalhar nesse projeto fará um checkout de todos os arquivos do projeto do servidor para uma pasta local. Então, sempre que quiser fazer alguma alteração no projeto, basta fazer um update para atualizar seus arquivos para a última versão, alterar o programa como você quiser, e depois realizar um commit para enviar as modificações para o servidor.

A cada commit no servido uma revisão é criada. Boas práticas de programação obrigam cada um que realizar um commit em um projeto a também anexar um comentário nessa revisão, o que torna a rastreabilidade da evolução do projeto bem mais fácil. Pode-se ainda apelidar as revisões e, assim, criar uma versão. Por exemplo, após 100 commits você estará na revisão 100 e estará lançando a versão 1.0 do seu programa.

A ferramenta de versionamento sabe exatamente qual versão você se encontra e baixará todas as modificações que ocorreram na ordem certa do programa desde a última vez que você o atualizou. 

Nos caso em que você já alterou sua versão e ela não era a mais nova, a própria ferramenta tentará fazer um merge das modificações, ou seja, a ferramenta tentará incorporar as suas modificações na versão atual automaticamente, bastando apenas, depois disso, realizar novo commit para atualizar a versão do servidor. Caso o merge automático falhe, ainda é possível realizá-lo na mão.

Dessa forma, ambos sabem como o software está evoluindo pois as modificações são rastreáveis. As ferramentas permitem você transitar entre as revisões (você não precisa trabalhar necessariamente na última), você pode fazer um fork do projeto e iniciar um novo projeto a partir da metade desse. E o mais importante de tudo, você pode compartilhar seu projeto e pessoas podem facilmente baixar, haquear o código e propor alterações que você pode escolher facilmente incorporar no seu programa. 

Continua...

No próximo post falarei sobre os sistemas de versionamento, ferramentas, e a conclusão desse post.

Att,

E se você tivesse um programa que juntasse/separasse PDFs?

Há algumas semanas, o Tiago (com h cortado do nome) sugeriu a implementação de um pequeno software que fosse que capaz de separar partes de um arquivo PDF em pequenos arquivos PDFs. Desenrolamos melhor a idéia e eu desenvolvi nos últimos dias um pequeno programinha em Python que realiza algumas tarefas relacionadas ao tratamento de documentos em pdf. Faltam poucos detalhes, entre eles o nome.

O programa é pequeno e leve, e necessita do ghost view (usualmente, vem instalado). Naturalmente, estamos falando de um software que roda em Linux. Atualmente, ele separa partes do PDF e une diferentes arquivos PDFs em um só. Isso é razoavelmente útil, principalmente porque é chato ter que ficar usando sempre o terminal gs. Vou expandi-lo em breve para fazer algumas outras tarefas, que ficam, por hora, em segredo.

O motivo maior desse é o nome do programa. Naturalmente, vou soltá-lo sob alguma lincença de free software (não sei ainda qual), e provavelmente no Google Codes. Como vou continuar indefinidamente a desenvolvê-lo, isso será muito bom. Agora fica com vocês: comentem com nomes que vocês acham que ficaria bom. Até semana que vem, terei o código no Google Codes e, para isso, deverei ter o nome: analisarei proposta por proposta e escolherei a melhor.

A única idéia que tive até agora é PyDFTools. Conto com a participação de vocês! : ) Divulguem!