Browsed by
Month: May 2011

Palestra “Building Chrome Apps with HTML5” com Boris Smus (do Google)

Palestra “Building Chrome Apps with HTML5” com Boris Smus (do Google)

Acabei de chegar da palestra “Building Chrome Apps with HTML5” com Boris Smus (que aconteceu na Caelum). O cara é desenvovedor frontend do Google e fã de open source.

Baixe aqui os slides da palestra: http://goo.gl/Mke5D

Ele explicou coisas legais (e extremamente simples), como por exemplo, incluir isso num input text:

<input type='text' <strong>x-webkit-speech</strong> />

E várias outras coisas, vale a pena conferir os slides e também o blog do cara: http://smus.com/.

Pra fechar com chave de outro, ganhei uma camiseta nos brindes no final da palestra :)

Por que parei de usar os gemsets do RVM

Por que parei de usar os gemsets do RVM

Uso RVM (Ruby Version Manager) desde que este foi lançado e pretendo continuar utilizando, dada a facilidade para utilizar diferentes implementações / versões do Ruby em uma mesma máquina.

Algo muito interessante que ele traz são os gemsets, ferramenta para separar suas gems em contextos separados, geralmente um para cada projeto. Isso fazia total sentido antes do Rails chegar em sua versão 3, quando Bundler foi incluso para o gerenciamento das gems. Depois disso, apenas projetos Rails 2 teriam o problema de versões diferentes das gems.

Mas atualmente é possível usar o Bundler em projetos Rails 2, tornando os gemsets inúteis. Juntei todas as minhas gems no gemset “global”, que já vem criado por default e há 2 meses tenho usado desta forma, onde tudo tem funcionado perfeitamente – tanto projetos em Rails 3 quanto em Rails 2.

O único detalhe, é que se você tiver duas ou mais versões de alguma gem que inclui um executável (rspec por exemplo) você precisa chamá-lo da seguinte maneira:

bundle exec rspec ...

Para que o bundler chame o executável correto, baseado no seu Gemfile.
Mas eu resolvi isso com os alias:

alias rake='bundle exec rake'
alias spec='bundle exec spec'
alias rspec='bundle exec rspec'

Como vocês estão fazendo? Alguma sugestão ou crítica?

My Vimfiles

My Vimfiles

Usage

Troubleshoot: Because of the large amount of submodules, if you ever have any trouble after pulling from the repository, it will be easier to just back up your old .vim folder and just git clone a new version.

Clone this repo into your home directory either as .vim (linux/mac) or vimfiles (Windows). Such as:

git clone git://github.com/lucascaton/vimfiles.git ~/.vim

Then ‘cd’ into the repo and run this to get the snippets submodule:

git submodule init
git submodule update

Now just copy (or symlink) the .vim/vimrc file as .vimrc (Mac/Linux) or copy as _vimrc (Windows) in your home directory. In Mac and Linux, the
easiest thing to do is:

ln -s ~/.vim/vimrc ~/.vimrc

If you already have a custom .vimrc file, append the following lines to load everything else along with your personal hacks:

source ~/.vim/vimrc      "linux
source ~/vimfiles/vimrc  "windows

Project source: https://github.com/lucascaton/vimfiles

Criando um log com detalhes de erros

Criando um log com detalhes de erros

Quando rodamos algum script em sistemas Unix, existem 3 tipos de mensagens de entrada e saída:

  • STDIN – Standard in (código 0)
  • STDOUT – Standard out (código 1)
  • STDERR – Standard error (código 2)

Se você precisar salvar um log contendo não só as mensagens da saída padrão, mas também as mensagens de erro, use o seguinte sufixo: 2>&1, assim:

ls -lR / > /tmp/file.log 2>&1

O que estamos fazendo aí é pegando tudo que é da saída 2 (STDERR) e jogando pra saída 1 (STDOUT), fazendo com que o log contenha tudo :)

Valeu Wagnão pela dica!

Novo theme pro blog

Novo theme pro blog

Aproveitando que voltei a usar WordPress, coloquei um novo theme no blog, chamado Cleanr, desenvolvido pela WPshoppe.

Retirei algumas coisas do lado direito, a fim de deixá-lo mais limpo.

O que acharam?

Porque voltei a usar o WordPress

Porque voltei a usar o WordPress

Esse blog foi criado em julho de 2009 e estava hospedado na Locaweb, onde toda a configuração para aplicações PHP já estava pronta: Apache, o PHP própriamente dito e MySQL (infelizmente WordPress não suporta PostgreSQL). Tudo funcionava muito bem.

Pouco mais de um ano depois, mudei de hospedagem, agora uso um servidor da WebbyNode, o qual tem sido excelente. Porém, sempre uso um server-deploy semi-pronto, ou seja, que já vem com algumas ferramentas do mundo Ruby. E como queria continuar com o WordPress, tinha que instalar o PHP na mão. Até aí sem problemas: Nginx + PHP + WordPress + MySQL foi moleza. Lembro que quando migrei de servidor tive problemas FastCGI, mas acabei resolvendo. Mas meus problemas reais começaram quando fiz um novo server-deploy, repeti os passos e notei que o blog estava muito lento e que havia algo errado. Pesquisei sobre isso e descobri que o meu server não estava usando FastCGI, essencial para aplicações que rodam em PHP. Passei um tempão tentando fazer isso funcionar, sem sucesso.

Foi aí que decidi usar o Enki, um blog manager open-source feito em Rails. Gostei muito dele assim que comecei a usar. Logo de cara fiz um fork e fiz algumas modificações pra me atender melhor.

Mas ainda haviam algumas coisas que realmente não estavam me agradando. Primeiro que migrar todos os posts, páginas, comentários e imagens não seria nada fácil. Depois, as páginas não estavam cacheadas (até onde eu vi), as views eram escritas em ERB (e não em HAML) e tinha bastante coisa que eu teria que mudar. Além disso, não haviam muito themes, como no WordPress.

Por fim, depois de 2 semanas, decidi que ficaria com o WordPress mesmo. Meu amigo Eduardo Ramos me ajudou a configurar o FastGCI (usando php-fpm) e voltei o blog pra WordPress. Embora o código dele torne difícil algumas moficações, acho que não vou mudar ele por um bom tempo. E confesso que fiquei feliz de ter voltado.