Olá pessoal, ultimamente recebi tarefas para desenvolver duas APIs de integração dos projetos em que estou alocado e escolhemos fazer a integração entre os vários projetos utilizando gems (para entender um pouco mais sobre rubygems leia: http://rubygems.org/).
Fuçando pela internet achei alguns geradores de gem e escolhi utilizar o newgem.
O que é newgem e para que serve?
O newgem tem a função de gerar um esboço para suas gems possibilitando o compartilhamento do seu código no RubyForge.
Instalando
Para instalar esta gem é bem simples:
sudo gem install newgem
Utilização
É muito simples criar uma nova gem, basta executar:
newgem wizzo
Ao executar este comando você terá o seguinte output:
create
create doc
create lib
create script
create tasks
create lib/wizzo
create History.txt
create Rakefile
create README.rdoc
create PostInstall.txt
create lib/wizzo.rb
dependency install_test_unit
create test
create test/test_helper.rb
create test/test_wizzo.rb
dependency install_website
create website/javascripts
create website/stylesheets
create config
exists script
exists tasks
create website/index.txt
create website/index.html
create config/website.yml.sample
create script/txt2html
dependency plain_theme
exists website/javascripts
exists website/stylesheets
create website/template.html.erb
create website/stylesheets/screen.css
create website/javascripts/rounded_corners_lite.inc.js
dependency install_rubigen_scripts
exists script
create script/generate
create script/destroy
create script/console
create Manifest.txt
readme readme
Important
=========
* Open Rakefile
* Update missing details (gem description, dependent gems, etc.)
É possível utilizar algumas opções ao gerar uma gem que tornam a geração mais interessante.
Por padrão o projeto gerará testes baseados no Test::Unit, caso você queira utilizar RSpec existe a opção: -T rspec
Outras opções interessantes é poder escolher o tipo de versionamento a ser utilizado: -c ou –svn para utilizar subversion ou -g ou –git para utilizar git.
A opção -j ou –jruby criará um esboço de gem para JRuby.
Para verificar as demais possibilidades:
newgem --help
Configurando
As configurações da gem serão centralizadas no Rakefile. Elas são feitas usando o Hoe e em sua maioria são de integração com o RubyForge. Para indicarmos que nossa gem possui depedências para poder ser instaladas devemos utilizar a seguinte configuração para o Hoe:
$hoe = Hoe.new('wizzo', Wizzo::VERSION) do |p|
p.extra_deps = [
['activesupport','>= 2.0.2'],
]
end
Neste caso mostrado acima será é necessário existir um versão igual ou superior à 2.0.2 da gem activesupport para que a nossa gem possa ser instalada.
Outro tipo de dependência que pode ser configurada é a dependência no ambiente de desenvolvimento:
p.extra_dev_deps = [
['newgem', ">= #{::Newgem::VERSION}"],
['factory_girl']
]
Por padrão o newgem coloca ele mesmo como dependência para o este ambiente, e no exemplo acima adicionei o factory_girl como necessário para o ambiente.
É possível omitir alguns arquivos ao gerar a gem para tanto basta setar a seguinte propriedade no Hoe:
p.clean_globs |= %w[**/.DS_Store tmp *.log *.swp nbproject]
Existe um conjunto de arquivos que são ignorados por padrão; no exemplo acima adicionei os arquivos *.swp e a pasta de projetos gerada pelo Netbeans.
Bom, é isto pessoal. Espero que tenham gostado e curtam o newgem!
Abraços.
$ cd ~/ruby_projects
$ newgem wizzo
create
create doc
create lib
create script
create tasks
create lib/wizzo
create History.txt
create Rakefile
create README.rdoc
create PostInstall.txt
create lib/wizzo.rb
dependency install_test_unit
create test
create test/test_helper.rb
create test/test_wizzo.rb
dependency install_website
create website/javascripts
create website/stylesheets
create config
exists script
exists tasks
create website/index.txt
create website/index.html
create config/website.yml.sample
create script/txt2html
dependency plain_theme
exists website/javascripts
exists website/stylesheets
create website/template.html.erb
create website/stylesheets/screen.css
create website/javascripts/rounded_corners_lite.inc.js
dependency install_rubigen_scripts
exists script
create script/generate
create script/destroy
create script/console
create Manifest.txt
readme readme
Important
=========
* Open Rakefile
* Update missing details (gem description, dependent gems, etc.)
Filed under: ruby | 1 Comment
Decidi começar a utilizar vim para desenvolver aplicações em Ruby. Desde que então criei um novo blog chamado Vi[m] Dojo um site em inglês mostrando o que tenho aprendido no vi desde a lição mais básica. Ultimamente tenho montado um ambiente de desenvolvimento que me ajude na produtividade e para isso é necessário dar hack no vim. Muitos já falaram sobre como fazê-lo, inclusive o Fabio Akita. O que vou mostrar aqui são os passos que precisei seguir para conseguir utilizar o vim para desenvolver em Ruby:
Compilando o vim:
O vim por padrão não vem com o ruby interpreter instalado e é necessário recompilá-lo para incluir este interpretador.Para verificar se o vim instalado na sua máquina está com o ruby interpreter instalado entre no vim e digite :version, caso apareça um -ruby significa que é necessário recompilar.
Para recompilar use:
sudo apt-get install libncurses5-dev ctags # Para compilar corretamente o vim e adicionar o ctags wget ftp://ftp.vim.org/pub/vim/unix/vim-7.2.tar.bz2 wget http://www.linuxfromscratch.org/patches/blfs/svn/vim-7.2-fixes-5.patch tar -xvjf vim-7.2.tar.bz2 cd vim72 patch -Np1 -i ../vim-7.2-fixes-5.patch && echo '#define SYS_VIMRC_FILE "/etc/vimrc"' >> src/feature.h && echo '#define SYS_GVIMRC_FILE "/etc/gvimrc"' >> src/feature.h && ./configure --prefix=/usr --with-features=huge --enable-rubyinterp && make sudo make install sudo ln -snfv ../vim/vim72/doc /usr/share/doc/vim-7.2 sudo rm /etc/alternatives/vi sudo rm /etc/alternatives/vim sudo rm /etc/alternatives/vimdiff sudo ln -s /usr/bin/vim /etc/alternatives/vi sudo ln -s /usr/bin/vim /etc/alternatives/vim sudo ln -s /usr/bin/vimdiff /etc/alternatives/
Configurando o vim:
git clone git://github.com/akitaonrails/vimfiles.git ~/.vim cd ~/.vim/ git submodule init git submodule update cp ~/.vim/vimrc ~/.vimrc sudo gem install jamis-fuzzy_file_finder
A forma mais fácil de testar se o seu ambiente foi iniciado é abrir um arquivo de um projeto rails e digitando :help rails, deverá aparecer todos os comandos do plugin. Para testar o FuzzyFinder pressione Ctrl + F, deverá aparecer uma lista de arquivos no lado esquedo.
Update 1: Antônio Carlos, um grande amigo meu, tentou refazer os passos e descobriu algumas modificações que são necessárias para poder rodar o script acima (linhas 1 e 6). Obrigado pelo feedback!
Update 2: Gabriel, tentou refazer os passos e identificou que alguns links (linhas 2 e 3) estavam fora do ar, busquei na internet os novos links e agora está corrigido com as URLs mais novas. Obrigado Gabriel.
Sites para referência:
http://www.akitaonrails.com/2009/01/03/rails-on-vim
http://www.linuxfromscratch.org/blfs/view/svn/postlfs/vim.html
http://blog.dotkam.com/2008/08/02/make-railsvim-work-compile-vim-from-sources/
http://dougsland.livejournal.com/51568.html
Filed under: Uncategorized | 4 Comments
Depois de muito tempo consegui descobrir uma forma de corrigir o erro de incompatibilidade entre o Flash e os meus programas de áudio no Ubuntu 8.04.
O erro ocorria após abrir um site de vídeo, como o Youtube por exemplo, se eu tentasse abrir o Songbird ele não conseguia tocar as minhas músicas. E caso abrisse o Songbird e tentasse abrir um video no Youtube ele também não tocava audio.
Eu tinha que reiniar o Firefox para liberar o Pulse Audio e só assim poderia utilizar aplicativos de áudio.
A solução é bem simples.
- Remova o pacote padrão do flash:
sudo apt-get remove flashplugin-nonfree - Baixe o pacote para o flash player 10 no site da adobe em:
http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_10_linux.deb
- Instale o pacote
- Reinicie o Firefox
Este pacote do novo flash player é compatível com Firefox 2.x e 3.x.
Abraços
Filed under: Ubuntu | Leave a Comment
Depois de muito apanhar consegui configurar a página do oxenterails.com para enviar e-mails por meio do gmail.
Para tal tive que fugir da configuração padrão de mailer do radiant, pois não consegui fazer a configuração utilizando o plugin da radiant (http://github.com/radiant/radiant-mailer-extension/tree/master).
Primeiramente instalei o fork do plugin do ntalbott:
git clone git://github.com/ntalbott/radiant-mailer-extension.git \
vendor/extensions/mailer
Para enviar emails por meio do gmail é necessário instalar o plugin action_mailer_optional_tls. O problema que encontrei é que não existe script/plugin para aplicativos radiant. Então rodei o seguinte comando:
svn export http://svn.douglasfshearer.com/rails/plugins/action_mailer_optional_tls/ \
vendor/plugins/action_mailer_optional_tls
Como indicado em http://wiki.github.com/radiant/radiant/mailer-extension, após a linha ResponseCache.defaults[:logger] inseri o seguinte código de setup do ActionMailer:
ActionMailer::Base.smtp_settings = {
:tls => true,
:address => "smtp.gmail.com",
:port => 587,
:domain => "mailerserver.com.br",
:username => "maileruser@mailerserver.com.br",
:password => "mailerserverpassword",
:authentication => :plain
}
ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.raise_delivery_errors = true
ActionMailer::Base.perform_deliveries = true
O body do mailer ficou no seguinte padrão:
<r:mailer:form name="contact">
<fieldset>
<legend>Contato</legend>
<r:error on="name">
<span class="error">Nome é necessário!</span><br />
</r:error>
<label for="name">Nome:</label>
<r:text name="name" required="true" /><br />
<r:error on="email">
<span class="error">E-mail é necessário!</span><br />
</r:error>
<label for="email">E-mail:</label>
<r:text name="email" required="true" /><br />
<label for="message">Mensagem</label><br />
<r:error on="message">
<span class="error">Por favor digite uma mensagem!</span><br/>
</r:error>
<r:textarea name="message" required="true" /><br /><br />
<input type="submit" value="Enviar!" />
</fieldset>
</r:mailer:form>
O yml do mailer ficou no seguinte padrão:
subject: Contato from_field: email redirect_to: /contact/thank-you/ recipients: - contact@mailerserver.com.br
Atente para o detalhe do redirect_to, criei uma página para retorno.
E o email ficou configurado segundo o padrão:
Olá, <r:mailer:get name="name"/> (<r:mailer:get name="email"/>): <r:mailer:get name="message"/>
Com estas configurações consegui fazer o mailer funcionar. 
PS: desculpem pela demora nos posts, tempo é algo muito raro…
Filed under: Radiant, Ruby on Rails | Leave a Comment
Esses dias recebemos os notebooks novos da empresa, são notebooks Dell Vostro 1310.
Ao tentar instalar o Ubuntu 8.04 no notebook encontrei alguns problemas, um destes foi com os microfones.
Este modelo vem com dois microfones, um embutido e um microfone externo (para headset por exemplo).
Procurei várias formas para fazê-los funcionar, o único que eu consegui foi o microfone externo. Para configurá-lo deve se adicionar a seguinte linha no arquivo /etc/modprobe.d/alsa-base :
options snd-hda-intel model=dell
É necessário fazer alguns ajustes no Volume Control e pronto! Ready to use.
Estes passos funcionaram na máquina que testei. Por favor, comentem caso funcione ou não na sua máquina.
Filed under: Ubuntu | 6 Comments
Hoje, ao tentar usar o rake spec:rcov para verificar a cobertura do meu código percebi que alguns testes de roteamento estavam falhando e a exceção lançada era a seguinte:
undefined method `to_plain_segments' for #<ActionController::Routing::RouteSet:0xb7659174>
O mais estranho era que ao executar os testes do RSpec (rake spec) nenhum erro era detectado.
Este erro ocorre por um bug no rcov 0.8.1.2.0.
Existe um fork do projeto rcov criado pelo usuário spicycode no github que corrige este erro. Basta usar o comando abaixo para poder ver seus testes de roteamento que estavam falhando voltando a ficar verdes:
sudo gem install spicycode-rcov -s http://gems.github.com
Agradecimentos ao post do Daniel no Kopongo.
Filed under: Ruby on Rails, errors | Leave a Comment
Tags: rails, rcov, rspec, rubyonrails
DRier database.yml
When we create a new Rails project a database.yml is created for us, and it looks like this one:
development: adapter: mysql encoding: utf8 database: project_development username: root password: password socket: /var/run/mysqld/mysqld.sock test: adapter: mysql encoding: utf8 database: project_test username: root password: password socket: /var/run/mysqld/mysqld.sock production: adapter: mysql encoding: utf8 database: project_production username: root password: password socket: /var/run/mysqld/mysqld.sock
But, RoR is strongly based on DRY (Don’t Repeat Yourself) concept. And, as we can see, we have a lot of duplicated lines here.
If we pay attention, some lines of the database.yml file are repeated on development, test and production databases, and for most of the projects we have this databases on the same local. So, we have some lines repeated:
adapter: mysql encoding: utf8 username: root password: password socket: /var/run/mysqld/mysqld.sock
Googling, you can find a “DRY database.yml” scratched like this one:
login: &login adapter: mysql username: root password: password socket: /var/run/mysqld/mysqld.sock development: <<: *login database: project_development test: <<: *login database: project_test production: <<: *login database: project_production
But, for me we still have some duplicated lines, and I don’t like it. So here goes the “DRier database.yml”:
login: &login adapter: mysql username: root password: password host: localhost <% ["development", "test", "production"].each do |environment| %> <%= environment %>: <<: *login database: project_<%= environment %> <% end %>
Enjoy it!
Filed under: Ruby on Rails | Leave a Comment
Tags: dry, rails, ruby, rubyonrails, yml
DRier database.yml
Ao criar um novo projeto rails é criado juntamente com o projeto um arquivo database.yml parecido com este:
development: adapter: mysql encoding: utf8 database: project_development username: root password: password socket: /var/run/mysqld/mysqld.sock test: adapter: mysql encoding: utf8 database: project_test username: root password: password socket: /var/run/mysqld/mysqld.sock production: adapter: mysql encoding: utf8 database: project_production username: root password: password socket: /var/run/mysqld/mysqld.sock
Mas, como sempre ouvimos, um dos conceitos base do RoR é o DRY (Don’t Repeat Yourself – Não repita a si mesmo). E como podemos ver neste arquivo existem diversas linhas duplicadas.
De uma forma geral as bases de dados de desenvolvimento, produção e teste residem na mesma máquina e portanto temos algumas linhas que sempre iremos repetir:
adapter: mysql encoding: utf8 username: root password: password socket: /var/run/mysqld/mysqld.sock
Googlando não é nada difícil encontrar o seguinte modelo de database.yml conhecido como “DRY database.yml”:
login: &login adapter: mysql username: root password: password socket: /var/run/mysqld/mysqld.sock development: <<: *login database: project_development test: <<: *login database: project_test production: <<: *login database: project_production
Mas, concordemos que ainda existe uma certa duplicação de código. Então lá vai a versão DRier do database.yml:
login: &login adapter: mysql username: root password: password host: localhost <% ["development", "test", "production"].each do |environment| %> <%= environment %>: <<: *login database: biblemarks_<%= environment %> <% end %>
Filed under: Ruby on Rails | Leave a Comment
Tags: dry, rails, ruby, rubyonrails, yml
If you have created an Abstract Class you may want to test its non abstract methods. But there is one problem: we can’t instantiate abstract classes.
There are two ways to test their non abstract methods:
Testing Abstract Classes Through Their Children’s
Suppose we have the following abstract class named Person:
public abstract class Person {
private String firstName;
private String lastName;
public abstract void doAnything();
public String getFullName(){
return firstName + " " + lastName;
}
// Getters and setters here...
}
And a Boss class that extends Person:
public class Boss extends Person{
@Override
public void doAnything() {
System.out.println("Do anything...");
}
}
And you want to test the Person.getFullName() method. So you must create the test below:
public class PersonTest {
Person person;
@Before
public void setUp() {
person = new Boss();
person.setFirstName("Anderson");
person.setLastName("Dias");
}
@Test
public void getFullName(){
assertEquals("Anderson Dias", person.getFullName());
}
}
On this first case, it will work fine and the test will pass no matter. But there is a problem, because it’s been assumed that the Boss class will never override the getFullName() method. If the Boss class changes, the test will fail.
public class Boss extends Person {
@Override
public String getFullName(){
return "Mr. " + super.getFullName();
}
@Override
public void doAnything() {
System.out.println("Do anything...");
}
}
So, what to do? Let’s see another way to test Abstract Classes.
Creating Mock Implementations for Abstract Classes
There is a simple way to test them. You can create a mock class that simulates the implementation of an abstract class. You will guarantee that the non abstract methods will be the same of the parent abstract class.
Let’s see a sample Mock implementation:
public class MockPerson extends Person {
@Override
public void doAnything() { }
}
Notice that you don’t have to test the Person abstract class methods right now. So you don’t have to implement the doAnything() method body on the Mock implementation.
And our Test Case will be:
public class PersonTest {
Person person;
@Before
public void setUp() {
person = new MockPerson();
person.setFirstName("Anderson");
person.setLastName("Dias");
}
@Test
public void getFullName(){
assertEquals("Anderson Dias", person.getFullName());
}
}
That’s a simple way to test abstract methods.
Of course there are some specifics cases that Mock Objects don’t solve, in those cases you will need to test using the first strategy.
public abstract class Person {
private String firstName;
private String lastName;
public abstract void doAnything();
public String getFullName(){
this.doAnything();
return firstName + " " + lastName;
}
// Getters and setters here...
}
In this case our non abstract method ( Person.getFullName() ) calls the abstract method ( Person.doAnything() ), and the implementation of Person.doAnything() method may be decisive for the Person.getFullName() return. So, the only way to test it will be by the Person children classes.
I hope you enjoy it.
Thanks to Raquel Carsi for help me to write this post.
Filed under: TDD | 1 Comment
Tags: java, junit, TDD, testing, unit test
Rubygems execution error
When I am trying to use rubygems on Ubuntu 7.10 I took this error:
"rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- sources (LoadError)"
This error occurs when GEM_HOME system variable is unset. To solve that first check your gems directory:
# locale will find occurrences of gems on the system # look for the one that points to gems home directory locate gems
The default path for rubygems ( ruby version 1.8 ) is “/var/lib/gems/1.8″.
So now create the GEM_HOME variable:
# export GEM_HOME="path_to_gems" export GEM_HOME="/var/lib/gems/1.8/"
And rubygems will work well.
Filed under: errors | Leave a Comment
Tags: gems, rails, ruby, rubygems, rubyonrails
Recent Entries
- Criando novas RubyGems com newgem
- Usando vim para programar em Rails
- Inconpatibilidade entre Flash 9 e Pulse Audio
- Enviando e-mail de contato no Radiant
- Configurando Ubuntu em Dell Vostro 1310 [Microfone externo]
- Undefined method ‘to_plain_segments’
- DRier database.yml
- DRier database.yml
- Writing unit tests for abstract classes
- Rubygems execution error
- puts “Hello World!”
Categories
- errors (2)
- Radiant (1)
- ruby (1)
- Ruby on Rails (4)
- TDD (1)
- Ubuntu (2)
- Uncategorized (2)
