A lei [PDF]46/2006 publicada em 28 de Agosto de 2006 proíbe e pune a discriminação em razão da deficiência. Entra em vigor, hoje, com um pequeno defeito, o governo terá (nos termos da lei) que regulamentar a lei nos próximos 120 dias.
Temo que estes 120 dias se transformem em algo como o da regulamentação da lei sobre protecção dos animais. (Publicação em 1995 ou 6 não tenho a certeza e ainda por regulamentar.)
A página de entrada da Faculdade de Belas Artes da Universidade do Porto está conforme a recomendação XHTML 1.0 (Transitional).
No caso de querer ser mesmo picuinhas (muito mesmo) poderiamos dizer que:
Não sei se esta página tenderá a ser eliminada ou não devido à integração no site da UP de todas as faculdades sistema Sigarra.
O site acima parece-me não ter sido feito para nenhum público alvo sendo demasiado frio (tal como os sites que se apresentam no Sigarra).
Em resumo uma página cujo código é bom mas que parece não tender a resolver nenhum problema para ninguém.
Outras entradas de blogue recomendo (não se referem a código mas a AI (arquitectura de informação, usabilidade, ...) dos sítios do Sigarra:
P.S.: As páginas do Sigarra são compatíveis com HTML 4.01.
Alex Bradbury desenvolveu Ariel, uma biblioteca que usa exemplos pré-definidos para compreender como extrair informação de outros documentos. É um projecto do Google Summer of Code Project e foi mencionado por Austin Ziegler em Londres.
Também do Código de Verão de 2006 vem um relato de Jason Morrison sobre o seu projecto de inferência de tipo para usar na RDT para completar código.
Luke e Dan criaram um suplemento ujs4rails para a RoR para produção de sites com javascript não obstrutivo.
Com javascript não obstrutivo quero dizer algo como aquilo que é dito no número 218 do ala por Jeremy Keith que nele publicou um artigo designado por Separação de comportamento no qual apresenta uma analogia entre separação de estilo e separação de comportamento para páginas na web, para explicar porque é que se deve separar o javascript das nossas páginas.
No caso de desejar conhecer um pouco mais sobre isto recomendo ainda o artigo do Christian Heilman Unobtrusive Javascript.
Scott Laird em como avaliar percas de memória em Rails diz-nos que:
Um dos meus problemas mais antigos com a Rails (e a Ruby em geral) é que é difícil depurar as percas de memória. Tive um certo número de casos onde coloquei algo num array ou num hash e descobri muito mais tarde que o meu processo Ruby estava a comer mais de 100 MB de RAM. Embora o ps torne fácil ver onde o Ruby está a usar muita RAM, descobrir para onde é que foi é muito mais difícil.
O criador do Mongrel foi entrevistado por Pratik Naik .
Neste artigo do Hiveminds Magazine explica-se passo a passo o que fazer quando se quer abstrair a camada de ligação a uma base de dados em ruby.
Um guia básico sobre como usar REST em Rails. No mesmo sítio há umas notas sobre o que de importante Erik Kastner, o autor, aprendeu na RailsConf e RailsDay.
O texto e os comentários são importantes para ficarmos com uma melhor visão do assunto.
Um artrigo interessante para quem deseja saber o que e como usar CSS nas suas mensagens de correio electrónico:
Neste artigo David Greiner apresenta resultados de uma investigação sobre o comportamento dos clientes de correio electrónico baseados em PC/MAC ou na Web.
Blogged with Flock
height, background em elementos table. Ausência de atributo type em elemento script, valor de atributo que não faz parte do conjunto de valores admissíveis para esse atributo género absbottom em align. Não inclusam do atributo alt em imagens ((> 30) embora tenha que admitir que são espaçadores) na generalidade dos casos. Ignorância de como usar o atributo nowrap, etc, etc, etc. A página seria considerada noutras paragens como sendo feita de forma amadora.
alt e 1 uso de absmiddle como atributo de align. O tempo necessário para corrigir isto seria de quantos segundos? Embora a solução mais correcta tecnicamente esteja numa forma de construir a página diferente.
type obrigatório num elemento script e uso de atributos em body que foram substituídos por outros meios (deprecated) e uso do atributo hight em table. Tempo para corrigir isto algus minutos?
body. Restantes erros ver compta
body. Uso de atributos já substituídos.Fecho de marcadores não abertos, uso de elementos onde já não é possível usá-los (elementos que pertencem à head a surgirem dentro do body. Alguns erros introduzidos por tornar certas linhas comentários. Ignorância quanto à forma de codificar de forma válida um ficheiro flash.
scroll no marcador de body. Um não membro de um objecto VIEWASTEXT normalmente gerado pelo VS em desenvolvimento.
Em resumo nenhuma das páginas das empresas de tecnologias e internet registadas na bolsa valida. Algumas com pouco esforço poderiam validar. Mas algumas teriam que ser repensadas (não digo em termos de conteúdos ou aspecto) em termos de código.
Uma coisa de me deixa perplexo é a falta de separação efectiva entre o que é conteúdo, aspecto e comportamento nestas páginas mas a falta de profissionalismo (dos respectivos conceptores) é manifesta.
Padrões são soluções óptimas para problemas comuns. À medida que os problemas sejam levantados à volta de uma comunidade e resolvidos, soluções comuns frequentemente emergem de forma espontânea. Eventualmente, a melhor destas destaca-se da ganga e auto identifica-se e vai-se refinando até alcançar o estatuto de Padrão de Concepção.
Christopher Alexander foi o primeiro a nomear este fenómeno em relação aos espaços vividos. Ele e os seus co-escritores introduziram o conceito de Padrões de Arquitectura para descrever características dos espaços vividos fossem eles salas, edifícios ou cidades.
Os Padrões são atómicos no sentido de que podem ser agrupados para formarem padrões mais complexos: um padrão cadeira enquadra-se num padrão sala de jantar que se enquadra num padrão casa que se enquandra num padrão cidade.
Uma ideia que destingue os Padrões de simples prescrições é que os Padrões nunca perdem o sentido do seu contexto; descrevem coisas que funcionam em conjunto e as regras que governam essas colecções.
Os padrões de software encontraram uma grande ressonância na indústria do software em particular entre os que usam Metodologias Ágeis.
Algumas pessoas tiveram aqui inspiração para criar um documento sobre Padrões de Sítio da Web.
O colapso das margens é um conceito simples mas que pode gerar
alguns problemas quando não estamos atentos. Os maiores problemas
surgem quando aparece espaço vertical em branco adicional que parece
não querer desaparecer ou o outro problema parace ser a incapacidade de
criar espaço em branco na vertical usando o atributo margens
(margin) de alguma caixa (de algum elemento com
comportamento de caixa).
O que sucede é que quando duas margens verticais estão uma em contacto com a outra, em vez de se adicionarem uma à outra, a margem maior toma a precedência e a outra "colapsa" no nada.
Se der uma margem de 20px a dois parágrafos consecutivos (como elementos de um documento html) a margem do topo do parágrafo de baixo, visto tocar na margem do parágrafo de cima, cai e assim o espaço entre os dois parágrafos mantém-se nos 20px em vez de somar 40px.
A maior parte das pessoas pensar que o colapso de margens sucede quando um elemento do nível de bloco (um elemento com comportamento de caixa) se sucede a outro. Contudo as margens entram em colapso quando uma margem entra em contacto com uma margem adjacente. Isto significa que as margens podem entrar em colapso quando um elemento está contido noutro.
Isto sucede por exemplo quando se coloca um parágrafo (p) dentro de uma divisão (div), ambos com margens verticais. Se a divisão tiver uma borda (border) as margens não se tocam e somam-se, caso contrário juntam-se uma à outra tomando a precedência a mais larga.
Para evitar colapsos é vulgar adicionar-se uma borda de 1px de forma a que as margens já não se toquem e portanto já não colapsem.
Outro método é mudar a propriedade da posição (position) do elemento. As especificações CSS2(en) [pt] explicam que margens de caixas posicionais absolutamente e relativamente não colapsam. Outra possibilidade ainda é fazer flutuar uma das caixas. Nem sempre é apropriado alterar as propriedades de posição de um elemento, mas em certas circunstâncias quando estiver a ter problemas de colapso de margens poderá ser uma opção.
Há ainda a possibilidade da margem de topo de um elemento estar em contacto com a margem de fundo do mesmo elemento por exemplo um parágrafo vazio e nesse caso poderá suceder que o espaço ocupado pelo parágrafo desapareça de todo.
Pode ainda haver a situação mais complicada de ter elementos flutuados, seguidos de elementos limpos com uma margem de topo pouco mais alta do que o elemento flutuado e ter que se perceber muito bem o que é que se deve à flutuação de um elemento e o que se deve à pequena diferença de alturas entre o primeiro elemento e a margem de topo do segundo elemento (esperando que nenhum esteja completamente vazio).
Nesta especificação, a expressão colapso de margens significa que margens adjacentes (sem esquadria ou borda a separá-las) de duas ou mais caixas (que podem estar uma a seguir à outra ou aninhadas) combinam-se para formarem uma só margem.
Em CSS2, as margens horizontais nunca colapsam.
As margens verticais podem colapsar entre certas caixas:
Por favor consultar os exemplos de margens, esquadrias e bordas para uma ilustração de margens colapsadas.
O RadRails é um IDE para desenvolvimento de aplicações usando Ruby on Rails (RoR). Há cerca de 2 semanas foi actualizado para a versão 0.7. Esta versão trás como características novas capacidades de integração contínua, integração com tarefas rake, modelos de código RHTML, além de correção de erros (e provavelmente alguns novos). Já se sabe que o quem o desenvolve deseja minimizar as diferenças entre um IDE e o ambiente de caracteres, para minimizar essas diferenças podemos iniciar ou parar o servidor web, executar os nossos geradores, aceder à base de dados, instalar a maior parte dos suplementos de rails e executar as tarefas de rake
Rails Plugin Directory é um repositório de suplementos (plugin) para aplicações web desenvolvidas em Ruby on Rails (RoR).
Não se esqueça que os suplementos rails podem ser usados fora do IDE.
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...
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...
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 |
Na sequência da minha entrada de ontem só hoje fui
à fonte e vi isto wiki.rubyonrails.com/ra...
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.
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.
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.
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.
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.
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.
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.
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.
Já foram escritos vários módulos para autenticação para Rails, alguns são melhores que os outros.
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 alterarlogin_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_authenticatedlogin_generator. É excessivo e difícil de alterar. Deve ser evitado.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.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.
Mensagens
