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.


Na versão 2007, o Microsoft Office começou a usar o formato OpenXML como padrão - no caso do Word, a extensão deste formato é docx. Porém, este formato é incompatível com o OpenOffice (e com versões anteriores do Word…). Para abrir arquivos deste formato no OpenOffice, instale o odf-converter. Após instalá-lo, reinicie o OpenOffice e você conseguirá abrir e salvar nesse formato. O pacote deb pode ser acessado aqui. Instalei este pacote sem problemas no Ubuntu com OpenOffice 2.3, apesar dos comentários nessa página de download.

Referência: Arquivos OpenXML (.docx, .xlsx) no OpenOffice e BrOffice sem traumas


O sshfs é um comando muito útil para quem precisa acessar servidores (ou máquinas virtuais) remotos. Com este comando, em vez de precisarmos executar o ssh para logarmos ou o scp para copiarmos arquivos entre o desktop e os servidores, podemos montar localmente um diretório remoto.

Para instalar esse pacote no Ubuntu, basta executar o comando sudo apt-get install sshfs. Em seguida, adicione seu login ao grupo fuse:

sudo usermod -a -G fuse login

Apenas usuários deste grupo terão permissão para montar e desmontar diretórios. Para montar um diretório remoto:

sudo sshfs [email protected]:/usr/local/test ./server-test

O comando acima mapeia o diretório /usr/local/test do servidor server no diretório local ./server-test, como usuário remoto user. Há uma série de parâmetros opcionais, como forçar sincronização e cache. Verifique o man do comando para mais detalhes.

Para desmontar o diretório, basta executar:

fusermount -u ./server-test

Referências:


O framework Rails é excelente na tarefa de automatizar o máximo possível o desenvolvimento de aplicações web. Todos os detalhes que podem ser implementados automaticamente são abstraídos do desenvolvedor, facilitando e agilizando muito o trabalho.

Porém, toda essa automatização e abstração de detalhes internos tem um custo, que é a padronização. Por exemplo, ao usar o script generate para criar um model, o Rails cria uma classe derivada de ActiveRecord::Base. Os nomes do arquivo, da classe e da tabela são automaticamente gerados a partir do parâmetro passado. Ex:

ruby script/generate model tipo_usuario

Arquivo: tipo_usuario.rb

Classe: TipoUsuario

Tabela: tipo_usuarios

Neste caso, a partir do parâmetro passado para o script, o nome do arquivo é o próprio parâmetro com “.rb” no final, o nome da classe é gerado retirando-se os “_” e colocando a primeira letra de cada palavra em maiúscula, e o nome da tabela é o plural - que pode ser redefinido no arquivo config/initializers/inflections.rb:

Inflector.inflections do |inflect|
  inflect.irregular 'tipo_usuario', 'tipos_usuario'
end

Com a configuração acima, o nome da tabela será tipos_usuario - desde que esta configuração seja realizada antes do generate!

O principal problema que esta padronização traz é que nem sempre queremos/podemos seguir o padrão de configuração gerado pelo Rails. Na maioria das situações, é possível definir explicitamente quando se quer usar uma configuração diferente, como no caso do plural da tabela acima. O nome da tabela associado a um model também pode ser alterado, através do método set_table_name. Desta forma, o Rails não amarra totalmente o desenvolvedor aos seus padrões.

Porém, apesar da flexibilidade, essas configurações fora dos padrões nem sempre funcionam como deveriam. Muitas vezes, ocorre algum “efeito colateral” que faz com que algum outro módulo não funcione corretamente. Conforme escrevi no post Acessando múltiplos bancos de dados em Rails, ao configurar o acesso a múltiplos bancos de dados, os unit tests pararam de funcionar. Mais uma vez, precisei passar algum tempo pesquisando no Google para encontrar uma solução.

O primeiro problema é com os fixtures. Quando o nome da tabela é diferente do model, o nome do arquivo de fixtures deve ser igual ao nome da tabela seguido por “.yml”. Nos unit tests, o símbolo passado para o método fixtures deve ter este nome. No artigo sobre acesso a múltiplos bancos de dados, citei como exemplo uma tabela usuario_tb. Neste caso, o arquivo de fixtures deveria se chamar usuario_tb.yml, e o arquivo com unit tests deveria carregar esses fixtures assim:

class UsuarioTest < ActiveSupport::TestCase
  fixtures :usuario_tb
end

Em casos onde a única configuração fora do padrão seja o nome da tabela, a configuração acima é suficiente. Porém, no caso do exemplo citado no artigo anterior, onde o model não é mapeado numa tabela local, e sim num outro banco de dados, surgem outros problemas. O primeiro é que, ao tentar executar os testes, o rake informa que a tabela não existe. A única maneira que descobri para corrigir este problema foi criar esta tabela no ambiente de desenvolvimento. Ela não é usada para nada, mas se não for criada, os testes não funcionarão.

O segundo problema com esta configuração é que não é possível carregar os fixtures da maneira descrita acima. Em vez disso, é necessário usar o método create_fixtures da classe Fixtures. Para simplificar, como podem haver mais models configurados desta maneira, fiz a seguinte configuração:

  1. criar o método set_fixtures no arquivo test/test_helper.rb:
def set_fixtures (table, base)
  return unless (table && base.kind_of?(ActiveRecord::Base))

  ActiveRecord::Base.connection = base.connection
  Fixtures.create_fixtures(File.join(RAILS_ROOT, 'test', 'fixtures'), table) { base.connection }
end
  1. criar o método setup nos unit tests, utilizando esse método para cada arquivo de fixtures que será carregado:
def setup
  set_fixtures('usuario_tb', AutenticacaoDatabase)
end

No código acima, AutenticacaoDatabase é a classe abstrata usada como base para o model Usuario.

Com essas configurações é possível realizar os testes, com um único problema: não é possível referenciar os fixtures pelos labels. Para simplificar, como ainda não descobri uma maneira de corrigir isto, eu costumo definir os labels dos fixtures como números sequenciais, começando em 0. Assim eu posso buscar todos os dados da tabela (ex: Usuario.find(:all)) e referenciar o array pelos índices, que, neste caso, correspondem aos labels. Mas cuidado: o find(:all) não garante que o array retornado terá a mesma ordem do arquivo de fixtures. O ideal é criar fixtures com id sequencial, e adicionar o parâmetro order ao find.

Referências:


O excelente blog Code Commit publicou um artigo interessante sobre linguagens de programação: como podemos definir se uma linguagem é de baixo, médio ou alto nível?

O post apresenta as principais características de cada nível e as dificuldades de se classificar as linguagens num nível específico, e inclui um gráfico apontando a classificação de algumas das linguagens mais populares, de acordo com a experiência do autor. Muito interessante.