2010 February 27, 23:08 h
Recentemente escrevi um artigo sobre como arrumei meu ambiente Ruby usando RVM. Desta vez quero falar sobre outros aplicativos open source como mysql, postgresql e mais.
Infelizmente, um dos grandes pontos fracos do Mac é a ausência de uma ferramenta oficial e robusta de gerenciamento de pacotes para software open source, algo como o Yum (Fedora, CentOS) ou Apt (Debian, Ubuntu). No mundo Mac temos duas ferramentas mais conhecidas, o Fink e o Macports. O Fink é baseado no Apt e pacotes Deb, é o que tem a maior quantidade de pacotes (mais de 10k), mas na minha experiência ele costuma não ter pacotes atualizados com muita frequência. O Macports é meio semi-oficial e é inspirado no Ports do BSD, tem menos pacotes mas os principais parecem mais atualizados.
O Fink instala seus pacotes normalmente no diretório /sw e o Macports no /opt/local. Uma coisa irritante sobre eles é que, como não são oficiais, eles criam um ambiente completamente separado. E o gerenciamento de dependência deles significa que, por exemplo, se um pacote depende do Python, ele não vai usar o Python já pré-instalado no sistema, mas vai instalar uma nova versão no diretório separado. Na maior parte do tempo eles até funcionam razoavelmente bem, até que alguma coisa começa a falhar e aí é um pesadelo. O Macports é o mais chato porque ele compila tudo a partir do código-fonte, incluindo todas as dependências, incluindo recompilar software que já existe no seu Mac.
No caso do MacPorts, ele compila tudo a partir do código-fonte, incluindo diversas dependências que você já tem instalado no Mac. Portanto ele gasta muito tempo duplicando as coisas. Softwares como ImageMagick e Git demoram bastante tempo para instalar. Para atualizar pacotes então, sempre é uma caixa de surpresas.
2010 February 21, 06:01 h
Yesterday I wrote about my exercises with Chef Solo. I’ve spent several hours experimenting different cookbooks, writing my own recipes, tweaking attributes, reverting snapshots of my virtual machine several times to execute everything again. That got me pretty excited as I was getting more and more confortable.
So, as the Solo exercise was great I decided to try the full blown client-server model. And, to my surprise, it was easier than I expected.
2010 February 20, 12:02 h
Last year I interviewed Adam Jacob, from Opscode about Chef. Chef is a configuration management tool, which does something similar to what Puppet and CFEngine provides. Check out the interview to have a better idea about it.
One thing that I like about Chef is its Chef Solo setup. It makes it easy for me to have a single server, such as a VPS (virtual machine) and set it up the same way everytime. So I did an exercise and installed a bare bone Debian server into a Parallels Desktop virtual machine. I want to configure it to the point where it can receive a simple MySQL based Rails app and run it under Phusion Passenger for Nginx.
2010 February 14, 09:38 h
Esta semana assisti ao excelente filme Up in the Air (recomendo). Eu me identifico muito com a forma de pensar do personagem Ryan Bingham, mas o artigo não é sobre isso. Esse filme conta a história de um profissional do ramo de “recolocação profissional” (eufemismo para “cara que demite”). A idéia do filme não é ser uma lição de moral ou coisa assim, mas tem um trecho que vale a pena compartilhar: Download “Up in the Air” movie snippet Todo mundo sabe que eu evito auto-ajudas, mas de vez em q...
2010 February 13, 17:01 h
Até hoje eu usava o Capistrano para fazer o deployment de modificações no código do meu blog. Mas resolvi fazer algo mais simples: usar hooks de git. É uma técnica já bem conhecida e muito simples, por isso acho que vale algumas dicas.
Minha configuração é bem simples: o repositório git fica no mesmo servidor do site. Para criar um repositório privado de Git não é necessário muita coisa, basta que seu servidor seja acessível via SSH. Crie um par de chaves na sua máquina e coloque a chave pública no authorized_keys do servidor.
2010 February 05, 09:10 h
Upgrade 05/02: o Rails 3 Beta está oficialmente lançado! Leia o post do DHH e a restrospectiva do Yehuda. Agora já dá para instalar via gems:
1 2 3 |
gem uninstall bundler # => precisa desinstalar os bundlers abaixo da versão 0.9.2 gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n gem install rails --pre |
Upgrade 04/02: o David atualizou as anotações. Acabei de retraduzir o principal.
O Rails 3.0 é pôneis e arco-iris! Ele vai te cozinhar o jantar e lavar sua roupa. Você vai se perguntar como era possível viver antes dele chegar. É a Melhor Versão do Rails Já Feito!
Mas falando sério, é realmente coisa boa. Estão todas as boas idéias trazidas quando a equipe do Merb se juntou à festa e trouxe um foco de agnosticismo de frameworks, partes internas mais leves e rápidas, e várias ótimas APIs. Se você está vindo para o Rails 3.0 a partir do Merb 1.x, vai reconhecer muito disso. Se você está vindo do Rails 2.x, vai adorar também.
Mesmo que você não dê a mínima para nada disso das limpezas internas, Rails 3.0 vai agradar. Temos várias novas funcionalidades e APIs melhoradas. Nunca houve um momento melhor para ser um desenvolvedor Rails. Algumas das coisas principais são:
Em cima disso tudo tentamos nosso melhor para deprecar as APIs antigas com avisos. Isso significa que você pode mover sua aplicação existente para Rails 3 sem imediatamente reescrever todo seu código antigo para as últimas boas práticas.
Estas anotações de lançamento cobre todas as principais atualizações, mas não incluem cada uma das pequenas correções de bug e mudanças. Rails 3.0 consiste de quase 4 mil commits por mais de 250 autores! Se quiser ver tudo, veja a Lista de Commits no repositório principal do Rails no Github.
