E ae galera! Como muitos sabem, eu sou meio doido por organização (heheh) e eu mesmo não gosto de ficar lendo coisas que não me interessam de outros blogs, ou seja, no blog de alguém que gosta bastante de Vim eu ter que ficar lendo sobre paraquedismo

Agora eu gostaria de além de escrever sobre coisas técnicas, escrever também sobre os meus outros hobbies, como Motos, Shows e etc. Alguns deles eu até já escrevia um pouco antes, mas nem tanto, e isso já me incomodava um pouco, por que eu sei bem que várias pessoas que seguem o feed não gostam das mesmas coisas que eu.

Então minha idéia foi simples, criei um feed só para os posts técnicos (programação, Vim, eventos de tech, e coisas relacionadas), e o que eu achar que não é tech eu não coloco a tag.

Portanto, se você só quer ver os posts técnicos do meu blog, assine este feed, e o feed atual começa a ser o “FULL” onde terá todos os posts.

Se você não liga para só ler posts técnicos e quer ler tudo que eu colocar, é só ignorar isso tudo

Há braços

Fui convidado pelo @jtadeulopes e pelo @qmx para participar do meme sobre ambientes de desenvolvimento, então estou fazendo esse post para falar um pouco mais sobre o meu.

Sistema Operacional

Já usei Windows um bom tempo atrás, e agora tenho um pós-conceito para usar (preconceito é só quando vc não conhece), não vejo nenhuma vantagem para utilizar ele e acho que não vale o preço (tenho um Vista e um Win7 originais que ganhei na compra do notebook e na CampusParty e nem uso).

Já usei Slackware (e ainda tenho ele instalado no meu notebook para brincar de vez em quando) e atualmente estou utilizando só o Ubuntu, que me fornece um ótimo ambiente para desenvolvimento. Acho muito fácil instalar coisas novas para dev com o Ubuntu, e tudo se encaixa muito bem com esse SO.

Controles de Versão

Já utilizei um pouco de SVN, Mercurial e Bazaar, mas não o suficiente para falar bem ou mal de qualquer um deles, por que quando eu utilizei eles supriram a minha necessidade tão bem quanto o Git. Atualmente utilizo muito o Git, que eu acho fantástico, e a cada hora que vou utilizando eu descubro coisas novas que me surpreeendem. Não utilizo nada gráfico para o Git, apenas linha de comando, afinal, do que mais eu preciso!?

Linguagens de Programação

Gosto de brincar com várias linguagens e sempre estou mexendo um pouco com Python e Javascript. Já faz um tempo que eu não brinco com C++, mas é outra linguagem que eu gosto bastante também.

Algum tempo atrás brinquei um pouco com desenvolvimento de aplicações para Android e para isso tive que brincar um pouco com Java também . Mas como todos sabem, a linguagem de programação que eu mais uso atualmente é Ruby, que uso no trabalho e para alguns projetinhos pessoais.

Editor de texto / IDE

Eu uso o único editor de texto que uma pessoa em plena sanidade poderia usar, ou seja, o VIM! heheheh

Saindo da trollagem e voltando as vantagens, eu gosto do Vim por que ele é um editor rápido, customizável, e me faz pensar a todo momento. Para mim é estar resolvendo puzzles a cada minuto, acho divertido ficar pensando em como eu poderia estar editando aquele texto de uma forma mais divertida, e consequentemente, quanto mais eu aprendo a editar textos de uma maneira melhor mais rápido eu vou ficando para editá-los.

Claro que não é viável utilizar o Vim para tudo (apesar de eu estar escrevendo esse post por ele…heheh), e para algumas coisas é mais viável utilizar uma IDE. Para desenvolvimento de apps para o Android por exemplo, é muito mais fácil desenvolver utilizando o Eclipse que já tem plugin que ajuda em algumas tarefas, e é Java…Não preciso dizer mais nada.

Musica

Sempre estou com meu player aberto ouvindo musica, e sempre estou ouvindo coisas diferentes, começo com um random na minha lib inteira e escolho uma banda nesse meio para ouvir. Eu tenho uma playlist das musicas que eu mais curto para ouvir nos dias que não estou afim de ficar ouvindo coisas aleatórias. Já testei diversos players no Linux (banshee, amarok e etc), e atualmente estou utilizando o Rhythmbox, que reconhece meu Ipod e posso ouvir sempre a mesma lib em casa e no trabalho.

Se quiser saber as musicas que eu ouço veja meu last.fm.

IMs

Geralmente fico logado em mais de 6 contas de IM (2 Gtalks pessoais, 1 Jabber da empresa, 2 contas de IRC, 1 conta de Skype e ainda tem o softphone). Parece ser meio bizarro ficar logado em tudo isso todo o tempo, mas eu só consigo essa proeza por que as pessoas que eu tenho nos IMs são inteligentes o suficiente para olhar o meu status e não em encher quando não devem, caso não eu não possa falar apenas aviso e pronto. Em casos que preciso de bastante concentração eu fecho quase todos, deixando apenas uma conta que tem só algumas pessoas adicionadas

Só para constar, se você usa MSN isso não funciona, por que se a pessoa usa MSN ela já não tem nenhuma noção.

Terminal

Aqui é onde eu passo 90% do meu tempo de trabalho, utilizando linha de comando, Vim (não uso interface gráfica para ele também…Não faz sentido para mim), Git e scripts em geral. Atualmente eu uso o gnome-terminal do Ubuntu, que não deixa a desejar.

Organização

Eu sou meio bizarro quanto a organização, e no meu ambiente tudo tem que ficar em seu devido lugar, assim, cada atalho de teclado me leva onde eu sei que as coisas estão. No trabalho tenho 2 monitores e 4 areas de trabalho, sendo que fica organizado assim:

1. Um browser em cada monitor
   • Firefox com Vimperator na esquerda com 3 abas com páginas que eu uso no sistema que eu trabalho atualmente
   • Chrome no monitor da esquerda com 2 e-mails, todoist e pivotal tracker
2. Todos os IMs e um terminal
3. Dois terminais, um em cada monitor com projetos auxiliares
4. Dois terminais, os dois abertos com o projeto que estou trabalhando
   • No terminal da direita deixo uma aba com Rails server, uma com Rails console e uma para o Vim
   • No terminal da esquerda rodo testes e outras coisas

Tem várias outras coisas que uso (como o Notecase para tomar notas por exemplo) mas acho que isso ae já é uma visão geral

Agora eu passo a bola para o @dlibanori, @crocidb e @sceadugenga

Pessoal,

Nesse post eu vou falar um pouco de como foi atualizar a aplicação que eu trabalho atualmente para Rails3.

Em uma segunda feira eu tive a brilhante ideia de aproveitar que as tasks que eu estava fazendo estavam dependentes de algumas coisas que ainda não estavam feitas, e resolvi começar a atualizar a aplicação para Rails3 só para saber o trabalho que ia dar, e no final do dia eu já tinha feito todas as alterações necessárias para o boot da aplicação e para rodar a suite de testes (não fazer os testes passar, apenas rodar!). Depois disso foi mais 1 dia para fazer todos os testes passar, e mais alguns outros testando a aplicação e resolvendo pequenos problemas de safe html e derivados.

Dicas para fazer a conversão do código

Tenha testes

Se não tiver testes, esqueça essa idéia e pare de ler o post, a menos que você queira quebrar sua app em produção.

Faça sua aplicação e suite de testes funcionar

Primeiramente, se você ainda não conhece, vale a pena dar uma olhada no plugin chamado Rails Upgrade que te dá um guideline do que você precisa ir alterando para tornar sua aplicação compatível com Rails 3. Esse plugin faz algumas coisas como criar o application.rb baseado no seu environment, te dar alguns guias das configurações que mudaram e tenta converter suas rotas para o novo padrão (vide próximo tópico) O primeiro passo a se tomar é utilizar o plugin (ou não, pode fazer manualmente também) e trocar as coisas principais para que sua aplicação pelo menos passe pela etapa de boot. Quando passar por esse passo vá para seus testes, e se for RSpec prepare-se para ter alguns problemas de conversão, por que algumas coisas mudaram do RSpec 1 para o RSpec 2, e você vai ter que lidar com os problemas de atualização dos seus testes tambem. A maioria das coisas que tive problemas foi com métodos que não existem mais como o have_tag por exemplo.

Não use o Rails Upgrade para a conversão das rotas

Como disse acima, esse plugin é um ótimo guia, mas tome cuidado com ele como solução final. Você pode dizer para ele converter suas rotas, mas tome cuidado, por que dependendo da forma que as suas rotas estão diagramadas o resultado que ele dá não é muito conciso. O que eu fiz foi utilizar a conversão dele apenas como estudo para saber como está a nova syntax e refiz o arquivo de rotas do zero.

Pare de usar remarkable

Eu sempre gostei de usar Remarkable para testar relacionamentos, validações e etc, mas remarkable no Rails 3 é uma grande porcaria. Os desenvolvedores que começaram o projeto ficaram sem tempo para o mesmo e deixaram na mão de outros, que não tem a mesma qualidade ou preocupação com o projeto, portanto, a menos que você queira ser o novo mantenedor do projeto e fazer as alterações necessárias para que funcione bem no Rails 3, fuja dele agora. O que eu fiz foi começar a usar o Shoulda para algumas coisas que me convinham, como por exemplo testes de relacionamento e validações. Para quem estiver interessado em fazer essa migração, eu fiz grande parte das trocas do que eu usava (validações e relacionamentos) facinho com grep e sed! Fiz um Gist disso.

Evite dependencias

Assim como o remarkable acima, cada outra gem/plugin que você está utilizando pode ter problemas com o Rails 3, portanto, antes de fazer a migração procure manter o menor número possível de dependencias no seu projeto, e as que você tiver veja se já possui uma versão funcional para Rails 3, e se não possuir você já pode se voluntariar para fazer .

Use o sufixo _html nos locales necessários

Suponho que as aplicações Rails estão usando os formatos de internacionalização do Rails, portanto suas string não estão perdidas pelas Views, Controllers e Models e sim estão em seus devidos arquivos de locale. Levando esse cenário óbvio em conta lembre-se de que você não precisa dar raw em toda mensagem que possui HTML por que Rails já faz isso para você quando você adiciona o sufixo _html na sua chave de locale. Exemplo:

not_yet: "<strong>Ainda não</strong>"

Ficaria:

not_yet_html: "<strong>Ainda não</strong>"

E assim ele não vai escapar automaticamente o HTML dessa chave.

Vá lidando aos poucos com DEPRECATION WARNING

Quando você rodar sua suite de testes pela primeira vez já vai ser bombardeado por uma quantidade monstra de DEPRECATION WARNINGs, mas não saia atacando eles de uma vez, primeiramente tenha em mente fazer sua aplicação funcionar e você vai corrigir esses probleminhas aos poucos enquanto estiver corrigindo os erros ou desenvolvendo coisas novas. Felizmente a API do ActiveRecord não deixou de funcionar, portanto você ainda não vai precisar fazer grandes modificações para a nova syntax utilizando Arel por enquanto, o que vai tornar a migração menos dolorosa e você pode migrar aos poucos enquanto seu código já estiver rodando.

Dicas de organização para a migração

Crie um branch separado e altere aos poucos

Sim! Todos queríamos que toda a equipe parasse por alguns dias e fosse alterar o projeto para funcionar com Rails 3, mas todos sabemos que isso não é possível na realidade de ninguém. Então uma coisa legal para se fazer (principalmente quando se está trabalhando com controle de versão distribuído, onde branches não são tão penosos) é criar um branch e manter uma pessoa trabalhando nele enquanto os outros vão tocando o projeto, sempre com muita comunicação para evitar que as pessoas criem cada vez mais código legado que precisará ser migrado, até que chegue uma hora que você possa voltar para o master e ficar sem deploy por alguns poucos dias para que a aquipe termine o trabalho e faça alguns testes.

Ataque um problema de cada vez

Acho muito legal a combinação Rails + Ruby1.9, mas acho que as coisas ficam bem mais fáceis quando atacamos no estilo estripador (por partes), assim você tem um caminho a menos para analizar de onde vem o possível erro, e assim que terminar uma migração para Rails 3 já pode começar uma para Ruby 1.9 e ver o que vai quebrar apenas para essa implementação específica.

Use seu ambiente de homologação

Não sei como seu deploy funciona atualmente, mas talvez com a migração você precise alterar ele e é na hora que você for colocar no seu ambiente de homologação que você vai descobrir isso, portanto, use-o bem!

Conclusão e Saldo final

Fazer a migração para o Rails 3 foi mais simples do que eu imaginei, mas mesmo assim tomou vários dias para a conclusão. Nos meus calculos levou mais ou menos 2 dias só meus e uns 3 dias meus e de outro desenvolvedor, isso contando os problemas de merge e etc. Portanto acho que em 1 semana é possível migrar uma aplicação bem coberta por testes sem grandes problemas e sem precisar parar a sua equipe inteira por um grande período. Escolha aquela semana com um feriado e atualize sua aplicação.

Há braços

Aqui estou eu mais uma vez para falar mais uma das maluquices que eu fiz um bom tempo atrás mas não tive tempo de postar.

Primeiramente eu vou falar o que muita gente já falou muito bem, que é sobre screen e pair programming. Mas vou dizer como funcionou para mim. Alguns posts que eu li antes e depois de começar a brincar com screen e pair programming, e que eu gostei:

• Post do Caike sobre Pair programming remoto usando screen
• Post do Qmx sobre pair programming usando screen

Primeiramente vamos começar com umas dicas do post do caike:

Para mim foi necessário alterar as permissões do Screen:

sudo chmod +s /usr/bin/screen
sudo chmod 775 /var/run/screen

Agora é só seguir a velha receita dos dois posts:

Primeiro usuário:

• O primeiro usuário acessa o computador host via ssh
• executa o comando screen -S nomedoscreen

Segundo usuário:

• Acessa o servidor com o mesmo nome de usuário/senha do primeiro
• executa screen -x

Pronto! As duas pessoas estão compartilhando a mesma tela agora e podem usar o Vim para programar (claro, qual outro editor seria, não!?).

Nunca consegui utilizar o screen multiusuário (como mencionado no post do caike) mas isso não é um grande problema.

Como eu usei

Primeiramente fiz um pair programming normal com o @mateuslinhares, onde nós dois ficavamos no mesmo screen conversando (estavamos há menos de 2 metros de distância), e cada um com seu teclado, podendo intervir a qualquer momento. Isso foi legal por que não precisávamos ficar dividindo espaço de um mesmo monitor ou de um mesmo teclado, e ainda driblava outros problemas que tínhamos na época.

Uma nova idéia

Na época desse pair programming estavamos com uma task grande e trabalhosa, mas podia ser feita individualmente, e provavelmente seria mais produtiva do que em pair programming, mas tinha uma particularidade muito interessante. Cada um de nós conhecia melhor uma parte do sistema, portanto, se mantivessemos contato contínuo isso ia acelerar o trabalho, pois precisávamos alterar/retirar algumas coisas que podiam ou não ser importantes para o sistema como um todo. Levando tudo isso em conta me surgiu uma idéia:

Por que não fazer tudo com um “semi pair programming”, onde cada um trabalhava no seu computador mas visualizando a tela do outro em um split.

Tanto eu como o @mateuslinhares estamos acostumados a separar o nosso vim em vários splits verticais e horizontais, ou seja, um split vertical do screen não seria o problema.

O que fizemos

Decidimos então seguir o seguinte script:

Setup das duas maquinas:

• Vim
• Screen
• Um usuário em comum

PotHix:

• com o usuário compartilhado
• executa um screen -S pothix na sua maquina
• Abre um novo split no screen com o comando ctrl+a s
• Nesse novo split acessa a maquina do Mateus e executa screen -x para acessar o screen que o @mateuslinhares criou na maquina dele
• Volta para o split anterior e trabalha normalmente

@mateuslinhares

• com o usuário compartilhado
• executa um screen -S mateuslinhares na sua maquina
• Abre um novo split no screen com o comando ctrl+a s
• Nesse novo split acessa a maquina do Mateus e executa screen -x para acessar o screen que o PotHix criou na maquina dele
• Volta para o split anterior e trabalha normalmente

Seguindo esse script teremos os 2 utilizando um screen com um split, sendo que um split é para seu trabalho local e no outro você pode acompanhar e dar pitacos no trabalho do seu comparsa!

Benefícios

No caso dessa nossa task isso resolveu muito o nosso problema, por que conseguimos trabalhar em locais distintos mas sempre em constante comunicação, o que sempre trazia alguns comentários como:

PotHix: Ow…Não tira isso aí não por que vai quebrar tal parada.

ou então:

Mateuslinhares: Cara…Olha isso aqui no screen, dá para fazer na sua parte tambem.

Conclusão

Para mim foi muito bom e recomendo a todos para tentarem algo do tipo quando tiverem chance (a não ser que você use Textmate…nesse caso…boa sorte! )! A unica coisa que eu recomendo é utilizar 2 monitores, assim você pode deixar a tela do seu comparsa no outro monitor (divida os monitores verticalmente) e trabalhar com vários splits no seu monitor. É totalmente possível trabalhar com 1 monitor apenas (foi assim que trabalhamos) mas você obviamente perde um pouco de espaço

Espero que essas informações sejam úteis para mais alguem.

Qualquer dúvida ou sugestão deixe nos comentários.

Há braços

Hoje estou aqui para falar de uma coisa que quando vi pela primeira vez ignorei por parecer uma coisa boba, mas olhando melhor eu percebi que é uma idéia bem interessante. O que a gem whenever faz é manter o seu crontab de uma forma mais Ruby, e melhor, dentro da sua aplicação!

A principio parece estranho tentar manter o crontab dentro da sua aplicação, mas ganhamos muitas vantagens com isso:

• versionamento
• menos acesso ao servidor
• rapida atualização do crontab do servidor via capistrano
• forma mais legível de ver o crontab

E tudo isso não influi no crontab que você já possui ( e que muitas vezes tem muita coisa que não é relacionada com a aplicação ), pois o whenever cria uma seção que ele atualiza mantendo a seção antiga onde está.

Para instalar o whenever é a mesma facilidade de sempre:

   sudo gem sources -a "http://gemcutter.org"
   sudo gem install whenever

OBS: Lembrando que a primeira linha só é necessária uma vez, se você já tem o gemcutter no seu sources então ignore-a.

Depois disso execute:

   wheneverize .

O comando acima vai gerar os arquivos necessários para a utilização do whenever ( básicamente o config/schedule.rb ).

E a partir de agora você já pode atualizar o seu crontab com as suas configurações feitas no config/schedule.rb executando o comando:

   whenever --update-crontab suaaplicacao

Quando você passa como parametro a sua aplicação ele cria um bloco apenas para as configurações da sua aplicação no crontab.

Mas é claro que você não vai precisar acessar o servidor e executar esse comando toda vez que você alterar o arquivo de schedule, para isso você provavelmente deve estar usando o capistrano para ser mais DRY. Se estiver usando inclua algumas linhas no seu deploy.rb:

   after "deploy:symlink", "deploy:update_crontab"
 
   namespace :deploy do
      desc "Update the crontab file"
      task :update_crontab, :roles => :db do
         run "cd #{release_path} && whenever --update-crontab #{application}"
      end
   end

OBS: Se você tiver problemas no deploy com essa linha ( como se o comando whenever não existisse ), tente adicionar o path absoluto para o whenever.

E com isso a cada vez que você fizer um cap server deploy seu crontab será atualizado com as configurações contidas no config/schedule.rb.

Veja alguns exemplos do que pode ter no seu schedule.rb:

  every 4.minutes do
    rake "ts:in"
  end
 
  every 1.day, :at => '5:25 am' do
    rake "bla_bla"
  end
 
  every [:monday, :thursday], :at => '11:59 am' do
    command "sudo rm -rf /" # claro!
  end

Nada do que eu demonstrei aqui é uma grande novidade, você pode ver mais exemplos de como usar no Railscasts e na própria página do plugin.

Espero que seja útil para mais alguem como está sendo para mim.

Há braços

Esses dias eu peguei para instalar o monit no servidor da empresa que eu trabalho e sofri um pouquinho com algumas coisas básicas, portanto decidi postar aqui para que seja útil para quem quer começar a utilizar o monit.

Se você usa Ubuntu, você pode fazer download do Monit por apt-get:

sudo apt-get install monit

Se você não usa Ubuntu ou quer a ultima versão do Monit, então faça download do tar.gz http://mmonit.com/monit/download/ e compile.

O Monit tem 2 dependencias:

• bison
• flex

Eu resolvi as 2 facilmente utilizando o próprio apt-get:

sudo apt-get install bison flex

Agora é só partir para compilar os fontes! ( prefiro compilar dos fontes em certas ocasiões para pegar a ultima versão ):

tar xvf monit-x-x-x.tar.gz
./configure
make
sudo make install

E pronto! Lá está o seu monit instalado! Agora é o momento da configuração. 

O monit utiliza o arquivo chamado .monitrc para saber o que deve ser monitorado e com quais parâmetros, portanto crie um arquivo na sua $HOME com o nome de .monitrc:

vim $HOME/.monitrc

Claro que usarei  o vim para isso ( qual outro poderia ser né? haha ). Agora você deve criar o seu próprio arquivo de configuração dizendo o que o monit deve monitorar e quais critérios deve usar.

Você pode pegar alguns exemplos de arquivos como o do pessoal do mongrel, ou até mesmo da documentação oficial do monit e criar o seu baseado nele. A syntax desse arquivo é de fácil entendimento.

Para e-mails eu utilizei a minha conta do Google Apps com a seguinte configuração:

set mailserver smtp.gmail.com port 587 username "pothix@pothix.com" password "abc123" using tlsv1,
with timeout 15 seconds

Com todas as configurações arrumadas o monit já pode ser iniciado:

monit

E agora você já tem vários comandos para utilizar, é só dar uma lida na documentação do monit para ver o que é possível fazer.

Espero que seja útil para quem ainda não usa nenhuma ferramente de monitoração e gostou do monit.

Há braços

Aqui começa uma série de artigos sobre por que eu gosto de usar o VIM para programar.

Uma das primeiras coisas que eu gostaria de comentar é sobre a quebra de paradigma que você deve ter quando começa a usar um editor como o vim que tem vários modos de operação, ou seja, não é mais apenas digitar, pois cada modo de operação tem o seu modo de agir. Os modos de operação são os seguintes:

• Inserção
• Visual
• Normal
• Comandos

Modo de inserção

O modo de inserção é um modo simples para se inserir texto sem nada muito complexo, você se sentirá usando um notepad se usar somente o modo de inserção.

Modo visual

Com o modo visual você pode selecionar facilmente trechos de texto, linhas inteiras e blocos de texto. Um exemplo bem legal de uso de blocos no Vim pode ser visto no blog do TaQ.

Modo normal

Agora sim as coisas ficam legais! No modo normal, que é o modo que você mais fica no Vim, você pode fazer as coisas mais interessantes!

Ok, falei…falei…e não mostrei o por que o modo normal é tão poderoso né? Bem, são coisas como essas:

• Dentro de aspas podemos dar um ci” e ele já excluiria todo o conteúdo que está dentro das aspas e deixaria você em modo de inserção para inserir um novo conteúdo
• Parar em cima do número 20 e quer adicionar 7? Apenas faça 7<ctrl+a> e ele fará a soma em cima desse número
• E se ao invés de soma vc quiser a subtração dos valores acima? Apenas faça 7<ctrl+x> e ele fará a soma em cima desse número
• É claro que você não vai ficar repetindo esse monte de coisas que você fez aí em cima se tiver várias ocorrências e você não quiser fazer um “find and replace”, por que você pode usar o . (ponto) para fazer a sua ultima ação novamente.
• Quer trocar as linhas de posição? Moleza! ddp ( sendo dd para excluir uma linha, que fica no buffer, e p para colar a linha do buffer )
• Está no começo da linha e quer ir para aquele parentese? f( e pronto, você já estará lá!
• Quer ir para um caracter antes do parentese? t( ta na mão!

Enfim…Tem muitas outras coisas legais a se fazer sem que você precise tirar a sua mão do teclado.

Modo de comandos

E o modo de comandos é onde você tem uma segunda linguagem de programação alem da que você está usando pra programar, e lá você pode tanto usar comandos de loop como:

:for i in range(1,10) | put ='192.168.0.'.i | endfor

OBS: créditos ao Sergio nesse post

Que imprime uma faixa de IPs de 192.168.0.1 até 192.168.0.10. Ou você pode alterar as funcionalidades e opções do editor utilizando :set ou outras comandos interessantes.

Use o Vim como ele foi feito para ser usado

Outra quebra de paradigma que deve ser usada é usar “hjkl” para se movimentar pelo texto, sempre usando os dedos indicadores sobre o “j” e o “f” que é o padrão de digitação, e você vai ser que você vai precisar tirar a mão do teclado para fazer outras coisas poucas vezes, e pelo menos para mim as coisas parecem bem mais fáceis. Isso lhe força a sempre usar <esc> ( ou <ctrl+[> ) após fazer alguma coisa, deixando o modo normal livre para uso.

Customização

O Vim pode ser facilmente incrementado com plugins, temas e outras coisas que tornam ele bem customizável, e você pode deixar ele com a sua cara. Atalhos são facilmente configuráveis no seu .vimrc, assim como configurações como highlight de busca, espaçamento para scroll, e mais muuuiiitas opções que obviamente não caberão nesse post.

Concluindo

A idéia desse post é falar que para se usar vim você precisa estar disposto a mudar muita coisa que você sabe, e a curva de aprendizado não é uma das mais fáceis, mas quando você está no meio dela você percebe o quanto é legal e acaba se viciando no negócio! hehe

Como o Vim é bem configurável pode acontecer de você ficar tentando implementar ele para ficar igual ao seu antigo paradigma ( modo de inserção para sempre ), mas isso não vai de ajudar muito e vai te abstrair toda a força do Vim.

É isso! Nos próximos posts sobre vim pretendo postar dicas, referências legais e falar bem mais aprofundadamente de algumas ferramentas.

Há braços

Como mencionei no meu ultimo post eu parcicipei do GameJam do Itaú cultural e desenvolvi um jogo com Allegro. Agora com o jogo pronto estou criando arquivos executáveis para divulgar e tinha me esquecido da diferença de arquitetura no Linux, assim compilei apenas para meu Linux x64.

Quando me dei conta que não funcionou no computador do trabalho por que eu tinha um binário x64, eu tive que instalar o Allegro no computador de lá para poder fazer funcionar também em Linux x86. Pensei eu:

“Vai ser moleza, assim como foi instalar o Allegro 4.2.2 no notebook que é x64″

E lá fui eu:

./configure
make

Ué…Deu um problema bizarro com o FNSTSW no make, então não vai ser tão fácil assim…E lá vamos nós procurar na internet. Procurando eu descobri que tem realmente um erro em uma parte Assembly do código do Allegro para x86 que está errada na versão 4.2.2 que provavelmente foi consertada nas versões futuras, mas nesse caso tive que arrumar na mão:

No arquivo src/i386/icpus.s alterar a seguinte linha (tirar a que tem um menos e colocar a que tem um mais):

fninit
movl $0x5A5A, %eax
-   fnstsw %eax
+   fnstsw %ax
cmpl $0, %eax
jne is_fpu_not_found

E assim eu consegui compilar certinho!

Quando tentei rodar meu binário me deparei com o seguinte erro:  “error while loading shared libraries: liballeg.so.4.2: cannot open shared object file: No such file or directory” ¬¬

Pesquisando na internet novamente eu descobri que estava faltando eu adicionar o diretório /usr/local/lib ao meu LD_LIBRARY_PATH:

No meu .bashrc:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

OU

Editar o meu arquivo /etc/ld.so.conf e incluir /usr/local/lib no final do arquivo e depois rodar o comando ldconfig como root

Com isso eu consegui finalmente compilar o jogo e  fazer o meu binário rodar o meu jogo normalmente.

Espero que seja útil para mais alguem.

Há braços

Como alguns sabem no final de semana passado ( dias 7, 8 e 9 ) eu participei do GameJam do Itaú cultural.

Nesse evento os participantes tinham que formar equipes de até 4 pessoas e fazer um jogo em 48 horas, sendo que o tema ao qual o jogo devia responder só seria passado na sexta feira as 19, e teríamos até as 19 horas do domingo para entregar o jogo pronto utilizando qualquer plataforma para desenvolvimento.

Pois bem, o que eu falei acima resume bem as regras do evento, agora vamos a minha situação. Fiquei sabendo na segunda feira pelo CrociDB que teria esse concurso e que tinha até quarta feira para se cadastrar, e eu tinha acabado de fazer uma mini-cirurgia para tirar um dente, portanto estava sentindo dores e tomando 4 tipos de remédios diferentes e não pude confirmar nada devido a esse motivo, mas a vontade era grande. Enquanto eu não confirmava o CrociDB ia procurando pessoas para a equipe.

Quarta feira ( ultimo dia para inscrição chega ) e eu já estava um pouco melhor e decidi me inscrever! Procurei por outras pessoas para compor a equipe, alguns descartei logo de cara por que sabia que ia ficar arrumando desculpinha para não participar, ou não teria peito o suficiente para aguentar a competição, então nem chamei, outros sabia que infelizmente não poderiam participar por motivo de força maior ( fez falta hein Rafael Masoni ), e teve ainda os últimos que eu achei que participariam e fui chamar mas me decepcionaram…

Início do contest

Sexta feira tudo preparado e lá vou eu as 19 para o Gamejam (que foi na faculdade Anhembi Morumbi), e após me perder um pouco ( para variar ) cheguei em cima da abertura e recebemos o tema:

“Maquinas inovadoras” “Maquinas e computadores podem tomar decisões inovadoras?”

E com isso lá se vai o nosso pensamento…Criar um robô em 2d no estilo side scroller? Criar um robô fazendo algum tipo de shooter? Criar um braço robô que faz algo? Como ele seria inovador? Ele seria inovador? Como são as decisões dos computadores atualmente?

E com essas várias perguntas chegamos a conclusão que um computador sozinho não pode tomar decisões inovadoras, ele apenas é programado para uma determinada finalidade, nunca cabe a ele as decisões finais com novas idéias. Com isso em mente nosso game foi baseado num braço robô que distribui caixas num armazém seguindo sua própria ordem, supostamente tentando uma maneira inovadora de organização de cores que pode ou não estar certa, e cabe ao jogador organizá-la da melhor maneira possível. Obviamente a idéia inicial não se fechou tão fácil, e fomos desenvolvendo ela de acordo com a evolução do game.

Com uma base inicial desenvolvida passamos para o desenvolvimento!

Preparamos o ambiente com Allegro e algumas classes que o CrociDB usa para facilitar algumas coisas e eu dei uma introdução sobre o workflow do Git para trabalhar utilizando controle de versão. Usamos um roteador para conectar os 2 notebooks e compartilhar um repositório para os códigos, por ssh mesmo, que infelizmente deixava a transferência muito ruim devido ao uso do Cygwin no Windows, mas não fui um grande empecilho, foi apenas chato.

Tenho que admitir que eu sou um zero a esquerda em Allegro e fui com a cara e a coragem participar desse contest, mas eu sabia que isso me traria muita experiência, por que eu sei que o CrociDB conhece bastante de Allegro e de desenvolvimento de games em si, e eu só comprovei isso durante todo o contest, ele já conhecia bem o conceito de desenvolvimento de games e tem bastante experiência com erros que podem acontecer.

Ficamos programando desde as 21 mais ou menos até as 5 da manhã e resolvemos ir para casa descansar para voltar no sábado a noite e ficar até terminar o game. A primeira vista achei o pessoal das outras equipes meio acuado, cada equipe isolada em suas mesas, excluindo apenas o pessoal que já se conhecia ou que era da faculdade.

Momento Hard work

Voltei no sábado as 19:30 para a programação e o CrociDB já estava por lá programando fazia alguns minutos e já tinha resolvido alguns probleminhas. Então já começamos a programar outras funcionalidades e fazer os desenhos para o jogo, que por sinal foi a parte mais difícil para nós, tendo em vista que nenhum dos dois tem a arte do desenho assim como as outras equipes tinham ( vi muitos desenhos e trabalhos legais ). Eu assumi uma boa parte dos desenhos para deixar o CrociDB mais focado na programação.

Durante o domingo tivemos vários problemas, como o não funcionamento do teclado do notebook do CrociDB, nos fazendo perder um tempo e ir para o laboratório usar um teclado USB, que levou a outro #fail, por que levamos o roteador e não prestamos atenção que a fonte não era bivolt, assim queimando a fonte do roteador…Ou seja…Nada de Git na parte final do projeto…

No laboratório conseguimos finalizar o jogo e encontrar umas midis legais até as 14:30 mais ou menos, quando preparamos as coisas para entregar o projeto final. Ao entregar o projeto e ver a organizadora testando percebemos que faltou uma dll para o allegro funcionar no Windows, e tivemos que pegar o projeto de volta umas 2 vezes para encontrar a dll certa, mas enfim funcionou.

Networking

Depois de entregar o projeto aproveitamos para fazer um Networking com alguma das outras equipes. Durante o evento estávamos sempre vendo algumas pequenas cenas dos outros jogos e algumas ferramentas, e uma que chamou bastante a atenção foi da equipe que estava ao nosso lado (Danilo, Gabriel, Theo e o Mario que eu não conheci) que estava desenvolvendo um game totalmente em blender! (assim que eles divulgarem o game eu posto o link aqui). O game deles ficou muito legal e o pessoal é muito gente fina também, foi muito válido conhecê-los!

Vi por cima mais alguns games que estavam em fase de produção ainda, e conheci algumas outras pessoas como o Danilo Vin (só conheço ele assim até agora…hahaha) que estava fazendo as artes do grupo dele, muito boas por sinal, mas não vi o jogo finalizado. Revi tambem o Speeder já tinha visto na campus party mas não tinha conversado muito.

Considerações

Finalizando, eu acho que esse contest foi muito legal,dormi apenas 40 minutos de sábado para domingo, mas foi minha primeira experiência com competição de desenvolvimento de games, meu primeiro contato mais próximo com Allegro, revi alguns conceitos de C++, conheci pessoas interessantes, vi alguns jogos serem criados do zero… Mesmo se nosso jogo não ganhar (o que é provável….hehe) esse contest valeu muito a pena!  O nosso game não ficou exatamente como queríamos por que além dos problemas, não conseguimos aplicar todas as idéias que tínhamos em apenas 48 horas.

Uma coisa que me deixou muito feliz foi ter conseguido fazer esse jogo usando apenas Software Livre! Utilizamos Inkscape, Gimp, Allegro e GNU/Linux. O Croci utilizou Windows para compilar a versão windows do jogo, e não tivemos sequer um problema de compatibilidade entre plataformas.

Para quem quiser dar uma olhada no nosso game, pode baixar ele no GitHub (o código não está um dos melhores, mas leve em consideração que foi um contest de 48 horas…hehe):

Código fonte

Download do pacote

• executáveis na pasta bin

Há braços

Esse vai ser um post rápido para relatar um problema que eu tive ( e ainda estou tendo ) para instalar gems do GitHub.

Por algum motivo bizarro ( nem tanto assim, parece ser dns, mas já tentei opendns e nada ) a página http://gems.github.com não abre de maneira nenhuma, enquanto a navegação continua normal sem nenhum problema…A consequência disso é que eu não consigo colocar o source do github nas minhas configurações do Rubygems.

Tendo em vista que eu não conseguiria utilizar gem install para nenhuma gem que vinha do GitHub tive que dar um jeito de instalar manualmente.

O que fiz foi acessar a página do GitHub referente a gem que eu queria instalar, que no caso é a kitabu do fnando, pegar o link de clone e clonar:

$ git clone git://github.com/fnando/kitabu.git

Mas ae que está o lance que eu demorei para encontrar ( noob ), para uma gem ser instalada localmente ela precisa estar empacotada, e no GitHub você baixa direto o código fonte. Para empacotar:

$ gem build kitabu.gemspec

Agora sim eu tenho o arquivo kitabu-0.3.3.gem que eu posso utilizar para instalar localmente! Para instalar é só utilizar o gem install padrão informando o arquivo a ser instalado:

# gem install kitabu-0.3.3.gem

E pronto! Lá está a minha gem instalada! Espero que isso seja útil para mais alguem que precise empacotar as suas gems.

Há braços