Tag: Linux

Pequena dica de Linux: CDPATH

Quando você executa o trivial comando cd o shell (seja o bash ou o zsh) procura pelo diretório informado nos caminhos indicados na variável de ambiente CDPATH. Se não houver uma variável CDPATH, o shell procurará no diretório atual. Veja:

elcio@vaio:~$ cd 5cms
bash: cd: 5cms: Arquivo ou diretório não encontrado
elcio@vaio:~$ export CDPATH=.:~/projetos
elcio@vaio:~$ cd 5cms
/home/elcio/projetos/5cms
elcio@vaio:~/projetos/5cms$ pwd
/home/elcio/projetos/5cms

Eu costumo editar meu .zshrc (edite o .bashrc se você usa bash) e incluir no final:

export CDPATH=.:~:~/projetos

Assim, sempre que eu executar um cd o shell vai procurar primeiro no diretório atual, em seguida no meu diretório home, por fim no meu diretório de projetos.

Extraindo o áudio MP3 de um vídeo com ffmpeg

Gosto bastante de alguns videopodcasts, como o Roda e Avisa e o Man in the Arena. Mas o tempo que tenho para ouví-los é quando estou dirigindo. Nesse momento, o fato de serem em vídeo não significam nada. Tê-los em MP3 é muito mais prático para mim, que assim consigo ouví-los no som do carro.

Para baixar os vídeos tenho usado o Easy YouTube Video Downloader. Meu próximo projeto pessoal é automatizar isso de alguma maneira, quem sabe com Miro.

Depois, para extrair apenas o áudio, em MP3, faço:

ffmpeg -i entrada_video.mp4 -vn saida_audio.mp3

Simples e rápido. E fácil de automatizar.

Lendo os logs do nginx com pipes e PHP

Um amigo me perguntou hoje sobre soluções NoSQL. Na conversa que se seguiu, descobri o que ele precisava fazer: precisa publicar um servidor cujas URLs vão simplesmente fazer um redirect para outro site, mas devem guardar as informações do redirect para enviar para o Clicky. É claro que os dados devem ser enviados ao Clicky o mais rápido possível, para que as estatísticas sejam atualizadas e o cliente do meu amigo possa acompanhar as estatísticas em tempo real. Mas o mais importante é que o redirect seja feito rapidamente, e que o serviço aguente tráfego massivo.

Meu amigo pensava em usar nginx com PHP e uma solução de NoSQL. Eu expliquei a ele que era uma ideia mais complicada do que precisava. O ideal, nessa situação, é dividir os problemas. O nginx poderia sozinho cuidar dos redirects, sem PHP, com uma performance impressionante. E ele poderia em seguida fazer algo que lesse o log do próprio nginx e enviasse os dados dados ao Clicky.

Meu amigo programa bem em PHP, então vamos fazer oq ue pudermos nessa linguagem. Veja um exemplo simples de como isso funcionaria: podemos criar um shell script simples que vai simplesmente executar um tail -f no log do nginx e redirecionar a saída para um script PHP.

O comando tail -f é muito interessante. Deixe uma janela de terminal aberta em seu Linux com:

tail -f /var/log/syslog

Você vai ver que o tail, com -f, imprime o final do arquivo mas não sai. Ele fica monitorando o arquivo e quando novas linhas são acrescentadas, ele as envia para a saída padrão (nesse caso, a tela.)

Então nosso shell script, chamado monitor.sh, terá o seguinte conteúdo (troque o caminho do arquivo de log pelo caminho onde ele fica em seu sistema):

tail -f /var/log/nginx/access.log | php monitor.php

Isso vai manter o script rodando, enviando cada nova linha no log para o monitor.php. Cada vez que o nginx processa uma requisição ele envia nova linha para esse arquivo. O monitor.php pode ter algo assim:

<?
$stdin = fopen('php://stdin', 'r');

while($l=trim(fgets($stdin))){
  // Aqui $l contém uma linha do log do nginx.
  // Faça o que quiser com isso. Como exemplo
  // vou só tratar os dados e imprimir.
  $l=split(';',preg_replace('/( |\t)+/',';',$l));
  $l[3]=substr($l[3],1);
  $l[5]=substr($l[5],1);
  if($l[5]=='GET' or $l[5]=='POST')
    echo "$l[0] $l[3] $l[5] $l[6]\n";
}

Por fim, falta deixar isso rodando. O jeito mais simples é deixar uma sessão de screen aberta com o comando. Basta rodar o comando screen, executar o monitor.sh no shell que vai se abrir e sair com CTRL+D. Claro que há jeitos melhores de deixar isso rodando. O ideal é transformar esse script num daemon. Mas a solução com screen é suficiente para iniciar no assunto.

JABÁ: para entender melhor os detalhes e aprender mais truques como esse, vá ao Workshop de Linux para Desenvolvedores.

Configurando o locale no Ubuntu

É um problema comum ao configurar um novo servidor com Ubuntu, descobrir que não há um locale válido configurado, ou descobrir que o locale padrão não é o que você desejava. Os sintomas comuns de um sistema sem um locale válido são as seguintes mensagens:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Ou essa outra, bem mais assustadora:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LC_CTYPE = "pt_BR.UTF-8",
   LANG = "en_US.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Os sintomas de um locale diferente do que você gostaria são mensagens em algum idioma estranho.

Como corrigir? Vou postar aqui, porque esse arquivo fica num local muito inusitado, em minha opinião. Não está em /etc. Edite, como root, o arquivo:

/var/lib/locales/supported.d/local

E coloque os locales que você quer que o sistema suporte. A maioria dos usuários brasileiros vai se dar bem com esse conteúdo:

pt_BR ISO-8859-1
pt_BR.UTF-8 UTF-8

No meu caso, como faço questão de trabalhar exclusivamente com Unicode, eu deixo esse arquivo assim:

pt_BR.UTF-8 UTF-8

Em seguida rode:

sudo dpkg-reconfigure locales

Isso deve resolver o problema.

Meu ambiente de trabalho em 7 itens

O Mike me convidou, então lá vai:

1. Ubuntu

O sistema operacional que simplesmente funciona. Meu notebook tem Ubuntu, o da minha mulher e os dos meus filhos também. Todos tem o Windows OEM em dual-boot. Nem me lembro quando foi a última vez que vi alguém bootar o Windows lá em casa. Aqui na Visie o Ubuntu também parece ser o sistema predileto de todo mundo que não tem um Mac 😉

Sem brincadeira, se você desenvolve para um sistema Unix-like, deveria usar um. Você vai ter o mesmo modelo de permissões, a mesma estrutura de arquivos e as mesmas ferramentas na sua máquina e na hospedagem. Você vai ter shell script. Um dia desses resolvemos um problema em um projeto criando um link simbólico para um arquivo. Essa solução roda em nossos servidores e em nossos desktops.

2. Git

Ainda encontro muitas empresas por aí que não usam controle de versão. Pode parar de rir, estou falando sério. Eu não entendo como alguém pode escrever software sem um bom sistema de controle de versão distribuído.

3. web2py

O framework de desenvolvimento web mais produtivo que eu já achei.

4. Vim

Vim não é fácil, e deve ser mantido fora do alcance de crianças e animais domésticos. Mas é o editor de código mais rápido do planeta. Extremamente poderoso, indispensável para o bom programador.

5. Firefox e Firebug

O desenvolvimento de HTML, CSS e Javascript se divide em duas eras: antes e depois da Firebug.

6. OpenDNS e Dnsmasq

Nós até conseguimos comprar boas conexões aqui no Brasil. Mas os serviços de DNS de todos os provedores que eu conheço são uma piada.

7. Terminator

Com o Terminator posso dividir uma janela em vários terminais, em abas. Para quem usa vim e muito shell, é uma mão na roda.

E eu vou convidar:

Diego Eis, Ederson Peka, Luciano Motta, Mauro Baraldi, Leandro Lima e Pedro Rogério.

Rodando Google Gears no Ubuntu 10.10 (Maverick) 64bits

Se você, como eu, usa Ubuntu 64bits e se viu privado de usar o Gmail Offline ao migrar para a versão 10.10 (Maverick), aqui está a solução: instale o pacote do Google Gears da 10.04 (Lucid).

Baixe aqui: xul-ext-gears_0.5.36.0~svn3423+dfsg-0ubuntu1_amd64.deb.

Codificar vídeo no Linux para iPod, iPhone, Android, PSP, etc? Transmageddon

O vídeo possui duas ferramentas fantásticas para a conversão de vídeo: ffmpeg e mencoder. Mas são ferramentas de linha de comando e nada fáceis de usar. Veja, por exemplo, como ripar DVDs para DivX com mencoder. Se a origem, ao invés de um DVD, for um arquivo mpeg, isso tudo muda bastante. Se a saída, ao invés de DivX, for mp4, muda bastante também.

Conheci recentemente o Transmageddon, ferramenta fantástica. Veja um screenshot:

Transmageddon

Se você clica em “Pré-definições”, por exemplo, veja a lista que aparece:

Transmageddon

Serve para quase tudo o que você pode querer fazer convertendo vídeo. Sem dor. Vale a pena experimentar.

O Linux também fala

Há um tempo eu ensinei aqui como fazer o Mac falar. O Linux também faz. Instala aí:

$ sudo apt-get install espeak

Daí é só mandar:

$ espeak "Luke, I am your father."

E fala português também:

$ espeak -v pt "Luke, eu sou seu pai."

Com -f arquivo.txt, ele lê o texto de um arquivo. Com -w arquivo.wav, ele salva o áudio num arquivo. E pode ser comandado via ssh.

Consegue imaginar utilidades para isso?

Exportando MySQL para CSV

Criei agora um pequeno script para resolver um problema meu, um exportador de base de dados MySQL para arquivos CSV. Resolvi compartilhar:

MySQL2CSV

Para baixar, você vai precisar do git. No Ubuntu, para instalar, faça:

$ sudo apt-get install git-core

Depois, para baixar:

$ git clone git@github.com:elcio/mysql2csv.git

Isso vai criar a pasta mysql2csv, com o script dentro. Você pode copiá-lo para a pasta /usr/local/bin/ e dar permissão de execução se for usar com muita freqüência:

$ cd mysql2csv
$ sudo cp mysql2csv.py /usr/local/bin/mysql2csv
$ sudo chmod +x /usr/local/bin/mysql2csv

Se fizer isso, vai poder chamar, em qualquer diretório:

$ mysql2csv host user passwd dbname

Rodando comandos do sistema operacional com cache no Python

Código simples, mas que pode ser útil para alguém não ter que escrevê-lo de novo (arquivo runcached.py):

import os,time
cachepath='cache'
timeout=360
 
def runcached(cmd):
  filename=os.path.join(cachepath,str(hash(cmd)))
  if os.path.isfile(filename):
    if time.time()-os.path.getmtime(filename)<timeout:
      return open(filename).read()
  t=os.popen(cmd).read()
  open(filename,'w').write(t)
  return t

A função runcached roda comandos do sistema operacional, e faz cache do resultado por 6 minutos. Para alterar o tempo do cache, basta mudar a variável timeout. Por exemplo, para cachear por 10 horas:

import runcached
runcached.timeout=36000
r=runcached('lynx --source http://www.tableless.com.br')

Navegação rápida com o Google Public DNS

Uma coisa que sempre me espantou é a ineficiência dos servidores de DNS dos provedores de hospedagem brasileiros. Já testei ADSL, cabo coaxial, 3G e, aqui em São Paulo, de maneira geral as conexões são boas. Mas como o servidor de DNS dos provedores é ruim, a navegação é muito lenta.

Eu vinha usando OpenDNS, cuja performance é muito boa. Mas hoje resolvi testar o Google Public DNS. Deixa o OpenDNS no chinelo!

Como o Google conseguiu isso? Um mega sistema de cache, com cobertura global, e um inovador sistema de prefetching. Se você não está usando ainda, vale a pena testar.

Para facilitar a vida dos usuários de Linux, segue meu /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

Sim, são esses IPs mesmo 😉 Não é fantástico?

Sobre Windows, Linux, paixões e times de futebol

Discussões sobre o melhor sistema operacional, o melhor navegador ou a melhor linguagem de programação tendem a entrar em loop infinito. Cada um dos lados parece achar o outro um completo idiota por não se convencer de suas opiniões.

Semana passada troquei algumas mensagens com o René de Paula que me fizeram pensar bastante sobre o assunto. O René provavelmente não me conhece, mas eu tenho aprendido muito com ele nos últimos anos, principalmente em seu podcast, o Roda e Avisa. E esse post não é um desabafo “estou chateadinho”. Estou citando o nome do René porque a conversa se deu no Twitter, ou seja, em público, e realmente me fez pensar.

O René recomendou esse artigo da ZDNet, analisando um estudo de segurança dos navegadores web. O artigo começa apresentando os resultados do estudo, em que o Internet Explorer ganha de lavada, e segue explicando porque, na opinião do autor, o estudo patrocinado pela Microsoft é tendencioso e irrelevante.

Respondi ao René dizendo que concordava com o artigo que ele havia indicado, que realmente o estudo era tendencioso. E usei a frase “o rei está nu.” Para mim, a crônica da roupa nova do rei é uma excelente metáfora para a situação. Ele me respondeu que havia visto meu blog e que achava que havia um “viés oculto” em tudo o que eu dizia. Em seguida twittou sobre o fato de as pessoas tratarem essas discussões como se fossem sobre times de futebol. Isso me fez pensar um bocado.

Eu gosto de, numa discussão, ouvir o outro lado. Também gosto muito de lógica. Se tem uma coisa que eu vou defender numa discussão, mais do que meu time de futebol, é o bom uso da lógica. Tento nunca ser irrazoável. Sei que todos somos tendenciosos, mas sempre tento ser mais imparcial que a média.

Talvez seja o fato de a discussão ter acontecido no Twitter, meio pouco propício, mas confesso que fiquei muito preocupado com a impressão que o René teve. Quem me conhece, sabe, trabalho com Linux, Windows ou Mac, sem rabo preso, escolhendo sempre o jeito mais simples de resolver cada problema.

Cada cabeça, uma sentença

Em primeiro lugar, não há um sistema operacional “melhor” e outro “pior”. Há um “melhor para você”. O fato de aquele seu amigo usuário de Windows não ter enxergado ainda que o Linux é o melhor sistema operacional do mundo talvez seja porque, para o perfil de uso dele, o Windows seja realmente o melhor sistema operacional.

Dificilmente eu tento convencer alguém a usar exclusivamente Linux. Sempre tento convencer as pessoas a experimentar. Se o sujeito me diz que é um heavy gamer, por exemplo, recomendo o uso de Windows. Sei, o Wine está muito evoluído e tal, mas se ele tem dinheiro para pagar as licenças e pode rodar a versão mais nova de cada jogo no ambiente em que ele foi feito para rodar, por que complicar?

Sim, não me esqueci, para certos perfis de uso, Mac OS X também é um sistema fantástico. Estou quase comprando um para minha mulher.

Existem, porém, padrões absolutos

O fato de não existir uma solução “bala de prata” e a paixão que costuma cercar essas discussões têm levado muita gente, principalmente programadores, a uma posição morna tão irrazoável quanto os extremos. É comum ouvir frases como “a melhor linguagem é aquele com a qual você sabe trabalhar” ou “a melhor ferramenta é a que resolve seu problema.”

Acredito sim que há casos de uso os mais variados. Mas, dentro de determinado caso de uso, há métricas objetivas que você pode usar para dizer o que é melhor. Falando em linguagem de programação, por exemplo, a melhor não é aquela que faz você se “sentir bem”. A não ser que programar para você seja só um hobby, a melhor é aquela que vai te permitir resolver mais rápido o problema do cliente, com a qualidade e a performance necessárias.

Dado um determinado problema do cliente, e uma determinada métrica de performance, deve ser possível apontar a melhor linguagem para essa situação.

Que problema seu software se propõe a resolver?

Se você é desenvolvedor de software, é importante entender isso. Você dificilmente vai encontrar uma oportunidade de desenvolver um produto que é o melhor para todo mundo. Não há unanimidades.

Você pode desenvolver algo que é o melhor para a maioria, pode achar uma minoria endinheirada, ou pode desenvolver algo legal para você mesmo e torcer para que haja gente parecido com você lá fora.

Mas, se você tentar ouvir todas as sugestões que receber e superar os concorrentes em absolutamente todos os perfis de uso, nunca vai terminar de desenvolver.

Mente aberta

Na Visie hoje temos 7 máquinas Windows, 6 Linux e 3 Macs. Sem contar as VMs, o ambiente de testes, e os servidores onde estão hospedadas as aplicações. Desenvolvedor, abra sua mente. Aprenda uma linguagem de programação nova, experimente outro sistema operacional, teste outra solução. Você vai aprender muito.

Aprenda Python, Ruby, Haskell ou Scala. Isso vai tornar você um melhor programador PHP, Java ou .Net. Desenvolva um projeto com uma banco de dados não relacional (estou usando MongoDB em um projeto.) Se você ama WordPress, faça alguma coisa com Joomla, e vice-versa. Tente outro framework, outro editor, outro jeito.

Sobre navegadores

No dia seguinte a essa conversa estive no escritório do W3C Brasil, assistindo ao Café com Browser com o pessoal do Internet Explorer.

Eles passaram boa parte do tempo falando sobre os recursos do navegador para o usuário final. Coisas como abas (oh!) e favoritos mais legais, webclips, processos independentes em cada aba, melhorias de performance e segurança. Tudo muito interessante mas, eu acho, apresentado para o público errado. Estávamos dentro do W3C, afinal de contas. Queríamos saber sobre as melhorias para o desenvolvedor.

Ao final, a palestra sobre melhorias para o desenvolvedor foi, para mim, parte surpreendente, parte decepcionante. Me surpreendi principalmente pela reação dos desenvolvedores no Twitter. Muita gente não conhecia as developer tools do IE8, ou os modos de compatibilidade, por exemplo. Quando foi apresentado o querySelector, muita gente twittou revoltada, porque a Microsoft estava “inventando um novo jeito proprietário de fazer as coisas”. Gente, o querySelector é uma recomendação do W3C (está em Working Draft, mas está lá.)

A parte decepcionante, expressei em minha pergunta:

Em suma, não tenho ódio da Microsoft ou de quem quer que seja. Não quero que o Internet Explorer suma do mapa. Ainda tenho projetos em ASP, VB e .Net, e sou feliz com isso. Só quero poder desenvolver uma vez só minhas aplicações. Quero não ter que cobrar do cliente pelo custo de fazê-la funcionar no Internet Explorer. Quero entregar mais rápido aplicações melhores, mais estáveis, com menos código.

Instalando o CouchDB e o Python-CouchDB no Ubuntu 8.10 (Intrepid)

Não a versão do repositório, mas a mais nova.

Só a sequência de comandos, que eu estou com pressa agora:

sudo apt-get install build-essential erlang libicu38 libicu-dev libmozjs-dev automake autoconf libtool help2man libcurl-ocaml-dev subversion python-setuptools
mkdir ~/src
cd ~/src
svn co http://svn.apache.org/repos/asf/couchdb/trunk couchdb
cd couchdb
./bootstrap && ./configure && make && sudo make install
sudo adduser --system --home /var/lib/couchdb --no-create-home --shell /bin/bash --group --gecos "CouchDB Administrator" couchdb
sudo chown -R couchdb /usr/local/var/lib/couchdb/
sudo chown -R couchdb /usr/local/var/log/couchdb/
sudo easy_install simplejson
sudo easy_install httplib2
sudo easy_install couchdb

Brincando com a API do twitter

Resolvi experimentar um pouco a Twitter API. É linda, do jeito que toda API deveria ser. É REST, muito fácil de entender e colocar para funcionar, e devolve dados em XML, JSON, RSS e ATOM.

Essa simplicidade permite interagir com a API usando ferramentas simples da linha de comando do Unix, como o wget e a cURL. Para nossos exemplos, vamos usar cURL. Se você usa Ubuntu, antes de começar faça:

sudo apt-get install curl

Para fazer um simples post, por exemplo, você pode digitar, em seu terminal:

curl -u seu_username:sua_senha -d status="Twittando do terminal. Aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/" http://twitter.com/statuses/update.json

É isso mesmo, meninos e meninas, é só um post com autenticação, mais nada. RESTful, simples e elegante, deixar qualquer SOAP no chinelo. Inspirador para qualquer um que precise projetar uma API. Isso retorna dados em JSON. Se você quiser os mesmos dados em XML, ATOM ou RSS, basta mudar a extensão na url.

Agora vamos automatizar isso. Eu criei um arquivo /usr/local/bin/twitter com o seguinte conteúdo:

source $HOME/.twitter
curl -u $user:$password -d status="$@" http://twitter.com/statuses/update.json

Naturalmente, criei o arquivo como root e dei permissão de execução para todos os usuários. Agora, no diretório de cada usuário, basta criar um arquivo .twitter com o seguinte conteúdo:

user=seu_username
password=sua_senha

Pronto, tendo feito isso, qualquer usuário que tenha o arquivo .twitter em seu home pode twittar do terminal com:

twitter "Twittando do terminal, aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/"

Simples e indolor, agora você pode automatizar suas twittadas com shell script. Pode, por exemplo, twittar toda vez que seu servidor baleiar, ou agendar twits com cron.

Search API

A Search API também é espetacularmente simples, dê uma olhada. Fiz a UPBox usando a Twitter Search API, por exemplo, com 22 linhas de código.

Fuja da complexidade

Abri o OpenOffice Writer, mandei gravar uma macro, escrevi “teste”, selecionei e pintei de vermelho. Olha o código gerado:

sub Main
rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
rem ----------------------------------------------------------------------
dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "Text"
args1(0).Value = "teste"
dispatcher.executeDispatch(document, ".uno:InsertText", "", 0, args1())
rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:SelectAll", "", 0, Array())
rem ----------------------------------------------------------------------
dim args3(0) as new com.sun.star.beans.PropertyValue
args3(0).Name = "FontColor"
args3(0).Value = 16711680
dispatcher.executeDispatch(document, ".uno:FontColor", "", 0, args3())
end sub

Há muito código complexo por aí. Nesse caso, para invocar os métodos dos objetos do OpenOffice, é preciso usar um objeto dispatcher, chamando executeDispatcher, e passando o objeto, o nome do método e um array de argumentos. Que espécie de sadismo leva alguém a projetar uma solução como essa? Vale lembrar o que diz o Zen do Python:

Se uma implementação é difícil de explicar, é uma idéia ruim.

Outro exemplo interessantíssimo é o protocolo SOAP. Se você precisar construir um serviço SOAP do zero, dê uma investigada na documentação que você vai ter que ler. Compare com a documentação do protocolo XML-RPC, para ter uma idéia.

Meninos, o tio vai ensinar um segredo a vocês, a complexidade se reproduz assexuadamente. Há muito código complexo demais por aí. Se você encontrar indícios de complexidade hoje, corte antes que ela se reproduza, porque ela tende a fugir do controle. Cada vez que você deixa uma implementação complexa num componente de um sistema, você está complicando um pouquinho todos os pontos do sistema que usam aquele. Os resultados ruins são exponenciais. Por mais talentoso que você seja, se deixar a complexidade se enraizar e crescer, vai chegar um momento em que a lógica vai “jogar a toalha” e você vai começar a programar na base da tentativa e erro.

Lembre-se, então, partes simples, conectadas por interfaces simples. Complicado é errado, feio e mau, faz você entregar atrasado e com bugs. E, se precisar de inspiração, abra o Python e digite:

import this