paulghaddad · August 29, 2015 14:15
diff --git a/gistfile1.txt b/gistfile1.txt
 1. In ruby and rails, we depend heavily on 'magic' behavior. How can we be consistent in our usage of the Principle of Least Surprise and still use this behavior?

 In my opinion, using "magic" behavior is consistent with the Principle of Least Surprise if used with commonplace Rails functionality. It is okay to use Rails's magic if the vast majority of Rails programmers are familiar with the usage. For example, defining associations using the Rails syntax (has_many :posts) is not surprising. This syntax is used in most Rails applications, is thoroughly documented and saves developers from writing many methods to make method calls across associations.

 2. Show an example of dangerously dynamic code, and one of code that is dynamic but consistent with the other principles you've learned.

 An example of dangerously dynamic code is improperly using method_missing to handle calls to methods that don't exist. This provides surprising behavior if the developer is unaware of the use of method_missing. Having the Ruby interpreter return a NoMethodError when a call is made to a non-existant method will be easier to work with in the long run.

 Examples of code that are dynamic but don't violate any engineering principles include using validations (validates :title), associations (has_many :posts), filters (before_action :method), and defining routes.
	1. In ruby and rails, we depend heavily on 'magic' behavior. How can we be consistent in our usage of the Principle of Least Surprise and still use this behavior?

	In my opinion, using "magic" behavior is consistent with the Principle of Least Surprise if used with commonplace Rails functionality. It is okay to use Rails's magic if the vast majority of Rails programmers are familiar with the usage. For example, defining associations using the Rails syntax (has_many :posts) is not surprising. This syntax is used in most Rails applications, is thoroughly documented and saves developers from writing many methods to make method calls across associations.

	2. Show an example of dangerously dynamic code, and one of code that is dynamic but consistent with the other principles you've learned.

	An example of dangerously dynamic code is improperly using method_missing to handle calls to methods that don't exist. This provides surprising behavior if the developer is unaware of the use of method_missing. Having the Ruby interpreter return a NoMethodError when a call is made to a non-existant method will be easier to work with in the long run.

	Examples of code that are dynamic but don't violate any engineering principles include using validations (validates :title), associations (has_many :posts), filters (before_action :method), and defining routes.