It took me some time to understand that sugar syntax.
First of : it's & :to_s obviously.
Operator is &.

What does it do ?

it turns

mythings.map(& :upcase)
# is the same as 
mythings.map(&:upcase)

into

mythings.map { |mything| mything.upcase }

Remark : sugar syntax can be a pain in the butt. I hope you do see it.

The map method applies the "block" { |mything| mything.upcase } on each and every elements of mythings and returns an enumerable of class mythings.class containing each result.

The operator is & and the argument in my example is :upcase. :upcase is a Symbol.
Symbols have a smart to_proc method.

Another example :

require 'date'
[1,DateTime.now,3].map(&:to_s)
# => ["1", "2021-09-05T12:06:54+02:00", "3"]

So how does it work ?

• &̀ when a parameter of a method is prepended with & then ruby knows this parameter to be a Proc

• :upcase is a symbol.

So the &:myproc is a smart shortcut implemented to turn the symbol :myproc into a proc.

Let's try it :

def call_my_block ( my_parameter, &myblock)
  myblock.call.myblock
end

The parameter &myblock is known to be a block.

When I use method call_my_block with the argument &:my_symbol :

• The second parameter is known to be a block.
• The argument will be translated into :my_symbol.to_proc
  If the first argument is of class KlassandKlassactually has a my_symbol method, then it will call it.

Example :

call_my_block DateTime.now , &:to_s translates into :

:to_s.to_proc.call DateTime.now 

note that :

a = :to_s.to_proc
#=> #<Proc:0x000055e77c191c98(&:to_s)>
a.call(13)
#=> "13"
a.class
#=> Proc

Hence :

call_my_block DateTime.now , &:to_s
# => "2021-09-05T12:06:00+02:00" 
[1,DateTime.now,3].map { |val| call_my_block(val,&:to_s) }
#=> ["1", "2021-09-05T12:21:54+02:00", "3"]
[1,DateTime.now,3].map(&:to_s)
["1", "2021-09-05T12:23:22+02:00", "3"]

Note ::

• A function/methods has parameters.
• When called the function is given arguments

In other terms, an argument is the value of a parameter.

Yet another online store framework in ruby

A collection of awesome Ruby gems, tools, frameworks and software.
Excellent website to know what's updated, followed etc.

#lotr.txt

Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.

readline accepts chomp flag

IO.readlines('lotr.txt', chomp: true)
#=> ["Three Rings for the Elven-kings under the sky,", "Seven for the Dwarf-lords in their halls of stone,", "Nine for Mortal Men doomed to die,", "One for the Dark Lord on his dark throne", "In the Land of Mordor where the Shadows lie."]

(example from big binaryblog)

Easy enough API to encrypt/decrypt.

(this snippet was tested with ruby 2.3)

RUBY helps a lot to write DRY code.
This feature is both great and very disturbing.

ruby on Rails, for example, is full of meta-programming.
That's how the rails "magic" happens.
Let's point out it's not magicall, and pretty simple to explain.

NB : This snippet requires some basic understanding of Object Oriented Programming.
I tried to take baby steps to explain it.
It should be very easy to understand.

Meta-programming, what is it ?

Let's assume we play with different living-dead species : Zombies and Vampires, Werevamps. Vampires have appetite for blood, whereas Zombies have appetite for brains, and Werevamps crave for blood and/or flesh.

We would like to be able to define a "macro" that let's us define what a class has appetite for, so we could write :

class Zombie < LivingDead
    has_appetite_for :brains
end

class Vampire < LivingDead
    has_appetite_for :blood
end

class Werevamp < LivingDead
    has_appetite_for :blood
    has_appetite_for :flesh
end

bob = Werevamp.new

bob.regime 
#=> [:blood, :flesh]

bob.hunt_blood
#=> "bob is hunting for blood"

bob.hunt_flesh
#=> "bob is hunting for flesh"

The "regime, " methods exists just because Werevamp is derived from LivingDead.
But how do we make that happening ?
The answer is "Meta-programming", also known as "macro".

This is precisely what rails classes are doing beind the hood. It's no magic.
For instance, your has_many :persons in your Company model gives you methods like Company.first.persons wich returns a collection of Person objects. Let's see how this is done, step by step

Monkey patching an object

We know how to monkey patch an object :

fred = "Zombie"
#=> "Zombie"

fred.class
#=> String

def fred.has_appetite_for
"brains"
end  
#=> :has_appetite_for

fred.has_appetite_for
#=> "brains"

We monkey patched the fred object.
It now has a new method called :has_appetite_for

fred is an object. It's a simple String.
Since a class is an object of class Class, we could do the same on the class itself.

Patching a class

class Zombie
end  
#=> nil

Zombie.class
#=> Class

my_zombie_classs = Zombie
#=> Zombie

my_zombie_class.class
#=> Class 

def my_zombie_class.has_appetite_for
     "brain"
end
#=> :has_appetite_for

Zombie.has_appetite_for
#=> "brain"

Pushing it into the class

We could put that the class itself.
Let's do that with the Vampire class

class Vampire
    def self.has_appetite_for
        "blood"
    end

    self.has_appetite_for
end
#=> "blood"

Vampire.has_appetite_for
#=> "blood"

Within the class definition, self refers to the Vampire class itself. Therefore, we could replace self with Vampire in the above example, it would do the same thing.

Now we would like to have a method called "has_appetite_for" that gets the food as an argument. Let's assume we have a new kind of living-dead called "Werevamp". A Werevamp has taste for either blood or flesh.

class Werevamp

    def self.has_appetite_for(food) 
        puts "#{self} has appetite for #{food}"
    end

    has_appetite_for :flesh
    has_appetite_for :blood
end

#=> "Werevamp has appetite for flesh"
#=> "Werevamp has appetite for blood"

bob = Werevamp.new
#=> "Werevamp has appetite for flesh"
#=> "Werevamp has appetite for blood"

If we remove the "self" call, ruby assumes that has_appetite_for is called on self

One last step : define a method within our method : to do that we use
define_method

class Werevamp

  def self.has_appetite_for(name) 
    puts "#{self} has appetite for #{name}"
    define_method("hunts_#{name}") do
      puts "A #{self.class} is now hunting for #{name}"
    end
  end

  has_appetite_for :flesh
  has_appetite_for :blood
end

#=> "Werevamp has appetite for flesh"
#=> "Werevamp has appetite for blood"
#=> => :hunts_blood

bob = Werevamp.new
#=> => #<Werevamp:0x00000001e244c8>

bob.hunts_blood
#=> A Werevamp is now hunting for blood
#=> =>nil               
#   reminder : puts returns nil

Pushing it on a parent class

Now we have everything we need to push the behavior a parent class.

class LivingDead
  attr :name, :food    # this too is meta-programming, by the way.  
  def initialize(name)
    @name = name
  end

  def self.has_appetite_for(food_name)
    puts "#{name} has appetite for #{food_name}"
    define_method("hunts_#{food_name}") do
      puts "#{self.name} is hunding for #{food_name}"
    end
  end

end

class Zombie < LivingDead
  has_appetite_for :brain
end

john = Zombie.new("J")
#=> => #<Zombie:0x00000002ad8610 @name="J">

john.hunts_brain
#=> J is hunting for brain
#=> => [:brain]

Important note :

One does NEED to understand the meaning of self here.

When ruby executes code, the self variable is contextual.

Wich means that in the class definition, self refers to the class itself.

In a class definition, self.class is a Class.

While when the code is being executed on the instance, self refers to the instance.

Let's push that to a module

Now we can create a LivingDead module.
Let's add a feature : we want to keep track of who eats what.

module LivingDead
  attr :regime
  @regime = a = Hash.new{ |hash, key| hash[key] = [] }

  def self.add_to_regime name, sender
    @regime["#{sender}"] << name
  end

  def self.get_regime sender
    @regime["#{sender}"]
  end

  private
  def self.regimes
    @regimes
  end

  public
  class Base
    include LivingDead

    attr :name; :regime

    def initialize(name)
      @name = name
    end

    def self.has_appetite_for(food_name)

      puts "#{name} has appetite for #{food_name}"
      # send :add_to_regime, food_name
      LivingDead::add_to_regime food_name, self

      define_method("hunts_#{food_name}") do
        puts "#{name} is now hunting for #{food_name}"
      end

      define_method (:get_regime) do
        LivingDead::get_regime "#{self.class}"
      end
    end

    def regimes
      LivingDead::regime
    end

  end
end

class Zombie < LivingDead::Base
  has_appetite_for :brain
end

class Vampire < LivingDead::Base
  has_appetite_for :blood
end

class Werevamp < LivingDead::Base
  has_appetite_for :flesh
  has_appetite_for :blood
end

john = Zombie.new("John")
bob = Vampire.new("Bob")
jenny = Werevamp.new("Jenny")

john.get_regime
#=> => [:brain]

bob.get_regime
#=> => [:blood]
jenny.get_regime
#=> => [:flesh, :blood]

john.hunts_brain

bob.hunts_blood
jenny.hunts_flesh

include LivingDead
LivingDead::regime
#=> => {"Zombie"=>[:brain], "Vampire"=>[:blood], "Werevamp"=>[:flesh, :blood]}

jenny.regimes
#=> => {"Zombie"=>[:brain], "Vampire"=>[:blood], "Werevamp"=>[:flesh, :blood]}

LivingDead::regimes
#=> => nil   because private !

Important note :
See how the "self" is behaving. When it's interpreted as a code from the class, it's the class. When it's interpreted from within the object, it's the object name.

I included a private sample so we can also see here that it does work as expected.

A good example of the above note :

     define_method (:get_regime) do
      LivingDead::get_regime "#{self.class}"
     end   

We have to consider here that the "self" will be interpreted WITHIN the object.
Therefore, the self.class is now being used.

require 'forwardable'

class ObjectFowardingCallsToThing
  def initialize(thing = [])
    @thing = thing
  end

  extend Forwardable
  def_delegators :@thing, :join, :<<

end

x = ObjectFowardingCallsToThing.new([1,2,3])

x.join
# => "123" 
x << 4
x.join
# => "1234"

the def_delegators :@thing, :join, :<< means that calling #join or #<< on the Object will forward the call to the @thing object.

example : where is #render ?

def index
  p method(:render).source_location
  render params[:id]
end

then curl http://localhost:3000/users/xxxx (or wherever your index is) and check your server output :

Processing by UsersController#show as */*
  Parameters: {"id"=>"xxxx"}
["/Users/aaron/git/rails/actionpack/lib/action_controller/metal/instrumentation.rb", 40]
Completed 500 Internal Server Error in 35ms (ActiveRecord: 0.0ms)

from : https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html

Modify your object, then return the object.

def update_params(params)
  params.tap {|p| p[:foo] = 'bar' }
end
# => returns the params object

# starts_with_consonant?(s)
# takes a string and returns true if it starts with a consonant and false otherwise. 
# (For our purposes, a consonant is any letter other than A, E, I, O, U.) 
# NOTE: be sure it works for both upper and lower case and for nonletters! 
def starts_with_consonant?(s)
  raise "#{__method__} : argument must be a String.\n #{s} is #{s.class}." unless s.is_a?(String)
  !((s =~ /\A[A-Z&&[^AEIOU]]/i) == nil) 
end