Alguns programas no Ubuntu permitem a impressão para o formato PDF, como o Evince e o Gedit. Para ter essa opção disponível em qualquer programa, basta instalar uma impressora virtual de PDF, usando o pacote cups-pdf. Se ele não estiver instalado na sua distribuição, instale-o com o comando sudo apt-get install cups-pdf.

Para criar uma impressora de PDF, acesse a opção “System” -> “Administration” -> “Printing” e depois “New Printer”. Depois selecione “Print into PDF file” como tipo de impressora, e na tela seguinte, “Generic” como fabricante e “PDF file generator” como modelo. Finalmente, dê um nome para a impressora. Feito isso, a impressora de PDF ficará disponível para qualquer programa que tenha a opção de impressão. Os PDFs serão criados no diretório PDF dentro do home do usuário.

O processo acima já foi descrito diversas vezes, em vários blogs e sites sobre Linux. Porém, decidi escrever sobre isso porque a maioria dos artigos pára por aí, não informando como alterar as configurações do cups-pdf e nem como resolver alguns dos problemas mais comuns.

Configurações

O arquivo de configuração do cups-pdf fica em /etc/cups/cups-pdf.conf. Neste arquivo, ficam definidos o diretório de destino dos PDFs, o diretório de spool, as regras para formação dos nomes de arquivos a partir do nome do documento impresso, configurações de segurança e permissões, o grupo de usuários que tem permissão para usar esta impressora, tipo de log, configurações do Ghostscript e outros. Se você alterar algum destes parâmetros, será necessário executar sudo /etc/init.d/cupsys restart para que as modificações tenham efeito.

Problemas

Os problemas mais comuns com o cups-pdf são:

  • se após enviar um trabalho para a impressora o arquivo correspondente não aparecer no diretório PDF dentro do seu home (ou o diretório que você tiver definido no arquivo de configuração), verifique o log (por padrão fica em /var/log/cups/cups-pdf.log). Ele pode ajudar a descobrir o que ocorreu (ex: problemas de permissão)
  • verifique se o usuário está no grupo correspondente definido no arquivo de configuração (grupo lp por padrão)
  • se você alterar o diretório de destino dos PDFs, altere também o arquivo /etc/apparmor.d/usr.sbin.cupsd, na seção /usr/lib/cups/backend/cups-pdf. Este arquivo contém as regras de segurança do AppArmor, e define os diretórios onde o cups-pdf tem permissão de escrita. Após alterá-lo, execute sudo /etc/init.d/cupsys restart
  • se o log do cups-pdf apresentar a mensagem “[ERROR] failed to set file mode for PDF file (non fatal)”, execute o comando sudo aa-complain cupsd

A execução de testes em Rails é feita, normalmente, com o comando rake test. Este comando executa automaticamente todos os testes unitários e funcionais. Porém, algumas vezes queremos executar apenas uma parte dos testes, seja porque sabemos que outra parte do sistema está dando algum erro que pretendemos tratar depois, seja porque acabamos de alterar um trecho do código (ou dos testes) e queremos verificar se estes estão OK.

Para executar apenas os testes unitários, executamos o comando rake test:units. Para os testes funcionais, rake test:funcionals. Mas se quisermos executar um arquivo de testes específico, devemos trocar o rake pelo próprio ruby:

ruby test/unit/usuario_test.rb

Para ser ainda mais específico e executar um único método, basta acrescentar o parâmetro --name:

ruby test/unit/usuario_test.rb --name test_dados

Outra vantagem de testar executando o Ruby diretamente (sem o rake) é que não ocorre o problema de tabelas não existentes no ambiente de desenvolvimento, como ocorre com o rake.

Referência: Rails: Unit Test without Rails


Quem já tentou tratar caracteres acentuados em Ruby deve ter percebido que a linguagem não considera estes caracteres como letras. Métodos como upcase e downcase são “locale insensitive”, como diz a descrição destes métodos no manual do Ruby:

str.downcase => Returns a copy of str with all uppercase letters replaced with their lowercase counterparts. The operation is locale insensitive—only characters `A’ to `Z’ are affected.

O projeto Brazilian Rails foi criado com o objetivo de resolver este e outros problemas. O projeto é instalado como um plugin para Rails, e define novos métodos para a classe String, como o upcase_br e o downcase_br, que podem ser usados em substituição aos métodos originais. O plugin acrescenta ainda outras funcionalidades, como data, hora, feriados, dinheiro e mensagens de erro, todas adaptadas ao português brasileiro.

Ontem enviei um patch para o projeto, contribuindo com alguns novos métodos para Strings. Em breve a versão atualizada deverá ser disponibilizada, conforme o post do Celestino Gomes.


Aqui na Globo.com adotamos Scrum em (quase) todos os projetos. Quando cheguei aqui eu não conhecia praticamente nada sobre Scrum, e precisei aprender sobre o assunto para não ficar perdido.

Minha primeira fonte de consulta para o assunto foi o ótimo livro Agile Software Development with Scrum (que, inclusive, está na lista de livros recomendados para desenvolvedores pelo Guilherme Chapiewski). É um livro introdutório, muito bom para quem está começando a conhecer o assunto.

Outro material interessante sobre o assunto são as checklists, também indicadas pelo GC.

Finalmente, o site Visão Ágil, que publica periodicamente uma revista em PDF sobre desenvolvimento ágil, inaugurou uma seção Biblioteca, com palestras, artigos e apresentações, alguns deles sobre Scrum. Vale a pena dar uma olhada.


O blog Penguim’s Place publicou um excelente artigo em 3 partes, apresentando várias técnicas para procurar falhas de segurança em servidores web utilizando apenas o Google para isso. São técnicas muito interessantes, como buscar servidores com a página inicial padrão do Apache (o que pode indicar que ele foi mal configurado) e procurar por falhas específicas em banco de dados. Na parte final são apresentadas técnicas de defesa.