fechaTag

Resolvi experimentar um pouco a Twitter API. É linda, do jeito que toda API deveria ser. É REST, muito fácil de entender e colocar para funcionar, e devolve dados em XML, JSON, RSS e ATOM.

Essa simplicidade permite interagir com a API usando ferramentas simples da linha de comando do Unix, como o wget e a cURL. Para nossos exemplos, vamos usar cURL. Se você usa Ubuntu, antes de começar faça:

sudo apt-get install curl

Para fazer um simples post, por exemplo, você pode digitar, em seu terminal:

curl -u seu_username:sua_senha -d status="Twittando do terminal. Aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/" http://twitter.com/statuses/update.json

É isso mesmo, meninos e meninas, é só um post com autenticação, mais nada. RESTful, simples e elegante, deixar qualquer SOAP no chinelo. Inspirador para qualquer um que precise projetar uma API. Isso retorna dados em JSON. Se você quiser os mesmos dados em XML, ATOM ou RSS, basta mudar a extensão na url.

Agora vamos automatizar isso. Eu criei um arquivo /usr/local/bin/twitter com o seguinte conteúdo:

source $HOME/.twitter
curl -u $user:$password -d status="$@" http://twitter.com/statuses/update.json

Naturalmente, criei o arquivo como root e dei permissão de execução para todos os usuários. Agora, no diretório de cada usuário, basta criar um arquivo .twitter com o seguinte conteúdo:

user=seu_username
password=sua_senha

Pronto, tendo feito isso, qualquer usuário que tenha o arquivo .twitter em seu home pode twittar do terminal com:

twitter "Twittando do terminal, aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/"

Simples e indolor, agora você pode automatizar suas twittadas com shell script. Pode, por exemplo, twittar toda vez que seu servidor baleiar, ou agendar twits com cron.

Search API

A Search API também é espetacularmente simples, dê uma olhada. Fiz a UPBox usando a Twitter Search API, por exemplo, com 22 linhas de código.

Abri o OpenOffice Writer, mandei gravar uma macro, escrevi "teste", selecionei e pintei de vermelho. Olha o código gerado:

sub Main
rem ----------------------------------------------------------------------
rem define variables
dim document as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
rem ----------------------------------------------------------------------
dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "Text"
args1(0).Value = "teste"
dispatcher.executeDispatch(document, ".uno:InsertText", "", 0, args1())
rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:SelectAll", "", 0, Array())
rem ----------------------------------------------------------------------
dim args3(0) as new com.sun.star.beans.PropertyValue
args3(0).Name = "FontColor"
args3(0).Value = 16711680
dispatcher.executeDispatch(document, ".uno:FontColor", "", 0, args3())
end sub

Há muito código complexo por aí. Nesse caso, para invocar os métodos dos objetos do OpenOffice, é preciso usar um objeto dispatcher, chamando executeDispatcher, e passando o objeto, o nome do método e um array de argumentos. Que espécie de sadismo leva alguém a projetar uma solução como essa? Vale lembrar o que diz o Zen do Python:

Se uma implementação é difícil de explicar, é uma idéia ruim.

Outro exemplo interessantíssimo é o protocolo SOAP. Se você precisar construir um serviço SOAP do zero, dê uma investigada na documentação que você vai ter que ler. Compare com a documentação do protocolo XML-RPC, para ter uma idéia.

Meninos, o tio vai ensinar um segredo a vocês, a complexidade se reproduz assexuadamente. Há muito código complexo demais por aí. Se você encontrar indícios de complexidade hoje, corte antes que ela se reproduza, porque ela tende a fugir do controle. Cada vez que você deixa uma implementação complexa num componente de um sistema, você está complicando um pouquinho todos os pontos do sistema que usam aquele. Os resultados ruins são exponenciais. Por mais talentoso que você seja, se deixar a complexidade se enraizar e crescer, vai chegar um momento em que a lógica vai "jogar a toalha" e você vai começar a programar na base da tentativa e erro.

Lembre-se, então, partes simples, conectadas por interfaces simples. Complicado é errado, feio e mau, faz você entregar atrasado e com bugs. E, se precisar de inspiração, abra o Python e digite:

import this

Um amigo me escreveu agora para mostrar algo muito curioso. Abra sua Firebug, ou qualquer outro lugar onde você roda Javascript, e teste:

new Date(2008,8,11)

Você deve ter como retorno um objeto de data, que se impresso mostra:

Thu Sep 11 2008 00:00:00 GMT-0300 (BRT)

Porque setembro e não agosto, você pode se perguntar. É porque em Javascript, assim com na maioria das linguagens de programação, arrays começam com zero, então faz sentido que contadores também comecem com zero. Assim, janeiro é o mês zero, e se você precisar construir um array com os nomes dos meses, janeiro será o primeiro do array. Faz todo o sentido.

Agora, o que não faz sentido. Tente:

new Date(2008,9,12)

Aqui no meu sistema eu obtive:

Sat Oct 11 2008 23:00:00 GMT-0300 (BRT)

Ou seja, uma hora mais cedo. O que será isso? Correção para o horário de verão? Se é, em que regra se baseia? Os horários de verão no Brasil mudam todo ano, e dependem de em que estado você está.

Alguém tem alguma dica?

Você está usando um terminal conectado a um servidor Unix quando as coisas começam a se comportar de maneira estranha. Depois de algum tempo você descobre o problema. Vai até a mesa de um programador novato e descobre que ele, como root, digitou:

# cd
# rm -rf *

O sujeito percebeu a burrada antes de apagar os diretórios /usr e /users. Nesse caso, /users continha os diretórios home. Mas todo o resto do sistema se foi, incluindo /dev, /etc e /bin.

O que você faria? Para complicar as coisas, esta história aconteceu há um bocado de tempo, numa VAX. Ou seja, não era só fazer um boot com um live-CD, fazer um backup dos dados dos usuários e reinstalar o sistema.

O que fazer? Não entrar em pânico. Uma história e tanto.

No Greg's Wiki você encontra os Bash Pitfalls, uma lista de problemas comuns entre os programadores bash iniciantes.

Encontrei vários dos meus erros comuns lá. E aprendi um bocado.

Exercício de lógica. Esses Puzzles do Wendel me fizeram perder um tempão! Boa diversão, depois conte para a gente aqui nos comentários até onde você foi. IMPORTANTE: não escreva as respostas, senão você estraga a brincadeira dos outros.