Atualização do Deduplicated e aviso

Não consegui escrever um post semana passada, infelizmente estou com menos tempo livre do que imaginei que teria este ano.

Porém semana passada não foi improdutiva, consegui fazer alguns testes do Deduplicated, que com alguns ajustes agora está funcionando com todos seus recursos no Windows também. Quem quiser fazer a instalação pode dar uma olhada no histórico da Issue no GitHub. Aproveito para agradecer a todos que deram uma olhada no projeto e até as pessoas que entraram em contato para verificar alguma questão.

Também comecei a publicar o código do meu gerenciador pessoa, são todos os repositórios que começam com “ergo” no meu GitHub, ainda estou mexendo bastante e pode mudar muita coisa até ficar relativamente estável. Quando conseguir finalizar mais alguns módulos e ajustes, trago um texto explicando sobre o mesmo.

Estou querendo iniciar mais um projeto, uma série na verdade, já tenho os assuntos separados, porém ainda preciso estudar alguns softwares antes de iniciá-la, mas aguarde por novidades no futuro. O que posso adiantar é que será sobre Python, porém não exatamente sobre desenvolvimento em si.

Aproveito para avisar que o FLISOL está chegando, então entre no site e descubra qual o local que terá o evento mais próximo de você. Nos dois anos que participei foi bastante interessante com várias palestras e até minicursos. Se você não tem muito conhecimento sobre software livre é uma ótima oportunidade, conhecer a comunidade da sua região, ou até aprender uma tecnologia/ferramenta nova nas palestras. Lembrando que você pode utilizar software livre, mesmo se seu sistema operacional não for.

Por hoje são estes avisos curtos.

Anúncios

Remover arquivos duplicados

Há algum tempo, escrevi sobre o método que utilizo para fazer backup do meu hd externo. Porém quando comecei a utilizá-lo, tinha pouco mais de 500 GB de arquivos e muitos backups antigos, diretórios que quando iria formatava o computador, simplesmente olhava que faltava fazer backup de um diretório apenas, copiava-o inteiro, recuperar os arquivos mais importantes ou utilizados, enquanto os demais ficavam perdidos e ocupando espaço, mesmo já vindo de outro backup.

A questão é que eu tinha, pelo menos, uns seis backups, envolvendo formatação e cópias de pendrivers. Muitos desses arquivos estavam repetidos, significando que eu poderia deixar apenas uma cópia, apagando as demais e mesmo assim ter todos os meus arquivos.

O primeiro método que pensei foi gerar hash de todos os arquivos, e depois compará-los para encontrar duplicados, porém gerar hash de 500 GB é extremamente demorado e muitos desses arquivos não sobrem alterações, então não seria necessário recalcular toda execução. Olhando no sistema de arquivos, temos a informação de última alteração no arquivo, então bastava gerar um cache com informações de arquivo, hash e data da última alteração, toda vez que o for executado, poderia comparar primeiro a data de alteração e calcular o hash apenas se necessário.

Com o script pronto, a primeira execução foi demorada, uma vez que teria que calcular o hash dos 500 GB, levando algumas horas, encontrando 5 GB de arquivos que poderiam ser apagados sem que eu perdesse qualquer informação. Uma próxima execução foi muito mais rápida, não levando mais de dois minutos, desde que com modificações em arquivos pequenos.

Consegui logo apagar uns 2 ou 3 GB, porém a lista de arquivos duplicados, apesar de auxiliar no processo, não era algo muito prática, uma vez que teria que buscar o arquivo manualmente para apagá-lo. Com arquivos grandes o processo ia rápido, e liberava mais espaço, porém em arquivos de texto puro não dava um rendimento satisfatório. Como sou programador web, logo montei uma página para listar esses arquivos, com um checkbox para selecionar os arquivos que desejava apagar, deixando o processo todo muito mais prático. Hoje tenho menos de 5 MB de pequenos arquivos duplicados, que comparados aos 5 GB representa menos de 0,1%.

Reorganizei todo o código, aproveitando para montar uma interface web mais completa, e publiquei o código no github sobre licença MIT (https://github.com/eduardoklosowski/deduplicated), então quem quiser dar uma olhada, utilizar, ou até contribuir com o desenvolvimento do mesmo fique à vontade.

Uma explicação rápida para quem deseja utilizá-lo. Por ser escrito em Python, recomendo a instalação via pip com o comando pip install git+https://github.com/eduardoklosowski/deduplicated.git ou pip install git+https://github.com/eduardoklosowski/deduplicated.git#egg=deduplicated[web] caso deseje instalar as dependências da interface web. Com isto você terá o comando deduplicated, bastando utilizar os parâmetros update para atualizar o cache dos arquivos, duplicated para listar os arquivos duplicados ou check para atualizar o cache e exibir os arquivos duplicados, seguido de um ou mais diretórios que deseja verificar, exemplo deduplicated check /home/eduardo. Caso tenha instalado a interface web, basta executar o comando deduplicated-web e abrir o endereço http://127.0.0.1:5050/.

Também existe uma opção para verificar se um arquivo está no cache com o comando indir, exemplo deduplicated indir meuarquivo.txt /home/eduardo. A vantagem é que você não precisa ter os arquivos para fazer essa verificação, eu verificava se os arquivos do meu notebook estavam no hd externo desta forma, sem precisar estar com ele ligado.

Recentemente tive um problema com o meu hd externo, essa história está no hack ‘n’ cast (quando for publicado disponibilizo o link aqui). Como eu tinha o cache do meu hd externo, pude compará-lo com o meu backup, descobrindo o que não estava atualizado e se eu tinha perdido algo. Esse procedimento se resumiu a executar as funções de atualização do cache na manualmente para adaptar certas partes e listar determinados valores. Caso alguém deseje posso até montar o script como uma função extra.

Eu fiquei extremamente feliz ao conseguir economizar o espaço do meu hd externo, o que já valeu o programa. Quando tive problemas no hd externo, percebi que ter as coisas organizadas e automatizadas, podendo consultar alguns logs, torna tudo mais fácil e tranquilo, bastando efetuar o RMA e depois executar um rsync para resolver todo o problema, obviamente teve a parte de formatação e criptografia também.

MX Reverse e escolhas de frameworks

Se alguém deu uma olhada recentemente no meu GitHub, pode ter visto um repositório chamado mxreverse, que é um site que desenvolvi para validar o DNS reverso de servidores de e-mail. Apesar do código ser simples, tomei algumas decisões que gostaria de compartilhar.

Primeiramente a linguagem escolhida foi Python principalmente por ser a qual tenho mais domínio e facilidade, também achei uma biblioteca para fazer as pesquisas do DNS, possibilitando o desenvolvimento. Inicialmente pensei em criar uma função para fazer a validação com algumas funções auxiliares, que depois de alguns testes e tempo de desenvolvimento estava pronta.

Agora até aqui foi algo bem normal do qualquer projeto. Porém como disponibilizar esta função? Como utilizei uma biblioteca externa, além do meu código seria necessário também instalá-la para executar local, ou poderia disponibilizar um webservice, que possibilitaria reutilizá-lo com linguagens também. Como o código é Python, a forma mais simples, e provavelmente a mais recomendada é usar a especificação do WSGI, sendo uma única página, com apenas um parâmetro (o domínio a ser verificado), retornando um JSON, não tive necessidade de utilizar outros frameworks. Apesar de conhecer e gostar de Django e Bottle, o projeto não teria vantagens ao utilizar qualquer um dos dois, além de possibilitar fazer algo mais otimizado e simples sem um framework no caminho.

Com a API definida e funcional, era necessário um cliente que consuma a API e mostre as informações, caso contrário perderia a praticidade que gostaria, exigindo que cada um desenvolvesse seu código. Com as atuais aplicações em JavaScript no navegador, interessei me pela ideia de fazer uma página estática, utilizar AJAX para comunicar com a API e JavaScript para mostrar a resposta. Um framework JavaScript que tinha vontade de testar a algum tempo e aproveitei para fazê-lo neste projeto é o AngularJS. A principal ideia é atualizar um template HTML a partir de variáveis do JavaScript, ou seja, bastava ler o JSON e guardá-lo numa variável que o resultado seria mostrado na página.

O mais importante deste projeto é que mesmo que você conheça e goste de algum framework, ele pode não ser o melhor para a aplicação que está sendo desenvolvida. Abandonei a montagem do HTML em Python, passando para o JavaScript, deixei o código no servidor muito mais simples e aproveitei para conhecer outra forma de desenvolver aplicações, que poderei reutilizar em outros projetos onde ela se adapte melhor.

Resumo saia de sua zona de conforto, conhecer outros frameworks, por mais que superficialmente, pode ajudar na hora de montar uma aplicação, escolhendo uma arquitetura mais adequada.

Compartilhar prints com Django

Webprint

Algum tempo, desenvolvi um site com Django para compartilhar prints, motivado pela falta de praticidade do envio e visualização dos mesmo por email ou jabber. Seu código está disponível no meu GitHub. Não irei abordar como desenvolver um aplicativo Django neste post, porém vou deixar o link do tutorial da documentação oficial que é muito bom e da para se ter uma ideia inicial do seu potencial e praticidade, infelizmente apenas em inglês (https://docs.djangoproject.com/en/1.6/intro/tutorial01/, esse link é da versão 1.6, a mais atual na data de publicação deste post, porém é só procurar por tutorial na página principal da documentação de qualquer versão).

O meu objetivo aqui é mostrar o motivo de inicialmente ter gostado do Django, passado um tempo longe e posteriormente reconhecer o seu potencial. A primeira vez que tive contato com o desenvolvimento no mesmo foi maravilhoso e ver como as coisas eram práticas. Acesso ao banco de dados, formulários, templates, tudo era bem interessante e organizado.

Apesar das coisas serem práticas e ter um conhecimento razoável de Python na época, passava muito tempo pesquisando a documentação e sentindo que estava escrevendo uma coisa diferente de Python, apesar de ser a mesma linguagem. A falta de uma IDE com recursos avançados pode ter tido seu peso nisso. Porém não entender como era o seu fluxo com o HTTP e funcionamento com os middlewares do WSGI (que eu não tinha a menor ideia do que era na época) deixavam as coisas obscuras. Para quem veio de programação web com PHP e sem a utilização de um framework, acabei não gostando muito.

Tempo depois conheci o Bottle, por ser extremamente minimalista tive a impressão de voltar a programar da forma que tinha com o PHP. Como ele é extremamente simples (apenas um arquivo .py) e funcionar corretamente no Python 3 virou meu padrão de pensamento e tive a impressão de realmente programar para a web em Python.

Porém nem tudo é simples, utilizando-o diariamente no trabalho notei que passava muito tempo escrevendo código para acessar o banco, que logo foi adotado um ORM, porém para formulários continuava extremamente lendo e tedioso o trabalho, para minha surpresa não encontrei nenhum framework para resolver este problema. Voltei a olhar para o Django quando tive um tempo e lá estava uma solução para esse problema.

Ainda não desenvolvi nada grande com Django, porém hoje acho ele realmente completo para a tarefa, talvez não seja o melhor, mas é o que eu conheço (Python também tem mais frameworks web que palavras reservadas mesmo) e cumpre seu papel. Novamente fiquei surpreso ao perceber que o tempo que eu passava fazendo as coisas no Django e a forma como ele recomenda fazer as coisas era o que estava buscando hoje. Sim, ele também tem pilhas inclusas, ORM, formulários, autenticação e controle de permissão, tudo o que eu queria e iria precisar, ele já possuía.

O que aprendi com tudo isso é que sempre vale a pena aprender como um framework funciona e organiza o código de sua aplicação. Mesmo que não vai ser utilizado, essa ideia pode ser reaproveitada e se funciona é válido, mesmo que você odeie o resto dele, e quem sabe num futuro vir a ser adotado. Rails está na minha lista de coisas a aprender, embora ainda não conheça Ruby.

Aplicativo para Firefox OS

Firefox OS - Jogo da Velha

Como no FISL 15 tiveram várias palestras para quem era desenvolvedor web, com assuntos desde novos recursos do HTML5, API do JavaScript, design responsivo e mobile first, fiz um aplicativo para Firefox OS. Motivo é que desenvolver para Firefox OS é igual a desenvolver um aplicativo web para navegador com HTML, CSS e JavaScript, ou seja, dependendo das bibliotecas utilizadas é possível rodar o aplicativo também no seu navegador desktop, vídeo game e até TV.

O aplicativo que desenvolvi foi um jogo da velha (código no GitHub), tentei deixar as coisas o mais organizado possível e seguindo alguns padrões, porém se alguém tiver uma sugestão para melhorar o código avise ou faça um pull request.

Agradecimentos a Marcus Saad pela oficina de aplicativos para Firefox OS e Andre Alves Garzia pelo livro que disponibilizou gratuitamente (link para download), recomendo a todos que tiverem interesse no desenvolvimento de aplicativos para Firefox OS, além da documentação na Mozilla Developer Network.

Agora sobre o desenvolvimento do aplicativo. A principal diferença entre um site para um aplicativo do Firefox OS é o arquivos “manifest.webapp”, onde diz algumas informações extras como nome do aplicativo, descrição, desenvolvedor, ícone e página principal. Essa página principal é o caminho do arquivo que será executado pelo Firefox OS para iniciar o aplicativo, normalmente um “index.html”. Mais informações sobre o manifest na MDN.

Como não sou muito bom para bolar um design, utilizei o tema padrão, disponível no site “Building Firefox OS”. Basicamente é fazer o download dos arquivos do tema e adicionar o CSS ou JavaScript na página que for utilizar.

A estrutura do HTML não muda muito das páginas web padrão, apenas foram adicionadas alguns atributos para a utilização do tema. O CSS foi utilizado apenas para mostrar os elementos no lugar correto, porém vale lembrar que foi utilizado unidades relativas para manter um design responsivo e funcionar em vários tamanhos de telas.

O JavaScript talvez seja o mais complexo de todos, mas devido controlar toda a lógica do jogo e interagir com o HTML, não teve nenhuma diferença do que seria feito para um site normalmente. Porém lave lembrar que diferente dos computadores, no celular os recursos de memória e processador são menores e o código deve ser otimizado sempre que possível. Preferi deixar a lógica do jogo no model.js e as mudanças no HTML no app.js, seguindo a ideia do aplicativo apresentado no livro já citado. Obviamente ele poderia ter ficado muito mais simples se feito de outra forma, porém achei interessante este modelo e de fácil adaptação para outros aplicativos que trabalhem com alguma estrutura de dados.

Caso tenha alguma dúvida consulte o código do meu aplicativo ou do aplicativo desenvolvido no livro do Andre (código no GitHub), a documentação da MDN também é excelente, porém algumas páginas estão diferentes em português e inglês, então vale a pena consultar as duas versões que podem ter mais informações.