Eu estava utilizando o cucumber com o selenium no desenvolvimento de uma aplicação e não estava funcionando.

Depois de muito fuçar vi que o problema era a incompatibilidade do webrat versão 0.5.1 com a versão do firefox que eu estou usando 3.6.6.

Para resolver o problema sem perder toda a sua manhã como eu siga as instruções abaixo:

   1. Crie um diretório onde você possa manipular o conteúdo do jar
     mkdir -p ~/tmp/selenium
     cd ~/tmp/selenium

   2. Copie o arquivo jar do Webrat para a pasta criada
     cp ~/.gem/ruby/1.8/gems/webrat-0.5.1/vendor/selenium-server.jar .

OBS: Eu instalei a gem webrat localmente no meu home, você deve realizar uma
adaptação para a sua realidade neste ponto.

   3. Descompacte os arquivos contidos no jar e delete o arquivo jar
     unzip selenium-server.jar
     rm selenium-server.jar

   4. Procure os arquivos *.rdf (deve existir 5 destes arquivos):
     find . -name "*.rdf"
     ./customProfileDirCUSTFF/extensions/{538F0036-F358-4f84-A764-89FB437166B4}/install.rdf
     ./customProfileDirCUSTFF/extensions/readystate@openqa.org/install.rdf
     ./customProfileDirCUSTFFCHROME/extensions/{503A0CD4-EDC8-489b-853B-19E0BAA8F0A4}/install.rdf
     ./customProfileDirCUSTFFCHROME/extensions/{538F0036-F358-4f84-A764-89FB437166B4}/install.rdf
     ./customProfileDirCUSTFFCHROME/extensions/readystate@openqa.org/install.rdf

   5. Em cada um destes arquivos você verá:
     <em:maxVersion>3.5.*</em:maxVersion>
   Mude para
     <em:maxVersion>3.6.*</em:maxVersion>

   6. todos os arquivos agora estão prontos. Gere novamente o arquivo jar
e mova para o local correto do webrat:
     zip -r selenium-server *
     mv selenium-server.zip selenium-server.jar
     mv selenium-server.jar ~/.gem/ruby/1.8/gems/webrat-0.5.1/vendor/selenium-server.jar

OBS: Eu instalei a gem webrat localmente no meu home, você deve realizar uma
adaptação para a sua realidade neste ponto.

	* Referência: http://www.qaautomation.net/?p=15

Você vai se deparar com isso:

warning: You did not specify any refspecs to push, and the current remote
warning: has not configured any push refspecs. The default action in this
warning: case is to push all matching refspecs, that is, all branches
warning: that exist both locally and remotely will be updated.  This may
warning: not necessarily be what you want to happen.
warning:
warning: You can specify what action you want to take in this case, and
warning: avoid seeing this message again, by configuring 'push.default' to:
warning:   'nothing'  : Do not push anything
warning:   'matching' : Push all matching branches (default)
warning:   'tracking' : Push the current branch to whatever it is tracking
warning:   'current'  : Push the current branch

Pode ficar tranquilo que não foi uma falha de segmentação no seu SO, mas sim uma mensagem de Warning que o novo git trás para te avisar que você precisa configurar a variável:

push.default

É claro que o seu comando vai continuar funcionando perfeitamente como sempre funcionou se você não configurar essa variável, mas você vai ficar agoniado com essa mensagem imensa de warning aparecendo toda hora na sua tela.

Acredite em mim

Então para ajeitar isso basta configurar variável com o comando:

git config push.default matching

Se você deseja que esta seja uma configuração padrão para todos os seus repositórios digite o comando:

git config --global push.default matching

Propaganda do PT para as eleições 2010

As discussões que acontecerem no evento estavam bastante acalouradas e contou com a presença de grandes personalidades do cenário político da Bahia, como o governador Jaques Vagner.

Não resisti ao meu impulso de tiete e tirei uma foto com ele

Paulo Henrique Amorim e eu

do blog do Nassif

A Abril consegue a primeira condenação

Ainda não tenho os dados à mão. Mas, pelo que sou informado, fui condenado a pagamento de 100 salários mínimos pelo juiz Vitor Frederico Kümpel, da 27ª Vara Cível, em processo movido por Mário Sabino e pela revista Veja. No primeiro processo – de Eurípedes Alcântara – fui absolvido.

Pode haver apelação nas duas sentenças.

Ao longo dessa longa noite dos celerados, a Abril lançou contra mim os ataques mais sórdidos que uma empresa de mídia organizada já endereçou contra qualquer pessoa. Escalou dois parajornalistas para ataques sistemáticos, que superaram qualquer nível de razoabilidade. Atacaram a mim, à minha família, ataques à minha vida profissional, à minha vida pessoal, em um nível só comparável ao das mais obscenas comunidades do Orkut.

Não me intimidaram.

Apelaram então para a indústria das ações judiciais – a mesma que a mídia vive criticando como ameaça à liberdade de imprensa. Cinco ações – quatro em nome de jornalistas da Veja, uma em nome da Abril – todas bancadas pela Abril e tocadas pelos mesmos advogados, sob silêncio total da mídia.

Não vou entrar no mérito da sentença do juiz, nem no valor estipulado.

Mas no final do ano fui procurado por um emissário pessoal de Roberto Civita propondo um acordo: retirariam as ações em troca de eu cessar as críticas e retirar as ações e o pedido de direito de resposta. A proposta foi feita em nome da “liberdade de imprensa”. Não aceitei. Em nome da liberdade de imprensa.

Podem vencer na Justiça graças ao poder financeiro que lhes permite abrir várias ações simultaneamente. Quatro ações que percam não os afetará. Uma que eu perca me afetará financeiramente, além dos custos de defesa contra as outras quatro.

Mas no campo jornalístico, perderam para um Blog e para a extraordinária solidariedade que recebi de blogueiros que sequer conhecia, de vocês, de tantos amigos jornalistas que me procuraram pessoalmente, sabendo que qualquer demonstração pública de solidariedade colocaria em risco seus empregos. Melhor que isso, só a solidariedade que uniu minhas filhas em defesa do pai.

Primeiro só utilize as dicas deste post caso você tenha um banco de dados muito grande, onde dump do banco leve bastante tempo para ser gerado.

Caso contrário basta você digitar o comando:


mysqldump -u user -p password database_name > database_dump.sql


no computador que você quer extrair o dump e depois o comando abaixo:


mysql database_name < database_dump.sql


no computador que você deseja armazenar o novo banco de dados.

Mas se este não é o seu caso e você possui uma base de 10gb ou mais, gerar o dump de uma bases dessas é muito complicado, pois demora muito e as vezes copiar todo o banco num pendrive e substituir os arquivos no novo computador vale mais a pena.

Então para isso basta copiar a pasta '/var/lib/mysql' para um pendrive, e tem que ser um pendrive grande já que isso só é aconselhável quando se está manipulando bases muito grandes , e depois substituir a pasta '/var/lib/mysql' do servidor no qual você quer que o banco de dados rode por esta pasta copiada.

É aconselhável fazer um bakcup da pasta /var/lib/mysql antes de substituir os arquivos. Assim você poderá repetir este processo e rodar o antigo banco de dados novamente.

No meu caso ficou assim:

Antes de rodar este comando no ‘Computador 2′ pare o apache.


/etc/init.d/apache stop


Observe que para fazer a cópia dos arquivos você terá que ter acesso ao root do computador.

Ao realizar a cópia, as pastas terão permissão somente para o usuário root, então rode o comando:


chown mysql.mysql /var/lib/mysql -R


Agora o usuário mysql terá permissão para acessar os arquivos.

Se você tentar inicializar o apache novamente terá o seguinte problema:


root@smurf:/var/lib# /etc/init.d/mysql start
Starting MySQL database server: mysqld ..
Checking for corrupt, not cleanly closed and upgrade needing tables..
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
root@smurf:/var/lib# ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)


Este erro ocorre pois você copiou a pasta do mysql de um outro computador que possuía configurações específicas daquele computador. Neste caso a configuração em questão é a senha do usuário do banco debian-sys-maint que é o usuário que o sistema operacional utiliza para realizar algumas operações no banco.

O usuário debian-sys-maint é como se fosse o usuário root do banco. Ele é utilizado para realizar executar certos scripts de manutenção no Debian.

Abaixo segue uma breve descrição deste usuário encontrada no arquivo README.Debian:

* MYSQL WON’T START OR STOP?:
=============================

You may never ever delete the special mysql user “debian-sys-maint”.
This user together with the credentials in /etc/mysql/debian.cnf are used by the init scripts to stop the server as they would require knowledge of the mysql root users password else.

Então para que o banco possa inicializar corretamente eu preciso dar acesso ao usuário debian-sys-maint ao banco. O Debian utiliza este usuário com a senha definida no arquivo ‘/etc/mysql/debian.cnf’.


[client]
host = localhost
user = debian-sys-maint
password = ********************
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
user = debian-sys-maint
password = ********************
socket = /var/run/mysqld/mysqld.sock
basedir = /usr


Então precisamos modificar a senha do usuário ‘debian-sys-maint’ pela senha contida neste arquivo.

Se você não tiver nenhum acesso ao banco, ou seja, nenhum login e senha de usuário para poder modificar a senha do usuário debian-sys-maint então continue lendo o post caso contrário leia também .

Reinicie o mysql com o comando:


/usr/bin/mysqld_safe --skip-grant-tables &


Logue no console mysql:


root@smurf:# mysql


E modifique as permissões do usuário ‘root’ e do usuário ‘debian-sys-maint’. Assim você terá acesso ao banco com o usuário ‘root’ também.


mysql> UPDATE mysql.user SET Password=PASSWORD('password') WHERE User='root';
mysql> FLUSH PRIVILEGES;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;

Substitua a palavra password pelo password que você encontrou no arquivo ‘/etc/mysql/debian.cnf’

Agora basta derrubar o servidor e carregá-lo novamente.


/etc/init.d/mysql stop
/etc/init.d/mysql start


Não use o comando ‘/etc/init.d/mysql restart’ pois o mysql poderá iniciar com a opção ‘–skip-grant-tables’ e você não quer isso

E tudo funcionará bem agora, pelo menos em teoria

Antigamente ao adicionar um repositório novo eu tinha um problema.

Eu seguia todos os passos descritos no tutorial para adicionar um novo repositório, e ao dar um pull eu recebia a seguinte mensagem de erro:


smurf@smurf:~/safernet/projetos/snscripts$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull ').
See git-pull(1) for details on the refspec.

branch.master.remote =
branch.master.merge =
remote..url =
remote..fetch =


Abrindo o arquivo de configuração do git (.git/config) eu notei que não existiam as informações do branch master que eu estava trabalhando no momento.

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@host.com.br:project_name.git
fetch = +refs/heads/*:refs/remotes/origin/*


Então eu editei o arquivo .git/config adicionando as informações do branch master:


[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@host.com.br:project_name.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master


Pronto.

Agora será possível dar um pull normalmente.


smurf@smurf:~/safernet/projetos/snscripts$ git pull
Already up-to-date.


Não sei se esta é a melhor forma de resolver o problema, mas é a que eu utilizo.

Espero que seja útil para alguém

O meu problema era que o nome do meu resource na aplicação cliente não era a correspondência exata do nome esperado no meu servidor.

Trocando em miúdos…

Eu tenho uma aplicação servidora com o seguinte controller:

class CategoriesController < ApplicationController

  def index
    @categories = Category.all
    respond_to do |format|
      format.json { render :json => @categories }
    end
  end

end

e outra aplicação cliente com o seguinte resource:

class RemoteCategory < ActiveResource::Base

  self.site = ‘http://localhost‘
  self.format = :json

end

A minha aplicação servidora roda na porta 3000, e a cliente na porta 3001.

O problema é que utilizando somente este código no meu resource, ele vai procurar pelo recurso no meu servidor utilizando o caminho:

O problema é que o meu servidor, obviamente , não tem esta rota. Uma vez que o controller que ele possui tem nome categories, gerando portanto a rota:

Entretanto eu não podia modificar o nome do meu resource para Category, pois eu já possuía um outro model com este nome na aplicação.

Então depois de perder alguns minutos encontrei a solução.

Basta definir o nome do elemento no resource. Neste caso em particular definir o element_name no objeto RemoteCategory:


self.element_name = 'category'


A configuração final do resource RemoteCategory fica então:

class RemoteCategory < ActiveResource::Base

  self.element_name = ‘category‘
  self.site = ‘http://localhost‘
  self.format = :json

end

Espero que seja útil para outras pessoas

Claro que algumas vezes eu acabo levando mais tempo automatizando a tarefa do que repentindo-a. Entretanto no somatório de de tempo que seria gasto para se realizar a tarefa quando o tempo tende a infinito, eu acabo economizando muito tempo de minha vida que seria gasto em coisas não tão interessantes

A bola da vez é a necessidade de se executar o comando ’ssh’ diversas vezes com diversos parâmetros diferentes.

Pesquisando um pouco encontrei um forma de otimizar meu tempo.

Se você criar um arquivo de nome ‘config’ na pasta ‘.ssh’ no seu home o ssh carrega este arquivo e procura por opções de configuração que você deseje criar.

Então:

mkdir "~/.ssh"
vim "~/.ssh/config"


Agora basta configurar o arquivo de acordo com a sua necessidade.

No meu caso utilizei os seguintes parâmetros de configuração:


Host leandro
User smurf
Port 22
HostName leandronunes.net

Host proxy
User smurf
Port 2299
HostName app.dcc.ufba.br
LocalForward 3128 app.dcc.ufba.br:8080


No primeiro caso:

Host leandro
User smurf
Port 22
HostName leandronunes.net

Eu ganho a possibilidade de acessar meu servidor apenas digitando o comando:

ssh leandro


O ssh lerá o arquivo ‘~/.ssh/config’ e saberá que eu quero acessar o servidor leandronunes.net, com o usuário smurf e utilizando a porta 22.

O segundo caso é semelhante ao caso anterior só que desta vez eu escolho outra porta para acessar o meu servidor cujo host é servidor.com.br

Eu acesso o servidor com o comando:

ssh servidor


O terceiro e último exemplo é mais legalzinho.

Host proxy
User smurf
Port 2139
HostName ufba.br
LocalForward 2148 ufba.br:7070


Eu posso acessar o servidor da UFBa, que utilizo como proxy para acessar o periódicos da capes de casa, com o seguinte comando:

ssh proxy


Somente com isso, o ssh já entende que é para fazer um tunel ssh da minha porta ‘2148′ para a porta ‘7070′ do meu host ‘ufba.br’, que eu acesso utilizando o usuário ’smurf’ na porta ‘2139′.

Seria algo equivalente ao comando:

ssh -p 2139 app.dcc.ufba.br -L 2148:app.dcc.ufba.br:7070


É claro que você precisa configurar o seu navegador ( que eu espero que seja o firefox ) para utilizar o proxy.

Existem muitas outras opções que podem ser realizadas utilizando esta técnica.

Se divirta!

Pois é, agora isso não me incomoda mais. Basta criar um arquivo de nome ‘.irbrc ‘ no home com o seguinte conteúdo:

Para que o histórico de comandos funcione você precisa da biblioteca ‘libwirble-ruby’ instalada.

aptitude install libwirble-ruby

Pronto. Tudo funciona bonitinho agora