Enter u.nu, arguably the shortest URL shortener in town - which, unfortunately, does not come with a one-click shortening option like bit.ly's bookmarklet. It does, however, offer an API, with which I quickly hacked a minimalistic bookmarklet.

Just drag and drop the link below to your browser and turn anything in your browser into a short URL with a single click:

u.nu <- drag that to your browser's toolbar.

UPDATE: Real stupid mistake - forgot to escape the URL (but hey, I told it was a quick hack :-P ) - fixed now (Feb 9, 2010).

Para quem se interessa pela parte operacional da coisa, escrevi na época uma série de posts detalhando as técnicas utilizadas no mashup – vale lembrar que isso foi feito em 2008, e hoje devem existir outras bibliotecas e plugins mais avançados para fazer a mesma coisa no Ruby on Rails.

A escolha do fórum foi um misto de brincadeira e de experiência social. Não tenho nada contra a atividade proposta (para mim, recai na linha “se é consensual e não afeta ninguém de fora, que mal tem?”), mas não é exatamente a minha praia – razão pela qual passei o site adiante, não tendo hoje qualquer ligação com ele.

Os atuais proprietários (em seu pleno direito) optaram por simplificar o visual, removendo informações sobre o desenvolvimento e a repercussão na mídia. No entanto, eu achei essa mesma informação aqui e resolvi (re-)reproduzir só para preservar:

O bitchmaps é um experimento de geotagging/ mashup , motivado pela enorme quantidade de endereços físicos de acompanhantes/estabelecimentos nos fóruns do site GPGuia , que poderiam ser facilmente visualizados num mapa se fossem processados e disponibilizados no formato KML.

Os botões abrem os resultados no Google Maps, e os abrem no Google Earth (ou outro programa compatível com KML que você tenha). Usuários do iPhone ainda podem digitar a URL da cidade (incluindo o “http://”) na caixa de busca do iPhone Maps.

Informações Técnicas

O sistema de captura foi desenvolvido usando Ruby On Rails, devido às facilidades oferecidas pela linguagem e pelo framework, tais como o Hpricot (usado para localizar os links no site) e o GeoKit (que faz a consulta nos sistemas de geotagging).

Os arquivos .kml de cada cidade são gerados com base nos resultados obtidos por estas ferramentas, e a versão compactada (.kmz) é servida no site (com um rewrite simples para encurtar as URLs).

Os endereços são identificados por uma expressão regular, considerando a cidade/estado referenciados pelo fórum. A eficácia depende da qualidade da formatação destes endereços no título do post. Algumas cidades não foram representadas por terem endereços pouco convencionais (ex.: Brasília), outras porque os posts raramente ou nunca apresentam endereços no título. A atualização tem periodicidade indefinida.

Avisos Importantes

Este site ou seus desenvolvedores não têm qualquer conexão com o GPGuia. ou com qualquer um dos softwares, aparelhos ou sites mencionados, tampouco com as empresas ou pessoas que os desenvolvem ou representam. O uso das informações é livre, respeitando restrições que as fontes eventualmente venham a impor. Não assumimos qualquer responsabilidade pela veracidade ou precisão das informações, tampouco corroboramos qualquer finalidade de uso das mesmas.

Salientamos que nosso objetivo não é desviar tráfego do GPGuia. Ao contrário: o mapa permite que os posts sejam alcançados de forma mais interativa (todos os pontos no mapa dão link para os posts que os originaram). O que queremos aqui é mostrar o potencial do geotagging para fazer a ponte entre os amplos recursos de mapeamnto existentes na rede e as mais diversas fontes de informação.

Créditos e Agradecimentos
A idéia inicial e a programação foram do Chester – com uma grande ajuda do Andre Cardozo, que deu o caminho das pedras das bibliotecas. O Felippo criou o logo/visual e a Dani Valentin fez a página. O Roudi bolou o nome (e uma tonelada de idéias para o futuro), e mais um monte de gente ajudou com sugestões, testes e conselhos.

Repercussão
Mídia: Folha de São Paulo · Folha Online · O Globo Online · Terra · UOL Tecnologia (GigaBlog)

Blogs: Antena Paranóica · Bazar 21 · blog.zoom.fot.br · Bobagento · Boteco Sujo · Descascar Alho · Quero te Contar · Site da Morróida · Steffania Paola Blog · Update or Die · Vídeos Espetaculares · Zé Guardinha

Outros: Twitter · Orkut · del.icio.us (en) · BlogBlogs · Ueba · Gafanhoto · hardMOB · GPGuia

Antes de mais nada: ao contrário do que a apresentação da API SMS multi-linguagem dava a entender, a idéia inicial da plataforma não é disponibilizar aplicações server-side baseadas em SMS. Isso é tecnicamente possível, mas a idéia é realmente algo nos moldes da App Store da Apple, isto é, um marketplace para que as pessoas comprem e baixem aplicativos sem as complicações de download e pagamento tradicionalmente envolvidas nesse tipo de operação.

O público consiste em assinantes Vivo cujos celulares rodem aplicações Java (JME). Pode parecer restritivo, mas fazendo as contas, estamos falando de algumas dezenas de milhões de clientes potenciais nessas características (segundo a própria Vivo). Com um detalhe: tudo em português, direto no celular, e debitando na conta – ou seja, nada de cartão de crédito ou de exigir um celular de elite – as maiores barreiras entre o “jeito Apple” e o público brasileiro.

O outro aspecto comercial interessante é que, de fato, o desenvolvedor interage diretamente com a Vivo, com um processo bem definido para colocar sua aplicação no ar. Isso é, talvez, a parte mais revolucionária da proposta. Hoje em dia, um desenvolvedor que queira colocar suas aplicações à venda numa operadora precisa, necessariamente, passar por um intermediário.

Comparando com iPhone OS/Objective C (a única outra plataforma viável para desenvolvedores independentes), os aparelhos não têm todas as plumas e paetês (alguns até tem, mas se você quer um público amplo tem que abrir mão), mas a curva de aprendizado e o tempo/complexidade de desenvolvimento são maiores – em particular se você for cuidadoso com detalhes como gerenciamento de memória. Além disso, você desenvolve usando qualquer computador/sistema operacional, o que é outra vantagem em termos de custo.

Com essa perspectiva fica bem mais fácil entender as informações no site. No geral, o processo é:

1. Desenvolver a aplicação usando JME/Java. Se sua aplicação gerar envio de SMS, use as APIs – fora isso é uma aplicação JME absolutamente normal;
2. Submeter a aplicação à certificação como “beta”. A aprovação nesse processo já vai permitir colocar a aplicação à venda por R$ 0,99 ou R$ 1,99 (à sua escolha). Disso, 70% é seu. E do tráfego de SMS que a aplicação gerar, 10% também vai para o seu bolso;
3. Uma vez que a aplicação tenha sua viabilidade comprovada, ela pode ser submetida para o processo completo de certificação, no qual estará lado a lado com as aplicações dos grandes vendedores (a preços equivalentes).

Assim como o sistema, o processo ainda está sendo desenhado e implementado – o passo 2 só rola a partir de Março. Mas não é nada viajante como roubar cuecas para obter lucro, e os caras estão realmente abertos a feedback.

Se vai dar certo, só o tempo dirá – mas é a chance que eu queria ter tido em 2005, quando comecei a desenvolver o miniTruco. Na época nenhuma integradora com que conversei se interessou: eles consideravam os gráficos minimalistas como “defeito” – sendo que isso foi feito propositalmente para garantir a universalidade e evitar telas de loading que tanto me irritam nos jogos tradicionais. Hoje, isto é, 300 mil downloads depois, eu suspeito que estava com a razão…

A notícia (TI Inside) me deixou salivando: potencialmente a coisa permitiria publicar apps sem o envolvimento de terceiros (como na App Store), mas cobrando direto na conta telefônica – só isso já merece alguma consideração.

O processo começa com a abertura de um cadastro e leitura da documentação das APIs – que são chamadas externamente (ou seja, seu aplicativo não roda no celular, e sim no seu próprio servidor), e consistem no envio de SMS, MMS e WAP Push (que é, grosso modo, o envio de um link para um conteúdo WAP) através de uma API REST (que cheira a SOAP com uma capinha REST por cima, apesar de contar com conversão implícita de JSON), com bibliotecas prontas para PHP, Java e .Net – mas, claro sendo REST, qualquer linguagem vale.

Pode parecer pobre em comparação, digamos, com apps iPhone, mas aplicações baseadas em SMS rodam até mesmo nos celulares mais modestos – eu lembro que, quando vi um pager pela primeira vez, minha primeira reação foi “cara, eu muito faria um adventure de texto rolando nessa parada”. De repente um miniTruco baseado em SMS… idéias mil.

Dei uma olhada na biblioteca Java. Ela é empacotada de maneira, digamos, pouco carinhosa (ex.: inclui o Jakarta Commons HttpClient como código-fonte, misturado com o código da API – provavelmente foi gerada por alguma ferramenta) e abre com um caminhão de issues no Eclipse. O mérito é que vem com uns exemplos (bem básicos) de uso, e os issues devem ser coisa fácil de resolver (depois eu vejo com calma).

Juntando o fato de as APIs só rolarem atualmente num sandbox com a quantidade de “em breve” no site, a primeira leitura é que o produto ainda está bem em construção – o link “modelo de negócio” ser um Flash com quatro slides explica muito sobre o estágio embrionário da empreitada enquanto produto. Dá pra encarar como risco (i.e., será que a plataforma vai pro ar?) ou como oportunidade (dá tempo de desenvolver algo e sair na frente).

E ficam no ar duas grandes dúvidas:

• As APIs só falam (numa leitura superficial que fiz até agora) em envio de mensagens. E o recebimento? A coisa só pode ser considerada uma aplicação autônoma se o usuário puder enviar SMS de volta, e não achei nenhuma API para que a app consiga receber respostas. Será que a idéia é fazer WAP Push, mandar o cara para o meu site e lá ele interagir para receber o próximo SMS?
• Quanto isso custa pro usuário? O artigo fala em porcentagens sobre o tráfego gerado, mas não diz quanto o usuário do aplicativo vai pagar por esse tráfego (se for preço normal de SMS, esquece – sai mais barato comprar um netbook pra jogar o adventure de texto :-P). E ainda fala em venda dos aplicativos, o que também é complicado: se o cara tiver que pagar pra baixar e pagar pra usar, só vai dar certo em um país onde as pessoas sejam conformistas a ponto de pagar imposto várias vezes sobre o mesmo produto… ah, tá, entendi.

Espero que as pessoas que foram à apresentação tenhma perguntado essas coisas e postem em algum lugar em breve. Também devo perguntar no fórum e ver no que dá. Eu sou sempre reticente com qualquer associação com operadoras de celular, mas numa primeira análise essa plataforma (quando e se ficar pronta) parece menos evil do que de costume. Vamos ver.

Isso sem contar que olhar sites antigos das pessoas é tão ou mais divertido do que olhar álbuns de fotos – experimente fuçar a vida online dos seus amigos (em particular a velha guarda) e vai entender o que eu estou falando.

Posto isso, ajuste o DeLorean rumo a 1997/98 (eu tinha uma versão anterior, mas essa foi a que eu achei), ignore links quebrados e acesse a…

Galeria Central
a home page do Chester

(sim, a gente falava desse jeito.)

Bônus: quem precisa de Google Maps? (não, eu não moro mais lá)

Minha primeira reação ao saber do imbróglio foi de espanto: o Google China foi vítima de uma invasão que procurava dados de contas de ativistas pró-direitos humanos – e é bem razoável acreditar que o responsável tenha sido o próprio governo. A empresa ameaça fechar sua página local (que pré-censura há anos seus resultados, de forma a agradar ao governo chinês) e até fechar as portas no país.

Ainda não tenho uma leitura definitiva disso – eu quero muito acreditar que é possível manter princípios éticos numa corporação desse tamanho, mas a ida deles à China me jogou um balde de água fria nessa idéia já há alguns anos.

Também não dá pra descartar que a majestade deles é diminuída pela sombra do Baidu, e há quem enxergue nisso uma jogada de transformar um prejuízo em ação de marketing/downsizing disfarçado (eu, pessoalmente, não compro muito essa idéia – não ao menos enquanto não tiver números confiáveis sobre o mercado de busca lá.)

Por ora, tudo o que se tem é um blog post. Vamos ver o que vai acontecer.

No site você acompanha os educativos ensinamentos e testemunhos de todos aqueles que encontraram a salvação na palavra. Seu conhecimento sobre temas como o budismo e a cultura oriental impressionam.

Se você gostar, ainda pode imprimir uma cópia em alta resolução do edificante cartaz abaixo (colorida ou preto-e-branco), colar no seu local de trabalho/estudo e ajudar na divulgação deste belo e revelador trabalho. Seus colegas irão agradecer pela alegria proporcionada.

Os veteranos costumam responder a essa pergunta vendendo suas linguagens prediletas em detrimento de outras, usando argumentos como tipagem, clareza, simplicidade, performance e tantos outros que nem sempre são tão objetivos quanto aparentam.

No entanto, a resposta que eu costumo dar (e que, por distração, não usei no programa) é “inglês”.

Pode parecer que falo isso porque trabalho com muitas empresas/pessoas de fora, mas não é verdade: o campo está em constante atualização, e as novidades relevantes quase sempre começam neste idioma, independente do país de origem.

Não ler inglês é ter que esperar pelas traduções; não escrever inglês é não participar. Pouco importa se você quer colaborar ou apenas consultar, os assuntos mais “enroscados” vão exigir alguma familiaridade com este idioma.

Sim, existem muitos livros traduzidos. Eu mesmo uso bastante (o custo e disponibilidade são um fator importante), mas a qualidade da tradução varia a ponto de tornar algumas passagens ininteligíveis para quem não tem como deduzir a intenção do autor.

Não estou falando (só) daqueles falsos cognatos que fazem doer a vista – um problema comum é a tradução livre de termos técnicos e expressões para formas que ninguém usa, muitas vezes a ponto de tornar a frase incompreensível – se eu dissesse que trabalho com logiciário, pouca gente ia se animar a falar de tecnologia comigo.

Resumindo, galera: antes de entrar nos ponteiros e closures, vamos para o básico: I am, you are, he is…

find . -type f | xargs -I {} sh -c 'iconv -f MACROMAN -t UTF-8 {} > {}.converted_from_iconv'; find . -type f | grep -v converted_from_iconv | xargs -I {} mv {}.converted_from_iconv {}

Funcionou no Mac OS X, e deve rodar bem em Linux/Cygwin também.

Mas acabei me surpreendendo: a energia do Tommy Tallarico (que apresenta as músicas, anima a galera e introduz um contraponto à orquestra com a guitarra empolgada) faz a coisa acontecer. Claro, depende muito da sua conexão emocional com os jogos cujas músicas estão sendo interpretadas: coisas que eu não joguei pareciam bem “yeah, whatever” – mas era só pintar algo mais familiar que eu me empolgava um pouco.

Uma das características do show é que eles estimulam fotos e filmes – e o HSBC Brasil mandou muito bem ao disponbilizar uma rede Wi-Fi. Isso me permitiu usar o Qik para filmar algumas músicas do evento, mais as tradicionais fotos e comentários no Twitter. (pena que eu só descobri que o Qik não usa o giroscópio do iPhone na metade – mas whatever, o que mais importava era a música mesmo.)

O evento deve duas interações com o público: uma quando chamaram um cara pra jogar Space Invaders de um jeito inovador (com um sistema que fazia tracking da imagem na camiseta dele, então ele tinha que correr pelo palco para mover a nave) e um cara que ganhou um campeonato de Guitar Hero e DETONOU no palco.

Enfim, a vergonha alheia passa logo nos primeiros minutos. Dali pra frente é uma maneira inovadora de ver música clássica. Ou de ver música de videogame.