flash

by default, values stored into the flash during the process of a request will be available during the process of the immediately following request. Once the 2nd request has been processed, those values are removed from flash

cucumber Features In Subdirectories

From this blog
I’m working on a project where we’ve amassed a decent amount of Cucumber features. Dumping them in the root directory makes it difficult to find the feature you’re looking for and running related features is impossible.

I’ve fooled with organizing my cucumber features in the past, but didn’t have much luck. Grouping related features into subdirectories was fine when running the entire suite, but running an individual feature failed because Cucumber doesn’t know to load step definitions from the parent directory. As I was looking through cucumber –help the other day, I happened to notice the –require flag.

-r, –require LIBRARY|DIR
Require files before executing the features.

Running the following command was exactly what I needed.

cucumber –require features features/users/sign_in.feature

This tells Cucumber to load all .rb files under features/ which will find the step definitions and support files. To save some typing, I created an alias in ~/.bashrc.

alias cuc=’cucumber -r features’

Where I’ve really enjoyed this setup is when running all related features. After touching a step definition, I’d like to run the features that depend on it quickly without running the entire suite. Now that’s as simple as:

cuc features/users/*

form_for and form_tag

form_for and form_tag both are used to submit the form in ruby on rails.
but the way of handling objects related to model is different.

form_for:

you should use form_for for a specific model i.e while crating an new row in database. form_for will perform the standard http post which is having fields related to active record objects.

here is the example for using form_for in ruby on rails:

{ :action => “update” } do |f| %>

then in here you can use the f object to create input field.

First name: <%= f.text_field :firstname %>
Last name : <%= f.text_field :lastname %>
Biography : <%= f.text_area :biography %>

<% end %>

form_tag:

form_tag just creates an form as an normal form. form_for will perform the standard http post without any model backed and has normal fields. this is used mainly when specific things need to be submitted via form

ruby random number

f you needed a random integer to simulate a roll of a six-sided die, you’d use: 1 + rand(6). A roll in craps could be simulated with 2 + rand(6) + rand(6).

Finally, if you just need a random float, just call rand with no arguments.

(From first result of google search: Ruby Random Numbers)


As Marc-André Lafortune mentions in his answer below (go upvote it), Ruby1.9.2 has its own Random class (that Marc-André himself helped to debug, hence the 1.9.2 target for that feature).

For instance, in this game where you need to guess 10 numbers, you can initialize them with:

10.times.map{ 20+Random.rand(11) } #=> [26, 26, 22, 20, 30, 26, 23, 23, 25, 22] 

Note:

This is why the equivalent of Random.new.rand(20..30) would be 20+Random.rand(11), since Random.rand(int) returns “a random integer greater than or equal to zero and less than the argument.”
20..30 includes 30, I need to come up with a random number between 0 and 11, excluding 11.

validation_inclusion_of

validates_inclusion_of(*attr_names) public

Validates whether the value of the specified attribute is available in a particular enumerable object.

class Person %w( m f )
validates_inclusion_of :age, :in => 0..99
validates_inclusion_of :format, :in => %w( jpg gif png ), :message => “extension %s is not included in the list”
end

Configuration options:

* :in – An enumerable object of available items
* :message – Specifies a custom error message (default is: “is not included in the list”)
* :allow_nil – If set to true, skips this validation if the attribute is null (default is: false)
* :allow_blank – If set to true, skips this validation if the attribute is blank (default is: false)
* :if – Specifies a method, proc or string to call to determine if the validation should occur (e.g. :if => :allow_validation, or :if => Proc.new { |user| user.signup_step > 2 }). The method, proc or string should return or evaluate to a true or false value.
* :unless – Specifies a method, proc or string to call to determine if the validation should not occur (e.g. :unless => :skip_validation, or :unless => Proc.new { |user| user.signup_step <= 2 }). The method, proc or string should return or evaluate to a true or false value.

====================================================

My note: it can be allowed to be nil when you specified. Wen you don’t, nil value will fail the validation

update_attribute & update_attributes

On clicking show source you will get following code

      # File vendor/rails/activerecord/lib/active_record/base.rb, line 2614 2614:       def update_attribute(name, value) 2615:         send(name.to_s + '=', value) 2616:         save(false) 2617:       end 

& now refer update_attributes and look it’s code you get

      # File vendor/rails/activerecord/lib/active_record/base.rb, line 2621 2621:       def update_attributes(attributes) 2622:         self.attributes = attributes 2623:         save 2624:       end 

the difference between two is update_attribute use save(false) where as update_attributes uses save or you can say save(true)

Sorry for the long description but what i want to say is important. save(perform_validation = true)) if perform_validation is false it bypasses (skips will be the proper word) all the before_* callbacksassosciated with save.

=======================================

My note: 1) update_attribute use save(false)=save(perform_validation=false) means the attribute will be saved

2) update_attributes use save(true)=save(perform_validation=true) means that the attributes will not be saved if any of them is invalid. And if ANY of the attribute violates the validation, ALL the attributes intended to be updated will not be changed.

Hello world!

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can always preview any post or edit it before you share it to the world.