Eu vou ser bem direto, o Ubuntu está progressivamente matando a minha produtividade.

Sou usuário Ubuntu a anos e acompanhei boa parte, para não dizer todas as versões e atualizações de perto e eu me considero apto para dizer que a Canonical errou!

Na verdade, ela não errou, ela está convergindo para uma direção que eu não acredito que seja a melhor para mim. Provavelmente seja melhor para ela, em busca de mais usuários finais, mas para mim, não.

Talvez eu esteja ficando velho e ranzinza, ou como meu amigo Tonismar falou no post dele, estou ficando mais maduro. Após tantas versões do Ubuntu, de inúmeras horas buscando soluções para problemas básicos que, digamos, não deveriam existir em um sistema operacional direcionado ao usuário, confesso que cansei. Cansei de várias coisas.

Velocidade

Atualmente estou com a versão 12.04 e uma coisa que *sempre* me intrigou no Ubuntu é o fato de que toda a versão nova é anunciada como mais rápida que a última. Só eu que não consigo atestar isso. Tenho um computador relativamente bom, não é nenhum super computador do MIT, mas também não é um computador do milhão, é um notebook, mas não é do milhão, é um Dell. Tenho como padrão, reinstalar do zero cada versão nova do Ubuntu (depois de tanto apanhar com as atualizações, nunca deram certo) e mesmo com tanto alarde sobre a velocidade, é fato que para mim as coisas estão ficando mais lentas. 

Unity/Gnome 3

Como eu sinto saudade do Gnome 2, ele era tão simples e prático, simplesmente funcionava, eu configurava as áreas de trabalho, colocava cada programa na sua devida área e instintivamente, usava o sistema, simples assim.

Neste "admirável" mundo novo de Unity/Gnome 3, o que eu vi, foi uma perda muito grande de produtividade.  

Vamos falar do Unity. Ele é lento, fato! Ele pode ter maravilhas de recursos, fantásticas opções, mas ele é lento e isso não me serve. Eu estou usando atualmente o Unity, mas somente por necessidade. Menus, Unity Lens, Global Menu, nada disso me são úteis, na verdade, me confundem mais do que ajudam.

Falando de Gnome 3, essa maravilha que eu declarei amores ao ver os videos e o funcionamento, também se tornou um presente de grego. Primeiramente o esquema de áreas de trabalho dinâmicas, onde elas são criadas de acordo com a demanda, e em linha, ou seja, os atalhos eu eu usava antes no teclado para navegar entre as áreas são parte do passado passado, enterrados, sem contar que cada vez que uma área de trabalho ficava sem um aplicativo, ela era removida, me obrigando a re-organizar todos os aplicativos e re-decorar onde cada um está.

Sim, eu sou neurótico com a organização das áreas de trabalho. Deal with it!

Vídeo

Meu notebook tem uma placa nVidia, consideravelmente boa, com o seu driver feito especificamente para Linux, mas isso de nada me adianta. Travamentos, bugs de transição, janelas desaparecendo são constantes no meu uso, cansei de "perder" a janela do Empathy (outra opção lamentável de IM, mas na falta de uma boa integração de outros clientes, continuo usando), multiplicar janelas do Sublime Text 2 e simplesmente sumir o meu Navegador. Isso não me serve, não mais.

O suporte a multiplos monitores também é algo que está *muito* longe de ser algo aceitável, Usar duas telas é a certeza de muitos dos bugs relatados aqui e mais algumas péssimas decisões de layout (como no Gnome 3 onde o monitor secundário funciona como um monitor estático, ou seja, se tu mudar de área de trabalho, ele não muda e no Unity, ele extender a barra de contexto ao segundo monitor).

Bugs, bugs e um pouco mais de bugs

Eu sei que sou errado por ser um bleeding edge user (também conhecido como: "preciso ter as últimas versões de cada software"), mas a cada versão nova do Ubuntu, luto contra bugs cretinos chatos e recorrentes. Um exemplo atualmente é que eu simplesmente não consigo ver videos em flash, e quando consigo, parece um trailer do avatar pois está tudo em tons de azul. Houve um tempo que eu passava horas corrigindo esses bugs, procurando por soluções, verificando possibilidades, mas isso não condiz mais com a minha realidade, eu não tenho mais esse tempo e preciso de algo que simplesmente funcione.

A morte da produtividade

Eu preciso ligar meu computador e trabalhar, esse tem sido o meu uso nos últimos tempos do meu computador, raras as excessões, vejo algum video ou faço algum post (isso sim é raro :D). Esses pontos relacionados acima, juntamente com as mudanças causadas pelos novos gerenciados de janela, simplesmente mataram a minha produtividade. Onde antes eu tinha um ambiente 100% controlado onde eu sabia onde estaria cada aplicativo e ao alcance de um atalho navegava entre eles, hoje o que eu tenho é um mar de confusão onde a cada nova versão tenho que me acostumar com novos atalhos (lógico que eu posso personalizar, mas tudo é uma questão de usabilidade e principalmente, tempo) e novas maneiras de fazer velhas coisas que eu simplesmente funcionavam e eu estava contente como estavam.

This is the end?

Não sei, honestamente, eu continuo usando o Ubuntu, estou escrevendo esse post dele, uso ele diariamente no trabalho também, mas não levanto mais a bandeira dele como fazia antes. Acho que estou ficando cada vez mais critico e buscando algo que me faça ser mais produtivo, como o Tonismar falou no post dele, é a maturidade, profissional e pessoal, onde tu tem que resolver as coisas e precisa ter um sistema que não vai te deixar na mão quando tu precisar dele. 

E a vida continua, um bug de cada vez.

Ultimamente tenho me envolvido no processo de tradução da documentação do framework PHP Symfony2, por isso não tenho disponibilizado de muito tempo para os posts (traduzir documentação é uma das retribuições que dou para os projetos Open Source que utilizo/divulgo).

A propósito, se alguém tiver tempo disponível e gostaria de ajudar, recomendo fortemente, é muito bom ajudar :), dê uma lida neste link que a Andréia Bohner explica certinho como fazê-lo.

• Contribuindo com a tradução da documentação oficial do Symfony2

É necessário que você tenha lido a primeira parte do artigo, caso não tenha feito ainda, corre lá.

Agora que cheguei a uma decisão, já desabafei, você já deve ter lido o primeiro artigo, já está com todos os arquivos em mãos, vamos parar de papo e vamos para o que interessa.

Permissões

Depois de levar muita bola nas costas, o Facebook aprendeu sobre privacidade (e a falta dela). Existe uma extensa lista de tipos de permissão que sua aplicação pode solicitar ao usuário, disponível na documentação da api, mas para o nosso exemplo, vamos precisar especificamente da permissão publish_stream, que libera a aplicação para atualizar o status do usuário a qualquer momento, assim como criar comentários e curtir conteúdos.

Code is Beautiful

Quem não concorda com isso, está no lugar errado!

Uma vez que já temos a permissão escolhida, vamos montar o código necessário para pedir a autorização e postar algum conteúdo no mural do usuário. Estou considerando que você já fez o download da SDK do Facebook no GitHub (lembre-se do primeiro artigo, jovem Padawan):

    require 'php-sdk/src/facebook.php';

    $facebook = new Facebook(array(
        'appId'  => '125178627581346',
        'secret' => '9fcc6b62c0f23c337d8ecb9aec27d155'
    ));    

    $user = $facebook->getUser();

    if ($user) {
        $post =  array(
            'message' => 'I may be paranoid... but not an android...'
        );
        $facebook->api('/me/feed', 'POST', $post);
    } else {
        $loginURL = $facebook->getLoginUrl(array(
            'scope' => 'publish_stream'
        ));
        echo "«a href="\"".$loginURL."\""»";
    }

Lembrem-se, isso é só um exemplo (extremamente tosco simples). Explicando:

• Linha 1: Requisita a biblioteca do facebook;
• Linha 3 a 6: Instancia a biblioteca, passando os tokens da aplicação ParanoidAndroid (aqui você substitui pela sua aplicação);
• Linha 8: Recupera o usuário;
• Linha 11 a 13: Caso o usuário tenha liberado o acesso da aplicação, monta a mensagem que vai ser postada no mural do usuário;
• Linha 14: Efetua a postagem;
• Linha 16 a 18: Caso o usuário não tenha liberado ainda o acesso da aplicação, monta a URL para solicitar permissão, informando o tipo de permissão necessária;
• Linha 19: Imprime a URL para se logar pelo Facebook.

Neste exemplo, (lembrando novamente, simples), postamos uma mensagem no mural do usuário, mas você pode postar qualquer coisa (desde que seja possivel via a própria aplicação do facebook). Dê uma olhada na lista completa do que você pode postar aqui.

Com isso temos, basicamente, um sistema que permite que sua aplicação, poste algo no mural do usuário, mediante a permissão do usuário.

Caso queira ver a "aplicação" funcionando, dê uma olhada no meu site. Para fazer o download dos fontes, clique aqui

That's all folks, aguardem, mais artigos estão por vir :)

Links úteis

• https://developers.facebook.com/docs/reference/api/post/
• https://developers.facebook.com/docs/reference/api/permissions/

Iniciando a brincadeira

Antes de mais nada, para podermos brincar com qualquer recurso da API do Facebook, temos que necessariamente criar uma aplicação no Facebook. Para isso, seguimos os seguintes passos:

1. Acesse a página inicial de Apps do Facebook devidamente logado;
2. No canto direito superior, clique em + Create New App;
3. Dê um nome para a aplicação (e tente adivinhar o captcha);
4. Após isso, sua aplicação já está funcionando. Você pode adicionar uma imagem, alterar o nome. Mas por enquanto, somente isso já está ótimo.

Feito o cadastro, vamos precisar fazer o download da SDK do Facebook. Podemos fazer de duas maneiras:

• Clonando o repositório do GitHub (recomendado. Isso me lembra que tenho que fazer um artigo sobre Git)
• Fazendo o download do pacote via a url https://github.com/facebook/php-sdk/zipball/master

Com a aplicação registrada e a SDK em mãos, podemos realmente nos divertir

Configurando a SDK

Para configurar a SDK, vamos precisar somente de duas coisas: App ID e App Secret. Ambas informações estão disponíveis na administração da sua recem criada aplicação, em "Summary".

Eu criei uma aplicação chamada Paranoid Android e as informações dela são:

• App ID: 125178627581346
• App secret: 9fcc6b62c0f23c337d8ecb9aec27d155

Com essas informações em mãos, vamos ao que interessa!

Vamos criar um arquivo, vai se chamar index.php mesmo, estou sem imaginação, e colocamos o seguinte código nele:

    require 'facebook_sdk/facebook.php';
    $facebook = new Facebook(array(
        'appId'  => '125178627581346',
        'secret' => '9fcc6b62c0f23c337d8ecb9aec27d155'
    ));
    $kidh0 = $facebook->api('/henrique.boaventura');
    echo 'Nome: ' . $kidh0['name'];
    echo 'Localização ' . $kidh0['location']['name'];

Explicando:

• Linha 1: Requisita a biblioteca do Facebook;
• Linha 2: Criamos a instância da nossa aplicação, setando as informações da nossa aplicação (App ID e App secret);
• Linha 6: Faz a chamada para a API, requisitando o perfil público do usuário (aqui também pode ser o id do usuário);
• Linha 7 e 8: Exibimos algumas informações do usuário.

A API retorna um array para a variável (no caso $kidh0) com todas as informações públicas do usuário.

E é somente isso, com 6 linhas de código temos acesso ao perfil público de qualquer usuário (logicamente, desde que o usuário compartilhe o seu perfil).  

Para fazer o download do arquivo de exemplo (com HTML exibindo o perfil público do usuário), clique aqui.

Esse artigo foi bem curto, mas nos próximos, vamos nos aprofundar mais na API. See you there!

Links úteis:

• http://www.github.com/facebook/php-sdk
• https://developers.facebook.com/docs/reference/api/

O que são Desktop Notifications

Vou assumir que toda alma que chega neste post tem um e-mail ou pelo menos sabe para que serve (just kidding :D). Bom, Desktop Notifications é uma maneira de integrar o navegador com o seu ambiente desktop. Quantos softwares você já instalou no seu SO (Sistema Operacional para os menos intimos) ou plugins para o seu navegador, só para saber que tu recebeste um e-mail ou uma menção no Twitter. Com Desktop Notications, nada disso é mais necessário, isso já vem "embutido" no navegador.

Para que servem?

Bom, exemplos são vários, mas podemos citar:

• Integração com o Twitter (Tweetdeck for Chrome já faz o uso disse de forma magistral);
• WebIM (Web Instant Messengers) – O imo.im  implementou as notificações quando a janela não está em foco;
• Notificação de e-mails – O GMail já tem o recurso e, até onde sei, é o único a implementar;

Estes são só alguns exemplos funcionais de Desktop Notifications, mas existe uma gama enorme de outras coisas que podem ser feitas, ficando a cargo do desenvolvedor implementar.

Então porque o uso com parcimônia?

Já perceberam que no mundo do desenvolvimento Web sempre tem um "porém" na história? Infelizmente, aqui também não é uma excessão :/ . Nativamente, apenas o motor WebKit tem o recurso. É, nem o Firefox e nem Opera ainda possuem o recurso, muito menos previsão de suportar (#fail). O Internet Explorer, bom, deixa pra lá.

Então temos que fazer um uso correto das notifications (vou tratá-las somente por notifications de agora em diante). Podemos traduzir isso como "adicionar verificações e fallbacks" para cada um desses safados que ainda não implementaram as notifications:

if (!window.webkitNotifications) {
    //fallback, mensagem, xingamento, etc
}

Colocando a mão na massa!

Bom, não vamos chorar sobre o leite derramado e vamos usar o Chrome[http://www.google.com/chrome] (sim, ele usa o WebKit[http://www.webkit.org/], não sabia?) para testar as notifications.

Para usar as notifications na sua aplicação, temos que ter noção de três (na verdade quatro) chamadas para a API:

• window.webkitNotifications.checkPermission() – Retorna 0 se o dominio tem acesso as notifications ou 1 se não tiver ainda decidido e 2 caso tenha negado acesso;
• window.webkitNotifications.requestPermission(callback) – Solicita acesso as notifications para o dominio. O callback é executado após a tomada de decisão;
• window.webkitNotifications.createNotification(icon, title, text) – Retorna a instancia da notification. É utilizado o método show() para mostrá-la;
• window.webkitNotifications.createHTMLNotification(link) – Faz a mesma coisa que createNotification, mas carrega um link na notification.

Conhecendo essas chamadas, podemos montar um exemplo simples para demonstrar o potencial das notifications. No caso, vamos fazer um wrapper para gerenciar nossas notifications, e usá-la em um simples e simpático "Bem vindo" ao clicar em um botão (tão anos 90)

Notification = {
    support: function(){
        if(window.webkitNotifications){
            return true;
        } else {
            return false;
        }
    },
    permission: function(){
        return window.webkitNotifications.checkPermission();
    },
    requestPermission: function(callback){
        window.webkitNotifications.requestPermission(function() {
            if (callback) {
                callback(window.webkitNotifications.checkPermission() == 0);
            }
        });
    },
    notify: function(icon, title, text, expires){
        if(Notification.permission() == 0){
            var notify = window.webkitNotifications.createNotification(icon, title, text);
            notify.show();
            if(expires){
                setTimeout(function(){
                        notify.cancel();
                    },
                    expires
                );
            }
        }
    }
}

Explicando:

• Linha 1 – Criamos o wrapper para as funções de notificação;
• Linha 2 a 8 – Função que verifica se o sistema tem suporte a notifications;
• Linha 9 a 11 – Retorna a permissão para a página (0 = Sim, 1 = Não setado, 2 = Não);
• Linha 12 a 18 – Função que solicita a permissão do usuário para mostrar notificações. Caso seja passado um callback, executa ele passando true como parâmetro;
• Linha 19 a 31 – Mostra o notify, com a opção de fechar automaticamente a notification depois de certo tempo (expires, em ms).

Bom, com nosso wrapper criado, é só aplicar ele em nossas páginas. Veja um demo dele em funcionamento.

Luz no fim do túnel

Pelo menos para os usuários do Firefox, existem soluções para "emular" as notifications, através de add-ons. O que eu achei melhor foi o HTML5 Notifications que funcionou perfeitamente no meu ambiente (Ubuntu 11.04), só demonstrando de uma maneira diferente (NotifyOSD). 

That's all folks, see you around :)

Mais links sobre o assunto:

• Web Notifications
• ff-html5notifications
• API  Specification
• Notifications

Saudações!

O grande problema de todas as criaturas que fazem artigos sempre é tempo. Meu tempo se divide ultimamente em cozinhar e trabalhar, então os artigos no blog tem ficado escassos. Hoje vamos mais uma vez tentar mudar isso.

Cenário

Imagine a seguinte situação:
Seu site, com tudo funcional, em seu perfeito e equilibrado estado, precisa de uma alteração, um novo recurso, ou algo parecido. Para isso, você tem que alterar o seu CSS e seu Javascript. Até ai tudo bem, nada de mais, visto que é algo banal, alterações são banais (NOT!), mas alguns usuários assiduos não estão vendo essas alterações feitas no sistema. O que diabos está ocorrendo? Se chama cache.

Cache

Para os pouco iluminados, cache é mais ou menos como copiar uma música no teu computador para evitar de sempre ter que ir na prateleira buscar, mas aplicado a informática. No caso do CSS e do Javascript, ele guarda uma cópia desses arquivos na máquina do cliente. Quando esse cliente acessar o site novamente, ao invés de fazer o download do arquivo do site, ele usará o arquivo em cache, evitando consumo de banda para o cliente e para o site. Essa cópia tem uma data para expirar, mas em muitos casos, não podemos contar com todo esse tempo (e sorte).

Evitando o Cache

Agora que já sabemos o que é Cache e como nosso browser usa ele, vamos aplicar isso no nosso cenário inicial. A prática padrão para isso é concatenar na URL do CSS/JS uma string, vamos iniciar com uma declaração padrão de um CSS (pode ser um JS, mas vou  usar CSS para os testes):

<link rel="stylesheet" type="text/css" media="screen" href="main.css" />

Bom, se analisarmos usando alguma ferramenta (neste caso, o firebug), vamos ver que no primeiro acesso, ele faz o download do CSS, tudo normal, mas ao acessarmos pela segunda vez a mesma página, ele não faz novamente o download do CSS e sim carrega ele do cache. Hum, já era sabido que isso ia acontecer, mas dessa vez, vamos fazer com que ele recarregue o CSS, sem necessidade de limpar o cache:

<link rel="stylesheet" type="text/css" media="screen" href="main.css?nocache" />

Hey! Mas o CSS aceita parâmetros como PHP? 
Não, não aceita, nem cogite deixar esse tipo de pensamento alocado no cérebro. Ele não aceita parâmetros, mas ele aceita a adição de conteudo "como se fosse" um parâmetro.

Recarregamos a página e analisamos novamente. Que maravilha, ele fez novamente o download do CSS como queriamos! But wait! se fizermos isso mais uma vez, lá vem o cache novamente para atrapalhar. 

Isso acontece porque ao adicionarmos a string, ele vai procurar no cache um arquivo "main.css?cache" para o seu dominio e não vai encontrar, porque em cache estava o "main.css", mas na segunda vez, ele vai encontrar e usar o cache novamente.

E agora? Eu quero que ele recarregue o CSS sempre que o usuário acessar o site. Como vamos fazer isso? 

Aqui entra nosso amigo PHP para nos dar uma mão (poderia ser em qualquer linguagem decente de programação). O que vamos fazer é adicionar como "parâmetro" ao CSS um timestamp (da execução do script), usando a função time do PHP assim:

<link rel="stylesheet" type="text/css" media="screen" href="main.css?<?php echo time();?>" />

Dessa maneira, sempre que o o usuário acessar o site, ele vai recarregar o CSS e sempre ter a última versão.

Isso funciona, na maioria dos casos vai ser o suficiente, mas imaginem um site com milhares de acessos, cada usuário tendo que recarregar sempre o CSS/JS, o consumo de banda que isso geraria no servidor. That's not cool!

Evitando o Cache (menos nocivo)

Existe uma maneira menos nociva de evitar o cache, que é recarregar o CSS/JS somente quando ele tiver alguma alteração, mantendo o cache até quando for necessário recarregá-lo.

Para isso, precisamos descobrir a data de alteração do arquivo (lá vem o PHP de novo) e usarmos ele como "parâmetro":

<link rel="stylesheet" type="text/css" media="screen" href="main.css?<?php echo filemtime('main.css'); ?> />

Agora sim, ao invés de recarregar o CSS toda santa vez que o usuário acessar o site, isso é seletivo, somente quando há uma mudança no CSS, mudando o timestamp de alteração do arquivo, ele será recarregado, consumindo somente a banda necessária, no momento certo!

Não foi tão dificil assim, podem admitir :)

Ficamos por aqui, aguardem notícias!

afirmação, estamos aqui novamente para falar de… Twitter!

Já falei que ia ser um artigo de somente 3 partes, extendi para uma 4ª parte extra. Mas ainda não deixei todos contentes, e mais uma vez vou espichar o artigo para uma 5ª parte e quem sabe dessa vez final (eu tenho vários outros assuntos legais para escrever também).

Dessa vez vamos aprender como usar a biblioteca do sr. Abraham Williams autenticar qualquer usuário que queira permitir o acesso a nossa aplicação.

Daqui em diante, vou considerar que você já viu os dois artigos anteriores que abordaram autenticação na API do Twitter. Caso não tenha lido eles ainda, faça-o agora!

• PHP: Integrando o Twitter ao seu Site – Parte 3 (Agora com OAuth)
• PHP: Integrando o Twitter ao seu Site – Extra (Mais comandos da API)

Agora que você já sabe de cor e salteado os outros artigos, vamos ver como autenticar um usuário para nossa aplicação poder acessar os dados
dele.

Ingredientes da receita

Para o usuário permitir o acesso a nossa aplicação, primeiramente, precisamos de alguns dados do app criada na nossa conta do Twitter:

• Consumer Key;
• Consumer Secret;
• URL de retorno da autenticação (você já vai entender o porque).

Também para você já preparar seu ambiente, vamos criar 3 arquivos:

• index.html (somente uma página simples com um link para autenticar o usuário);
• config.php (define 3 constantes para evitar ficar digitando o tempo todo);
• redirect.php (script que vai solicitar a autenticação e liberação);
• callback.php (script que será chamada se o usuário se autenticar).

Com esses dados em mãos, podemos continuar e fazer nossa aplicação, requisitar a permissão do usuário, lembrando que nenhum desses nomes é obrigatório, eu defini eles da maneira que eu achei mais apropriado e compreensivel (ou não!)

Configurando a aplicação

Bom, o arquivo index.html não é nada mais nada menos que um link para o arquivo redirect.php, portanto, nem vou me dar ao trabalho de explicá-lo.

Vamos começar então pelo config.php. Ele vai ser responsável por guardar as informações estáticas da nossa aplicação:

Há! antes que eu me esqueça, eu utilizei $_SESSION e constantes para guardar as informações de tokens que irão ser retornadas da requisição ao Twitter. Na sua aplicação, você muito provavelmente vai guardar isso em um banco de dados, assim espero!

define('CONSUMER_KEY',    'ELi0Wc1kMAuJyHJQ68AEg');
define('CONSUMER_SECRET', 'Vkf6oqNnckF3Tlf00BVzQkMYmcx8mkkI7MzpXixsjY');
define('OAUTH_CALLBACK',  'http://localhost/twitter/callback.php');

Lembrando que a consumer_key e o consumer_secret vem da sua aplicação cadastrada no Twitter. A URL de callback pode ser qualquer URL, até mesmo uma URL local, pois ela vai ser o retorno da autenticação do Twitter. Com isso, só precisamos usar o require no inicio dos arquivos redirect.php e callback.php para usar as constantes.

Requisitando autorização

Dando continuidade a brincadeira, vamos para o redirect.php. Ele vai ser o responsável por montar uma URL com o token da aplicação, que irá para a página do Twitter. Ele fica da seguinte maneira:

session_start();
require_once('twitteroauth/twitteroauth.php');
require_once('config.php');

$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET);

$request_token = $connection->getRequestToken(OAUTH_CALLBACK);

$_SESSION['oauth_token'] = $token = $request_token['oauth_token'];
$_SESSION['oauth_token_secret'] = $request_token['oauth_token_secret'];

$url = $connection->getAuthorizeURL($token);
header('Location: ' . $url);

Explicando:

• Linha 1 – Inicio a sessão, só tem utilidade caso você não utilizar banco de dados;
• Linhas 2 a 3 – Require da biblioteca e do arquivo de configuração;
• Linhas 5 e 7 – Cria uma conexão e requisita um token temporário para a URL de callback;
• Linhas 9 e 10 – Guarda os tokens na sessão;
• Linha 12 – Gera a URL com o token para ser redirecionado para a autenticação do Twitter;
• Linha 13 – O redirecionamento!

Neste momento, se você acessar o redirect.php, você já vai ser redirecionado para o Twitter, pedindo sua senha, e depois, perguntando se você permite que a aplicação X se conecte a sua conta. Agora, vamos fazer o callback.php, que vai pegar o token do usuário e liberar o acesso.

Callback

O callback.php, vai pegar o token verificador e recuperar o token de acesso na API do Twitter. Sei que essa história de token pra cá, token pra lá, pode até ficar chata e complicada, mas c’est la vie.

session_start();
require_once('twitteroauth/twitteroauth.php');
require_once('config.php');

$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $_SESSION['oauth_token'], $_SESSION['oauth_token_secret']);

$access_token = $connection->getAccessToken($_REQUEST['oauth_verifier']);

$_SESSION['access_token'] = $access_token;

$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $access_token['oauth_token'], $access_token['oauth_token_secret']);

$content = $connection->get('account/verify_credentials');

Desmistificando:

• Linha 1 – Inicio a sessão, só tem utilidade caso você não utilizar banco de dados;
• Linhas 2 a 3 – Require da biblioteca e do arquivo de configuração;
• Linhas 5 e 7 – Cria uma conexão com os tokens temporários recuperados no redirect.php e requisita o token de acesso do usuário;
• Linha 9 – Guarda o token na sessão;
• Linha 11 – Cria uma nova conexão, agora com o token de acesso, liberando o acesso da aplicação a conta do usuário;
• Linha 12 – Teste para verificar se a permissão foi liberada com sucesso.

Com isso, você já pode fazer qualquer coisa na conta do usuário, lógico, se ele tiver liberado o acesso da sua aplicação (dãh).

Finalizando

Esse é um exemplo bem simples, e muito diferente do que você virá a usar dentro da sua aplicação, mas conta como um aprendizado. Como disse anteriormente, em um ambiente de produção, o ideal é gravar os tokens todos em banco de dados, podendo assim usar o acesso liberado pelo usuário continuamente, não exigindo sempre a validação no Twitter.

Caso você queira fazer o download dos arquivos para testar, clique aqui.

Alterem, criem e comentem. That’s all folks!

Este artigo vai ser bem simples e direto ao ponto. Juntei todas as ações que mais foram pedidas nos comentários e adicionei algumas que julguei que podem se tornar dúvidas mais adiante. Vamos partir do pré-suposto que você já leu o artigo anterior (right?!) e já sabe tudo sobre como se autenticar na API do Twitter. So, let’s code!

Recuperando informações do Usuário

Nada melhor para começar do que saber para quem se está enviando um tweet (a não ver que você seja um spammer, você já deve saber), afinal, informação nunca é demais. Vamos então recuperar os dados do usuário:

require_once('twitteroauth/twitteroauth.php');

$consumer_key = '******';
$consumer_secret = '******';
$oauth_token = '******';
$oauth_token_secret = '******';

$connection = new TwitterOAuth(
    $consumer_key,
    $consumer_secret,
    $oauth_token,
    $oauth_token_secret
);

$result = $connection->get(
    'users/show',
    array(
        'screen_name' => 'kidh0'
    )
);

$id = $result->id

Isso vai me retornar o profile do usuário @kidh0 (eu mesmo, fique a vontade para me seguir @kidh0) com todas as informações referentes ao mesmo. Para acessar as informações, simplesmente use o $result como uma classe com atributos:

//codigo necessario para autenticacao na API (vide parte 3 do artigo)
$id = $result->id;
$nome = $result->name;
$avatar = $result->profile_image_url;

Aqui cabe uma observação: Sempre que você for recuperar uma informação (tweets, profile, direct messages), você deve usar o método ‘get’ da classe TwitterOAuth. Já quando se for enviar alguma coisa (um update, uma direct), deve se usar o ‘post’. “Mas porque isso?” vocês devem estar se perguntando. Isso é porque o Twitter tem uma API REST, e precisa que seja explicito o verbo HTTP para que a requisição seja feita sem problemas.

Enviando/Removendo Direct Messages

Agora que já temos as informações do usuário, vamos começar a comunicação com ele. Primeiramente, vamos nos manter no anonimato e mandar Direct Messages.
Para enviar uma DM, você vai precisar necessariamente de 2 coisas: ou nome do usuário para quem você vai enviar a DM (tipo @kidh0) ou o ID do usuário, e a mensagem propriamente dita. Para facilitar, vou usar somente o usuário:

$result = $connection->post(
    'direct_messages/new',
    array(
        'screen_name' => 'kidh0',
        text' => 'O que vamos fazer essa noite Cérebro?'
    )
);

Dentro da variável $result, estará toda a informação referente a DM enviada, para acessar as informações, siga o mesmo padrão que usamos antes.
Lembrando que para enviar uma DM, o usuário deve obrigatoriamente seguir você.

Para remover, é mais simples que enviar. Vamos recuperar a última DM e deletá-la:

//recupera as 20 ultimas DM
$result = $connection->get(
    'direct_messages/sent',
    array(
    )
);

//pegamos a ultima enviada
$id = $result[0]->id;
$dm = $connection->post(
    'direct_messages/destroy/' . $id,
    array(
    )
);

Voilá, DM deletada!

Enviando um Retweet

Nossa, eu ia “aportuguesar” a palavra, mas doeu aos olhos. Bom, para retweetar um tweet é bem simples, você só vai precisar… rufem os tambores… do ID do tweet :D.
Digamos que você queira retweetar o meu tweet “code is mighter than the sword #devlife”. Bom, o ID deste tweet é 25681189229, para descobrir o ID, você deve usar recurso “statuses/user_timeline”, explicado no artigo anterior. Tendo em mãos o ID:

$id = 25681189229;
$result = $connection->post(
    'statuses/retweet/' . $id,
    array(
    )
);

Deletando um tweet

Quantas vezes você já tweetou algo errado, ou chegou em casa de cabeça quente e usou o famoso #prontofalei e depois se arrependeu? Para remover um tweet, assim como para retweetá-lo (garanto que já deve ter no aurélio essa palavra), você precisa só do ID do tweet:

$id = 13823697837;
$result = $connection->post(
    'statuses/destroy/' . $id,
    array(
    )
);

Pronto, sem mais dores de cabeça referentes a um tweet embriagado. A não ser que quem não devesse ler, foi mais rápido que você.

Concluindo

Existem ainda dezenas de outros recursos a serem utilizados na API do Twitter, listei aqui alguns dos mais pedidos. Conforme necessidade, vou acrescentando outros aqui, mas por enquanto, ficarão somente estes. Por hoje é só pessoal, drive safely!

Alguns links interessantes:

• Twitter API Documentation
• REST

Depois de desaparecer por praticamente 4 meses (se você não me segue no twitter, é claro), cá estou eu novamente, tomando as rédeas para terminar de uma vez esse jornada em 3 partes.

Esta etapa deveria ter como finalidade, conforme o primeiro artigo, o desenvolvimento de uma biblioteca que agregasse as funções que foram desenvolvidas nos primeiros dois artigos, mas as coisas mudaram um pouco de figura. Visto que o Twitter recentemente parou de dar suporte a Basic Auth à sua API, muitas pessoas me pediram para que este terceiro (e último) artigo mudasse para como se autenticar na API usando OAuth. Como sou fácil de se convencer, resolvi mudar o artigo final para atender essa nova demanda.

O que nós vamos ver daqui em diante é o passo a passo de como gerar os tokens necessários para se autenticar no Twitter, usá-los junto com OAuth para se autenticar e enviar/receber os tweets através da API.

Para aqueles que estão praguejando agora e esperavam pela biblioteca que integraria todos os recursos, sugiro dar uma olhada nesses projetos, que, basicamente, fazem o que iríamos fazer aqui (pra que retrabalho, right?):

• PHP Twitter
• My Twitter
• TwitterLibPHP

Parte 3: Usando OAuth para acessar a API do Twitter

Antes de mais nada, vamos explicar o que diabos é OAuth. Mas não vá imaginando grandes coisas. O foco principal não é detalhar e esmiuçar o OAuth, e sim usa-lo para acessar a API do Twitter).

OAuth

Basicamente, OAuth (Open Authorization) é um padrão aberto que permite que os usuários compartilhem seus dados entre sites, sem a necessidade usar seu usuário e senha. Ele se baseia no uso de tokens, que transitam entre os sites, permitindo acesso a recursos especificos por um determinado tempo.

Gerando os tokens (a.k.a. pedindo pro Twitter liberar o acesso)

Primeiramente, vamos gerar os tokens necessários para acessar a API (ou você achou que aquela abominação de colocar o usuário e senha do artigo anterior ia ser definitiva?). Para isso, acesse o Twitter Developers e clique em “Register an app”.

Será solicitado seu usuário e senha e aparecerá a tela para Registrar uma nova aplicação. Neste formulário, para o nosso uso, é importante que seja selecionado em Application Type a opção “Browser” (dãh) e em Default Access Type, a opção “Read & Write” (no nosso exemplo, vamos enviar e receber tweets). Preencha o resto dos campos com os dados da sua aplicação, mas não precisa se preocupar se a Callback URL é valida (lembrando, para o nosso exemplo em especifico).

Feito o cadastro, a página seguinte tem 2 informações necessárias para nosso exemplo: “Consumer key” e “Consumer secret”.

No menu a direita, no link “My Access Token”, tem as duas últimas informações necessárias para continuarmos: “Access Token (oauth_token)” e “Access Token Secret (oauth_token_secret)”.

Aqui cabe uma explicação.

Nossa aplicação é simples e visa o simples acesso aos nossos próprios tweets ou tweets de nossa aplicação. Justamente por essa simplicidade que não vamos ver como obter o Access Token e o Access Token Secret remotamente (não neste artigo, quem sabe mais adiante). Aplicações tipo TwitPic e o TwitCam fazem uso desses tokens e os recuperam remotamente (Lembra? Allow/Deny?) evitando de digitar usuários e senha em aplicações de terceiros.

Bom, depois da explicação, vamos continuar a brincadeira. Já estamos em posse de tudo que precisamos para colocar as mãos em código (estavam ansiosos não?), então pra que ficar esperando, let’s go!

Mãos a obra

A partir de agora é jogo rápido, codificar é sempre mais fácil do que falar (digitar no caso, eu acho).

Eu não vejo porque de reinventar a roda, já existem várias bibliotecas que fazem o trabalho pesado, eu vou usar para o nosso exemplo, uma feita por Abraham Williams, chamada OAuth Twitter PHP, que faz muito bem o que se propõem, é de fácil uso, e foi uma das primeiras que eu achei (just kidding :D).

Faça o download da versão mais recente da biblioteca (na data de criação deste artigo, era a 0.2.0-beta3) e descompacte o diretório “twitteroauth” dentro da sua aplicação.

Feito isso, vamos criar o script que vai fazer a conexão com a API:

require_once('twitteroauth/twitteroauth.php');

$consumer_key = 'sua-consumer-key';
$consumer_secret = 'seu-consumer-secret';
$oauth_token = 'seu-oauth-token';
$oauth_token_secret = 'seu-oauth-token-secret';

$connection = new TwitterOAuth(
    $consumer_key,
    $consumer_secret,
    $oauth_token,
    $oauth_token_secret
);

$result = $connection->get(
    'account/verify_credentials',
    array()
);

if(property_exists($result, 'error')){
    echo 'Ooops. Deu erro';
} else {
    echo 'Tudo tranquilo';
}

Explicando:

• Linha 1: Require para a biblioteca do Twitter OAuth;
• Linha 3 a 6: Simples atribuição dos tokens a variáveis (parece ficar mais fácil de visualizar);
• Linha 8 a 13: Criando a instância da classe TwitterOAuth usando os parâmetros levantados anteriormente;
• Linha 15 a 18: Uso o método get da classe TwitterOAuth para recuperar os dados da conta do Twitter;
• Linha 20 a 24: Simples verificação a verificação foi feita com sucesso.

O método get tem como parâmetros o recurso e os parâmetros a ser passados para a API. Para este exemplo, usei o recurso “account/verify_credentials”, que basicamente trás informações sobre o usuário. A lista completa de recursos pode ser vista aqui.

Recuperando os tweets

Partindo do pressuposto que já está tudo certo e você está autorizado na API, vamos brincar mais um pouco.
No primeiro artigo da série, mostrei como recuperar de maneiras mais simples (RSS, basicamente) os tweets do usuário. Agora que já estamos mais profissionais no assunto, vamos usar a API para recuperar esses dados. É bem simples:

require_once('twitteroauth/twitteroauth.php');

$consumer_key = 'sua-consumer-key';
$consumer_secret = 'seu-consumer-secret';
$oauth_token = 'seu-oauth-token';
$oauth_token_secret = 'seu-oauth-token-secret';

$connection = new TwitterOAuth(
    $consumer_key,
    $consumer_secret,
    $oauth_token,
    $oauth_token_secret
);

$result = $connection->get(
    'statuses/user_timeline',
    array()
);

echo '<ol>';
foreach($result as $node){
    printf('<li><a href="%s">%s</a></li>',
        'http://twitter.com/' . $node->user->screen_name. '/status/' . $node->id,
        $node->text
    );
}
echo '</ol>';

A Explicação também é simples: Eu adaptei o exemplo do primeiro post para ao invés de percorrer um XML ele percorrer o resultado da consulta à API. Com isso ele vai montar a mesma lista com os Tweets.

Enviando um tweet

No segundo artigo, utilizamos cURL para acessar a API e enviar tweets, passando o usuário e senha. Isso não é legal, e é evil. Agora podemos usar o método “post” para enviar os tweets, basicamente temos que mudar o recurso e passar a mensagem como parametro:

require_once('twitteroauth/twitteroauth.php');

$consumer_key = 'sua-consumer-key';
$consumer_secret = 'seu-consumer-secret';
$oauth_token = 'seu-oauth-token';
$oauth_token_secret = 'seu-oauth-token-secret';

$connection = new TwitterOAuth(
    $consumer_key,
    $consumer_secret,
    $oauth_token,
    $oauth_token_secret
);

$result = $connection->post(
    'statuses/update',
    array(
        'status' => 'Text of status here',
    )
);

Rápido, fácil e indolor. Assim que as coisas devem ser!

Com isso você já tem uma boa base para criar aplicações no seu site, interagindo com a API do Twitter. Como complemento recomendo fortemente ler a documentação da Twitter Developers, que tem muita coisa boa pra ser aproveitada.

Pessoal, fico por aqui, até a próxima e boa diversão!

Links:

• OAuth;
• Twitter Developers;
• How to PHP OAuth Twitter.

Créditos da imagem do “mano” twitter – Luciano Fontoura

Se você não está familiarizado com essa biblioteca, não se preocupe, vamos dar um jeito de fazer parte da familia :D

Parte 2: Atualizando sua timeline

Como diria a bruxa do desenho do Pica-Pau (lembre-se, desenho!): “E lá vamos nós!”. Para começar, uma explicação básica do que é a biblioteca cURL e seu processo de instalação.

cURL

cURL(Client URL Reques Library) na wikipedia: “cURL é um projeto de sofware que fornece uma biblioteca e uma ferramenta de linha de comando para transferir dados usando vários protocolos”. Ele nos permite, basicamente, fazer requisições para uma URL e recuperar o resultado dessa requisição. Podemos também adicionar parâmetros a ela.

O PHP tem uma biblioteca para usar o CURL. A instalação é bem simples. No Ubuntu basta digitar a seguinte no terminal:

sudo apt-get update && sudo apt-get install curl php5-curl

Com isso você tem tanto a ferramenta para linha de comando quanto a biblioteca para PHP instaladas na sua máquina.

Um teste bem simples para ver o cURL funcionando é digitar o seguinte no terminal:

curl http://www.hboaventura.com

O retorno vai ser o código-fonte do meu site no seu terminal. Não vou me estender muito na cURL, tem bastante conteúdo na web, just google it!

Usando o php-curl para enviar tweets

Com o ambiente pronto, podemos agora focar na integração com o PHP que o pacote php5-curl adiciona ao nosso server. Basicamente, para enviar um tweet, você vai precisar:

• seu usuário (d’oh);
• sua senha (tinha dúvidas sobre isso ainda?);
• a mensagem que você quer tweetar (até vou procurar no dicionário se isso já virou um verbete);

Assim como no outro artigo, a explicação é maior do que o código propriamente dito. Com esses dados a mão, o que temos que fazer é usar algumas funções do php-cURL para “embuti-los” na requisição. Vamos ao que importa (código!):

$usuario = 'kidh0';
$senha = 'hahaNoWay!';
$mensagem = 'Wow! Meu primeiro tweet via API';

$url = 'http://twitter.com/statuses/update.xml';

$curl_handle = curl_init();
curl_setopt($curl_handle, CURLOPT_URL, $url);
curl_setopt($curl_handle, CURLOPT_POST, true);
curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl_handle, CURLOPT_CONNECTTIMEOUT, 30);
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, 'status='.$mensagem);
curl_setopt($curl_handle, CURLOPT_USERPWD, $usuario.':'.$senha);
$resultado = curl_exec($curl_handle);
curl_close($curl_handle);

Explicando a coisa toda:

• Linhas 1 a 3: Basicamente coloquei em atributos os dados necessários para a requisição;
• Linha 5: URL para qual é feita a requisição (envio do tweet). Note que o arquivo requisitado é um XML, por isso o retorno é um XML, mas a API do Twitter também aceita o formato JSON, retornando, obviamente, uma string JSON;
• Linha 7: Inicia uma nova sessão e retorna o handler cURL para ser usado com as outras funções, leia mais;* Linha 9: Seta a requisição para ser um POST HTTP;
• Linha 10: Ao setar para true, retornará o resultado de curl_exec() como uma string, se estiver false, vai jogar na tela direto;
• Linha 11: Seta para 30 o número de segundos para esperar enquanto tenta conectar;
• Linha 12: Adiciona um campo para o POST chamado status com o conteudo da variável $mensagem;
• Linha 13: Seta o usuário e senha para a validação da requisição;
• Linha 14: Atribui a variável $resultado o resultado da requisição. Vale lembrar aqui que o retorno, em caso de sucesso, vai ser um XML com todas os atributos do status. Em caso de erro, retornará a mensagem referente;
• Linha 15: Fecha a conexão, mas não é necessário;

Para manipular a variável $resultado (lógico, se você optou por retornar um XML) podemos usar nosso bom amigo SimpleXML que foi usado no post anterior).

Com isso temos uma simples mas funcional integração de envio de tweets direto do seu site para o Twitter, prático e rápido.

No próximo artigo (e final, at least!), vamos fazer uma classe para trabalhar com o que vimos até agora, colocando um plus a mais :D. Até o próximo artigo!