Archive for category Ruby

(Do not) Use Rails cache as a distributed lock system

You should strive to design your application in a way that eliminates the need of critical sections as possible.

It is not robust, it adds layers of complexity and is VERY difficult to test.

You can avoid such burdens by using alternative threading constrains such as actors

Having said that there are still cases in a large distributed environment that you need to use Distributed lock manager in order to wrap a critical section of your flow.

It is preferable to use event based distributed locking – can be achieved with Zookeeper (based on Google’s Chubby)

I will show here a very simple locking mechanism based on Rails cache store.

You can set a shared cache between all your rails processes by setting config/environments/#{env}.rb

In the example I use Dalli (excellent memcached client by Mike Perham) but any store that is shared between the machines will work.

You can scroll to the bottom to see the CacheMutex spec and code

Usage is simple:

As you can see, the main disadvantage here is using a sleep-lock instead of event to notify the waiting thread.

CacheMutex source code:

<Edit>

Due to potential race conditions scenario identified by http://en.gravatar.com/cryo28 I switched to provided lock abilities of Redis-Objects https://github.com/nateware/redis-objects#lock

</Edit>

Advertisements

, , , , , ,

2 Comments

DRY your scopes

I encountered a pattern today that I would like to share:

There is no justification to write such a code in ruby (or in any language)
ActiveRecord 3 with ARel does not defer class singleton methods from scopes and in my opinion they are more readable.
We could write the same functionality with:

Now, the path is short to go to:

I like it – do you?

We didn’t only clean the code.
We did much more – every new status in the STATUS list will effortlessly represented with a matching method.

For instance :curator key which had no scope in the original version is now represented with the User.curator method.

DRY is not (just) about aesthetics. DRY is about maintainability and simplicity.

, , ,

6 Comments

Add ruby 1.9.3 on OSX 10.7

OSX adds gcc 4.2 via LLVM
You need to get a non LLVM GCC – can be done easily from here
After installing the new gcc just write in terminal:

rvm install 1.9.3 --with-gcc=clang

 

>>EDIT

Actually you just need


rvm get
rvm install 1.9.3

 

Leave a comment

ActiveRecord default_scope

ActiveRecord, starting at v2.3.2, provides with a convenient way to perform default scoping on a model. This feature must be handled with extra thought before applying. Let’s look at the following class:

class Post < ActiveRecord::Base
default_scope where(:deleted_at => nil)
end

We’re going to use a nice trick here in order to display the actual query rails generates for us:
ActiveRecord::Base.logger = Logger.new(STDOUT)

Now let’s start playing with our Post model a little bit:

:046 >; Post.all
SELECT `posts`.* FROM `posts` WHERE `posts`.`deleted_at` IS NULL
=>; []

As expected, activerecord chained the default scope into our initial query.

:047 >; Post.unscoped
SELECT `posts`.* FROM `posts`
=>; []

The unscoped method rips the model of any chained scopes it has been applied with.

To make things a little bit more interesting I’m adding another scope to the Post model:

class Post
scope :id_is_one, lambda { where(:id =>; 1) }
end

and a post(:id =>; 1, :deleted_at =>; Time.now) to the database.

Back to rails console:

:060 >; Post.id_is_one
SELECT `posts`.* FROM `posts`
WHERE `posts`.`deleted_at` IS NULL AND `posts`.`id` = 1
=>; []

Returns an empty result since our post does have a delete_at field which is different than nil.

:061 >; Post.unscoped.id_is_one
SELECT `posts`.* FROM `posts`
WHERE `posts`.`deleted_at` IS NULL AND `posts`.`id` = 1
=>; []

What just happened here? didn’t we unscope our Post model before querying for a post with id 1? We did, but it looks like rails just ignored it and chained the default_scope again.

More interestingly:

:062 >; Post.unscoped.where(:id =>; 1)
SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 1
=>; [#;]

Replacing the named scope with a simple where clause of ActiveRecord does the job.
So, what do we have so far?
1. Chaining an unscoped with named scopes does not supply with expected results.
2. Chaining unscoped with ActiveRecord query methods does supply with expected results.

This raises the obvious question: Can’t we use named scopes ignoring the default scope of a model? And the answer is: yes, we can! (sounds familiar?!) How? It is very simple:

:063 >; Post.unscoped { Post.id_is_one }
SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 1
=>; [#;]

Passing the desired query inside a block does the job as expected.

To conclude: Dealing with default_scope may look appealing at first, but may also give you some hard times when you want to ignore it. It’s efficiency decreases the more times you find yourself trying to ignore it, so make a serious consideration before going this slippery slope.

, , ,

Leave a comment

Our version of mysql backup using rake

https://gist.github.com/1258918

Leave a comment

Oh my god! where all my digits went?

Case 1: decimals
You are troubled to find out that some of your precision is lost…

1. First place to look is whether you are using the correct number class.

2. next place to look is db column definition
decimal 10,4 for instance, will support 6 digits number with 4 digits after the decimal point.
Don’t get too depressed, you can easily migrate your column to support more digit numbers:


class ExpandDecimals < ActiveRecord::Migration
def self.up
change_column :[table], :[column], :decimal, :precision => 12, :scale => 2
end

def self.down
change_column :[table], :[column], :decimal, :precision => 10, :scale => 4
end
end

Case 2: blob
You are using a table column to store data blob and it’s too short to contain all data?

Migration can be something like:

class ExpandLongtext < ActiveRecord::Migration
def self.up
change_column :[table], :[column], :text, :limit => 16777215
end

def self.down
change_column :[table], :[column], :string, :limit => 255
end
end

 

Migration is very easy and makes your life easy.

Use it.

, ,

Leave a comment

Bootstrap

We are on our bootstrap stage.
Bootstrap means almost everything is done for the first time.
For example-

Setting up your Ruby on Rails development environment on mac OS X 10.6

You will need to get familiar with the terminal. Keep it docked in your programs pane. You are going to use it a lot.

General note: in some installations you are required to change your .profile or your .bash_profile. I prefer using only .bash_profile and apply all the changes in the same file.

Memorize the holy trinity 🙂

$ ./configure
$ make
$ sudo make instal

Now we can get to work…

  • Install X-code, from your OS X installation disk. It has gcc compiler and some other tools that will help you during your installations.
  • Install macports, http://www.macports.org/install.php. The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing,
    and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system.
  • Install wget, a tool that helps fetching packages and files from internet locations
$ port install wget
$ port install readline
$ rvm install 1.8.7
$ rvm install 1.9.2
$ rvm 1.9.2 --default
$ gem install bundler
  • Install rails freamework
$ gem install rails
  • Install ruby debug  1.9 gem which enables to debug ruby from rails console.
$ gem install ruby-debug19

OK ready to go!

2 Comments