
Ask HN: How do you memorize the tons of commands related to rails? - aaronsung
I am currently learning rails. I used to programming in .NET and Java ecosystem and I got good GUI tools&#x2F;IDEs such as VS and Eclipse.
However, when I had come into rails, I found there are tons of commands are needed to memorize before you can use rails efficiently, e.g. rvm commands related to gemsets, rails commands for generating controller and models, rake commands for managing databases, etc. I found it&#x27;s a bit difficult for me. Do you guys have any tricks or tools for this hard job?
======
patio11
Back in the day, I had Amy Hoy's Rails cheatsheet printed out next to my work
desk, and I referred to it pretty constantly for the first few weeks. ~6 years
later all of the common stuff is second-nature and the esoteric stuff is
either a) somewhere in one of my codebases or b) on Google.

~~~
christiangenco
Is this the referenced Amy Hoy cheatsheet?

[https://www.addedbytes.com/cheat-sheets/ruby-on-rails-
cheat-...](https://www.addedbytes.com/cheat-sheets/ruby-on-rails-cheat-sheet/)

------
rubiquity
Realistically, you only need to memorize a few:

\- 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.

~~~
lukeHeuer
'rake' also runs the entire test suite, as it's an alias for 'rake test'.

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.

~~~
rubiquity
I think I made the decision a couple years ago that I'd rather just remember
what the files should look like and create them as I need them. I work on
varying types of Rails apps (some full-on HTML/JS and others just JSON APIs)
where a lot of times you don't need most of those files. I could see merit in
just remembering the generator commands, though.

~~~
lukeHeuer
I see. I'm on the same boat as far as developing varying types of apps w/
Rails. Disabling things I don't need, like asset pipeline for API dev is
pretty quick: config.assets.enabled and config.generators.assets set to false
and you don't have to worry about generators creating any unnecessary js/css
in that scenario. Out of curiosity, what other things are being generated that
wouldn't be of use?

~~~
rubiquity
Resource-based SCSS/CoffeeScript files. For an API I definitely don't need
these, for a regular app I don't need them because I try to write JS/CSS
around components rather than resources.

Good call on just removing the generators though. I should just do that.

------
mechanical_fish
Let me get the plug in first: if you are on a Mac, try Dash, the app that
looks up docs for you. I have it mapped to a keystroke in emacs, and I can
sometimes park the cursor atop, say, the word 'render' and look it up in one
motion.

(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.

------
barry-cotter
Download anki or mnemnosyne or supermemo or any other Spaced Repetition System
program. Add the 50 or so most common commands to it and what they do. If you
set it to test you on 10 new commands a day you will know all of them cold
within two weeks at five minutes a day.

------
heyalexej
I use Anki[0] to learn and memorize tons of command line tools and Vim
motions. It takes a couple minutes every day. Doing this in combination with
actually using the tools brings fluency rather quickly.

[0] [http://ankisrs.net](http://ankisrs.net)

