Ruby – Installation and compilation from sources on Debian

If you don’t want to use Ruby from your repositories and you don’t want (or can’t because of some reason) to use RVM, here’s a quick howto download and compile Ruby from sources (all the commands should be executed with sudo or as a super user):

First a small update and some neccessery libs:

sudo su
apt-get update

# Not sure if all of them are required but nothing bad will happen if you just install them

apt-get install build-essential bison openssl libreadline6 libreadline6-dev \
libyaml-dev libxml2-dev libxslt-dev zlib1g zlib1g-dev libssl-dev autoconf \
libc6-dev ncurses-dev libaprutil1-dev libffi-dev libcurl4-openssl-dev libapr1-dev

Then we should go here and download the most recent stable version:

# Still as root
cd ~
wget http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.2.tar.gz

Of course we need to unpack it:

tar -xvf ruby-2.1.2.tar.gz
# go to where it was unpacked
cd ruby-2.1.4/

and now the whole installation process:

./configure  
make  
make test  
make install 

and a small cleanup:

cd ~
rm -rf ruby-2.1.2*

To test it, just:

ruby -v
# output: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]
27
Oct 2014
POSTED BY
POSTED IN Hosting Ruby
DISCUSSION 1 Comment

Adding reentrancy and a on failure fallback for your Sidekiq workers

Few months ago I’ve created a post about reentrancy: Ruby (Rails, Sinatra) background processing – Reentrancy for your workers is a must be!.

In this post, I will present a nice way to implement such feature for your Sidekiq workers.

Simple reentrancy

Normally a Sidekiq worker looks similar to this one:

class ExampleWorker
  include Sidekiq::Worker

  def perform(*args)
    # Background logic here
  end
end

and if something goes wrong, you should see it in your Sidekiq log (or a bugtracker like Errbit). However there is no reentrancy there. You could catch exceptions and handle reentrancy with this code:

class ExampleWorker
  include Sidekiq::Worker

  def perform(*args)
    # Background logic here
  rescue => exception
    # Do something on failure before reraising
    raise exception
  end
end

but it is not too elegant and if you have multiple Sidekiq workers, than probably you will end-up with a lot of code duplication.

Making your reentrancy code more fancy

Instead of handling reentrancy in every single worker, you could just create a base worker class, that would provide such functionality for all the workers that would inherit from the base one:

class BaseWorker
  include Sidekiq::Worker

  def perform(*args)
    # you need to implement the execute method
    # execute method should contain code you want to execute in the background
    execute(*args)
  rescue => exception
    after_failure(*args) if respond_to?(:after_failure)
    raise exception
  end
end

Now, instead of implementing a perform method in every worker, you need to name it (or rename) execute. Perform method will act as a wrapper that will try to execute your worker code and if it fails, will run the after_failure method (if it exists).

Note that the error will be reraised, but now we have a fallback to do for example some database status changes.

class KeywordsWorker < BaseWorker
  def execute(keyword_name)
    KeywordsService.new.remotely(keyword_name)
  end

  # Bring to an expire state if something goes wrong
  def after_failure(keyword_name)
    KeywordsService.new.expire(keyword_name)
  end
end

Of course we might have workers, that won’t require reentrancy at all. Then we just skip the after_failure method and thanks to the respond_to? method, everything will work normally.