Here’s the source code of ruby String.length (at the time of writing this article):

VALUE
rb_str_length(VALUE str)
{
    return LONG2NUM(str_strlen(str, NULL));
}

As you can see it a calls str_strlen and then calls LONG2NUM on the results, what LONG2NUM does is just to convert a C long int into a ruby Numeric class. At this point let’s see what str_strlen does:

static long
str_strlen(VALUE str, rb_encoding *enc)
{
    const char *p, *e;
    int cr;

    if (single_byte_optimizable(str)) return RSTRING_LEN(str);
    if (!enc) enc = STR_ENC_GET(str);
    p = RSTRING_PTR(str);
    e = RSTRING_END(str);
    cr = ENC_CODERANGE(str);

    if (cr == ENC_CODERANGE_UNKNOWN) {
	long n = rb_enc_strlen_cr(p, e, enc, &cr);
	if (cr) ENC_CODERANGE_SET(str, cr);
	return n;
    }
    else {
	return enc_strlen(p, e, enc, cr);
    }
}

What you should focus on is just the bold text, which is what usually runs (except if the string is encoded in a multi-byte encoding). If you take a look all is does is to call RSTRING_LEN(str):

#define RSTRING_LEN(string) RSTRING(string)->len

The above is a C macro which just fetches len from a RString struct. In fact every Ruby string is stored in a RString struct, which contains meaningful informations such as the current length of the String:

struct RString {
    struct RBasic basic;
    union {
        struct {
            long len;
            char *ptr;
            union {
                long capa;
                VALUE shared;
            } aux;
        } heap;
        char ary[RSTRING_EMBED_LEN_MAX + 1];
    } as;
};

Now that you’ve seen how it works I think you already know the answer: the time complexity to read a String length in ruby is O(1) constant time, unless we are saving a string in a multi byte encoding which cannot benefit from the single_byte_optimizable feature. In that case we have a performance degradation to O(n).

Below some benchmarks which shows this:

require 'benchmark/ips'

optimizable = "this is a string" * 10_000
not_optimizable = "this is â string" * 10_000

Benchmark.ips do |x|
  x.report("optimizable") { optimizable.length }
  x.report("not optimizable") { not_optimizable.length }
  x.compare!
end

result:

Calculating -------------------------------------
         optimizable   268.816k i/100ms
     not optimizable     7.570k i/100ms
-------------------------------------------------
         optimizable     28.189M (± 4.8%) i/s -    140.322M
     not optimizable     76.836k (± 5.8%) i/s -    386.070k

Comparison:
         optimizable: 28188582.0 i/s
     not optimizable:    76836.2 i/s - 366.87x slower

As you can see just by using a 160000 length string the optimized O(1) version is 366 times faster, the longer is the string compared the faster will be the optimized version due to the different time complexity.

The main idea is to create an abstaction which receives in input an array of ActiveRecord relations and then transform the given array into SQL, eventually we’ll use ActiveRecord.from method in order to load the given SQL as an ActiveRecord relation.

Please note that I extracted this examples from gitlab codebase.

module Gitlab
  module SQL
    # Class for building SQL UNION statements.
    #
    # ORDER BYs are dropped from the relations as the final sort order is not
    # guaranteed any way.
    #
    # Example usage:
    #
    #     union = Gitlab::SQL::Union.new([user.personal_projects, user.projects])
    #     sql   = union.to_sql
    #
    #     Project.from("(#{union}) projects")
    class Union
      def initialize(relations, remove_duplicates: true)
        @relations = relations
        @remove_duplicates = remove_duplicates
      end

      def to_sql
        # Some relations may include placeholders for prepared statements, these
        # aren't incremented properly when joining relations together this way.
        # By using "unprepared_statements" we remove the usage of placeholders
        # (thus fixing this problem), at a slight performance cost.
        fragments = ActiveRecord::Base.connection.unprepared_statement do
          @relations.map { |rel| rel.reorder(nil).to_sql }.reject(&:blank?)
        end

        if fragments.any?
          "(" + fragments.join(")\n#{union_keyword}\n(") + ")"
        else
          'NULL'
        end
      end

      def union_keyword
        @remove_duplicates ? 'UNION' : 'UNION ALL'
      end
    end
  end
end

With the above class you can create very quiclky an UNION given an array of AR relations, for example as explained in the comment you can do:

union = Gitlab::SQL::Union.new([user.personal_projects, user.projects])
sql   = union.to_sql

projects = Project.from("(#{union}) projects")

Worth noting that we are dealing always with AR relations which imples that the query is run only if needed; this also implies that the AR relation can be used as parameter to other queries.

Also note that this code will run without loading data in memory (until is needed) thus the code is performant!

Most of the time when you want to find an item based on a set of different conditions you do something like this:

class Project
  		def issues_for_user_filtered_by(user, filter)
		# A lot of logic not related to project model itself
  		end
end

By doing that you end up having a lot of methods that does not really belong to the Model logic. A better solution is through the finder pattern:

issues = IssuesFinder.new(project, user, filter).execute

What the finder does is to accept a set of parameters and return an ActiveRecord::Associations::CollectionProxy that you can use for further filtering/mapping operations.

You can find a complete example of a finder following this link

(function(){
app.Animal = function(){};
app.Animal.prototype = {
	animal: function(){
		return "Hello i am an animal";
	}
};

app.Mammal = function(){};
app.Mammal.prototype = {
	mammal: function(){
		return "I am a mammal";
	}
};

app.Dog = function(){};
app.Dog.prototype = {
	dog: function () {
		return "I am a dog";
	}
};
// dog is an animal but also a mammal
angular.extend(app.Dog.prototype, app.Animal.prototype, app.Mammal.prototype);
// wrap to not pollute the global namespace
})(window.app || (window.app ={}));

var dog = new app.Dog();

// Hello I am an animal
console.info(dog.animal());
// Hello I am a mammal
console.info(dog.mammal());
// Hello I am a dog
console.info(dog.dog());

As you can see you can extend multiple classes (Mammal and Animal) from the Dog class. Here it is! Now you know that you can easily implement traits in Javascript using angular.extend() method. Happy coding!

  def post_authorized(uri, data, user, headers = {})
	post uri, data, headers.merge({'X-Api-Token' => user.api_token})
  end <!-- more -->

  def patch_authorized(uri, data, user, headers = {})
	patch uri, data, headers.merge({'X-Api-Token' => user.api_token})
  end

  def put_authorized(uri, data, user, headers = {})
	put uri, data, headers.merge({'X-Api-Token' => user.api_token})
  end

  def delete_authorized(uri, user)
	delete uri, nil, {'X-Api-Token' => user.api_token}
  end
end

As you can see from the code above there is some code duplication, in fact the authorized methods get,delete and post,patch,puth shares the same code besides the fact that the method called is different, for example post_authorized calls post etc. In a general OOP approach we could just extract the logic into a shared method that accepts the verb name to be called and then makes a call with that name. But this time i decided to leverage some ruby metaprogramming technique. In the code below we dynamically create in pair the get,delete and post,patch,put methods; in fact the only thing that changes is the method name #{m}. Here is the code:

module RequestMacros
  %w(get delete).each do |m|
	class_eval <<-eoc
	  def #{m}_authorized(uri, user)
		  #{m} uri, nil, {'X-Api-Token' => user.api_token}
	  end
	eoc
  end

  %w(post patch put).each do |m|
	class_eval <<-eoc
	  def #{m}_authorized(uri, data, user, headers = {})
	  	#{m} uri, data, headers.merge({'X-Api-Token' => user.api_token})
	  end
	eoc
  end
end

What we just did is with every verb make a method verb_authorized that calls verb, we couldn’t do that without ruby metaprogramming tools! Leveraging metaprogramming allow us to build readable and compact code in a very fascinating way. That’s all for today, happy coding!

Class X
   def method_x(*args)
 	  #do something
   end
  	end <!-- more --> if you want to do something after calling method x you can easilly override the method in a module like this:

module X
	def method_x(*args)
		super(*args)
		# do something more
	end
end

And then include the module X in your class X. So why should you handle that with metaprogramming? As first in certain situations you cannot override the method using a classical oop approach, for example when you are already leveraging some metaprogramming to dynamically create a method_x inside an included module like this:

module Y
	def self.included(base)
		base.instance_eval do
			def method_x(*args)
				# do something
			end
		end
	end
 end

In that case the method_x is dynamically created and you cannot override it easilly and use the “super” classical oop, therefore you need to handle that with a callback. Callbacks also allow you to handle that in a more fashioned and readable way. Let me show you how can you do an after_method_x callback: Firs of all include the Callbacks method i’ve created:

module Callbacks
  		extend ActiveSupport::Concern

  module ClassMethods
	  def do_after(method)
		guid = SecureRandom.uuid
		define_method("#{guid}") do |*args|
		  yield self, __send__("#{guid}_#{method}", *args), *args
		end
		alias_method "#{guid}_#{method}", method
		alias_method enum, "#{guid}"
	  end
	end
 end

When you use the method do_after it creates a new method using guid to ensure uniqueness, that method yields self allowing to pass a custom block, and then calls the original method aliased as #{guid}_#{method}. To use that in your class you coud do like this:

Class X
  	include Callbacks
	do_after(:method_x) do |klass, result, *args|
		# do wathever you like here in the block
	end
 end

And we have handled a do_after leveraging metaprogramming. I let you imagine the other hooks by yourself. Have fun and Happy coding!

Class MyModel 
	include ActiveModel::Model
	
	validates_with MyValidator, attributes: :urr

And here is the custom matcher code:

 RSpec::Matchers.define :have_my_validator do |attr_name|
  # Check for all the callback that have MyValidator on the given attribute attr_name
  match do |actual|
    validator = actual._validate_callbacks.select {|callback|
      callback.filter.attributes == [attr_name.to_sym] &&
          callback.filter.class == MyValidator
    }
    expect(validator.size).to be > 0
  end
end

What the matcher does is to:

1. Fetch the list of all the validation used in the model
2. Search for a validator fo MyValidator class and that is applied on a given attribute name
3. If any is found the test passes otherwise it fails.

You can use the validator as following: expect(object).to have_my_validator(:urr)

You can also be more DRY and extract the class name as a parameter and then use it to match any kind of validator.

That’s all for now. Happy coding!

module Devise
  		module Models
		module RemoteAuthenticatable

	   def serialize_from_session(username, password)
		 resource = User.new
		 resource.username = username
		 resource.password = password
		 resource
	   end

	   def serialize_into_session(resource)
		 #IMP you can only pass two params, no more because of this code :
	 	 # devise.rb.466      args = key[-2, 2]
 		 [resource.username, resource.password]
	   end
	 end
  
  	 end
	end
end

What happens is that devise passes the result of serialize_into_session to serialize_from_session but it fetches only the last 2 items of the return value: “args = key[-2,2]”. for this reason you need to pass the needed information in a two item array in order to make this work (if you need more data replace the items with an hash). In this example we use the username to identify in a unique way the user and then we create an user with the given username when we deserialize the item (you can also have a custom method that fetches the model form a temporary memory data or a model saved in the database).
I hope you found this article useful! If you have any question feel free to ask me (will help to increase the quality of the post). Happy coding and enjoy ruby!