O Google acabou de anunciar o lançamento de uma nova linguagem de programação chamada Go. A linguagem foi desenvolvida por um time formado por cinco engenheiros do Google, incluindo Ken Thompson e Rob Pike, que são famosos por terem trabalhado no UNIX.
De acordo com o Google, além de oferecer suporte integrado a processos concorrentes, Go tem a pretensão de combinar a velocidade de desenvolvimento de uma linguagem dinâmica com a performance de uma linguagem compilada.
Eu ainda não testei a linguagem o suficiente para poder expressar qualquer opinião. De qualquer forma, a melhor coisa a fazer é testar por si próprio e tirar suas próprias conclusões. Abaixo você vai encontrar um breve tutorial com os passos que percorri para instalar tudo o que é necessário para começar a brincadeira no meu Mac Os. Espero que ele seja útil para você também.
Instalando o Mercurial
Mercurial é uma ferramenta de controle de versão distribuído, assim como o nosso querido Git. É necessário instalá-lo para poder baixar o código fonte do Go.
Eu utilizei o instalador disponível para Mac na página de downloads no próprio site da ferramenta.
Após a instalação, você pode verificar se tudo deu certo digitando o comando abaixo no terminal:
No meu caso, uma mensagem de erro foi disparada e a solução foi configurar algumas variáveis de ambiente. Se isto também acontecer com você, abra o arquivo ˜/.profile e acrescente as seguintes linhas no final:
Configurando o ambiente para a instalação do Go
Aproveite que você já está com o arquivo .profile aberto e também acrescente as seguintes linhas no fim do arquivo. Estas linhas servem para configurar o seu ambiente para a instalação do Go.
$GOROOT deve conter o diretório onde o código fonte da linguagem será baixado.
As variáveis $GOOS e $GOARCH servem para configurar o seu ambiente. As combinações validas são: linux/amd64, linux/arm, linux/386, darwin/amd64, darwin/386 e nacl/386. O código acima está preparado para a instalação no Mac OS 10.6.
E por último, a variável $GOBIN deve conter o diretório onde você deseja que os binários do Go sejam instalados. Se você optar por instalar os binários no diretório /usr/local/bin, aconselho ler esta discussão. Esta variável é opcional e o valor padrão para ela é o diretório $HOME/bin.
Para garantir que tudo está funcionando execute:
O resultado deve ser uma lista semelhante a esta:
Instalando
Após instalar o Mercurial, utilize o comando abaixo para recuperar o código fonte do projeto:
Antes de continuar, certifique-se de criar o diretório que você configurou para receber os binários e execute os comandos abaixo:
Criando o primeiro programa
Se tudo correu bem, você já tem o seu ambiente pronto para começar a programar em Go. E nada melhor do que um “Hello, world” para começar. Crie um arquivo com o nome helloworld.go e adicione o seguinte código nele:
Primeiro compile o arquivo com o comando:
Para “linkar” o arquivo utilize:
E para executar:
Agora é só continuar no tutorial criado pelo próprio time de desenvolvimento. E não deixe de compartilhar suas experiências com a linguagem deixando um comentário.
Wow, a major release? Yes, a major release and we have plenty reasons for that. Since me and José Valim were working on it for a couple months, we have quite a list :). So follow up:
1. Remarkable Core
Remarkable is now a framework for rspec matchers. Since Rails matchers are not simple, as Remarkable grew, we saw our matchers full of logic to show messages (description and failure messages) and that some methods could be automatically generated, reducing repetitive work.
Compare the allow_mass_assignment_of matcher in Remarkable 2.x and in Remarkable 3.0. Which one do you prefer? :)
So we built a DSL and called it Remarkable, which with Remarkable ActiveRecord and Remarkable Rails, provides you nice matchers/macros to speed up your tests. To install them, just do:
You can also install just remarkable or just remarkable_activerecord. But remarkable_rails brings you the whole packet.
2. I18n
On Rails Summit Latin America, Obie Fernandez talked about the Hash Rocket way and one of the items were that they actually print out the specs and give it to the client. Both me and José work with Rails projects and we couldn’t deliver the same to technical clients, because the output was in english. Well, we scratched our own itch!
This is how an English output would be like:
User
- should require name and email to be set
- should ensure length of name is within 3..40 characters
- should require unique values for email
- should ensure numericality of age allowing only integer values and allowing blank values
In Remarkable, we can have the same results in Portuguese:
Usuário
- deve exigir presença de nome e email
- deve garantir tamanho de nome seja entre 3..40 caracteres
- deve garantir valores únicos para email
- deve aceitar apenas números em idade permitindo somente valores inteiros e permitindo valores nulos
As you have noticed everything gets translated including the class and attributes names. This happens by setting up Remarkable and Rails yml files.
3. Macros
In Remarkable earlier versions, we coded the matcher (validate_presence_of) but most of the time we had to do some tweaks in other to a matcher becomes a macro (should_validate_presence_of). In Remarkable 3.0 it happens transparently.
In other words, if you are using Remarkable 3.0 to build your matchers you have cleaner matchers, I18n support and transparent macros creation.
4. Pending and disabled macros
In Remarkable 2.2, we added the ability to mark macros as disabled:
xshould_validate_uniqueness_of :name
And it would print on your specs output:
As some people pointed out, Remarkable was still lacking support for pending macros. Pending examples in Rspec would be:
pending("create managers resource")
end
pending("create managers resource")
end
And now in Remarkable, you have the pending group:
pending "create managers resource" do
should_have_one :manager
should_validate_associated :manager
end
In both cases a message “PENDING: create managers resources” is appended to matcher description.
5. More options to matchers
In Remarkable 2.2, we started to support ALL Active Record validations with ALL options. And now we extended support for association matchers!
From only :dependent and :through as supported options, now it accepts:
Besides matchers became much smarter. Whenever :join_table or :through is given as option, it also checks if the given table exists. Whenever :foreign_key or :counter_cache is given, it also checks if the given column exists.
6. Controllers matchers extended
To provide I18n, we ported redirect_to and render_template matchers from rspec-rails. We also added some extra options to respond_with and render template, so you can now do:
render_template 'edit', :layout => 'users'
respond_with 422, :content_type => Mime::XML,
:body => /Unprocessable Entitity/
And the route matcher is willing to make your life twice easier. Since it tests params recognitation and routes generation at once, you can cut your routing_specs at least in a half! So the following lines:
route_for(:controller => "companies",
:action => "show",
:id => "1").should == "/companies/1"
params_from(:get, "/companies/1").should == {:controller => "companies",
:action => "show",
:id => "1" }
Will become:
route(:get, "/companies/1", :controller => "companies",
:action => "show",
:id => "1")
7. Macro stubs
There is a presentation from José Valim that explains this feature with more details, but it basically makes your controllers specs from this:
@task ||= mock_model(Task, stubs)
end
Task.should_receive(:new).with({'these' => 'params'}).
and_return(mock_task(:save => true))
post :create, :task => {:these => 'params'}
assigns[:task].should equal(mock_task)
end
Task.stub!(:new).and_return(mock_task(:save => true))
post :create, :task => {}
response.should redirect_to(task_url(mock_task))
end
end
end
Become this:
mock_models :task
expects :new, :on => Task, :with => {:these => 'params' }, :returns => mock_task
expects :save, :on => mock_task, :returns => true
should_assign_to :task, :with => mock_task
should_redirect_to {task_url(mock_task) }
end
end
It aims to improve readability and be more DRY, since you declare your expectations/stubs just once. You can see the whole controller specs in rspec and remarkable way compared here.
It works by eval’ing the expectation/stubs chain and performing the action before each macro is executed. On should_assign_to it evals using expectations (:should_receive), on should_redirect_to it uses stubs (:stub!).
We also want to thank David Chelimsky that gave the nice hint to allow :post => :create inside the describe method and suggested to use mocha syntax. :)
8. Documentation, documentation and documentation
Yes, three times, because each project is very well documented. Browse them:
Remarkable:
http://remarkable.rubyforge.org/core/
Remarkable ActiveRecord:
http://remarkable.rubyforge.org/activerecord/
http://remarkable.rubyforge.org/activerecord/classes/Remarkable/ActiveRecord/Matchers.html (just matchers)
Remarkable Rails:
http://remarkable.rubyforge.org/rails/
http://remarkable.rubyforge.org/rails/classes/Remarkable/ActionController/Matchers.html (just matchers)
9. Volunteers?
Last but definitely not least: we need you!

We created a solid basis for matchers/macros creation. And we want to take it further by hosting even more matchers. So anyone who wants to work on Remarkable Datamapper, Remarkable Sequel, Remarkable Sinatra, please step in! We are waiting for you. :)
And all the others can equally help us by joining the group and posting bugs, matchers, enhancements in bug tracking system.
Remarkable 2.2.x series was made of frequent releases with deprecation warnings to consolidate the API. Until we get into 2.3, we improved support for ActiveRecord validations, fixed some bugs and made some changes, so we are safe and clear to work on new features and new matchers.
We also run our specs suite in Rails 2.3.x and Rspec 1.2.0 to assure that everything is working as supposed, and they are. :)
Keep on checking, we will have very good news, very soon. So get Remarkable on Github, appear in the mailing list and if you find some problems, tell us about them in the bug tracking system.
Thanks for everyone who collaborated, we are getting solid as rock. :)
Thomas Fuchs, o criador do script.aculo.us iniciou um novo projeto esta semana chamado Prototype helpers. O projeto visa disponibilizar uma série de scripts do Prototype criados por ele.
Eu particularmente gostei muito do defaultValueActsAsHint, um script que facilita a inclusão de dicas sobre o preenchimento de um formulário dentro do próprio campo no formato de um texto mais claro. Ao se clicar no campo o texto some, mas caso o usuário não preencha o campo o texto volta a aparecer ao perder o foco.

O efeito em ação
Enfim, é melhor mostrar do que falar. Clique aqui para ver um exemplo funcionando.
Como não sou um usuário de Prototype, fiz questão de portar este script para um plugin do jQuery, que faço questão de disponibilizar para vocês.
Para usar é muito fácil, lembrando que você deve estar usando o jQuery, basta incluir o script abaixo em sua página:
function$
return this.eachfunction
$().attr'_default'$().attr'value'
$().addClass'hint';
$().bind'focus'functionevent
if $().attr'_default' == $().attr'value'
$().removeClass'hint'.attr'value''';
;
$().blurfunction
if $trim$().attr'value' == ''
$().addClass'hint'.attr'value'$().attr'_default';
;
;
;
jQuery;
Download: jquery.defaultvalueactsashint.js
E definir quais campos se beneficiarão deste script, assim:
Como sempre, tudo está em um projeto no GitHub. Bom divertimento!
Desde que lancei a primeira versão do Remarkable tenho visto cada vez mais pessoas aderindo ao projeto para criar seus testes com maior rapidez. E com uma quantidade maior de pessoas usando nas mais diversas aplicações é claro que os bugs começaram a aparecer.
A maior parte dos problemas ocorriam por uma falha na arquitetura inicial do Remarkable, o que tornou necessário um refactoring no projeto inteiro para estruturá-lo melhor. Na primeira versão, internamente havia uma separação muito clara entre as duas sintaxes que o projeto oferecia. Com a reestruturação não existe mais esta separação, não importa qual é o seu estilo, RSpec ou Shoulda, internamente você sempre usará o mesmo código para realizar os testes.
Desta forma, acabamos por ganhar muitas macros novas.
Enquanto na versão em RSpec isto já era algo comum:
end
Na sintaxe do Shoulda apenas possuíamos macros should_[alguma coisa] e quase nenhuma should_not_[alguma coisa]. Mas agora todas as macros possuem as duas opções, assim:
should_belong_to :user
should_not_have_many :fleas
end
Além disso mais testes foram adicionados para garantir que problemas antigos não voltem para nos assombrar.
Para atualizar o Remarkable, execute no terminal (lembrando que no Windows não precisa usar o sudo):
Ainda falta um logo e um site para o projeto. Alguém se habilita?
O (Comovente) Guia de Ruby do Why

Acabei de atualizar o livro com novas traduções e correções. Devido a minha falta de tempo, acabei demorando para aplicar alguns dos patches que me foram enviados.
Na maioria das vezes, os colaboradores são rápidos demais e várias pessoas corrigem o mesmo texto de formas diferentes, e isto complica um pouco na hora de aceitar uma atualização. Eu tenho de olhar arquivo por arquivo antes de decidir qual será aplicado. Mas isto é bom, porque garante uma maior qualidade à tradução, embora torne o processo um pouco mais lento.
O livro pode ser encontrado na url: http://why.nomedojogo.com. Também existe uma versão para impressão em http://why.nomedojogo.com/print.html.
A processo de tradução já foi finalizado, todo o livro já está em português. Ainda falta ajustar algumas imagens e formatações de texto, mas acredito que se conseguirmos mais colaboradores teremos o livro completo e finalizado até o fim do ano.
Quer ajudar? Comece lendo o livro e quando encontrar algo errado altere aqui.
Finalmente a versão final do Rails 2.2 saiu!
Acho que já cobrimos todas as novidades desta nova versão, e de várias formas possíveis. Para ficar sabendo de tudo que temos de novo você tem três formas:
Série Edge Rails (Rails 2.2): clique aqui.
Rails Podcast Especial Rails 2.2: clique aqui.
Livro “Ruby on Rails 2.2 – O que há de novo?”: clique aqui.
Para atualizar, primeiro você precisa ter a versão 1.3.1 do RubyGems:
Então instale a última versão do Rails:
For a long time I was evangelizing Shoulda at Surgeworks and used it in my personal projects. The fact is, I didn’t have much success in convincing my co-workers to adopt Shoulda. On the other hand, they managed to convince me to learn and use RSpec.
RSpec is a very interesting Testing Framework. But I start to like it more after I started to use the Cucumber.
The great thing about Shoulda is that it’s simplifies tests for trivial things.
I got to like RSpec more and more, so I decided to adopt it as my official testing framework from now on. But I can no longer live without the resources that Shoulda offers me. So I decided to scratch my itch.
Remarkable
Initially, the main objective of Remarkable is to port all Shoulda macros to RSpec, but of course the plan is more ambitious than that. I have other ideas that will hopefully be especially useful for Rspec users.
At this point you may ask: “But aren’t there already plug-ins that do the same thing, such as skinny and rspec-on-rails-matchers. Why build something else?”
First, this isn’t simply “another” plugin with RSpec matchers. It also does a lot of things differently that I feel are better than other approaches.
Here are some of the things that make Remarkable special:
- It is not a plug-in; it’s a gem.
- All currently Shoulda macros are ported to RSpec.
- It has two different test syntaxes: one for those who like the RSpec style and another for those who are migrating their projects from Shoulda to RSpec.
- Tests.
- More tests.
- And a few more tests.
Unlike other similar projects, Remarkable is the only one that tests itself, and this is a big difference, believe me! How can we trust in a project that has no tests? How can you develop an open-source project with no tests? How do you ensure that the last commit didn’t break anything?
Install
Install Remarkable is very easy. It is stored in GitHub, so if you have never installed a gem via GitHub run the following:
Then install the gem:
In RAILS_ROOT/config/environment.rb:
config.gem "carlosbrando-remarkable", :lib => "remarkable", :source => "http://gems.github.com"
Using
All Remarkable macros can be accessed in two different ways. For those who prefer the Shoulda style, let’s look at some model tests:
fixtures :all
should_belong_to :user should_belong_to :owner should_belong_to :user, :owner
should_have_many :tags, :through => :taggings should_have_many :through_tags, :through => :taggings should_have_many :tags, :through_tags, :through => :taggings
should_require_unique_attributes :title should_require_attributes :body, :message => /wtf/ should_require_attributes :title should_only_allow_numeric_values_for :user_idend
Like Shoulda, right? That’s the idea! This syntax is for those who wish to migrate their Shoulda tests to RSpec. You basically just have to change context to describe and wrap your should statements with it {}.
But if you don’t like this syntax, you can also create the same tests as follows:
fixtures :all
Now with an RSpec style!
Macros
Here are all the available macros:
For Shoulda style, click here.
For RSpec style, click here.
Finalizing
This project has already reached the first goal, which was to port all Shoulda macros to RSpec. This has been done with great care and attention to detail, and I have tried to write lots of tests. But there is no substitute for using it in real life and finding areas that could use improvement.
Please use Remarkable and help me to make it even better!
Durante um bom tempo andei evangelizando o uso do Shoulda na Surgeworks e fiz muito uso dele em meus projetos pessoais. O fato é que não obtive muito sucesso em evangelizar meus colegas de trabalho a adotarem o Shoulda, por outro lado eles conseguiram me convencer a aprender e usar RSpec.
E realmente RSpec é um framework de testes muito interessante. Mas tudo ficou ainda mais interessante quando comecei a brincar com o Cucumber (pretendo escrever sobre isto no futuro).
Mas o segredo do sucesso do Shoulda é a maneira em que ele transforma testes comuns como verificar se as associações estão funcionando, se todas as validações necessárias foram adicionadas ou se uma simples informação foi adicionada corretamente a sessão, em algo extremamente trivial.
Passei a gostar cada dia mais do RSpec e decidi adotá-lo como meu framework oficial de testes de agora em diante. Mas não posso mais viver sem as facilidades que o Shoulda me oferecia. Então resolvi coçar a minha própria coceira.
Remarkable
Inicialmente, a função do Remarkable é portar para RSpec todas as macros do Shoulda, mas obviamente o plano é muito mais ambicioso do que isto. Tenho muita coisa em mente que tornará este projeto especialmente útil para os usuários de RSpec.
Neste momento você talvez se pergunte: “Mas já não existem plugins que fazem a mesma coisa, como o skinny e o rspec-on-rails-matchers, por exemplo?”. Sou obrigado a responder: “Sim”. Então, por que mais um projeto?
Por que mais um projeto?
Em primeiro lugar este não é simplesmente “mais um” plugin com matchers para RSpec. Vou usar um clichê agora, mas é mais pura verdade: “Este é um projeto feito do jeito certo!”.
Vejamos então uma lista com o que torna o Remarkable único:
- Não é um plugin, e sim um gem.
- Porta todas as macros atuais do Shoulda para RSpec.
- Possui duas sintaxes de escrita, uma para quem gosta do estilo RSpec e outra para os que estão migrando seus projetos Shoulda para RSpec.
- Testes.
- Mais testes.
- E mais um pouco de testes.
Sim, diferente de todos os outros projetos com o mesmo objetivo, o Remarkable é o único que possui testes, e este é um grande diferencial, acredite! Como se pode confiar em um projeto que não tem testes? Como evoluir um projeto open-source que não possui testes? O que garante que o último commit não quebrou alguma coisa que estava funcionando?
Instalação
Instalar o Remarkable é muito fácil. Ele está armazenado no GitHub, então se você nunca instalou um gem via GitHub execute primeiro:
Agora instale o gem:
Por último adicione a seguinte linha no seu arquivo RAILS_ROOT/config/environment.rb:
Usando
Todas as macros do Remarkable podem ser acessadas de duas maneira diferentes. Para aqueles que preferem o estilo Shoulda, vejamos como ficaria o teste de um modelo:
fixtures :all
should_belong_to :user
should_belong_to :owner
should_belong_to :user, :owner
should_have_many :tags, :through => :taggings
should_have_many :through_tags, :through => :taggings
should_have_many :tags, :through_tags, :through => :taggings
should_require_unique_attributes :title
should_require_attributes :body, :message => /wtf/
should_require_attributes :title
should_only_allow_numeric_values_for :user_id
end
Igualzinho ao Shoulda? É esta a idéia! Esta sintaxe é ideal para aqueles que desejarem migrar seus testes do Shoulda para o RSpec (tendo apenas de alterar de context para describe e de should para it) ou mesmo para os que adoram a jeitão do Shoulda, assim como eu.
Mas se você não gosta desta sintaxe, também pode criar os mesmos testes da seguinte forma:
fixtures :all
Agora muito mais no estilo RSpec!
Macros
Veja uma relação com todas as macros disponíveis na documentação do projeto.
Para o estilo Shoulda, clique aqui.
Para o estilo RSpec, clique aqui.
Finalizando
Este projeto já atingiu o primeiro objetivo, que era portar todas as macros do Shoulda para o RSpec. Tudo feito da maneira correta, com todos os cuidados e muitos testes. Mas nada melhor do que o uso na prática para encontrarmos pontos que devem ser melhorados.
Enfim, usem o Remarkable, e ajudem a torná-lo ainda melhor!
No último podcast mencionei minha escolha pelo Paperclip como meu plugin preferido para upload de arquivos. Depois disso algumas pessoas tem me perguntado porque usá-lo, já que o attachment_fu seria a opção mais conhecida.
Durante muito tempo usei o attachment_fu para esta função, mas em um projeto recente da Surgeworks optei por testar o Paperclip e depois disso acabei adotando-o como meu plugin padrão para uploads. Confesso que de inicio o grande motivo para experimentar o novo plugin foi por ele ter sido criado pela thoughtbot, o mesmo time que criou o Shoulda (que não estou usando mais, mas é uma outra história que vou explicar em um outro post), e como os caras são bons e tem criado inúmeros projetos interessantes, resolvi dar uma chance.
Mas foram alguns detalhes que me chamaram a atenção, como o fato de você não precisar de uma tabela extra no banco de dados para armazenar o caminho dos arquivos, a forma simplificada que ele oferece para se acessar e configurar o tamanho das fotos enviadas para o servidor, a macro de teste preparada para o Shoulda, a facilidade para configurar o acesso ao Amazon S3, entre outros detalhes que valorizam o plugin.
Enfim, não existe um grande motivo que chegue a desvalorizar o famoso attachment_fu ou torná-lo obsoleto. São apenas alguns pequenos detalhes que me conquistaram, só isso. É puramente uma questão de preferência pessoal.
Não importa qual plugin de upload você use, só não esqueça do :multipart => true na construção do formulário!
Usando o Paperclip em 3 passos
1. Instale o plugin em seu projeto Rails:
./script/plugin install git://github.com/thoughtbot/paperclip.git
2. Adicione três colunas na tabela que armazenará os dados dos arquivos:
end
3. Adicione uma linha no modelo com as configurações desejadas (tive de dividir em mais linhas para caber no blog):
end
Leve ao forno e sirva à vontade!
No exemplo acima acabamos de adicionar um avatar (a famosa fotinha) para os usuários. Para recuperar a foto enviada pelo usuário, use:
O attachment_fu também não é tão diferente disso, mas gosto mais do Papeclip. Apenas para fechar o artigo, um bônus! Para testar se o Paperclip está funcionando você pode pegar a macro para Shoulda, e depois adicionar uma linha ao teste do modelo:
end
Excelsior!
