Category Archives: tutorial

Ruby to C, a couple snippets

As you might already know, the Ruby interpreter you’re (probably) using (the one at know as MRI, for Matz Ruby Interpreter, is written in C. The VM is entirely written in C and most of the standard libraries too. So it seems that the way to make code run faster is really to dive into C.

Now I hear you yell with your ears all red, eyes full of blood and a big vein pumping on your forehead: But it will be unmaintainable!

If everything seems under control, you’re not going fast enough

– Mario Andretti

The hard part is that the C API of MRI lacks documentation. You either have to search through the mailinglist, look at other people’s code or try to guess from Ruby’s code. I recently ported a bit of code from Ruby to C and here are a couple of Ruby to C mapping that might help you.

If you’ve never written or looked at a Ruby extension before, I suggestion reading Peter Cooper excellent and very simple tutorial on how to set things up.

Objects are VALUEs

my_var = nil
this_is_true = true
some_fixnum = 1

VALUE my_var = Qnil;
VALUE this_is_true = Qtrue;
VALUE some_fixnum = INT2FIX(1);


string = "hi"

VALUE string = rb_str_new2("hi");

/* Ruby string to C string */
char *s = RSTRING_PTR(str);
int len = RSTRING_LEN(str);

Object to C struct

In C you’ll probably want to store your data in a struct. Ruby provide some things to wrap a struct inside a Ruby object. Also, since Ruby is not aware of the stuff created in the C world we have to be pretty explicit about everything.

module MyModule
  class MyClass
    def close
      @closed = true

In C

/* This is called by Ruby GC when the object is freed
 * so free all resources used here. We hook it up
 * in the Data_Wrap_Struct call down there.  */
void my_obj_free(my_struct_t *s)

/* Called by Ruby then and instance of your class is created
 * hooked by rb_define_alloc_func. */
VALUE my_obj_alloc(VALUE klass)
  my_struct_t *s = ALLOC_N(my_struct_t, 1);
  /* This stores the struct inside the Ruby object, so you
   * can get the struct back on each method call. */
  return Data_Wrap_Struct(klass, NULL, my_obj_free, s);

/* The actual MyClass#close method, first argument is the
 * instance object. It's hook into our class by the rb_define_method
 * call in Init_ */
VALUE my_obj_close(VALUE self)
  my_struct_t *s;
  /* This is where we get the struct back from the Ruby object */
  Data_Get_Struct(self, my_struct_t, s);
  s->closed = 1;

/* Init_* is magically called by Ruby to bootstrap your extension,
 * it's like a main function if you will. */
void Init_name_of_your_extension()
  VALUE mMyModule = rb_define_module("MyModule");
  VALUE cMyClass = rb_define_class_under(mMyModule, "MyClass", rb_cObject);  

  rb_define_alloc_func(cMyClass, my_obj_alloc);
  rb_define_method(cMyClass, "close", my_obj_close, 0);

Calling methods


result = begin

rb_funcall(obj, rb_intern("method_name"), 0);
/* if an error is raised, result will be set to Qundef */
VALUE result = rb_funcall_rescue(obj, rb_intern("method_name"), 1, arg);


my_ary.each do |i|
  puts i

VALUE i_each(VALUE elem, VALUE *obj)
  /* elem is the yielded object and obj is a pointer to obj down there v */
  printf("%d\n", FIX2INT(elem));
  return Qnil;
rb_iterate(rb_each, my_ary, i_each, (VALUE) obj);

Error handling

raise ArgumentError, "..."

rb_raise(rb_eArgError, "...");
/* To raise an error corresponding to the one in errno */

Garbage Collection

When creating Ruby objects in the C world, Ruby is not aware of the scope of each, it’s impossible to track when a variable is used and when it’s not, so it’s impossible for the garbage collector to know when do leave or sweep objects. If you create a long live object, that will persist for several method calls you have to tell Ruby’s garbage collector when it’s in use and when you’re finished with it. If you don’t, Ruby GC will free your variable in the worst possible time, ending up with unthinkable tragedies around the world, leaving you homeless and poor for all eternity.

VALUE var = rb_str_new2("prout");

/* Tell Ruby GC this object is in use */
/* when you're finished you can unregister it and let the GC free it */

Note that you don’t need to do this if you only use the variable in one method since the control is not given back to Ruby during the method call. Also if the variable is still referenced in the Ruby world it’s already registered.

More, more, more!

This is far from a complete guide to MRI, you’ll need to dig the Ruby doxygen doc if you need more info.

Now lets port Rails to C!



Filed under ruby, tips, tutorial

The Flexible Thin Anorexic Gymnast that Democratized Deployment

ImageThin is fast, I don’t think I need to prove that again. But what I’d like to showcase now is Thin extensibility. Most of it is due to Thin being based on Rack. It’s also why lots of framework are supporting Thin already.

Can Thin replace all images with LOLCAT pics on my site when it’s my birthday of a leap year, plz, plz, plz? Cause it should!

Yeah, you’re not the first one to ask. file

require 'open-uri'
require 'hpricot'

class LolCater
  def initialize(app)
    @app = app
  def call(env)
    status, headers, body =
    if iz_ma_burdae? && leap_year?
      doc = Hpricot(body)'img').set('src', lolcat_pic_url)
      body = doc.to_html
    [status, headers, body]
    def iz_ma_burdae? == 11 && == 7
    def leap_year?
    def lolcat_pic_url
      doc = Hpricot(open(''))
      pic = (doc/'div.snap_preview img').first.attributes['src']

use LolCater
run => '/path/to/my/app')

That’s called a Rack middleware. It must have a call method and receive a Rack app as the first argument of new. You then tell Thin to use this middleware when running your Rails application. Save the file as .ru is for Rackup config file.

You can now launch your application with the thin script:

thin start --rackup

Wai-wai-wait that means I can built my own framework in like 30 LOC and use all of Thin goodness?

Right! You can start a cluster of your lolcat image replacer app like you would for a Rails app, but specify the --rackup option, which tell Thin to load your application from this file instead to go with the default Rails adapter.

thin start --rackup --servers 3

In fact, here’s a lil’ framework I built in 35 LOC:

# Start w/ thin start -r invisible.rb
require 'tenjin'

module ::Invisible
  class Adapter
    def initialize
      @template =>'.rbhtml', :layout=>'../layout.rbhtml', :path=>'home')
      @file ='public')
    def call(env)
      path = env['PATH_INFO']
      if path.include?('.')
        _, controller, action = env['PATH_INFO'].split('/')
        Invisible.const_get("#{(controller || 'home').capitalize}Controller").new(@template, env).call(action || 'index')
  class Controller
    def initialize(template, env)
      @template, @status, @env, @headers = template, 200, env, {'Content-Type' => 'text/html'}
    def call(action)
      render(action) unless @body
      [@status, @headers.merge('Content-Length'=>@body.size.to_s), [@body]]
      def render(action=nil)
        @body = @template.render(action.to_sym, instance_variables.inject({}) {|h,v| h[v[1..-1]] = instance_variable_get(v); h})

require 'app/controllers'

Full code on my github repo:

And you know I can’t help myself but benchmark it:
merb-core: 1865.19 req/sec
invisible: 2428.17 req/sec

(Disclamer: it’s just for fun, don’t use that framework ever or I will come in your house when you sleep and steel all your left foot socks).

Democratizing deployment

I don’t know if you get what this means? It means, deploying a Rails or Merb, Ramaze, etc, app is just a matter of writing a simple Rack config file and playing w/ the –rackup option. It’s all the same script and tools now!

For example, there’s a Ramaze Rack config file in example/, so to deploy your Ramaze application you would.

thin start --servers 3 --rackup

Or create a config file and install it as a runlevel script:

thin config --rackup -C myapp.yml
edit myapp.yml
sudo thin install # Installs the runlevel script
mv myapp.yml /etc/thin/myapp.yml

Or if you prefer to monitor your clusters with God, check out the sample God config file that is a drop-in replacement for Thin’s runlevel script.

Happy hacking & deploying!


Filed under ruby, thin, tutorial

Moron no more : I can Git !

Since Linus said we’re all morons ’cause we use Subversion and the like, lots of people started to migrate to his new faster, better, stronger, cooler and geekier revision control system Git.


Installation for Subversion morons like me

Get the latest stable source from

tar xzf git-
cd git-
make prefix=/usr/local all
sudo make prefix=/usr/local install

Create your own little repo

mkdir moron
cd moron
git init

Congrats, you just created your first Git repo!

Most common commands looks like Subversion ones. add, rm, mv and commit. But you gotta remember that there’s no such thing as a working copy in Git. It’s a distributed revision control system. Which means that your local copy is a repository. In fact, with Git you do not checkout (in the Subversion sense) a copy of the repo, you clone it. That’s why Git is so much faster. Most of the commands: history browsing, local commits, reverting, etc, are done locally, without talking to the server. Check the official guide for Subversion morons.

Try adding a file:

echo "I'm no longer a moron Linus" > moron-no-more.txt
git commit -a

The -a ensures that all new files are added, you can do this manually with the git add command.
You then commit you change as you would do in Subversion, with the difference that it’s all done locally:

git commit -m "Take that Linus!"

All is not lost for us poor Subversion mortals

The cool thing about Git is it has builtin support for playing nicely with Subversion. Which ease the migration and can even let you use Git side by side with Subversion. So you can import a Subversion branch like this:

git svn init http://repo/url/trunk
git svn fetch

You Git repo now has all the revisions of you Subversion branch. Try running git log.
You can even send you changes back to Subversion:

git svn dcommit

Create your central repo

mkdir mah-repow.git
cd mah-repow.git
git --bare init-db
git-repo-config remotes.origin.url; # notice trailing slash!

Upload that directory to your public server. Like Subversion, Git supports various ways of serving a remote repo, I chose WebDAV because it’s the simpler one on DreamHost.

To send your changes to the server with Git you push your changes to the server and pull changes from others. With our previous examples, to push a series of commits to the server you’d do:

git repo-config remotes.origin.url; # once to setup the default server url
git push

Happy Gitting!


Filed under tips, tutorial

Getting TextMate ready for Rails 2.0

After updating a couple of existing Rails app to 2.0, I found out some of TextMate sugar was out of date. Here’s 2 things I did to put the hot and sweet sugar back into TextMate.

Update the bundle

TextMate bundles are under heavy development all the time, get the latest version from their repo:

svn export

Then double-click on the downloaded Ruby on Rails.tmbundle.

Fix the test commands

I’m a heavy user of Run (command+R), Run Focused Unit Test (shift+command+R) and the Rails menu (shift+ctrl+\) but that do not work with Rails 2 because of a conflict with the builder module.

Rob Sanheim explain how to solve this very easily, just rename the Builder.rb in the Rails bundle.

Hope this helps!


Filed under rails, tips, tutorial

Rack, the frameworks framework

RackWith all the Ruby frameworks popping up, we’re starting to see some similarities. All of them provide something new or unique but one part of their code is always the same. The part that plugs it into a web server. Ultimately, all web servers have to support all frameworks and vice-versa. That is a lot of duplicated code! That makes me yell, running in circles, waving my arms: not DRY, not DRY, not DRY!


Rack (not the iRack) by Christian Neukirchen, solves this problem.

From Rack website:

Rack provides an minimal interface between webservers supporting Ruby and Ruby frameworks.

Rack looks like this in my head:

Handlers on the left (web servers) serve requests to Adapters (frameworks) on the right.
(Don’t ask me what the rabbit is doing there, must be important)

Run Forest!

But Rack can do a lot more then plug Ruby framework into webservers. It is a framework in itself.

When you install it:

sudo gem install rack

You get the rackup command. Which lets you start your app on any supported web server.

require 'rack/lobster'



Start your app: rackup -p3000 then browse to http://localhost:3000, oh the cute lobster!

To run it on other web servers (mongrel by default) play with the -s option.

It’s a framework I said

The Handler API is only 1 method: call(env). Which allows you to use proc as application.

app = proc do |env|
  [200, { 'Content-Type' => 'text/html' }, 'no pepper plz!']
run app


That will return a 200 OK response with the text/html content type and the body no pepper plz!. env contains the request parameters, so you could play with the QUERY_STRING or wrap it inside a Rack::Request and get a request param value with request.params['name'].


You can use middlewares to filter the process. For example, you can add logging and detailed exception support with those 2 lines in your file:

use Rack::CommonLogger, STDOUT
use Rack::ShowExceptions

You can also validate your application, the requests and responses according to the Rack spec automatically using the Rack::Lint middleware.

(There’s also a Reloader, Static, Cascade, File and much more middlewares, check the doc)

You can also have fun with urls:

map '/files' do

map '/lobster' do

Check it out!

Rack is the best example of a very well design Ruby library. The code is simple, well separated and yet, easily extensible, it’s beautiful! I encourage you to check out the code but mostly to use it if you’re building any Ruby web framework (like we need other one!).


Filed under rails, ruby, tutorial

Moving to Rails 2.0

I know … it’s like exercising, you know you’ll be better afterwards but you don’t feel like going trough the pain right now. Updating a framework can be a pain, here’s a short list summarizing what I had to do to migrate RefactorMyCode from Rails 1.2.3 to 2.0 (Preview). I hope this makes it easier for you!

0. Pistonize it!

Instead of using the classic way of freezing Rails in you app tree (rake rails:freeze:edge TAG=rel_2-0-0_PR), I’d recommend using Piston:

piston import vendor/rails

This way, you’ll be able to make changes to Rails code and keep them while updating your copy!

1. Update your stuff

Update configs, scripts and javascripts:

rake rails:update

2. Move your session config to environment.rb

Add this in your environment.rb and remove the session ... line in application.rb:

# Your secret key for verifying cookie session data integrity.
# If you change this key, all old sessions will become invalid!
config.action_controller.session = {
  :session_key => '_app_name_session_id',
  :secret      => 'your secret key'

To compute your secret key:

require 'digest/md5'
puts [now =, now.usec, rand(0), $$, 'you_app_name'].inject( { |md5, e| md5 << e.to_s }

3. Split environment.rb

Rails now recommend putting your specific config code in config/initializers. Move everything outside do |config| ... end into separate files. For starter, create config/initializers/inflections.rb and config/initializers/mime_types.rb and move what was in environment.rb. Split as much as you can in files with descriptive names.

4. Singleton resource, plural controller name

If you were using singleton resource: map.resouce :account, you’ll need to pluralize your controller name. In this case AccountsController. Not sure if it makes more sense, but follows the convention to pluralize controller names I guess…

5. Rename your views

Rails 2.0 brings a beautiful view naming convention:

[name].[content type].[template engine]

eg.: show.html.erb or create.js.rjs

Renaming manually can be pretty painful. Jamie created a Rake task for this.

6. Fix the plugins

Expects some plugins to break. In my case, asset_packager broke, but fixing it was simple: synching method signature for compute_public_path.

I’d recommend checking plugins compatibility before doing the jump. Read the doc. Or if you’re feeling adventurous, give it a try.

7. Add Request Forgery Protection

Cross-site request forgery can be hard to protect from. Not with Rails 2.0.

Add this to your application.rb

# See ActionController::RequestForgeryProtection for details
# If you're using the Cookie Session Store you can leave out the :secret
protect_from_forgery :secret => 'same_as_the_session_one'

And this to your config/environments/test.rb:

# Disable request forgery protection in test environment
config.action_controller.allow_forgery_protection    = false

Good luck!

Update: Paolo sent me an article he wrote for upgrading routes to 2.0 w/ a script, nice!


Filed under rails, tips, tutorial

3 simple tips to make your Rails app 100 times faster

After the initial meltdown of the RefactorMyCode server I had to find a solution to put it back online fast!

Here are 3 things I did that helped me put the app back online and made it amazingly fast serving more then 50 000 page load in a day, even if it was hosted on a shared hosting plan on DreamHost. Not the fastest provider but the cheapest and most supported for sure. I since then switched to SliceHost on an account graciously offered by StandoutJobs (that’s right, for my personal project, how cool is that?).

I know lots of people have wrote guides to make your web app faster, but I tried, with this one, to focus on the simplest, yet most effective, things you can do to dramatically speed up your app without loosing any of Rails and Ruby tasty sugar. I think even people with little experience with Rails and web deployment can follow this guide with no problem.

1. Pack that asset up

First tip is the easiest to put in place. Downloading your 3 stylesheets and 6 javascript files slows down page loading because the web browser has to open a new connection for each one. Plus some browser limits the number of files that can be downloaded from a same host at the same time.
The solution is to reduce the number of external resources your page depend on by merging all of them into one file. AssetPackager is great for doing this in your Rails app, plus it minifies your javascript for free, check out RefactorMyCode stylesheet and javascript file. All that by changing one line in your view layout!

Now to make it load even faster you want to move all your static files to another host (see why here). For example on RefactorMyCode, images, the stylesheet and javascript are loaded from
With Rails, this is stupidly easy. In your config/environments/production.rb, set config.action_controller.asset_host to your assets host. Now all the image_tag, javascript_include_tag, etc will point to this host. On your DNS server, all you need to do is setup an alias (A record) pointing to the same IP as the main domain.

2. Remove unused stuff

Something to keep in mind while trying to improve performance is that, for each request, everything will be loaded, checked and executed. Authentication, session, database queries. Do you really need all this stuff on every request?

You can turn off session on specific actions with:

session :off, :only => :index

This boost performance like crazy. So it’s a great alternative to caching if you really need to go to the database but not to login the current user.

If you’re using RestfulAuthentication or ActsAsAuthenticated plugin, you can turn off loading the user form the cookie with:

skip_filter :login_from_cookie

which will save you one query.

Use fragment caching for partial views with heavy data from the db and skip your queries on the controller side with:

@users = User.find('all) unless read_fragment('unique_cache_key')

Also with queries, make sure you know how to use the :include option for eager loading of associations.

Post.find(:all, :include => :user)

will cut the number of queries in half.

3. Cache the whole page

This last tip is by far the most effective. Cache everything you can to reduce queries to the database, or even, requests to the dispatcher.
The best solution is caching the whole page into and HTML file so the web server serves the static file rather then sending the request to the dispatcher. Most web server are serving static files faster then Lance Armstrong on drugs. And can serve lots and lots of them, letting your dispatchers breath a bit between requests. Rails Envy as a great guide on how to set this up.

Now the hard part is caching the layout. To cache a full page, the page needs to be the same for every users, logged in or not. To do that, you have to remove all those <%= ... if logged_in? %> and show everything, at least in the HTML. You still can use javascript to show and hide links that are for logged in users. For example here’s a code sample from RefactorMyCode:

var CurrentUser = {
  loggedIn: false,
  author: false,
  admin: false,

  init: function() {
    this.loggedIn = Cookie.get('token') != null;
    this.admin    = Cookie.get('admin') != null;

var Application = {
  init: function() {

  onBodyLoaded: function() {
    if (CurrentUser.loggedIn) {
    if (CurrentUser.admin) {

Another thing you wont be able to use anymore on your layout is <%= flash[:notice] %>. The flash changes on each request, not cacheable. The solution again is to transfert everything to the client with cookies and javascript. Cacheable Flash is a nice Rails plugin to do just this. Cool thing is, you don’t need to change anything on your controller. Just replace your previous flash ERB block with something like this:

<div id="error_div_id" class="flash flash_error"></div>
<div id="notice_div_id" class="flash flash_notice"></div>
<script type="text/javascript">
  Flash.writeDataTo('error', $('error_div_id'));
  Flash.writeDataTo('notice', $('notice_div_id'));

I hope this was helpful to you. Let me know if you got more tips or questions on how I’ve setup my server.


Filed under rails, tips, tutorial