ROXTerm.... r0x

Eu uso Linux para 99% das minhas necessidades computacionais, a excessão ficando apenas por conta de um ou outro jogo que só existe para Windows. Ao contrário de muitos outros usuários de Linux, eu não uso um ambiente gráfico "completo" como Gnome ou KDE - a minha preferência é o Enlightenment 16, um gerenciador de janelas relativamente minimalista, muito leve, e muito rápido.

O E16 não possui um programa de terminal integrado, necessitando que este seja instalado separadamente. Existe um, o ETerm, que parece ter sido feito para acompanhá-lo, mas eu não me dei muito bem com ele - achei a configuração um pouco chata. Também já fiz uma breve tentativa de usar os terminais do Gnome e o KDE, no começo, mas logo desisti, já que nenhum dos dois funciona muito bem fora do seu ambiente nativo.

Até há pouco tempo atrás, minha escolha era o aterm. Ele também é bastante leve, suporta pseudo-transparência, e pode ser configurado por opções de linha de comando (ou seja, é só copiar sua configuração preferida da Internet e colocar como o comando de inicialização no menu to Enlightement). Ao longo do uso no trabalho, entretanto, notei alguns problemas. Eu preciso manter no mínimo três terminais abertos, e as janelas não cabem todas na tela em tamanho legível. Para resolver isso, tentei o multi-aterm, uma versão com suporte a abas, mas que infelizmente é baseada em uma versão jurássica do programa original. Logo a deixei de lado.

Além disso, o aterm não tinha um suporte muito bom a caracteres "estranhos": sempre que o meu dedo escorregava e digitava uma cedilha por engano, glifos estranhos apareciam no terminal, e a posição real do cursor saía de sintonia com a mostrada na tela (hilário, especialmente quando você está digitando um comando complexo e cheio de opções).

Então, um dia, em uma passada de rotina pela lista de pacotes disponíveis ao Gentoo, vi um chamado ROXTerm. Eu já usava o ROX como gerenciador de arquivos, então imaginei que não haveria problema em testar o terminal novo. Logo eu havia deixado o aterm de lado, e não me arrependo nem um pouco. Em primeiro lugar, o ROXTerm suporta abas e não tem problema nenhum em exibir caracteres especiais. Só isso já bastaria para me fazer mudar. Mas, como diria o tiozinho da Polishop, não é só isso! A configuração dele é muito mais intuitiva que a dos outros terminais mencionados aqui, e ele se integra muito melhor ao ambiente gráfico, inclusive com suporte à área de transferência (os outros terminais usam seu próprio mecanismo para copiar e colar texto, que o ROXTerm também suporta).

Se você usa Gnome ou KDE, os terminais "nativos" desses ambientes provavelmente já fazem tudo isso. Mas se você é louco como eu, e usa um ambiente diferente, não vai se arrepender de mudar para o ROXTerm.

"Codifier"

No post sobre Dificuldades Técnicas, havia mencionado que criei um script para formatar trechos de código para postar aqui. Ei-lo:

#! /usr/bin/env ruby
if ARGV.size == 0
  puts "Usage: #{__FILE__} (files to format)"
end
File.open("out.txt", "w") do |out|

  ARGV.each do |filename|
    out.puts "<pre>"
    out.puts File.read(filename).gsub("<","<")
    out.puts "</pre>"
  end

end

Chamadas Periódicas Sem Atropelo

Recentemente, precisei criar uma página que fazia chamadas periódicas ao servidor, para saber se um determinado processamento longo havia acabado, e carregar os resultados no caso positivo. No Rails, a melhor maneira de se fazer isso é com a função periodically_call_remote, que dispara uma chamada AJAX em intervalos regulares. Mas, aí, como é de praxe, encontrei um pequeno problema quando o código foi para o ambiente de integração. As chamadas são assíncronas (o primeiro A do AJAX), acontecendo a cada X segundos, mas a chamada que finalmente carregava os resultados demora mais de X segundos para ser completa. Então, no meio do carregamento, uma outra chamada era iniciada e terminava justo a tempo de substituir a maravilhosa tela de resultados pela tela de "por favor espere".

Tornar as chamadas síncronas resolvia este problema, mas fazia o browser congelar completamente nos n*X segundos que a resposta demorava para carregar. Então, a saída que eu acabei utilizando foi criar uma variável de "estado", manipulada pelos callbacks do Prototype, para garantir que apenas uma chamada assíncrona executasse por vez.

Este é o resultado:

<script>
var stop_polling = false;
var polling = false;
</script>
<%= periodically_call_remote(
              :url => ping_search_search_results_url(@search),
              :method => :get,
              :frequency => 3,
              :condition => "stop_polling == false && polling == false",
              :after => "polling = true",
              :complete => "polling = false"
             ) %>

A primeira variável ("stop_polling") tem seu valor mudado pelo servidor quando os resultados ficam prontos. A segunda é alterara pelo próprio script para impedir que uma nova chamada seja executada enquanto a anterior ainda está esperando sua resposta. Com isso, o browser do usuário não congela.

Dificuldades técnicas.

Um dos motivos pelos quais eu não tenho escrito nada nesses últimos dias é porque eu quero postar exemplos de código, e o Blogger não é lá muito bom nisso. Achei alguns "add-ons" que fazem um bom trabalho, mas para instalá-los eu precisaria ter o controle do servidor onde os posts são hospedados. E se é para fazer isso, eu vou é criar a minha própria plataforma de "blog", eventualmente. Dizem que o Rails faz isso em quinze minutos, então vai ser uma boa oportunidade de aprendizado.

Por enquanto, vou usar um programinha que escrevi em dois minutos para embrulhar a amostra desejada em um par de tags "pre", e substituir todos os "<" lá dentro pela entidade HTML correspondente.

Um Pouco de Computaria Explícita

Ouvido na Internet:

"Dizer que Java é bom porque roda em qualquer plataforma é como dizer que sexo anal é bom porque 'funciona' com os dois sexos."

"Comentários em código são como sexo. Até mesmo quando são ruins, ainda são bons."

"Não, é a programação que é como o sexo. Se você cometer um pequeno erro, vai ter que sustentá-lo pelo resto da vida."

Tijolos

Este artigo sobre tijolos fala muito sobre o processo de desenvolvimento de software.