https://www.addedbytes.com/cheat-sheets/ruby-on-rails-cheat-...
- rake test: run the entire test suite
- rails s: run the rails server
- rails c: opens up an IRB/pry session with your Rails app
- rails g migration: create a new migration
- rake db:migrate - Run new migrations
- rake db:create - create the DB the first time
- rake db:schema:load - generate the DB from schema.rb
- rake db:setup - generate a new database from migrations
- rake routes - Spit out the routes and path helpers
Don't ever use rails generate model/controller. It generates so much garbage that you likely won't need.
There are a bunch of other commands off of rake db:migrate but most aren't needing to be memorized. Our brains are only so large and dense and mine is particularly small, memorize what is important and memorize how to look up the rest.
I really disagree on the bit about not using rails g for controllers, and especially models. If you include your fields and types in the generate command you are given the corresponding migration, fixture, and test file for said model. If most of what you need can be generated by a single command, that's a whole lot less to remember compared to the intricacies of manually creating migrations, fixtures, test files etc. The generate commands have gotten so solid throughout the years, you can even do polymorphic and other associations through them and skip manually writing out all those details at this point. A whole lot less to remember there.
I don't see the penalty for some empty javascript files etc. And I like having everything where it belongs.
script/rails console and rake db:migrate
everything else I look up online, and I've been coding for 5 years in rails
(Sometimes it takes more motions, because Dash knows the docs for everything and sometimes doesn't get the context right, but that might also be driver error: the app is always politely telling me that I could learn to use it even better.)
Docs aren't always the best tool but it is good to have them at your fingertips.
patio11 is on to something when he suggests using your own codebases. Keep them all on your machine. Learn how to search them. (I use emacs and its various project-directory search utilities like Projectile and Helm, but there are other tools.)
If you don't have any Rails codebases to refer to yet, Michael Hartl is here to help you.
Your personal library is best because it comes from your perspective and with your memory cues. It also only covers use cases you have actually seen, which sounds like a bug but which is actually a feature. The problem with trying to use public docs as references is that they cover all the features that you will never use.
One drawback of your personal library is that it will always feel obsolete. This is a good thing; it means you are improving. Fix it up in bits and pieces where you can. Borrow ideas from the pages you Google.
There is a school of thought which says that you should use your public Github profile as your personal library. Having dabbled in this for a while, I now reject it. Do not write your notes for an audience larger than one. The amount of time you spend thinking "is it dangerous or embarrassing to record this line of code in my private personal repo?" should be zero. If there is anything worse than having the internet read over your shoulder, it is imagining the internet reading over your shoulder. Buy a big private Github account, use Bitbucket, or run a private server for your hacks and notes.
Take notes on everything you do. In particular, get in the habit of pasting the command-line things that you do into a cheat sheet. This is the beginning of devops wisdom. One reason why the advanced deployer does everything with a script (or Vagrantfile, or Dockerfile) is that the script remembers the steps for you and can be looked up later.
