Shiny happy people coding

Coding with smile

Test Your Rabl’s View

| Comments

Since several month, I use only Rabl to do all my API. To me this gems is really awesome. Before using it, I try doing all of my API with the #to_json method. But it was a nightmare. If you already try to do that, you understand what I mean. The most bad case is when you want represent your object in different way depending of where is represent.

Rabl simply clean

To manage your JSON and XML view, the most common gem is JBuilder and XmlBuilder, both are created by DHH. To me it’s not a good DSL and can be a little too verbose. Rabl has a clean a simplest DSL and you just need one view to generate XML and JSON. You can even generate some other output with Rabl.

A little example of Rabl’s view :

1
2
3
4
5
object @post
attribute :content
child(:author) do
  attribute :firstname, :lastname
end

Test your Rabl’s view

To test the output of this view, you have multiple choice. You can generate this view in an integration test and test this output. You can do it in your controller test. Or the best, test only your output on your view test. With this last choice, you can define what you really put on your view and test only your rabl representation. In this case you can have a flexible and fast test.

Since Rabl 0.6.0, a new method help to generate your view directly. It’s with this method you can simply test our view.

An example of how we can test our view ( spec/views/posts/show_rabl_spec.rb) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
require 'spec_helper'

describe "blogs/show.rabl" do

    let(:auhor) { Author.new(:firstname => 'Cyril', :lastname => 'Mougel') }
    let(:blog) { Blog.new(:content => 'hello', :author => author) }
    let(:valid_json) {
      {
        :content => blog.content,
        :author => {
          :firstname => author.firstname,
          :lastname => author.lastname
        }
      }.to_json
    }

    let(:render) {
      Rabl.render(
        blog,
        'blog/show',
        :view_path => 'app/views'
      )
    }

    it 'should render valid_json' do
      render.should eql(valid_json)
    end

end

We have a really simple test unit with a complet JSON validation. This test is fast because no need doing some database request and no controller stuff needed.

But, I found a little limitation in this method. You can’t pass some locals variables. So you can only test this render with value pass on the first params. If you have some other object you want use, you can’t. I start a Pull Request to pass this variables in a :locals options. You can follow it on github

Traduction Française

Vundle the Bundler of Vim

| Comments

I use vim like text editor since my school. I allways appreciate vim and I really don’t want change to another one.

How I manage my plugin around the time

Vim is really powerfull with this plugins. You need really quick use it. It’s really important to manage it. All around the time, I change how I manage it with new technique inside vim or develop by other developper.

Handmade management

In start of my vim usage, I manage my plugin by copying file in different directory. I put in versionning my .vimrc and .vim. But this technique can be hard to maintain in time. The installation is not really simple and know if you need update or not is hard too. So the evolution of plugins become rare.

Vimball management

In vim evolution, the vimball management system was implemented. With this vimball, you can more easily install plugin and know which version you use. So you can improve your plugins management. But to know if a new version is available, you need go to vimscript.org and check each of your plugins. The update become rare too.

git-submodule management

With github, all plugins become a git repository. We can check all new commit on our favorite plugin. I start to link all plugin in a new submodule and link file in good directory. The update was really simple and my plugins can be up to date. But the installation become really hard.

Janus management

Yehuda Katz and Carl Lerche start a new project call janus. This project’s goal is an easy plugin management by rake task. In this Rakefile, you can see the list of your plugin and with some rake task you can install it and update it. This project was really great. It start with a bunch of plugins pre-configure and good if you start using vim and you are not aware with what plugin can be good to you. But in time, the management can be a little tricky with version of janus. So it’s a really good project to start vim.

Pathogen management, the first vim plugin to manage you plugins

To closed of janus’s released, Tim Pope ( a very important vim plugin developper ) release Pathogen. This plugin help to manage your vim plugin directly in your vimrc file. I don’t really use it. But a lot of people say it’s a really good plugin. There are a lot of fork of janus trying to use pathogen directly.

Vundle management

Now, someone told me about a very good plugin to manage his vim’s plugin, Vundle. As Pathogen, the plugin management is do directly in your vimrc. His usage is really simple and well designed. If you are a ruby guy and use already Bundler, you can easily understand how works Vundle and how use it. Vundle is directly inspired of this project.

Using Vundle

Install Vundle

To install vundle, you just need clone the project’s repository in your .vim directory and add 2 lignes in your vimrc file

1
git clone https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle

Add in your vimrc

1
2
set rtp+=~/.vim/bundle/vundle/
call vundle#rc()

Configure your plugins

To use vundle after his installation, it’s really simple. You just need add in your vimrc a Bundle command with path to your plugin. By example, if you want install the vim-rails plugin, you juste need add this line in your vimrc :

1
Bundle 'tpope/vim-rails.git'

Install your plugins

Now, when your vim is open, you can install or update your plugins by two vim’s command.

  • BundleInstall install your plugins
  • BundleInstall! update your plugins

Now, you can try this wonderfull plugin and install all plugins you want try.

My vimrc

If you want see my own vimrc your can see it on one of my github repository. With the Vundle help, it’s really simple to understand what plugin I really use. All is in only one file.

Traduction Française

Dante Lets You Put Some Daemon in Your Code

| Comments

Few days ago, I needed to convert a ruby script into daemon.

In my deployment toolkit, I use monitrc to monitor my scripts. Monit checks a pidfile to know if the process is running or not.

So, I looked the best ruby solution to easily to transform this script in deamon generating its own pidfile.

The most popular project in ruby to convert a ruby script into daemon is daemons. I’ve tried several times in the past and never became fan. It’s too complicated and doesn’t generate pidfile. You have to manage everything yourself.

The second big project about managing daemon in the ruby community is daemon-kit. I’ve tried it several times without success. To me, it’s way too big and not flexible enough to use on a simple daemon script.

Therefore, I decided to see if the ruby community had a new gem for this purpose. I discovered dante. This project was exactly what I really needed. It really gets the job done.

By default, Dante manages few options in commandline. These options are all what you really need. No more useless stuff.

Default options available :

1
2
3
4
5
6
7
8
9
10
11
-p, --port PORT           Specify port
                          (default: )
-P, --pid FILE            save PID in FILE when using -d option.
                          (default: /var/run/scheduler.pid)
-d, --daemon              Daemonize mode
-l, --log FILE            Logfile for output
-k, --kill [PORT]         Kill specified running daemons - leave
blank to kill all.
-u, --user USER           User to run as
-G, --group GROUP         Group to run as
-?, --help                Display this usage information.

You can define the PID, the log file, the user and group launching this daemon (if launched in root). The only argument which is not essential to me is the PORT. But this gem was created to launch rack applications. So it’s really needed in this case.

An other great feature is the option extension. You can add some new options. Dante manage to you all options pass on your script.

To use it, it’s really simple. You just put Dante.run and put your code in a block. :

1
2
3
Dante.run('myapp') do |opts|
  myapp.run
end

I am really impressed by this gem by the gomiso company. Thanks for creating such a good gem.

Traduction Française

Moped the New mongoDB Ruby Driver

| Comments

In December 2011, Bernerd Schaefer created a new MongoDB ruby driver. This new driver is not supported by 10Gen (MongoDB creator) directly. The official MongoDB ruby driver is the gem mongo-ruby-driver.

Goal of this gem

This gem will be created after some frustration from the Mongoid Core developer The team proposed to change the internal software design on MongoDB Ruby driver but all changes were refused.

Thread-safe

One of this gem’s goals was to have a more thread-safe gem than the official MongoDB ruby driver. This official gem is sometimes considered like not 100% thread-safe like reported Mike Perham. Since the ruby community discovered again the thread, it hasn’t stopped of being a real problem. With Moped we can use sidekiq.

No more extension

If you want to use the MongoDB official driver, you will need to install another gem bson_ext. Without it, you will have some performance penalties. As this gem is a C extension, this gem has 2 versions in order to be compatible with JRuby. One in C and the other in Java. It’s therefore harder to maintain.

With Moped, no more extension needed. Everything is done in pure ruby. A benchmark shows that this moped’s bson version is even faster than the C extension.

The only case where moped is slower than bson_ext is the ObjectId generation, like reported on Mongoid mailing-list. But, after all, Moped is new. It can be improved in the future.

Cleanest API

The Moped API is really clean and simple. It depends on the developers using it. But, to me, it’s a good API because it’s really more “ruby way”.

Better Replicat Set management

One of big feature of MongoDB is the ReplicatSet. With Moped, the ReplicatSet management is even better. There are no exception raise when a node is down. The switch off of node is immediately done by Moped.

No need to list all of your node. Moped does it automaticly with the MongoDB mechanism. You can even add new nodes in your Replicat without restarting your application.

Limitation

Moped has some limitation in front of Mongo-ruby-driver.

Ruby 1.9 only

Moped works only with Ruby > 1.9. in order to avoid troubles with the 1.8 compatibilities. For instance, the Socket on Ruby 1.8 series is not the best.

No GridFS support

GridFS is not supported on Moped. This choice has been made to limit the size of the Moped code core. In the future, this feature may be added in a Moped extension.

Mongoid 3 integration

Mongoid 3 now uses only MongoDB ruby driver. Moped is a new dependency of Mongoid and mongo-ruby-driver is not anymore a dependencie. If you want to try this new driver you can test it on Mongoid 3.

Warning: Mongoid 3 is still not released. If you want to test it, you will need to use the Master branch on Mongoid.

1
gem 'mongoid', :git => 'git://github.com/mongoid/mongoid'

French Translation

Quiet Assets Help You to Have Little Log

| Comments

One week ago, I discover a new gem really helpfull, quiet_assets.

This gem is not a big deal, but it help a lot when you develop a Rails application ( > 3.1 ) with ‘assets_pipeline’. If you have a lot of assets you have already see in your log a lot of information about requests doing on this assets. You can see log like :

1
2
Started GET "/assets/application.js?body=1" for 127.0.0.1 at 2012-02-13 13:24:04 +0400
Served asset /application.js - 304 Not Modified (8ms)

After, when you want see the log really interresting about the request you do, you need up on your log. It’s really annoying. Our log file is really bloat by this logs.

But quiet_assets is here to help you in this mess. After adding this gem in your Gemfile.

1
gem 'quiet_assets', :group => :development

You can discover your log clean and light like before assets_pipeline. No more logs about your assets request. Just your log you really need.

Some gem can really be usefull even if it’s little.

Since rails 3.2.0, there are an option to define the logger of Sprockets. All informations is on this issue 2639. But quiet_assets is allways usefull. When you define your sprocket’s log to false you have allways logs from actionpack. You have less log, but allways too much.

French Translation

EventMachine’s PeriodicTimer the Simply Cron

| Comments

EventMachine is one of the best Ruby libraries. But it’s also the most unknown and unused.

I started to look at Event Machine and where I could use it. The first application I found was the PeriodicTimer.

This feature aims to replace the cronjob.

Let me explain : a cronjob is really a great tool. We can precisely define the time where task is executed. Usually, this task executes precisely at a given time… But when a task is executed too soon, using a cronjob can become awful.

Cron doesn’t have any queue system, therefore there can be an increase of the number of tasks running at same time. Your server might become overloaded and in that case you’d have to restart it. This situation would happen only if your task is created to be executed more times than your frequency of execution.

The solution can be to have a little application like jobq to manage your queue system. But in many cases you don’t really need a queue system, so it would be a little bit like overkill.

The PeriodicTime’s advantage is to execute after a time define precisely. There is no management of time: only the elapse time needs to be managed. The task is sent after X seconds after the end of the previous task and when there are no tasks running anymore. There might be some little variations in the time the task will execute, but it’s not really a problem. The most important is that the task is executed regularly (e.g. when fetching statistics).

Below is [a sample of code]http://gist.github.com/345000) using PeriodicTimer.

<typo:code lang=”ruby”> require ‘eventmachine’ require ‘timeout’ EventMachine.run { EventMachine::PeriodicTimer.new(10) do puts “#{Time.now} : I am 10” sleep 10 end

EventMachine::PeriodicTimer.new(1) do puts Time.now end } </typo:code>

And the output is after 50 second of execution.

<typo:code lang=”plain”> $ ruby em_periodic.rb Fri Mar 26 16:07:39 +0100 2010 Fri Mar 26 16:07:40 +0100 2010 Fri Mar 26 16:07:41 +0100 2010 Fri Mar 26 16:07:42 +0100 2010 Fri Mar 26 16:07:43 +0100 2010 Fri Mar 26 16:07:44 +0100 2010 Fri Mar 26 16:07:45 +0100 2010 Fri Mar 26 16:07:46 +0100 2010 Fri Mar 26 16:07:47 +0100 2010 Fri Mar 26 16:07:48 +0100 2010 : I am 10 Fri Mar 26 16:07:58 +0100 2010 Fri Mar 26 16:07:59 +0100 2010 Fri Mar 26 16:08:00 +0100 2010 Fri Mar 26 16:08:01 +0100 2010 Fri Mar 26 16:08:02 +0100 2010 Fri Mar 26 16:08:03 +0100 2010 Fri Mar 26 16:08:04 +0100 2010 Fri Mar 26 16:08:05 +0100 2010 Fri Mar 26 16:08:06 +0100 2010 Fri Mar 26 16:08:08 +0100 2010 Fri Mar 26 16:08:08 +0100 2010 : I am 10 Fri Mar 26 16:08:18 +0100 2010 Fri Mar 26 16:08:19 +0100 2010 Fri Mar 26 16:08:20 +0100 2010 Fri Mar 26 16:08:21 +0100 2010 Fri Mar 26 16:08:22 +0100 2010 Fri Mar 26 16:08:23 +0100 2010 Fri Mar 26 16:08:25 +0100 2010 Fri Mar 26 16:08:26 +0100 2010 Fri Mar 26 16:08:27 +0100 2010 Fri Mar 26 16:08:28 +0100 2010 Fri Mar 26 16:08:28 +0100 2010 : I am 10 </typo:code>

We can see that the task is executed each second. But the other task executing after 10 seconds, runs and locks the thread. So the first task (executing each second) is executed only after the end of second one. After that, each second the task restarts. and locks again after 10 seconds.

This is really the great strength of PeriodicTimer. We can easily make a suite of tasks who will never execute at the same time. Lately I’m using this for all my scripts fetching data.

About

| Comments

Who Am I?

This is the Cyril Mougel’s blog. I spoke about my developments experiences. That can be some bugs, or new stuff.

What about I speak ?

The blog’s main line is mainly the framework Ruby on Rails, but also all around the Ruby lang.

Voici le blog de Cyril Mougel. Ici, j’y parle de mes expériences de développement. Que ca soit des bugs, rencontrés des nouveautés ou des améliorations apportés.

My experience

After 1 year in CapGemini where I code on J2EE, I am now a Ruby on Rails developer since 2008 in several companies.

Oupsnow 0.5.0 Released

| Comments

That’s it. After only one month to released Oupsnow 0.4.1, I released the 0.5.0 version. This version mark adding features and stability on code base.

New features ?

  • Add filter by closed or not with closed keywords
  • You can edit a milestone now
  • You can define one milestone like current. By define the first one created
  • Add the recover password configuration by your email
  • Add remember solution when you logged
  • Add information about number of ticket in search
  • A logged user can watch a ticket. If user watch ticket he received email when ticket is update
  • A user can change his own email.

Like I made each time, my capistrano file to deploy Oupsnow

set :application, “oupsnow” set :repository, “git://github.com/shingara/oupsnow.git” set :domain, “dev.shingara.fr” # If you aren’t deploying to /u/apps/#{application} on the target # servers (which is the default), you can specify the actual location # via the :deploy_to variable: set :deploy_to, “XXXXXXXXX” # If you aren’t using Subversion to manage your source code, specify # your SCM below: # set :scm, :subversion set :scm, :git set :git_enable_submodules, 1 set :runner, “xxxx” set :user, “xxxx” set :use_sudo, false set :thin_conf, “/etc/thin/#{domain}.yml” set :rails_env, “production” role :app, domain role :web, domain role :db, domain, :primary => true task :update_config, :roles => [:app] do run “ln -s #{shared_path}/config/database.yml #{release_path}/config/database.yml” run “ln -s #{shared_path}/config/email.yml #{release_path}/config/email.yml” run “ln -s #{shared_path}/config/initializers/errornot.rb #{release_path}/config/initializers/errornot.rb” run “cd #{release_path} && echo ‘GOOGLE_ANALYTICS="XXXXXXXX"’ >> config/environment.rb” end namespace :deploy do task :start, :roles => [:app] do run “thin -C #{thin_conf} start” end task :stop, :roles => [:app] do run “thin -C #{thin_conf} stop” end task :restart, :roles => [:app] do run “thin -C #{thin_conf} restart” end end task :update_db do run “cd #{current_path} && RAILS_ENV=#{rails_env} rake db:update” end after “deploy:update_code”, :update_config after “deploy:symlink”, :update_db

Traduction française

Typo 5.4.0 Released

| Comments

That’s it. A new version of Typo is released. I don’t really participate to this version, by lack of time and motivation, but I am allways proud to see a new version.

Each release see a new admin, but each time is allways better than previous. So it’s a good thing.

My french blog is update and use this new version with new default design.

My little gift with this released is my capistrano config file to deploy it. It can be useful

set :application, “typo” set :repository, “git://github.com/fdv/typo.git” set :domain, “blog.shingara.fr” # If you aren’t deploying to /u/apps/#{application} on the target # # servers (which is the default), you can specify the actual location # # via the :deploy_to variable: set :deploy_to, “/var/rails/blog-typo” # # # If you aren’t using Subversion to manage your source code, specify # # your SCM below: set :scm, :git set :runner, “rails” set :user, “rails” set :use_sudo, false set :thin_conf, “/etc/thin/#{domain}.yml” role :app, domain role :web, domain role :db, domain, :primary => true task :update_config, :roles => [:app] do run “cp -Rf #{shared_path}/config/* #{release_path}/config/” run “ln -s #{shared_path}/files #{release_path}/public/files” end task :update_gems, :roles => [:app] do run “cd #{release_path} && RAILS_ENV=production rake gems:install” end after “deploy:update_code”, :update_config after “deploy:update_code”, :update_gems namespace :deploy do task :start, :roles => [:app] do run “thin -C #{thin_conf} start” end task :stop, :roles => [:app] do run “thin -C #{thin_conf} stop” end task :restart, :roles => [:app] do run “thin -C #{thin_conf} restart” end end task :clear_cache, :roles => [:app] do run “cd #{current_path} && RAILS_ENV=production rake sweep_cache” run “cd #{current_path} && RAILS_ENV=production rake tmp:cache:clear” end after “deploy:restart”, :clear_cache after “deploy:start”, :clear_cache

Traduction française