Com a proliferação dos pen drives com alguns GB de capacidade e a preços acessíveis, aplicativos que rodam sem necessitar de instalação tornaram-se igualmente populares. Estes aplicativos “portáteis”, mais conhecidos como Portable Apps, podem ser executados diretamente do pen drive, geralmente com todas as funções dos equivalentes instaláveis. Eles são mais comuns em ambiente Windows (o site mais conhecido é o PortableApps, mas existem outros, como o The Portable Freeware Collection), porém também existem Portable Apps para Mac OS X. Até onde eu sei, não existem Portable Apps para Linux, porém, é possível executar os Portable Apps de Windows via Wine.

Como não poderia deixar de ser, existem também muitos ambientes de desenvolvimento portáteis. Talvez o mais conhecido seja o XAMPP, que inclui um servidor Apache com MySQL, PHP e Perl, entre outras ferramentas. Basta descompactar e executar.

Para Ruby on Rails, também existe um ambiente portátil. É o Instant Rails, infelizmente disponível somente para Windows. A exemplo do XAMPP, basta descompactar um arquivo zip para se ter um ambiente Rails totalmente funcional, com Mongrel, Apache e MySQL. É possível, inclusive, instalar RubyGems e plugins Rails normalmente, como num ambiente Rails comum. O pacote inclui ainda o SQLite, PHP, phpMyAdmin, o editor SciTE e o typo, sobre o qual já escrevi aqui no blog.

A principal desvantagem do Instant Rails é que ele está bastante desatualizado - a versão atual, 2.0, é de dezembro de 2007, e inclui as seguintes versões:

  • Ruby 1.8.6
  • Rails 2.0.2
  • Mongrel 1.1.2
  • RubyGems 1.0.1
  • Rake 0.8.1
  • Apache 1.3.33
  • MySQL 5.0.27
  • SQLite 3.5.4
  • PHP 4.3.10
  • SciTE 1.72
  • phpMyAdmin 2.10.0.2

Segundo o wiki do projeto, há uma petição solicitando o upgrade para a versão 1.9.1 do Ruby.

UPDATE: Só agora vi que o Urubatan escreveu sobre o mesmo assunto no blog dele. Só que ele citou o Ruby on Rails Portable, um projeto muito semelhante ao InstantRails, porém um pouco mais atualizado: a versão do Rails atualmente é 2.1.0 (a do Ruby é 1.8.6).

Outro projeto semelhante que encontrei, mas ainda não testei, é o Flash Rails.


Uma das maiores dificuldades para se aprender JSF é seu aparentemente complexo ciclo de vida, composto por 6 fases. Ao debugar uma aplicação JSF, percebe-se que alguns métodos dos Managed Beans são executados várias vezes, uma em cada fase, o que não é muito intuitivo, principalmente quando se está acostumado com outros frameworks web que utilizam abordagens bem diferentes.

Para facilitar a compreensão do ciclo de vida do JSF, recomendo o tutorial The JSF application lifecycle, da IBM. Ele explica cada fase, e apresenta um exemplo bem simples de uma aplicação usando JSF. Este tutorial é a segunda parte da série “JSF for nonbelievers”. As demais partes também são bem interessantes:


No ano passado trabalhei na Globo.com, e lá tive algumas oportunidades de trabalhar com Scrum (aliás, para quem ainda não leu, recomendo o post do Guilherme Chapiewski sobre a adoção de Scrum na Globo.com). Eu pretendia escrever sobre isso há algum tempo, mas a procrastinação me impedia de transformar um rascunho antigo neste post.

Quando cheguei na empresa, eu não sabia nada sobre Scrum, e fiquei muito curioso ao ver que, em determinado horário, todos os dias, todos os membros de algumas equipes levantavam-se, reuniam-se (em pé!) em torno de um cartaz na parede com vários post-its, e, após 15 minutos, todos retornavam às suas atividades normais. Comecei a observar e estudar o assunto, e aos poucos fui percebendo a simplicidade desta metodologia: tudo o que não for realmente necessário não deve ser feito. Acredito que isto seja um dos principais elementos do Scrum, pois ajuda a manter o foco naquilo que é realmente importante.

Outro ponto importantíssimo, e que é o assunto principal deste post, é o comprometimento. Para que o Scrum realmente funcione, é necessário que o time esteja comprometido com o projeto.

Num dos projetos em que trabalhei com Scrum, o Scrum Master era o Guilherme Chapiewski e o Product Owner, inicialmente, era o Antônio Carlos Silveira. Porém, por falta de tempo disponível para dedicar-se ao projeto, o Antônio saiu do time, repassando o papel de PO para outra pessoa. De todo o time, incluindo o SM e o PO, eu era o único que não estava envolvido em outro projeto. O GC, por exemplo, trabalhava em um outro projeto que era muito maior e mais importante que este, que, consequentemente, tinha baixa prioridade. Desta forma, começamos a passar pelos seguintes problemas:

  • nos Daily Meetings geralmente eu tinha concluído a minha tarefa, e muitas vezes até adiantado alguma outra, enquanto os demais membros do time não tinham nem iniciado as suas, pois estavam muito ocupados com seus outros projetos, e já sabiam que não poderiam iniciá-las nos próximos 2 ou 3 dias;
  • após algumas semanas, começamos a não conseguir mais realizar o Daily Meeting todos os dias, pois não conseguíamos 15 minutos livres de todos os membros do time simultaneamente.

Quando isso começou a acontecer com mais frequencia, começamos, na prática, a parar de usar Scrum, pois já não havia mais comprometimento. Como o Bruno Carvalho já escreveu, Daily Meeting é comprometimento. Não estou dizendo que o time estava desestimulado ou não queria se dedicar ao projeto. Pelo contrário, todos achavam o projeto bem interessante, porém não conseguiam se comprometer a ele, exatamente por estarem comprometidos com outro.

A solução encontrada pelo GC foi pararmos de usar Scrum neste projeto, pois tornou-se impossível praticar Scrum sem que todos os membros estivessem comprometidos. Continuamos a utilizar algumas das práticas do Scrum, como o Planning e o Review, mas na verdade não era Scrum.

A lição que tirei daí foi que é importantíssimo ter um time comprometido com um projeto para que o Scrum realmente aconteça, e que, sem isso, fica muito difícil utilizá-lo na prática. Até acredito que seja possível trabalhar em dois projetos simultâneos com Scrum, mas com certeza exigiria uma grande disciplina para conseguir dividir igualmente o tempo entre os dois, sem deixar de comprometer-se com um ou outro.


Há muito tempo o OpenOffice oferece uma opção para exportação de documentos para o formato PDF. Apesar de ser muito útil, falta uma opção para importar esse formato para edição. Faltava! A extensão PDF Import Extension da Sun faz exatamente isso: arquivos PDF podem ser importados e editados no OpenOffice Draw.

Apesar de a extensão estar em versão beta, fiz alguns testes e funcionou muito bem (apesar de alguns comentários de usuários com problemas na página da extensão). Achei a importação dos arquivos um pouco lenta, conforme alguns testes que eu fiz:

  • Arquivo com 18 páginas (300 kB) =~ 10 segundos
  • Arquivo com 209 páginas (6,28 MB) =~ 2 minutos
  • Arquivo com 322 páginas (1,15 MB) =~ 3 minutos

Num dos arquivos, uma página que continha muitos gráficos não foi importada adequadamente, mas foi o único problema que tive.

A opção salvar utiliza o formato ODF Drawing (.odg). Para salvar novamente como PDF, é necessário utilizar a tradicional opção de exportação para este formato. Porém, percebi que num dos testes a fonte ficou um pouquinho diferente da original. Mas, mesmo assim, a exportação foi de boa qualidade.

Referência sobre o assunto (incluindo uma descrição passo-a-passo da instalação): Modificando PDF no OpenOffice.org 3.0.


O Google se tornou, há muito tempo, a ferramenta padrão para qualquer desenvolvedor procurar ajuda para resolver os problemas que encontra. Porém, os resultados retornados nem sempre são satisfatórios e confiáveis. O objetivo do Custom Ruby on Rails search engine é resolver este tipo de problema: ele filtra os resultados de uma busca no Google para exibir somente os resultados que vêm de uma lista específica de sites que o autor considera como confiáveis - além de links “oficiais”, como o site oficial do Rails, o wiki do Rails, o Ruby Forum e a API do Rails, alguns dos blogs mais conhecidos. O autor também aceita sugestões de sites para incluir nos resultados.

A ferramenta pode ser utilizada através do link direto ou através de um bookmarklet, conforme descrito no blog.