Eis um agregado de podcasts com o conteúdo da Idea Conference 2006 em Seatle.
Esta conferência dirigia-se a arquitectos de informação e a bibliotecários (os primeiros especialistas a terem que lidar com grandes quantidades de informação e necessidades inerentes de classificação, preservação e recuperação. Nota: a conferência foi realizada na biblioteca pública desenhada por um dos discípulos deKoolhaas, e também apresentada por Prince Ramus e podemos ver o que está por detrás do conceito desta biblioteca neste vídeo:
Durante a Idea 2006 a responsável apresenta a sua visão sobre a concepção da Biblioteca.
Em dezembro escrevi aqui um pequeno artigo sobre BDD - Desenvolvimento Orientado pelo comportamento e TDD - Desenvolvimento Orientado pelo Teste para melhor ilustrar a diferença hoje apresento um exemplo básico de desenvolvimento em TDD.
Os passos a seguir são:
Escrever o teste
Escrever a lógica
Fazer a lógica passar o teste
Refactorizar
A cada refactorização verificar que o teste continua a ser passado
Vamos pois passar ao primeiro passo escrever o teste mais simples possível. Em TDD em ruby a primeira coisa que há a fazer é criar um programa que comece por requisitar os testes unitários:
require 'test/unit'
Para exemplificar iremos criar um Exemplo e portanto iremos criar um teste designado por ExemploTeste:
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def test_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
end
Corra o programa e veja o que sucede surge um relatório com o número de presunções, falhas e erros com um erro (1 presunção, 0 falhas e 1 erro).
Passemos pois ao passo número 2.
Criar a classe a testar:
class Exemplo
def initialize
end
end
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def test_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
end
Se agora corrermos o teste iremos ver que não temos erros. Passámos o teste.
Se o programa só fizesse isto não servia para nada, por isso, imaginemos que quando um Exemplo é gerado o mesmo gera uma variável com uma string vazia. Ao teste existente acrescentamos um método:
class Exemplo
def initialize
end
end
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def test_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
def teste_exe
ex = Exemplo.new
assert_equal("",ex.exe)
end
end
Agora corremos novamente o programa teste e vemos que obtemos um erro, pois não existe variável exe na classe a testar. A nossa próxima acção é tratar de a incluir da forma mais simples para passar este teste.
class Exemplo
attr_reader :exe
def initialize
end
end
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def testar_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
def testar_exe
ex = Exemplo.new
assert_equal("",ex.exe)
end
end
Executando novamente o programa vemos que ele passa sem erros mas falha! Porque falta a atribuição inicial de valor a exe. Então tratemos disso
class Exemplo
attr_reader :exe
def initialize
# a arroba denota que é uma variável de instância
@exe = ""
end
end
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def testar_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
def testar_exe
ex = Exemplo.new
assert_equal("",ex.exe)
end
end
Agora se correr o programa este passa sem erros nem falhas. O programa evoluíu um pouco. Mas se uma variável não pudesse mudar de valor de pouco servia, vamos pois tentar criar um teste para a mudança do seu valor.
class Exemplo
attr_reader :exe
def initialize
# a arroba denota que é uma variável de instância
@exe = ""
end
end
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def testar_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
def testar_exe
ex = Exemplo.new
assert_equal("",ex.exe)
ex.exe = "Olá moça!"
assert_equal("Olá moça!",ex.exe)
end
end
Se corrermos o programa ele terá uma falha pois não há forma de mudar o valor. Então tratemos de o fazer.
class Exemplo
attr_reader :exe
attr_writer :exe
def initialize
# a arroba denota que é uma variável de instância
@exe = ""
end
end
require 'test/unit'
class ExemploTeste < Test::Unit::TestCase
def testar_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
def testar_exe
ex = Exemplo.new
assert_equal("",ex.exe)
ex.exe = "Olá moça!"
assert_equal("Olá moça!",ex.exe)
end
end
Agora já não temos nem erros nem falhas. Passamos o teste. Então chegou o momento de refactorizarmos a nossa classe Exemplo:
class Exemplo
attr_accessor :exe
def initialize
# a arroba denota que é uma variável de instância
@exe = ""
end
end
class ExemploTeste < Test::Unit::TestCase
def testar_initialize
ex = Exemplo.new
assert_not_nil(ex)
end
def testar_exe
ex = Exemplo.new
assert_equal("",ex.exe)
ex.exe = "Olá moça!"
assert_equal("Olá moça!",ex.exe)
end
end
Voltamos a correr o teste e podemos comprovar que a nossa refactorização correu bem.
Hoje o Público (edição em papel) tem uma tradução de um artigo do LA Times sobre a perca da inocência no Second Life. Como leitor atento do blogue da Adaptive Path tenho vindo a acompanhar uma série (ainda pequena) de artigos relativos às entrevistas conduzidas por Chiara Fox e Andrew Crow numa sala devidamente preparada pelo Linden Lab.
Já agora o quartel-general, da campanha do John Edward, foi vandalizado no Second Life.
Hugo Neves da Silva no seu Lisbon Lab tem um conjunto de entrevistas, que designa por BloggerView, muito interessantes.
Tim Berners-Lee testemunhou no Congresso Americano como períto sobre o futuro da www.
Porque é que não escrevo em inglês tem que ser actualizado.
Porque o meu conhecimento de inglês não chega aos pés do Language Log. Já agora este é um dos sítios de que assinei o respectivo alimento. É bom para aprender algo sobre a língua inglesa.
Há uma lista de elementos HTML que estão mal representados na generalidade da marcação usada actualmente na web. Vários destes elementos têm maior valor semântico que o que actualmente é aplicado, mas com o aumento da popularidade do design orientado pelo CSS com os elementos HTML a serem usados para o que foram concebidos julgo que seria bom expôr estes elementos indicando em que situações seriam úteis. Um desses elementos é o elemento address:
<address>
O marcador <address> foi concebido para conter informação sobre endereços, assinatura e autoria. Números de telefone, fax, endereços físicos, endereços de correio electrónico, ICQ/Gtalk... ou qualquer outros dados de contacto em linha e fora dela são todos válidos. Normalmente os elementos <address> encontram-se no topo ou na parte de baixo do documento.
Utilização:
<address>
O Nome da entidade
<br />
Rua do Mistério, 126
<br />
1025 Lisboa
<br />
Telefone: 21 000 0000
<br />
Fax: 21 00 0001
</address>
Para quê? Posso fazer o mesmo com um marcador <div>
Os elementos agrupados com um <div> não têm valor semântico excepto se lhes for atribuída uma identificação ou classe. Então porquê criar uma <div class="contacto"> quando já há um elemento que o pode fazer?
O Joost acaba de me enviar uma mensagem dizendo-me que tenho mais alguns convites disponíveis para quem queira testar este novo sistema de ver TV. Os poucos leitores deste blogue que queiram experimentar podem pedir um nos comentários. Este serviço Joost exige banda larga e um computador que não seja um molenga a contrapartida é poder aceder-se a alguns programas de televisão com boa qualidade. O interface é diferente do de uma televisão. Toma por defeito a totalidade do ecrã mas pode ser posto a correr numa janela. Há versões para Windows e para Mac.
--Completamente fora de tópico.
De momento já não tenho convites para enviar
Para a Anna e outros leitores, de momento não tenho convites. A recusa do vosso comentário é só para evitar poluir excessivamente o blog. Quando e se tiver convites volto a contactar.
Volto hoje, 2006-04-26 a ter 4 convites disponíveis. Agradecia que quem pedisse um convite me fizesse chegar um comentário com: aliteração (alias) nome (nome próprio), apelido (sobrenome), e mail válido agradecia que não o ofuscassem em demasia. Em vez de publicar os comentários passarei a colocar um comentário eu mesmo com a aliteração ou caso não seja enviado com o nome próprio da pessoa que pede. Isto evitará que eu atribua um nome à pessoa. O mail tem que ser válido para a joost poder confirmar a v. inscrição.
Houve dia 27 de Abril quem tenha pedido um convite, só não tenho dados válidos para lho puder enviar.
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...
Mensagens
