O Grupo de Trabalho do HTML acaba de distribuir a segunda edição do XHTML 1.1 - XHTML baseado em módulos como rascunho de trabalho em preparação para Proposta Editada de Recomendação. XHTML 1.1 é uma reformulação do XHTML 1.0 Strict baseado em módulos XHTML. Não se trata de uma nova versão, a segunda edição incorpora todas as correções conhecidas e acrescenta uma nova descrição em esquemas XML.
XML Events 2: Rascunho de Trabalho
O Grupo de Trabalho do HTML distribuiu o Rascunho de Trabalho do XML Events 2: Uma Sintaxe de Eventos para XML. Para associar comportamentos a marcadores, os conceptores de linguagens podem incorporar o módulo nesta especificação para integrarem escutas e manipuladores de eventos com interfaces de eventos de nível 2 do DOM. A versão 2.0 adiciona nova funcionalidade para tratamento condicional de ventos e adiciona elementos explicitos aos manipuladores. Também actualiza o esquema XML e o DTD e incorpora todos os erros conhecidos encontrados na Recomendação de Eventos XML de 2003.
Tem um sistema grande com milhares e milhares de testes. As suas compilações vão ficando cada vez mais lentas e começão a tornar-se um peso para a equipa. Está a trabalhar numa nova funcionalidade e uma grande parte dos testes testa algo onde não toca há meses. Continuando a desejar a segurança de não regredir em funcionalidade existente gasta várias horas do dia a testar algo que é pouco provável quebrar.
Solução
Criar duas compilações: uma compilação rápida e uma compilação completa. Mantenha uma lista de teste excluídos e exclua a maior parte dos testes da compilação rápida e faça com que esta seja realmente rápida, à volta de 10 minutos. Deixe só coisas que sejam muito prováveis quebrar, coisas em que esteja a trabalhar e coisas sensíveis. Não perca tempo a classificar teste, penso só se é provável que quebrem ou não. A compilação completa percorre todos os testes.
Execute a compilação rápida como parte de cada commit, antes do commit e como parte da verificação da integração contínua da compilação.
Execute a compilação completa menos frequentemente. À noite, algumas vezes ao dia ou numa máquina diferente executando em permanência (mas menos frequentemente visto sem obviamente mais lenta). Quando efectuar refactorizações grandes de componentes partilhado deve provavelmente executar uma compilação completa.
Adicionalmente mantenha uma lista de testes incluídos nas compilações rápidas, quando um teste falha na compilação completa deve ser de imediato adicionado à lista de testes a executar na compilação rápida e ser executado na compilação rápida seguinte.
Motivação
A função da integração contínua é dar uma resposta de imediato. Quando mais rápida for esta resposta mais rapidamente é possível corrigir o problema e seguir. Os ganhos de produtividade de uma compilação de 10 minutos é de uma ordem de grandeza mais elevada do que o de uma compilação de 1 hora.
Quando tem uma compilação grande e lenta essencialmente perde essa resposta rápida. Para voltar a ter essa resposta rápida constrói uma compilação rápida que irá potencialmente apanhar uma grande parte das falhas possíveis. Não sacrifica nenhuma segurança pois a compilação completa ainda é executada e protege-o contra regressões.
Esta segurança pode ser melhorada adicionando automaticamente testes que tenham falhado recentemente logo que falhem na compilação completa. Se falhou recentemente pode voltar a falhar, é óbvio. Também assegura que os programadores tratem de corrigir o teste visto não deverem efectuar commit com uma compilação rápida com defeito.
Ampliação
Este padrão pode ser ampliado incluindo várias camadas de compilações. Por exemplo pode ter camadas para compilação rápida, compilação completa e depois um conjunto completo de testes funcionais. Os testes funcionais com a totalidade dos sistemas de retaguarda ligados e activos podem ser extremamente lentos. Não é fora do comum ter conjuntos destes a correrem mais de 24 horas seguidas.
Numa das sessões do Google Edu, a responsável pelos testes dizia que considerava que o mínimo para estes testes serem executados era de cerca de 1 semana (pois o padrão de acessos varia com o dia da semana e a hora do dia).
Houve um dos meus leitores (algo que eu pensava não ser muito abundante) que me pediu para escrever em inglês. Até hoje não comentei o comentário dele, pois ainda não me tinha ocorrido a respostam mais adequada até que a encontrei aqui: "English As She Is Spoke."
Já agora, ainda não consegui ver o meu nome na lista do ILG pois ainda não me dei ao trabalho de migrar os meus conteúdos para uma nova plataforma, pois não consigo eliminar alguns dos erros que encontro nesta. Mas o trabalho não deverá demorar muito.
O jornal o Público pública hoje uma notícia com o título "Governo terá perdoado uma multa...", na notícia propriamente dita aparece um chico esperto (não se trata do Chico Esperto que prezo)que de forma simples vem dizer que os tripulantes de aeronaves que combatem fogos não necessitam saber português, basta-lhes saber falar português. O que é que lhes parece isto. A ser verdade que a pessoa disse isto o que é que pensam sobre o assunto?
Isto hoje está complicado esta entrada devia pertencer ao meu outro blogue e nele figura uma entrada que devia estar aqui. Porcaria de confusão. Totalmente culpa minha. Acho que vou duplicar as entradas.
Pistas e ligações a artigos para criação de folhas de estilo devem ser aqui coligidas. Para introdução do problema que estamos a tentar resolver ver [entrada no blogue do Simon]. Para ferramentas que ajudem na manutenção de folhas de estilo, ver TheToolsWillSaveUs.
[Arquitectar CSS], por Garrett Dimon, é uma boa revisão do problema com ideias fortes sobre como repartir as regras de CSS em diversos ficheiros.
[CSS Modular], por Mike Stenhouse, descreve um esquema simples onde as regras são agrupadas em diferentes ficheiros baseadas em assuntos: tipografia, formulários, arranjos e cor.
[Organização de CSS], por Doug Bowman, pistas sobre agrupamento e indicação de grupos. (Por acaso acho que a separação do CSS em vários ficheiros é contraprodutivo em termos de manutenção, mas pode ser só minha opinião.)
[Inclusão PHP em CSS], por Nick Bair, descreve o uso dos mecanismo de inclusão do PHP de modo a oferecer uma solução de ficheiro único para um CSS com facilidade de ser mantido.
Limitar especificamente o "alcance" das declarações de estilo. Por exemplo, tenho um certo estilo aplicado a conteúdo prefixo isso com um #conteudo, mesmo que não seja necessário. Especificar a parte da estrutura semântica a que o estilo se aplica irá essencialmente segregar o estilo de modo a que a cascata não afecte mais nada por acidente.
De forma similar separo o posicionamento da tipografia.
Desenvolver "conceitos" para o sítio/aplicação ajuda a manter as coisas sãs. Toda a decoração para cada conceito vai para o(s) seu(s) próprio(s) ficheiro(s). Exemplos de conceitos:
Carrinho de compras (carrinho-ecra.css / carrinho-impresso.css)
Tabelas de doces coloridas
Formulários de entrada de dados
Estes ficheiros podem depois ser ligados a tantas folhas de estilo quantas as necessárias.
CSS Fácil de Manter
As minhas recomendações para CSS Fácil de Manter. Admito que possa haver aqui alguma repetição mas estou a tentar ser mais conciso aqui.
Repartir o seu CSS no conceito coerente mais pequeno possível
Organizar ficheiros num conjunto de pastas que lhe permitam perceber a finalidade de cada ficheiro. Mantenha aquelas coisas que tenham elevada probabilidade de alteração como (cor, tipografia, gráficos, etc) projecto a projecto, ou semana a semana em localizações diferentes
Use ID raramente: ID tem que ser única numa página e assim sendo ao usarmos id em elementos estruturais significa que só iremos ter por exemplo um bloco conteudo numa página. Se for cuidadoso, #conteudo p é tão específico como .content p e <div class="conteudo">...</div> pode ser largado em tantos lugares quantos os necessários. Pode usar ID para algo como <div class="produto" id="produto00121">...</div> mas deve ter muito cuidado para se assegurar que só se refere uma vez numa página a produto00121.
Evite usar o mesmo nome de classe para diferentes finalidades: A cascata pode ser muito poderosa mas, por vezes, há a tentação de usar o mesmo nome de classe genérico em vários sítios. Se não segregar o seu CSS bem, pode correr perigo.
Usar sempre o mesmo nome de classe para finalidade similar: Visto a cascata ser tão poderosa deve reutilizar o mesmo nome de classe em diferentes classes quando representam o mesmo conceito.
Usar nomes de classes que revelem intencionalidade: Pode ser tentador usar nomes de classes breves mas demasiado cifrados (.s, .lbl) que no caso de não manter um glossário actualizado de nomes de classes irá esquecer o que querem dizer. Pode também correr perigo com navegadores desactualizados que podem ocasionalmente ser confundidos por nomes de classes breves que comecem da mesma forma (i.e. .err e .erros são, por vezes, confundidos.)
Colocar o seu nome de classe no elemento mais exterior onde faça sentido e Não Se Repita a Sí Mesmo (DRY): Por vezes irá ver coisas como:
Usar vários nomes de classes em todo o lado: As an example, if you have a form, fields are typically either required or optional and have an error or not. Without using multiple classnames you often end up with the following:
Isto frequentemente leva a muita duplicação de CSS visto a diferença entre exigido e opcional é normalmente um asterísco para indicar que determinado campo tem que ser preenchido. De forma similar campos onde haja erros são normalmente coloridos a vermelho ou são de algum outro modo realçados. Uma solução melhor é usar vários nomes de classes:
Numa recente entrevista a Eric Meyer quando perguntado por Todd Austin: Como é que as empresas podem ajudar as universidades a ensinar web standards, visto ter notado que muitos curricula ainda estão cheios de ensino de html com tabelas (para fins de arranjo)? Ao que Eric respondeu:
Deixem de empregar as pessoas que esses curricula produzem. É a única coisa que julgo iria funcionar, e isso não seria justo para as pessoas que não fossem empregues, visto não ser uma falha delas mas sim uma grande desajuda por parte dos seus instrutores. Mesmo assim, e mesmo sabendo que possa provavelmente parecer duro, será que as firmas de engenharia iriam empregar engenheiros que fosse treinados em engenharia do século XVIII? Será que uma firma de software iria empregar novos engenheiros formados em COBOL? Será que contrataria um contabilista que tivesse aprendido o Código de Impostos de 1950 e não tivesse aprendido nada desde essa data?
Porque é que será que as firmas da web devem fazer algo de modo diferente?
Substantial Experience with Ruby on Rails, XHTML, CSS, PHP and mySQL
Comprehensive Understanding of XML and AJAX
ability to work in an acronym-free environment
Não resisti acronym-free environment figura num anúncio para suporte a Mac.
Já agora aquele mySQL será que quer dizer MySQL.
Parece-me que ler este anúncio restaurou-me a boa disposição...
As imagens valem muitas palavras. Estas imagens têm palavras. O blogue de «quase gráficos» da Jessica Hagy é um daqueles que tem que ser visitado, ideia simples e muito bem conseguida.
Vi anunciado que O Jogo tinha uma nova página na web, fui ver. Meu deus (é um deus muito pequenino) quem serão os tecnólogos/decisores por detrás deste sítio. Estou a tentar manter-me objectivo mas o que produziram, no século XXI parece-se muito com o que se produzia há já 10 anos. Não queria acreditar quando vi o conteúdo original em formato de texto um documento que começa por <style>, não entendo. Uso de iframe com margens nulas e largura e altura a 100% sem esquadria para o iframe, isto claro como único elemento do corpo. Claro que não existe elemento head embora exista um elemento title. Isto é mesmo novo ou estou a delirar e a ver mal. Tenho que ir buscar o termómetro e ter cuidado para ver se ele não rebenta. Bolas, é digital, já não tem mercúrio.
Quando é que alguém entende que quantos mais elementos estiverem a passear pelos ecrãs das pessoas menos atenção as pessoas lhes prestam. 2 anúncios a piscarem e depois aquela linha com notícias é um pouco demais. Bom já chega de publicidade gratuita.
O próprio documento no iframe é uma verdadeira manta de retalhos, mas estou com tão pouca paciência que não me vou estender mais.
Claro que os autores desse sítios podiam-me responder na mesma moeda. Hoje ao finalmente deixar o blogger convencer-me a actualizar os meus blogues para a nova plataforma deles, criei-me um problema deixei de ter páginas válidas para passar a ter em média 50 erros (claro que os mesmo) e vou ver como poderei remediar isto.
Arranjo Multi-colunas Directamente da Caixa, por Alan Pearce. Neste artigo Pearce mostra como criar um arranjo elástico e líquido com três colunas com barras laterais de largura fixa e colunas com a mesma altura. É óbvio que se refere a técnicas já conhecidas mostrando as suas limitações.
Neste artigo Bobby Sluis fala dos vários métodos sobre como integrar um elemento com flash numa página. Fala dos métodos que estão e dos que não estão em conformidade com as recomendações do W3C, fala das limitações destes devido a excesso de abertura dessas mesmas recomendações, fala de constrangimentos devidos à instalação cliente e fala de uma tentativa de solução que está a preparar.
Mensagens
