Bom, depois de traduzir um artigo, e conhecer a incrível tradução de Machado de Assis para o … português, o assunto de hoje é tradução.

Poderia falar horas sobre isso, mas o foco aqui será apenas na tradução de uma palavra, que os desenvolvedores fazem (ou fizeram, ou ainda farão) confusão. A razão é que em alguns posts que estão por vir essa confusão pode acontecer.

PADRÃO é uma palavra das mais usadas atualmente, na área de informática . A confusão acontece pois duas palavras em inglês têm a mesma tradução pattern e standard, ambas são “padrão”, mas são “padrões” diferentes e por favor não os confunda, pode ser prejudicial a você.

Agora vamos a semantica da confusão. O padrão “standard”, como em “webstandard”, como os padrões da w3c significa uma norma, ou um padrão de qualidade. Como exemplo temos, o padrão de qualidade do inmetro ou as chaves de boca e as respectivas porcas que são construídas obedecendo uma norma ou padrão para que se encaixem. Ou seja padrões “standard” são para ser seguidos.

Por outro lado padrões “patterns” são modelos a serem repetidos ou serem usados como guia. Entre estes estão os “design patterns”, “architectural patterns”, entre outros. Exemplos de “pattern” são o reconhecimento de padrões (ou seja reconhecimento de repetições) ou padrões utilizados por exemplo nos azulejos. Ou seja, padrões patterns são algo que se repetem comumente ou podem ser usados como referência.

E antes que você ache que MVC, REST são padrões como HTML e CSS que devem ser usados (corretamente de preferência), tente descobrir sempre que ler/ouvir sobre um “padrão” se ele é um “standard” ou um “pattern”.

Anúncios

Mais um desafio do site tableless, mas para convites para Porto Alegre. Esse é um pouco mais complicado. Mas vamos lá, o desafio era decifrar essa mensagem. Quando olhei o background pensei que fosse uma mensagem em QR. Depois de um tempo tentando achar uma ferramenta pra decoding de QR para MacOS X, acabei achando essa ferramenta on-line. Mas não era QR.

Próxima tentativa, vejamos o código, lá tem o seguinte comentário.


<!--
Não, a mensagem não está no código fonte, mas já que você se esforçou um pouquinho, fica aqui uma dica:
rffn anb r n zrafntrz, n zrafntrz rfgn rz pbqvtb zbefr
-->

Bom, olhando assim dá pra notar que é um código por transposição, a primeira palavra já indica rffn devia ser “essa”, “isso”, “erro”, “erra”, primeiro chute foi usar ROT13 pra isso o textmate me quebrou o galho. Mas é algo simples de fazer, segue o código em ruby

"rffn anb r n zrafntrz, n zrafntrz rfgn rz pbqvtb zbefr".tr('a-z', 'n-za-m')

O resultado é:

essa nao e a mensagem, a mensagem esta em codigo morse

Agora era tentar decodificar a mensagem da imagem. Aumentando o zoom e consultando a wikipedia. Consultando a tabela e olhando a imagem, temos “Vida longa e próspera”. Mais nerd impossível!

Como início da explicação sobre REST resolvi traduzir o How I Explained REST to My Wife um texto antigo (2004), mas muito explicativo. Ainda empolgado como o Gil Giardelli utilizou várias citações clássicas, aqui vai uma pergunta que está no What do HTTP URIs Identify?.

O que a URL “http://www.vrc.iastate.edu/magritte.gif” representa?
A traição da imagem

  1. Um cachimbo.
  2. Não sei o que é, mas não é um cachimbo.
  3. Uma contradição.
  4. Uma pintura do Magritte
  5. A fotografia de uma pintura do Magritte
  6. Uma representação na forma de 341632 bits de uma foto de uma pintura.
  7. 4, 5 e 6 estão corretas, mas 1 não.

Nesses últimos dias acabei fazendo uma pesquisa informal com desenvolvedores web de vários níveis, desde quem está iniciando, a quem já trabalha a alguns anos com isso. E o resultado foi o que eu infelizmente esperava, nem todos sabem o básico. Estranho? Acho que não. Antes de continuar pense na resposta para a seguinte pergunta “Para que serve no protocolo HTTP os métodos GET e o POST e quais suas diferenças?”.

As respostas foram as mais variadas, algumas muito boas, melhores até do que a explicação que vou dar a seguir, mas a maioria foi focada nas diferenças, essa sim todo mundo sabe. O GET coloca os parâmetros na URL da requisição e o POST coloca os parâmetros no corpo da requisição. Exemplificando, quando você envia por um formulário por GET a URL expõe todos os parâmetros e o POST esconde-os. Ótimo isso é uma das diferença, mas não responde para que serve, pois o GET não serve para passar parâmetros e o POST pra escondê-los. Dos que se arriscaram a dizer para o que servia o POST a maioria respondeu assim: é para tratar submissões de formulários. Nada errado com a reposta, mas não é apenas isso.

Segundo a rfc do HTTP o GET serve para recuperar conteúdo, e o POST para enviar dados a serem processados. Mas não é isso que os formulários fazem? Sim, é. Mas o ponto é que muitos desenvolvedores acabam além de processar os dados exibindo conteúdo na requisição POST. Ou seja utilizando o POST para uma coisa que ele não foi feito para ser usado, a mesma coisa é passar os parâmetros a serem processados por GET. Mas, o que tem de ruim nisso?

Bom, usar uma ferramenta errada para o problema certo é algo certamente ruim. Mas desenvolvedores insistem no lema “Se tudo que você tem é um martelo, trate tudo como se fosse prego”, e acabam martelando muitos parafusos, mesmo tendo uma chave de fenda também. Que é claro, esses mesmo desenvolvedores não vêem que tem. Mas voltando a prática, o problema de exibir informações depois de um POST é que o browser guarda a última requisição para caso você queira fazer um refresh da página. Ou seja mesmo que não tenhamos um formulário na página, o usuário pode acabar reenviando os mesmos dados novamente apenas apertando F5 (ou ⌘+R), e isso logicamente é ruim. Usar GET para passar dados é mais sutil, pois a intenção do GET é ser uma requisição que não tenha efeitos colaterais, ou seja não mudem o estado de uma aplicação. Mas, o que eu ganho com isso? Bom, tem a ver com o fato de o HTTP ser um protocolo sem estado. Mas também tem a ver com a capacidade de você paralelizar sua aplicação, ou seja, rodar eficientemente em vários servidores. Mas para explicar isso é preciso saber o porquê de as linguagens puramente funcionais serem trivialmente paralelizáveis (vou explicar isso em um post futuro, mas se tem curiosidade, procure saber sobre isso, é algo que com toda certeza vale a pena aprender).

E como eu critiquei aqui por fazerem confusão com REST, que tem tudo a ver com métodos HTTP, os próximos posts vão ser sobre isso, afim de explicar este padrão arquitetural. Que não é tão complicado, é só pensar na razão de URL significar “Uniform Resource Locator”, ou seja “Localizador uniforme de recursos”.

A última palestra, foi sobre marketing, que não é a minha praia, mas achei interessante. Pelo menos conheci o trabalho da AG2, e vi que existe gente pensando na web realmente como uma nova mídia, que necessita de novas técnicas, métodos, etc.

Como não podia deixar de ser, essa foi uma palestra muito boa (alguém já viu alguma palestra de marketeiros serem ruins?). Mas o melhor de tudo é que não valeu só pela palestra, mas sim pelas novas idéias para o marketing on-line e pela percepção da diferença entre o mundo web e o mundo real.

Apesar de fugir um pouco do título da palestra, tenho que admitir, essa palestra foi algo que eu não esperava. O Gil Giardelli começou a falar, e no começo achei que ia ser uma maluquice só, pois ele citou Satre, David Lynch e vários outros filósofos e artistas menos conhecidos. Mas me enganei, ele conseguiu no meio de toda a loucura de suas referências (leia um livro do Satre ou assista um filme do Lynch pra você entender) mostrar que o Brasil, infelizmente, tirando alguns poucos sites/serviços ficou pra trás na web 2.0. Lógico, não no aspecto tecnológico, com interfaces ricas, AJAX, etc. Mas na questão das idéias, ou será que temos no Brasil sites/sistemas que exploram a folksonomia? Ou o forte senso de comunidade on-line para fins mais interessantes? Existe alguém explorando a colabaração humana aqui no Brasil?

A resposta é, sim existem, mas apenas poucos. Muito pouco, e temos todo o potencial para fazermos bonito na web 2.0, existe povo mais colaborativo do que o brasileiro? A criatividade então nem se fala …

Algumas coisas que foram ditas na palestras estão meio fora da realidade brasileira, mas em questão de idéias, deu pra ver que estamos muito atrás ainda. Mas temos todo o potencial para fazermos uma verdadeira revolução.

Se eu fosse falar da paletra inteira ficaria um post muito grande, porém podem ter certeza que esta palestra ainda vai render alguns posts futuros aqui no blog.

Ao contrário da palestra da Microsoft que fugiu completamente do padrão de apresentação da empresa, a palestra do Google foi, como sempre, uma palestra do Google. Desde a estrutura da palestra, passando pela apresentação da empresa, o fato da missão ser citada ao longo de toda a palestra, etc. Mas uma das coisas que eu mais admiro neles, é o fato de se manterem coerentes com sua missão, e mais, eles agregam valor a marca. O Google sabe usar a seu favor algo que muitos dos que trabalham com informática não dão o devido valor. Eles valorizam o trabalho de outras áreas. Existem várias razões para eu citar isso, mas uma foi que na apresentação, eles manteram a identidade visual da marca. Ou seja quando você assistia a apresentação, mas do que o logo indicando que era uma apresentação do Google, você via as mesmas características visual dos serviços, o tom de azul era o mesmo, o fio cinza para destacar, as mesmas fontes, o mesmo tom de laranja, o uso do cinza ao invés do preto e provavelmente mais outras coisas que não notei, pois não é a minha área. Mas qualquer um notou que aquela palestra era do Google, esse era o objetivo, algo que nesse encontro apenas a AG2 também se preocupou (afinal esse é um dos trabalhos deles).

A palestra em si, foi sobre os serviços, como funcionam, para mim nada de novidade, só para não deixar de citar o assunto da vez do encontro, também falaram de Cloud Computing (mais sobre o que o Google faz com isso do que sobre a idéia em si). No fim, foi como eu esperava, foi uma típica apresentação do Google.