Olá, no último post falei de um novo projeto que coloquei no ar, o Zapt.In, um encurtador de URLs brazuca (sim, mais um, hehe). E nos últimos dias liberei algumas novas funcionalidades no Zapt.In. A mais interessante delas é a versão inicial da API de Desenvolvimento do Zapt.In. Mas o tema deste post não é a API, mas sim como colocar o Zapt.In para funcionar no Tweetie, um dos melhores clientes do Twitter para iPhone.

Bom, mas chega de bla bla bla e vamos ao que interessa…

1. Conseguindo sua Chave da API do Zapt.In

Para utilizar a API do Zapt.In, você precisa pegar sua chave da API. Para isto faça seu login no Zapt.In e clique na opção “Perfil” do menu de usuário. Na página com informações de seu perfil você verá sua Chave da API.

2. Agora abra o Tweetie em seu iPhone

Teta, basta clicar no ícone do Tweetie em seu springboard:

3. Configure o Tweetie para usar o Zapt.In

Na tela inicial do Tweetie (para escolhar qual conta você vai usar), clique no botão “Settings” (configurações):

Depois clique na opção “URL Shortening” (encurtamento de URLs):

Depois escolha a opção “Custom” (Customizado) para configurar o Zapt.In:

Agora é colocar a URL da API do Zapt.In no campo de customização. A URL deve ficar da seguinte forma:

http://zapt.in/api/links/shorten?version=1.0&login=SEU_LOGIN&key=SUA_CHAVE&longUrl=%@

Não se esqueça de substituir os valores SEU_LOGIN e SUA_CHAVE pelos valores de sua conta no Zapt.In!!

Depois de colocar a URL clique no botão “save” (salvar) e você estará pronto para usar o Tweetie com o Zapt.In.

3. Agora é só usar…

Digite sua mensagem com uma URL longa que você deseja encurtar. Depois clique no botãozinho que fica no campo da mensagem com a contagem de caracteres:

Agora é só clicar no botão “Shrink URLs” (Comprimir URLs) e as URLs longas de sua mensagem serão magicamente encurtadas pelo Zapt.In:

Eeeeba… agora só faltam dois zilhões de outras aplicações suportarem o Zapt.in!!! ;-)

Quase todo mundo já deve ter esbarrado (e se perguntado sobre o que são) umas URLs estranhas com domínios mais estranhos ainda, como por exemplo: bit.ly/7XC3Lo, migre.me/ck3k, tinyurl.com/yge8jzg, j.mp/7XC3Lo e zapt.in/k. A maior parte do mistério é esclarecida quando clicamos num link destes e somos redirecionados para um outro site. Tratam-se de URLs encurtadas através de algum serviço de encurtamento de URLs (Wikipedia: URL shortening).

Bom, mas pra que precisamos disto. Afinal os browsers evoluíram para aceitar URLs de tamanhos gigantescos (não existe um consenso quanto ao tamanho máximo de uma URL, mas elas podem passar dos milhares de caracteres na maioria dos browsers e web servers). Na realidade existem várias utilidades para estes encurtadores de URL como facilitar a digitação e a verbalização de URLs (é melhor usar/ditar/digitar uma dezena de caracteres do que milhares de caracteres), permitir que URLs grandes fossem compartilhadas em mensagens SMS (imagine passar a URL toda deste post numa mensagem de texto) ou até mesmo fazer o tracking de clicks/visualizações de um determinado link. Mas a coisa decolou mesmo foi com a popularização do Twitter, que permite apenas mensagem com no máximo 140 caracteres. Ou seja, qualquer caractere é valioso ao se compartilhar um link em um tweet. Fica claro que na hora de compartilhar aquele link do torrent do Ubuntu 9.10 no Twitter é melhor usar a URL encurtada http://zapt.in/m com apenas 16 caracteres do que a original http://releases.ubuntu.com/9.10/ubuntu-9.10-alternate-i386.iso.torrent com 70 (e olha que esta é relativamente curta).

Mas como funcionam os encurtadores (ou compressores) de URLs?

Bom, na prática (pelo que vi até o momento), nenhum “encurtador” de URL faz realmente a compressão da URL. Entendendo como compressão de dados a utilização de algoritmos como o Lempel-Ziv (LZW – utilizado no winzip, gzip, etc) ou o Run Length Encoding (RLE – utilizado em máquinas de fax).

O que eles fazem, em geral, é construir uma função bijetora que leva cada URL longa para uma URL ou chave menor (e vice-versa), tentando minimizar ao máximo o espaço necessário para esta nova URL ou chave. Existem variações quanto aos modelos de funções de mapeamento utilizadas (algumas não sendo de fato bijetoras) e também em como as URLs menores ou chaves são geradas.

Para a geração das chaves, muitas vezes se utiliza um hash único calculado aleatoriamente (para evitar que se possa prever as sequências) ou mesmo uma chave calculada através da transformação de um número sequêncial (cada URL encurtada incrementa a sequência) utilizando uma base de representação maior do que a decimal. A idéia é utilizar menos posições (caracteres) para representar o mesmo número (índice). Por exemplo:

Número 70015 (setenta mil e quinze) representado em diferentes bases numéricas:

• Base 2 (binária) : 10001000101111111 : 17 caracteres
• Base 8 (octal) : 210577 : 6 caracteres
• Base 10 (decimal) : 70000 : 5 caracteres
• Base 16 (hexa-decimal) : 1117f : 5 caracteres
• Base 32 : 24bv : 4 caracteres
• Base 62 : IDH : 3 caracteres

Observe que para representar o mesmo número, podemos entre 17 e 3 caracteres (somente com os exemplos de representações utilizados no exemplo).

Me parece que o Migre.Me utiliza Base 62 e um índice sequencial de URLs, já o Bit.Ly parece usar Base 62, mas com algum esquema de sequenciamento estranho (talvez ele use algum particionamento do espaço a partir da URL original).

Bom, depois de mapear a URL original para uma encurtada, e armazenar isto num banco de dados, o que o “encurtador de URLs” faz é redirecionar um visitante que segue a URL encurtada para a URL original. De preferência os serviços utilizam o redirecionamento do tipo permanente (HTTP 301 – Permanent Redirect), já que este tipo de redirecionamento preserva as características da página destino para fins de web crawling, SEO, rankings, etc. Digamos que ele é o tipo de redirecionamento mais amigável com os motores de busca.

O interessante é que entre receber a requisição na URL encurtada e redirecionar o visitante para a URL original, o encurtador pode capturar vários tipos de estatísticas para aquele link. Ele pode contar quantas vezes o link foi clicado, qual o tipo de browser que foi utilizado, etc. Isto torna os serviços ainda mais úteis, podendo ser utilizados para medir taxas de conversão de clicks, eficiência de campanhas online, concursos e outros.

Joia, mas agora vamos falar do Zapt.In…

Bom, a idéia do Zapt.In nasceu há alguns meses quando este tipo de serviço começou a explodir pela rede: o Brasil ainda não tinha um encurtador de URL decentes – Leia-se: o Jonny Ken ainda não havia criado o Migre.Me ;-), eu trocava várias ideias sobre as possibilidades de um serviço destes associado ao BlogBlogs e o LiveStream com Manoel Netto e eu acabei me esbarrado em alguns domínios interessantes (bem curtos) como foi o caso do ZAPT.IN. Acontece que o tempo passou, muita coisa aconteceu e nunca rolou de fazermos o tal encurtado.

Mas como para tudo chega a sua hora, neste feriado (última semana) aconteceu o alinhamento planetário perfeito: a Isabella passou a semana em Uberaba, as coisas estavam mais tranquilas no trabalho e, no final de semana prolongado, minha mãe e irmã vieram para Sampa e passaram grande parte dos dias caminhando pelos shoppings e ruas do centro (com a Isa que já havia retornado), deixando o viciado em codar (eu mesmo) livre para criar, hehe. Amo muito tudo isto!!!

Bom, ai foi a hora de arregaçar as mangas, abrir o TextMate e começar a codar. Com algumas boas horas de coding e pesquisa consegui colocar a primeira versão (bem tabajara, mas lembrando que ‘shipping is a feature‘) para rodar na plataforma de Cloud Computing da Heroku. Na realidade passei mais tempo estudando algumas coisas (algoritmos, Heroku, Git, etc) do que codando, mas na hora de mandar brasa no “POG” e escrever o Zapt.In a coisa andou bem rapidamente.

É isto, agora o Zapt.In está no ar em versão nem-alpha-ainda. Claro, cheio de bugs, sem logo, sem layout, com poucas funcionalidades e sem a menor preocupação, ainda, com escalabilidade. Mas um dia ele chegará lá, para isto preciso da ajuda de vocês (para usarem, testarem e enviarem suas ideias).

Tá, mas por que fazer MAIS UM encurtador de URLs?

Esta é uma boa pergunta. O Brasil já tem o Migre.Me e existe mais de uma centena de serviços parecidos por ai. Então por que?

Ué, porque é divertido! ;-) Porque serviços como o BlogBlogs e vários outros nasceram assim. Porque não?

É isto, depois escreverei alguns posts sobre os desafios, os perrengues e as aventuras de colocar mais uma aplicação no ar. HeyHo!!!!

Há alguns vários dias publiquei um post com a apresentação que fiz no Campus Party sobre Tendências em Aplicações Sociais para 2009. No mesmo post comentei que escreveria alguns novos posts sobre o assunto e este é o primeiro deles.

PS:. Também desisti de ficar revisando o post e protelando a publicação. Então, fica o convite, se você encontrar algum erro ou mesmo alguma idéia ou conceito equivocado, me avise que farei o possível para corrigir o artigo. A idéia é deixar um trabalho que possar ser uma boa referêncie para o assunto.

O que são as aplicações sociais

Antes de falar das tendências, é preciso que entender o que são aplicações sociais e em que contexto elas se encontram no momento atual. Por definição, aplicações sociais (social software, ou social applications) são todas as aplicações, sistemas e serviços que permitem que usuários (pessoas) interajam entre si e troquem informações. O verbete da Wikipedia que descreve social software também chama a atenção para o fato da maioria destes serviços compartilharem características comuns como oferecem APIs (application programming interfaces) abertas, design orientado a serviços e a capacidade de se fazer o upload de dados e mídia. Alguns destes serviços acabaram ficando muito famosos como é o caso do Orkut, o FaceBook, o Twitter, o YouTube e também – porque não? – alguns serviços nacionais como o BlogBlogs e o VideoLog.

A infra-estrutura da nova web

Recentemente as Redes Sociais emergiram como uma grande novidade ou até mesmo como as killer applications da Internet, mas discordo desta visão e acredito que redes sociais são muito mais features (ou funcionalidades) do que produtos. Para mim elas são apenas um nova camada da infra-estrutura da nova web, a camada social. Podemos entender a web atual sendo composta por três camadas: a) a primeira camada (começando da mais profunda para a mais superficial inspirado pelo modelo OSI) é a camada física que começou a ser construída em meádos da década de sessenta quando o foco era conectar todos os pontos do planeta através de cabos metálicos e fibras ópticas; depois temos b) a camada lógica que se consolidou com o surgimento do protocolo HTTP e constitui o conjunto de protocolos de identificação e endereçamento de nós da rede; e do roteamento e troca de mensagens pela rede. Finalmente temos c) a camada social, que traz os usuários para o cenário. Esta camada é o conjunto de conceitos, padrões e serviços que permitem a interação entre os usuários e a troca de informação entre eles. Estamos falando de mecanismos de troca de mensagens, modelos de dados para o armazenamento das relações entre pessoas (grafo social ou social graph), mecanismos de identificação e autenticação de usuários; e todos os outros que se consolidaram com a popularização das redes sociais.

É sobre estas três camadas da infra-estrutura da nova web que as aplicações sociais aparecem com sua maior força. Utilizando os serviços oferecidos pela camadas inferiores as aplicações oferecem serviços específicos para os usuários entregando valor (funcionalidade e utilidade) para os mesmos. Assim, um serviço de compartilhamento de fotos como o Flickr utiliza recursos básicos das camadas inferiores para transformar o ato de armazenar e distribuir imagens numa aplicação social. Seus usuários podem, então, subir (upload) suas fotos, enviá-las para seus amigos, montar grupos de interesse, trocar mensagens, avaliar as imagens e muito mais. Por outro lado as funcionalidades de enviar mensagens, montar grupos e avaliar itens não teriam sentido sem a especificidade criada em torno das fotos no Flickr. Ou seja, a aplicação agrega valor na medida que dá um fim (objetivo) para os features utilizados das camadas de infra-estrutura. Por fim, como as aplicações sociais normalmente oferecem APIs abertas, outras aplicações mais complexas podem ser criadas utilizando-se da infra-estrutura e também dos diversos serviços oferecidos por outras aplicações. Um desenvolvedor pode, então, utilizar a API do Twitter e a API do Flickr para montar um novo serviço de disseminação informal e espontâneo de fotos e mensagens como o SnapTweet.

Assim, as redes sociais são, em última instância, plataformas que implementam e disponibilizam a camada social da infra-estrutura da nova web, onde veremos, cada vez mais, novas aplicações serem construídas e disponibilizadas. Um exemplo claro é o que está acontecendo com o OpenSocial no Orkut e as aplicações do FaceBook. É na camada das aplicações que reside o maior valor e as maiores inovações. O restante é infra-estrutura, uma nova commodity com pouca inovação e valor reduzido no novo contexto da web social.

O cenário atual

Se por um lado estas aplicações se tornaram super frequentes e um sucesso de popularidade, por outro isto é parte do problema que enfrentamos no momento. A diversidade de aplicações e as constantes pressões para que façamos, sempre, parte de todas elas gera uma situação enfrentada por quase todas as pessoas que estão profundamente envolvidas e conectadas na rede: a saturação por informações (content overload, ou information overload). Além da saturação por informações o contexto atual também é marcado por uma série de fatores que ajudam a definir o ambiente para que nossas tendências façam sentido. Entre eles podemos destacar: a) a crise internacional, que traz pressões financeiras para todos os mercados; b) a escassez de capital para novos empreendimentos consequente da crise; c) a decepção com os modelos de publicidade super direcionada beseados em informações demográficas imprecisas ou falsas nas redes sociais; d) a consagração dos agregadores de conteúdo, da inteligência coletiva e das conversações on-line como uma mídia; e) a popularização das redes móveis 3G e o surgimento de inúmeros e sofisticados dispositivos móveis conectados como o iPhone e a plataforma Android; f) o início da consolidação dos serviços de computação sob demanda em larga escala (cloud computing, ou computação das nuvens); g) a popularização dos widgets e, por fim, h) a preocupação com aspectos de portabilidade de dados (especialmente os pessoais) e as discussões sobre privacidade e segurança destas informações.

Pronto, agora que o contexto está entendido, estou quase pronto para falar das tendências. Antes, quero deixar claro que este material é fruto de minha avaliação (e imaginação) pessoal do cenário e de várias horas de pesquisa realizadas na Internet. Não tenho bola de cristal e, como todo exercício de futorologia, os riscos são bem altos, especialmente na Internet.

Vamos às tendências

As tendências que abordei em minha apresentação foram:

• Descoberta (Discovery)
• Mídias Sociais e Computação das Núvens (Social Media & Cloud Computing)
• Mídias Sociais e Mobilidade (Social Media & Mobility)
• Conteúdo e Seviços Super Locais (Hyper-Local Content & Services)
• Widgetização e Des-sitelização* (Widgetization)

* Este termo foi ‘roubado’ de uma apresentação do Abel Reis da Agência Click.

Nos próximos posts tratarei individualmente de cada uma destas tendências.

Abraços e até o próximo post!!!

O Campus Party 2009 está simplesmente animal. Palestras e conversas para todos os tipos de geeks. De fotografia a vídeo digital, de desenvolvimento a robótica, o que não falto é conteúdo interessante para os campuseiros. Uma das áreas que acho bem legal do Campus Party é a área de Desenvolvimento, focada em temas sobre desenvolvimento de software. Ali são apresentadas novas técnicas de programação, frameworks de desenvolvimento e as mais variadas ferramentas. Hoje, passando por ali, bati um papo rápido com o organizador da área e perguntei se eles teriam algum espaço na agenda para uma palestra sobre como estamos fazendo software na WebCo Internet (a empresa que desenvolve o BlogBlogs e o Brasigo). Para minha surpresa o organizador (do qual, infelizmente, não sei o nome, mas agradeço muitíssimo) foi super simpático e conseguiu um espaço no horário do almoço. Foi duro competir com o almoço dos campuseiros, mas aproveitei a oportunidade e compartilhei com a audiência um pouco de como estamos fazendo software na WebCo. Falei de nossas preocupações com escalabilidade e de como isto foi crucial para o sucesso do BlogBlogs; e também falei um pouco sobre como estamos aplicando metodologias ágeis e engenharia de software para escrever nossas aplicações de maneira mais eficiente e prazerosa. Foi muito legal, pois apesar de não termos tido tempo de divulgar a apresentação (usamos apenas o Twitter para divulgar), haviam várias pessoas interessadas que assistiram a palestra e fizeram várias perguntas interessantes sobre o assunto. Já compartilhei a apresentação no SlideShare e você pode vê-la aqui mesmo.

* As estatísticas da apresentação estão bem defasadas, pois não tive tempo de preparar a apresentação e usei alguns slides bem antigos para fazê-la.

Como o Campus Party tem uma agenda muito dinâmica, uma boa maneira de saber das modificações e novidades de última hora é acompanhar o LiveStream do Campus Party que agrega em um único lucar tudo que rola sobre o Campus Party (com a tag #cparty) em vários serviços e redes sociais (incluíndo blogs, twitter, flickr, youtube, videolog, gengibre e pinfotos).

Vejo vocês no Campus Party!!!

Nos últimos 15 anos de minha vida venho trabalhando cada vez mais com o desenvolvimento de software, na maior parte das vezes indiretamente (já que não fui programador profissional) e, algumas vezes, diretamente, em alguns projetos pessoais (como foi o caso dos 2 primeiros anos do BlogBlogs). Neste longo período, pude vivenciar evoluções interessantes na indústria de software: a popularização das linguagens orientadas a objeto, a esperança nas ferramentas CASE, a evolução rápida de JAVA, a emergência de UML como a maneira de se modelar e especificar software, os métodos planejados de desenvolvimento (Unified Proccess, RUP, etc) e, mais recentemente, a popularização das linguagens dinâmicas e dos métodos ágeis (XP, SCRUM, etc). E claro, tudo isto seguido da tradicional devoção (muitas vezes cega) de alguns dos grandes usuários de cada uma destas tecnologias, ferramentas ou metodologias.

Porém, acho que uma das coisas mais significativas que está acontecendo na indústria é a socialização do “como” fazer software. E não estou falando apenas de colaboração, que já vimos todo o seu poder na comunidade OpenSource, mas de aspectos mais mundanos e presentes no dia-a-dia do desenvolvimento. Sim, desenvolver software está se tornando uma atividade cada vez mais social e a geração de programadores que sacou isto está tomando uma dianteira indiscutível. Eles não são mais os antigos programadores do estereótipo clássico: obesos, anti-sociais e brilhantes. Eles são descolados, adoram conversar, interagem em todos os níveis e gostam muito do que fazem e desenvolvem aplicações complexas de maneira ágil, objetiva e pragmática.

Recentemente tenho tido o privilégio de vivenciar um ambiente onde este tipo de desenvolvimento está acontecendo. E isto não quer dizer que problemas não existam, mas sim que eles são atacados de maneira mais humana e social. Um membro da equipe desmotivado ou chateado é sim um problema da equipe toda e não é em super-técnicos que a coisa se sustenta, mas sim no trabalho em equipe. Nestes últimos 10 meses, uma situação me chamou muito a atenção: ver membros da equipe produzindo loucamente enquanto desenvolviam várias outras atividades paralelas, como jogar xadrez online. Incrível, centenas de linhas código fluindo naturalmente, discussões de arquitetura e design acontecendo no sofá ou no vídeo-game e o xadrez rolando, quase que como uma malha entre membros do grupo.

Claro, isto depende de skills sociais, não só para garantir a interação social, mas principalmente para permitir enxergar além de pequenas questões mundanas do dia-a-dia. Sim, humildade e maturidade são skills sociais importantes. Sem elas fica difícil escutar e, mais difícil ainda, aprender mais (principalmente com os outros) e crescer. Mais legal ainda é ver que este tipo de coisa é contagiante e todos que estão em volta acabam, de um modo ou de outro, tocados por esta situação. A gente, normalmente, aprende por exemplos ou por bater em superfícies bem sólidas, hehe. Mas o ponto é que a coisa começa a se propagar e já é possível ver outros membros sacando que ser um bom desenvolvedor exige muito mais do que dominar uma linguagem, uma técnica, um framework ou um conjunto de bibliotecas. Bingo!!! Kudos!!! E parabéns a todos (isto é uma piada interna).

É isto, a era do esporte coletivo de desenvolvimento de software chegou. E quem disse isto foi ninguém menos do que um dos grandes desenvolvedores que a humanidade conheceu, que concebeu e implementou a linguagem de programação C++, Bjarne Stroustrup. Recentemente Stroustrup deu uma entrevista polêmica sobre como educar melhores desenvolvedores de software, onde ele fala exatamente desta nova era.

Programming is part of software development. It doesn’t matter how fancy your code is unless it solves the right problem and you can explain it to others. So, brush up on your communication skills. Learn to listen, to ask good questions, to write clearly, and to present clearly. Serious programming is a team sport, brush up on your social skills. The sloppy fat geek computer genius semi-buried in a pile of pizza boxes and cola cans is a mythical creature, best buried deep, never to be seen again. Por Bjarne Stroustrup

A citação acima foi retirada desta entrevista, mas me foi enviada por um dos Jedis da equipe da WebCo. Ela fala por si só e acho que o post acaba por aqui.

Que 2009 seja um ano de muito papo, muita cerveja e muito software!!!

Hey Ho!!!!