Developers from all levels will accidentally run rake tasks using the `rails` keyword when they meant to use `rake`. Often times beginners struggle with the difference between the tools. The most common example would be `$ rails db:migrate`
Rather than telling the developer simply that they did not use a valid rails command, we can see if it was a valid rake command first. If it is a valid rake command we can auto execute it giving the user a period of time to cancel if that isn't what they intended.
Here is what `rake db:migrate` would look like if you cancel the command:
```sh
$ rails db:migrate
Assuming you meant: $ rake db:migrate
press any key to cancel in 3 seconds
>
command terminated ...
```
Here is what it looks like if you don't cancel the command:
```sh
$ rails db:migrate
Assuming you meant: $ rake db:migrate
press any key to cancel in 3 seconds
>
Running: $ rake db:migrate
== Foo: migrating ============================================================
== Foo: migrated (0.0000s) ===================================================
```

This reverts commit 86c3dfb.
Conflicts:
activerecord/lib/active_record/attribute_methods/read.rb
Reason: whilst this increased performance, it also presents a DoS risk
via memory exhaustion if users were allowing user input to dictate the
arguments of read/write_attribute. I will investigate alternative ways
to cut down on string allocations here.

…llow all the hash
params.require(:person).permit(:projects_attributes) was returning
=> {"projects_attributes"=>{"0"=>{"name"=>"Project 1"}}}
When should return
=> {}
You should be doing ...
params.require(:person).permit(projects_attributes: :name)
to get just the projects attributes you want to allow