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.

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.

A recomendação desse mês é o TidBits. O Danilo tem feito interessantíssimos experimentos com HTML5 e CSS3, sempre postando o código e explicando. Além disso, tem dicas, notícias e outros assuntos interessantes, principalmente para quem trabalha com front-end.

Você está desenvolvendo um plugin ou tema para WordPress e precisa fazer uma conexão HTTP? Não use fopen, curl, file_get_contents, etc. Use a HTTP API do WordPress.

A HTTP API é simples de usar, muito bem implementada e tem excelente performance.  E se um dia você precisar hospedar seu site num servidor debaixo de um proxy, não vai precisar reescrever seu código. Ao configurar o proxy no wp-config.php, tudo vai funcionar.

Veja um exemplo do uso da HTTP API:

$content=wp_remote_retrieve_body(
           wp_remote_get('http://visie.com.br/'));

Saiu a notícia hoje: Android ultrapassará Windows e será sistema mais usado do mundo, diz IDC.

Agora veja o gráfico:

Sistemas operacionais mobile navegando na web no Brasil de Fev/2011 a Fev/2012

Apesar disso, continuo recebendo das agências sites para construir que não tem versão mobile ou, quando tem, foi desenhada e deve ser construída para iPhone e iPad.

Cena comum numa reunião entre cliente e agência: todo mundo, de ambos os lados, coloca seu celular sobre a mesa. São todos iPhone. Logo, acho que até inconscientemente, eles deduzem que iPhone é o que importa. Alô pessoal! Vocês estão falando com 8,7% do público! Com um investimento semelhante, mas um pouquinho mais de planejamento, poderiam falar com praticamente todo mundo que está navegando no celular.

A maioria dos blogs sobre Ubuntu ou sobre Linux é escrita por hackers para hackers. O Ubuntu Dicas não. É sobre Ubuntu, e útil para qualquer um que use o sistema, não importa seu nível de conhecimento técnico. São excelentes dicas de programas, dicas de uso do sistema e notícias sobre o Ubuntu.

Recomendo.

É 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.

Acesse o HTML5 Please. Clique em use e dê uma olhada na lista. Agora clique em use with caution e confira a lista. Viu quanta coisa?

Por que a maioria dos exemplos de site em HTML5 brasileiros, dois anos depois de começarmos a usar esse treco, ainda são um mark-up levemente vitaminado e canvas?

Onde estão nossas aplicações offline? Web sockets? Drag-and-drop? Geolocation? Micro-data? Device orientation? Novos campos de formulário? SVG? History API?

Mas não tem demanda…

Você pode se desculpar por estar usando os mesmos velhos recursos de sempre, dizendo que os clientes da agência ou produtora onde você trabalha não querem os recursos novos, que seu chefe não quer saber dessas coisas, que tem trabalho pra caramba pra simplesmente recortar os layouts que recebe e não quer arrumar sarna pra se coçar…

Você vai mesmo querer passar o resto da vida recortando layouts? O mundo vai mudar, e você vai ser extinto, dinossauro. Se não tem demanda, crie a demanda. Comece a desenvolver projetos pessoais com o que você acha que seus clientes deveriam estar usando. Em seguida, mostre para todo mundo. Você vai ver se a demanda não aparece.

Todo mundo tem celular conectado. Todos os navegadores (até o IE) estão se esforçando para funcionar direito. É um momento mágico. É uma oportunidade que você não quer deixar passar. Um pouquinho de esforço aí, galera.

O Miguel parou de blogar, o último post dele tem mais de seis meses. Ele tem publicado exclusivamente o videopodcast Man in the Arena.

O que é excelente. É claro que se o Miguel tivesse tempo para escrever um novo bom post por dia e ainda manter o Man in the Arena funcionando, todos adoraríamos. Mas isso me parece, claramente, pedir demais.

O Man in the Arena é um dos podcasts mais inteligentes e relevantes que eu conheço para quem se interessa por empreendedorismo. Eles estão trabalhando agora na temporada 2012, mas se você não conhecia, por favor, assista desde o primeiro. Vai achar inspirador.

Na última quinta-feira, indo para casa, fui assaltado. Havia deixado o Peka e o Hugo em casa, e estávamos eu a Dani no carro. Levaram meu computador, um Mac que eu estava usando para desenvolver um projeto, meu iPad e meu celular. Da Dani levaram computador, celular, documentos e dinheiro.

Passado o susto, fui na quinta à noite mesmo comprar um computador para repor o que haviam levado. É minha ferramenta de trabalho, não posso ficar sem. Comprei um Vaio VPCSB25FB, instalei Xubuntu 11.10, a passei a sexta-feira e o domingo colocando as coisas no lugar nele e num Mac Mini que eu já tinha e vou usar no lugar do que levaram.

Algumas lições:

  1. Criptografe sua pasta pessoal: dormi mais tranquilo sabendo que a minha estava criptografada.
  2. Cloud rulez: meus contatos, agenda e e-mails estão no Google. No dia seguinte, mesmo sem meu celular, consegui conferir meus compromissos e ligar para quem eu precisei. Meus projetos estão todos no Git e os arquivos pessoais todos no Dropbox. Perdi no total uns quatro dias de trabalho, a maior parte desse tempo reconfigurando as coisas.
  3. Tenha seguro: eu não tinha seguro das minhas coisas. Quando procurei, me pareceu muito caro. Quando levaram minhas coisas, comecei a achar o seguro barato.
  4. Tenha backup: tenho uma conta Pro 100 no Dropbox. Custa 20 dólares por mês. É barato.

É isso. Passou o susto. Vamos trabalhar bastante agora, pra pagar as coisas novas.

Update: excelente post do Maudy Pedrão: Instale o PREY no Ubuntu e não perca de vista o seu notebook.

Dica: ao iniciar o desenvolvimento com Python em uma máquina nova, procure pelo arquivo sitecustomize.py e acrescente:

import sys
sys.setdefaultencoding('utf-8')

O arquivo sitecustomize.py é automaticamente executado toda vez que você executa o Python (sim, você pode fazer o que quiser nele…) Ele fica em lugares diferentes dependendo da plataforma e da sua instalação do Python. No Ubuntu, fica em /usr/lib/python2.7/ (trocando 2.7 pela versão que você estiver usando.) As linhas acima configuram o encoding padrão como Unicode UTF-8. Claro, você pode configurar outro encoding como o padrão, se preferir.

Recomendo muito que, se você não entende nada de charsets ou nem sabe do que estou falando, use UTF-8.

Palestra apresentada na TDC 2011. Tentei separar os recursos do HTML5 em quatro grupos:

  1. O que você já pode usar hoje;
  2. O que você já pode usar hoje, mas oferecendo alternativas Javascript para navegadores sem suporte;
  3. O que você já pode usar hoje, mas só para plataformas específicas;
  4. O que não sabemos ainda quando poderá ser usado.