Create your own Gem!-Part1

Hi All! today we are going to learn  how to create a gem from scratch!

STEP1: Choose a name for your gem and create an empty repository for the gem in GitHub.

Your Gem name must be unique so run a quick search in Github or Rubygems.org to check if the name has already been taken or use the following command:

$ gem list -r your_gem_name

*** REMOTE GEMS ***

If the gem name exists it would be returned as an output after you type the above command.

In this example, I have chosen my gem name to be ‘word_play’. You can find this in GitHub

STEP2: Inside your rails console, create the following folders and files for the gem you wish to create and follow the naming conventions, the below images shows  the required files/folders to be created for the gem ‘word_play’ :

General Layout of a Gemfile

General Layout of a Gemfile

Gemfile folders expanded

Gemfile folders expanded

Do not create the folders ‘doc’ and ‘word_play-0.0.1.gem’ file yet as I will explain more more about it later !

STEP3: The ‘lib’ folder and its contents

The source code of the gem would go into a ruby file which has the same name as the gem itself and is found under the ‘lib’ folder by convention.

word_play.rb

word_play_ruby_code

There is a another folder under the ‘lib’ folder, also with the same name as the gem and has a ruby file named ‘version.rb’ under it. It contains the version number of the gem embedded into it by the following ruby code:

module Mygem

VERSION = “0.0.1”

end

Every time we make any change in the gem, we should increment the gem’s version number before pushing it into rubygems.org or GitHub. The version  number of gem is of the form A.B.C , where A, B, C are non-negative integers. Remember the following rules while giving a version to the gem.

  • Increment in A.B.C for a backward incompatible changes to your public API, which is a major change.
  • Increment in A.B.C if new backward compatible functionality is introduced to the public API or if any public API functionality is deprecated, a minor change.
  • Increment in A.B.C for backward compatible bug fixes, a patch level change.

STEP4 The Gemspec file

The gemspec file consists of information about the gem. It contains details about the gem author, summary of its function, dependent gems, gem file path etc. It would be worthwhile to click the below image and learn more from the comments.

Gemspec file

Gemspec file

STEP5 Build and Install your gem

$ gem build word_play.gemspec

WARNING: no homepage specified
Successfully built RubyGem
Name: word_play
Version: 0.0.1
File: word_play-0.0.1.gem

$ gem install word_play-0.0.1.gem

Successfully installed word_play-0.0.1
1 gem installed

STEP6 Testing your gem

Testing your gem is very important. Your test cases should be under the ‘test’ folder or ‘spec’ folder as in my case. I have used rspec gem to test my code although one can use any gem for testing.

STEP7 Push your gem into GitHub or Rubygems.org

To push your gem into Rubygems.org, create an account in the website and in your rails console use the below command:

$ gem push word_play-0.0.1.gem

Enter your RubyGems.org credentials.
Don’t have an account yet? Create one at http://rubygems.org/sign_up
Email: sadicarnot@gmail.com
Password:
Pushing gem to https://rubygems.org…
Signed in.
Pushing gem to https://rubygems.org…
Successfully registered gem: word_play (0.0.1)

Use the following commands to push your gem into GitHub:

touch README.md  #(It is good to have a Readme file to explain how to use your gem)

git init

git add README.md

git commit -m “first commit”

git remote add origin git@github.com:Anu4ruby/your_gem.git

git push -u origin master

STEP 8: To Use your Gem, go to the ruby terminal and type the following commands.

$irb

require “word_play”
=> true

Word.is_anagram?(“scream”,”creams”)
The 2 words are anagram of each other
=> true

Word.is_palindrome?(“Madam”)
The word is a palindrome
=> true

STEP9 Delete your gem if you want!

first install the gemcutter gem and then use ‘gem yank’ command as below to remove your gem from rubygems.org:

$ gem install gemcutter

$ gem yank your_gem -v x.y.z (# you gem version number in x.y.z )

to remove your gem from GitHub, simply delete the gem repository.

That’s all for now. We now know how to create a basic gem and publish it. There are more features that can be added to a gem namely executable files, extensions and requiring more files into your gemfile. We will see about each of these in Part 2 of this blog.

Credits and References: I thank Stephen Ball and Ruby Gem Guides
who inspired me to write this blog.

Leave a comment

Filed under Ruby on Rails

Closures in Ruby – Part2

Blocks, Procs,  Lambdas and Methods come under the category of closures in Ruby. The concept of Closures is explained in detail at Part1 of this blog. In this we blog we are going to discuss in detail about Blocks, Procs, Lambdas and Methods.

Blocks & Procs

Blocks are chunks of code that can be passed to a method. This can be achieved in many ways. Try following the below sample codes to learn more.

class Maths

def initialize(val)

@val = yield(val)

p @val

end

def print

yield(@val)

end

end

num = Maths.new(10){|val| val = val * 10}

num.print{ |val| val = val * 20

p val}

Output:

100

2000

In all the method definitions inside the class ‘Maths’, the key word ‘yield’ means that it would accept any block of  code passed to it. When the object ‘num’ is created from the class Maths the ‘initialize’ method is invoked which accepts a parameter named ‘val’. This variable ‘val’ is then yielded to the block of code passed during the creation of the object “{|val| val = val * 10}”. The ‘val = 10’ is thus multiplied by 10 and the result ‘100’ in then stored in @val.

The print method once again yields this ‘@val’ to another block of code passed during the ‘print’ method call and gets multiplied by 20 and the result 2000 is printed as the result. Thus we can understand how blocks can be manipulated to perform different actions depending upon the requirement.

Now let us imaging that we want to perform the same actions on 5 more objects say num1, num2, num3, num4, num5. We should explicitly pass the blocks of code for each object as below:

num1 = Maths.new(10){|val| val = val * 10}

num1.print{ |val| val = val * 20

p val}

num2 = Maths.new(10){|val| val = val * 10}

num2.print{ |val| val = val * 20

p val}

etc..

Does this not make the code redundant?  The cost of coding will also be high. It would be great if we can store this block of code in a variable and pass the variable to each object to achieve the same results, right? This is where Procs come into picture. Look at the below code:

class Maths

def initialize(val,code)

@val = code.call(val)

end

def print(code)

code.call(@val)

end

end

mul = Proc.new {

|val| val = val * 10

p val

}

mul1 = Proc.new {

|val| val = val * 20

p val

}

num = Maths.new(10,mul)

num.print(mul1)

Output:

100

2000

The variable ‘mul’ and ‘mul1’ stores the block of code and is passed to the methods. This achieves the same result as the block. Also, if we want to perform the same operation of multiple objects we just have to use the proc appropriately. Example ‘num1 = Maths.new(20,mul) , num2 = Maths.new(29,mul)’ etc.

Interestingly, blocks are Proc objects! Look at the code below:

def methodnew(&block)

block.class

end

p methodnew{p “I am a block”}

Output:

Proc

Having learnt about blocks, it would be much easier to understand what Proc is and when should we use them. Procs are useful if we wish to execute a block of code multiple times.

Lambdas:

Let us look at the below example code to understand Lambdas:

class Maths

def initialize(val,code)

@val = code.call(val)

end

def print(code)

code.call(@val)

end

end

mul = lambda {

|val| val = val * 10

p val }

mul1 = lambda {

|val| val = val * 20

p val}

num = Maths.new(10,mul)

num.print(mul1)

Output:

100

2000

Lambdas are similar to Procs but the difference is, lambdas checks the number of arguements that is passed to it but a Proc does not check the number of arguements passed to it. For example

class Maths

def initialize(val,code)

@val = code.call(val)

end

end

mul = Proc.new {

|val,val1| val = val * 10

p val

p val1

}

mul1 = lambda {

|val, val1| val = val * 10

p val

p val1

}

num = Maths.new(10,mul)

num = Maths.new(10,mul1)

Output:

The output after calling the Proc:

100

nil

The output after calling Lambda:

example3.rb:29:in `block in <main>’: wrong number of arguments (1 for 2) (ArgumentError)

from example3.rb:11:in `call’

from example3.rb:11:in `initialize’

from example3.rb:35:in `new’

from example3.rb:35:in `<main>’

There is also one more difference between Procs and Lambdas.  Let us look at the below code:

class Maths

def initialize(val)

@val =val

end

def print(code)

code.call(@val)

return “return from method”

end

end

mul = Proc.new {

|val| val = val * 10

p val

return “return from Proc”

}

mul1 = lambda {

|val| val = val * 10

p val

return “return from Lambda”

}

num = Maths.new(10)

p num.print(mul1)

Output :

100

“return from method”

We see that Lambda continues code execution even after encountering return inside lambda.  Whereas Proc does not permit return commands when passed to a method and gives error as below:

p num.print(mul)

Output:

100

example3.rb:30:in `block in <main>’: unexpected return (LocalJumpError)

from example3.rb:17:in `call’

from example3.rb:17:in `print’

from example3.rb:45:in `<main>’

If you call a Proc directly inside a method without passing it as a parameter like the code below:

def method1

Proc.new{return “proc”}.call

return “from method1”

end

def method2

lambda{return “lambda”}.call

return “from method2”

end

p method1  #Output : proc

p method2 # Output: from method2

Lambda thus continues its execution even after encountering a return whereas Proc stop its execution after encountering first return.  When we expect out code to strictly check the number of arguments and continue program execution till the end we should use Lambdas else we should use Procs.

Methods:

‘Methods’ are another way of passing a block of code to a method and is similar to Lambdas. For example:

class Maths

def initialize(val,code)

@val = code.call(val)

end

def print(code)

code.call(@val)

end

end

def mul(val)

val = val * 10

p val

end

def mul1(val)

val = val * 20

p val

end

num = Maths.new(10,method(:mul))

num.print(method(:mul1))

Output:

100

2000

Thus we come to the conclusion of Closures in Ruby. I hope this blog was useful to you.

References:

1. Closure (computer science). (n.d.). , from http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Closure_(computer_science).html

2. Alan Skorkin : “http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/

3. Robert Sonsinski: “http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/

Leave a comment

Filed under Uncategorized

Closures in Ruby – Part1

Hello readers! welcome to my blog spot once again!

We all have come across Procs, Blocks, Lambdas and Methods in Ruby and have found them to be quite useful! but what are the differences between them? when to use each of them? In order to answer these questions we should first understand the concept of “Closures”. There are 2 parts in this blog: The first part explains about closures and the second part explains about Procs, Blocks and Lambdas in detail!

What are Closures ?

“In computer science, a closure is a first-class function with free variables that are bound in the lexical environment.”[1]

Let’s try to understand the terms used in the above definition! Firstly a closure is a first-class function. A first-class function is a function or a method that can be treated like an object and can be passed as a parameter to another method/function.

Secondly, because of their ability to be passed around like a parameter, closures retain the values of its local variables at the time of their creation and can access the values of the variables even when the closures are called out of the scope of the variables.

The following ruby code would be helpful to understand closures better:

# Add 2 strings

class Maths

def initialize(v1)

@v1 = v1

end

def sum(v2)

lambda { puts ” #{@v1}” + ” #{v2}”}

end

end

def call_closure(closure)

closure.call

end

num = Maths.new(“hi”)

var = num.sum(“hello”)

call_closure(var)

Output:

hi hello

In the above code, the method sum creates a closure using Lambdas. The parameter passed to this closure is ‘v2’ which is a local variable to the method ‘sum’. Now when the method sum is assigned to a variable ‘var’ as in the code “var = num.sum(“hello”) “, the method ‘sum’ returns the lambda and stores it into the variable var. Now this variable var is passed as a parameter to the method call_closure. This satisfies the first property of closures (first-class functions), the ability of a method to be passed like a parameter to another method. Inside the method call_closure the lambda is invoked and the value ‘v1’ and ‘v2’ is accessed even though they are out of scope in the method call_closure but within the lambda they are still alive. This satisfies the second property of retaining the values of the variables even though they are out of scope when the closure is called. In other words closures retain the knowledge of the variables in their lexical environment.

Not all programming languages support closures. In ruby closures are supported via Procs, Blocks and Lambdas. Programming languages implement closures in 2 ways:

  1. Closures create a copy of the variables when they are defined and are used where ever they are invoked.
  2. Closures keep a reference to the variables and access them where ever the closure is invoked.

Ruby uses the second method to retain the knowledge of its lexical environment. This would also mean that the values of these variables are susceptible to change inside the closure where ever it is passed. This can be both advantageous and disadvantageous. The advantage being: writing less code and following the DRY principle. The disadvantage being: These variables are not protected and can’t hold sensitive data and these variables are not eligible for garbage collection. Using too many of these variables might affect performance! Nevertheless closures are very handy and dynamic and can be very useful. The below ruby code would help us assess its pluses and minuses.

class Maths

def initialize(v1)

@v1 = v1

end

def square(closure)

p “The square of the number is: #{closure.call(@v1)}”

end

def change_square

lambda {

@v1 = @v1 + 1

p “The square of the changed number is: #{@v1**2}”

}

end

end

num = Maths.new(5)

num.square(lambda{|n| n**2} )

num.change_square.call

Output:

“The square of the number is: 25”

“The square of the changed number is: 36”

In the above code a closure is passed to the method ‘square’ to find the square of a number. The code can also be changed during the run time to perform other functions like finding the cube of the number or multiple of a number and so on. Thus closures are handy to execute any block of code, making the code highly flexible.

In Ruby closures keep a reference to the variables defined inside it as a result they are liable for change by other closures. For example in the above code, the method ‘change_square’ increments the value of @v1 and squares the result. The variable @v1 thus changes based on the code used inside the closure. Thus closures should be used with care. Now let’s look at the below code:

class Maths

def initialize(v1)

@v1 = v1

end

def multiple

lambda{

@v1 = @v1*2

p “The second multiple of the number is: #{@v1}”

}

end

end

num = Maths.new(5)

num.multiple.call

num.multiple.call

num.multiple.call

num.multiple.call

p “————–”

num1 = Maths.new(5)

num1.multiple.call

num1.multiple.call

Output:

“The second multiple of the number is: 10”

“The second multiple of the number is: 20”

“The second multiple of the number is: 40”

“The second multiple of the number is: 80”

“————–”

“The second multiple of the number is: 10”

“The second multiple of the number is: 20”

See how the same variable @v1 has been modified by closures called by 2 objects of the same class! Thus closures must be used with caution to avoid confusion and to protect data.

Hope you found this blog useful! Please feel free to share your comments. In the part-2 of this blog we will have a look at the four types of closures used in Ruby: The Procs, Blocks, Lambdas and methods. I thank Alan Skorkin and Robert Sosinski for inspiring me to write this blog

References:

1. Closure (computer science). (n.d.). , from http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Closure_(computer_science).html

2. Alan Skorkin : “http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/

3. Robert Sonsinski: “http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/

Leave a comment

Filed under Uncategorized

Ruby-Difference between Public, Private and Protected methods!-Part1

Hello RoR developers! Welcome to my blog spot!

This blog is about Access Control in Ruby with relevant code snippets and is very useful for beginners. Advanced programmers may go through this topic to brush up their basics.

What is Access Control and Why do we need it ?

In order to protect data variables/methods from manipulation by external classes, it has to made accessible or visible to chosen classes. Ruby has 3 types of visibility to protect methods/variables:  Public, Private and Protected. We will look at each one them in detail now.

Public: When a method is declared a public, it means that objects of any class have direct access to it. For example in the below code snippet.

class Account

attr_reader :final_balance, :balance

RI = 0.5

def initialize(balance)

  @balance = balance

  @final_balance = @balance + interest

  final_balance = @final_balance

end

public

  def interest

  p ( @balance * self.class::RI )

  end

public

  def rewards(time)       

@reward_points = interest * time * final_balance * 0.1

p ‘Reward points = ‘,@reward_points

p ‘interest = ‘, interest

  end

 def compare (obj1,obj2)

 if (obj1.interest == obj2.interest)

p ‘true’

  else

p ‘false’

p obj1

p obj2

  end

end

end

class Savings < Account

RI = 0.9

end

class Checking < Account

RI = 0.2

end

class User

end

acc = Account.new(100)

sav = Savings.new(200)

chk = Checking.new(300)

usr = User.new

#Now call the instance method using the objects created and see the output

acc.interest # 50

sav.interest # 180

chk.interest # 60

usr.interest # undefined method for User

we observe that public methods are accessible by objects of the parents class ‘Account’ as well as the child class Savings and Checking.

Private & Protected: When a method is declared under private or protected visibility, it cannot be directly accessed by parent class or any of the sub classes. For example in the above code,suppose if we declare the function interest as private as below:

private  (# or protected)

def interest

p ( @balance * self.class::RI )

end

p acc.interest # no method error

p sav.interest # no method error

p chk.interest # no method error

p usr.interest # no method error

In order to access the private/protected methods of a class, Ruby allows implicit calls to private/protected methods through public methods. For example:

acc.rewards(10) # interest = 180

sav.rewards(5)  # interest = 19200

Checking.new(200).rewards(20) # interest = 40

The private/protected method ‘interest’ is accessed via the public method ‘rewards’ as per the definition below:

def rewards(time)

@reward_points = interest * time * final_balance * 0.1

p ‘Reward points = ‘,@reward_points

p ‘interest = ‘, interest

end

Now the most important question arises, what is the difference between private and protected. To understand this lets test both scenarios for the following code and observe the results:

private

def interest

p ( @balance * self.class::RI )

end

obj1 = Account.new(200)

obj2 = Savings.new(200)

Checking.new(200).compare(obj1,obj2) # Private method interest called for Account, NoMethod Error

Now declare the method interest as protected

protected

def interest

p ( @balance * self.class::RI )

end

obj1 = Account.new(200)

obj2 = Savings.new(200)

Checking.new(200).compare(obj1,obj2)

output:

# “false”

#Account:0x2733e70 @balance=200, @final_balance=300.0>

#Savings:0x2733e28 @balance=200, @final_balance=380.0>

 

This actually worked! but why! lets look at the function definition:

def compare (obj1,obj2)

if (obj1.interest == obj2.interest)

p ‘true’

else

p ‘false’

end

end

Inside the public method compare, obj1 of class Account and obj2 of class Savings makes an explicit/direct call to the method ‘interest’ (obj1.interest abd obj2.interest respectively) which is not permitted by Ruby for private methods. Whereas if the method is declared protected, objects of the parent class and its subclass objects can access the method when called inside a public method. Hence the visibility of private is lesser than a protected method.

I hope this blog was useful to some extent to understand different types of access control and their differences!

1 Comment

Filed under Ruby on Rails