Depois de se contruir 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, 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 corregir. 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 ser 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

A comunidade Portugal-a-Programar completou no passado dia 28 de Maio 6 anos de existência. Foram 6 anos a contribuir para a discussão e divulgação de temas ligados programação e informática em geral, que recentemente lhe valeram o título de um dos recursos online mais influentes na área das tecnologias.

A comunidade mantém diversos projectos, dos quais se destacam o fórum, um local privilegiado para a discussão e esclarecimento de dúvidas, a revista Programar, onde regularmente podemos ler artigos sobre diversos temas relacionadas com a programação e informática, e o wiki, um repositório colaborativo de conteúdos como tutoriais ou exemplos 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…

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 changelog (para além da descrição do widget, e onde colocarei outras informações relevantes).

Como parece que também havia bastante gente a usar o widget GuiaTV (tal como o Dicionario, este também da autoria do José Coelho), resolvi revê-lo, de forma a tentar resolver os problemas que tinha, e parece que ficou novamente a funcionar

Quem estiver interessado, pode fazer o download aqui.

No final do mês de Maio e início do mês de Junho vão se realizar três eventos no âmbito do programa UTAustin-Portugal (área de Computação Avançada):

• Spring School in Advanced Computing TACC @ IST (25-27 Maio, IST, Lisboa)
• Spring School in Advanced Computing TACC @ UP (28-19 Maio, FCUP, Porto)
• Advanced Seminar on Multicore Platforms (1-3 Junho, UM, Braga)

O Dicionário era um dos widgets que mais falta me fazia no MacOSX. 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.

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 a 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 a 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 na Time Machine: backups das últimas 24 horas, backups diários dos últimos 30 dias, e backups semanais no resto (no entanto, alterando algumas vará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 MacOSX, 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 2 anteriormente citados.

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 suas páginas, e que contribuirão para uma web mais acessível, por vezes até para utilizadores normais.

Algumas ligações úteis:

• Web Accessibility Initiative
• Web Content Accessibility Guidelines 1.0
• Web Content Accessibility Guidelines 1.0 (versão em português)
• Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
• Complete List of Web Accessibility Evaluation Tools
• Overview of WCAG 2.0 Documents

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