Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)

20 julho, 2006

Edge e-mag redesenhado

O número de Julho de 2006 do magazine electrónico edge da Adobe foi redesenhado, passando a ser feito aplicando web standards, xhtml e CSS.

technorati tags:, , ,

Blogged with Flock

16 julho, 2006

Quirky serifs aside, Georgia fonts win on Web - Style - International Herald Tribune

Que coisa estranha um jornal generalista a falar de um aspecto tão obscuro como é a tipografia, Georgia ganha na Web

Se quizer ler o artigo completo no Herald Tribune iht.com/articles/2006/0...

14 julho, 2006

Câmara Municipal de Torres Vedras

Uma das coisas que me assusta é continuar-se a assistir à recriação de sítios de diversos organismos públicos que praticamente não servem para nada para além de repositórios de informação.

Veja-se por exemplo que a Câmara Municipal de Torres Vedras acaba de lançar o seu novo sítio na Web em www.cm-tvedras.pt .

O site foi concebido com técnicas standard (uma raridade na web portuguesa pelo que devo dar os parabéns à Slingshot), mas não me interessa só a roupagem (mesmo que só a interior ou seja o código) mas o conteúdo. E este parece-me parco. Será assim tão interessante saber a identificação dos vereadores ou poder efectuar interacção com os serviços do munícipio. Porque é que quando a câmara decidiu partir para um redesenhar da sua presença na net não observou o que de melhor se pratica cá e lá fora e tentou abrir o leque de serviços que se podem usar. Francamente parece-me um desperdício de recursos.

Para mim este sítio tem ainda o defeito de ter um número excessivo de ligações na sua página inícial: 74.

No entanto volto a dizer bom trabalho para quem criou o código, trabalho abaixo do que espero hoje para quem concebeu a arquitectura de informação do sítio por ser excessivamente pobre.

Por exemplo na secção «VISITAR» não há nada noutra língua que não o Português algo que não consigo comentar sem umas fortes palavras impublicáveis...

07 julho, 2006

Ranking de Serviços Publicos - Portais do Cidadão

No sítio da Umic diz-se que:
Subidas de Portugal no Ranking de Disponibilização Completa Online de Serviços Públicos, de Out. 2004 para Abr. 2006: • De 15º para 11º nos 28 países da UE25 + Noruega, Islândia e Suiça, • De 13º para 10º na UE25, • De 11º para 7º na UE15...
Eu até dou de barato que há mais serviços disponíveis em linha por cá o que eu desconfio é da respectiva qualidade. Só encontrei um portal do cidadão declaradamente pior que o nosso o austriaco. Para poder aferir por si eis uma tabela de resumo da situação.
País endereço, não liga erros html obs.
Portugal www.portaldocidadão.pt HTML 4.01 c/ 74 erros trata da acessibilidade como se estivesse em 1998
Espanha www.060.es XHTML 1.0 Transitional (valida) tenta a conformidade com WCAG WAI-AA
Itália www.italia.gov.it HTML 4.01, WAI-A, CSS
Reino Unido direct.gov.uk HTML 4.01 (valida) tenta a conformidade com WCAG WAI-AA
Áustria www.buergerportal.at s/ declaração doctype está ao nível amador, muito pior que o nosso
Alemanha www.buergerportal.de XHTML c/ 2 erros xml:lang e lang com valores nulos (deviam ser de), WAI-AA, CSS, secção 508 a conformidade com WAI-AA não é completamente conseguida
França www.internet.gouv.fr XHTML 1.0 Transitional ao nível do alemão embora não ande para aí a pavoniar-se
Bélgica www.belgium.be HTML 4.01 com o mesmo tipo de erros que o nosso

06 julho, 2006

Estruturando formulários com listas não ordenadas por Bruno Torres ponto net

Passei a usar esta técnica quando deixei de querer que o utilizador abrisse outra aplicação para além do browser. Para que isto funcione deve enviar-se uma cópia da mensagem ao próprio autor para que este a possa arquivar.

brunotorres.net/2006/04...

rikrikrik - CSS Reset

Tenho que voltar aqui, admito que uso esta técnica mas quero estudar mais isto. rikrikrik.com/log/css-r...

RailsBestPractices in Ruby on Rails

Na sequência da minha entrada de ontem só hoje fui

à fonte e vi isto wiki.rubyonrails.com/ra...

05 julho, 2006

Boas Práticas em Rails

Boas Práticas em Rails

Tabela de Conteúdos

Desenvolvimento orientado por testes

Isto é absolutamente essencial. A Rails torna a escrita de testes unitários e testes funcionais muito simples e assim é praticamente obrigatório usar testes para validar aquilo que se irá programar. Devem ser empregues tanto testes positivos como testes negativos: primeiro verificar que a aplicação faz o que deve fazer quando são passadas as variáveis adequadas para a acção correcta e depois verificar se passando variáveis incorrectas se passa a ocorrer o comportamento preferido.

Leitura recomendada

  1. Introdução ao Desenvolvimento Orientado por Teste

Teste Unitário

Como regra geral, os testes unitários devem testar todas as validações nos modelos assim como quaisquer métodos adiccionados a esses modelos.

Por exemplo, se tiver um modelo Utilizador que valide a presença do nome e do apelido (validates_presence_of...) nos respectivos campos e que tenha um método nomecompleto que combina os dois, é provável encontrarem-se os seguintes casos de teste: test_validates_nomes e test_nomecompleto, que irá testar o modelo para se poder verificar se funciona de acordo com o previsto.

Teste Funcional

Os testes funcionais são usados para testar controladores. Como regra, deve haver, pelo menos, um caso de teste por cada acção sendo necessário empregar também aqui os testes pela positiva e pela negativa. Isto significa que se tivermos uma acção create no nosso controlador de entradas PostsController deve haver pelo menos os métodos test_create e test_bad_create nos testes funcionais que efectuam os testes pela positiva e pela negativa. Isto não significa que devam haver só dois testes por cada acção. No caso de haver casos excepcionais para além de um simples bom ou mau, um teste adequado implica cobrir também esses casos.

Leitura recomendada

Migrações

As migrações significam nunca se arrepender de destruir completamente a sua base de dados. Permitem criar esquemas de bases de dados que são agnósticas quanto aos sistema de gestão de bases de dados específico, o que significa que pode desenvolver a sua aplicação localmente com SQLite e depois distribuir a sua aplicação com MySQL sem problema. São mais limpas (e mais fáceis) de escrever do que os seus esquemas à medida e devem ser sempre que possíveis usadas.

NUNCA, NUNCA, NUNCA por nunca alterar o ficheiro schema.rb pois é uma reflexão da sua base de dados. As migrações devem ser usadas para fazer a evolução. Se não usar as migrações e em seu lugar alterar o schema.rb as coisas passaram a ficar pouco estáveis e os seus utilizadores (e clientes) ficaram deveras pouco satizfeitos.

Nota: Deve sempre executar um svn update antes de gerar uma migração de modo a não ter que efectuar prefixos em colisões.

Leitura recomendada

  1. A Alegria das Migrações
  2. Manual abreviado sobre migrações em ActiveRecord
  3. Guia superfácil sobre de migrações

SQLite

SQLite é um motor de SQL que corre num único ficheiro em vez de num servidor. É normalmente tão rápido quando o MySQL e torna-se assim uma ferramente excelente para teste e desenvolvimento. De facto com a possibilidade de executar uma base de dados directamente e completamente da memória (uma pequena base de dados excepto se tiver muita memória RAM disponível) os testes são acelerados de forma significativa. Com o aparecimento das migrações, faz todo o sentido usar o SQL para teste pois não há trabalho adicional para a instalação da sua aplicação num ambiente MySQL.

DRY - Não se repita

A principal ideia da DRY (seca) é a de que se o código se repete é extraído para um ajudante (helper) ou uma função, assim passa a ter só um lugar para ver (e alterar se for caso disso) se algo correr mal. Se encontrar código similar em vários lugares poderá querer ler atentamente esse código e extraí-lo para uma função ou um parcial.

Leitura recomendada

  1. Rails API - Reproduzir parciais
  2. Refactoring de Marting Fowler

Convenções dos nomes

Não use abreviaturas, em especial nos nomes das colunas de uma tabela. Deve ser óbvio qual o conteúdo de uma coluna (pelo menos qual o significado do nome) quando se lê o respectivo nome. além disso o sistema de erros da Rails sabe como humanizar os nomes das colunas, quando usar um nome que descreva bem o conteúdo de uma coluna será mais fácil a apresentação de erros.

Se os nomes forem demasiado compridos, pense noutra expressão (palavra ou frase) com o mesmo significado, mas que seja óbvia.

Controlo de Versões (Subversion)

Deve ser usado algum modo de controlo de versões de forma contínua. Isto permite voltar atrás de forma fácil se algo correr mal, assim como a possibilidade de nos referir-mos a código antigo se necessário. A Rails tem alguns ficheiros que não devem ser incluidos no repositório central de fontes (gosto mais da palavra originais mas estou em minoria) e assim deve consultar esta página do wiki sobre preparação da importação inicial.

Sistemas de autenticação

Já foram escritos vários módulos para autenticação para Rails, alguns são melhores que os outros.

acts_as_authenticated
Deve ser o suplemento de autenticação preferido. É facilmente instalável via script/plugin, é fácil de ampliar e pode tratar de todos os aspectos dos restantes módulos de autenticação. Além disso o código de teste é excelente o que o torna fácil de alterar
login_generator
login_generator é o gem gerador de login original desenvolvido por Tobias Luetke. A desvantagem é que se surgir um erro que danifica a palavra de passe se gravar um utilizador já existente. Não deve ser usado por esta razão. Foi substituído e ultrapassado por acts_as_authenticated
SaltedHashLoginGenerator
Foi a primeira tentativa de criar um gerador de login (sem transporte da palavra de passe a descoberto) que conseguia alterar senhas e fazer activações. Foi extraído para login_generator. É excessivo e difícil de alterar. Deve ser evitado.
login_engine
É uma extração do SaltedHashLoginGenerator e como tal tem as suas desvantagens. Além disso usa o sistema de Rails Engines que deve ser evitado pois está quase a ser descontinuado. Se necessitar mais do que de uma pequena alteração deve ser evitado.

Sobre andaimes

Os andaimes podem ser uma forma de poupar tempo ou um verdadeiro aborrecimento. Quando os usar assegure-se de que compreende exactamente o que é que o código está a fazer e porquê. Uma fez alcançado tal pode tornar-se mais fácil e rápido escrever o seu próprio código pois é frequente ter que se alterar cada uma das secções que o scaffolding nos oferece.

Leitura recomendada (geral)

  1. The Pragmatic Programmer, por Dave Thomas e Andy Hunt
  2. Refactoring por Martin Fowler
  3. Agile Web Development with Rails por Dave Thomas e David Heinemeier Hannson
  4. Ruby for Rails por David A. Black
  5. Programming Ruby por Dave Thomas, com Chad Fowler e Andy Hunt