Infelizmente nada disso é novo, logo lembrei do relato do físico, ganhador do prêmio Nobel em 1965, Richard Feynman no seu livro “O senhor está brincando, Sr. Feynman?: As estranhas aventuras de um físico“. O trecho em questão (que vale a pena ser lido) pode ser encontrado aqui. O relato do texto data da década de 50, porém ainda retrata a atual maneira como se ensina/aprende ciência no Brasil.

Infelizmente não somos ensinados para entendermos e utilizarmos a ciência, e sim para usá-la no papel, de preferência em provas que “medem” o seu conhecimento, e para tanto devem ser as mais difíceis possíveis. Um reflexo disso, é que temos “cursos preparatórios” que ensinam como passar em diversas provas. Uma busca simples no google devolve 1,180,000 resultados, entre provas, concursos, certificações, vestibular, escolas especializadas, …

Algo que eu aprendi enquanto estudava no IMPA é que provas devem ser as mais simples possíveis, pois só assim você pode garantir que alguém sabe, ou não o conteúdo que deveria. Numa prova complicada se alguém dá a resposta errada muitas vezes não é possível distinguir se o problema é a falta de entendimento do assunto em si, ou da falta de entendimento de toda a dificuldade criada em torno do assunto.

Refletindo sobre o tema, e lembrando de algumas discussões antigas sobre pedagogia, lembrei-me da Taxonomia de Bloom, que organiza os níveis de conhecimentos cognitivos de maneira ordenada. A ordem é a seguinte:

1. Lembrar
2. Entender
3. Aplicar
4. Analisar
5. Avaliar
6. Criar

O interessante é que para motivos de “prova”, precisamos apenas dos primeiros dois níveis: Lembrar e Entender. E é exatamente aí onde para o ensino brasileiro. Ou alguém lembra da aplicabilidade de matrizes, movimentos ondulatórios, briófitas, prosopopéias e afins? Acho que não. E não é por que essas assuntos são “inúteis” que não vemos sua aplicabilidade, o que acontece é exatamente o contrário, como não vemos a aplicabilidade, temos a visão que isso é inútil.

Por mais simples que possa paracer, esse problema acaba se refletindo em vários aspectos do nosso dia a dia. Quantas vezes você já se deparou com um problema, foi ao google, achou a resposta, entendeu e parou por aí? E dias depois um problema semelhante apareceu e você não conseguiu resolver, foi procurar novamente aquela mesma solução que já deveriamos ter aprendido na primeira vez. Bom, talvez isso reflita a forma como você sempre aprendeu as coisas.

Talvez seja a hora de começarmos a rever nossa maneira de aprender.

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

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

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!

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

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.

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.

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.

Foi uma palestra toda confusa, que o palestrante nem se deu ao trabalho de preparar. Pra quem assiste uma palestra, ou aula, ou alguma coisa do gênero, fique atento, pois quando alguém faz como esse palestrante é que não se preparou. O que ele fez foi ficar falando superficialmente de vários tópicos, sempre dizendo “Vou falar disso melhor depois”, após vários “depois” ele acabou não falando nada e conseguiu estourar o tempo. Nota, eu sei que isso é uma característica de quem não se preparou, pois infelizmente eu já fiz isso. E isso acontece pela falta de uma sequência lógica na sua cabeça antes de começar a falar ou apresentar. Detalhe, ele falou do Live ID, que o terra estava usando, mas não conseguiu mostrar, só pra completar o vexame.

Lamentavelmente acabei vendo no que o visual studio se tornou, uma confusão só, que mais complica do que auxilia o desenvolvedor. Nessa hora me ocorreu a epifania, uma das coisas que eu tinha lido lido no Getting Real e tinha discordado era sobre ao planejar um sistema, faça as escolhas ao invés de deixá-las para o usuário. Ao ver o próprio funcionário da Microsoft se enrolar para aumentar a fonte, eu percebi o quanto eu gosto do emacs e do textmate, por falar nisso preciso arranjar uma grana pra pagar a licensa, pois o período de trial tá acabando.