Forem: Subash

Rails default port

Subash — Sat, 13 May 2023 11:46:01 +0000

There might be cases where you need to utilize more than one port for an application in your local. For example web-server might be utilizing port 3000 and if you start rails engine by using the command rails server or rails s you will get an error Address already in use - bind(2) for "127.0.0.1" port 3000. So manually you need to specify rails to use a different port like rails s -p 3001

Actually there is a way you can specify the rails engine to use a specific port to use by default.

Just locate the rb file with the engine name under /config directory. In my case puma is the engine so lets open config/puma.rb.

The below line is responsible for using the port 3000 by default.

port ENV.fetch("PORT") { 3000 }

Replace the 3000 with port whichever you want to use. In my case it is 3001

port ENV.fetch("PORT") { 3001 }

That's it. Now start the server by default port 3001 will be used by rails.

Ruby Lambda VS Proc

Subash — Thu, 27 Apr 2023 16:07:10 +0000

Lambda and Proc - both are container for a block of code. Define a set of codes inside either of them and save them as a variable for later use.

Let's see the usage of both in detail

Lambda

A lambda is very similar to method, just the syntax varies. Below is the syntax for creation

test_lambda = -> { puts 'something'}

# lambda using arguments
test_lambda = -> (x) { x + 1}

Now we have defined a lambda and store in a variable test_lambda, we have to call it to use. There are multiple ways to call a lambda. Below is the list of ways

test_lambda.call
test_lambda.call()
test_lambda.()
test_lambda.[]
test_lambda.[]
test_lambda.===

I prefer .call() as it is more readable than others

If we call the defined lambda, the block of code is executed and result is displayed

test_lambda.call(5)
6
=> 6

As I stated earlier, lambda works very similar to methods if lambda is defined with args, the number of args should match during call, else it will raise an exception just like a regular method.

Also like a regular method a lambda will return normally to it's __callee__ rather than returning from a context

Example

def demo_lambda(num)
  test_lambda = -> (x) { return x + 1 }
  new_value = test_lambda.call(num)
  puts 'new value returned'
  new_value
end

Here the return of the test_lambda will return the value within the scope of the lambda (i.e returned value is stored in new_value) and will proceed with the execution of below lines

Proc

Procs are similar to lambda, but there are few differnces and the choice to use between Proc and Lambda depends on it

Proc creation uses different syntax

test_proc = Proc.new {|x| x+1 }

Calling Proc is similar to lambda. It can be called using .call(), .(), .[], .===

Proc doesn't care about the number of arguments passed. But if the argument is used for any kind of calculation or manipulation it will raise an error.

Example

p = Proc.new{|x| puts 'something'}
p.call()
=> "Something"

p = Proc.new{|x| x*2 }
p.call()
(irb):61:in `block in <main>': undefined method `*' for nil:NilClass (NoMethodError)

p = Proc.new{|x| x*2 }

#since there is a calculation based on the args passed NilClass error is thrown

One more major difference is proc will return from the current context. i.e if proc is inside an method, then calling return from proc is equivalent to returning from that method. Let's see an example

def demo_proc(num)
  test_proc = Proc.new{ |x| return x + 1 }
  new_value = test_proc.call(num)
  puts 'new value returned'
  new_value
end

demo_proc(5)

irb(main):008:0> demo_proc(5)
=> 6

In the above sample, the puts statement will not be printed. This is because the return in test_proc will return from the demo_proc itself.

Source: Proc Lambda

Ruby Benchmarking

Subash — Sun, 23 Apr 2023 05:30:55 +0000

Benchmarking is one of the crucial part of code, since it can help developers to identify and fix the performance issues thereby improving the execution speed of the application. That said will see how can we benchmark a given code

Requirements

benchmark - gem. Rails comes with this gem installed by default. There are some external gems which also serves the same purpose. In this article we will cover the benchmark gem

The usage is simple. Write scripts - load it in system-irb/rails-irb - execute and analyse

Lets benchmark below select and detect methods
launch irb or rails console

# declare an array of 1 to 100
arr = (1...1000)

def get_matching_first_element_using_select(arr)
  return arr.select{|num| num == 1}.first
end

def get_matching_first_element_using_detect(arr)
  return arr.detect{|num| num == 1}
end

It is obvious that detect is much more effecient than select. Lets confirm this with benchmark

Require the gem (if you are launching rails console requiring 'benchmark' is not needed as it is already loaded by default)

require 'benchmark'

Benchmark.measure{ get_matching_first_element_using_select(arr)}
=> 
#<Benchmark::Tms:0x00007fa96a532fd0                                        
 @cstime=0.0,                                                             
 @cutime=0.0,                                                             
 @label="",                                                               
 @real=0.00016800200000943732,                                            
 @stime=1.2999999999985246e-05,                                           
 @total=0.00017499999999998073,                                           
 @utime=0.00016199999999999548>

If you just want to see the actual time taken in microseconds use ms instead of measure.

Benchmark.ms{ get_matching_first_element_using_select(arr)}
=> 0.16017500001908047 #we will get this simplified clutter free output

This is fine but we need to do benchmark for 2 different methods separately. Is there any way to run both of them together and compare side by side. Yes there is

Benchmark.bm do |x|
  x.report("select: ") {100.times do; get_matching_first_element_using_select(arr); end}
  x.report("detect: ") {100.times do; get_matching_first_element_using_detect(arr); end} 
end

This will yeild the below output which is easy to compare

              user     system      total        real
select:   0.004269   0.000015   0.004284 (  0.004280)
detect:   0.000052   0.000003   0.000055 (  0.000055)

And the results are clear, Detect is faster than select since we are fetching the first element - which is like 78 times faster.

There are multiple ways to benchmark, this is just the basic. Read more at source

Rails console sandbox mode

Subash — Thu, 20 Apr 2023 02:38:16 +0000

rails c or rails console starts the irb session, where we can execute, test and confirm queries. It is one of the helpful feature for developers. However we need to use it with caution as it is capable of modifying records. Any accidental modification in staging or production data might lead to problem.

There is an option to avoid this. Rails comes with an inbuilt sandbox mode. When you start the console with --sanbox flag, we will see a message Any modifications you make will be rolled back on exit because the whole irb session starts within an ActiveRecord::Transaction, which is rolled back when you exit the session.

Here's a sample

But wait, There is a catch

In sandbox mode, database rows are fully locked, which means that it prevents your live production services from modifying them. If you are holding a record for too long, all the live transactions related to it have to wait till the lock is released or in some cases might mess up the updations.

Ruby - dig method

Subash — Wed, 19 Apr 2023 04:14:14 +0000

The dig method is a useful tool to dig through all the keys of a given hash (recursively) and returns the value. If the value for final key or the intermediate key is not found a nil value is returned

Let's say we have the given params

params = Hash.new
params[:user1] = {
  name: 'Alice',
  gender: 'F',
  age: '40',
  job_details: {
    company: 'XYZ'
  },
  contact_details: {
    Landline: '00000000',
    mobile: '0000001'
  }
}
params[:user2] = {
  name: 'Bob',
  gender: 'M',
  age: '40',
  job_details: {
    company: 'ABC'
  }
}

Now if we need the mobile number of all users, the following code will break because in case of Bob the contact_details hash is not available.

params.map{|key,value| value[:contact_details][:mobile]}

So we need to check if the key is available before diving into it. If there are more iterations then there would be more conditional checks. Luckily there is an alternative
We can use dig to fetch with single line of code as the dig handles the conditional checks internally. The code will look like this and it will work for both users

params.map{|key,value| value.dig(:contact_details, :mobile)}

which will give the following output

=> ["0000001", nil]

dig iterated through the given keys recursively, if any of the keys are not available it will break returning nil (as in case of Bob).

Note: In scenarios where an error should be raised when a key is not found, dig will not be helpful as it returns nil.

Source

Rails - annotate method

Subash — Sun, 16 Apr 2023 11:33:43 +0000

The `annotate` method

is used to add an SQL comment to queries generated from the relation. Here is an example

Bullet.includes(:user).
  find_by_id(params[:id])

The above query uses include to eager-load the user table. We can use annotate to add a sql comment to explain the same like

Bullet.includes(:user).
  annotate('Eager loading user table').
  find_by_id(params[:id])

That's it.

Now when you see the rails server logs, you can find the sql comment which was added in the query explanation.

Processing by BulletsController#show as HTML
  Parameters: {"id"=>"5"}
  Bullet Load (0.1ms)  SELECT "bullets".* FROM "bullets" WHERE 
"bullets"."id" = ? /* Eager loading user table */ LIMIT ?
  [["id", 5], ["LIMIT", 1]]
  ↳ app/controllers/bullets_controller.rb:73:in `set_bullet'
  User Load (0.1ms)  SELECT "users".* FROM "users" WHERE
 "users"."id" = ?  [["id", 2]]

Caution: Some escaping is performed, however untrusted user input should not be used.

Source-Code