Shiny happy people coding

Coding with smile

Errbit 0.2.0 Released

| Comments

After 3 month of developpement a lot of fix bug and improvement with do by 16 contributors. I am proud to release this second version of Errbit where I am involved totally.

This version 0.2.0 is the last supporting ruby 1.8.7. This ruby version become old and a lot of dependencies used by Errbit stop the maintain of this version too. So it’s time to move forward and stop maintain this old version. The next version support only ruby 1.9.3 and higher.

You can download this version directly on github :

https://github.com/errbit/errbit/releases/tag/v0.2.0

A new branch ( 0-2-stable ) is now create to push some important bug fix on this version.

The complete changelog is :

Improvements

Bug Fixes

  • #343 Fix the ical generation. (@shingara)
  • #503 Fix issue on where the service_url choose never use. (@nfedyashev)
  • #506 Fix issue on bitbucket issue tracker creation failed. (@Gonzih)
  • #514 Add CDATA in xml return by Javascript. (@mildavw)
  • #517 Javascript escape path from javascript Notifier. (@roryf)
  • [#518][] Fix issue when you try launch task errbit:db:update_update_problem_attrs. (@shingara)
  • #526 Fix issue of pagination after search. (@shingara)
  • #528 Fix issue of action after search. (@shingara)

Next Step

The next step on this project is the usage of Mongoid 3.0. A complete list of issue planned to this next version is define on his milestone

Errbit 0.1.0

| Comments

Errbit was release for the first time in August 24 2010 by Jared Pace.

Errbit is not dead. It’s actually maintained and used for the past 3 years and now, I’m proud to announce the release of errbit. There was not real release from the start, but I think it’s needed. I do this first one with 0.1.0. Errbit do a lot of thing but can do better. I hope try to do this challenge with the Errbit Team and try to release more often this application.

A Changelog is now available to see what change in your favorite error catcher application. I have not list all thing errbit can do, but I list some new improvement in last couple of month. You can find it on github

If you want download this version you can do by github : https://github.com/errbit/errbit/archive/v0.1.0.zip

0.1.0 – 2013-05-29

Improvements

  • #474 Improve message when access denied. (@chadcf)
  • #468 Launch a repairDatabase in MongoDB database after launching the clear_resolved task. (@shingara)
  • Update gem of Mongoid to 2.7.1
  • Update gem of Mongo to 1.8.5
  • #457 Add task information about db:seed in Readme. (@mildavw)
  • Add support of Ruby 2.0.0
  • #475 Return a HTTP 422 status code when you try push notice with bad api key. (@shingara)
  • Return a 400 http status when you try put a notice without args. (@shingara)
  • #486 Add confirms box when you do massive action. (@manuelmeurer)
  • #487 Add specific template to redmine notification with less useless data. (@tvdeyen)

Bug fixes

  • #469 Fix issue about the documentation of new heroku addons usage. (@adamjt)
  • #455 Avoid raising exception if you comment an exception and no other user are define to received this comment. (@alvarobp)
  • #453 Fix ruby 2.0.0 incompatibilities with gem (@SamSaffron)
  • #476 Fix javascript notifier issue with IE8 (@sdepold)
  • #466 Fix not see problem if octokit gem not define (@tamaloa)
  • #460 Fix issue when you try see user with gravatar activate but no email define to this user (@ivanyv)
  • #478 Fix issue about calculation of statisque of problem after merge (@shingara)

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.