Esses dias estava trabalhando com uma aplicação web que tinha que mandar um e-mail de confirmação de cadastro. Fiz uns testes manuais e, por burrice minha, me cadastrei com um e-mail que existe e que não é meu! Minha sorte é que, na rede em que estava, a porta de envio de e-mails (SMTP) estava bloqueada. Isso fez com que meu e-mail ficasse preso na fila do Postfix para uma nova tentativa de entrega mais tarde. Pesquisando um pouquinho nos manuais do Postfix, descobri algumas coisas interessantes.

A primeira: como verificar a fila de e-mails. Um simples comando me mostrou que já tinha 99 e-mails para enviar.

mailq

Esse comando é, na verdade, um alias para um comando do Postfix:

postqueue -p


Agora, a parte mais importante: como remover esses e-mails antes que eles sejam enviados. Mais um simples comando, mas dessa vez como superusuário:

postsuper -d ALL

O ‘-d’ especifica quais e-mails da lista remover. Você pode ver o código na saída do comando ‘mailq’.

Ufa! Quase lotei a caixa de e-mails de alguém…

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Não sei se muitas pessoas tem esse problema, mas eu tenho mais de um par de chaves (no caso, tenho a minha para a conta jonasabreu do github e a da conta vidageek, também no github). Como era muito chato troca-las manualmente, fiz um pequeno script em bash para fazer isso para mim.
O script assume que as chaves atuais tem o nome de “id_rsa” e “id_rsa.pub” e as outras estão com um sufixo qualquer, como “id_rsa.vidageek” e “id_rsa.pub.vidageek”. O script deve estar na pasta .ssh .

#! /bin/bash

OLD_KEY=$1;
NEW_KEY=$2;

if [[ ! -f "id_rsa.$NEW_KEY" ]]; then
	echo "could not find id_rsa.$NEW_KEY";
	exit 1;
fi;

if [[ -f "id_rsa.$OLD_KEY" ]]; then
	echo "$OLD_KEY already exists";
	exit 2;
fi;

if [[ -f "id_rsa.pub.$OLD_KEY" ]]; then
	echo "$OLD_KEY already exists";
	exit 3;
fi;

mv id_rsa id_rsa.$OLD_KEY;
mv id_rsa.pub id_rsa.pub.$OLD_KEY;

mv id_rsa.$NEW_KEY id_rsa;
mv id_rsa.pub.$NEW_KEY id_rsa.pub;

Como chaves rsa são algo meio ruim de se perder, o script faz algumas checagens básicas, mas use-o por sua conta e risco :D

Usage:

./switch_keys.sh nome_das_atuais nome_da_que_vai_ser_ativada

Exemplo:

./switch_keys.sh jonas vidageek

Troca as chaves atuais jonas pelas que estão com a terminação vidageek .

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Ta aí um utilitário que deveria estar instalado por padrão no Gnome. Esse achado eu devo ao Pedro Matiello, colega meu de faculdade e de trabalho.

O Gnome Do é um acelerador de tarefas muito poderoso. Basta apenas pressionar o atalho configurado para ele e digitar uma ou duas teclas e pronto, você já fez o que precisava fazer: abrir o navegador (já com o site que você quer, se for o caso), o terminal, o gerenciador de pacotes, o seu jogo preferido, deslogar, tocar uma música, etc. É bastante extensível e customizável e ainda pode funcionar como um dock de aplicações. Você pode alterar o atalho que lança o aplicativo, ativar e configurar plugins. Dentre os plugins que eu uso estão o de indexação de arquivos, o de busca na Internet (OpenSearch, que te permite buscar em diversos serviços), o do Remember The Milk (ele até fica te alertando que você tem tarefas atrasadas!) e o de controle de sessão de usuário.

Em cada etapa do comando que você quer fazer, o Gnome Do faz busca em qualquer parte do nome dos itens pelas teclas que você digita. Por exemplo, se você digitar “t”, ele mostrar “Terminal” e, se você apertar a seta para baixo, vai ver uma lista com mais itens que contenham a letra “t”. Ao selecionar o item desejado, você pode escolher a ação apertando “Tab”. Nesse segundo passo, você também pode fazer busca digitando apenas algumas letras. Alguns itens também têm subitens, que podem ser acessados apertando a seta para a direita. Quando escolher a ação desejada, basta apertar “Enter”.

Esse utilitário é inspirado em utilitários semelhantes para o Mac OS X (Spotlight e Quicksilver, que eu saiba). Foi bom eu ter descoberto isso porque já estava ficando tentado a comprar um Mac quando vi as pessoas usando. Pena que ele ainda não é tão poderoso quanto os similares do Mac, mas já é de grande ajuda.

Imagem via valeriovalerio.org

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Recentemente passei a utlizar git em todos os meus projetos (depois de sofrer muito com a lentidão do sourceforge e outros repositórios svn).

Me atrapalhei um pouco no começo por não entender os conceitos por trás de repositórios distribuídos, mas no fim das contas o que realmente era importante é que o meu fluxo de trabalho tinha mudado e eu não estava entendendo isso direito até eu pedir para o Fábio Kung sentar do meu lado e me explicar o workflow com o git. Como muitos não tem a chance de fazer isso, aqui fica o que eu aprendi (e estou usando com frequência agora).

1. Clonar um repositório: Antes de mais nada você precisa ter um repositório para trabalhar. Com git, você faz isso clonando um repositório já existente (semelhante ao checkout do svn)

   git clone URL_REPOSITORIO PASTA_LOCAL_PARA_ARQUIVOS
   

   Com isso foi criado o seu branch principal, chamado master.

2. Criar um branch de trabalho: Uma das maiores vantagens do git é a facilidade com que você pode trocar de branch a fazer merge. Se você não usar branch, perde muito do que o git te proporciona.

   git checkout -b work
   

   checkout é o comando para você trocar de branch. Se você acrescentar um “-b”, ele também cria o branch pra você. Chamei meu branch de work, mas ele poderia ter qualquer outro nome.

3. Programe e faça commits pequenos: Como os commits feitos em git são sempre locais, você pode fazer commits bem pequenos, que são bem mais fáceis de fazer merge caso ocorra um conflito.

   git commit -a -m "mensagem de commit"
   

   Lembrem-se sempre de que mensagens de commit são importantes. Escreva mensagens que esclarecem o que foi feito.
   Além disso, a flag “-a” que eu coloquei ali indica para o git commitar todas as modificações que foram feitas. Se você quiser algo mais granular, pode usar:

   git add NOME_DO_ARQUIVO
   

   ou

   git add -i
   

   No qual você pode escolher os arquivos a commitar. Bem interessante.
   Não esqueça de fazer o commit sem o “-a” depois se for fazer assim.

4. Download de alterações que outras pessoas com acesso ao repositório tenham feito: Você não trabalha sozinho em geral e sempre que você for enviar algo para o repositório alguém já terá enviado antes. O que vamos fazer agora é trazer essas atualizações.

   git checkout master
   git pull origin master
   

   Na primeira vez que você tentar dar pull você tem que informar de onde (origin) e para onde (master). Depois você pode apenas usar git pull, porque o git é espertinho e lembra o que você quer.

5. Rebase do work: Como todas as suas modificações estão no work, você conseguiu trazer as modificações para a máquina, mas agora seu branch work está desatualizado com relação ao master. Essa é a maior maravilha do git. Você vai temporariamente remover as modificações do work, aplicar os commits que estão no master e reaplicar seus commits.

   git checkout work
   git rebase master
   

6. Resolvendo os conflitos: Pode acontecer do git não conseguir resolver algum dos conflitos de modificação. Quando isso ocorre ele para o rebase para que você resolva os conflitos, commit a commit e não tudo de uma vez como o svn.

   git mergetool
   git rebase --continue
   

   O git mergetool abre uma ferramenta visual para merging (facilita muito a vida). O git rebase –continue fala para continuar o rebase.

7. Enviando modificações para o servidor remoto: Quando você termina o rebase, seu repositório está novamente compatível com o do servidor remoto. Basta agora aplicar essas modificações no master e enviar para o remoto.

   git checkout master
   git merge work
   git push origin master
   

   O comando git merge work aplica seus commits no master. O git push envia para o servidor remoto. Novamente, na primeira vez que você tentar isso, o git ainda não sabe o que nem para onde você quer mandar. Por isso você precisa informar.

É um pouco mais trabalhoso que o svn, mas os ganhos são significativos. Vale a pena usar git direito. Eu não volto mais pro svn.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.