It’s easy to talk about public or private type of access control, because it’s obvious that public allows everything while private allows access only from within the same kind of objects (inherited). What about protected it’s quite different and some behavior of it could be surprising even for experienced ruby programmers, so make sure that you know it;)

class Person
  attr_reader :address

  protected :address
 
  def initialize(address)
    @address = address
  end
  
  def send_invitation_to(person)
    "Sending invitation to '#{person.address}'"
  end
end

igor = Person.new('Ukraine')
peter = Person.new('Germany')

peter.address # => NoMethodError (protected method `address' called for #<Person:0x0000559e29f7ae50 @address="Germany">)
igor.send_invitation_to(peter) # => "Sending invitation to 'Germany'"

As you can see we have no access from outside to peter.address but when we try access it from within the same kind of instance where it was defined as protected then it works just fine. But you still need to be careful in place of polymorphism because if protected method was redefined then it will be no longer available for instances produced by parent class:

class VeryImportantPerson < Person
  protected
  
  def address
    @address
  end
end

vip = VeryImportantPerson.new('France')
vip.send_invitation_to(igor) # => "Sending invitation to 'Ukraine'"
igor.send_invitation_to(vip) # => NoMethodError (protected method `address' called for #<VeryImportantPerson:0x0000564a6ca9af58 @address="France">)

The same is true for class methods with only difference that protected methods as all other class related stuff is located in Metaclass, so could be accessed only from within the same kind of Metaclasses.

There is still the issue with class methods access control which beginners are tending to do:

class First
  protected

  def self.info
    "some protected info - #{object_id}"
  end
end

First.info # => "some protected info - 180"

First does not protect info method simply because protected does not affect class methods (which are located in Metaclass) and has effect only for methods which are defined for instances and if we need our class methods to be protected then we need to define them as protected in Metaclass.

class Second
  class << self
    protected

    def info
      "some protected info - #{object_id}"
    end
  end
end

Second.info # => NoMethodError (protected method `info' called for Second:Class)

Access control methods itself are private and could be used within class definition, but with send method we still could invoke private methods, so we could make our First.info protected without even opening Metaclass.

First.singleton_class.send(:protected, :info)

First.info # => NoMethodError (protected method `info' called for First:Class)

As you already know protected attributes could be accessed only from same kind of instances and instances produced by some classes have no relation to their Metaclasses, so there is no ability to access protected attributes of instance from within class methods or access protected class methods from within instances produced by it. Of course we have send which ignore access control and requires additional attention in places where it’s used, but attention is quite limited and valuable, so if you just need dynamically access public attributes and not violate access control, please use public_send ;)

Service object expects to perform single action, so there shouldn’t be more than one public method which could trigger it.

Actually, there could be a number of methods but a service object as function in functional programming language expects to have a single entry point for executing it. If your service has more methods which perform some different things, then maybe it has more than one responsibility. So, if we have one method then it makes sense to name it call, not perform or execute because we already have call for lambda, proc, block invocation and they all are about single action. The more obvious benefit is that we could use our services interchangeably with lambdas, proc, block. But before we will dive into it, we need to clarify what kind of service objects we could have.

1. Service class

class PrintService
  def self.call(value)
    puts value
  end
end

PrintService.call('well') # => 'well'
PrintService.('well') # => 'well'

It’s the simplest service object which could be, it doesn’t require the creation of a new instance of himself. I think such kind of service objects make sense while it is simple and you didn’t start creating more class methods and passing arguments around, which brings us to the next type of service object.

2. Service instance (+class compatible)

class MultiplyService
  def initialize(a, b)
    @a = a;
    @b = b;
  end
  
  def call
    @a * @b
  end
end

RandService.new(2, 2).call # => 4
RandService.new(2, 3).() # => 6

Sometimes we need additional private methods in our service to make call method simpler and to avoid passing call method arguments down to other methods that perform some related work. Maybe later you will find out that some of these methods are ready to be service objects as well. But who wants additional new method invocation? — so it could make sense define a class method in such way:

class MultiplyService
  def self.call(*args)
    new(*args).call
  end
end

MultiplyService.call(1, 3) # => 3
MultiplyService.(2, 2) # => 4

Now our service has own instance but the interface for triggering it could be the same as in the previous case via invocation of call class method. At the same time service initialization using new and then multiple invocations of it also is possible, which could make sense for some cases like mutating state (side effects), or generating some kind of events like “ping”, but as our instance call method has no arguments we could introduce next type of service.

3. Reusable Service instance (-class compatible)

class LogService
  def initialize(source)
    @source = source
  end
  
  def call(message)
    @source << "Info -- #{message}\n"
  end
end

service = LogService.new(STDOUT)
%w[one two].map { |m| service.call(m) } # => Info -- one\n...

The difference from the previous kind of service is that we split arguments between initialize and call in a way that we don’t want initialize new service on every invocation while only the target argument is changed but the whole service is still the same. As result we need to initialize service before it could be used, if you initialize it one every invocation then you don’t need to split arguments and use the previous type of service object, from the same point such service has no sense in class invocation method, because initialization and invocation expect to be done separately.

Now let's move back to our lambda, proc, block and benefits of call method and why it happens that using our service as block requires us to do such things like: &PrintService.method(:call)

Service object to Proc

Services defined previously have a method call so we could switch them with lambda or proc but just in a place where call method is invoked, but when we wont to pass our service object as block it doesn’t work:

[1,2,3].map &PrintService
# => TypeError (wrong argument type PrintService (expected Proc))

& expects that there will be something which could be converted to proc, but our services just have a method call, so we need to fix it:

module Service
  def to_proc
    method(:call).to_proc
  end
end

PrintService.extend(Service)
MultiplyService.extend(Service)
LogService.include(Service)

[1,2,3].map &PrintService # => 1\n2\n3\n

log_service = LogService.new(STDOUT)
[1,2,3].map &log_service # => Info -- 1\n...

Now it looks better! So & invoke to_proc on an object which is used with it, as a result we could extend our services with such a method and returns exactly what we need. In the case of LogService we extend the functionality of our service instance since it is not expected to be used as the service class. But were an example of MultiplyService? — move to the next section.

Service object with currying

[1,2,3].map &MultiplyService # => ArgumentError(given 1, expected 2)

As expected we cannot iterate over our MultiplyService since it requires two arguments while map provide only one. For such kind of problem proc already has currying, so we just need to extend our services with such ability:

module Service
  def [](*args)
    method(:call).curry.call(*args)
  end
end

[1,2,3].map &MultiplyService[2] # => [2,4,6]

I think square brackets are exactly what is needed since they are available for proc invocation in the same way as call, but in our implementation, we will have currying in place when not enough arguments are provided.

Composition of Service Objects

Since Ruby 2.6 we have the ability to build the composition of our Proc objects, so it looks normal to have such ability for our services as well:

module Service
  def >>(service)
    method(:call).>>(service)
  end

  def <<(service)
    method(:call).<<(service)
  end
end

[1,2,3].map (MultiplyService[2] >> PrintService) # => 2\n4\n6\n

It looks nice that we have such ability but in terms of performance, it’s not the same as direct invocation.

PS: Ability to interact with your service object as with Proc doesn’t mean that you need to use it instead of Proc, as already mentioned they both are about single action so it could even make sense just to use Proc instead of service objects.

inspect # => "main"

So, let's try to clarify what it is.

self.class # => Object
method(:inspect).owner # => #<Class:#<Object:0x000055bd67f9dd58>>
method(:inspect).owner == singleton_class # => true

It looks like main is an instance of Object Class instance, while a method inspect is defined as it’s Singleton:

def self.inspect
  "my-main"
end

inspect # => "my-main"

singleton_class.instance_methods(false) # => [:inspect, :to_s]

It’s expected behavior since Ruby check’s Singleton methods in the first place and just then instance methods defined by Class instance which produced it. So, if main is an instance produced by Object then what about instance variables?

@instance_var = 1
@instance_var # => 1

Works as expected, but what about regular methods defined with def which we could define without using Class scope? Maybe it would be better do not have such ability, so every method would be possible to define only in the context of Class instance, but currently, we have such ability, so let's check it:

def my_method
  'method in main scope'
end

my_method # => 'method in main scope'

This is the place where main is no more just instance produced by Object Class instance, but something more, because we could add methods to already existed instance without using Singleton or Object Class instance, so it works like we are in the scope of Object Class instance and defining regular instance method:

method(:my_method).owner  # => Object
Object.instance_methods.include?(:my_method) # => true

Object.new.my_method # => Error: private method `my_method' called

As you could see, it’s not a regular instance method, it’s private, so methods defined in main scope are defined as a private methods of Object Class instance. One more thing which works in main scope as in Class instance scope are constants:

CONST = 'constant' # => defined like in class scope
Object.const_defined?(:CONST) # => true
Object::CONST # => "constant"

Maybe there are more examples which could demonstrate that main is not just instance produced by Object Class instance, but also as we already see it has some special power which is available in Class scope. Additionally, we could check few more methods which extends our main instance:

singleton_class.private_instance_methods(false)
# => [:public, :private, :include, :using, :define_method]

In the case of using IRB it’s common to see irb(main) > but you could change it redefining inspect and to_s as we did above, but more interesting is that you could change scope using cb command and jump around from one context to another, but remember that main is not just simple Object instance;)

irb(main)> singleton_class.remove_method :to_s, :inspect
irb(#<Object:0x000055b6fc5e1d58>)> cb Object
irb(Object)> cb Object.new
irb(#<Object:0x00005612b111dd38>)> 

How we define our ‘proc’ and ‘lambda’

my_proc = Proc.new { p 'Hello!' } # => #<Proc:0x000055...>
my_proc = proc { p 'Hello!' }     # => #<Proc:0x000055...>

my_lambda = lambda { p 'Hello!' } # => #<Proc:0x000055... (lambda)>
my_lambda = -> { p 'Hello!' }     # => #<Proc:0x000055... (lambda)>

You could replace {} with do end and have the same results but with a pretty different look and if you will mix these styles with no reasons then it will be just harder to read and one more way to frighten newcomers. So, if you have multiline definition then do end could be better than {}, while for inline definitions {} is more appropriate, BTW there is no relation between lambda and {} as between Proc and do end.

In which way to construct — Proc.new is just an explicit way of creating new proc as an instance of the Proc class instance and almost never used on practice, so if we need proc then just use proc keyword but even this is a rare case simply because Ruby has a more elegant way of constructing proc and it has name block to which we will return later. What about lambda keyword it’s mostly used when we have a multiline definition with do end, while for inline definitions we have -> {}, but at some project -> {} could be used even for multiline definitions while lambda in conjunction with do end could be avoided at all.

What about invocation:

greeting = "Hello"
my_lambda = -> (name) { "#{greeting} #{name}!" }
my_lambda.call('John') # => 'Hello John!'

greeting = "Aloha"
my_lambda.call('John') # => 'Aloha John!'
my_proc.('John')       # => 'Aloha Hello!'
my_proc['John']        # => 'Aloha Hello!'

In the same way both proc and lambda scope outer variables, as a result of changing greeting we changed behavior. At the same time, there are few ways of invocation, while .call is the most common and frequently used way, some projects could follow .() style and have:

add = -> (a) { -> (b) { a + b } }

add.(1).(2) # => 3

What is the difference between ‘proc’ and ‘lambda’?

You may already noticed from the definition part that lambda is just some kind of Proc but there is a difference in place of receiving arguments and returning a value, while Proc is a special kind of beast, lambda could be simply treated as an anonymous method because it has the same behavior for incoming arguments and return as a regular method defined with def keyword:

greeting = -> (name) { return "Hello #{name}!" }
greeting.call('John') # => Hello John!
greeting.call() # => ArgumentError (wrong number of arguments ...

But why Proc is something special? — Simply because it behaves in a different way in comparison with regular methods, it’s not restricted to arguments and return not just return some value from inside of Proc, it returns value out from scope it’s defined in:

greeting = proc { |name| return "Aloha John!" if name == 'John' }
greeting.call('Bond') # => nil
greeting.call('John') # => LocalJumpError (unexpected return)

def perform(name)
  greeting = proc { |name| return "Aloha John!" if name == 'John' }
  greeting.call(name)
  "Hello #{name}!"
end

perform('Bond') # => "Hello Bond!"
perform('John') # => "Aloha John!"

As you can see, greeting returns value right from perform in which it was defined. Just as a note — last value in lambda or proc will be returned as a result of .call invocation, so use return when it makes sense, which is not about previous example, a better example of immediate return could be:

class Array
  def has?(target)
    each { |item| return true if item == target }
    false
  end
end

[1,2,3,4].has?(2) # => true
[1,2,3,4].has?(5) # => false

So, each is a method which iterates through every item of array with invocation of code in the curly brackets for every item in array and in the place where item equal to target we return true right from has? method and only in case if nothing was matched during iteration then false will be returned.

What about ‘block’?

In the above example, you may already notice something similar to proc or lambda, something in curly brackets which was passed to each method without proc or lambda keywords — block. It’s one of the things Matz is proud of, thing which is on every corner in Ruby world, no keywords needed no constructors only block of code in {} or do end and named block, how it could be named in a better way?;) Ok, it’s cool, but we already have proc and lambda why do we need something new? — It’s not new, it’s just simple Proc but constructed in place of method invocation in an elegant way, but since it’s not a regular argument which we are passing into the method, it needs to be handled differently:

def perform_block(&block)
  block.call if block
end

# or

def perform_block
  yield if block_given?
end

perform_block # => nil
perform_block { "Hello!" } # => "Hello!"

As you can see we need a special sign & for argument which will receive block and then we could simply access our variable which will contain our proc instance, also we could use a special method yield for invocation and block_given to check if the block was passed. The fact that we have block doesn’t mean that we could not create proc manually and pass it to method explicitly, even more, we could convert proc and lambda to block argument:

def perform_proc(my_proc = nil)
  my_proc.call if my_proc
end

greeting = proc { "Hello!" }
perform_proc(greeting)   # => "Hello!"

perform_block(&greeting) # => "Hello!"
perform_block(&-> { "Convert lambda to block" })

Conversion of lambda to method's block argument doesn’t mean that we change its behavior, so yield or block.call will invoke the same lambda which we pass to the method as block

More ways to ‘return’

if we still need immediate return of some value from proc without returning from the scope in which it was defined we could use next keyword which for lambda works the same as return:

class Array
  def replace(target_value, new_value)
    map do |item|
      next new_value if item == target_value
      item
    end
  end
end

[1, 2, 3].replace(2, 'X') # => [1, "X", 3]

map — is method which iterates over array in the same way as each with a difference that it collects results from each iteration, so we don’t need return from replace method itself, we only need return value from proc and continue iteration and next does exactly what we need. Of course, we could avoid next in the above example via using simple condition but in complex cases next as part of a “guard clause” could be simpler.

So with proc we could return value from the scope where it was defined using return, we could simply return value from inside of proc using next, but what about returning value from the scope where it was invoked not defined?

def greeting(&block)
  "Hello #{block.call}!"
end

greeting { 'John' }        # => 'Hello John!'
greeting { next 'John' }   # => 'Hello John!'
greeting { return 'Ups' }  # => LocalJumpError (unexpected return)
greeting { break 'Bye!' }  # => 'Bye!'

While break inside block works fine, you could be quite disappointed to notice that it doesn’t work in the same way for proc and produce LocalJumpError (break from proc-closure) no matter where you call it. It’s strange since block is just the same proc and expect to have the same behavior, so for me it sounds like language issue.

What about break with lambda we just have one more way to return ;)

def greeting(my_lambda)
  "Hello #{my_lambda.call}!"
end

greeting -> { 'John' }                 # => 'Hello John!'
greeting -> { next 'John' }            # => 'Hello John!'
greeting -> { return 'again' }         # => 'Hello again!'
greeting -> { break 'one more time' }  # => 'Hello one more time!'

something 
# => NameError (undefined local variable or method `something` ...

def something; :method; end
something() # => :method
something   # => :method

something = :variable
something() # => :method
something   # => :variable

So, in the first place, we are looking for a variable and just then for a method with the same name. It’s more explicit when the method is invoked with parenthesis, but there is no reason for it:

user.update(first_name: 'John')

What is user in the above example? Yes, it could be variable or method but in both cases, we expect some value, no matter how it is delivered. In some cases, during refactoring, we simply could just replace a variable with the method or replace method with inline variable without additional changes.

One more interesting case is the situation with constant variables which are used for Class instances and regular constants LIKE_THIS:

ONE = 1
def ONE
  1.0
end

ONE   # => 1
ONE() # => 1.0

# but

def TWO
  2.0
end

TWO   # => NameError (uninitialized constant TWO)
TWO() # => 2.0

As you can see there is a difference between regular variable and constant variables, there is no lookup by methods, so even if you have a method with the same name as constant it will not be invoked until you explicitly use parenthesis or pass arguments to it. While we could have method names similar to constant names it looks strange, but situation with constants used for Class instances are different:

def Person(first_name, last_name)
  Person.new(first_name, last_name)
end

class Person
  def initialize(first_name, last_name)
    @first_name = first_name
    @last_name = last_name
  end
end

Person("Ricky", "Martin") # => #<Person:....>

In the above example, we use a method with the same name as our Class instance variable name to perform the creation of new instances which may have no much sense, but there are more useful examples — in Ruby, we have such methods like Array() which tries to invoke to_ary or to_a on argument passed to it, so it could be used for conversion. Also, we could get some example from dry-rb, where we have such methods for generating new Class instances:

module Dry
  def self.Struct(attributes = EMPTY_HASH, &block)    
    Class.new(Dry::Struct) do
      attributes.each { |a, type| attribute a, type }          
      module_eval(&block) if block
    end
  end
end

User = Dry.Struct(name: Types::String, age: Types::Integer)

# equal to:

class User < Dry::Struct
  attribute :name, Types::String
  attribute :age, Types::Integer
end

If a method is instantly invoked without parenthesis then how we could get reference on it and pass around? How we could invoke methods in different contexts? Is it possible at all? — Yes, there is a Class instances Method and UnboundMethod which provide such abilities:

bounded_push = [1,2].method(:push) # => #<Method: Array#push>
bounded_push.call(3)               # => [1,2,3]

unbound_push = bounded_push.unbind # => #<UnboundMethod: Array#push>
unbound_push.bind(['a']).call('b') # => ['a','b']

As you can see, we can get “reference” on method and invoke later, at the same time we could unbind method from one context and bind it to another instance.

class Person
  def initialize(first_name, last_name)
    @first_name = first_name
    @last_name = last_name
  end
 
  def full_name
    "#{@first_name} #{@last_name}"
  end
end

Person.instance_methods(false) # => [:full_name]

person = Person.new("Bob", "Martin")
person.full_name # => Bob Martin

As we can see there is a definition of Class instance Person which describe functionality of instances it could produce. Method new is part of Class implementation which is responsible for creating new instance and after such instance is created the private method initialize will be invoked on it. So, both methods initialize and full_name are called instance methods simply because they are available for instances produced by Person, but in the same way method new is instance method of Person instance produced by Class, such methods, available for Class instances we call simply as “class methods”.

So, if we need more functionality for instances produced by Person we could define it in place of creation Person instance, but how we could add some functionality to Person instance itself which is produced by Class instance? Do we need to define it in place of creation Class instance? but where is such a place? — The answer is that we don’t need to modify Class instance to add functionality to the single instance produced by it, such as Person, at list because we need to define some functionality only for Person instance not for all instances produced by Class instance. The solution is that every instance has one more instance behind it and it is linked to the initial one and could be used for such purpose:

class Person
  def self.info
    "Some description"
  end
end

# or

class Person
  class << self
    def info
      "Some description"
    end
  end
end

# or

def Person.info
  "Some description"
end

# or

class << Person
  def info
    "Some description"
  end
end

Person.singleton_class.instance_methods(false) # => [:info]

Person.info # => Some description

So, if we need some “class methods” for our Class instances such as Person instance then we use the second instance behind it which is called as Metaclass or Eigenclass or Singleton.

def Person.new; end

Person.new # => nil

As you can see we redefine new method with our own implementation located in Metaclass. The next question could be — if every instance has some instance behind it then how it works when we try it on instances different from Class instances?

bob = Person.new("Bob", "Martin")
ricky = Person.new("Ricky", "Martin")

def bob.full_name
  "Robert Cecil #{@last_name}"
end

# or

class << bob
  def full_name
     "Robert Cecil #{@last_name}"
  end
end

bob.full_name # => Robert Cecil Martin
ricky.full_name # => Ricky Martin

So, we redefine bob instance full_name method definition with custom implementation placed in Metaclass which just highlight the way how it’s linked to initial instance, at the same time instance ricky didn’t change behaviour simply because it has own Metaclass. While this works fine there is no much reason to use it and confuse everyone why instances produced by the same Person instance have different behaviour, so remember that it’s solution to have different behaviour for instances produced by Class instance such as Person, File, Dir, etc. which are produced from the same Class instance but needs different functionality.

If there is still a need to define some functionality which need to be available for all Class instances or we need to change already existed Class instance then we could simply “re-open” it, but there is no much sense in such monkey patching, which could bring a lot of pain:

class Class
  def info
    "#{self.name} instance produced by Class instance"
  end
end

class Person
  def full_name
    "patched full_name" # original method need to be updated instead
  end
end

Person.info # => Person instance produced by Class instance
Person.new(nil, nil).full_name # => patched full_name

Again there is some special cases with “unique” values such as symbols and numbers which doesn’t have additional instance behind it because there is no much sense to define specific functionality only for single symbol or number, at same time we have such ability for true, false, nil values:

def true.info; end

a = :something
def a.info; end
# => TypeError (can't define singleton)

From the message, it’s obvious that we try to define Metaclass but it was rejected, so Metaclasses are created automatically only for instances produced by Class instance, while for other instances Metaclasses are created when they are needed.

class Person; end

This is the way how we create class in Ruby via using language syntax. At the same time, it is just a common way we create a new instance of Class and assigning it to Person variable, which is equal to:

Person = Class.new

Only instances of Class have abilities to create new instances:

person = Person.new

And someone could raise a question — if only instances produced by Class have the ability to create new instances then how we could explain the ability of having Class.new and produce such instances too? So, there is a logical answer — Class is the instance of Class or itself;)

person.class # => Person
Person.class # => Class
Class.class  # => Class

Class.object_id == Class.class.object_id # => true

The question of how Class could be an instance of them-self is rhetorical because it’s language implementation about which could be more discovered in Ruby source code, also there is an awesome book Ruby Under a Microscope: An Illustrated Guide to Ruby Internals.

Instances of Class we simply call “classes” as places of definitions for our instances which they could produce, at the same time we name our “classes” with capital letter as Person to highlight the fact that it’s Class instance, but as it’s still an instance it could have any name:

person = Class.new # => #<Class:0x00005614bb425718>
Person = Class.new # => Person

The difference is only the way how such instance represent/print itself, so if we will ignore such customization there will be no difference:

Module.remove_method :inspect

Person # => #<Class:0x0000563455a4c920>
Class  # => #<Class:0x000055a8aa2a1608>

Not every Class instances have the ability to create new instances due to global uniqueness:

true.class # TrueClass
false.class # FalseClass
nil.class # NilClass
1.class # Integer
:something.class # Symbol

:something.object_id == :something.object_id # => true

Symbol.new('something') 
# => NoMethodError (undefined method `new' for Symbol:Class)

So, there is no sense in Symbol.new('something') simply because Symbol is not able to produce new instances one every invocation of new. The same is true for boolean and number instances which are globally unique, so instance of Integer such as 1 is always the same and there is no ability to create new 1

Integer.remove_method :inspect

1 # => #<Integer:0x0000000000000003>
2 - 1 # => #<Integer:0x0000000000000003>

Also, there is some special case with such Class instance as String which always produce new instances when it’s done explicitly, but when we use literals in conjunction with magic comment # frozen_string_literal the instance of string is reused (and it’s frozen so cannot be changed)

String.new('a').object_id == String.new('a').object_id # => false
'a'.object_id == 'a'.object_id # => false

# with magic comment which need to be placed on top of your .rb file
# frozen_string_literal: true

String.new('a').object_id == String.new('a').object_id # => false
'a'.object_id == 'a'.object_id # => true

Next to read: Ruby Metaclass, Eigenclass, Singleton

On one of the projects we catch a few exceptions in a short period of time which pointed to Ohm::Model objects with the message RuntimeError: not connected. Ohm is a gem that provides objects mapping for Redis and the issue in the first place was fixed with some tweaks around Redis connections, but the reason for the issue was not clear. Why connection to Redis was not established? Or maybe the connection was lost due to some reasons? So it was decided to clarify where such exception comes from and why.

Ohm by default use Redic adapter for connecting to Redis. In Redic client implementation lib/redic/client.rb:

def connect
  establish_connection unless connected?

  @semaphore.synchronize do
    yield
  end
rescue Errno::ECONNRESET
  @connection = false
  retry
end

def establish_connection
  begin
    @connection = Redic::Connection.new(@uri, @timeout)
  rescue StandardError => err
    raise err, “Can’t connect to: %s” % @uri
  end

  # ...
end

we could see that StandardError exception during creation of connection instance is handled and exception message raised in result is different from what we’ve got, at the same time we handle Errno::ECONNRESET exception which expects to re-establish connection via retry if it to was lost. So, there is no reason why we could have RuntimeError: not connected, to clarify it we need dive dipper into implementation of Redic::Connection which simply wraps Hiredis::Connection from hredis-rb gem.

Moving to Hiredis we could find connection implementation which by default lead us to Hiredis::Ext::Connection which wraps C implementation of connection used for better performance and maps EOFError to already spotted in Redic exception Errno::ECONNRESET

module Hiredis
  module Ext
    class Connection
      def read
        _read
      rescue ::EOFError
        raise Errno::ECONNRESET
      end
    end
  end
end

moving down the line to C-extension we could find definition of read method https://github.com/redis/hiredis-rb/blob/master/ext/hiredis_ext/connection.c#L459

static VALUE connection_read(VALUE self) {
    // ....
    if (__get_reply(pc,&reply) == -1)
        parent_context_raise(pc);

which means that if a connection is lost we invokeparent_context_raise(pc) which expects that connection will be nullified and raised `EOFError` exception https://github.com/redis/hiredis-rb/blob/master/ext/hiredis_ext/connection.c#L61

static void parent_context_raise(redisParentContext *pc) {
    // ...
    parent_context_try_free(pc);
    // ...
    case REDIS_ERR_EOF:
        /* Raise native Ruby EOFError */
        rb_raise(rb_eEOFError,"%s",errstr);

as we already have seen EOFError later is transformed to Errno::ECONRESET and expect to be handled by Redic via creating a new connection, but if we will try to send data to such broken connection RuntimeError: not connected will be raised, so why the connection was not re-established but instead we send data to bad one? It happens simply because Redic establish_connection was involved outside of @semaphore.synchronize block which expects to sync all execution, as a result, while Errno::ECONNRESET was handled by one thread, others were trying to send data to old broken one and resulted in exception.

As conclusion, the issue was spotted and synchronization was fixed in PR to Redic https://github.com/amakawa/redic/pull/15

If the quality is not one of the major points of the developing process then maybe you didn’t have a review process at all or it’s something formal which I think could happen in conjunction with Strong code ownership where developers allowed only to make changes to modules/areas they own. So there is only a single person who fully understands and is responsible for some area of the product. As for me, it’s not a team but individuals who leave in own worlds coordinated in some ways. There is no sense to talk about the quality of code produced in a such way, no matter how skilled is developer, because it will be alien code for the rest of the team. One more problem, in this case, is bus factor equal to 1, which means that if developer leaves the product there will be troubles with knowledge in areas they were responsible for.

Opposite situation is when team own the product with no borders between developers and this requires review, so developers will be aware of what code is introduced and how it is implemented, in case if there are questions to implementation they could be raised/discussed/resolved and just then accepted/merged. After PR is merged the code automatically becomes collective responsibility and has Collective ownership which means everyone in the team is responsible for it. Without review, we cannot have Collective ownership simply because no one wants to be responsible for something no one aware of. In this case expects that there is no bus factor but it could be true maybe only in case when all developers in a team have the same experience and all participate in every PRs, which is too ideal. While review is required for Collective ownership it doesn’t mean that every developer need perform PR review before it will be merged but it requires review from at list one/few developers who could represent collective ownership, it could be team/tech lead or senior developers it could be middle developer, but the main point is that whole team need to trust to this developer and accept responsibility for made decisions, so it needs to be experienced developers who can perform review in a way that there will be no questions why something bad was merged. If such questions are raised multiple times then maybe such developer cannot accept PRs at list alone, to stress such problem could be quite tricky, as example such team member could be a team lead, which has wide responsibilities and no time for writing code but still accepts PRs which will brings questions. So maybe it could make sense does not allow accept PRs for team members who don’t produce code and doesn’t work with code which they want to merge. At the same time, review should not be limited just to some developers and could be performed by anyone who wants to do it and could get value from it, learning new things, gain product expertise, etc.

In some cases Collective ownership could shift to Weak code ownership where developers could take additional responsibility for the modules they implemented and keep an eye on changes made by other developers, additional responsibility is fine and every developers could have some fillings to code which they produce and be more interesting in evolution of it into right direction but there need to be a balance and such additional responsibility should not become a protection from other developers changes which could lead to Strong code ownership.

Also there could be opposite case where team put additional responsibility on author of changes and it could happens where some PRs are accepted with rush due deadlines or accepted by someone who is not fully responsible for collective ownership or PR changes was so big that it wasn’t possible review it in precise way but it was accepted by some reasons. In such cases, a team could disassociate from such code and put additional responsibility on the author of it since it was not properly accepted and the team doesn’t want to take responsibility for it. This situation could be solved by them-self during some time as team go through such implementation and improve/refactor it, and it is good point if author has responsibility about own code and put additional efforts to fix/improve it and bring it back to Collective ownership as fast as possible, but there is a chance that such developer could avoid such responsibility and maybe even forgot about some promises, when team will highlight the problem there could be excuses that it’s Collective ownership and responsibility, by the time it’s not even a Weak code ownership it shifts directly to Strong ownership simply because no one wants to be involved into areas of code which own author avoid, so better when developer has additional responsibility then has no it at all, and it is more critical in cases when review process wants to be better.

Few points to highlight about review process which I think could make sense:

1— keep PR small so they could easily pass review process and every one of the team developer could understand changes without diving into details, so setup limits on changes in single PR and do not accept large PR’s with excuses like “it’s not so big”, “we need merge it at once due dependencies” etc.

2 — PR could be merged only after everything is done, no unresolved comments, because after it’s merged there will be no more authors responsibility for it, so do not accept excuses like: “no time for polishing, it expects to be done yesterday”, “it will be updated later”. I think there could be single exception to perform some work later if it’s not closely related to PR and could increase complexity and size of it, but it needs to be described and linked to the source of the issue before PR will be merged

3 — reviewer is more responsible for accepted code then author because he represent Collective ownership, so if there will be question about quality they will be directed to reviewer in first place and it could be possible that after few such questions reviewer cannot be able to make acceptance decisions by them-self, at same time it’s better when acceptance of PR is based on couple of reviewers decision

4 — reviewer as developer need to understand that after merge he could be next who will work with that code, so make sure that it will be a pleasure to continue work with it and it’s one more reason why reviewer need to be involved into code crafting

Martin Fowler — Code Ownership