Terminal Velocity

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:
| Terminal | Time (sec) |
|---|---|
| iTerm2.app (Mac) | 12.72 |
| Terminal.app (Mac) | 41.03 |
| xterm (Mac) | 41.52 |
| mintty (Win32) | 14.86 |
| xterm (Linux) | 29.70 |
| Gnome Terminal (Linux) | 61.68 |
| 80x24 text-mode console (Linux) | 276.68 |
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.
Extreme WYSIWYG
Essa semana, Slashdot nos contemplou com dois deliciosos eye-candies na área de interface e usabilidade:
Gliimpse
Devo confessar que, se eu tivesse como utilizar esse tipo de preview para redigir HTML, esse blog teria updates muito mais frequentes :P
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 usoualert()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).
TicketFeed – Alimentando o seu leitor de feeds!
Sei lá o que posso prosear a respeito disso 😛
Mas vamos começar pelo começo. Um belo dia, estive eu no caixa de um restaurante, prestes a pagar pelo meu almoço, quando uma notícia nada agradável me surpreende: o meu saldo estava zerado!!!
Como isso seria possível, se o meu ticket até está na minha planilha de gastos (isso é, sempre que uso ele, anoto quando e aonde foi)?! Pois é, foi clonado.
Então de que adiantou todo o meu acompanhamento de crédito/débito? Pfffffft 😛
Aí no processo de resgatar o rico dinheirinho do meu rango, me deparei com o site oficial, http://www.ticket.com.br/, que é uma tosqueira inigualável. Para começar, o "sistema de segurança" é tão pífio que requer apenas o número do cartão, sem senha alguma, para consultas de extrato/saldo! Tudo bem que não é uma informação pra lá de sigilosa, ainda assim... Qual a utilidade podemos extrair disso?
- Funcionários de uma mesma empresa recebem seus cartões do mesmo lote. A numeração dos cartões é sequencial, só muda o dígito verificador (que segue o padrão do cartão de crédito). No extrato sai o nome do local aonde o dinheiro foi debitado. Assim, é perfeitamente possível rastrear os meus coleguinhas;
- Posso fazer coleta automática do extrato, assim saberei de antemão se fui debitado indevidamente. Poderia receber avisos de débito/crédito por email, mas o email está morrendo, e o hype do momento são os leitores de feed (sarcasmo mode off).
Acabei optando pela segunda opção. Aliás, aproveitei para fazer um test drive do DotCloud, e gostei!
Então, o negócio é o seguinte. Pegue o seu Ticket. Entre em http://ticket.iwatcher.net/. Preencha o respectivo campo, e gere URL do tracker. Eu gosto do Google Reader, mas funciona em qualquer outro agregador de feeds. A ideia central é: para cada "ping" no tracker, o webservice rodará um scrapper no site oficial, e gerará um feed a partir dos dados coletados. Assim, você terá um feed de notícias gerado pelos seus hábitos gastronômicos 😉
Uma observação importantíssima a respeito da privacidade dos dados: o número do seu Ticket é transferido em plaintext, assim como no site oficial. Obviamente, dessa forma ele acaba parando no access.log do servidor. Não tem como evitar isso. Já os dados das transações não estão sendo replicadas em nenhum banco de dados. Traduzindo: eu não sei o que se passa na sua conta, caso você venha a utilizar o meu webservice. Nem pretendo saber. Mas, de posse dos logs dos servidores, é perfeitamente possível acessar o extrato referente a cada Ticket consultado, visto que o site oficial não utiliza nenhum tipo de PIN/senha.
Ah, e o layout da página do gerador de feeds fica uma nhaca no Firefox. Eu não sei corrigir 
Alguém com um bom domínio de CSS se habilita?