Arquivo da Tag: programação

Usando o Git para Deployment de Websites

Há uns tempos atrás, depois de vários anos a usar SVN, e de uma breve passagem pelo Mercurial, decidi converter os meus repositórios de código para Git. Ao longo dos últimos meses tenho aprendido a usar este sistema cada vez melhor, muito com a ajuda do Google.

No meio das muitas pesquisas que efectuei, encontrei alguns artigos sobre a utilização do Git para efectuar o deployment de aplicações web. Decidi então investigar um pouco mais este assunto, e ver até que ponto podia tirar partido de um sistema do género. O resultado foi um sistema que me permite fazer o deployment de uma aplicação web através de um comando git push para um determinado repositório no servidor de produção. O Git do servidor encarrega-se de colocar as alterações enviadas online, num website de testes ou de produção, dependendo do branch em causa. A solução é bastante simples, e passa pela utilização de hooks, que são basicamente scripts executadas automaticamente em conjunto com outras acções do Git.

O primeiro passo para colocar o sistema a funcionar passa por criar um repositório Git no servidor remoto.  Neste artigo vamos chamar-lhe repo, e vamos colocá-lo em /var/git. Isto pode ser feito através dos comandos:

mkdir -p /var/git/repo
cd /var/git/repo/
git init --bare

(De referir que caso use a pasta /var/git irá precisar de permissões de administrador para executar os comandos.)

De seguida passamos à criação do hook. Neste caso concreto, vamos usar um post-receive hook, que é executado no servidor no final de uma acção push. Assim, para definir o hook criamos o ficheiro hooks/post-receive, onde colocamos uma script com as acções a executar depois de um push. Na primeira linha da script vamos colocar #!/bin/bash, para indicar quem vai executar a script. Na linha seguinte colocamos read oldrev newrev refname. O objectivo desta linha é permitir saber qual o branch que foi usado no push, de modo a permitir efectuar acções diferentes em função do branch, que ficará associado à variável $refname.

Agora passamos à parte de especificar as acções a realizar. Vamos assumir que existem dois branchs, o dev e o master, e que sempre que se fizer push do dev se pretende actualizar os ficheiros na pasta /var/www/dev/ e sempre que se fizer push do master se pretende actualizar os ficheiros na pasta /var/www/main/. Para tal, vamos usar o seguinte código:

case "$refname" in
	refs/heads/master)
		echo 'Deploying files to production website...'
		GIT_WORK_TREE=/var/www/main git checkout -f master
		echo 'Fixing file permissions...'
		# chmod ...
		echo 'Done.'
		;;
	refs/heads/dev)
		echo 'Deploying files to development website...'
		GIT_WORK_TREE=/var/www/dev git checkout -f dev
		echo 'Fixing file permissions...'
		# chmod ...
		echo 'Done.'
		;;
	*)
		echo "No deployment action (unknown refname: $refname)."
		;;
esac

O comando case trata de escolher a acção apropriada. Por exemplo, no caso do branch master, usamos o comando GIT_WORK_TREE=/var/www/main git checkout -f master para actualizar os ficheiros, indicando a pasta onde os mesmos são colocados através da variável GIT_WORK_TREE. Por vezes temos também que corrigir as permissões e/ou proprietários dos ficheiros, pelo que devem ser adicionados os comandos apropriados. Também podemos imprimir algumas mensagens de feedback, que serão mais tarde mostradas no cliente que está a fazer push.

Um pormenor a ter em conta é que o utilizador usado na operação de push terá que ter permissões para realizar as referidas operações (entre outras, precisará de permissões de escrita em /var/git/repo, /var/www/main e /var/www/dev).

Depois disto podemos então adicionar o repositório remoto do servidor de produção ao nosso repositório local através do comando git remote add <id> ssh://<utilizador>@<dominio>:/var/git/repo. E pronto, agora sempre que quisermos fazer deployment das actualizações feitas na nossa cópia local basta usar o comando git push <id> master, por exemplo.

Referências

  1. http://sebduggan.com/blog/deploy-your-website-changes-using-git/
  2. https://halfthetruth.de/2011/09/13/using-git-to-deploy-a-website/
  3. http://thekeesh.com/2012/01/lightweight-deployment-with-git/
  4. http://www.janosgyerik.com/deploying-new-releases-using-git-and-the-post-receive-hook/

Avaliação de Websites: Algumas Ferramentas Úteis

Depois de se construir um website, é conveniente fazer alguns teste, e verificar se está tudo em ordem, ou o que ainda pode ser melhorado. Desde validar o código HTML, até verificar se o desempenho das páginas é razoável, há várias coisas que se podem fazer. Ficam então aqui algumas ferramentas que podem ser úteis neste processo.

Ferramentas do W3C

O W3C fornece um conjunto de ferramentas de validação para avaliar a qualidade de um website. Entre essas ferramentas estão o Unicorn, que permite verificar se algumas das tecnologias usadas num website (HTML, CSS, Atom, etc.) estão de acordo com os standards. Temos também o Link Checker, que permite encontrar links inválidos. Ambas são ferramentas disponíveis online, e que não requerem instalação software.

Adicionalmente, podemos também usar o W3C::LogValidator, um conjunto módulos Perl que nos permitem correr as ferramentas de validação nos nossos PCs. Esta solução será particularmente útil para quem mantém websites de alguma dimensão. Pessoalmente, só experimentei o módulo para verificar links inválidos (e que me permitiu encontrar alguns erros que não tinha encontrado com a ferramenta online).

Acessibilidade

Ao nível de verificação de normas de acessibilidade, as melhores ferramentas que encontrei foram o WAVE e o AChecker.

O WAVE mostra-nos as páginas que estamos a verificar, com algumas anotações, alertando para problemas, ou potenciais problemas (que devem ser verificados manualmente). Esta ferramenta agradou-me sobretudo pela facilidade em utilizá-la.

Já o AChecker produz um relatório textual, também identificando problemas e aspectos que requerem verificação manual. Uma vantagem do AChecker (relativamente ao WAVE), é que nos permite facilmente consultar a documentação relevante para percebermos melhor os problemas e como o corrigir. Adicionalmente, também me parece mais completo do que o WAVE.

Desempenho

Hoje em dia, com as melhorias na qualidade das ligações à internet, há quem defenda que o desempenho não é propriamente um problema. Ou pelo menos, questões como o tamanho (bytes usados) das páginas, número de imagens usadas (ou até número de ficheiros), e afins, não são muito importantes. Uma das razões para discordar desta visão, é a utilização cada vez maior de internet móvel, onde a largura de banda é muitas vezes um problema.

Para descobrir aspectos a serem optimizados, recorri sobretudo às ferramentas disponibilizadas pelos browsers, nomeadamente o Web Inspector do Safari (que é em tudo semelhante ao do Google Chrome). Em particular, a tab Audits indica-nos vários aspectos que podem ser melhorados, como a utilização de compressão e caches, a redução do tamanho de ficheiros (quer ficheiros de texto, como CSS, quer imagens), a redução do número de ficheiros, entre outras coisas.

Outras duas ferramenta semelhantes para este efeito são as extensões para Firefox Page Speed e YSlow, que também me pareceram muito boas (na verdade, até achei estas mais completas do que o Audits).

Outros

Outro aspecto importante para um website é a sua visibilidade em termos de motores de busca. Aqui, ferramentas como o Google Webmaster Tools ou Bing Webmaster Tools, podem ser úteis, permitindo submeter sitemaps, ver erros encontrados no processo de crawling, redireccionar domínios, etc.


Existem certamente muitas outras ferramentas, e provavelmente melhores do que as que indiquei, até porque na minha pesquisa dei preferência a ferramentas gratuitas, e que pudessem ser usadas online. Mesmo assim, acredito que as ferramentas aqui apresentadas podem ser bastante úteis. E é claro, não se esqueçam de uma outra ferramenta também bastante eficaz a detectar problemas: testes manuais em diferentes browsers e sistemas operativos :)

Documentação de Código

Desde há umas semanas que tenho andado a analisar o código de duas aplicações de dinâmica molecular bastante conhecidas, e largamente usadas, o NAMD e o GROMACS.

Tendo em conta a reputação das aplicações, seria de esperar uma documentação a condizer. Mas se ao nível da documentação para o utilizador, até esteja bastante completa, o mesmo não se pode dizer da documentação do código. Não encontrei um único documento que descrevesse os vários módulos que constituem a aplicação, nem que descrevesse quais as funcionalidades das várias funções. A única solução possível para perceber a aplicação é, assim, percorrer as centenas de ficheiros que a constituem. E mesmo percorrendo os ficheiros, continua a ser complicado perceber quais as funcionalidades que estes disponibilizam, pois os comentários no código não abundam…

Custa-me um pouco a perceber como é que aplicações desta dimensão têm uma documentação tão pobre…

Widget DicionarioPT agora com conjugação de verbos

Era uma das funcionalidades que temos disponível no site da Priberam, mas que não estava acessível no widget. Agora este problema foi resolvido, e os links que permitem conjugar um verbo já estão a funcionar :)

Entretanto, aproveitei para criar uma página para o widget, onde está disponível um change log (para além da descrição do widget, e onde colocarei outras informações relevantes).

Dicionário de português – widget para Mac OS X

O Dicionário era um dos widgets que mais falta me fazia no Mac OS X. Infelizmente, há alguns dias atrás, depois de algumas alterações no site da Priberam (donde o widget extraía a informação), deixou de funcionar. Adicionalmente, o autor (José Coelho) também deixou de manter o widget.

Resolvi então dedicar algum tempo a analisar o código fonte do widget, de modo a tentar resolver o problema.

Nunca tinha trabalhado no desenvolvimento de widgets, nem com JavaScript (a linguagem mais relevante para este widget), mas a Apple disponibiliza uma excelente ferramenta para este tipo de tarefa, o Dashcode (que infelizmente só descobrir depois de já ter perdido umas horas a usar o Vim como editor, e a Console para ver os erros), e o JavaScript também é relativamente simples (a minha maior dificuldade foi não ter encontrado uma API com as funções que poderia usar).

E assim, aos fim de alguns dias, lá consegui colocar o widget novamente funcional.

Quem estiver interessado, pode fazer download do widget aqui: DicionarioPT.

Também criei uma página com informações sobre o widget aqui.

Time Machine no Tiger ou no Linux

Há algum tempo atrás, depois de começar a usar um MacBook como a minha máquina principal, decidi voltar a meter o Tiger no meu PowerBook. Tendo em conta o pouco uso que lhe dou actualmente, chega perfeitamente. A única funcionalidade que senti mesmo falta foi o Time Machine.

Tendo em conta que era uma funcionalidade que também me dava jeito no Linux, decidi investigar um pouco, para ver se encontrava alguma alternativa. Depois de ler isto e isto, consegui perceber o funcionamento da Time Machine. As scripts apresentadas nos sites indicados, tinha o problema de não fazer uma gestão tão elaborada dos backups antigos como o Time Machine. Assim, decidi fazer uma script um pouco mais completa.

O resultado final pode ser encontrado aqui.

É uma script Perl que faz backups incrementais (usando o rsync), e que apenas apaga os antigos caso seja usada uma opção disponível para esse efeito. A estratégia seguida para apagar backups antigos é semelhante à seguida no Time Machine: backups das últimas 24 horas, backups diários dos últimos 30 dias, e backups semanais no resto (no entanto, alterando algumas variáveis na script, podemos adaptar isto às nossas necessidade).

Para ter a script a correr de hora em hora é só adicionar uma entrada no cron (o ideal seria usar o launchd, mas estava a ter alguns problemas com esta alternativa).

NOTA: A script foi testada em Linux (Debian 4.0) e em Mac OS X, estando, aparentemente, a funcionar sem problemas. Ainda assim, recomendo algum cuidado com a sua utilização, pois pode conter bugs. Deverá funcionar em qualquer sistema UNIX, mas não testei em mais nenhum, para além dos dois anteriormente referidos.

Acessibilidade de Conteúdos na Web

Estive hoje a ler a recomendação da W3C para acessibilidade, versão 1.0 (a versão 2.0 ainda só é Candidate Recommendation), de forma a tentar melhorar as (poucas) páginas web que desenvolvo (o blog não está incluído, pois o software que o suporta não é desenvolvido por mim, mas mesmo assim espero também corrigir alguns defeitos).

Não tenho por objectivo cumprir todas as regras (espero pelo menos atingir o nível de conformidade A), no entanto, parece-me que a maior parte delas até são relativamente fáceis de respeitar. Apesar disso, passo a vida a ver sites de dimensão considerável a não cumprirem algumas regras bastantes simples, o que me leva a colocar a questão: será que os profissionais da área do desenvolvimento web se dão ao trabalho de ler as recomendações da W3C?

Fica a sugestão, para quem ainda não as leu, que o faça. Mesmo que não implementem tudo como é sugerido (pois é provável que tal obrigasse a que certas páginas não ficassem tão funcionais para os utilizadores normais, ou a fazer páginas não tão agradáveis visualmente), provavelmente ficarão a conhecer alguns aspectos que podem facilmente melhorar nas vossas páginas, e que contribuirão para uma web mais acessível, por vezes até para utilizadores normais.

Algumas ligações úteis:

Dois tipos de programadores…

Two Types of Programmers

There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%.

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.

Shocking statement #1: Most of the software industry is made up of 80% programmers. Yes, most of the world is small Windows development shops, or small firms hiring internal programmers. Most companies have a few 20% folks, and they’re usually the ones lobbying against pointy-haired bosses to change policies, or upgrade tools, or to use a sane version-control system.

Shocking statement #2: Most alpha-geeks forget about shocking statement #1. People who work on open source software, participate in passionate cryptography arguments on Slashdot, and download the latest GIT releases are extremely likely to lose sight of the fact that “the 80%” exists at all. They get all excited about the latest Linux distro or AJAX toolkit or distributed SCM system, spend all weekend on it, blog about it… and then are confounded about why they can’t get their office to start using it.

[…]

Quem quiser ler mais: http://blog.red-bean.com/sussman/?p=79