Observer pattern in ruby

Created quickly a couple of classes to show the observer pattern in Ruby .

	class Subject
	def initialize
	@name = "Subject1"
	p "Subect initialized to #{@name}"
	@observerList=Array.new #initialize the observer list
	end
	def name=(n)
	@name = n
	p "Subject's name changed to #{@name}"
	setChanged(); #indicate the object has been changed - that calls the publishing function
	notifyObservers
	end
	def addObserver(observer)
	if (defined?@observerList).nil? #if our observer array is damaged
	p "Some problem with observer list - no array defined"
	else
	@observerList[@observerList.length] = observer
	end
	end
	def setChanged
	@@changed = 0
	end
	def clearChanged
	@@changed = 1
	end
	def hasChanged?
	@@changed ||= 1
	end
	def notifyObservers
	if hasChanged?
	@observerList.each do |observerToNotify| #notify all the observers
	observerToNotify.update(@name)
	p "#{observerToNotify} has been updated"
	end
	clearChanged #notification complete
	p "Clear changed called.<end>"
	end
	end
	end
	class Observer
	def initialize
	@name = "Initial observer name"
	p @name
	end
	def update(name)
	@name = name
	p "Updated name in observer to #{@name}" #just for testing
	end
	end
	s1 = Subject.new
	o1 = Observer.new
	s1.addObserver(o1)
	s1.name="Arun"

view raw observer_ruby.rb hosted with ❤ by GitHub

Note : work to be done in finding the name of the object in the block under notifyObservers method.

Subtle difference between flash and flash.now

The flash variable is supposed to be used before a redirect. So it appears in the resulting page and waits for a request. So if we use it before we do anything but redirect, for instance before render, it would appear in the rendered page but is still waiting for a "redirect" request and so will appear again if you click a link.

To avoid this weird behavior we use flash.now during a render instead of flash. flash.now is supposed to be used in pages that are rendered. 

Ruby On Rails tutorial

Ruby on Rails tutorial by Michael Hartl is one of the few books that explains the basics of Rails ecosystem in a very simple manner. I didn't have to refer to any forum or log on to any freenode chat throughout the time I read this book. The whole ecosystem and the gears (gems) that are connected with Rails could be daunting to many. I am a Database administrator by profession and was scared when I read various online Introductions to Rails.

Firstly the installs are painful. Ruby, gem, rails etc. Here is where the author's simple no-nonsense approach starts. He relies heavily on the ecosystem for the best tool(gem) available to do the job. RVM to have a modular install for anything Rails (Ruby, gemsets etc) was excellent as I did not tinker with the underlying installs of the same software. I could uninstall(implode) RVM when I needed and reinstall gems in a much cleaner way using this amazing tool.

Secondly rspec for testing. I was curious to see why the author chose rspec over Test::Unit and found various members on forums supporting his decision due to the power and clarity of the tool. Annotate helped me in viewing the model in a descriptive form that I have been used to in the database world.

The best part of the tutorial was the 'Validating Users' part wherein we developed the login mechanism ourselves, from getting to know the various encryption algorithms available to the way we think of coding the same functionality (has_password? anyone???) was brilliant.

When I completed the book I was not only a bit conversational with the Rails world but also had developed lateral thinking in coding any functionality be it in the classical database world where I live in. For me there cannot be a better introductory book to Rails than this (believe me when I say I did try out the no.1 obvious choice that all the forums listed and was unhappy with the whole flow of the book).

Blocks, Procs and Lambdas

I was able to google around and get a wealth of information regarding Ruby blocks, Procs and Lambdas - closures in Ruby.

blocks vs Procs

Block: Your method is breaking an object down into smaller pieces, and you want to let your users interact with these pieces.
Block: You want to run multiple expressions atomically, like a database migration.
Proc: You want to reuse a block of code multiple times.
Proc: Your method will have one or more callbacks.

unlike Procs, lambdas check the number of arguments passed.

lambdas have diminutive returns

Part of Ruby’s syntax is that arguments (a Proc in this example) cannot have a return keyword in it.

The neat thing is that this Method object will act just like a lambda, because the concept is the same. This method however, is a named method (called square) while lambdas are anonymous methods.

Thanks Robert Sosinsky 

Three ways of declare a regex operator in Ruby

/mm\/dd/ # => /mm\/dd/
Regexp.new("mm/dd") # => /mm\/dd/
%r{mm/dd} # => /mm\/dd/

Ruby : Methods, Procs and Lambdas

Started reading understanding Ruby blocks, Procs and Lambdas from a link in a rails post. Very very interesting.

I learnt what blocks are, Proc object is, and the subtle difference between the Proc and Lambdas. The differences aren't many and visible, but they are interesting.

1. Proc doesn't check number of arguments while Lambdas do
2. Use lambdas to pass the 'return' keyword as a part of an argument - Ruby doesn't allow you to do that in Proc

The 2nd point is because Procs are 'drop in code snippets and not methods', but lambdas act like methods.

Lambdas are anonymous way to write methods.

To use a named lambda use the Method object and assign the code to it.

eg      puts method(:square).class

Rails naming-1-Migrations

Migration naming convention - _to_<table_name>

add_password_to_user - constructs a migration to the user table.