sexta-feira, 14 de março de 2014

Adicionando o nome do branch em todos os commits do git

*obs: testei isso rodando no Ubuntu 12.4, não tenho certeza se funciona no Mac e no Windows

Com este hook o nome do branch será colocado no começo de todos os commits do git

Por exemplo se fizer isso no branch [historia_1]

git commit -am "lala popo"

A mensagem gravada será "[historia_1] lala popo"

Segue o passo a passo de como configurar o git para isso:

- Se estiver usando o git acima da versão 1.7.1, é possível deixar o hook global deste jeito

git config --global init.templatedir '~/.git_template'

- Depois disso, criar o arquivo abaixo

~/.git_template/hooks/prepare-commit-msg

- Colocar o conteudo abaixo:

#!/bin/bash

FILE=$1

if [[ "$git_status" =~ On\ branch\ ([^[:space:]]+) ]]; then
    BRANCH_NAME=${BASH_REMATCH[1]}
    test "$branch" != master || branch=' '
else
    # Detached HEAD.  (branch=HEAD is a faster alternative.)
    BRANCH_NAME="`git describe --all --contains --abbrev=4 HEAD 2> /dev/null ||
        echo HEAD`"
fi

echo $1

if [ -n "$BRANCH_NAME" ] && [ "$BRANCH_NAME" != "master" ]; then
    sed -i.bak -e "1s/^/[$BRANCH_NAME] /" $FILE
fi

- Salvar o arquivo e colocar permissão chmod 755

A partir desse ponto, todos os repositórios clonados e inicializados terão este hook, para os já existentes, precisa rodar o comando git init que carregará o hook global.

terça-feira, 14 de janeiro de 2014

PostgreSql migrando da versão 9.2 para a 9.3

No Debian/Ubuntu existe um jeito simples de fazer um upgrade da versão 9.2 para a versão 9.3 do PostgreSql com os comando pg_upgradecluster (http://manpages.ubuntu.com/manpages/jaunty/man8/pg_upgradecluster.8.html).

Basta seguir o procedimento abaixo:

sudo apt-get install postgresql-9.3
sudo /etc/init.d/postgresql stop
sudo pg_dropcluster --stop 9.3 main
sudo pg_upgradecluster 9.2 main

Após isso, é possivel rodar o comando pg_lsclusters para verificar que a versão 9.3 está ok.


quarta-feira, 6 de fevereiro de 2013

Lumosity - You have the power to improve your brain

Hoje vou falar do site lumosity.com

O Lumosity é um site com vários jogos feitos para treinar o cérebro.

Segundo eles, os jogos treinam 5 diferentes áreas:

  • velocidade
  • memória
  • atenção
  • flexibilidade
  • resolução de problemas

Ao criar uma conta, você escolhe quais áreas deseja melhorar e quais tem preferência no treinamento.

Todos os dias, são 5 jogos selecionados de acordo com seu perfil. Eles dizem que treinar o cérebro deve ser um costume como escovar os dentes, deve ser feito todos os dias e assim terá resultados no futuro.

Uma das partes mais legais é acompanhar o gráfico de evolução das suas habilidades e como você se compara com as outras pessoas da sua mesma faixa etária. A seguir coloquei um print dessa tela:


 Para experimentar é possível criar uma conta trial e jogar por 3 dias.

Eu não consegui resistir e estou pagando um plano mensal para poder continuar, até minha esposa está treinando e gostando!

A dica é fazer um plano familiar, fica mais barato por pessoa, inclusive tenho vagas no meu plano, se alguem tiver interesse me avisem!

sexta-feira, 18 de janeiro de 2013

sexta-feira, 13 de abril de 2012

Importação de dados em massa no MongoDB com Mongoimport

No mysql quando precisamos inserir grande quantidade de registros podemos utilizar o comando LOAD DATA, no MongoDB temos o comando mongoimport, vou falar de algumas coisas que percebemos ao utilizá-lo
obs: Nossa implementação foi feita em Rails + Mongoid

Utilização básica


Após alguns testes, decidimos utilizar a importação com algumas opções, como abaixo:

mongoimport -d [DB_NAME] --upsert --stopOnError -c [COLLECTION] [IMPORT_FILE]
onde:
  • DB_NAME: nome do database
  • --upsert: atualiza documentos que já existirem (abaixo falarei mais sobre isso);
  • --stopOnError: interrompe a importação caso ocorra algum erro em alguma linha do arquivo de importação;
  • COLLECTION: nome da collection;
  • IMPORT_FILE: arquivo com os os dados a serem importados (falarei mais sobre isso)

Opção --upsert


Quando utilizada a opção --upsert, ao importar uma linha, o mongo irá procurar se existe algum documento com esse ID no banco e se existir sobrescreverá esse pelo que está no arquivo de importação, mas atenção, ele não faz e não tem como fazer um MERGE, que é uma feature request no mongodb, ele irá sobrescrever todos atributos desse documento!

Se não utilizada a opção --upsert, as linhas que já existirem no mongo serão ignoradas pela importação

Arquivo de importação


Para rodar o mongoimport, é preciso gerar um arquivo de importação seguindo o exemplo na documentação do mongoimport

É preciso tomar cuidado ao gerar esse arquivo, por exemplo alguns campos como created_at e updated_at que são criados automaticamente ao inserir um novo documento, não são criados se não forem colocados nesse arquivo de importação. Também precisamos tomar cuidado com os campos de relacionamento, mesmo que esse documento não esteja relacionado, é preciso colocar no json o campo com o valor vazio.

Na nossa implementação para geração desse arquivo, fizemos um metodo to_mongo_json no modelo a ser importado, para que gerasse o json esperado pelo mongoimport de cada documento.

Para isso utilizamos o método attributes para pegar todos atributos do documento e gerar o json, além disso precisamos converter alguns valores (data, object_ids, etc..) de acordo com essa página

Velocidade de importação


Ao rodar o comando mongoimport, é impresso a taxa de importação. Nos testes que fizemos chegamos a taxas de até 9mil documentos por segundo, muito rapido! Se fizéssemos o create de cada documento individualmente no Rails, demoraria muito mais.

Atualização de documentos existentes


Como no mongoimport não existe a opção de merge dos dados, como mencionado acima, a solução seria gerar o json desse documento com todos os dados existentes e rodar o mongoimport com a opção --upsert. Assim poderíamos ter problemas, pois se enquanto a importação estivesse sendo processada, se um documento fosse atualizado pela aplicação, e ele já tivesse seu json gravado no arquivo de importação, ao rodar o mongoimport, os dados atualizados nesse meio tempo seriam perdidos.

O ideal nesse caso seria atualizar somente os novos dados com uma opção de merge que não existe, como falamos acima. Nossa solução foi separar os documentos que já existem no mongo dos que são novos. Para os novos utilizamos o mongoimport normalmente, já para os existentes, não colocamos no arquivo de importação e simplesmente rodamos a query de update direto no mongo, como o exemplo abaixo:

MODEL.collection.update({_id: MODEL.id}, { "$set" => { lala: "popo" }, "$addToSet" => { list_ids: {"$each" => lists.map(&:id)} } })

O método collection.update é o que o mongoid utiliza internamente para executar as queries no mongodb e pelos testes que fizemos é muito mais rápido do que se utilizássemos o método save do objeto.

* Créditos também ao @marciotrindade e Claudio Bruno Martins

quinta-feira, 5 de abril de 2012

Campos customizáveis com Rails, MongoDB e Mongoid

Em algumas situações queremos ter um modelo onde alguns campos podem ser customizáveis pelo cliente, vou dar um exemplo de como implementar isso com Rails, MongoDB e Mongoid

Onde guardar os campos customizáveis

A primeira idéia seria se aproveitar do fato do Mongo não ter uma estrutura definida para as collections (tabelas) e criar os campos customizáveis dinamicamente no modelo. No mongoid existe a configuração allow_dynamic_fields que permite que sejam inseridos campos dinamicos no modelo. Mas nessa solução temos alguns problemas, entre eles:
  1. perdemos o controle dos campos customizados que foram criados, pois teriamos que varrer cada documento e ver quais campos existem
  2. nao temos o controle do tipo de campo customizado que foi criado, por exemplo não saberíamos se ele deve se comportar como uma string, data ou inteiro
  3. temos que nos preocupar em proteger os campos default, por exemplo state, id, created_at, etc.. e não permitir que o usuário consiga apagar ou editar esses campos
  4. teríamos que implementar getters e setters no modelo para esses campos, pois não conseguiríamos definir os fields que é o jeito padrão do mongoid
A sugestão é criar um campo no modelo chamado custom_fields (ou algo parecido) e externamente um cadastro de campos customizáveis, desse jeito temos algumas vantagens:
  1. temos a lista dos campos customizáveis que existem e seus tipos (data, string, inteiro, etc..)
  2. só precisamos liberar o campo custom_fields para alteração e os campos default podem ficar protegidos no modelo
  3. podemos fazer buscas tipadas, por exemplo se um campo for do tipo data, buscar por um range de datas
Utilizando mongoid, a implementação ficaria desse jeito:

field :custom_fields, type: Hash   , default: {}

Desse jeito, no mongodb, os campos customizáveis ficam armazenados do mesmo jeito que se fossem embed documents

Criando índice de campos customizáveis

Porém quando implementamos essa solução, tivemos o receio de que não conseguiriamos criar um índice no mongo para otimizar as buscas por esses campos customizáveis, aí veio a grande surpresa do Mongo!

O Mongo permite que sejam criados índices desses campos customizáveis mesmo que alguns documentos dessa collection não tenham esse campo, e melhor ainda, mesmo que nenhum documento tenha esse campo customizável. Desse jeito podemos por exemplo, criar um índice em "custom_fields.empresa" mesmo que esse campo ainda não exista, mas quando ele for criado já terá um índice!

No exemplo abaixo temos uma busca feita no mongo sem o índice e logo após a criação do índice e a nova busca. Podemos ver que na primeira, foram percorridos os 1002 documentos e na 2a, somente os 482 do sexo "fem"



*Créditos também ao @marciotrindade e Claudio Bruno Martins por esse conteúdo


segunda-feira, 19 de março de 2012

Init script para Mongos no Debian

Procurei em vários lugares um init script para subir o serviço MONGOS do MONGODB e não achei, resolvi fazer um baseado no init script do mongodb: