Testando a qualidade da rede da sua operadora

Há dois meses, o Eduardo Akira, amigo blogueiro e assíduo leitor do blog desde as remotas épocas do NokiaBR (e lá se vão mais de seis anos), me sugeriu um aplicativo para testar a rede da minha operadora de celular.

Sabe quando você acha que sua operadora não está prestando um bom serviço em algum ponto? Com esse aplicativo é possível provar para eles que o serviço está ruim e onde está ruim.

O programa se chama “Cellphone Coverage Map” e testa tanto a qualidade do sinal de voz quanto a velocidade de transmissão de dados (download e upload).

Com este app, ele e os colegas de trabalho dele conseguiram isenção de pacotes de dados da operadora dele, porque provaram que a internet móvel na cidade deles, para aquela operadora, estava morta ;).

Os links para download para iPhone e Android seguem abaixo, junto com as telas do programa rodando aqui no Rio de Janeiro no meu celular que usa a rede da Vivo.

https://itunes.apple.com/br/app/cell-phone-coverage-map/id399701910?mt=8

https://play.google.com/store/apps/details?id=com.rootmetrics&hl=pt_BR

IMG_0149

IMG_0145

IMG_0144

IMG_0143

IMG_0142

IMG_0141

IMG_0139

Primos na Espiral de Ulam

Uma das razões dos números primos serem tão legais se deve ao fato deles se comportarem de forma estranha. Eles parecem aleatórios.

Algumas vezes você tem longos espaços entre dois números primos e, de repente, como os ônibus, vêm dois de uma vez só. No entanto, no fundo no fundo, eles não são completamente aleatórios.

Um matemático Polonês chamado Stanislaw Ulam, que foi para os EUA pouco antes da Segunda Guerra Mundial, estava, depois da guerra, em 1963, assistindo uma apresentação de um trabalho chatíssimo e longo com um papel e uma caneta na mão e resolveu fazer a seguinte brincadeira para se distrair:

No centro do papel colocou o número 1 e foi fazendo uma espiral quadrada com a sequência, conforme a figura abaixo:
ulam1

Depois disso, começou a circular os números primos nesta espiral, conforme a figura a seguir:
ulam2

Ele ficou surpreso pelo fato dos números primos caírem em diagonais. Como todos os números primos, exceto o 2, são números ímpares e como as diagonais nesta espiral alternam entre pares e ímpares, não é surpresa que os números caiam em diagonais alternadas, mas que algumas diagonais tenham mais primos do que outras.

Pouco tempo depois ele resolveu fazer um programa usando o computador MANIAC II para imprimir pixels nos pontos primos (exatamente como eu fiz em vermelho no excel) e conseguiu fazer uma imagem com os números até 65.025 (255 x 255).

Aqui abro um parêntese para falar do MANIAC II.

Ele era um computador criado em 1957 com 4096 words de 48bits (24kbytes) de memória RAM em Magnetic-core Memory e 12288 words de 48bits (576kbytes) em Williams tubes. Em média, uma multiplicação neste computador demorava 180 microsegundos e uma divisão 300 microsegundos. Uma verdadeira eternidade para os tempos de hoje.

Voltando à espiral do Ulam, o que ele conseguiu com a impressão da matriz de 255 x 255 de pixels foi a confirmação do que ele havia visto com 100 números. Realmente há um padrão no qual os números primos aparecem em diagonais, com intervalos, é claro, e algumas diagonais parecem ter mais primos do que outras.

ulam-255x255

Todas as linhas nesta espiral obedecem à seguinte equação quadrática: 4x^2+bx+c

Por exemplo, a diagonal que começa no número 3 tem a seguinte equação: 4x^2-2x+1
3, 13, 31, 57, 91, … (Confira na imagem acima)

Na prática, há uma hipótese de que estas diagonais podem servir para procurarmos números primos grandes, já que algumas diagonais têm mais primos do que outras diagonais. Melhor dizendo, algumas equações quadráticas têm mais chance de retornar números primos do que outras.

Um exemplo de diagonal com 40 números primos em sequência é a seguinte: x^2-x+41 que gera a seguinte sequência de 40 números primos:

41, 43, 47, 53, 61, 71, 83, 97, 113, 131, 151, 173, 197, 223, 251, 281, 313, 347, 383, 421, 461, 503, 547, 593, 641, 691, 743, 797, 853, 911, 971, 1033, 1097, 1163, 1231, 1301, 1373, 1447, 1523, 1601 (O 41o número é igual a 41^2 e, portanto, não é primo)

As diagonais com as maiores densidades de números primos conhecidas são a belezuras abaixo:

x^2 + x + 3399714628553118047

e (desculpe, não cabe na tela)

x^2 + x + 332518109806968781031500852571295088573128477514981900349983874538507313

O que interessa nisto tudo, é que, parece que, há fórmulas com mais densidade de primos do que outras (isso ainda não foi provado) e isto pode ajudar a resolver outros problemas, como a hipótese de Goldbach (que diz que todos os números pares maiores do que 2 podem ser expressados pela soma de dois números primos) ou a hipótese da existência de infinitos números primos gêmeos.

Como não poderia faltar, eu fiz uma implementação em javascript para mostrar esse grid, só que em vez de 255 x 255, o grid que eu fiz é de 1000×1000. O resultado está neste link. Obviamente você pode aumentar o tamanho do canvas para gerar coisas grandes, como essa de 25.000.000 de números (5000 x 5000) que eu fiz usando o mesmo código (Clica que aumenta).

ulam-5000x5000

 

Edição das 11:50 (Não podia faltar o código Python. O @jbvsmo depois dirá que está lento….)

#!/usr/bin/env python
import sys,math
import Image
 
size = int(sys.argv[1])
 
def sieveGen(siz):
    l = [2,3,5,7,11,13,17,19,23,29]
    if (siz < 31):
        return l
    for i in xrange(31,siz,2):
        isP = True
        rT = math.sqrt(i)
        for j in l:
            if i%j == 0:
                isP = False
                break
            if j>rT:
                break
        if isP:
            l.append(i)
    return l
 
mySieve = sieveGen(size)
 
 
def isPrime(n):
    if (n == 1):
        return False
    if (n < size):
        return (n in mySieve)
    isP = True
    sqrtN = math.sqrt(n)
    for j in mySieve:
        if (n%j)==0:
            return False
        if (j>sqrtN):
            return True
    return True
 
 
 
 
def spiral(N):
    im = Image.new("RGB", (N, N), "white")
    pix = im.load()
    red = (255,0,0)
    if(N%2):
        x = y = ((N-1)/2)
    else:
        x = y = (N/2)
    N2 = N*N
    dx = 1
    dy = 0
 
    val = 1
    amp = 1
    c = 0
 
    while (val <= N2):
        mvd = 0
        while ((mvd < amp) and (val <= N2)):
            if isPrime(val):
                pix[x-1,y-1] = red
            x += dx
            y += dy
            mvd += 1
            val += 1
 
        c += 1
        if (c == 2):
            c = 0
            amp += 1
 
        if (dx == 1):
            dx,dy = 0,1
        else:
            if (dy == 1):
                dx,dy = -1,0
            else: 
                if (dx == -1):
                    dx,dy = 0,-1
                else:
                    if (dy == -1):
                        dy,dx = 0,1
    im.transpose(Image.FLIP_TOP_BOTTOM).save("ulam.png")
 
spiral(size)

Estimando Pi com agulhas e linhas

Há alguns dias, assisti a um vídeo muito legal que mostrava que era possível estimar Pi pelo número de vezes que uma agulha cruzasse linhas verticais num tabuleiro no qual as linhas verticais fossem separadas por uma distância igual ao dobro do tamanho da agulha.

Para testar o que o sujeito fez no vídeo com fósforos, no lugar de agulhas, fiz um programinha em Javascript que deixo abaixo. Como o Javascript não é uma linguagem muito apropriada para isso, não esperem muita precisão nem muita performance. No final do post mostro uma solução mais elegante.

Atenção não coloque mais de 1.000.000 de agulhas ou seu browser pode travar.

Esse método de estimar Pi, é baseado no problema da agulha de Buffon, que foi proposto lá pelo século XVIII, pelo matemático francês Conde de Buffon.

A proposição diz o seguinte: Dada uma agulha com comprimento l e um assoalho com tábuas de largura t, a probabilidade de se jogar uma agulha no chão e ela cair sobre uma junção de tábuas é \frac{2l}{t\pi}.

Se l = \frac{t}{2}, então a probabilidade da agulha cair sobre uma junção é \frac{1}{\pi}

Portanto, se jogarmos N agulhas no chão e o número de agulhas que caírem sobre as junções for h, poderemos aproximar \pi pela fração \frac{N}{h}.

A demonstração dessa probabilidade você encontra aqui. Coloquei o link da Wikipedia em inglês porque essa página na Wikipedia lusófona está muito ruim.

Não satisfeito com a implementação porca que eu fiz em Javascript, o Pedro Paulo resolveu fazer uma muito mais eficiente e elegante em python, que deixo abaixo:

#!/usr/bin/env python
import math, random
 
def generateNeedles (n):
    cross = 0
    for i in xrange(n):
        x = random.random()
        theta = random.random()*(math.pi/2.0)
        if ((x + 0.25*math.cos(theta)) >= 1.0):
            cross += 1
        else:
            if ((x - 0.25*math.cos(theta)) <=0.0):
                cross += 1
    return cross
 
needleCount = 30000000
cross = generateNeedles(needleCount)
print cross,needleCount, needleCount / float(cross)

Ao executar o script acima obtive os seguintes resultados:

30.000 agulhas 3.13217790771
300.000 agulhas 3.14261171985
3.000.000 agulhas 3.14226609757
30.000.000 agulhas 3.1423348868

Esse Conde de Buffon deve ter perdido muita agulha deixando cair entre uma tábua e outra do piso de casa, só pode… 🙂

CAPTCHAS eficientes e CAPTCHA ruim

Não se preocupe se você não sabe o que significa CAPTCHA. Na prática, são aquelas letrinhas embaralhadas que quase todo formulário de cadastro ou votação online têm.

E para que serve aquele negócio que atrasa a nossa vida?

Serve para impedir que um computador consiga preencher o formulário sozinho, uma vez que ele não vai conseguir entender aquelas letrinhas dentro da imagem. Isso impede que robôs enviem milhares de mensagens ou votem milhões de vezes numa pesquisa online.

Quanto mais embaralhadas forem as letras na imagem, melhor.

Ah, e precisa ser uma imagem, porque se for texto, o computador não faz nem esforço, como é o caso do site de uma das maiores operadoras de telecomunicações do Brasil, que coloca os números do CAPCHA em texto, e ainda coloca os dados na página escondidos num campo “hidden”! Isso não dura 1 segundo na mão de um script feito por um garoto de 10 anos.

Você está fazendo isso errado...

Não vou dizer qual foi a operadora, mas acho que você consegue descobrir. 😉

Outra maneira interessante de fazer um CAPTCHA é exibir uma pergunta simples, mas em linguagem natural, por exemplo:

  • Qual é o triplo de dois?
  • Quais são as vogais da palavra piauiense?
  • Quanto é dois mais sete?
  • A palavra travesseiro começa com qual letra?

Se você tiver uma lista grande de perguntas como essas, e for exibindo de forma aleatória, isso funciona da mesma forma que as imagens do CAPTCHA.

Atualmente o CAPTCHA mais usado por aí se chama reCAPTCHA, inventado por um sujeito chamado Luis von Ahn, que descobriu uma maneira muito simples de pessoas irem convertendo livros digitalizados em texto e ainda fazer isso servir como CAPTCHA.

Como funciona? Há um projeto grande de digitalizar jornais muito antigos e convertê-los em texto através de OCR. O problema é que algumas partes do texto ficam ilegíveis para o OCR e a tradução dessas palavras de imagem em texto sai errada. Veja abaixo:

sample-ocr

Nós conseguimos perfeitamente identificar o texto “This aged portion of society were distinguished from”, mas o computador não. Dessa forma, o que ele faz é partir a imagem do texto em palavras e exibir para as pessoas traduzirem aquilo para texto, no CAPTCHA.

recaptcha

Agora, se ele não sabe o que significam as palavras, como ele faz para saber se você digitou certo as palavras da imagem?

Por esse motivo ele sempre coloca duas imagens juntas. De uma ele sabe o significado, da outra não. Se você acertar uma, provavelmente tentou acertar a outra. Quando um número X de pessoas disse a mesma coisa para aquela palavra, ele guarda aquilo como o texto referente àquela palavra.

E assim vão digitalizando jornais e livros antigos…

Fica aqui uma dica para o sujeito que fez o site da operadora de telefonia: O reCAPTCHA é gratuito e funciona 10 mais 11 vezes melhor do que o seu CAPTCHA feito em texto. 😉

Acelerando o emulador de Android no Mac e no Windows

Executar o emulador de Android no Mac em qualquer sistema operacional é terrível.

Você abre o programa, espera, espera, espera, espera, espera, espera, espera, espera, espera, espera, espera, espera, …….(parece que vai abrir)……, espera, espera, espera, espera e ele abre. Aí manda ligar, espera, espera, espera, espera, espera, espera, espera, espera,… Bom você já sabe, né?

Procurando uma solução para isso, encontrei esse post aqui, que fala como resolver o problema para o 4.0.3, mas funcionou para mim também com o 4.2.2.

Os passos a seguir são para o Mac, mas funcionam também para o Windows com algumas mudanças.

Passo 1

Abra o Android SDK Manager e procure por “Intel Atom x86 System Image” dentro de Android 4.X.X.
Obs.: Também tem um dentro de 2.3.3 se você quiser testar no Gingerbread também.

Passo 2

Faça o download do “Intel Atom x86 System Image” e espere terminar de instalar.

Passo 3

Vá para a pasta /extras/intel/Hardware_Acceleration_Execution_Manager/ e abra o arquivo haxm-macosx_r02.dmg (IntelHaxm.exe no Windows). Dentro dele há um IntelHAXM_1.0.1.mpkg. Execute o programa.

No Windows, se o programa reclamar que a virtualização não está ativada. Você vai ter que ativá-la na BIOS do seu computador (Procure no Google como ativar para a sua BIOS).

Passo 4

Siga os passos do instalador e escolha a quantidade de RAM que você deseja reservar para o emulador. Para mudar isso depois, basta executar esse instalador novamente. Não abuse desse valor para não deixar seu Mac lento enquanto estiver usando o emulador.

Passo 5

Feche o Android SDK Manager e abra-o novamente. Isso não tem no tutorial original, mas comigo só funcionou depois de fazer isso.

Passo 6

Abra o AVD Manager e crie um novo Device.
Escolha “Android 4.X.X – API Level XX” (onde XX corresponde à sua versão instalada).
Na parte de CPU/ABI, escolha “Intel Atom (x86)”
Marque o checkbox “Use Host GPU”
Deixe desmarcado os “Snapshots”. (Ou você usa Snapshots ou a GPU).

Passo 6

Use o emulador e seja feliz.

Passo 7

Use o tempo livre que você acaba de ganhar para fazer algo de útil ou ajudar alguém. 🙂

Dica para atualizar o seu Lumia para Windows Phone 7.8

Ontem tentei atualizar o meu Lumia 710 do Mango (Windows Phone 7.5) para o Windows Phone 7.8 e o Windows Phone Connector do Mac não achava nenhuma atualização.

Procurei em vários lugares e todos diziam que para forçar a atualização precisava fazer isso no Zune (Windows).

O blog que ensinava com mais detalhes o processo dizia que era preciso ser paciente porque o método nem sempre funcionava de primeira e precisava tentar até funcionar. Tentei umas 5 ou 6 vezes até o primeiro sucesso e tive que fazer tudo no Windows mesmo.

Depois tive que repetir o processo mais 2 vezes porque na primeira atualização e na segunda ele ainda foi para versões do Windows Phone 7.5. Na terceira e última ele subiu para o 7.8. Nenhuma das vezes funcionou de primeira, por isso repito o conselho do blog que eu li, tenha paciência e persistência.

lumia_710_7_8

Vamos aos passos. Se não funcionar, continue tentando que uma hora funciona. Acredite.

0. Se você está num Mac, arrume um Windows (sem choro!).
1. Abra o Zune
2. Antes de conectar o celular, desative a rede de dados celular e o wifi.
3. Conecte o celular na porta USB do computador.
4. Clique em configurações (lá em cima) e depois atualizar
5. Deixe o programa dizer que não há atualização para seu celular. Se ele disser que tem atualização, sorte sua!
6. Clique na opção de menu que fica abaixo de atualizar (ou qualquer outra), para sair daquela tela.

Agora vem o pulo do gato:

7. Clique novamente em atualizar e, o mais rápido que puder, desligue a conexão do seu computador (tirando o cabo de rede ou desativando o wifi).
8. Se tudo der certo, vai aparecer um botão dizendo que há atualização. Ligue novamente a internet do computador, siga os passos e atualize seu celular.
9. Caso apareça uma mensagem dizendo que não foi possível encontrar um servidor ou não foi possível atualizar, volte para o passo 4 e repita o processo até funcionar.

Depois de atualizar o celular, se ele ainda não tiver subido para o 7.8 (7.10.8858), desconecte o celular da USB e repita o processo.

Lumia_710_7_8_2

Garota sem Fio de volta à ativa

Na época que eu tinha um Compaq Aero 1500 (era parecido com um Palm, mas da Compaq e rodava Windows CE), lá se vão muitíssimos anos, bem antes de eu sonhar em escrever um blog, eu conheci o site da Bia Kunze, “Garota sem Fio”.

Eu lia todos os posts e ficava impressionado com o entrosamento daquela dentista com a tecnologia (O domínio do site ainda era odontopalm.com.br). Tirava o chapéu ao ler coisas do tipo fazer hotsync do Palm para baixar os e-mails via internet discada num celular Sony Ericsson T3! (Tá, eu abusei das velharias com as expressões, Baixar e-mail, Hotsync, Palm, internet discada e Sony Ericsson T3, mas eu me lembro de um post exatamente assim)

Um tempo depois eu criei o finado blog NokiaBR e, através dele, conheci mais de perto muita gente que eu admirava e que eu nunca imaginava conhecer, dentre essas pessoas, a Bia Kunze (a Garota sem Fio).

No episódio do fechamento do NokiaBR, ela me deu uma força muito grande, divulgando o novo blog, o Zeletron, e reclamando muito da decisão da Nokia. Nem tenho como agradecer por aquilo. Na época eu nem sabia que ela já estava com problemas de saúde sérios e mesmo assim me ajudou bastante!

Pois bem, a Bia Kunze vem desde 2010 passando por uma série de problemas de saúde gravíssimos, mas conseguiu dar a volta por cima e, nos últimos meses, vem fazendo progressos enormes na sua recuperação a ponto de virar uma atleta (corrida e remo)!

Hoje ela fez um post sobre sua doença e recuperação. Vale a pena visitar o blog dela e ler o post. Deixo o link abaixo.

http://www.garotasemfio.com.br/blog/2013/01/31/minha-historia/

Aproveito o post para parabenizá-la pela recuperação e de dizer que estávamos aqui todos rezando e torcendo pelo restabelecimento da sua saúde o quanto antes.

Palavra do dia, Geocoding

Imagine que você tem um banco de dados grande de pontos de interesse (padarias, lojas, restaurantes, escolas, monumentos, museus, etc.) com as posições geográficas (latitude e longitude) de cada um e deseja saber qual deles está mais próximo de um certo endereço.

Sabendo a latitude e longitude do endereço, descobrir a distância em “linha reta”, na verdade é um arco, entre cada ponto é uma conta bem simples.

Distância entre duas coordenadas geográficas

Onde  e são respectivamente as latitudes dos dois pontos, é a diferença das longitudes e S é o arco que queremos descobrir. Para saber a distância em km, é preciso multiplicar o valor de S pelo raio da Terra, que, na média é igual a 6367,5km.

Por exemplo, suponhamos que quiséssemos saber a distância entre a Torre Eiffel (48.8582780, 2.2942540) e o museu do Louvre (48.86063610, 2.33760960) em Paris.

= 48.8582780˚ = 0.852737818rad
= 48.86063610˚ = 0.852778975rad
= (2.33760960 – 2.2942540) = 0.0433556˚ = 0.000756697969rad

cos(S) = sin(0.852778975) * sin(0.852737818) + cos(0.852778975) * cos(0.852737818) * cos(0.000756697969) = 0.99999987523

Srad = acos(0.99999987523) = 0.000499539793

Skm = 0.000499539793 * 6367.5 = 3.18km

Antes que me xinguem, esta conta não é muito precisa, visto que o raio da Terra não é constante e a Terra não é uma esfera, mas é uma boa aproximação e serve para podermos comparar distâncias.

Então o problema está resolvido, diria um leitor mais afoito. Infelizmente, não. A pergunta é: “Como eu sei que a posição da Torre Eiffel é (48.8582780, 2.2942540)?”

Para isso, precisamos saber como descobrimos a latitude e longitude de um certo endereço (Ex.: Av. Nações Unidas, 12.901, São Paulo, SP) ou local (Tour Eiffel) para podermos resolver o problema. A ação de converter um endereço em latitude e longitude é chamada de “Geocoding”

Algum esperto poderia dizer de gozação: “Ah, procura no Google!” e eu responderia que ele estava certo. O Google disponibiliza gratuitamente um serviço de Geocoding que resolve esse problema, mas tem algumas limitações. A maior delas é o limite de 2.500 buscas por dia, e também a restrição de ter que exibir o resultado da busca num mapa. O endereço de busca é o seguinte:

http://maps.googleapis.com/maps/api/geocode/json?address=[Endereço]&sensor=false

Existem outras soluções gratuitas, como o Bing Maps, o Mapbox e o OpenStreetMaps, dentre outras.

Este último é o único que realmente é gratuito e sem limites, se você quiser hospedar os dados num servidor próprio. O problema é que os dados e o sistema de Geocoding do OpenStreetMaps, chamado de Nominatim, do planeta inteiro ocupam aproximadamente 600GB de HD e sugerem um servidor com 32GB de RAM para rodar bem. Caso contrário, eles sugerem usar um serviço hospedado em sites de terceiros.

Eu encontrei no site da Mapquest, um serviço gratuito de Geocoding, baseado no Nominatim, que parece não ter as limitações do Google.

O endereço é http://open.mapquestapi.com/nominatim/#search_basic

Ainda não sei qual serviço vou usar no projeto que estou terminando, mas estou tendendo a usar este último.

E você? Já fez algum projeto usando Geocoding? Tem alguma dica para passar? Deixe seu recado nos comentários!

Atualizou hoje seu Mountain Lion? Perdeu os Applets Java no browser.

Interrompo brevemente meu silêncio forçado pela quantidade de trabalho, para falar de um problema da atualização de hoje do Mac OS X Mountain Lion.

Depois que eu atualizei meu Macbook hoje, não consegui mais entrar no site de nenhum banco. Desconfiado da atualização, fui ver o que ela trazia de novidade (Eu sei, devia ter feito isso antes de instalar) e, para minha surpresa, ela dizia simplesmente o seguinte:

http://support.apple.com/kb/HT5493
This update uninstalls the Apple-provided Java applet plug-in from all web browsers. To use applets on a web page, click on the region labeled “Missing plug-in” to go download the latest version of the Java applet plug-in from Oracle.”

Ou, na minha versão, “Retiramos o plug-in do Java que já estava pré-instalado pela Apple para todos os browsers. Se quiser usar alguma coisa com Java, baixe novamente no site da Oracle”.

A solução para essa baboseira que a Apple fez, é justamente baixar de novo o Java, que já tem uma atualização para corrigir essa “atualização” da Apple.

http://www.java.com/en/download/mac_download.jsp?locale=en

Já não é a primeira vez que eles fazem uma coisa dessas.

Vou te contar, a Apple está cansando minha beleza…

Troquem as opções nome do mascote da Copa!

Meu falecido avô materno, quando solteiro, morava na Piedade, um bairro do subúrbio do Rio. Ele contava que antigamente aquele bairro se chamava Gambá e que houve um abaixo-assinado com o seguinte título: “Troquem por piedade o nome deste bairro”. Não sei se foi gozação do Prefeito ou de algum vereador da época, mas o pedido foi aceito ao pé da letra e mudaram para Piedade.

Lembrei desse caso que meu avô contava porque precisamos impedir que dêem qualquer um dos três nomes sugeridos para o lindo tatu-bola que fizeram para o mascote da Copa de 2014.

As geniais opções são as seguintes:

1) Amijubi, uma contração de Amizade + Júbilo (Alguém ouviu mijo?);
2) Zuzeco, outra mistura só que de Azul + Ecologia (Vai ter mãe dizendo pro filho “Zuzeco facho menino!)
3) Fuleco para Futebol + Ecologia (Seria o Cebolinha falando Furreco?)

Ninguém, além dos criadores desses nomes, gostou dessas sugestões. Por isso, a nossa amiga Elis Monteiro resolveu criar um abaixo-assinado virtual para tentarmos impedir esse atentado ao pobre tatu-bola.

Se você ainda não assinou, assine já. Deixo o link abaixo:

http://www.avaaz.org/po/petition/Queremos_um_nome_decente_para_o_Mascote_da_Copa_2014/

Outra mancada da Nokia – Baniu do Nokia Dev o criador do Gravity

Pois é moçada, parece mesmo que a Nokia não consegue ficar muito tempo sem soltar um “fogo amigo“.

O último a receber uma bordoada da Finlandesa foi o alemão Jan Ole Suhr, mais conhecido como o desenvolvedor do Gravity, o melhor cliente de Twitter feito para Symbian. Na minha opinião, ele é melhor do que qualquer outro por aí.

Contatado pela Nokia sobre sua intenção de portar o Gravity para Windows Phone, o rapaz disse que não tinha intenção de portar, uma vez que não via um retorno financeiro razoável que justificasse o trabalho de portar e manter o aplicativo para Windows Phone.

Por causa dessa negativa, a Nokia baniu o sujeito do programa Nokia Dev, mesmo ele sendo um campeão de vendas na Ovi Store com o Gravity.

Quem já usou o Gravity pelo menos por um tempo, sabe que ele é um excelente cliente para Twitter e que ele é continuamente atualizado com correções de bugs e novas funções. O programa é muito bem cuidado, mas também é muito bem pago. Uma licença do Gravity custa a “bagatela” de R$ 18,00 (segundo minha pesquisa na Ovi Store). E você reclamando em pagar US$ 0,99 por um Angry Birds…

Enfim, o desenvolvedor achou que não teria condições de manter uma versão no Windows Phone da mesma forma que ele mantém a do Symbian e, por causa disso, tomou um “ban” da Nokia.

O negócio pegou mal e a Nokia, reparando na besteira que havia feito, tentou chamar o sujeito de volta oferecendo a ele um Lumia de graça e um e-mail de desculpas tosco assim: “Desculpe, você pode voltar quando aprender a desenvolver para Windows Phone 7”. O resultado dessa lambança é que ele agora está pensando em portar o Gravity para iPhone e Android.

Deixo abaixo uma conversa do Jan Ole sobre o assunto no Twitter.


Quem ganha com isso? Os usuários de Android e iPhone, que poderão ter um cliente decente de Twitter. Só perdeu com isso a Nokia, que teve mais uma vez a imagem arranhada por um fogo amigo.

Desenvolver aplicativos para Android requer uma certa dose de loucura

Off topic: Antes de mais nada, gostaria de me desculpar pela falta de atualização do blog no último mês. Este foi o segundo mês com menos posts de toda a história do blog (O primeiro foi o fatídico mês de janeiro de 2010 quando o NokiaBR foi fechado e tive que me organizar para continuar blogando). Andamos todos bastante ocupados com nossos trabalhos que não conseguimos escrever o quanto gostaríamos. Também acho que o Mobile Analyst anda comendo tanto ovo cozido na Cinelândia que se esqueceu de nós…

Mas vamos ao que interessa. Android. Plataforma aberta. Milhares de opções de aparelhos. Isso é bom para o usuário (tenho minhas dúvidas). Mas será que é bom para o desenvolvedor?

Venho desenvolvendo há alguns anos aplicativos para iOS e, no ano passado aqui na empresa começamos a portar alguns dos nossos aplicativos e jogos para Android. Para nossa surpresa, desenvolver um aplicativo no Android que funcione em todos os aparelhos requer muita paciência porque várias coisas que funcionam para uma versão do sistema não funcionam em outras versões. Às vezes, coisas que funcionam no 2.3 não existem no 2.2 e coisas do 2.3 não funcionam da mesma maneira no 3.0, e assim por diante. É preciso testar o programa no máximo de aparelhos que você consiga, o que é inviável.

Para completar a guerra, existe um número absurdo de tipos de tela (dimensões x densidade de pixels x orientação). Telas quadradas, telas verticais, telas horizontais, resolução baixa, resolução média, resolução alta, resolução extra alta, cada uma dessas com suas peculiaridades.

A cereja desse bolo é a chamada “customização” dos fabricantes e operadoras, que pode deixar a guerra ainda mais complicada para o desenvolvedor.

Os defensores do Android dizem que essa fragmentação é uma qualidade e não um problema. Garanto que quem diz isso nunca desenvolveu nada para Android ou nunca teve que responder a um cliente que vem reclamar que o seu aplicativo não roda no aparelho dele que tem tela hexagonal e nem no do amigo dele que tem tela elíptica em landscape. 🙂

Outro dia li num post do TechCrunch que um desenvolvedor chamado Animoca, chega a testar os seus aplicativos em 400 aparelhos diferentes (parte deles na foto abaixo).

E outro, esse eu li no Ars Technica, que diz já ter identificado 4.000, QUATRO MIL, modelos de aparelhos diferentes rodando um aplicativo dele (gráfico abaixo). Outra curiosidade que esse desenvolvedor revelou, é que nesses 4.000 modelos de aparelhos, ele descobriu quase 600 fabricantes diferentes! 599 para ser mais preciso.

Com os nossos aplicativos acontece exatamente a mesma coisa. Temos o exemplo do jogo “Manobrista Maluco“, que é sucesso no iOS e também no Android, que tem mais de 850.000 downloads no iOS e pouco mais 145.000 downloads no Android (a versão Android tem quase dois anos a menos).

O gráfico de aparelhos que usam esse jogo é o seguinte:

Como podemos reparar, somente 46% dos downloads estão concentrados em 9 aparelhos. Os outros 54% estão distribuídos em aparelhos que individualmente participam com menos de 2,6% do total. Se quiséssemos atender à maioria dos usuários, teríamos que testá-lo em centenas de aparelhos diferentes.

Hoje recebemos da Amazon um e-mail informando que o Manobrista Maluco não foi aceito para ser publicado na loja de aplicativos do Kindle Fire. Segundo eles, o jogo não se adapta às dimensões de tela do Kindle Fire. Teremos que adaptar o jogo para o Kindle se quisermos publicá-lo na loja da Amazon.

Cada vez mais vemos aparelhos com Android sendo vendidos nas mais variadas versões do sistema e com as mais diversas disposições de tela. Outro dia alguém me mandou uma foto de um flagra de uma loja de celulares vendendo aparelhos com Android com a versão 1.6 ainda! Isso sem falar dos Xing-Lings dos camelódromos que de MP10 viraram num passe de mágica aparelhos com Android.

Enfim, gostaria de saber se outros desenvolvedores de aplicativos para Android compartilham dessa opinião e o que eles fazem para contornar esse problema, além de testar os seus programas em N+K aparelhos.

Mario Kart para gente grande

O nome do veículo é ChibiKart e foi feito por alunos do MIT. É como um carrinho de rolimã, só que ele sobe ladeira. 🙂

Ele tem 4 motores que ficam diretamente nas rodas e fazem o kart chegar a 30km/h (Duvido que chegue a essa velocidade comigo em cima, mas tudo bem).

Já falei muito! Vejam o vídeos abaixo.

Página do projeto: http://www.etotheipiplusone.net/?page_id=1987