Mudança

9 outubro, 2009

O blog mudou para Distópico

Voltando a escrever

10 junho, 2008

Após um tempo sem escrever, algumas palavras:

  • Fiquei apenas com o notebook por enquanto, o desktop parece que queimou a fonte … O que me rendeu inúmeros problemas.
  • No momento estou trabalhando num projeto, então meu tempo para escrever diminuiu.
  • Fim de semestre pra quem estuda é sempre complicado, e comigo não é diferente.
  • Estou brigando feio com a AST de Lua para adaptar nos moldes do DLTK
  • Já que eu fiz o comentário, quem puder dê uma olhada no projeto LuaEclipse é uma IDE para Lua uma linguagem brasileira, que não deve nada para as linguagens atuais, só pra ter uma idéia ela é usada no World of Warcraft e também pela Adobe … Pronto, já fiz minha propaganda.

Mas as boas novas. O que vem por aí?

  • Vou continuar a série de explicações sobre REST, e colocarei um exemplo prático.
  • Ainda sobre REST, alguns tutoriais de Ruby on Rails, que é o framework que eu conheço que tem melhor suporte a REST.
  • Estou trabalhando num projeto de tradução de livros, é bem interessante, estou precisando de ajuda, mais detalhes em breve.
  • Consegui uma conta para teste da nova hospedagem de Ruby on Rails da Locaweb então como eu critiquei a hospedagem anterior, logo eu publicarei o que eu achei para ser justo.

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”.

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.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.