Archive for the ‘Programação’ Category
Interessantices
Depois de longo tempo sem postar, eis que eu lembro que tenho um blog novamente. ;) É que na verdade o plano era mudar o blog para outro servidor (junto do meu portfolio e um csv pra que eu possa subir alguns códigos interessantes), mas ainda não tive tempo.
No entanto, hoje eu tenho algo interessante pra postar, então lá vai. Eu costumo frequentar o fórum internacional do Arch, e nesse tópico um usuário deu uma idéia interessante: como seria possível copiar um arquivo entre TERMINAIS. Ou seja, você tem 2 terminais abertos (ou mais), e quer copiar um arquivo de um terminal para o diretório que está sendo usado no outro. Obviamente, você usaria algo como:
$ cp arquivo o-caminho-completo-de-onde-está-o outro-terminal
Mas isso é chato. Então eu pensei, que bom seria se eu pudesse simplesmente fazer:
$ cp arquivo /dev/pts/1
E a cópia iria para o diretorio em que o pts/1 está trabalhando. Bem, o comando cp não sabe funcionar assim. Mas ele também não sabe que eu fui treinado pelo MacGyver. Então, vejamos como implementar esse recurso usando minha linguagem preferida, Ruby (não confundir com Rails, POR FAVOR!):
#!/usr/bin/ruby
if (ARGV.empty?) || (ARGV[0] == "-h") || (ARGV.size < 2)
STDERR.puts <<EOS
Usage: #{$0} [-h] FILE TARGET
If TARGET is a terminal device (under /dev/), the copy operation will occur
to the terminal's current working dir. Otherwise, will behave like as a path.
EOS
exit 1
end
file = ARGV[0].to_s.strip
target = ARGV[1].to_s.strip
if File.directory? target
path = target
else
unless (pts = target.split("/dev/")[1])
STDERR.puts "Invalid target: #{target}"
exit 1
end
if (pid = `pgrep -n -t #{pts}`).empty?
STDERR.puts "Cannot determine pwd of device: #{pts}"
exit 1
end
path = `pwdx #{pid}`.split(": ")[1].strip
unless File.directory? path
STDERR.puts path
exit 1
end
end
`cp #{file} #{path}`
Esse script irá permitir copiar um arquivo apontando como alvo um terminal ao invés de um caminho, e vai se encarregar de encontrar o diretório atualmente usado. Se o terminal tem mais de uma shell aninhada (ou seja, se você abriu o terminal, e está rodando mais um shell dentro), ele irá usar o diretório do último shell chamado. Se ao invés de apontar um terminal, apontar um caminho, ele irá se comportar igual ao cp comum.
Minha sugestão de uso é copiar para /usr/local/bin/cpt e criar um alias no .bashrc:
alias cp='/usr/local/bin/cpt'
Outra sugestão também é colocar no .bashrc:
if [ "$DISPLAY" ]; then
echo -n -e "\e]0;`tty`\a"
fi
Com isso, todos os terminais terão como título o seu pts, assim fica fácil ver qual janela ou aba de terminal você quer destinar a cópia (só vai executar se for uma janela de terminal no Xorg, não no terminal em modo texto).
Por fim, você irá usar o comando, por exemplo:
$ cp arquivinho.txt /dev/pts/2
E bingo, seu arquivo vai estar disponível no seu outro terminal aberto, sem ter que quebrar a cabeça pra achar o caminho completo. Pra quem usa vários terminais abertos (eu), ou usa tilling window managers (xmonad, awesome), fica bem mais prático trabalhar.
Atenção: não sei como o script se comporta em shells não-Bash (zsh, csh), apesar de que no dash deve funcionar corretamente.
Apesar de nada ortodoxo (afinal, pela lógica do UNIX, copiar um arquivo para um device não faz sentido), o recurso é prático. Boa diversão!
Rails Rants
Dê uma olhada nos comentários do post sobre o release do Rails 2.0.2:
http://weblog.rubyonrails.org/2007/12/17/rails-2-0-2-some-new-defaults-and-a-few-fixes
De quase 100 comentários, 90% é de alguém reclamando, ou colocando debug info e esperando que alguém ajude a arrumar a sua aplicação quebrada depois da atualização (aliás, a seção de comentários é o PIOR lugar para se pedir ajuda).
O que isso me leva a crer?
Primeiro, que o estrelismo dos desenvolvedores do Rails vai cada vez mais voltar na forma de ofensas, agora que o hype diminuiu e que aquela aura de “web development made easy” pode ser arranhada com o menor dos problemas. Muita gente está adotando o Rails, e os desenvolvedores opinados™ vão continuar a fazer mudanças ao sabor do vento. Não entrando no mérito se isso é correto ou não, mas sim para ressaltar que é uma briga eterna para saber quem é o usuário do software: os próprios desenvolvedores ou o resta do mundo que usa? Será que os desenvolvedores tem alguma responsabilidade, apesar de não ser obrigada por nenhum termo ou contrato?
Segundo, que o projeto atraiu um público alvo que claramente não sabe como funciona um projeto opensource. Eles foram apresentados à ferramenta, mas não absorveram os conceitos de boas maneiras e comportamento. O resultado é uma catástrofe: quando a pessoa encontra uma dificuldade, ao invés de ler os release notes, se dirigir ao fórum/mailing-list, ou fuçar até descobrir o que há de errado, prefere choramingar na seção de comentários de um blog e amaldiçoar o projeto até a morte.
Enfim, estou curioso para saber qual será o futuro do Rails. Recentemente existiu um affair, buscando levar o Rails para o mundo corporate. Mas se o projeto ainda toma atitudes muito “radicais” (e gosta de marketear isso), e não apresenta nenhum tipo de responsabilidade com legado e com os outros, isso inviabiliza a adoção em massa. Para uma coisa o Rails serviu: motivou muitos outros projetos semelhantes, em diversas linguagens. As coisas vão ficar interessantes daqui pra frente. ;)
Flexibilidade é tudo
Tenho notado um padrão recorrente, onde as coisas mais interessantes a ocorrer na área da computação são fruto da aplicação de uma pequena regra básica: flexibilidade. Softwares ideais, assim como idéias e pessoas, deveriam ser flexíveis o bastante para se moldarem e para neles se encaixar a realidade (e não o inverso). Primando pela flexibilidade desde o início, ao contrário do que se pode imaginar, as coisas ficam menos complexas, as idéias mais concisas e as decisões mais duradouras.
Recentemente tenho testado a linguagem Ruby, criada por Yukihiro Matsumoto (saudações Nihon!), e fiquei impressionado em como é flexível. Ruby conseguiu unir todos os pontos positivos de diversas outras linguagens adotando uma estratégia simples: tudo é um objeto. Como tudo é um objeto, desde o tipos mais básicos como um número (classe Fixnum) até um bloco de código (classe Proc), você pode manipular e misturar coisas a vontade, de forma tão natural que mais parece estar moldando a realidade com pequenos blocos de Lego. Tudo graças, apenas, a adoção de uma abordagem flexível.
Mas deixa eu te contar um segredo: “orientação a objeto” é mais velho que sucrilhos Kelloggs. Se Ruby viu além, é porque estava sobre o ombro de gigantes. Antes mesmo do conceito de orientação à objeto chegar as linguagens, ele existiu em um sistema operacional, onde tudo também era um objeto: o UNIX, aquele sistema onde “tudo é um arquivo”, surgido no monte Olimpo, e que influenciou os sistemas mais inovadores de hoje, como Linux, Mac OS, QNX (usado em usinas nucleares, Windows nem pensar!) e Plan9 (mais uma vez a Bell Labs, estendendo o conceito de “tudo é um arquivo” ao máximo). E como o UNIX conseguiu ser tão parrudo assim, quase ganhando do Chuck Norris? Com o uso de Pipes, conceito criado por Douglas McIlroy. É um modelo tão flexível que tem dado certo por mais de 40 anos até agora. Ainda espero viver pra saber o que dura mais: a abordagem do UNIX, um fuzil AK-47 ou um Fusca.
O conceito de Pipe se baseia na idéia de pequenas caixas pretas (assim como objetos na programação), que podem ter suas entradas e saídas conectadas e redirecionadas de forma anônima (assim como métodos na programação), o que torna possível ter uma sequência de etapas de processamento de baixo acoplamento e grande coesão (mais uma vez, assim como na programação). Essa sequência de etapas forma o chamado pipeline, que seria equivalente a um programa, ou uma sequência completa do algoritmo do seu programa.
Ou seja, qualquer sistema cujo objetivo é processar informação, irá se beneficiar imensamente adotando uma abordagem flexível. Eu não sei como grande parte da indústria ainda não caiu na real e não começou a praticar Yoga e entoar “flexibilidade-hummmmmm” como se fosse um mantra em seus escritórios. Ao invés disso, insistem em engessar e proteger o maxímo possível suas plataformas com implementações imensamente complexas, duras, proprietárias. É quando elas não percebem grandes notáveis como Douglas McIlroy e Yukihiro Matsumoto passando, alterando tudo, e quando caem em si, já estão 10 anos atrasadas.
Se você quer um conselho para vencer e surpreender a todos, não só no âmbito do TI, mas para todos os aspectos da sua vida, aceite esse: seja flexível. Saber se articular ao invés de impor é uma habilidade recompensadora.
