1.0 / 0.0
=> Infinity
0.0 / 0.0
=> NaN

Because Ruby follows IEEE 754:

- Invalid operation: mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.
- Division by zero: an operation on finite operands gives an exact infinite result, e.g., 1/0 or log(0). By default, returns ±infinity.

Links

• IEEE 754

Mixins are another syntax for inheritance

TL;TD And they are used for code sharing, thus mixins are evil. Indeed, in Ruby included module becomes an implicit superclass with all perks of inheritance. And this can be abused.

1) super and method overriding

module One
  def func
    puts "in module"
  end  
end  

class Two
  include One
  def func
    puts "in class"
    super
  end  
end

# take a look at object hierarchy
Two.ancestors
[
    [0] Two < Object,
    [1] One,                  # implicit superclass
    [2] Object < BasicObject,
    [3] PP::ObjectMixin,
    [4] Kernel,
    [5] BasicObject
]

# call a function
Two.new.func
in class
in module    # <- yes, you can call `super`

You can also include many modules with the same methods:

module One
  def func
    puts "in one"
  end  
end  

module Two
  def func
    puts "in two"
  end  
end

class Three
  include One
  include Two
  def func
    puts "in class"
    super
  end
end

Three.ancestors
[
    [0] Three < Object,
    [1] Two,
    [2] One,
    [3] Object < BasicObject,
    [4] PP::ObjectMixin,
    [5] Kernel,
    [6] BasicObject
]

Three.new.func #=> what do you expect here?

The last example can be an interview question. It requires knowledge of how modules and inheritance actually work.

2) they have access to instance variables of a class

Being just a superclass, included module can access private instance variables of a child:

module One
  def func
    puts @var
  end  
end  

class Two
  include One
  def initialize
    @var = 'hello'
  end  
end  

Two.new.func #=> hello

Same is true for private methods.

Evil begins

Now a developer can abuse mixins and make his code an unreadable mess. With good intentions, of course. For example, why not include 10 modules in 1 class? Now I have a “small” class and everything else spread across 10 entangled modules. Did I mention that you can call methods of another module from withing a module? Multiply this possibility by method overriding and instance variables and here comes a mess.

Is this really bad? Yes! You should keep you classes and method small, but when you split a big class into modules you make things worse. Now you have not only a big class, but a big class scattered across multiple files making it harder to read.

Conclusion

Mixins are just cheaty syntax for inheritance intended for code sharing. Avoid them if you can. Prefer composition instead. This is true for any kind of inheritance, and especially for mixins.

In my opinion, the only legit case for mixins is when your module has no dependency on a class where it’s included. But even if it’s true for now doesn’t mean other developers cannot add dependency later. There is no barrier.

Links

• The Pragmatic Programmer’s Guide - Modules

Why?

Ruby is slow, right? Most of the time we don’t care, but sometimes we do. And when we do, there are not so many options: C, C++, microservices/rpc/jruby, … . C is good enough to shot yourself in the foot. C++, well, just C++. Other options are to comprehensive for a simple task, like CPU intensive algorithm. You can probably use Go, but it has its own runtime with garbage collector which adds more overhead.

Rust is another option because of:

• safety
• speed
• no runtime

There are couple of challenges with Ruby-Rust integration (actually, for Ruby-whatever integration). This post is about them.

Passing data between Ruby and Rust

This is relatively easy when you are passing simple integers, but if you need to pass complex objects there is a lot of headache. You can avoid it by using JSON and passing it as string. If you need to call a function in Rust and get result of its CPU intensive calculation, then it’s OK to have JSON overhead.

One gotcha is that you have to deallocate memory allocated for char * inside Rust after it has been returned to Ruby. That’s why we have rust_free function in Rust, which is a wrapper for libc’s free:

require 'rustygem/version'
require 'fiddle'
require 'json'

module Rustygem
  @lib = Fiddle.dlopen("#{File.dirname(__FILE__)}/../rust/target/release/librustygem.so")
  @rust_perform = Fiddle::Function.new(@lib['rust_perform'], [Fiddle::TYPE_VOIDP], Fiddle::TYPE_VOIDP)
  @rust_free = Fiddle::Function.new(@lib['rust_free'], [Fiddle::TYPE_VOIDP], Fiddle::TYPE_VOID)

  def self.perform(arg)
    ptr = @rust_perform.call(arg.to_json) # do the actual work
    result = ptr.to_s
    @rust_free.call(ptr) # char* was allocated in Rust, so don't forget to free it
    JSON.parse(result)
  end
end

#[no_mangle]
pub extern "C" fn rust_free(c_ptr: *mut libc::c_void) {
    unsafe {
        libc::free(c_ptr);
    }
}

Check out rustygem for more details.

Building dynamic library when installing the gem

Ruby gems have builtin mechanism for building native extensions in C. But what about Rust? Actually, we don’t need any external tools to build Rust library because in Rust we have Cargo which is very similar to bundler. So, the only thing we need to do is call cargo build inside Rust project. But how to do this when installing the gem? Turns out this is very simple. Just put Makefile along with empty extconf.rb and add extconf.rb to gemspec.

# rust/Makefile:
all:
	cargo build --release

clean:
	rm -rf target

install: ;

# gemspec
spec.extensions = Dir['rust/extconf.rb']

Optionally, you can put some checks into extconf.rb:

# rust/extconf.rb
raise 'You have to install Rust with Cargo (https://www.rust-lang.org/)' if !system('cargo --version') || !system('rustc --version')

Conclusion

There is an alternative to C. And it’s not so hard to use Rust in Ruby project.

This post illustrates very basic approach to integration Rust with Ruby. There is Helix project which is much more comprehensive. Check it out if you want less boilerplate and more nice API.

Links

• rustygem - an example gem written in Rust
• Bending the Curve: Writing Safe & Fast Native Gems With Rust
• Helix project
• SO: How can I build a Rust library when installing a gem?
• Turbo Rails with Rust by Godfrey Chan
• Opinionated tool for creating and managing Rubygem projects using Ruby 2.3 and beyond. Supports Rusty gems

But there are couple issues with it:

1. doesn’t support rails 5 yet;
2. creates additional tables to store translated data;
3. requires you to reference models in migration, which is anti-pattern.

It’s somewhat OK to live with 2 and 3, but not with 1 if you are on rails 5.

That’s why I’ve created another solution and extracted it into a gem.

The idea is very simple: save all translation data in one field. It’s possible to do so even with serializable attribute, but much better is to use jsonb type in PostgreSQL 9.4. It’s indexed and you can query it just like any data.

ActiveRecord supports jsonb since 4.2 so you can work with those fields just like with hashes.

So, let’s save translatable text data under a key, representing locale:

{ "en": "hello", "ru": "привет", "it": "ciao" }

Now, with a very little abstraction you can do this:

I18n.locale = :en
post = Post.create(title: 'hello')
post.title #=> hello
I18n.locale = :ru
post.update(title: 'привет')
post.title #=> привет

Also, it’s very easy to manage multiple languages in a single form if you treat them as nested attributes:

class Post < ActiveRecord::Base
  def title_translateable_attributes=(arg)
    self[:title] = arg.each_with_object({}) do |i, obj|
      hash = i.second
      next if hash[:_destroy]
      obj[hash[:locale]] = hash[:data]
    end
  end
end

Together with nested_form_fields you can add/delete translations dynamically in a single form.

Conclusion

This very simple idea illustrates yet another use case for jsonb type. Don’t be afraid of it.

However, it requires you to write raw SQL queries, like this:

Post.where("title->>'en' = ?", 'hello'))
# more examples in gem's readme

But, imo this is better than joins with additional tables.

Links

• translateable gem
• Using PostgreSQL and jsonb with Ruby on Rails
• Querying JSON in Postgres
• Query postgres jsonb by value regardless of keys

eval

The most basic and well-known in other dynamic languages method. Receives a string and run it as a Ruby code.

txt = 'hello'
eval "puts '#{txt}'"  #=> hello

Optionally you can pass a context which eval operates on with binding.

def get_binding
  binding
end

class Klass
  def initialize
    @var = 42
  end

  def self.class_func
    11
  end

  def get_binding
    binding
  end
end

puts self                                 #=> main
puts eval('self', get_binding)            #=> main
puts eval('self', Klass.new.get_binding)  #=> #<Klass:0x007f77d1161728>
puts eval('@var', Klass.new.get_binding)  #=> 42

Binding allows you to capture current execution context. For example, it’s used by closures.

instance_eval

Allows you to operate on object with self set to this object. It also can accept block instead of string to evaluate it. Somewhat similar to eval with binding.

# self is also passed as a block argument
Klass.new.instance_eval do |obj|
  puts @var             #=> 42
  puts self             #=> #<Klass:0x007f0c71f4d7e0>
  puts obj == self      #=> true
end

# Class itself in an instance of class `Class`
Klass.instance_eval do |obj|
  puts class_func       #=> 11
  puts self             #=> Klass
  puts obj == self      #=> true
end

# works with string too
Klass.new.instance_eval "puts @var" #=> 42

instance_exec

Similar to instance_eval, but also allows you to pass an argument to a block.

# instance_exec can pass an argument(s)
Klass.new.instance_exec(1, 2) do |obj1, obj2|
  puts @var             #=> 42
  puts self             #=> #<Klass:0x007f1136e57060>
  puts obj1             #=> 1
  puts obj2             #=> 2
end

# for example, you can define methods dynamically with instance_exec
instance = Klass.new
instance.instance_exec(3) do |obj|
  @_obj = obj
  def new_func
    @_obj
  end
end
puts instance.new_func  #=> 3 (or nil if no arguments passed to instance_exec)

# works only with block
Klass.new.instance_exec "puts 'hello'" #=> no block given (LocalJumpError)

class_eval

Similar to instance_eval, but operates on object itself. Available only on Module (Class).

Klass.class_eval do |obj|
  puts obj                  #=> Klass
  def another_func
    14
  end
end
puts Klass.new.another_func #=> 14

class_exec

Like instance_exec but for class_eval. Allows you to pass an argument to a block.

Klass.class_exec(1) do |obj|
  puts obj                  #=> 1 (or nil if no arguments passed to class_exec)
  def yet_another_func
    18
  end
end
puts Klass.new.yet_another_func #=> 18

# because class_{exec,eval} opens `Klass` itlelf any @variables are class instance variables (like instance_exec on a class)
# but any methods defined are instance methods
Klass.class_exec(1) do |obj|
  @_obj = obj
  puts @_obj                    #=> 1
  def yet_another_func1
    @_obj
  end
end
puts Klass.new.yet_another_func1 #=> nil
puts Klass.instance_variables    #=> @_obj

module_eval

Same as class_eval.

module_exec

Same as class_exec.

Conclusion

eval is the most basic and well-known method. You can evaluate any Ruby code with it. But if you’re using rubocop it will yell at eval as a security issue. True, if you run eval against user-provided string it can be exploited like SQL-injection.

Other methods are a little bit safer since they accept block, not a string (don’t use strings with {instance,class,module}_eval).

obj.instance_{eval,exec} operate on singleton class of an obj.

obj.{class,module}_{exec,eval} operate on obj itself and available only on Module (Class).

{instance,module,class}_exec allows you to pass an argument to eval’d block while {instance,module,class}_eval don’t.

{instance,module,class}_eval can also accept string (just like regular eval).

Links

• Eval, module_eval, and instance_eval
• Kernel#eval at ruby-doc.org
• BasicObject#instance_eval
• BasicObject#instance_exec
• Module#module_eval
• Module#module_exec
• RubyMonk: Class eval
• Module#class_eval
• Module#class_exec
• Stanford CS 142: Understanding class_eval and instance_eval
• Understanding class_eval, module_eval and instance_eval
• StackOverflow: What is the difference between class_eval, class_exec, module_eval and module_exec?
• RubyMonk: Eval

There is nice awesome_print gem which helps a lot with coloring and formatting output. It’s much nicer then pp and simple puts. But I like to do one little thing to make it even better:

def sap msg
  ap "*** #{Time.now} ***", color: {string: :green}
  ap msg.class if msg.respond_to?(:class)
  src = caller.first.gsub(Rails.root.to_s + '/', '')
  ap src, color: {string: :purpleish}
  ap msg
  ap '*** END ***', color: {string: :green}
end

As you can see, now every output will be wrapped inside *** along with file/line and type of printed value. It helps a lot.

Started GET "/news/8" for 127.0.0.1 at 2016-01-31 15:21:00 +0200
Processing by NewsItemsController#show as HTML
  Parameters: {"id"=>"8"}
  User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1  ORDER BY "users"."id" ASC LIMIT 1  [["id", 1]]
  NewsItem Load (0.3ms)  SELECT  "news_items".* FROM "news_items" WHERE "news_items"."id" = $1 LIMIT 1  [["id", 8]]
"*** 2016-01-31 15:21:00 +0200 ***"
"app/controllers/news_items_controller.rb:16:in `show'"
#<NewsItem:0x007f4b63f3c0e0> {
            :id => 8,
          :body => "123234234",
    :created_at => Sun, 08 Nov 2015 16:24:49 UTC +00:00,
    :updated_at => Sun, 08 Nov 2015 16:24:49 UTC +00:00,
         :title => "4567"
}
"*** END ***"
  Rendered news_items/_single.html.haml (0.6ms)
  Rendered news_items/show.html.haml within layouts/application (2.1ms)
  Rendered layouts/_navbar.html.haml (2.9ms)
  Rendered layouts/_messages.html.haml (0.1ms)
  Rendered layouts/_footer.html.haml (3.8ms)
Completed 200 OK in 1362ms (Views: 1358.3ms | ActiveRecord: 0.6ms)

I use it in all my projects, so I created a gem to avoid copy-pasting.

Conclusion

I almost never use debugger because console print is just enough in 99% cases. Not only with Ruby/Rails development, but with any technology I ever worked. If you use console print a lot, then you probably have your favorite set of tools. I’ll be glad to know your preference.

Links

• super_awesome_print gem on github

For example, you have a controller:

class UserGroupsController < ApplicationController
  def index
  end

  def show
  end
end

By default, rails will search for templates in app/views/user_groups. But what if you want to put those templates in app/views/users/groups? Instead of this:

class UserGroupsController < ApplicationController
  def index
    render 'users/groups/index'
  end

  def show
    render 'users/groups/show'
  end
end

You can do this:

class UserGroupsController < ApplicationController
  def self.controller_path
    'users/groups'
  end

  def index
  end

  def show
  end
end

However, this will break controller’s spec.

There is another way to do this, however, with another limitation:

class UserGroupsController < ApplicationController
  prepend_view_path 'app/views/users'

  def index
  end

  def show
  end
end

Now rails will search for templates in app/views/users/user_groups. The limitation is that you must name a folder for your templates like a controller. For example, you cannot use app/views/users/groups as a folder for templates for UserGroupsController. You must name this folder app/views/users/user_groups because of the controller’s name.

Conclusion

There are couple ways to set custom templates path per controller. Both have their downsides as a price for breaking conventions.

Links

• StackOverflow question
• controller_path reference on apidock.com
• prepend_view_path reference

It helps you remove duplication:

belongs_to :playlist, touch: true,  inverse_of: :devices
belongs_to :company,  inverse_of: :devices

Will become:

with_options inverse_of: :devices do |a|
  a.belongs_to :playlist, touch: true
  a.belongs_to :company
end

However, there is one gotcha which was unclear for me after reading apidock.

When using ActiveRecord associations you have to use block variable to define associations like in example above. So this:

with_options inverse_of: :devices do
  belongs_to :playlist, touch: true
  belongs_to :company
end

Will not work! However, when using validations, delegations, attr_* it’s not required and you can write this:

class User < ActiveRecord::Base
  with_options to: :profile, allow_nil: true do
    delegate :locale, :email, :gender, :time_zone, :first_name, :last_name
  end

  with_options presence: true do
    validates :login, length: { maximum: 256 }
    validates :password
  end
end

Conclusion

Use with_options, but remember to add block variable when using it for ActiveRecord associations.

Links

• Reference on apidock.com
• RailsCasts#with_options

def func1
  puts "one"
  return
  puts "two"
ensure
  puts "ensure"
end

How the result will look? Of course you’ll never see "two", but what about "ensure"?

[13] pry(main)> func1
one
ensure
nil
[14] pry(main)>

Even you return from a function without exceptions, ensure gets executed.

Another example:

def func2
  10.times do |num|
    begin
      puts "iteration #{num}"
      next if num.even?
      puts "after iteration #{num}"
    ensure
      puts "ensure"
    end
  end
end

And let’s look at result:

[18] pry(main)> func2
iteration 0
ensure 0
iteration 1
after iteration 1
ensure 1
iteration 2
ensure 2
iteration 3
after iteration 3
ensure 3
iteration 4
ensure 4
iteration 5
after iteration 5
ensure 5
iteration 6
ensure 6
iteration 7
after iteration 7
ensure 7
iteration 8
ensure 8
iteration 9
after iteration 9
ensure 9
10
[19] pry(main)>

It was very surprising for me in a contrast with Ruby’s “least surprise principle”. But this is how it works:

Marks the final, optional clause of a begin/end block, generally in cases where the block also contains a rescue clause. The code in the ensure clause is guaranteed to be executed, whether control flows to the rescue block or not.

Conclusion

Every time execution leaves begin block, ensure gets executed no matter what: exception, return, next, break, etc.

Links

• Reference on ruby-doc.org
• Weird Ruby Part 2: Exceptional Ensurance

REST architecture is about CRUD over http. Rails uses RESTful routes. And in every RESTful controller action you may find something like this:

def create
  @post = Post.new(post_params)

  if @post.save
    redirect_to @post, notice: 'Post was successfully updated.' }
  else
    flash[:alert] = "Error updating post: #{@post.errors.full_messages.to_sentence}"
    render :edit
  end
end

def update
  @post = Post.find(params[:id])

  if @post.update(post_params)
    redirect_to @post, notice: 'Post was successfully created.'
  else
    flash[:alert] = "Error creating post: #{@post.errors.full_messages.to_sentence}"
    render :new
  end
end

Not very DRY, isn’t it? The only differences between these actions are:

• Method called on a model
• Action on success
• Action on error
• Text in flash message on success
• Text in flash message on error

What if we can extract them? We can decide which method to call on a model, where to redirect/render after, which flash messages to show by inspecting the model itself and a controller’s action.

But this is fine when you are dealing with ActiveRecord (ActiveModel to be precise) models. What if we are using service objects? One of the “canonical” way to use service objects is by calling call method, like this:

# app/services/create_membership_service.rb
class CreateMembershipService
  def call(options)
    # creating associations, sending notifications, etc
  end
end

# app/services/destroy_membership_service.rb
class DestroyMembershipService
  def call(options)
    # destroing associations, sending notifications, etc
  end
end

# app/controllers/memberships_controller.rb
class MembershipsController < ApplicationController
  def create
    if CreateMembershipService.new.call
      redirect_to :back, notice: "Membership has been created"
    else
      flash[:alert] = "Error creating membership"
      render :edit
    end
  end

  def destroy
    if DestroyMembershipService.new.call
      redirect_to :back, notice: "Membership has been destroyed"
    else
      flash[:alert] = "Error destroying membership"
      render :edit
    end
  end
end

Again, not very DRY. And here comes services which behave like ActiveModel and use CRUD interface.

Also, let’s add some magic method which will call appopriate method on an object, redirect and show flashes:

# app/services/membership_service.rb
class MembershipService
  include ActiveModel::Model

  def save
    # creating associations, sending notifications, etc
    # return true if ok, false otherwise and add messages to `errors`
  end

  def destroy
    # destroing associations, sending notifications, etc
    # return true if ok, false otherwise and add messages to `errors`
  end
end

# app/controllers/memberships_controller.rb
class MembershipsController < ApplicationController
  def create
    magic MembershipService.new
  end

  def destroy
    magic MembershipService.new
  end
end

What inside magic function?

• Check which actions it is called from by inspecting caller
• Call save or destroy according to the action
• Redirect to appropriate url or render a template according to result of calling save or destroy
• Show appropriate flash messages. In case of error - extract messages from errors object

Not so magic, isn’t it? Luckily you don’t have to implement all this logic because I’ve already done this in crud_responder gem.

Now it’s very handy to have all domain objects (models and services) with CRUD interface so you can use them in controllers without worrying whether it’s ActiveRecord model or a service object.