Last active
December 14, 2015 16:08
-
-
Save rkulla/5112787 to your computer and use it in GitHub Desktop.
My Rails 3 Tutorial notes that I recommend people use.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
My notes and shortcuts for working with Michael Hartl's great Rails tutorial | |
(http://ruby.railstutorial.org/) | |
- Since he has you install RVM in the very first chapter, I recommend actually using it | |
immediately rather than getting in the habit of typing out "bundle exec" all of the time | |
or forgetting to create and switch to gemsets. I recommend running this right away: | |
$ rvm use 1.9.3@sample_app --create | |
This way if you're reading other tutorials too, and want to experiment with gems they | |
have you install, you won't have to worry about conflicting gems. Just create a separate | |
gemsets for each project. | |
Optionally create a .rvmrc file that contains 'rvm use 1.9.3@sample_app' in case you run | |
tmux/screen so you don't have to manually type out 'rvm use ...' every time you open a | |
new terminal, etc. | |
- If you already know you want to learn HAML or Slim or some other templating language, | |
then I recommend installing them immediately and converting the ERB examples to it. | |
You can always just paste the html.erb code into html2haml.heroku.com to or into | |
http://html2slim.herokuapp.com/ to convert to HAML or Slim, respectively. | |
- You don't have to type 'bundle install'. The 'bundle' command does the same thing. | |
Considering how much we have to type this command, I much prefer simply typing: | |
$ bundle | |
- You don't need to run 'bundle update' before 'bundle [install]'. It's a dangerous habit | |
to get into because in real projects you could end up with backwards-incompatible changes | |
to your dependencies. Runnig 'bundle update' by itself will try to update every single | |
gem and it isn't necessary if you've already explicitly added the gems to the Gemfile. | |
- You don't have to type "--skip-test-unit" every time you run "rails new" if you create | |
a file called $HOME/.railsrc and put --skip-test-unit in it. | |
- You don't have to type 'heroku create --stack cedar'. The cedar stack is the default in | |
Heroku, so you can simply type 'heroku create'. | |
- At the time of this writing, the tutorial uses a 1.x version of capybara, even though | |
2.0.0 has been out. The reason for this seems to be because capybara 2.0 broke the | |
has_selector helper that the tutorial uses and isn't fixing it until 2.1. You can | |
read about this here: https://github.com/jnicklas/capybara/issues/844 | |
The tutorial will confuse you when you switch to 2.x because capybara no longer places | |
specs in specs/requests but instead puts them in specs/features. I recommend using the | |
exact 'old' version of capybara the the tutorial recommends, for doing the tutorial. | |
For your own projects, if you want to use 2.0, you'll get errors about 'visit' method | |
missing. However, the rails integration_testgenerator still puts things in spec/requests, | |
so do: | |
$ mv spec/requests spec/features | |
You'll also need to not put rspec-rails 2.11.0 in Gemfile, but will need a higher | |
version, or you'll also get errors about 'visit' method missing. So instead use: | |
gem 'rspec-rails', '>= 2.11.1' | |
Or you could put the following line in spec/spec_helper.rb in the RSpec.configure | |
config.include Capybara::DSL | |
And you will also need to edit Guardfile and change 'requests' to 'features'. | |
- I don't recommend using spork. It's not much faster usually and many people find it | |
too buggy and annoying to work with. If you really want to bootstrap a rails environment | |
up front, there are potentially better methods such as https://github.com/jstorimer/spin. | |
- When using bootstrap-sass you rarely should just add Twitter Bootstrap's classes directly | |
in your HTML, since that makes refactoring away from Bootstrap harder later (and bootstrap | |
is just a 'bootstrap' afterall, not something you'll want to be tied to forever). Since we | |
are using SCSS we have access to mixins. This means, instead of doing things like: | |
<header class="navbar navbar-fixed-top navbar-inverse"> | |
we can make our *own* CSS class, say header-nav bar: | |
<header class="header-navbar"> | |
and use the @extend directive to inherit Bootstrap's LESS-based CSS classes. (make sure you | |
have @import "bootstrap"; or you won't have access to Bootstrap's styles, mixins and | |
variables. So in custom.css.scss (or application.css.scss or wherever you're styling from): | |
.header-navbar { | |
// Use Twitter Bootstrap's navbar component | |
@extend .navbar; | |
@extend .navbar-fixed-top; | |
@extend .navbar-inverse; | |
} | |
Later if you decide to stop using Bootstrap you won't have to grep your html for all of the | |
possible different Bootstrap classes to replace! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment