Mais um desafio do tableless

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!

Tradução do “How I Explained REST to My Wife”

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?

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.

O quanto você sabe sobre desenvolvimento Web?

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