DEV Community: M Bellucci

Transplanting Git Branches

M Bellucci — Sat, 16 Dec 2023 14:08:57 +0000

Surely in your life as a developer you have come to this situation. You've made changes to your branch then pushed, and your github branch shows a series of undesired "shared" commits.

It could be multiples causes to this problem but today we will focus on its solution.

quick-question: How do you often solve this problem?
(leave your comments 🙏)

Well, I used to solve this problem in one of these two ways:
1) Rebase interactive
2) New-Branch + cherry-pick

Any of those two process take between 5 and 15 minutes to complete depending on the number of commits and feels a bit tedious.

That was until get to know the --onto option of git rebase and I managed to do this task in 30 seconds with a single command 😎

This option allows you to cut a series of consecutive commits and paste them on top of the target branch.
The documentation in man git-rebase refers to this process as transplant a branch and this is the example shown there.

Where it indicates that initially topic depended on functionality introduced in next but then next was merged to master so we can now transplant topic on top of master

That can be done with this simple command:

For the case presented in the first image we can see that we want to put schexp-e2e-2 on top of schexp-e2e but we only want from 576c19ccd to 8812f12b3b (commits starting with 'test:' or 'fix:')

The command for applying this transplant would be:

$> git rebase —onto schexp-e2e 576c19ccd^ 812f12b3b

Which would result in:

It is straightforward, but it has a caveat which is not clearly specified in the documentation.
If you want to include the initial commit (second argument) into the result, then you need to add ^ at the end because the command starts pruning from its child. So if we want to include foo commit we need to indicate foo^ which means parent of foo

Hope you find this useful, thanks for reading!
If you want to know more about me, visit my personal site or drop me an email, don't hesitate to reach out.
Happy coding!

Avoid nil propagation

M Bellucci — Sun, 30 May 2021 13:46:30 +0000

Introduction

Nil causes hard-to-track bugs and particularly represents a big problem in ruby because ruby returns nil in many cases.

irb(main):001:0> [][1]                                            
=> nil                                                            
irb(main):002:0> {}[1]                                            
=> nil

The fact that nil is Falsy makes us love😍 it.

if (user.latest_post) do
  post = user.latest_post
end

try and &. give us syntactic sugar to hide this conditional.

post = user.try(:latest_post)

but all these options present the same problem.
When latest_post is nil, then it will flow out through our program, until eventually our program breaks.

...
post.title # => NoMethodError (undefined method `title' for nil:NilClass)

How often nil is introduced?

After checking our error tracking service I found that around 40% of the errors were related to undefined or nil (typescript + ruby).
So you can think that about 40% of the bugs could be avoided by handling this problem when programming.

Comparing costs

Cost of writing an extra test case:

30 minutes to 1 hour

Cost of finding and solving a bug (considering the find-solve-review-merge-deploy process):

from 5 hours to days 🤔 ???

Nil introduction examples

Nil can be introduced in many ways.

Here I list just a couple of them.

Missing environment configuration

config = YAML::load(File.read('config/database.yml'))
username = config["development"]["username"]
# username not configured yet would give us a nil

Handling optional data

uri = URI('https://jsonplaceholder.typicode.com/posts')
res = Net::HTTP.get_response(uri)
name = JSON.parse(res.body).dig(0, "data", "name")
# data is not in the response path so name will be nil

An Uninitialized variable

if condition
  user = {name: "John"}
end
...
puts user.name
# when the condition is `false` user will be nil

Missing return value for if, unless, empty methods.

# a programmer implements this function
def half(x)
  if x % 2 == 0
    x / 2
  end
end

 # suppose a that another programer doesn't read the implementation just uses the method
[1,2].map(&method(:half))
=> [nil, 1]

Lets pick another example and look closer

Using a method (from framework or library) that returns nil.
In this case, we mock the implementation for User.find_by with a hash.
(I always like to highlight the distinction between provider and consumer code)

##### PROVIDER CODE #####
class User
  attr_reader :name, :id

  def initialize(id, name)
    @id = id
    @name = name
  end

  def self.find_by(id:)
    { 1 => new(1, "Emma"), 2 => new(2, "James") }[id]
  end
end

class EmailSender
  def self.invite(user)
    UserInviterJob.perform_later!(user_id: user.id, name: user.name)
  end
end

class InvitationsController
  attr_reader :params

  def initialize(params:)
    @params = params
  end

  def create
    user = User.find_by(id: params[:person_id])
    EmailSender.invite(user)
  end
end

# Consumer Code
InvitationsController.new(params: { person_id: 3 }).create

The execution would cause:

Traceback (most recent call last):
        2: from example.rb:36:in `<main>'
        1: from example.rb:32:in `create'
example.rb:15:in `invite': undefined method `name' for nil:NilClass (NoMethodError)

The problem with this traceback is that it doesn't lead you to the point where the nil is introduced so you may be tempted to "solve the problem" by using a .try(:name) in line 15.

but what is the real problem that we want to solve here?
This is the real execution:

find_by returns nil
The controller passes nil to the email sender
The email sender is accessing an attribute on the person which is nil

The line that introduces the nil is not present in the traceback and this happens when the introduction of the nil is not local to the usage of it, resulting in hard-to-track bugs.

What can we do?

we can do either one of these:

Avoid the introduction of nil
Deal with nil effectively

Avoid the introduction of nil

Avoid using methods(or lang features) that can potentially return nil.

Avoid using [] for accessing hash or arrays.
In this case, accessing a hash using fetch would raise KeyError which would result in an easy-to-track bug.

irb(main):002:0> {1 => "Emma", 2 => "James" }.fetch(3)
Traceback (most recent call last):
        5: from /Users/delbetu/.rbenv/versions/2.7.2/bin/irb:23:in `<main>'
        4: from /Users/delbetu/.rbenv/versions/2.7.2/bin/irb:23:in `load'
        3: from /Users/delbetu/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `<top (required)>'
        2: from (irb):2
        1: from (irb):2:in `fetch'
KeyError (key not found: 3)

fetch can be used with arrays too.

irb(main):018:0> [1,2,3].fetch(0)
=> 1
irb(main):019:0> [1,2,3].fetch(3)
Traceback (most recent call last):
        5: from /Users/delbetu/.rbenv/versions/2.7.2/bin/irb:23:in `<main>'
        4: from /Users/delbetu/.rbenv/versions/2.7.2/bin/irb:23:in `load'
        3: from /Users/delbetu/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `<top (required)>'
        2: from (irb):19
        1: from (irb):19:in `fetch'
IndexError (index 3 outside of array bounds: -3...3)

fetch also provides you a fallback method

irb(main):021:0> [1,2,3].fetch(3) { |param| "No entries for #{param}" }
=> "No entries for 3"

In a similar way with Rails you should prefer find over find_by.

As a general rule bang methods usually raise errors too.

[1] pry(main)> User.find_by(id: 2)
  User Load (0.9ms)  SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 2], ["LIMIT", 1]]
=> nil
[2] pry(main)> User.find_by!(id: 2)
  User Load (0.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 2], ["LIMIT", 1]]
ActiveRecord::RecordNotFound: Couldn't find User
from /Users/delbetu/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/activerecord-6.1.3.1/lib/active_record/core.rb:384:in `find_by!'

Deal with nil effectively

Guard clause

    user = User.find_by(id: params[:person_id])
    return unless user
    EmailSender.invite(user)

Assertion

def assert(condition, message = "Error")
   raise StandardError, message unless condition
end

user = User.find_by(id: params[:person_id])
assert(!user.nil?, "User not found.")
EmailSender.invite(user)

Wrapping `find_by`

Note that find_by sometimes returns nil and sometimes returns a User.
In other words, sometimes returns something that doesn't complain to User API and sometimes it returns something that does complain to User API.

This is forcing the consumer to handle the nil case.

we can fix that by wrapping find_by and try to always return the same API.

Two possible wrapping techniques:

Arrify
Special Case Object

Arrify

This means wraping the result with an array.

If you wrap with an array you will always get an array.

First note that

irb(main):001:0> Array(nil)
=> []

So if we do

    users = Array(User.find_by(id: params[:person_id]))
    EmailSender.invite(users)

def EmailSender.invite(users)
  users.each do |user|
    # ... previous code ...
  end
end

When find_by returns nil, no failures happen. Instead, no emails are sent.

Wrap find_by with special-case-object.

The wrap method handle the special case (when find_by returns nil)

def Maybe(obj)
  if obj.nil?
        NullObject.new
    else
        obj
  end
end

def wrapped_find_by(id:)
  Maybe(find_by(id: id))
end

Before continuing remember this:

NullObject can respond to everything.

In other words, NullObject conforms to every API

class NullObject
  def nil?
    true
  end
  def present?
    false
  end
  def blank?
    true
  end
  def to_s
    ""
  end
  def method_missing(*args)
    self
  end
end

NullObject conforms to User API

NullObject.new.id.name.other_user_attr.nil?
=> true

Coming back to the strategy, how the execution goes now?

Email sender would receive a null object:

   user = User.find_by(id: params[:person_id])
   EmailSender.invite(user)

def EmailSender.invite(user)
  # enque job with null object
end

The job would try to send an email to "" empty string which probably causes an error in our smtp provider.
Causing a hard to track issue. So NullObject is not the best strategy for this case.

In A Nutshell

You must think and decide which strategy is the best the case.
This table will help you to make that decision.

Strategy	Behavior	Consequence
Use no-nil functionality (fetch,bang-mehods)	stop execution raises an error	If the error handler doesn't catch it It will produce an easy to track error
Provide Default values	executes with no error	executes happy path
Special Case Obj for nil (NullObject)	execution continues	may final user see empty value or execution fails when trying to use an empty value (hard to track error)
Arrify	execution continues	executes happy path
Guard clause	skip parts of the execution that doesn't make sense. execution finishes ok!	some parts of the process are skipped make sure that is correct
Assertion	stop execution raises an error	If the error handler doesn't catch it It will produce an easy to track error

Ruby Money & BigDecimal

M Bellucci — Fri, 28 May 2021 20:26:54 +0000

The problem

In my current job, we faced calculation errors when operating with float for Money.
After some investigation, we found this article

Our first approach was to find every usage of money attributes and parse them with BigDecimal.

This solution has some drawbacks. First, we would need to replace it in many places. Second, it doesn't prevent future developers to use float.

In order to overcome those issues, I wanted to enforce a validation over every money attribute.
Then if a future execution accidentally does money_attr = 233.0 (float) we could detect that error and report it.
After thinking for a moment I thought that would be preferable to do a conversion (float->BigDecimal) rather than raising an error.

So I'd like to write Ruby code to say: "hey if someone tries to assign a float to a money attribute then convert it to BigDecimal"

The Solution

In order to do that I came up with this solution:

module BigDecimalCheck
  def self.included(klass)
    klass.extend(ClassMethods)
  end

  module ClassMethods
    def enforce_big_decimal(*attrs)
      attrs.each do |attr|
        define_method :"#{attr}=" do |value|
          # try to convert argument to BigDecimal
          instance_variable_set(:"@#{attr}", BigDecimal(value.to_s))
        end
      end
    end
  end
end

class Rate
  attr_accessor :money

  include BigDecimalCheck
  enforce_big_decimal :money
end

With that code in place a consumer code would work like this

r = Rate.new
r.money = 33            # works
r.money = 33.0293       # works
r.money = "33"          # works
r.money = "33.0293"     # works
r.money = "no numeric"  # Argument Error

How this solution work?

self.included it is a hook that Ruby modules provide. It is called when the module is included and receives the class that included it.
klass.extend(ClassMethod) Let's say that klass = Foo, then this would be the same as doing:

class Foo
  extend ClassMethod
  # Now I'm able to call methods in ClassMethod form here
end

which will inject methods from ClassMethod into Foo object at class scope.

enforce_big_decimal

    def enforce_big_decimal(*attrs)
      attrs.each do |attr|
        define_method :"#{attr}=" do |value|
          # try to convert argument to BigDecimal
          instance_variable_set(:"@#{attr}", BigDecimal(value.to_s))
        end
      end
    end

If I call enforce_big_decimal :unit_price, total_price
It will define two methods:

def unit_price=(value)
  parsed_value = BigDecimal(value.to_s) # raise error if cannot parse
  instance_variable_set(:@unit_price, parsed_value)
end
def total_price=(value)
  parsed_value = BigDecimal(value.to_s) # raise error if cannot parse
  instance_variable_set(:@total_price, parsed_value)
end

Conslusion

I've shown an example of how to generalize the solution of a problem by using ruby meta-programming techniques.

I hope it can help you solve similar problems.

Feel free to ask questions or suggest improvements.

Thanks for reading!

Rails Dependent Destroy

M Bellucci — Sat, 10 Apr 2021 21:02:04 +0000

Dependent Options

Given:

class User < ApplicationRecord
  has_many :posts, dependent: XXXXXXX
end
class Post < ApplicationRecord
  belongs_to :user
end

Let's see what happens when using the existing dependent options.

destroy

irb(main):002:0> u.destroy                                                                                                                                                                            
  TRANSACTION (0.1ms)  begin transaction                                                                                                                                                              
  Post Load (1.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = ?  [["user_id", 1]]                                                                                                      
  Post Destroy (0.4ms)  DELETE FROM "posts" WHERE "posts"."id" = ?  [["id", 1]]                                                                                                                       
  Post Destroy (0.1ms)  DELETE FROM "posts" WHERE "posts"."id" = ?  [["id", 2]]                                                                                                                       
  User Destroy (0.1ms)  DELETE FROM "users" WHERE "users"."id" = ?  [["id", 1]]                                                                                                                       
  TRANSACTION (0.7ms)  commit transaction                                                                                                                                                             
=> #<User id: 1, name: "John", email: "some@email.com", created_at: "2021-04-10 13:39:08.099961000 +0000", updated_at: "2021-04-10 13:39:08.099961000 +0000">

delete_all

:delete => u.destroy will call u.posts.delete (callbacks no executed)

irb(main):002:0> u.destroy                                                                                                                                                                            
  TRANSACTION (0.1ms)  begin transaction                                                                                                                                                              
  Post Destroy (0.6ms)  DELETE FROM "posts" WHERE "posts"."user_id" = ?  [["user_id", 1]]                                                                                                             
  User Destroy (0.1ms)  DELETE FROM "users" WHERE "users"."id" = ?  [["id", 1]]                                                                                                                       
  TRANSACTION (1.0ms)  commit transaction                                                                                                                                                             
=> #<User id: 1, name: "John", email: "some@email.com", created_at: "2021-04-10 13:17:09.423794000 +0000", updated_at: "2021-04-10 13:17:09.423794000 +0000">

destroy_async

It is supposed to delete posts in an async job but for my case this was the behavior:

irb(main):002:0> u.destroy                                                                                                                                                                            
  TRANSACTION (0.1ms)  begin transaction                                                                                                                                                              
  Post Load (0.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = ?  [["user_id", 1]]                                                                                                      
  User Destroy (0.7ms)  DELETE FROM "users" WHERE "users"."id" = ?  [["id", 1]]                                                                                                                       
  TRANSACTION (0.5ms)  rollback transaction                                                                                                                                                           
Traceback (most recent call last):                                                                                                                                                                    
        1: from (irb):2                                                                                                                                                                               
ActiveRecord::InvalidForeignKey (SQLite3::ConstraintException: FOREIGN KEY constraint failed)

nullify

:nullify => user.destroy will try to user.posts.each { |p| p.user = nil } (callbacks no executed)
Will raise an error if column is not nullable

irb(main):002:0> u.destroy                                                                                                                                                                            
  TRANSACTION (0.1ms)  begin transaction                                                                                                                                                              
  Post Update All (0.6ms)  UPDATE "posts" SET "user_id" = ? WHERE "posts"."user_id" = ?  [["user_id", nil], ["user_id", 1]]                                                                           
  TRANSACTION (0.1ms)  rollback transaction                                                                                                                                                           
Traceback (most recent call last):                                                                                                                                                                    
        1: from (irb):2                                                                                                                                                                               
ActiveRecord::NotNullViolation (SQLite3::ConstraintException: NOT NULL constraint failed: posts.user_id)

restrict_with_exception

:restrict_with_exception => u.destroy will do raise ActiveRecord::DeleteRestrictionError if u.posts.any?

irb(main):002:0> u.destroy                                                                                                                                                                            
  TRANSACTION (0.1ms)  begin transaction                                                                                                                                                              
  Post Exists? (0.1ms)  SELECT 1 AS one FROM "posts" WHERE "posts"."user_id" = ? LIMIT ?  [["user_id", 1], ["LIMIT", 1]]                                                                              
  TRANSACTION (0.0ms)  rollback transaction                                                                                                                                                           
Traceback (most recent call last):                                                                                                                                                                    
        1: from (irb):2                                                                                                                                                                               
ActiveRecord::DeleteRestrictionError (Cannot delete record because of dependent posts)

:destroy => a.destroy will call a.bs.destroy_all

restrict_with_error

:restrict_with_error => causes an error to be added to the owner if there is an associated object

irb(main):002:0> u.destroy                                                                                                                                                                            
  TRANSACTION (0.1ms)  begin transaction                                                                                                                                                              
  Post Exists? (0.1ms)  SELECT 1 AS one FROM "posts" WHERE "posts"."user_id" = ? LIMIT ?  [["user_id", 1], ["LIMIT", 1]]                                                                              
  TRANSACTION (0.1ms)  rollback transaction                                                                                                                                                           
=> false                                                                                                                                                                                              
irb(main):003:0> u.errors                                                                                                                                                                             
=> #<ActiveModel::Errors:0x00007fc2b209d428 @base=#<User id: 1, name: "John", email: "some@email.com", created_at: "2021-04-10 13:17:09.423794000 +0000", updated_at: "2021-04-10 13:17:09.423794000 +
0000">, @errors=[#<ActiveModel::Error attribute=base, type=restrict_dependent_destroy.has_many, options={:record=>"posts"}>]>

Join vs includes vs eager load vs preload

M Bellucci — Fri, 02 Apr 2021 14:22:12 +0000

Intro

Per rails guides

Eager loading is the mechanism for loading the associated records of the objects returned by Model.find using as few queries as possible.

This is the API that rails give you to avoid N + 1 queries.

includes
joins
preload
eager_load

Reference

	SQL contains join	Load associated record in memory	Performs two queries
joins	yes (inner join)	no	no
preload	no	yes	yes
includes	yes (left join)	yes	sometimes
eager load	yes (left join)	yes	no

Joins

Only affects the SQL query
doesn’t load related data into memory

pry(main)> u = User.joins(:alerts).first
  User Load (1.4ms)  SELECT "users".* FROM "users" INNER JOIN "alerts" ON "alerts"."user_id" = "users"."id" ORDER BY "users"."id" ASC LIMIT $1  [["LIMIT", 1]]
...
pry(main)> u.alerts
  Alert Load (0.6ms)  SELECT "alerts".* FROM "alerts" WHERE "alerts"."user_id" = $1  [["user_id", 2]]
...

Preload

Load associated data into memory
User.preload(:posts) executes two queries

pry(main)> u = User.preload(:alerts).first
  User Load (0.4ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT $1  [["LIMIT", 1]]
  Alert Load (0.3ms)  SELECT "alerts".* FROM "alerts" WHERE "alerts"."user_id" = $1  [["user_id", 1]]
=> #<User id: 1, email: ...
pry(main)> u.alerts
=> []

Includes

Performs outer left join and store the associated result in memory.
Sometimes generate one query and sometimes generates 2 queries.
If you want to force to use a single query you can add .references

pry(main)> u = User.includes(:alerts).first
  User Load (0.4ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT $1  [["LIMIT", 1]]
  Alert Load (0.2ms)  SELECT "alerts".* FROM "alerts" WHERE "alerts"."user_id" = $1  [["user_id", 1]]
=> #<User id: 1, email:...
pry(main)> u.alerts
=> []


pry(main)> users = User.includes(:alerts).references(:alerts)
  SQL (12.7ms)  SELECT "users"."id" AS t0_r0, t1_r1, "alerts"."user_id" AS t1_r2, "alerts"."date" AS t1_r3,... FROM "users" LEFT OUTER JOIN "alerts" ON "alerts"."user_id" = "users"."id"
=> [#<User id: 2, ...
pry(main)> users.first.alerts
=> [#<Alert:0x00007fc279e76128
  id: 1,
...

Eager Load

Load data in memory
Performs SQL join
Forces to use a single query
Some times takes more time than two queries

pry(main)> users = User.eager_load(:alerts)
  SQL (14.0ms)  SELECT "users"."id" AS t0_r0, ... FROM "users" LEFT OUTER JOIN "alerts" ON "alerts"."user_id" = "users"."id"
=> [#<User id: 2, ...
pry(main)> users.first.alerts
=> [#<Alert:0x00007fc269b87d78
  id: 1,
  ...

what an engineering team does ?

M Bellucci — Fri, 13 Mar 2020 01:56:04 +0000

Hi everyone I’d like to hear personal opinions about what are the main responsibilities and problems that engineering teams usually face.

Hope your comments, thanks!

Choosing a Storage Strategy

M Bellucci — Tue, 25 Feb 2020 15:38:28 +0000

Intro

Technical decisions are all about trade-offs.
This post exposes some information that can be used as a guide when deciding which storage strategy is more convenient for each case.

Storage Options

In-memory
File-based
Norelational
- Redis
- Mongo
Relational
- Postgres
- Mysql

Decisions Factors

What data is being stored?
Is data constrained to meet a complex structure?
How quickly needs to be read/write?
How much data exists?
How data need to be queried?
How long and reliably the data need to be stored?
Is data accessed by many connections concurrently?

Tradeoffs

RDBMS

Pros:

Long-term
Complex-structure-support
Powerful-search

Cons:

Bad performance
Require administration tasks
Require ORM

In memory

Pros:

Good performance

Cons:

Less reliable

File-based

Pros:

No-dbms-maintainance

Cons:

Concurrency issues

MySQL vs PG

MySQL easier setup
PG supports recursive queries
PG supports specialized datatypes
PG supports standard authentication methods (LDAP, GSSAPI)
PG supports asynchronous replication

Not only SQL DBs

Pros:

Scalability
Simplicity

Redis

Pros:

In memory => Quick data manipulation
Support data structures
Support publish/suscribe

Cons:

No long term access
Space limited

Supported data structures

Hash-tables
Lists
Key/value pairs
Sets

Support publish/subscribe

Channels as data delivery mechanism

Channel --has_many--> Subscriber  
Channel --has_many--> Publisher  

Subscribers can Listen to Events on a Channel  
Publishers can Emit Events on a Channel

Note that your code consumer can play both Subscriber and Publisher roles.

MongoDB

It is general-purpose.

Used for the same sorts of applications that you'd use an RDBMS for.

Cons:

No schema constraints

You can use libraries on top of MongoDB to provide validations, schema and searching capabilities.

Collection --has_many--> Document  
analogous to  
Table --has_many--> Row

Collection's API provides (insert, update, find, remove)

Case Study

An exercise for the reader.

Let's suppose that we are going to build an application that supports group-conversations such as WhatsApp.

What data is being stored?
Our server needs to save messages for at least one month.
The client application can save messages locally.

Is data constrained to meet a complex structure?
Not too complex

User <------ Message -----> Group
User <------ can_send ----> Group
Restriction: A user cannot send messages to groups that he doesn't belong

How quickly needs to be read/write?
We expect 3 million users sending messages at the same time.

Usability is negatively affected if the user receives the message with more than 2 seconds of delay.

How much data exists?
It must support millions of channels.

But we can assume that messages don't need to be saved forever.

We can delete the messages after a month.

Anyway, the participants will have their own copies of the messages locally.

How data needs to be queried?
We don't need sophisticated queries. Just fetching the messages for a channel that the user belongs to.

How long and reliably the data need to be stored?
Messages need to be stored for a month.

Is data accessed by many connections concurrently?
Messages can be concurrently read.

Concurrent writes over a message don't make sense.

With the previous scenario which storage strategy would you choose for client-app and server-app?

References

Node.js in Action

A simple SOLID object-oriented solution example.

M Bellucci — Mon, 20 Jan 2020 19:55:48 +0000

First of all, I write this because I want to improve my knowledge of SOLID principles, I don't completely understand them so I encourage you to make questions or have an opinion.

Let's start solving a problem.

Requirement

A text editor allows the user to select a layout for the document.
The default layout is one column, but he can choose two-columns.

Analysis

Under certain conditions, the format needs to be different.
This implies that the format is implemented in many different ways.

Design

How do we model this with objects?
We could create a Format class with #one-column and #two-columns methods.
If we do that, the Page object would need to have two versions.

class TwoColsPage
 def render
  ...
  @text = Format.one-column(@text)
  ...
 end
end

class SinglePage
  def render
    ...
    @text = Format.two-columns(@text)
    ...
  end
end

The main problem with this is that once you create a single page document you cannot change it to a two-column document.
Also if we need another format we're forced to create a new Page object for that format.

Another option is to rely on polymorphism(multiple classes implementing the same method)

OneColumnFormat#format
TwoColumnFormat#format

From the consumer perspective:

class Page
  def render
    ...
    @text = FormatterFactory.create(with: :two_columns).format(@text)
    ...
  end
end

class FormatterFactory
  # Returns objects that implement the implicit Formatter interface
  # That is, objects that respond_to :format method
  def self.create(with:)
    case with
    when :one_column
      OneColumnFormatter.new
    when :two_column
      TwoColumnFormatter.new
    end
  end
end

Open-Close

It is open to support new formats by adding new formatters without modifying code.

Single Responsibility

It does respect SRP, every object has a single responsibility.

Page --> returns the resulting text after by applying a set of transformations
FormatterFactory --> creates the requested formatters
OneColumnFormatter --> applies the format strategy for one-column text
TwoColumnFormatter --> applies the format strategy for two-column text

Interface Segregation

ISP would mean that the consumer object doesn't get useless methods. The Page (consumer) receives only one method format which he uses.

Liskov Substitution

In this case LSP means that objects returned by FactoryFormatter all met the same interface.
If we call FactoryFormatter.create(:unknown_format) it returns nil.
does nil meet the formatter interface?
does nil respond to format?
NO!
how can we fix that?

class FormatterFactory
  def self.create(with:)
    case with
    when :one_column
      OneColumnFormatter.new
    when :two_column
      TwoColumnFormatter.new
    else
      NullFormatter.new
    end
  end

  class NullFormatter
    def format(text)
      text
    end
  end
end

Why doing that?
If we return nil for some cases, then the consumer would need to ask for the answer.

formatter = FormatterFactory.create(with: format)
if formatter.nil?
  # we're not able to format the text
  Logger.error("Formatter failed creating formatter with format #{format}")
else
  @text = formatter.format(@text)
end

Let's suppose that the execution returns a NullFormatter.

formatter = FormatterFactory.create(with: format)
@text = formatter.format(@text) # returns the same text it was before

In that case instead of handling a failure or getting a No method :format for nil class
The failure is avoided and the user gets the text with no format.

Dependency Inversion

DIP Depends on abstractions, not concretions. Well, I think that Page depends on objects that implement #format so I think that "something that implements format" is the abstraction.

Something that confuses me is that this principle is also called Dependency Injection, in this scenario we could adapt the code to inject the formatter to the page.

Page.new(format: FormattersFactory.create(:two-columns))

Doing that Page wouldn't depend anymore on FormattersFactory, but we are moving the dependency to the consumer of Page (a previous step in the call stack).

I suppose that this is trying to organize the code in a way were all the creations are at the top level in the call-stack.
why doing that?

If you reached this point, thanks for reading hope your comments!

How to become a more valuable developer?

M Bellucci — Fri, 17 Jan 2020 19:50:18 +0000

I've been rethinking about my career path, I'm setting goals for this year and becoming a great software engineer doesn't seem like a well-defined goal.
So I thought that I would need to start investigating what are the skills that are most valuable for my employer (startups or big companies). So I can get a plan for reaching those skills.

What do you think?

what are the best actions that a Software Engineer can do in order to provide great value to its project?

Dealing with untestable code

M Bellucci — Tue, 14 Jan 2020 20:51:33 +0000

If I ask you to write a test for this function:

def sum(*nums)
  nums.inject(:+)
end

your answer would be immediate

describe '#sum' do
 it { expect(sum(1,2,3,4)).to eq(10) }
end

But what happens when I ask you to write a test for this code:

#### Print a rand number every three seconds ####
while sleep(3) do
  puts rand(10)
end

Stop for a moment and try to write a test for it.

You may face these difficulties:

1) This code never ends (the test will never end)
2) There are no inputs (how do I think of different cases?)
3) There are no outputs (I should assert against what?)
4) How do we execute this code?

For each of these points I would say:

1) The test must make it finish
2) False, we need to recognize them
3) False, we need to recognize them
4) We can wrap the code into a function

Generalizing our understanding of input/output

Input: Any data that can affect the result of the execution.

Read from database
Get data from an external source (api-call)
Return value from a collaborator (Time.now, File.read, I18n.locale)
Parameters
Shared variables (inside an object could be the instance variables)

Output:

Return value
Call collaborator
Side effects
- Http call
- Write to a Database
- Shared variables mutated
- Write to a file
- Internal state mutation

Recognizing input/output

Outputs:
In the first example, the output is a return value.
In the second example, the output is a call to a collaborator self.puts.

Inputs:
In the first example, the input values are the parameters.
In the second example, the input values come from a call to a collaborator self.sleep(3) and self.rand(10).

In the first example, the input values are passed by parameter by the caller while in the second example, the input values are gathered by the code itself.

So in order to state multiple inputs' combinations, we need to mock the input gathering part of the code.

def execute
  while sleep(3) do
    puts rand(10)
  end
end

require 'rspec/autorun'

describe '#execute' do
  it 'prints a random number' do
    # Pending: Simulate input gathering
    execute
    # checking the output
    expect(self).to have_received(:puts)
  end
end

How can we simulate the input-gathering part?

def execute
  while sleep(3) do
    puts rand(10)
  end
end

require 'rspec/autorun'

describe '#execute' do
  it 'prints a random number' do
    allow(self).to receive(:sleep).and_return(true, true, false)
    rand1, rand2 = 10, 20
    allow(self).to receive(:rand).and_return(rand1, rand2)

    execute

    expect(self).to have_received(:puts).with(rand1).ordered
    expect(self).to have_received(:puts).with(rand2).ordered
  end
end

Leason learned

Why the second case wasn't trivial to test?
it is because input/output is not easy to recognize.
Would it be easier to write a test if we make it obvious by passing them as parameters?

Think now, how would you test this code?:

def execute(loop_condition, next_number, print_callback)
  while loop_condition.() do
    print_callback.(next_number.())
  end
end

execute(->{sleep(3)}, ->{rand(10)}, ->(x){puts(x)})

What do you think, is it easier to test?


require 'rspec/autorun'

describe '#execute' do
  it 'prints a random number' do
    condition = double; allow(condition).to receive(:call).and_return(true, false)
    next_number = double(call: 1234)
    print = double(call: nil)

    execute(condition, next_number, print)

    expect(print).to have_received(:call).with(1234)
  end
end

Isolating side effects into collaborator objects

Instead of isolating side effects behind Procs let's use Objects which will act as collaborators to the execute method.

  interval = Class.new { def wait; sleep(3); end  }.new
  numbers_stream = Class.new { def next; rand(10); end  }.new
  screen = Class.new { def print(n); puts(n); end }.new

  def execute(interval, numbers_stream, screen)
    while interval.wait do
      screen.print(numbers_stream.next)
    end
  end

  require 'rspec/autorun'

  describe '#execute' do
    it 'prints a random number' do
      interval = double
      allow(interval).to receive(:wait).and_return(true, true, false)

      numbers = double
      n1, n2 = 10, 20
      allow(numbers).to receive(:next).and_return(n1, n2)

      screen = double('screen', print: nil)
      execute(interval, numbers, screen)

      expect(screen).to have_received(:print).with(n1).ordered
      expect(screen).to have_received(:print).with(n2).ordered
    end
  end

Ruby Bit Manipulation

M Bellucci — Wed, 18 Dec 2019 23:06:24 +0000

Some days ago as part of a recruiting process, I faced a code-challenge on Devskiller.
One of the challenges requires using an integer to represents the Groups that a User belongs to.
For example 101 means that the user belongs to Group0 and Group2 but not to Group1.

7 years ago I probably would pass this challenge but since this challenge is assessing the most underused feature of the language for a web-developer and it is time-constrained, I didn't pass :'( .

So if you want to succeed on this kind of challenges make sure you can unerstand this code:

# operators Description
# &   AND
# |   OR
# ^   XOR
# ~   NOT
# <<  left shift
# >>  right shift

# Calculating the binary version of the number (.to_s(2) doesn't work for negated values ~x)
def binary_string(number)
  31.downto(0).reduce('') {|result, index| result += number[index].to_s }
end
alias :bs :binary_string

# returns the value of the bit at the position index
# index 0 is the last bit
def get_bit(number, index)
  # since Ruby is awesome this also could be implemented as number[index]

  ith_one = 1 << index       # 0000000000100
  ith_bit = number & ith_one # 1101101101X01 & 0000000000100 => 0000000000X00
  ith_bit >> index           # 000000000000X
end

# puts a 1 in the index position of number starting from right to left
# doesn't change its parameter instead returns a new number
# index 0 is the less significant bit
def set_bit(number, index)
  ith_one = 1 << index # 00000000010000000
  number | ith_one
end

# puts a 0 in the index position of number starting on 0 from right to left
# index 0 is the less significant bit
def clear_bit(number, index)
  mask = ~(1 << index)
  number & mask
end

# param value must be 0 or 1
def update_bit(number, index, value)
  mask = ~(1 << index)
  (number & mask) | (value << i)
end

x = 5
zeroes = 0 # 000000000000000000000000000000
ones = ~0 # 111111111111111111111111111111

########################## XOR ##########################
p "#{ x ^ zeroes } == #{ x }"
p "#{ bs(x ^ ones) } == #{bs(~x)}" # using bs because to_s prints a negative binary
p "#{ x ^ x } == #{0}"

########################## OR ##########################
p "#{ x | zeroes } == #{ x }"
p "#{ x | ones } == #{ones}"
p "#{ x | x } == #{x}"

########################## AND ##########################
p "#{ x & zeroes } == #{ zeroes }"
p "#{ x & ones } == #{x}"
p "#{ x & x } == #{x}"

# Convert into array
0b01010101.to_s(2).split('')
# => ["1", "0", "1", "0", "1", "0", "1"]


################################## Sample Problem #################################################
# Insertion:
#   You are given two 32-bit numbers, N and M, and two bit positions, i and j.
#   Write a method to insert M into N such that M starts at bit j and ends at bit i.
#   You can assume that the bits j through i have enough space to fit all of M.
#
#   That is, if M = 10011, you can assume that there are at least 5 bits between j and i.
#   You would not, for example, have j = 3 and i = 2, because M could not fully fit between bit 3 and bit 2.
#
# EXAMPLE
# Input:
#   N = 10000000000, M = 10011, i = 2, j = 6
# Output:
#   N = 10001001100
###################################################################################################

def merge_bits_at(n, m, i, j)
  # m = M4 M3 M2 M1 M0
  # m1 = 0  0  M3 M2 M1 M0 0 0
  # n = N7 N6 N5 N4 N3 N2 N1 N0
  # n1 = N7 N6 0  0  0  0  N1 N0
  # n1 | m1 = N7 N6 M3  M2  M1  M0  N1 N0

  m1 = ( m << i )      # 0  0  M3 M2 M1 M0 0 0

  ones = ~0
  x1 = ones << i      # 1 1 1 1 1 1 0 0
  x2 = ~( ones << j ) # 0 0 1 1 1 1 1 1
  mask = x1 & x2      # 0 0 1 1 1 1 0 0
  mask = ~mask        # 1 1 0 0 0 0 1 1

  n1 = n & mask       # N7 N6 0  0  0  0  N1 N0

  m1 | n1
end


n, m, i, j = 0b10000000, 0b10011, 2, 6
puts "N = #{bs(n)}"
puts "M = #{bs(m)}"
puts "i = #{i}, j = #{j}"
puts 'Calling merge_bits_at(10000000, 10011, 2, 6)'
merged_bits = merge_bits_at(n, m, i, j)
puts "#{ bs(merged_bits) } should be 11001100"


#### Using string representation ####
( "101".to_i(2) & "110".to_i(2) ).to_s(2)

A TDD Example

M Bellucci — Wed, 26 Jun 2019 17:27:43 +0000

Introduction

As part of my TDD learning process I faced this problem and found hard to solve it following the TDD rules.
So I started this discussion --> https://dev.to/delbetu/solve-this-simple-problem-with-tdd-5e41

The TDD process I tried to follow at that point was:

Write a set of tests (input--->expected-output)
Pick the simplest test case to solve. (RED)(Write a failing spec)
Write the most naive code change that solves the current set of tests. (GREEN)
Check if DRY is needed (Refactor)
Go back to 2

The change that made me reach the solution

Instead of creating a predefined set of test I created a new test conveniently for each TDD cycle.

Write a test case conveniently for the current state of the algorithm (RED)
Write the most naive code change that solves the current set of tests. (GREEN)
DRY if needed (Refactor)
Go back to 1

In the example we will understand what conveniently means.

The Problem

flatten an array of arbitrarily nested arrays of integers into a flat array of integers. e.g. [[1,2,[3]],4] -> [1,2,3,4].

Before you continue reading try to solve it with TDD.

Hands on!

Cycle 1

def test_empty
  assert_equal [], flatten([])
end

def flatten(array_tree)
  []
end

Cycle 2

def test_no_subarray_one_element
  assert_equal [1], flatten([1])
end

def flatten(array_tree)
  array_tree
end

Cycle 3

The first and only element is an array.
At this point I decided decided to tackle the recursiveness behavior of the algorithm.
So I conveniently chose the next set of test cases.

def test_with_subarray_one_element
  assert_equal [1], flatten([[1]])
end

def flatten(array_tree)
 if array_tree[0].is_a?(Array)
   array_tree[0]
 else
   array_tree
 end
end

Cycle 4

def test_with_subarray_one_element
  assert_equal [1], flatten([[1]])
end

def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    array_tree[0]
  else
    array_tree
  end
end

Cycle 5

def test_with_subsubarray_one_element
  assert_equal [1], flatten([[[1]]])
end

def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    if array_tree[0][0].is_a?(Array)
      array_tree[0][0]
    else
      array_tree[0]
    end
  else
    array_tree
  end
end

Cycle 6

At this point you can recognize a recursive pattern.

def test_with_subsubarray_one_element
  assert_equal [1], flatten([[[[1]]]])
end

def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    if array_tree[0][0].is_a?(Array)
      if array_tree[0][0][0].is_a?(Array)
        array_tree[0][0][0]
      else
        array_tree[0][0]
      end
    else
      array_tree[0]
    end
  else
    array_tree
  end
end

# Refactor
def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    flatten(array_tree[0])
  else
    array_tree
  end
end

Cycle 7

At this point I realized of two things about the generalization of the algorithm.
(Left in comments)
These two points will make me pick the test for generalize that part of the behavior in future tests.

def test_when_first_and_second_are_subarray
  assert_equal [1,2], flatten([[1], [2]])
end

def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    result = flatten(array_tree[0]) # I will need this for each sub_array
    if array_tree[1].is_a?(Array)
      result = result + flatten(array_tree[1])
    end
    result
  else
    array_tree # This should return only the numbers not the subarrays
  end
end

Cycle 8

At this point I realized how to combine the recursive calls, so I decided to refactor.

def test_when_all_are_subarrays
  assert_equal [1, 2, 3], flatten([[1], [2], [3]])
end

def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    result = flatten(array_tree[0]) # call flatten for each sub_array and concatenate results
    if array_tree[1].is_a?(Array)
      result = result + flatten(array_tree[1])
      if array_tree[2].is_a?(Array)
        result = result + flatten(array_tree[2])
      end
    end

    result
  else
    array_tree # elements without subarrays
  end
end

# Refactor --> Generalize the ifs
def flatten(array_tree)
  if array_tree[0].is_a?(Array)
    sub_arrays = array_tree.select {|x| x.is_a?(Array)}
    sub_arrays.reduce([]) do |result, sub_array|
      result + flatten(sub_array)
    end
  else
    array_tree
  end
end

Cycle 9

Tackling one of the pending behaviors found in cycle 5.
The else branch should return only the numbers not the subarrays
If the first element of the input is a number but the second is a subarray then the else branch would fail.
So the next test could be:
[1, [2]] --> [1, 2]

def test_when_first_is_number_and_second_is_subarray
  assert_equal [1, 2], flatten([1, [2]])
end

def flatten(array_tree)
  result = array_tree.reject {|x| x.is_a?(Array)} # elements without subarrays
  sub_arrays = array_tree.select {|x| x.is_a?(Array)}
  result = result + sub_arrays.reduce([]) do |accumulator, sub_array|
    accumulator + flatten(sub_array)
  end
end

Cycle 10

At this point I think I found the generalized solution so the next test is a complicated case.

def test_complicated_case
  assert_same_elements [1, 2, 3, 4, 5, 6, 7, 8, 9, 0], flatten([[[1, 2, 3]], [4, [5, 6]], 7, [[[[8]], 9]], 0])
end

def flatten(array_tree)
  result = array_tree.reject {|x| x.is_a?(Array)} # elements without subarrays
  sub_arrays = array_tree.select {|x| x.is_a?(Array)}
  result = result + sub_arrays.reduce([]) do |accumulator, sub_array|
    accumulator + flatten(sub_array)
  end
end

private

def assert_same_elements(array1, array2)
  assert array1 - array2 == []
end

Thanks for reading,
Comments are welcome!

DEV Community: M Bellucci

Transplanting Git Branches

Avoid nil propagation

Introduction

How often nil is introduced?

Comparing costs

Nil introduction examples

Lets pick another example and look closer

What can we do?

Avoid the introduction of nil

Deal with nil effectively

Guard clause

Assertion

Wrapping find_by

Arrify

Wrap find_by with special-case-object.

In A Nutshell

Ruby Money & BigDecimal

The problem

The Solution

How this solution work?

Conslusion

Rails Dependent Destroy

Dependent Options

destroy

delete_all

destroy_async

nullify

restrict_with_exception

restrict_with_error

Join vs includes vs eager load vs preload

Intro

Reference

Joins

Preload

Includes

Eager Load

what an engineering team does ?

Choosing a Storage Strategy

Intro

Storage Options

Decisions Factors

Tradeoffs

RDBMS

In memory

File-based

MySQL vs PG

Not only SQL DBs

Redis

Support publish/subscribe

MongoDB

Case Study

References

A simple SOLID object-oriented solution example.

Requirement

Analysis

Design

Open-Close

Single Responsibility

Interface Segregation

Liskov Substitution

Dependency Inversion

How to become a more valuable developer?

what are the best actions that a Software Engineer can do in order to provide great value to its project?

Dealing with untestable code

Generalizing our understanding of input/output

Recognizing input/output

How can we simulate the input-gathering part?

Leason learned

Isolating side effects into collaborator objects

Ruby Bit Manipulation

A TDD Example

Introduction

The change that made me reach the solution

The Problem

Hands on!

Cycle 1

Cycle 2

Cycle 3

Cycle 4

Wrapping `find_by`