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

30 abril, 2007

REST explicado à minha mulher (Tradução)

Ryan Tomayko escreveu um ensaio onde explica de forma clara o que é REST à sua mulher.

http://tomayko.com/articles/2004/12/12/rest-to-my-wife

A minha mulher: quem é Roy Fielding?

Eu: Um tipo. Brilhante.

A minha mulher: O que é que ele fez?

Eu: Ajudou a desenvolver os primeiros servidores de web e de seguida efectuou um número de investigações sobre o porquê do funcionamento da Web. O seu nome aparece no documento técnico que define o protocolo usado para recuperar as páginas de um servidor para o teu navegador.

A minha mulher: Como é que isso funciona?

Eu: A Web?

A minha mulher: Sim.

Eu: Bem, é espantoso. O caso é amusant é que é verdadeiramente subestimado. O protocolo de que falamos chama-se HTTP pode fazer muitas coisas verdadeiramente geniais que um bom número de pessoas ignora por uma ou outra razão.

A minha mulher: Queres dizer que o http como no início de uma linha que escrevo no navegador?

Eu: Sim. Essa primeira parte que diz ao navegador qual o protocolo a utilizar. Aquilo que escrever é um dos mais importantes desenvolvimentos na história da informática.

A minha mulher: Porquê?

Eu: Porque descreve a localização de qualquer coisa não importando aonde no mundo e a partir de que ponto no mundo é pedido. É o princípio fundador da Web. Uma maneira de o imaginar será as coordenadas GPS para o conhecimento e a informação.

A minha mulher: Para as páginas Web?

Eu: Não importa para quê. Verdadeiramente. Este tipo, Roy Fielding, fala disso muito nos seus trabalhos de investigação. A Web foi construída sobre um estilo de arquitectura designado por REST. REST fornece a definição de um recurso, que é aquilo que vemos na ponta.

A minha mulher: Uma página Web é um recurso?

Eu: De algum modo. Uma página Web é a representação de um recurso. Os recursos são justamente conceitos. Os URL essas coisas que escrever no navegador...

A minha mulher: Eu sei o que é um URL...

Eu: Bem. Eles dizem ao navegador que há um conceito nalgum local. Um navegador pode então pedir uma representação particular do conceito. De maneira específica, o navegador pede a representação página Web do conceito.

A minha mulherQuais são os outros tipos de representação disponíveis?

Eu: De facto, as representações são uma das coisas que são raramente usadas. Na maior parte dos casos, um recurso só tem uma única representação. Mas há a esperança que as representações seam utilizadas mais no futuro pois há um número de formatos importantes que estão a aparecer um pouco por todo o lado.

A minha mulher: Como por exemplo?

Eu: Bem, há o conceito que as pessoas designam por "serviços Web". Isto cobre coisas diferentes para pessoas diferentes mas o conceito elementar é que as máquinas poderiam utilizar a Web do mesmo modo que as pessoas o fazem.

A minha mulher: Ainda algo do género do robot?

Eu: Não propriamente. Não penso que as máquinas se sentem a uma mesa e naveguem na Web. Mas os computadores podem usar os mesmos protocolos para enviar mensagens uns aos outros. Fizemos isto há muito tempo mas nenhuma das técnicas que usamos hoje funciona muito bem devido à necessidade de termos que falar a todas as máquinas no mundo inteiro.

A minha mulher: Porquê?

Eu: Porque ainda não são concebidas para funcionarem deste modo. Quando Fielding e os seus colegas começaram a construir a Web, ser capaz de falar com todas as máquinas não importando onde no mundo era uma exigência primeira. A maior parte das técnicas que utlizamos no trabalho para fazer comunicar os computadores entre eles tinham essa exigência. Nós tinhamos só a necessidade de falar com um pequenos grupo de máquinas.

A minha mulher: E agora, temos necessidade de falar com todas as máquinas?

Eu: Sim e mais. Necessitamos de falar com todas as máquinas a propósito de todas as coisas contidas nas outras. Necessitamos de um meio pela qual uma máquina fala com outra a propósito de um recurso que poderá estar eventualmente disponível numa terceira máquina.

A minha mulher: O quê?

Eu: Digamos que falas com a tua irmã e ela te pede emprestada a bicicleta, mas que quem a tem é a vossa mãe. Donde dizes à tua irmã para falar directamente com a tua mãe. Isto sucede actualmente permanentemente na via actual e o mesmo sucede a todo o momento quando as máquinas começam a falar entre elas.

A minha mulher: Como é que as máquinas dizem umas às outras onde se encontram as coisas?

Eu: Através do URL, está claro. Se todas as coisas de que as máquinas tenham necessidade de falar possuirem um URL correspondente, criamos o equivalente máquina de um nome comum. Que tu, eu o resto do mundo tenhamos optado por falar dos nomes do mesmo modo é verdadeiramente importante, não?

A minha mulher: Sim.

Eu: As máquinas não têm nomes universais - é por isso que são nulos. Cada linguagem de programação, cada base de dados, ou um outro sistema têm uma forma diferente de falar de nomes. É por isso que os URL são tão importantes. Tal permite a todos os sistemas trocar com todos os outros a propósito dos seus nomes.

A minha mulher: Mas quando vejo uma página Web não penso desse modo.

Eu: Ninguém. Só Fielding e muito poucas outras pessoas. É por isso que as máquinas hoje continuam a ser nulas.

A minha mulher: e a propósito de verbos, pronomes e adjectivos?

Eu: Tem piada que fales disso, pois trata-se de outro aspecto importante do REST. Em todo o caso os verbos são outro aspecto do REST.

A minha mulher: Só estava a brincar.

Eu: É uma piada interessante, mas de facto não é uma piada. Os verbos são importantes. Existe um conceito poderoso em programação que a teoria de informática designa por polimorfismo. É uma maneira técnica de dizer que os diferentes nomes podem ver-se aplicados ao mesmo verbo.

A minha mulher: Já não brinco.

Eu: Bom... Vê a mesa do café. Quais são os nomes comuns? Chavena, Tabuleiro, Jornal, Controlo remoto. Agora, quais são as coisas que podes fazer com todas estas coisas?

A minha mulher: Já não brinco.

Eu: Posso apanha-las (get) certo. Podes apanhá-las. Podes bater-lhes, Podes queimá-los. Podes aplicar estes verbos exactamente a quaisquer objectos que se encontrem aí.

A minha mulher:Sim e?

Eu: Bem, isso é importante. Se em vez de te poder dizer apanha a chavena, apanha o jornal ou apanha o controlo remoto o que sucederia se tivessemos que usar verbos diferentes com cada um dos nomes? Não podia usar a palavra "apanhar" de modo universal, mas teria que pensar numa nova palavra para cada combinação verbo/nome.

A minha mulher: Oh! É estranho.

Eu: Sim. é. Os nossos cérebros são de algum modo suficientemente inteligentes para saberem que esses mesmos verbos podem ser aplicados a vários nomes diferentes. Alguns verbos são mais específicos que outros e só se aplicam a um conjunto pequeno de nomes. Por exemplo, não posso conduzir uma chavena ou beber um automóvel. Mas alguns verbos são praticamente universais como: apanhar (GET), colocar (PUT) e apagar (DELETE).

A minha mulher: Não podemos APAGAR uma chavena.

Eu: bem realmente. Mas podes atirá-la fora. Isso era outra piada. Certo?

A minha mulher: Sim.

Eu: Enfim, o protocolo HTTP que Fielding e amigos criaram é inteiramente consagrado à aplicação dos verbos sobre nomes comuns. Por exemplo, quando vais a uma página Web o navegador faz um HTTP GET do URL que escreves e de volta obtém uma página Web.

As páginas Web normalmente têm imagens, sim? Elas são recursos separados. A página Web só específica os URL para as imagens e o navegador efectua HTTP GETs suplementares de modo a que todos os recursos sejam obtidos e a página mostrada. Mas a coisa importante é que os nomes comuns de natureza muito diferente podem ser tratados do mesmo modo. Que o nome seja uma imagem, um texto, um vidéo, um mp3, um diaporama, seja o que fort. Posso obtê-los do mesmo modo com um URL.

A minha mulher: Parece que o GET é um verbo muito importante.

Eu: Sim. Particularmente quando usas um navegador Web porque os navigadores não fazer praticamente nada a não ser apanhar (GET) as xoisas. Não fazem grande coisa para além disso, poucos outros tipos de interacção com os recursos. É um problema pois tal incita numerosas pessoas a crer que o HTTP não serve para mais nada a não ser apanhar (GET) coisas. Mas o HTTP verdadeiramente é um protocolo geral para aplicar verbos sobre nomes comuns.

A minha mulher: Bom. Mas não percebo como é que isto altera algo. Que tipo de nomes e verbos queres?

Eu: Bem os nomes estão lá mas não no bom formato.

Por exemplo pensa o que sucede quando navegas num sítio como a fnac.pt para procurares coisas para me comprares pelo Natal. Imagina cada produto como sendo nomes. Agora, se estiverem disponíveis numa representação que a máquina possa compreender, poderias efectuar várias coisas interessantes.

A minha mulher: Porque é que uma máquina não pode compreender uma simples página Web ?

Eu: Porque as página Web foram escritas para serem compreendidas pelas pessoas. Uma máquina não se interesse pela apresentação e estilo. Praticamente, as máquinas só necessitam de dados. Idealmente cada URL teria uma versão legível por humanos e uma representação para máquinas. Quando a máquina apanha um recurso ela pedirá a versão apropriada legível pela máquina. Quando um navegador apanha o recurso para um humando pedirá a representação legível por um humano.

A minha mulher: Então as pessoas terão que reproduzir todas as suas páginas de modo legível pelas máquinas.

Eu: se tal foi útil. Vê, falá-mos disto com numerosas abstracções. Passemos a um exemplo concreto. És professora - na escola aposto que têm um sistema de computador grande ou três ou quatro sistemas, mais provável, que vos deixam gerir os estudantes: em que turmas se encontram, em que níveis estão, contactos de emergência, informação sobre bibliografia, etc. Se os sistemas forem baseados na Web, então é provável que haja um URL para cada um dos nomes aqui envolvidos: estudante, docente, turma, livro, sala, etc. De imediato, obter o URL através do navegador dá-te uma página Web. Se houvesse uma representação legível pela máquina de cada URL, então seria trivial encavalitar novas ferramentas no sistema porque toda a informação seria consumível de um modo padrão. Seria também fácil a cada um dos sistema falar uns com os outros. Ou poderia ser possível construir um sistema que abarcasse todo o país que fosse capaz de falar com cada um dos sistemas escolares individuais para coligir os resultados de um exame. As possibilidades não acabam.

Cada sistema iria obter informação de cada um dos outros usando simples HTTP GET. Se um sistema necessitar de adicionar algo a outro sistema, utilizaria um HTTP POST. Se um sistema quizer actualizar algo noutro sistema usa HTTP POST. A única coisa que falta e perceber como é que os dados devem parecer.

A minha mulher: Então é nisso que tu e toda a gente dos computadores está a trabalhar agora? Decidir como é que os dados devem parecer?

Eu: Infelizmente não. Em vez disso a grande maioria está ocupada a escrever camadas de especificações complexas para fazer isto de um modo diferente que não é nem tão útil nem tão inteligente. Os nomes não são universais e os verbos não são polimórficos. Estamos a deitar para o lixo décadas de utilização real em campo e técnica testadas e a começar tudo de novo com algo que se parece muito com outros sistemas que falharam no passado. Estamos a usar HTTP porque nos ajuda a falar na nossa rede. Estamos a trocar simplicidade com ferramentas espanpanantes.

A minha mulher: Porquê?

Eu: Não tenho a mínima ideia.

A minha mulher: Porque é que não dizes algo?

Eu: pode ser que diga.

O perfeito é inimigo do bom

Paul Buchheit escreveu há tempos que todos já sabemos que o óptimo é inimigo do bom. Ele acrescentou uma voltinha e diz que o bom pode ser uma barreira à criatividade.

Que não nos devemos preocupar em demasia com a nossa falta de talento, capacidades, tempo ou qualquer outro recurso que seja necessário para alcançar o bom (excepto claro em campos críticos como por exemplo a neurocirurgia onde podem acreditar em mim queremos que os médicos sejam óptimos e que a cirurgia decorra nas melhores condições).

Ele advoga que as pessoas comecem por criar um blogue, mesmo que mau (inane nas suas palavras), que se tirem más fotografias, se carreguem para o YouTube vídeos aborrecidos, que se toque má música e se faça arte horrível. Que não nos preocupemos com o bom mas que simplesmente gozemos com a alegria da criação.

O seu sonho é deixarmos o consumo passivo de entretenimento velho e aborrecido. E alegre criação do entretenimento do futuro!

Ele diz que pode suceder que após vencermos a fricção provocada pela qualidade (a que aspiramos) poderá suceder que seja criado algo realmente bom.

Mostra um exemplo do que quer dizer usando como exemplo o blogue do xkcd.

26 abril, 2007

Recomendações TAC 2006

Isto é uma tradução inacabada, faltando por exemplo todas as referências

Recomendações e conclusões

  1. Panorama: Os formatos abertos de comunicação de documentos para administrações públicas
  2. Objectivo: Actualizar as Recomendações TAC de 2004
  3. Progresso Efectuado: O que foi alcançado em termos de normalização
  4. Progresso Efectuado: Actividades nas Administrações Públicas
  5. Recomendações
  1. Panorama: Os formatos abertos de comunicação de documentos para administrações públicas

    As comunicações entre o sector público e os cidadãos e negócios e outras administrações são frequentemente baseadas em documentos. Ser capaz de trocar documentos electronicamente entre parceiros de comunicação independentes é assim de extrema importância para as administrações públicas europeias. Devido ao seu papel social especial na sociedade o sector público deve evitar impor aos seus parceiros de comunicações o uso de produtos específicos, permitindo assim a esses parceiros a liberdade de escolha.

    As administrações públicas também têm a obrigação de manter arquivos para uso futuro, o acesso, à informação contida nos documentos, deve ser assegurado durante longos períodos de tempo.

    Assim, há um entendimento comum entre as administrações públicas na Europa de que a troca e armazenamento de documentos electrónicos deve depender de formatos abertos de documentos. Tais formatos devem ser definidos num processo aberto a todas as partes interessadas e deve estar disponível para todos os actores interessados e competentes para o implementarem sem restrições. Usar tais formatos oferece às administrações públicas, negócios e cidadãos uma gama alargada de produtos capazes de ler, escrever e manipular documentos enquanto se estimula a competição e inovação na área de tratamento de documentos.

    Preferencialmente, estes formatos abertos de troca e armazenamento de documentos devem ser sujeitos a normalização formal via procedimentos de normalização internacionais.

  2. Objectivo: Actualizar as Recomendações TAC de 2004

    O programa IDABC é um programa da Comunidade Europeia cujo objectivo é identificar, auxiliar e promover o desenvolvimento e estabelecimento de serviços de eGov pã-europeus e redes que suportem os Estados Membros e a Comunidade na implementação, nas respectivas áreas de competência, de orientações e actividades da Comunidade, alcançando vantagens substanciais para as administrações públicas, negócios e cidadãos. O programa IDABC é o sucessor dos programas IDA e IDA II.

    Na sua reunião de 25 de Maio de 2004, o comité de gestão do IDA II, composto por representantes dos Estados Membros e aconselhando a Comissão sobre a implementação do programa, apoiou um conjunto de “Conclusões e Recomendações sobre Formatos Abertos de Documentos”, adiante referidos como “Recomendações TAC”.

    As Recomendações TAC aconselham o sector público a evitar impor produtos específicos aos seus parceiros de comunicação e recomenda o uso de formatos abertos de troca de documentos. Para documentos que possam ser revistos os formatos baseados em XML foram recomendados visto permitirem separação de conteúdo, estrutura, semântica e apresentação e visto poderem ser tratados por uma gama alargada de aplicações.

    As Recomendações TAC pediram à indústria que providenciassem aplicações baseadas em formatos abertos de troca de documentos que permitissem que os documentos electrónicos fossem trocados sem restrições entre autoridades e entre autoridades, cidadãos e negócios. Elas deram as boas vindas ao trabalho da OASIS sobre a normalização de formatos de documento Open Office e convidaram a indústria a juntar-se à iniciativa. As Recomendações TAC também apoiaram a submissão do OASIS Open Document Format emergente a uma organização de normalização oficial tal como a ISO. Além disso a TAC pediu à Microsoft para publicar e providenciar um acesso não discriminatório a futuras versões das especificações dos seus documentos Office e para pensar na submissão dessas especificações a um corpo internacional de normalização à sua escolha.

    Finalmente, as recomendações encorajaram o sector público a providenciar a sua informação em vários formatos. Onde por escolha ou circunstâncias só um único formato de documento alterável pudesse ser usada, este deveria ser um formato sobre o qual houvesse consenso na indústria, como demonstrado pela adopção do formato como norma.

  3. Progresso Efectuado: O que foi alcançado em termos de normalização

    Recentes desenvolvimentos estão a encorajar a indústria a levar a cabo grandes esforços para alcançar os requisitos instituídos nas Recomendações TAC (e instituídas por outras organizações do sector público).

    1. Em Maio de 2005 a OASIS adoptou a especificação de documento aberto baseada em XML. A OASIS ofereceu esta especificação para normalização internacional via procedimento “fast track” da ISO em Novembro de 2005. Em 30 de Novembro de 2006 foi publicado o ISO/IEC 26300 “Open Document Format for Office Applications”. Um número crescente de produtos que suporta a norma têm vindo a ficar disponíveis.
    2. A Microsoft adoptou um formato XML “puro” para ser usado no conjunto Office 12 e submeteu a especificação OpenXML ao ECMA em Dezembro de 2005. O trabalho do grupo técnico terminou e a Assembleia Geral Internacional da ECMA aprovou o resultado do seu trabalho. A ECMA irá oferecer a especificação para normalização internacional via procedimento “fast track” da ISO. Esta normalização oferece aos concorrentes da Microsoft a possibilidade de incluírem suporte para o formato OpenXML nos seus produtos.
    3. Tantas as especificações ODF (OASIS) como as OpenXML (ECMA) estão livremente disponíveis na web e os principais contribuintes de ambas as especificações (SUN e Microsoft) asseguraram que as especificações podem ser implementadas pelas partes interessadas, incluindo programadores de open-source sem obrigações e ou custos adicionais.
    4. Tanto as especificações, de formatos de documentos das ODF como das OpenXML, são baseadas em XML, prometendo maiores oportunidades para explorar a informação contida nos documentos via ferramentas que não os tradicionais conjuntos de aplicações de escritório. Exemplos de exploração incluem a indexação de colecções de documentos, extracção de metadados dos documentos, motores de busca, extracção de informação específica para reutilização, etc…
    5. Várias equipas, incluindo uma da Microsoft anunciaram que estão a desenvolver extras open-source para o conjunto Microsoft Office facilitando a interoperabilidade entre os formatos OpenXML e ODF.
    6. Outro desenvolvimento é a adoptçãi pelo ISO/TC171-SC2 (Aplicações de gestão documental – Temas relativos a aplicações) do ISO 19005: “Gestão documental – Formato de ficheiro para documento electrónico para conservação de longo prazo parte 1, Uso de PDF 1.4 (PDF/A1)”. O PDF/A é um formato de documento não alterável que pode ser usado para documentos que não necessitem de processamento ou alteração adicionais. Embora haja muitos produtos capazes de mostrarem produtos PDF/A, só há uns poucos capazes de gerar documentos no formato PDF/A.
  4. Progresso efectuado: Actividades nas Administrações Públicas

    1. Os formatos dos documentos continuam a ser importantes na agenda de orientações do sector público. Seguindo a publicação das Recomendações TAC, os directores gerais responsáveis pela administração pública da EU afirmaram nas suas recomendações de Novembro de 2004 que “Os Directores Gerais em particular dão as boas vindas à iniciativa da Comissão relativamente ao formato aberto de documento e concordam em estimular o uso do formato aberto de documento nos estados membros, uma vez tendo ele sido mais desenvolvido.”
    2. Um relatório de 2005 da Unidade Conjunta de Inspecção das Nações Unidas propôs como princípio que “Todos os Estados Membros e outros parceiros devem ter o direito de acesso público à informação tornado disponível em formato electrónico por organizações e que ninguém deva ser obrigado a adquirir um software determinado de modo a exercer tal direito.”
    3. Vários Estados Membros embeberam o uso de normas de formatos abertos para troca de documentos nas suas estratégias nacionais de tecnologias de informação ou infraestruturas de interoperabilidade.
    4. Algumas organizações deram mais um passo, reagindo ao processo de finalização da normalização da OASIS ao obrigarem ao uso do formato OASISODF. O Concelho de Ministros Belga aprovou um memorando em Junho de 2006 indicando que a partir de Setembro de 2008 todas as trocas documentais entre serviços públicos federais belgas se teria que usar uma norma de formato aberto. ODF – preferencialmente ISO 26300—é até agora a única proposta de norma aceite. O governo da região da Estremadura anunciou a migração de todos os equipamentos de secretária na sua administração para a norma ODF em Agosto de 2006. Na Dinamarca, o parlamento adoptou uma resolução em 2 de Junho de 2006 para uso de normas abertas na qual o “Parlamento pede ao governo para assegurar o uso de tecnologia de informação, incluindo software, no seio das autoridades públicas, baseada em normas abertas com início em 1 Janeiro de 2008 ou quando a tecnologia for adequada”. Um relatório com a interpretação detalhada da resolução do parlamento foi publicada em Agosto de 2006.
    5. A atenção mundial mais alargada foi atraída pela decisão (em Setembro de 2005) da Comunidade de Massachusetts (USA) para tornar o uso da OASIS ODF e PDF obrigatória na sua administração pública.
    6. A existência de normas internacionais irá claramente facilitar a aquisição de produtos que usem formatos abertos de troca e armazenamento de documentos. Alguns Estados Membros já anunciaram as suas intenções de implementar a norma ISO 26300 quando esta se tornar disponível.
  5. Problemas a resolver

    Mesmo tendo em conta estes desenvolvimentos favoráveis a situação mantêm-se preocupante do ponto de vista das administrações públicas Europeias.

    Os peritos dos Estados Membros identificaram os problemas de compatibilidade esperáveis entre produtos baseados na ISO 26300 (ODF) e as aplicações comerciais que dominam os escritórios das administrações hoje como a principal barreira ao uso de formatos abertos de troca e armazenamento de documentos. A chegada potencial de uma segunda norma internacional para documentos que sejam alteráveis conduz a mais complexidade e custo acrescido. Embora filtros, tradutores e extras possam teoricamente permitir a interoperabilidade, a experiência mostra que transformações múltiplas de formatos podem conduzir a problemas em especial onde não haja uma completa correspondência entre características de cada uma das diferentes normas.

  6. Recomendações

    Tendo em conta a presente situação as administrações públicas são convidadas a:

    1. Maximizar o uso de formatos abertos, normalizados internacionalmente, de troca e armazenamento de documentos nas suas comunicações internas e externas.
    2. Usar só formatos que possam ser tratados por uma variedade de produtos, evitando deste modo o uso de produtos específicos aos seus correspondentes. Quando o uso de formatos proprietários for absolutamente inevitável, formatos abertos normalizados internacionalmente devem ser providenciados como alternativa aos formatos proprietários.
    3. Adaptar, onde apropriado, directrizes e regulamentos nacionais, tendo em conta a chegada de normas internacionais nesta área;
    4. Ter em conta a definição de requisitos mínimos em relação a funcionalidades dos formatos abertos de troca de documentos com vista a alcançar a compatibilidade de aplicações;
    5. Criar directrizes para uso de formatos de documentos alteráveis e não alteráveis (com possibilidade de serem ou não revistos) de troca e armazenamento para diferentes finalidades.

    A indústria, consórcios industriais e corpos de normalização internacionais são convidados a:

    1. Trabalhar em conjunto no sentido de criarem uma só norma internacional aceite por todos para respectivamente documentos abertos alteráveis ou não-alteráveis.
    2. Desenvolver aplicações que possam tratar todas as normas internacionais relevantes deixando ao critério dos seus clientes o formato a ser usado “por omissão”;
    3. Evitar invalidar a finalidade dos formatos abertos de troca e armazenamento de documentos ao oferecerem extensões às normas internacionais relevantes como formatos por omissão.
    4. Propor testes de conformidade e desenvolver ferramentas adequadas à salvaguarda da interoperabilidade entre aplicações;
    5. Continuar a melhorar as normas existentes, também tendo em conta as necessidades adicionais tais como a assinatura electrónica de documentos.

25 abril, 2007

Boas práticas - Ligações externas

Uma excelente fonte de informação sobre o uso de UTF-8 e rails pode encontrar-se em Segurar Entradas em UTF-8 em Rails.

No eigenclass encontra-se um artigo sobre tabelas fracas de chaves, versão corrigida pois havia da parte do autor um falha nos pressupostos quanto ao (momento do) funcionamento do almeida (gargabe colector) e dos finalizadores.

Teste com frequência, verifique os seus pressupostos, codifique com cuidado, leia-a os originais! (cópia descarada do eigenclass)

10 abril, 2007

O Futuro da Web - Comparativo

A Digital Web Magazine desta semana apresenta uma comparação entre o HTML5 e o XHTML5 e o XHTML2 e o futuro da rede feita por David Andersson. A principal vantagem do XML de para quando seja detectado um erro na web, na sua opinião e na minha por uma visão pragmática da rede é também o seu calcanhar de Aquiles. Ele lembra que xhtml servido como text/html na prática significa ser interpretado por um navegador como uma sopa de marcação.

O segundo artigo desta semana é uma crítica do livro de Jeremy Keith "Bulletproof Ajax".

A List Apart 235

No número 235 do A List Apart Martin Kliehm fala de Aplicações Web 2.0 Acessíveis com WAI-ARIA.

Para quem não saiba ele explica muito bem as implicações das WAI-ARIA.

As nossas aplicações podem sofrer de problemas de acessibilidade devido às limitações de marcação existentes. Martin ajuda a percebermos as especificações WAI para Aplicações de Internet Ricas e Acessíveis (ARIA) para melhorar a usabilidade.

Wilson Miner apresenta um artigo para o tipógrafo que há em nós.

Código de Conduta a Resposta Burocrática

Hoje de manhã coloquei um comentário sobre o código de conduta inspirado por Tim O'Reilly. Aquilo que penso dele é que se trata de um documento sem qualquer utilidade, feito por quem tem demasiado tempo disponível, um burocrata na minha linguagem.

Recentemente Jeremy Shoemaker (n. t. sapateiro) foi indiciado sobre comentários deixados no seu blogue.

A responsabilidade acerca de um comentário deve ser imputada à primeira pessoa que se possa identificar com a afirmação em causa. Devo acrescentar que o nome indicado aquando do comentário é fácil de falsificar, o endereço de IP registado no momento do gravação do comentário idem, o endereço de correio electrónico idem, pelo que de facto os blogues não têm algo que nos permita assegurar a identidade de quem lá coloca um comentário, pelo que em último caso, a responsabilidade do conteúdo do blogue é do autor do mesmo independentemente da autoria do comentário.

Por esta razão retiro qualquer comentário que considere ofensivo ou completamente fora do tópico ou da entrada ou do próprio blogue.

Há ainda uma outra razão para retirar comentários quando tal me é solicitado pelo autor do comentário. Foi o que fiz em relação a um comentário importante que retirei a pedido do autor dos comentários de um artigo meu sobre semântica que inexplicavelmente continua a ser um dos mais lidos. Omito intencionalmente uma ligação para o artigo pois fico envergonhado sempre que vejo as estatísticas (embora estas fiquem muito bem colocadas na escala da mentira) de acesso (um dos três artigos mais lidos deste blogue).

Já agora, para terminar, ao meu comentário acima houve uma pessoa de quem gosto do blogue que me dizia que a minha observação era demasiado (para ser simpático comigo) simplista. Pois é, os valores têm mesmo que ser algo simples senão uma pessoa não consegue viver com eles, e talvez seja verdade eu ter exagerado na simplicidade.

07 abril, 2007

RFC1 Faz aninhos - 38

Hoje faz aninhos o primeiro RFC 38. Este RFC este na origem da ARPANET que veio a transformar-se na Internet que hoje conhecemos.

04 abril, 2007

Cache no Google Code

O que é que acham desta técnica, colocar em cache no google os ficheiros estáticos que todos temos nos nossos sítios: obrigado Dean Edwards

02 abril, 2007

DRM free

A Apple e a EMI chegaram a acordo para venda de músicas sem DRM (software anti-pirataria). As músicas livres do DRM são mais caras que com DRM.

Agora com um custo de um CD (LP) com 12 músicas o custo de um CD digital será da ordem dos 15,6 Euros e o custo de um CD com caixinha, livrinho, capinha será da ordem dos 15 Euros. Assim a EMI tem um enriquecimento sem justificação.

The Art of Agile Development

O livro em pré-publicação do Jim Shore e Shane Varden The Art of Agile Development é interessante porque reflete a filosofia por detrás do desenvolvimento Agile. Capítulo a capítulo vai sendo apresentado e comentado. Em alguns capítulos tem autores especializados como por exemplo Elisabeth Hendrickson que trata de Testes Exploratórios. A leitura dos comentários é indispensável, neste caso. Os comentários ao livro propriamente dito podem ser encontrados em: tech.groups.yahoo.com/group/art-of-agile/.