A linha mais comprida de um arquivo

Eu precisava descobrir quantas colunas tinha a linha mais comprida de um arquivo. O único porém é que o arquivo é muito grande.

Primeiro, tentei um pouco de shell.

while read line; do echo -n "$line" | wc -c; done< arquivao  | sort | uniq -c

Isso deveria apresentar o número de linhas com determinado comprimento e o número de ocorrências de cada comprimento (não há muita variação nos comprimentos das linhas, embora haja muitas linhas).

Infelizmente, não tive paciência de deixar esta pequena solução terminar. Resolvi averiguar se o Perl seria mais rápido.

perl -MData::Dumper -n -e '$n{length($_)}++; END {print Dumper(%n)}' arquivao

A solução é bem simples e muito mais rápida que a primeira. Com os parâmeteros -n e -e, o bloco de código é aplicado a cada linha do arquivo (último parâmetro). Cada tamanho de linha vira uma chave no hash %n e é incrementada a cada ocorrência. No fim, uso o módulo Data::Dumper para apresentar o que há dentro de %n.

Gotas de otimização Oracle

Há dois problemas de SQL comuns que vejo, com frequência, sendo resolvidos com complexidades e ineficiências desnecessárias.

O primeiro é o de precisar o número de registros de uma consulta junto com os dados. A solução ineficiente é a de executar a consulta duas vezes; usando count() primeiro e buscando os dados depois. As funções analíticas são pouco conhecidas ainda, infelizmente.

select count(1)
from pessoas;

select nome
from pessoas;

Usando a versão analítica de count(), as duas consultas podem ser unidas.

select nome, count(1) over ()
from pessoas

E ganha-se uma coluna com o total de linhas.

O segundo problema é o de retirar acentos. Já vi soluções com múltiplos ifs, com case, e até com muitos replace() aninhados.

A minha solução preferida é muito simples e fácil de ler:

select nome, translate(nome,
                'ÀÁÃÂÄÈÉÊËÙÚÛÜÌÍÎÏÒÓÔÕÖÇÑàáãâäèéêëùúûüìíîïòóôõöçñ',
                'AAAAAEEEEUUUUIIIIOOOOOCNaaaaaeeeeuuuuiiiiooooocn') 
from pessoas;

Talvez haja uma solução mais curta (sei que há em Java), mas não creio que haja uma tão legível.

Os problemas médicos da informática

O modelo de medicina no Brasil tem um problema fundamental. Os médicos são remunerados por procedimentos, exames, consultas, etc. Isto é, sua remuneração não aumenta com a saúde dos pacientes. Ela aumenta, isto sim, quanto pior for a saúde das pessoas.

Na informática, isso seria como pagar os programadores por linha de código. Fosse essa a nossa realidade, teríamos legiões de programadores Java e algumas poucas almas iluminadas usando Perl.

Receitas

A comparação de programas e algoritmos com receitas é antiga e comum, mas sempre me incomodou.

Acho que achei uma maneira de melhorá-la.

Um programa é como uma receita, mas uma receita que requer cinco mil ingredientes, dois milhões de passos, e dezesseis panelas (para um fogão de quatro bocas).

2016

Em soma de potências de 2: 2¹⁰+2⁹+2⁸+2⁷+2⁶+2⁵ 

Em binário: 11111100000

Em base 8: 3740

Em base 16: 7E0

Em base 32: 1V0

Em primos: 2 ⁵ * 3 ² * 7

E o meu favorito: 2017-1.

Humanos e máquinas

Precisei consertar um Oracle Dataguard (um banco reserva que recebe todas as alterações do banco principal e que funciona como  cópia de segurança) e descobri algo sobre a produtividade dos seres humanos.

O banco reserva estava 17h atrás do banco principal quando resolvi o problema que impedia que o banco principal enviasse as alterações. Em 15 minutos os dois estavam sincronizados.

Isso quer dizer que os humanos levaram 17h para invocar transações suficientes para provocar 15 minutos de trabalho no banco secundário. Ademais, o banco primário funciona em duas máquinas, enquanto o secundário roda sobre apenas um servidor.

Evidentemente, o processamento usado em consultas não entra nessa conta. Por outro lado, muitas das alterações são provocadas por jobs (não precisam de interação humana). Mesmo assim, é interessante o fato de que um computador fez o trabalho de milhares de pessoas 68 vezes mais rapidamente.

Linguagem de baixo nível

Foi numa conversa com uma usuária que percebi o quão inadequada era uma das palavras mais comuns do vocabulário da informática: salvar. Certamente, trata-se de um anglicismo e que funciona suficientemente bem no português. Mesmo considerando que os dados realmente precisam de salvação, já que podem desaparecer se faltar luz (salvo se o sistema usar memória de ferrite), é excessivamente dramática essa palavra. O verbo gravar (ou talvez guardar) seria mais adequado e menos teatral.

Mais recentemente, escutei uma conversa na qual um colega explica a uma usuária que uma rotina havia sido codificada em linguagem de baixo nível.

Fiquei a imaginar o que a pessoa leiga pensou. Que alguém levantou a voz e insultou a máquina? Que ela própria corria o risco de escutar poucas e boas? De qualquer forma, o assunto foi resolvido com brevidade e salvou-se o dia.