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

13 junho, 2006

Uma carta aberta ao governo português

Que efeito teria uma carta aberto sobre ensino de desenvolvimento para a web se fosse enviada ao governo português (julgo que o efeito seria nulo mas qual é a opinião dos leitores?) semelhante à enviada pelos suecos?

Carta aberta ao governo sueco sobre ensino de desenvolvimento para a web

Desenvolvimento Web 2006

Sumário

A educação em ”Media Interactivos”, ”Programação Internet” e ”Tecnologia da Informação” têm que dar aos estudantes a capacidade de desenvolverem para a web actualmente e no futuro. Há um risco de a educação continuar a ensinar, tal como o faz em grande parte hoje, métodos desactualizados e tecnicamente inferiores.

O progresso na web não parou e estamos a observar dois desenvolvimentos importantes:

1.A camada de apresentação está a mudar para uma baseada sobre standards, semântica e separação de conteúdo, de design e comportamento. Isto oferece uma possibilidade à acessibilidade, de forma a nenhum utilizador ser excluído, independentemente do seu sistema operativo, navegador ou tipo de hardware, ou se o utilizador tiver qualquer tipo de deficiência funcional. Quando este passo for dado é possível continuar e criar interfaces de utilizador ricas.

2.A dinâmica dos sítios está a mudar. A partir de como se fossem ilhas isoladas, com pontes entre elas, até fazerem trocas de dados directamente entre servidores e uma nova dimensão para interacção social para utilizadores.

O ensino secundário (similar à senior high school) não será capaz de tornar os seus estudantes em responsáveis pelo desenvolvimento da web completamente capazes, com uma compreensão olística dos padrões e princípios de acessibilidade e serem capazes de programar os servidores para trabalharem com as novas formas de troca de dados. Mas é da maior importância que a educação ofereça uma fundação, sobre a qual os estudantes não necessitem de ser destreinados e necessitem de se reeducar a sim mesmos, por lhes terem sido ensinados os métodos errados. A escola deve ser uma rampa de lançamento para as autoestradas do futuro, não um beco sem saída para o passado.

Não dizemos que os standards e a acessibilidade é a única coisa que necessitam saber, quando constroem um sítio moderno, mas dizemos que não há outra opção válida para construir sítios web, quando falamos destes aspectos. Não deve colocar-se a questão entre escolher design ou standards, sobre efeito curiosos ou acessibilidade. Usar a metodologia que sugerimos estas questões não se irão tornar umas a oposição das outras.

Esta carta descreve a opinião da «The Web Standards Project Educational Task Force» e um grupo de responsáveis suecos pelo desenvolvimento da web que desejam ver uma web não discriminatória e acessível.

CONTEÚDOS

Desenvolvimento Web 2006.

Sumário

Introdução

”Web 2.0”

Web 1.0 – a web como parque fechado

Web 1.5 – Sistemas de Gestão de Conteúdos(Content Management Systems)

Web 2.0 – a web como selva

Troca de informação “por baixo da superfície”

Os utilizadores são jardineiros

Mashups

Standards: Fim da LEI da selva

Standards, desenvolvimento não específico de um navegador

Separação de conteúdo, design e comportamento

Código semântico

AJAX e interfaces de utilizador ricos

A web em 24 horas

Lista de consequências

Assinada por:

Introdução

Chegou o momento de explicar e implementar as visões dos curricula, mas antes de passarmos a uma descrição detalhada do que é que a escola deve ensinar, necessitamos de ter um conhecimento acerca dos actuais desenvolvimentos e do futuro. Este documento irá tentar oferecer um inquérito sobre algumas das principais tendências que envolvem o desenvolvimento web na actualidade.

Não dizemos que o ensino secundário (senior high school) deva ensinar todas as tecnologias que serão mencionadas nesta carta. Algumas delas são demasiado avançadas para este nível de ensino. Queremos contudo dizer, que os fundamentos devem ser ensinados, de tal modo a serem realmente uma fundação adequada para os níveis seguintes.

Um certo número de pessoas será mencionado neste documento com o seu nome. São nomeados como sendo peritos e exemplos. Um bom desenvolvimento web é feito com o espírito que estas pessoas representam. Isto não implica que cada uma das pessoas mencionadas seja infalível ou mesmo a “melhor” no seu campo. Foram aqui nomeadas porque são relativamente bem conhecidas e de certo modo tornaram-se a face humana de certas ideias.

”Web 2.0”

Poderia pensar-se que surgiu uma nova tecnologia com todo o bruaá sobre a “Web 2.0” durante 2005. A verdade é que não houve nenhuma alteração drástica de tecnologia quando se observa o conteúdo e as especificações da tecnologia. Continuamos a utilizar o HTML 4, que foi definido em 1997-1999, ou o XHTML 1.0, definido em 2000. Acrescentámos o CSS 2.1, que é um subconjunto do CSS 2.0>, i.e. uma simplificação, e as CSS 2.0 já estavam definidas em 1998. O terceiro componente fundacional numa página web é a JavaScript. A última parte da JavaScript, que recentemente atraiu atenção (XMLHttpRequest) foi desenvolvida pela Microsoft em 1998 e as especificações DOM 1.0 já foram também definidas em 1998.

Contudo a web de 2006 é radicalmente diferente da de 2000. Um novo modo de usar estas técnicas viu a luz do dia e a diferença é enorme. Quem não tenha seguido o desenvolvimento foi deixado para trás. É da maior importância que o ensino reflicta esta alteração de paradigma e não ensine métodos obsoletos.

As alterações não são só técnicas, mas envolvem a web como um todo e como é que interagimos com ela como utilizadores.

Web 1.0 – a web como parque fechado

[[A ligação só se encontra na camada de apresentação. Poucas entradas, talvez só uma entrada.]]

[[O jardineiro – o webmaster. Três papeis principais: Técnico, design, conteúdo e Especialização. DMOZ é um exemplo de um pequeno número de voluntários que oferecem conteúdo, mas em que o utilizador regular só vê (a ser comparado com del.icio.us). Mesmo as comunidades operam dentro de “uma cerca”.]]

Web 1.5 – Sistemas de Gestão de Conteúdos/Content Management Systems

[[Os fornecedores de conteúdos necessitam de ferramentas para sítios grandes sítios orientados por bases de dados. Desde os finais dos anos 90 os sítios estáticos estão mais ou menos mortos. Há um CMS por detrás dos principais sítios web. As organizações pagam por um CMS.]]

[[Mesmo os novatos necessitam de conhecer que não falta muito até que a página estática seja incorporada num CMS. Os designers desenvolvem modelos, não páginas. O designer puro não toca sequer em código, mas desenha no papel ou no photoshop e deixa alguém implementar o design.]]

[[A metáfora do jardim fechado ainda se mantém. Comunidades isoladas na web.]]

[[Os CMSs causam um problema importante, pois produzem frequentemente marcação não standard, inválida e não semântica. Tais CMSs não devem ser colocados em primeiro lugar como algo que os estudantes devam simular.]]

Web 2.0 – a web como selva

[[Qualquer página é uma página de entrada. Não há só uma porta de entrada no jardim. Mas a grande revolução é que as ligações nos sítios se encontram na camada da lógica de negócio. As raízes e ramos são misturados livremente com aquelas que pertencem a outras plantas.]]

Troca de informação “por baixo da superfície”

[[Onde começa uma liana na floresta é pouco importante normalmente. Crescem entre várias árvores. Os sítios da web da actualidade podem mostrar informação que é guardada noutro local. Assinatura, agregação, serviços web, blog ping, etc levam a que os sítios estejam ligados de outro modo. Estes sítios não só se ligam a outros, mas partilham informação uns com os outros.]]

Os utilizadores são jardineiros

[[Os utilizadores estão a tornar-se na principal fonte de informação. A Amazon.com lidera ao deixar aos leitores a oferta de críticas, pistas e listas de desejos e padrões de utilização (”Clientes que compraram este livro também compraram…”).]]

[Há uma maior dinâmica ao ter um  blogue do que ser membro de uma comunidade. A palavra “blogosfera” poderá nem sempre transmitir as conotações correctas mas é uma tentativa de atribuição de um nome a esta nova dinâmica. A web como comunidade.]]

[[Wikipedia é outro exemplo.]]

[[Novas regras – a ”long tail”. Mais poderes aos utilizadores. Novos padrões económicos.]]

Mashups

[[Nem todas as plantas na selva têm raízes no chão. Uma planta pode crescer a partir de outra. Um “mashup (sítio ou aplicação web que combina informação de mais do que uma origem)” é um sítio que usa uma API de outro sítio, com o seu consentimento, para fornecer um serviço em cima do outro. Isto encoraja sítios como Google, Amazon, Yahoo, etc.]]

Standards: Fim da LEI da selva

O novo tipo de troca de informação, mashups, etc. é o resultado do facto de num outro sentido a web se ter tornado menos selva. O intercâmbio exige standards cuidadosamente definidos. Mesmo as grandes organizações têm que seguir cuidadosamente os standards existentes e a maior parte das tentativas de utilização de técnicas proprietárias é punido pelas pessoas com verdadeiro poder - o colectivo dos responsáveis pelo desenvolvimento da web.

No ano de 2003 Jeffrey Zeldman publicou o livro ”Designing with Web Standards” e no mesmo ano Dave Shea lançou o sítio CSS Zen Garden e desde essa altura os responsáveis pelo desenvolvimento da web competentes ficaram conscientes que os sítios web  modernos são desenvolvidos de acordo com uma filosofia clara, que ao lado dos standards também incluem separação de design, conteúdos, comportamento e código semântico.

O inventor da web, Timothy Berners-Lee, é claro a pessoa mais importante em todo este progresso. O modo como ele previa a web originalmente significava o que estamos a ver agora é o retorno ao que ele achava que devia ser, antes de ter em grande medida sido destruída por pessoas bloqueadas na perspectiva da edição de secretária.

Standards, desenvolvimento não específico de um navegador

No final dos anos 90 sucedeu aquilo que foi designado por “guerra dos navegadores”. A Netscape e a Microsoft guerrearam-se pelos responsáveis de desenvolvimento criando tecnologias proprietárias e esperando que as páginas de entrada não trabalhassem com os navegadores concorrentes. “Este site está optimizado para” e instruções similares eram frequentes. A Microsoft ganhou a guerra dos navegadores, oferecendo um melhor suporte que o da Netscape aos standards definidos pelo World Wide Web Consortium (W3C) para HTML, XHTML, CSS e DOM.

Quando a Netscape lançou o Mozilla Project e os responsáveis pelo desenvolvimento se tornaram poder em vez das pessoas do marketing, foi tomada uma decisão inicial sobre parar o suporte a tecnologias proprietárias da Netscape e em seu lugar seguir meticulosamente os standards da web.

O resultado é que todos os navegadores modernos (gen 6+) seguem pelo menos de forma decente os standards. Houve pouco desenvolvimento no Internet Explorer desde 2001, mas no momento a melhoria do suporte dos stantards está a ocorrer e é um dos temas chave. A versão Internet Explorer 6 é suficientemente boa para nos capacitar ao desenvolvimento baseado nos standards.

O tempo em que se desenvolvia para determinado navegador, ou a dificuldade de desenvolvimento para um certo número de navegadores passou. Algumas companhias suecas de desenvolvimento ainda não compreenderam que estão em risco de serem deixadas para trás à medida que cada vez mais clientes perceberem que podem ter melhores sítios web por menos dinheiro com este novo modo de fazer sítios web.

Separação de conteúdo, design e comportamento

O desenvolvimento baseado nos standards frequentemente é acompanhado da consciência de que as páginas de entrada de ontem eram feitas com mau código. Normalmente designado por “sopa de marcação”. HTML ou XHTML não devem ser de todo usadas para controlar o aspecto visual de uma página. Os marcadores ou atributos que só servem uma finalidade visual, designados por “marcação física” (um termo normalmente usado na Suécia) não devem ser usados de todo. Estes marcadores e atributos incluem < font> , < center> , bgcolor, align, etc.

separaçãoentre conteúdo, descrito por (X)HTML e design, controlado por CSS, é o primeiro passo. Ganha-se as seguintes vantagens:

  • Desenvolvimento mais rápido.
  • Redesigns extremamente mais rápidos.
  • Mais possibilidades de arranjo.
  • Fácil adaptação a plataformas de media alternativas (TV, telemóveis, impressão, Braille, síntese de voz, etc.)
  • Melhor classificação nos motores de busca, em especial quando combinada com codificação semântica (ver abaixo).
  • Quantidade de dados reduzida necessária ao envio de página devido à tamponização dos ficheiros externos com CSS e JavaScript efectuada pelos navegadores visitantes.

Na página podem figurar coisas como menus descendentes, controles com valores num formulário, etc. A estes chamamos comportamento. JavaScript, pelo que de facto é uma combinação de ECMAScript e DOM 18, é o meio pelo qual se deve controlar tal comportamento em primeiro lugar. Esta foi também uma área abusada. O JavaScript foi usado para entregar conteúdo e controlar design, sem nenhuma segurança, em especial ao usar JavaScript para adaptar páginas aos diferentes navegadores. O código descuidado ainda ficou mais descuidado! O JavaScript é talvez a tecnologia mais abusada e mais mal compreendida de todas na web.

O ano de 2005 significou uma alteração drástica contudo. Livros como ”DHTML Utopia” 20 e ”DOM Scripting” 21 significaram uma alteração do paradigma e um número elevado de responsáveis de desenvolvimento começaram a usar esta tecnologia de modo correcto.

Código semântico

Durante a era da sopa de marcadores, houve também frequente abuso de marcadores HTML-tags. O marcador < p> , que deve ser usado para denotar um parágrafo foi usado para arranjar espaço. O marcador < blockquote> , que deve denotar uma citação extensa, foi usado para gerir recortes. E a tecnologia mais abusada de todas, as tabelas, foram usadas com finalidade de gerir arranjos e não para dados tabulares. Quase todos os livros ou páginas Web suecas que ensinavam web design ensinavam estes métodos abusivos.

O sítio Webdesignskolan (“Web Design School”) reclam a ser visitado por milhares de estudantes do ensino secundário todos os anos. Chegou à conclusão de que ensinava métodos desactualizados e colocou um aviso pequeno no seu próprio material!

Ao só usar marcadores com significado semântico e usando-os de forma correcta, são ganhas algumas vantagens. O código torna-se mais compreensível, e portanto mais fácil de desenvolver e alterar. As páginas poderão interagir mais. A sua acessibilidade aumenta drasticamente. Páginas codificadas de forma semântica podem ser compreendidas pelas pessoas que escutam os sintetizadores de voz ou que leiam em terminais Braille. É mais fácil fazer adaptações para pessoas com outras formas de deficiência. O robot de pesquisa do Google, assim como a maior parte dos motores de busca, é um utilizador “cego”significando que uma página semanticamente codificada será indexada correctamente e provavelmente classificada mais alto se o seu código for semântico.

A semântica cria novas possibilidades. Responsáveis visionários de desenvolvimento começaram a usar microformats. Concebidos sobre o surgimento dos standards e código semântico. Isto é há padrões para usar dados de calendário (hCalendar) e informação de contacto pessoal (hCard). Outra área a aparecer é a dos “padrões web”, tornando possível reutilizar as melhores soluções para criar a estrutura de páginas web.

Os responsáveis pelo desenvolvimento que continuarem a usar marcação não semântica serão ultrapassados e deixados para trás!

AJAX e interfaces de utilizador ricos

Em Fevereiro de 2005 Jesse James Garret cunhou o termo AJAX, ao tentar explicar a nova implementação de JavaScript em sítios como Google Suggest, Google Maps, Flickr31 e Basecamphq. O termo ganhou popularidade de tal modo que algumas pessoas julgam tratar-se de um sinónimo de “web 2.0”. Não é o caso, mas o AJAX é uma peça importante na nova era.

AJAX é de facto um termo de marketing (tal como o DHTML), e não uma tecnologia. AJAX é o desenvolvimento de um novo tipo de interface do utilizador usando tecnologias existentes. A web está a ser transformada num Run Time Environment (ambiente de execução/sistema operativo). O entusiasmo é em parte perigoso. A era DHTML dos anos 90 era um passo além da visão da web. Soluções para só alguns navegadores que eram inacessíveis para utilizadores com deficiências de visão, audição, movimento ou cognitivas, estão em risco de reaparecer em aplicações AJAX desenvolvidas por pessoas cujas mentes não foram “purgadas” dos pecados da era DHTML.

Um grupo de responsáveis pelo desenvolvimento estão nas barricadas {{esta frase faz sentido em português?}}, tentando promover uma atitude responsável a este novo método. É importante que a sua filosofia ganhe, para não voltamos a cair no pesadelo das soluções proprietárias e inacessíveis que pelo menos estamos a começar a emergir.

Contudo, há algumas aplicações para o ambiente web, que pela riqueza das suas interfaces substituem aplicações de secretária existentes. A programação nos anos 80 significava que se programava para o hardware, nos anos 90 houve uma mudança de codificação para APIs do sistema operativo. No futuro próximo poderemos ver  “programas” de secretária de hoje serem substituídos ou pelo menos complementados por sítios web que deixamos de poder descrever como “páginas” mas como aplicações completas.

A web em 24 horas

O governo sueco cunhou a expressão “a web em 24 horas”. “O guia para a web em 24 horas” contém os princípios orientadores de todos os sítios públicos na Suécia, e estão lentamente a ter um efeito. Um blogue muito bom (em sueco) segue este desenvolvimento “The 24-hour blog”.

Estes princípios orientadores estão de acordo com o que figura neste documento. Como consequência da sua adopção os responsáveis pelo desenvolvimento que não aderirem a estes princípios não vão obter novos contratos (tal como deve ser!). Em Dezembro de 2005 o governo sueco anunciou legislação que irá surgir em breve que exigirá um mínimo de acessibilidade nos sítios web públicos suecos.

Isto deve implicar consequências, também no ensino de tecnologias relativas à web no ensino secundário.


Lista de consequências

Qual o melhor modo de fazer algo, i.e. “melhores práticas”? O que deve ser evitado?

”Campeões da causa”: Jeffrey Zeldman, Dan Cederholm e The Web standards Project.

Melhor material disponível em sueco: Desenvolvimento com Web Standards por Roger Johansson.

“Pioneiro”: Jeffrey Zeldman.

Imagem útil: “O banco de três pernas.”

“Pioneiro”: Eric Meyer.

Standards relevantes: CSS 2.1 e CSS 3.

Melhor material em sueco: ”Aprenda você mesmo CSS” por Russ Weakley.

“Pioneiro”: Tantek Çelik.

Standards relevantes: HTML 4.01, XHTML 1.0, XHTML 1.1, XHTML 2.0 (em desenvolvimento) e HTML 5 (cooperação entre Mozilla, Opera, etc.)

Não há material adequado em sueco!

“Pioneiro”: Joe Clark.

Standards relevantes: WAI e WCAG. WCAG 2.0 deve ser considerado para Gy -07.

Melhor material em sueco: ”Tillgängliga webbplatser i praktiken” (Sítios web acessíveis na vida real).

(Controverso) “Pioneiro” Jacob Nielsen.

Melhor material em sueco: ”Användbarhetsboken” (O Livro da Usabilidade) por Tommy Sundström.

“Pioneiros”: Jeremy Keith, Simon Willison, Peter-Paul Koch (PPK), Scott Andrew LePera, James Edwards (“Brothercake”)

Palavras chave:

  • W3C DOM
  • ECMAScript
  • ”Não obstrutivo” (Separação de comportamento do Conteúdo e do Design)
  • ”Degradação aceitável” (Tolerância a falhas, acessibilidade)
  • ”Melhoria progressiva”
  • ”Detecção de objecto” (não “detecção de navegador”)

Não há bom material em sueco. Os livros seguintes em inglês são normativos:

  • JavaScript: The Definitive Guide por David Flanagan.
  • DOM Scripting por Jeremy Keith.
  • The JavaScript Anthology por James Edwards and Cameron Adams.

Assinada por:

The Web Standards Project Educational Task Force, através de Lars Gunther. (Lars Gunther é professor na Nils Ericsonsgymnasiet em Trollhättan, Suécia, e tem uma pequena companhia chamada Keryx.)

The Web Standards Project nasceu com Jeffrey Zeldman e outros e é liderado por Molly Holzschlag, autora de vários livros sobre HTML e CSS.

WASP-EduTT é liderado por April Siegfried que ensina desenvolvimento web baseado em standards na DePaul University, Chicago.

Tommy Olsson bloga sobre web standards e accessibility no actualmente dormente autisticcuckoo.net e é um guro de (X)HTML activo nos foruns SitePoint.

Roger Johansson possui o blogue internacionalmente famoso 456bereastreet.com , sobre desenvolvimento web com enfâse em standards, acessibilidade e usabilidade.

Robert Nyman trabalha como web developer há já alguns anos e escreve regularmente sobre o assunto em robertnyman.com . Além disso organiza reuniões entre responsáveis de desenvolvimento para web para partilha de conhecimentos e melhoria da compreenção.

Peter Krantz bloga em standards-schmandards.com e é um dos responsáveis pelo desenvolvimento do simulador de síntese de voz Fangs.

Martin Janner tem trabalhado com desenvolvimento baseado em standards entre outros na  Eniro e tem o blogue em http://stilmall.se

Björn Hagström é uma das forças nos bastidores do 24timmarsbloggen.se e é responsável pelos sítios da web da cidade de Örebro.

09 junho, 2006

Usar update_page em link_to_function

Introdução

Bruce Williams diz que vive numa terra de modelos e ajudantes de Rails. Para nos dar uma ideia de que está a falar a sério diz-nos o seguinte. Que a sua actual aplicação tem serca de 670 ficheiros de modelos separados (com cerca de 8500 linhas) e 75 ajudantes (com cerca de 2350 linhas) e que continua a crescer.

O que é que isto significa - para além do facto de o TextMate ser o nosso melhor amigo? Significa que se há alguma coisa que ele saiba sobre Rails é como gerir um grande volume de modelos e de código relacionado com vistas e construção de infraestruturas para ajudar a SECAR (DRY - não te repitas) o caos.

Ele diz-nos que irá tentar ajudar outros programadores, responsáveis pelo desenvolvimento de sítios na web que estejam no mesmo barco escrevendo uma série de artigos debaixo do título genérico Rails Views. Estes artigos irão realçar técnicas usadas por si no dia-a-dia. Poderá ser que as achemos úteis, e acrescenta que podem não ser a única forma de obter o mesmo resultado mas que é o processo por si usado.

Diz-nos ainda que esta série de artigos Rails Views partem do princípio que o leitor sabe Ruby bem, e dessa forma ele não irá tratar de se focar na explicação dos detalhes pois espera que um programador decente em Ruby os possa perceber. Irá partir do princípio que o leitor usa Edge Rails.

Utilização de update_page na link_to_function

Uma das técnicas que menos vejo usada nas aplicações em Rails e uma das que acho não só elegante mas que poupa tempo é o uso de update_page directamente na link_to_function .

Porque é que não há mais gente a usar esta técnica? Não percebo. Muito do trabalho foi para RJS... e assim porque não usá-lo?

Eis um exemplo rápido, de duas formas. Tornemos todos os parágrafos de texto, verdes, na página usando a classe CSS irish , só porque sim - finja que é dia de S. Patrício por uns instantes. De facto enfiemos rapidamente um anúncio de "Dia de São Patrício" também.

Em primeiro lugar a versão tradicional (mesmo que melhorada com o prototype) link_to_function .

link_to_function("Toca-me!", "$('p').each( function(tag) {tag.addClassName('irish');} ); new Effect.SlideDown('banner',{duration:0.4});" ) e, com update_page : link_to_function("Toca-me!", update_page{|page| page.select('p').each{|p| p.addClassName('irish')} page[:banner].visual_effect :slide_down, :duration =&gt; 0.4})

São aproximadamente do mesmo tamanho... qual é a espiga?

  • A Ruby é mais poderosa e mais fácil de ler do que JavaScript tenha em mente que este é um exemplo muito simples
  • Uma vez tendo começado a interpolar dinamicamente ids de diferentes elementos, numa string em javascript (claro está usando escape_javascript ), a versão sem update_page torna-se mais difícil de fazer e de manter (deixe só passar o almoço e volte ao seu código e veja)
  • É mais fácil expandir esta técnica usando outros ajudantes e infraestruturas (passando page para adicionar código comum por exemplo) e depois passar strings para serem concatenadas - correndo o risco de um erro sintático no javascript neste processo (alguém poderá dizer "falta de ponto-e-vírgula?").

Este técnica é pequena e simplesmente a minha preferida.

Entender o que são e para que servem os símbolos da Ruby

Quando uma pessoa está a aprender a utilizar uma infraestrutura como a Ruby On Rails e por essa razão tem que aprender Ruby é importante Entender a utilização dos símbolos na Ruby visto serem algo inerente à própria linguagem de programação.

08 junho, 2006

Levels of Accessibility Knowledge – Le «blog personnel» de Joe Clark

Que o Joe Clark não gosta da nova proposta de directrizes WCAG 2.0 já todos o sabíamos mas que achava que os «especialistas» do grupo de trabalho estm no nível 2 é mauzinho.

Níveis de conhecimento

Nas últimas semanas têm aparecido uma série de especialistas das várias disciplinhas da web que criam escalas sobre os conhecimentos devidos para execução de uma tarefa na web.

Emil Stenström apresenta os 7 níveis de conhecimento sobre CSS, Roger Johansson apresenta os 7 níveis de conhecimento em HTML , Dean Edwards documenta seis níveis de conhecimentos em JavaScript e por fim (pelo menos por agora) Joe Clark apresenta os oito Níveis de conhecimento em Acessibilidade .

Um Guia de Introdução à Ruby - de Eustáquio Rangel

O Eustáquio Rangel acaba de actualizar (com correções) o seu Tutorial de Ruby. Este guia encontra-se escrito em português do Brazil pelo que é necessário algum cuidado na sua interpretação. O tutorial do toq (Eustáquio Rangel) é um ficheiro em formato PDF