Google Maps GPS Navigation finalmente disponível para Angola

Da utilidade do Google Maps nem adianta mais debruçar. O que não se entendia mesmo, era porque razão não era possível receber sugestões de voz sobre rotas em tempo real em Angola e diversos países Africanos, tendo como base, origem e destino, não usando as antenas de radio-frequência das operadoras telefônicas, mas sim o apurado GPS.

É uma tecnologia duma utilidade incrível. Uma vez dessas na Europa, vem um turista ter comigo a perguntar sobre uma rua que ele nao conseguia localizar com um mapa de papel, daqueles altamente confusos, onde você não sabe se esta a subir ou a descer, enfim. Perguntei a mim mesmo como era possível em pleno seculo 21 em plena Europa, e com um recurso como o Google Maps GPS Navigation acontecer aquilo. Para mim so podia mesmo ser por uma especie de nostalgia ou glamour Europeísta, só pode.

O Google Maps GPS Navigation te conduz aonde você deseja ir, e a margem de erro é minima.

Google-Maps-navigation

Google-Maps-navigation

Sim, agora com o uso deste sistema de posicionamento global é possível por exemplo receber orientações de voz sobre rotas, seja andando a pé, de táxi de kupapata ou de carro próprio.

Download aqui.

Como funciona o Google? (I)

Este é o primeiro duma serie de artigos que irei publicar, desvendando alguns ‘segredos’ do funcionamento desta espectacular plataforma de serviços que funcionam na Web. Dizemos que são ‘segredos’, porque a maior parte da informação que discutiremos convosco foi providenciada pela Google e está disponível a quem quiser. Óbvio que procuraremos usar uma linguagem mais simples possível, tecnicamente acessível a maior parte de nós. Estamos em crer que é bastante interessante o que temos para vos relatar.  A razão porque escolhemos a Google foi por termos verificado que esta corporação que iniciou numa sala dum laboratório universitário em Stanford, tornou-se poderosa, a ponto de consagrar-se um provedor de telecomunicações, publicidade, entretenimento, computação e acima de tudo começa a assumir posições de padronizador/dinamizador em campos de pesquisa absolutamente emergentes hoje em dia, como o BIGData que iremos falar mais adiante.

Eu queria iniciar por contar-vos uma pequena historia: Em 2004/2005 enquanto técnico médio e programador Web freelancer em ASP/ASP.Net/C#/SQL Server fui assistir a conferencia na UCAN que consagrou a já defunta Associaçao Angolana de Software Livre (ASL).
A conferencia estava cheia de gente com bagagem de primeiro grau, como por exemplo Dr Pedro Teta, Eng Dimonekene Ditutala e Msc Mateus Padoca Calado. No entanto o que me chamou mesmo a atenção, foi a declaração do Dr Aires Veloso (um experiente docente de programação), onde  ressaltou que um sistema a serio tinha de ser criado com uma framework/linguagem de verdade, tal como .Net ou Java.
Aquelas palavras ficaram-me na mente, ainda mais, porque não possuía conhecimentos sobre computação paralela. Somente anos depois, percebi que fazia todo sentido ele ter dito aquilo. Aquela era a época dominada por linguagens para desenvolvimento dinâmico como Cold Fusion Modules (CFM), ASP e um tal de PHP, lol. Estas eram, na altura, linguagens não orientadas a objectos e sem suporte a computação paralela.

Por isso era somente natural que um serviço de buscas e publicidade como o Google que crescia a todo vapor se sentisse ‘tentado’ a optar por plataformas como ASP.Net e Java. Mas, nem pensar!!! O génio de Sergey Brin e Lauwrence Page ‘permitiu-os’ seguir um outro caminho: Optaram por utilizar uma linguagem que até então era desconhecida para a Web: O Python (esta linguagem que tive oportunidade de aprender enquanto estagiário numa das instituições governamentais).
De facto, Sergey e Larry, não a escolherem por acaso. Esta linguagem tinha suporte a orientação de objectos, sendo fortemente tipada (tipos de dados interessantes, como listas e dicionários) e sobretudo, é software livre. Tiveram ‘apenas’ o desafio de portar para a Web, porque até então não havia conhecimento do uso desta linguagem na Web de forma massiva, senão em desktop e também aí, muito mais em aplicações para administração de sistemas *.NIX.

Este desafio foi vencido recorrendo ao uso de CGI (Common Gateway Interface) sobre o servidor HTTP Apache, ou seja, por meio dessa interface era possível a código não nativo ser executado pelo Apache. Alguns de vocês deverão lembrar que antes de 2000 e um pouco posterior a isso programava-se para a Web até com linguagem C e C++ (na minha opinião algo terrível) justamente porque a CGI do Apache permitia essa versatilidade. Era algo estranho e inúmeros problemas de segurança envolvendo sobreposição de memoria (Buffer Overflow) sobre HTTP foram revelados. Mas isto está fora do nosso contexto.

Esta decisão, longe de ser uma espécie de estilo NERD por parte de Sergey e Larry, foi antes uma estratégia de longo prazo que viria a influenciar toda a politica de crescimento da infra-estrutura da Google, ou seja, seria suportada por produtos de baixo preço, mas de elevado desempenho operacional, o que permitiria que sua infra-estrutura fosse facilmente escalável sobre custos baixos. Se a Google apostasse em desenvolver a sua infra-estrutura sobre frameworks como ASP.Net ou Java, corria o risco de ficar muito dependente de patentes e tecnologias de empresas que sabiam eles, mais cedo ou mais tarde, seriam seus adversários de negócios.

O problema do crescimento

Com o aumento da quantidade de informação produzida via Web, os serviços de indexação da google foram crescendo de tamanho. Por exemplo de 1999 a 2009, ou seja em 10 anos a google passou a indexar de 70 milhões a muitos biliões de documentos, a media da pedidos processados/dia aumentou cerca de 1000 vezes, cada documento passou a ter 3 (três) vezes mais informações nos serviços de indexação.

Gerir tamanha quantidade de informação (índices e documentos) mostrou desde o inicio ser um desafio e tanto para o pessoal da Google.
Como todo projecto vencedor tem uma base forte, a Google não foge a regra. E a sua força encontra-se também na excelente esquematizar da sua arquitectura, simples mas sobretudo inteligente.
A principio a Google adoptou a seguinte arquitectura (1997):

Arquitectura Google em 1997

Arquitectura Google em 1997

Apesar da sua aparente simplicidade, era uma arquitectura já aparentemente complexa possuindo elementos que estão a ser utilizados até hoje. Como podemos notar, existem dois grupos de servidores (clusters) que desempenham um papel importante por detrás dos pedidos de pesquisa (query) recebidos pelo servidor que chamaremos frontal (frontend): Os servidores de indexação e de documentação.
Os servidores de indexação possuem algumas informações sobre paginas, como por exemplo um índice invertido duma URL, do tipo ‘com.wordpress.snnangola‘. Os servidores de documentação armazenam todos os documentos possíveis existentes na Web e os ordenam aleatoriamente por fragmentos de documentação que falaremos mais abaixo. Cada documento possui propriedades tais como, um ID único conhecido como docid, um conjunto de palavras-chave que permitirão corresponde-lo a uma possível procura, e um Score atribuído pelo algoritmo PageRank.

Quando um pedido de pesquisa é enviado para servidor frontal, este encaminha para o servidor de indexação que mapeia individualmente cada palavra do pedido para uma lista de documentos relevantes. A relevância (Score) ou o grau de importância do documento, é determinada pelo PageRank. Essa relevância determina a ordem de saída dos documentos para a resposta ao pedido do usuário (melhor PageRank sai primeiro).

Essa aparente facilidade, entretanto esconde uma alta complexidade. Como já dissemos, com o aumento do numero de documentos, usuários e mobilidade na Web, o numero de pedidos de pesquisa/segundo aumentou brutalmente, o que perigosamente poderia aumentar o latência (o atraso ou RTT time) na resposta aos pedidos dos usuários, afinal haveria mais pedidos disputando entre si, sobre quem seria atendido primeiro. Felizmente a Google também tem uma solução para este problema, recorrendo a computação paralela. Como assim?

Pela figura acima observamos que tanto os servidores de indexação, como os servidores de documentos, possuem fragmentos (shards). Interessa de facto, falar sobre os fragmentos de indexação, porque estes lidam directamente com os pedidos dos usuários, via servidor frontal, logo os servidores de indexação, estariam em teoria mais sujeitos a estresse. Bom, isto já não é um problema porque os fragmentos possuem aleatoriamente índices para um subconjuntos de documentos do índice total. Esta técnica é conhecida como particionamento da indexação por documento.

Isto constitui inúmeras vantagens, na medida que por exemplo, cada fragmento pode processar cada pedido independentemente, também melhora o desempenho do tráfego da rede, e facilita a gestão da manutenção de informação por documento.
Mas também tem os seus contras, na medida que cada fragmento precisa processar cada pedido, e cada palavra da pesquisa necessita de ser procurada em cada N fragmentos.
Para minimizar estes efeitos, os pedidos feitos a um fragmento são distribuídos a uma pool de servidores. Cada fragmento também está distribuído numa pool de servidores no cluster de indexação.

O processo de pesquisa pode então ser resumido da seguinte forma:

  1.  O usuário digita uma única/serie de palavra(s) (como por exemplo: ‘capital de angola‘);
  2.  O servidor frontal recebe o pedido e envia para um dos fragmentos localizado numa das pools do cluster de indexação;
  3.  O fragmento dado a(s) palavra(s) corresponde a uma lista ordenada de documentos composta por docid, score, etc;
  4.  Um dos fragmentos numa das pools do cluster de documentação recebe a mensagem do fragmento de indexação e dado o docid e a(s) palavra(s), gera um conjunto de documentos, composto por titulo e trecho. Claro que com o docid já é mais fácil localizar o documento completo no disco.

No entanto, isso levanta uma outra questão: Se um dos servidores dos cluster‘s de indexação/documentação vai abaixo, por qualquer motivo, a pesquisa é abolida? A reposta encontra-se na estratégia de computação distribuída que a Google adoptou desde o inicio.

Estratégia de computação distribuída

A google sempre adoptou uma estratégia de computação distribuída. Isso mesmo pode ser percebido pela sua arquitectura já descrita na figura acima, mas que actualizaremos já, sobre uma outra perspectiva na figura abaixo:

Arquitectura google 1997 suportando cache e Ad Sense

Arquitectura google 1997 suportando cache e Ad Sense

Podemos facilmente perceber as mudanças ocorridas:

  1. Introdução de replicação
  2. Introdução de caching

O investigador Português Jorge Cardoso no livro ‘Programação de sistemas distribuídos em JAVA, Editora FCA‘ escreveu que ‘o principio da localidade, admite que a comunicação entre computadores segue dois padrões distintos. Primeiro, é mais provável que um computador comunique com computadores que estejam mais próximos do que com computadores que estejam mais longe. Segundo, é provável que um computador comunique com o mesmo conjunto de computadores repetidamente‘.

Se você percebeu, notou claramente que o primeiro padrão é técnica de replicação, e o segundo a técnica de caching. Pela figura acima nota-se claramente a existência dos dois conceitos. Exactamente ao lado do servidor frontal notamos a presença dum conjunto de servidores de caching que não sabemos com toda certeza se pertencem a um cluster. Entretanto, isso é bastante útil, quando os usuários realizam pesquisas que não foram actualizadas. Nesse caso, se elas não mudaram então não é necessário encaminhar a pesquisa para o cluster de indexação, mas sim para o suposto  cluster de caching que encaminha os documentos, já anteriormente pesquisados, para o usuário.

Pela figura acima notamos também a existência de replicação vertical nos fragmentos de indexação de de documentação. Isso é muito importante, na medida em que explica porque raramente sentimos uma pesquisa no Google ser abolida ou gerar um erro. Notamos, que ainda que um fragmento vá abaixo por causa dum erro lógico ou físico num dos servidores do cluster, pela capacidade de replicação, automaticamente a tarefa passa para outro fragmento pertencente a outra pool de servidores. Isso é uma maravilha, já que estamos em crer ser difícil que uma pool inteira falhe, mas mesmo que falhe haverá sempre outra pool para a substituir.

Por esta altura já conseguimos perceber porque o Google consegue responder de forma tão rápida as nossas pesquisas. Sim, existem outras técnicas e alguma delas iremos abordar mais adiante, no entanto, isso é em parte porque eles conseguem manter imagens de toda a Web replicadas em seus cluster’s de documentação por todo mundo.

Não existirão teoricamente muitos problemas de paginas armazenadas no cluster mas que já não existem nos servidores onde estavam alojadas. O sistema Google é inteligente o suficiente para verificar isso, e actualizar se possível, da forma mais rápida. Mas isso as vezes não acontecia tão rapidamente, e por um motivo muito simples. Os cluster’s da Google começaram a expandir-se muito rapidamente, até a escala global.
As vezes fazemos uma pesquisa a partir de Angola, e os resultados Web vem da Irlanda, mas os de Video (Youtube) vem do Brasil, o AdSense do Polo Norte (exagerei!!!) no entanto, não existe praticamente latência. Como tudo isso é possível? Se um cluster de documentação nos EUA actualiza os seus documentos, os cluster’s em todo mundo necessitam fazer isso de forma automática com mínimo de atrasos possíveis, sob pena de elevadas receitas serem perdidas.
O próximo artigo falará sobre isso.

Nexus One: Um fracasso?

Nao sei se quando a google decidiu lançar o Nexus One imaginou como um produto de grande sucesso. A verdade é que os numeros anda muito aquem do esperado, muito mesmo, uma completa desilusão, um fracasso de vendas. Diz-se aí a surdina que o produto é bom é poderoso, entao o que falhou? Marketing? O google sabe fazer isso muito bem. Falta de pre-divulgação? Erro no modelo de vendas? Só eles podem dizer.

Leia mais sobre o assunto em:

http://applemania.info/?p=5095

Google lança Nexus One

Especificações técnicas
Altura: 119mm
Largura: 59.8mm
Espessura: 11.5mm
Peso: 130 gramas (com bateria)
Ecrã: 3,7 polegadas WVGA AMOLED 800 x 480 pixels
Câmara: 5 megapixels, autofocus, zoom digital 2X, flash
Processador: Qualcomm QSD 8250 1 GHz
Memória: 512MB Flash, 512MB RAM, 4GB cartão Micro SD
Wi-Fi
Bluetooth 2.1
Sistema operativo: Android 2.1

Pagina oficial: http://www.google.com/phone/

Analise do engadget: http://www.engadget.com/2010/01/04/nexus-one-review/

Google: De bom samaritano a ‘persona non grata’?

Parece que quando a Google começou e ganhou notoriedade tem quem nao percebesse que se estava perante o nascimento dum imperio multi-milionario que nao podia mais parar de crescer. E não é por se tratar duma conjuntura dum plano maquiavelico elaborado num escritorio qualquer de Wall Street, não, na verdade é uma conjuntura imposta a propria Google que para nao cair precisa de crescer, expandir os seus negocios.

O negocio principal da Google é busca e busca tornou-se sinonimo de Google (o googlear), mas esse dominio avassalador da Google no mercado de buscas criou a chamada concorrencia imperfeita no mercado. Repare o que lhe digo. Se você fosse no Domingo (06/12/2009) a noite ao site de buscas http://www.google.com buscar por ‘flamengo campeão’ a primeira noticia que aparecia era agregação de links na Google News, mesmo com milhares de sites como record, a bola,  globo etc a pagarem por serviços de publicidade lá.

Não é novidade alguma ir ao google procurar por Black Eyed Peas e dar de caras com videos de clips ilegais no youtube, sem que alguma vez os Black Eyed Peas recebessem alguma coisa por isso, e olha o youtube pertence a Google, não é?

Tente uma busca por ‘mail’ e a primeira indexação que aparece é a do gmail. Porquê? É o mais utilizado? Não! Coisa do PageRank? É dificil dizer, já que para já a hotmail parece ser o de maior utilização e continua a receber milhares de clientes.

A suposta imagem duma empresa virada para os interesses dos usuarios finais ficou manchada com o ‘deal’ com o governo Chines que permitiu assim a entrada lda Google lá a fim de estancar o irriquieto badoo.com. Em contrapartida é o governo Chines que dicide o que passa e o que nao passa no Google China.

Tem que já nao goste de diversos atrevimentos da Google como aquele em que prometeu aposentar o email com o seu ‘vaporweb’ Google Wave que aliás só o meu caro ultracognitivo (me perdoe) teve coragem de usar, alguem lembra e eu já reclamei também aqui quando tentaram dar cabo do famigerado Second Life e criaram apressadamente o ‘enterrado’ lively?

Nao que nao goste da Google, mas nao meparece que uma empresa com a conta bancaria a roer-se pelas costuras tenha muitas lições a dar agora, a Google nao minha opiniao já faz as coisas com o claro objetivo de dominancia do mercado Web, seja em video, musica, redes sociais, email, cloud, armazenamento etc, acabou a imagem duma empresa criada por dois miudos de boas familias de Harvard, lá agora trabalham os maiores gurus de gestãoe concorrencia que você nao gostaria de ter como adversarios de negocios.

Outras fontes:

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/12/07/MNMF1AUFBM.DTL

Google foge do mais dificil e entrega Chrome OS a ‘comunidade’

Quando a Google anunciou o Chrome, logo veio a ideia dum sistema leve e sem muitas exigencias de hardware. Ledo engano, o Chrome da-se até ao luxo de trabalhar melhor apenas com discos SSD (Solid State Disks) e vir apenas homologado em hardware de fabrica. Quem quiser tentar dar uma de hacker de Linux vai passar mal com problemas de drivers etc, tarefa esta que claro nao será a Google a dar-se ao luxo de fazer, afinal gastaria milhões e muita dor de cabeça, entrgando então a comunidade, atitude aliás vezeira de quem advoga a liberdade do software livre para diminuir custos.

Google lança Chrome OS. Primeira visão

Friedrich Nietzsche disse uma vez para ter-se cuidado ao lutar contra os monstros, para que nao se torne um. A Google vem prometendo um sistema operacional que viria revolucionar o mercado e quando anunciou o Chrome parecia uma daquelas coisas que ninguem nunca viu tipo uma ideia do Raymond Kurzweil.  Os Google aficionados (UltraCognitivos e outros, hehe) clamaram por este sistema e esperavam certamente uma coisa decente aquando do seu lançamento.

Ok, ele nao é indecente, mas é como aquelas provas de sistemas distribuidos  e paralelos, do professor Veloso, não são dificeis mas são extensas demais para serem resolvidas em 2 horas, e é assim mesmo. Conceito de cloud computing, ok, para quem quer vender seu sistema operacional a Google? Para Sul Coreanos que vivem em Seul com mais de 90% da cidade com rede Wireless? Eu aqui em Angola, Luanda nao teria hipoteses com um computador com este sistema.

Depois tem o problema das compatibilidades. Os problemas com os plugins, os ActiveX, os certificados, tecnologias de segurança etc, que só funcionam em IE6, até que alguem resolva pensar que existe um tal de navegador chamado Chrome (desculpe, eu uso Firefox) que agora é também sistema e tal, bom isso é uma longa historia.

Imagine eu no meu querido Google Docs a digitar uma planilha financeira para entregar amanha, só que epá, a energia em Luanda como de hábito deu uma sumidinha. E daí? Salva, rapaz! Ho, só que a Net foi e eu uso Chrome OS.

Depois vem a energia, mas como o sinal da Tv Cabo nao vem como as vezes é hábito (uma chuvarada as vezes é a causa, e ja falaremos disso) se calhar por causa daquela pá grande da construtora XYZ que deu uma comida no cabo de fiber, ou alguma coisa assim e tal.

Tem também o problema da largura de banda real. Imagine eu com um file de 6 Mb e ter que guardar isso tudo? E as musicas? E o Virtual DJ? Tem para Web?

E os navegadores? Que opção temos de instalar o Firefox? e o IE? E o Opera (Onde Mozart recusa tocar) e o Safari? Quantos processos Anti-Trust a Google prepara-se para enfrentar?

Sabem qual a minha opinião? Chrome OS é um sistema elitista, ora.