Não, não se trata de um fenômeno físico, nem de um videogame, e muito menos de um filme com Charle Sheen. Já que passo a maior parte do dia na frente de um emulador de terminal (a famosa "tela preta com as letrinhas"),  observei que em alguns casos a user experience (se é que posso falar assim de CLI) é mais fluida e agradável do que em outros.

Em outras palavras, bandwidth de saída de caracteres na tela é bastante variável.

Isso é evidente em programas que subvertem a ideia do texto linear, os fabulosos TUI, tais como Vim ou Midnight Commander. Não é tão evidente em libcaca ou icat, pois são poucas as pessoas que sabem o que é isso e um número ainda menor encontra alguma utilidade para eles.

Felizmente, tendo reduzido "usabilidade" em "bandwidth", quantificar a métrica se torna fácil. É só pegar um texto grande, jogar na tela e cronometrar. "Texto grande", no caso do meu teste, foi o código-fonte do Perl v5.16.0, "colorificado" através de source-highlight:

find ~/perl-5.16.0 -type f -name '*.[cht]' -or -name '*.p[lm]' -exec \
    source-highlight --failsafe --infer-lang -f esc --style-file=esc.style -i {} \;

Depois, listei esse arquivo em cada emulador de terminal, dentro de VMs respectivos de cada OS (isso é, VM de Linux, de Windows e de Mac OS). VM fez-se necessário para "nivelar por baixo": seria injusto comparar VMs de Windows e Linux com o Mac OS nativo. Não mexi em configurações/preferências dos emuladores de terminal: fontes, cores e tamanho da tela são os default de cada "fabricante". O resultado está no gráfico no começo do post, e também nessa tabela:

O que salta aos olhos é que justamente o Linux, o sistema que contribuiu tanto para o "revival" do CLI, é o que tem emuladores de terminal mais lentos. E o terminal mais simples (aquele que no Linux é acessível via Ctrl+Alt+F1; a telona DOS clássica) é, contra-intuitivamente, o mais ineficiente!

É claro que esse benchmark é muito tosco. Talvez seria mais representativo utilizar a mesma fonte em todos os terminais testados, e também maximizar a tela dos mesmos (a quebra de linhas longas costuma ser custosa), além de desabilitar o histórico de scrollback. Fonte com/sem antialiasing e uso/não-uso de ANSI escape sequences também interferem na velocidade da saída. Mas, enfim: a diferença de velocidade é suficientemente grande e perceptível. Portanto, duvido muito que algum ajuste fino deixará Gnome Terminal mais rápido do que iTerm2.app.

Antes de me taxarem de hater ou fanboy: já usei muito o Internet Explorer. Também já usei muito o Netscape, Mozilla, Opera, Firefox e Chrome. E "muito", para mim, traduz como "por mais de um ano". Só não usei o Safari pois a primeira coisa que fiz ao migrar para Mac foi instalar um navegador familiar, para não se sentir tão deslocado.

Acredito que usei todos esses navegadores no seu auge, dadas as circunstâncias: Opera era imbatível nos Lentium com 32MB de RAM da faculdade. Firefox era absurdamente mais leve do que o Mozilla, e tão completo quanto. Depois que engordou, migrei pro Chrome. Netscape Gold não tinha muitas alternativas na época do Windows 3.11. E o Internet Explorer... Por um bom tempo estava na vanguarda, era leve e com recursos (proprietários) muito interessantes.

Como sempre acontece, tudo o que sobe, tem que descer. Hoje, todos os webdevelopers odeiam o Internet Explorer e vibram com a perda do browser share pelo mesmo, porém, parafraseando o Mark Twain, "os rumores sobre a sua morte são, sempre, um tanto exagerados". Independente da métrica adotada (pois, dependendo da métrica, o share do IE varia de 16.7% a 32.31%, na metade de 2012), o declínio da popularidade é evidente.

Esta seria a história do lado dos usuários. Mas o que me chamou atenção, recentemente, é a história do lado dos webdevs. Especialmente essas três notícias:

1. Startup afirma ter economizado 100 mil Obamas deixando do lado a compatibilidade do seu produto com o Internet Explorer;
2. Online shop cria "imposto Internet Explorer": clientes usando esse navegador pagam mais (a justificativa é a dificuldade de manter uma versão compatível do site);
3. jQuery 2.0 abandonará o suporte a Internet Explorer 6, 7 e 8.

Seria equivocado afirmar que são essas as medidas que colocarão os últimos pregos no caixão do infame navegador da Microsoft. Para mim, estas são as evidências de que o seu share está, de fato, baixo o bastante para ser desprezado.

Google Refine is awesome. If you're unaware of what it is, access their official page and watch at least the first screencast. You'll see it can be helpful for several ETL-related tasks.

Currently, I use it a lot, specially for simple (but boring) tasks, like loading a CSV, trimming out some outliers and saving as JSON to be imported into MongoDB. Nothing a Perl one-liner couldn't do.

However, the opposite is not true: Perl one-liners are a lot more flexible than Google Refine. Now, what if we could merge both?

1. Google Refine could be easily integrated with any RESTful API.
2. Perl transforms one-liners into RESTful webservices.
3. PROFIT!!!

As a practical example, I'll use some georeferenced data I was working at. Let's suppose I have to deduplicate registers, and one of "duplicate" rules is their proximity on the map. Google Refine is far from a full-featured GIS, and is unable to handle bidimensional coordinate system. Enter the GeoDNA: an algorithm to lower geospatial dimensions. As it's FAQ says,

GeoDNA is a way to represent a latitude/longitude coordinate pair as a string. That sounds simple enough, but it's a special string format: the longer it is, the more accurate it is. More importantly, each string uniquely defines a region of the earth's surface, so in general, GeoDNA codes with similar prefixes are located near each other. This can be used to perform proximity searching using only string comparisons (like the SQL "LIKE" operator).

Another interesting property of GeoDNA is that when ordening a set of records by their GeoDNA code, close locations are likely to appear in adjacent rows (sometimes, close locations will share very different prefixes, but similar prefixes always represent close locations).

To incorporate GeoDNA into Google Refine, we'll use the Add column by fetching URLs option, clicking on the header of any column (which column it will be doesn't matter as we'll use two of them, anyway):

As the expression, we'll paste the following code (here, pay attention to the correct latitude/longitude column names):

'http://127.0.0.1:3000/?lat='+
row.cells['latitude'].value
+'&lon='+
row.cells['longitude'].value

Throttle delay can be zeroed, as our webservice is local. The final configuration should look like this (don't push the OK button, yet):

Now, check if you have Mojolicious and Geo::DNA Perl modules (install them via CPAN, if not) and paste into your 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

If you prefer a "human-readable" version, paste the following code into geocode-webservice.pl:

#!/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;

Once you started a webservice, it will report Server available at http://127.0.0.1:3000. Now, click OK on Google Refine dialog and wait. Even without delay, it could be a bit slow; however, even then this hack saved me a lot of time

(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!

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!

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?

1. Google Refine pode ser facilmente integrado com um web-service qualquer.
2. Perl transforma one-liners em webservices.
3. 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

Porém, ao invés de servir como uma espécie de complemento, é uma "volta às origens". O algoritmo original, desenvolvi em JavaScript puro, depois traduzi para Perl, refinei, detalhei e escrevi sobre. A intenção agora é ser mais show me the code possível, com um exemplo simples, enxuto e prático. Portanto, a teoria e os detalhes continuam lá no artigo original. Aqui, é mão na massa!

Ensinando o classificador

O classificador funciona por palavras-chave, e o MongoDB, nesse estágio, atua como um mero key/value storage. Salve o código de inicialização a seguir como init.js e carregue com mongo bayes init.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

db.bayes.update({_id: 'pelos'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'bigodes'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'rabo'}, {$inc: {total: 1, 'categ.gato': 1}}, 1);
db.bayes.update({_id: 'pelos'}, {$inc: {total: 1, 'categ.cachorro': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.cachorro': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.cachorro': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.cachorro': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.cachorro': 1}}, 1);
db.bayes.update({_id: 'rabo'}, {$inc: {total: 1, 'categ.cachorro': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.galo': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.galo': 1}}, 1);
db.bayes.update({_id: 'bico'}, {$inc: {total: 1, 'categ.galo': 1}}, 1);
db.bayes.update({_id: 'asa'}, {$inc: {total: 1, 'categ.galo': 1}}, 1);
db.bayes.update({_id: 'asa'}, {$inc: {total: 1, 'categ.galo': 1}}, 1);
db.bayes.update({_id: 'penas'}, {$inc: {total: 1, 'categ.galo': 1}}, 1);
db.bayes.update({_id: 'bico'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);
db.bayes.update({_id: 'pata'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);
db.bayes.update({_id: 'rabo'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);
db.bayes.update({_id: 'pelos'}, {$inc: {total: 1, 'categ.ornitorrinco': 1}}, 1);

Agora, entrando em MongoDB Interactive Shell com mongo bayes, podemos ver a estrutura resultante com db.mongo.find():

{ "_id" : "bigodes", "categ" : { "gato" : 1 }, "total" : 1 }
{ "_id" : "bico", "categ" : { "galo" : 1, "ornitorrinco" : 1 }, "total" : 2 }
{ "_id" : "asa", "categ" : { "galo" : 2 }, "total" : 2 }
{ "_id" : "penas", "categ" : { "galo" : 1 }, "total" : 1 }
{ "_id" : "pata", "categ" : { "cachorro" : 4, "galo" : 2, "gato" : 4, "ornitorrinco" : 4 }, "total" : 14 }
{ "_id" : "rabo", "categ" : { "cachorro" : 1, "gato" : 1, "ornitorrinco" : 1 }, "total" : 3 }
{ "_id" : "pelos", "categ" : { "cachorro" : 1, "gato" : 1, "ornitorrinco" : 1 }, "total" : 3 }

Cada palavra-chave é associada aos contadores das categorias, além do contador geral de ocorrências. Agora, vamos processar essa estrutura de dados!

Classificador em map/reduce

O código a seguir é quase que um programa independente em JavaScript, salve-o como bayes-mongodb.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

var words = [];
for (var word in doc)
    words.push(word);
 
var categ = [
    'gato',
    'cachorro',
    'galo',
    'ornitorrinco'
];
 
var guess = db.runCommand({
    mapreduce: 'bayes',
    out: { inline: 1 },
    query: {
        _id: {
            $in: words
        }
    },
    scope: {
        categ: categ,
        doc: doc,
    },
    map: function () {
        for (var i = 0; i < categ.length; i++) {
            var ctg = categ[i];
            var prob = Math.log(
                typeof(this.categ[ctg]) != 'undefined'
                ? this.categ[ctg]
                : 1.18e-38
            );
            prob -= Math.log(this.total);
 
            emit(ctg, prob * doc[this._id]);
        }
    },
    reduce: function (key, values) {
        var result = 0;
        values.forEach(function (value) {
            result += value;
        });
        return result;
    }
});
 
var res = { value: -Infinity };
for (var i in guess.results)
    if (guess.results[i].value > res.value)
        res = guess.results[i];
 
print(res._id);

Para passar parâmetros via linha de comando, usamos a opção --eval do MongoDB Shell, e o script imprime na tela a categoria "adivinhada":

$ mongo bayes --quiet --eval 'var doc = { bigodes: 1, rabo: 1 }' bayes-mongodb.js 
gato
$ mongo bayes --quiet --eval 'var doc = { bico: 1, rabo: 1, patas: 4 }' bayes-mongodb.js 
ornitorrinco
$ mongo bayes --quiet --eval 'var doc = { bico: 1, asa: 2 }' bayes-mongodb.js 
galo

Conclusão

O básico do básico esta aí
É evidente que os resultados e a eficiência do classificador bayesiano variam de caso para caso, e até de implementação para implementação. Se a primeira tentativa não for um sucesso, se quiser entender para que serve o "número mágico" 1.18e-38, ou se quiser automatizar o "treinamento" através de um pequeno script em Perl, consulte o artigo original!

Não, essa foto não foi tirada usando o Instagram

Neste post, não falarei nada a respeito do Instagram em si. Afinal, criticá-lo é estar na contramão do sucesso.

Não, ao invés disso, irei enumerar algumas tecnologias relacionadas à imagem que me impressionaram nos últimos anos. E, é claro, Instagram não está entre elas.

1 - Memória Fotográfica Coletiva

Qualquer um munido de um celular se acha o Paganini do pincel hoje. Imagine se ostentar uma Canon 5D Mark II, então!

Pois bem, Iain M. Banks já idealizou em seu Feersum Endjinn que, caso seja possível transferir personalidade para um chip, poderíamos obter uma compressão desgraçada de boa, já que 99.99% da nossa individualidade não é tão... Individual

Enfim, lembre-se: você é especial. Assim como todos os outros. E as suas fotos são super-originais e criativas. Assim como as dos outros, claro.

"Landmarks Layered into a Collective Memory", clique na imagem para ver mais.

2 - ONE-BIT CAMERA

Se lidar com limitações e restrições estimula a criatividade, esse seria o extremo absoluto na evolução dos filtros do Instagram.

Puxa, quando criança, sempre quis ter uma câmera Polaroid. Mas quando peguei numa câmera digital, a vontade passou na hora. Pois bem, muita gente ainda insiste nessa nostalgia. Sabem de onde vêm aquela ridícula borda branca em volta das "representações das fotos"? Aliás, já viu essa borda em uma foto qualquer? Pois é...

Enfim, se o objetivo não é mimetizar "velhos bons tempos", mas sim "conter para despertar a criatividade", por que não fotos monocromáticas? Não, não branco-e-preto; isso é mainstream demais! Só branco e preto!

1-BIT CAMERA for iPhone®

3 - Microsoft Photosynth

Outro extremo: ao invés de filtrar informação, agregar.
Qualquer um com o mínimo de habilidade no Photoshop monta um panoraminha em questão de minutos. Pois bem, com Photosynth e um celular com giroscópio/bússola, passa a ser uma questão de segundos.

4 - Lytro

E que tal agregar a informação de profundidade? OK, para isso, não basta um celular; o hardware precisa ser especializado.

Mas não é nada absurdo (custa a partir de 400 Washingtons, no momento da escrita). O efeito é imprescindível: primeiro se tira a foto, e depois ajusta o foco! Isso é, a imagem toda está em foco, e você tem a liberdade de escolher o plano de profundidade de uma imagem já "congelada"! Inclusive, Lytro promete soltar uma atualização de software que permita extrair uma espécie de voxel-maps a partir das fotos tiradas com o seu equipamento. Show!

Por mim, esse feito já merece o Oscar da Paz. Veja (clickando em diversos pontos na imagem):

5 - C3 Technologies

Afastando-se um pouco da Terra... Que tal olhar o seu bairro com os olhos de um game da Blizzard?

Tá bom, isso só se aplicaria se você morasse em Oslo, Noruega, mas a tecnologia da 3D-ficação da imagem aérea é impressionante.

Sim, há rumores de que a Apple comprou esta tecnologia. É também fato comprovado de que a Nokia comprou. Instale o bendito do plugin e deleite-se: http://maps.nokia.com/40.6897386,-74.044671,17.8,293.62,60.04,3d.day

Bônus

Google Maps também tem uma renderização 3D, não tão eye-candy, mas que impressiona pelo seguinte fato:

(clique para ver com os próprios olhos no Google Maps)

Sim, ele está tentando renderizar as árvores como se fossem prédios. Sabe o que isso significa, meu amigo? Uma gafe dessas indica que o processo é quase que totalmente automático! Isso é: uma falha (árvores = prédios) comprova a regra (prédios = prédios). Nada mal!

6 - Urthecast

Continuando com a temática espacial... Que tal um crossover entre YouTube e Google Earth?!

Quer dizer... Todo mundo já ouviu uma piadinha sobre algum mentecapto ligando para amigo pedindo para apontar Google Earth para a própria casa, na esperança de aparecer "ao vivo"... Pois bem: ainda em 2012, isso será possível, graças ao Urthecast:

7 - Fotos coloridas tiradas em 1910

Clique na imagem para ver galeria de mais 33 fotos como essa.

E não, não foram pintadas à mão! Sergei Mikhailovich Prokudin-Gorskii tirou fotos coloridas da Rússia no período de 1909 a 1912, valendo-se da técnica que utilizamos hoje em dia para tirar foto HDR com uma câmera comum: sucessão de imagens tiradas com parâmetros distintos. No caso dessas fotos, "parâmetro" era o filtro vermelho, azul e verde. Pois é, as fotos só puderam ser "reveladas" décadas mais tarde!

8 - Vídeo em HDR

Fotos HDR são bem comuns; até iPhone tira. Já vídeos... São os famosos timelapses, que dão uma "acelerada" no tempo. Por que isso?

Simples: para tirar uma foto HDR (High-Dynamic Range) com uma máquina comum, precisa ajustá-la para várias configurações de exposição, tirando uma série de fotos, e depois recombiná-las através de um software. O ajuste do diafragma é mecânico, logo, leva tempo, logo, não dá para chegar nem nos 12 fps.

Mas e se usar duas câmeras, pré-configuradas para exposições distintas?! Confesso que não entendo nem como funciona a exposição para filmagem, mas para dividir a imagem, saquei que usaram um espelho semi-transparente:

9 - GIFs animados fotorrealísticos!

Se para você GIFs animados são sinônimo das homepages toscas da década de 90, está na hora de rever os seus conceitos!

Apesar da limitação técnica de empregar uma paleta de 256 cores, resultados surpreendentes podem ser obtidos:

Clique para ir para um blog atualizado periodicamente com essas belezuras.

10 - Lente macro no celular

E, para fechar com a chave de ouro, não poderia faltar essa gambiarra no melhor estilo MacGyver: transforme o celular em uma câmera macro (quase um microscópio) acoplando a ele... Uma lente do cabeçote de leitura do drive de DVD :S

Aliás, a imagem lá em cima, no header desse blog, foi feita exatamente desse jeito

Clique e faça você mesmo!

Segue aqui uma listinha de utilitários ligeiramente diferentes dos tradicionais e consolidados, mas cujas pequenas e grandes melhorias me fizeram renunciar quase que completamente os mais clássicos e abraçar os bleeding edge

mosh is the new ssh

Não me entenda mal: SSH é muito mais do que uma simples shell remota! Também serve para tunelamento de conexões, transferência de arquivos, autenticação remota... Aliás, o próprio Mosh se autentica via SSH. Só que daí em diante, é outra história.

Mosh utiliza o protocolo UDP ao invés do TCP, então não precisa manter uma conexão. Simplificando muito, Mosh faz sincronização do estado do terminal remoto com o local, ao invés de redesenhar as telas caractere por caractere.

Ou seja: o seu link pode ser muito ruim, que o Mosh não está nem aí. Pode perder conexão, pode colocar o notebook em standby; quando o link voltar, está aí a sua shell, do jeito que você deixou! 'Network error: Connection reset by peer'‎, nunca mais.

Outro "efeito colateral" bacana do Mosh é que ele dispensa buffers. Já me ferrei dando um lsof numa conexão lerda; até que todo o output saia, SSH não deixa nem o input de Ctrl-C passar.

Para finalizar, o comparativo de tempo de resposta de SSH com Mosh, do site oficial do MIT:

tmux is the new screen

Mesmo que você seja um ávido fã do screen, o tmux vale uma espiada. O grande distintivo talvez seja o modelo client/server, que garante uma grande flexibilidade às sessões gerenciadas pelo tmux. Por exemplo, dá para mover janelas entre diversas sessões, ou então replicar o input em várias janelas (útil quando se quer iniciar o mesmo processo em diversos nós). Os atalhos de teclas tem perfis pré-definidos "emprestados" de Vim ou Emacs, e, é claro, dá para redefinir quase tudo do jeito que quiser pelo arquivo de configuração bastante legível. Ah, um bônus: split vertical da tela funciona sem patch adicional

Um breve tutorial:

1. TMUX – The Terminal Multiplexer (Part 1)
2. TMUX – The Terminal Multiplexer (Part 2)

htop is the new top

Esse dispensa apresentações. É praticamente um 'Activity Monitor.app' versão terminal. Infelizmente, a versão para MacOS tem algumas esquisitices (especialmente na parte que se refere à exibição da quantidade de memória). Ainda assim, é excelente para overview geral do sistema. Sempre mantenho um htop aberto nos meus servidores

ack is the new grep

Descobri o ack recentemente. Não é bem um grep, mas sim uma combinação de find/grep específica para trabalhar com código-fonte. Em suma, ele faz busca recursiva utilizando regexp "sabor Perl", e desconsidera coisas como subdiretórios do Git ou SVN. Por exemplo uma versão (very) quick & dirty do Perl::PrereqScanner seria:

ack -ho --perl '^\s*use\s+[\w+\.:]+' | sort -u

xz is the new bzip2

Um pequeno devaneio: aparentemente, Inteligência Artificial e compressão de dados são assuntos afins. Os organizadores do Hutter Prize, por exemplo, acreditam que uma compressão eficiente de um texto natural seria de dificuldade equivalente a passar no teste de Turing.

Voltando ao tema original: anos atrás, quando clock de um PC high-end não passava de 1 GHz, e conexão broadband ainda estava engatinhando nos países do 3-o mundo, ver um código-fonte compactado com bzip2 numa página de download era de restaurar a fé na humanidade. Pois era evidentemente um ato altruístico por parte do disponibilizador levar muito mais tempo para compactar para poupar um pouquinho de tempo e banda de quem fizer o download.

Hoje, o bzip2 roda na velocidade do gzip de outrora. Eis que revive o algoritmo LZMA: muito mais voraz quanto à CPU/RAM, na grande maioria dos casos chuta bonito o traseiro do bzip2! O conheci através do 7-Zip, de longe o melhor compactador para Windows (xupem, WinZip e WinRAR!). Depois, para a minha alegria, descobri o xz, que:

1. É mais fácil de digitar do que 'bzip2';
2. Compacta mais do que o bzip2;
3. Usa os mesmos parâmetros que o bzip2 (cat ... | xz -cv9 > dump.xz continua válido).

E você, tem algum exemplo assim? Comente!

Gliimpse

Devo confessar que, se eu tivesse como utilizar esse tipo de preview para redigir HTML, esse blog teria updates muito mais frequentes

Não me habituei com nenhum editor WYSIWIG, e até os meus slides faço em POD e renderizo com S5.

Realmente, me parece uma bela de uma mão na roda!

Light Table

Light Table - a new IDE from Chris Granger on Vimeo.

Demais esse conceito de IDE + REPL, que está para virar protótipo!

Só vejo um porém. Exemplificando metaforicamente: a melhor definição de uma "linguagem de programação" que conheço é "capacidade de produzir loop infinito". Por isso, falar "programador HTML", por exemplo, é meio que nonsense. Agora, apesar do loop infinito ser tão importante na teoria, não é nada bom na prática. Por exemplo, digitar :​​(){ :​​|:& };: na linha de comando do Linux ou Mac e dar ENTER leva ao suicídio do sistema operacional. Enfim, quem já programou em JavaScript e usou alert() para debugar, sabe do que estou falando

Agora, o cara usou um exemplo muito feliz: IDE dele é totalmente voltada para linguagens funcionais, tanto que a menor unidade de código, para ele, é a função. Por obséquio, linguagens funcionais não tem loop! Tem recursão, que até pode ser infinita, mas convenhamos: quem domina programação funcional, dificilmente vai cometer essa gafe...

Concluindo: a ideia é genial, mas daria certo para poucos. O meu palpite é que surgirá a versão dessa IDE para trabalhar com JavaScript, tanto client- quanto server-side (Node.js), pois JavaScript, surpreendentemente, é funcional (tecnicamente falando, JavaScript é quase um Domain Specific Language de Scheme, que é dialeto de Lisp).