SQL <=> MongoDB
(clique para ampliar)
Esse post nada mais é do que a divulgação de um fabuloso infográfico feito por Rick Osborne. Esbarrei nele buscando por alguma coisa relacionada ao MongoDB que não lembro mais, e fiquei encantado. Longe de ser algo que ninguém nunca fez (exemplos do driver do Perl são, convenhamos, mais práticos), ficou condensado e elegante. Have fun!
Attached Files:
SQL-to-MongoDBDuckDuckGo por um mês: NICE!
Disclaimer: isso não é um post patrocinado, eu realmente pretendo continuar usando o DuckDuckGo, e estou citando apenas algumas das razões. Também não sou hater, uso o Chrome, Gmail, Reader, Drive, Picasa, Maps, Calendar... Só não uso o Plus 😛
Deixando as coisas bem claras: não sou uma pessoa que se preocupa (excessivamente) com privacidade. Quanto assunto é propaganda, Google faz um excelente trabalho, sugerindo produtos/serviços de acordo com o perfil individual do usuário. Não tenho nada contra Google montar o meu perfil para me direcionar propaganda mais relevante. Até já comprei produto pelo anúncio do Google.
O que me incomoda é a tentativa de adaptar os resultados de busca de acordo com o tal perfil: o infame filter bubble. É o tipo de coisa que, quando acerta, pensamos "ooown, que bonitinho!"; já quando erra, "programa imbecil do !@#$%ˆ&". Concordo que pode funcionar muito bem para 99% das pessoas, mas evidentemente, não sou uma delas, pois para mim, enche o saco demais. Exemplo mais tosco possível: buscar por uma mensagem de erro em um programa relativamente popular. Para mim, Google retorna a pior fonte de informação possível: fóruns nacionais com um bando de gente perguntando o que é esse erro e ninguém sabendo resolver.
Ou então esses malditos de portais de downloads (não vou citar o nome pois "que falem mal, mas falem de mim" ainda é SEO). Quero o site oficial da bagaça, não alguma versão antiga para um sistema operacional tosco (sem nomes também)! Felizmente, dá para auto-censurar os resultados do Google quanto a esse tipo de coisa. Mas eu ainda prefiro que esse não seja o comportamento default.
Sem falar do modo "Maria-vai-com-as-outras"; aquela relevância alavancada de acordo com o seu círculo de contatos. OK, de certa forma, a médio/longo prazo, isso ajudará as pessoas a perguntarem coisas para o Google antes de perguntarem para a pessoa do lado. Mas, a curto prazo, é uma diminuição da filter bubble.
Bom, enfim, eu já sabia que o DuckDuckGo resolveria os meus problemas (imaginários ou não). Só faltava coragem para efetivamente começar a usar. O empurrãozinho veio do @garu_rj:
Então, é realmente possível sobreviver a base do DDG! Claro, estou nessa há apenas 1 mês... Já percebi que algumas vezes devo apelar para o "fallback" para Google; pois coisa muito obscura é com ele mesmo (o interessante é que coisas incomuns quase não sofrem dos efeitos do filter bubble: metadados são insuficientes para até para uma confusão). Mas, digamos, 99% das minhas buscas (segunda vez esse número nesse post...) o DDG atende.
Veredito: vale a pena!
Google Refine + Perl
Google Refine é show. Para quem não conhece, acesse já o site oficial e assista pelo menos o primeiro vídeo. Serve para inúmeras tarefas envolvendo ETL.
Eu, no momento, uso muito para coisas simples, como carregar um CSV, eliminar outliers e salvar em JSON para carregar no MongoDB. Nada que um one-liner em Perl não pudesse fazer.
Infelizmente, a recíproca não é válida: one-liners em Perl são bem mais versáteis do que o Google Refine. Que tal integrar os dois?
- Google Refine pode ser facilmente integrado com um web-service qualquer.
- Perl transforma one-liners em webservices.
- PROFIT!!!
Como exemplo concreto, utilizarei dados georeferenciados. Digamos que preciso eliminar registros duplicatas, e uma das formas de detectar é pela proximidade física dos pontos no mapa. Google Refine não é um GIS, e não faz a menor ideia de como processar latitude/longitude. Entra o GeoDNA: um algoritmo que transforma coordenadas numéricas bidimensionais em uma string com propriedade interessante: quanto mais longo o prefixo compartilhado de dois GeoDNAs, mais perto estão as respectivas coordenadas no mapa (infelizmente, GeoDNAs com prefixos totalmente distintos também podem estar fisicamente próximos; localidades próximas ao meridiano de Greenwich são um exemplo clássico). Portanto, ordenando os registros por GeoDNA, as localidades próximas tenderão a ficar em linhas adjascentes. Para a integração, usaremos o recurso Add column by fetching URLs, clickando em header de qualquer coluna (a coluna não importa pois, de qualquer maneira, usaremos dados de duas):
No diálogo que aparecer, colamos o seguinte código (atenção para o nome das colunas com as respectivas coordenadas):
'http://127.0.0.1:3000/?lat='+ row.cells['latitude'].value +'&lon='+ row.cells['longitude'].value |
Não precisamos do throttle delay, pois o nosso webservice é local. O diálogo deve ficar assim (nada de clickar em OK, ainda):
Agora, certifique-se de que você tem os módulos Mojolicious e Geo::DNA instalados, e rode no terminal:
perl -MGeo::DNA -Mojo -E 'a("/"=>sub{my$s=shift;$s->render(json=>{geocode=>Geo::DNA::encode_geo_dna($s->param("lat"),$s->param("lon"))})})->start' daemon |
Se preferir, aqui está a versão "por extenso":
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | #!/usr/bin/env perl use Geo::DNA qw(encode_geo_dna); use Mojolicious::Lite; any '/' => sub { my $self = shift; $self->render(json => { geocode => encode_geo_dna( $self->param('lat'), $self->param('lon'), ), }); }; app->start; |
Uma vez iniciado o webservice, clique em OK lá no diálogo do Google Refine e aguarde. Mesmo sem o delay, é relativamente lento; porém o custo/benefício dessa gambiarrinha é, evidentemente, favorável 😉
Categorias
- Computação (18)
- Computer-Human Interface (11)
- Design (14)
- DIY (4)
- Hack (9)
- JavaScript (3)
- Open-Source (12)
- Perl (5)
- Programação (13)
- Segurança da informação (2)
- Sem categoria (2)
- TCC (9)
- Tradução (2)
Tags
Posts recentes
- Terminal Velocity
- InterNOT Explorer
- Google Refine + Perl (English)
- SQL <=> MongoDB
- DuckDuckGo por um mês: NICE!
iWatcher.net