The First Step for Ruby on Rails
jamesjohnson.meI've been following through the online version of Michael Hartl's RoR book: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
It's proven to be a GREAT way to learn the basics from the ground up while building an actual app at the same time.
Thanks! Glad you like it. As you probably know, there's already a Rails Tutorial chapter (and screencast) on Rails 3.1, but I'm also working on a full 3.1 update as well. Look for the new book in November or December, with the screencasts to follow a couple of months later. Sign up for the news feed for the latest updates: http://feeds.feedburner.com/railstutorial
Hi Michael, got a few questions for you:
1) Will the update to 3.1 be free for existing customers?
2) Would you mind to share a bit of your process of making the screencasts?
Thanks!
PS: I have the print book, the pdf, and the screencast. Love them.
The supplementary Rails 3.1 chapter and screencast were free for existing customers. The full revision won't be free, but existing customers will receive a substantial discount on the new product.
As far as my publication and production processes go, I have big plans in this direction. I need to make the 3.1 update first, but after that I'll have more details for you. Stay tuned. :-)
I wrote a book called "Rails 3 in Action" for getting started with Rails. Obligatory link: http://manning.com/katz
The idea behind it was to have more focus on BDD than anything else out there, which is exactly what the community is all about these days.
Just like Michael's brilliant book, we go through building an application from the ground up using Rails 3.1, RSpec, Cucumber and many other gems provided by the community.
Why is your ebook more expensive than the print version on Amazon? (Amazon is $10 cheaper)
I am not quite sure. Maybe Manning gave them to Amazon at a certain price and Amazon chooses which price they want to sell at? I have no idea.
Fabulous introduction to Ruby on Rails, especially if you've already got some prior Ruby experience.
Ruby on Rails Tutorial is awesome. Even though I went through most of the Agile book years ago, going through the Tutorial helped me: get up to speed with newer versions of Rails, learn the basics of git, and see how test-driven development is done.
copy and paste in the following command:
/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
At some point you're downloading something and executing it. Unless you pick through all of the source code or decompile the binaries you download, you could get caught at any stage.
For a beginner, it makes no difference if they get burnt by a gist or by a compromised package or binary. And they can at least attempt to read https://raw.github.com/gist/323731 in plain text.
I feel the same way, but you are putting the same amount of trust in external services when you run something like 'npm install' already.
And don't forget that something like:
git clone .... sudo make install
is a huge hole for bad things to happen as well.
Nice guide, I wish I had it when I first started rails. However, vim? I love vim, and suggest everyone learns it. But if the point of a guide is to teach the basic installation of ROR, I wouldn't suggest making them open vim, too.
especially when it can be replaced with one line
echo "[[ -s $HOME/.rvm/scripts/rvm ]] && . $HOME/.rvm/scripts/rvm" >> ~/.bashrc
After using rvm, I'd suggest using rbenv (https://github.com/sstephenson/rbenv) instead.
It doesn't try to do as much, so a little less magic. The biggest thing I like is that it doesn't try to do anything with gems, which is good - I've been trying to use bundler for everything.
I hate to single you out, but it's become really hard for me to listen to any Ruby developers decry "magic" as a bad thing in RVM. RVM is an excellent tool that was taken down a notch by a hit job needlessly perpetrated by the author of rbenv.
RVM is no more magic than rbenv, and to listen to Ruby developers (who treasure "magic") talk about it as if RVM commits some cardial sin by overriding `cd` tops out my nerd-rage-meter. Ruby, home of the monkey patchers, has no place calling out RVM for overriding `cd`.
RVM and rbenv serve similar purposes. RVM gives you gemsets as well. You may not need them today, but they're there if you do. I use Ruby for a lot of system administrative tasks. These tasks run inside cron jobs and other places where a bundle really doesn't make sense. Despite the fact that they're no longer in vogue, gemsets are still very useful.
Should you check out rbenv? Yes. But the "little less magic" is a really poor basis by which you should evaluate it as a tool.
Monkey patching in ruby has well-known problems (what happens when two libraries patch the same object?), and now good library maintainers know not to monkey-patch standard libraries. Neither should RVM.
The monkey-patching of `cd` is the main reason I'm not using RVM. I depend on `cd` to work, every time, rock solid, especially when my system is unstable. I can't risk having a dependency or bug in their `cd` script breaking my most commonly used shell command.
rbenv has demonstrated that it's not necessary to override `cd` to manage ruby versions, so why does RVM still do it?
The only function of RVM that requires overriding `cd` is the autoloading of .rvmrc, which is easily turned off with a single line of configuration. The topic is so beaten to death that we've even been through one iteration where RVM turned it off by default.
Here's the rub. No one ever has a problem with the overridden `cd` command. Community outcry resulted in a reversion of the default returning to it's original configuration.
What bugs the shit out of me is the band-wagoning from people who, frankly, haven't got a clue. They hear that "there be dragons" in RVM, and all of the sudden everyone is running around flailing their hands over their head like RVM installs a custom kernel or something. It's unwarranted, and it all stems from the original hit job pulled by Sam Stephenson when he released rbenv. Meanwhile, all the same people who are screaming about the "magic" in RVM were cluelessly using it for god knows how long before rbenv came along.
Sam has since apologized and will tell you that RVM is a fine tool, but everyone seems to have forgotten that. If you don't want to use RVM, fine, don't use it, but the "reasons" everyone cites for avoiding it are pretty weak in practice. Wayne is one of the strongest bash programmers I've ever seen. I trust him, and every time I've needed him, he's been available in #rvm for help. Go forth and use rbenv, but you don't have to kick dirt on RVM along the way.
Can you explain to me how did RVM cause cd to interfere with your work experience? Im curious because Ive been using it forever and other than it executing my .rvmrc files, havent noticed a bit of difference
RVM's overriding of cd isn't portable to other shells. I can't use it in my favourite shell (fish).
Yeah, there's http://beginrescueend.com/integration/fish/, but I tried that and it started printing errors every time I used cd due to some bug (this was over a year ago, there's a good chance it's been fixed, but it just left me really shy about overriding cd).
As an RVM user, I wholeheartedly agree with your main point but I think there's an argument to be made to allow some other program handle gemsets. As it is, when you use RVM you most likely have to add your .rvmrc to your .gitignore. This unfortunately obfuscates what version of Ruby your project is on. Using rbenv is nice in that you can keep that documentation alongside the project where it belongs. Tying the gemset to the version is nice for testing various environments for a single project but doesn't work well when you have to choose between sharing a local development setting with the whole team or not sharing an rvmrc at all.
I use Bundler for all my application projects. Fortunately, nothing about RVM forces you to use gemsets. I use gemsets for scenarios where I'm writing code that will not run within an 'application'.
Ruby is my go to language for damn near everything. I use it for working with log files, parsing Excel documents & performing analysis, system administration, you name it. Many of these scripts are one-offs that reside in '~/bin'. RVM allows you to do something like this in your shebang:
#!/usr/bin/env ruby-1.9.2-p290@vqm-analysis
That's the first line in a shell script that I wrote to collect examples of bad calls in a csv file output from an AdTran 900-series VoIP gateway. The CSV file contains about 30 columns of data related to the quality of VoIP calls. I have a collection of five or six scripts that use that gemset, but they're not really an application. They just run from '~/bin', so using bundler isn't really practical. I could wrap them up in a gem and make them a proper application, but this is scripting. Simply using RVM + gemsets saves me a lot of time.
My point is that gemsets may or may not have any utility for you, but it's narrow minded to assume that they have no utility for everyone.
rbenv is a bit easier to use in production (doesn't require any Capistrano addons, etc.) IMO, but for local dev it doesn't really matter one way or the other.
I have switched to rbenv myself, but that "magic" makes RVM a potentially better choice for a beginner.
* No need to install a second thing (ruby-build) to install rubies.
* No need to do manual things like running "rbenv rehash".
* More chatty and hand-holding (tells you dependencies you need to install for your platform, etc)
rvm still has more traction in the community and the end result is going to be very similar to rbenv for the majority of users--except that rvm has a built-in rubies installer + gemsets, which can make things easier for beginners to dive in and access other projects. New users should probably stick to rvm.
I tend to think that rvm is overkill for beginners. If you're really just getting started, installing ruby and rubygems is what you should stick to and adding steps like "install rvm" "install a ruby" "create a gemset" just add potential points of failure and frustration.
What is it about having gemsets that makes it easier for a beginner? Bundler seems to handle installing dependencies just fine.
gemsets are especially important for beginners that will be trying out lots of different codebases with different gem dependencies.
With rvm you can create a gemset just for that project youre testing out. Imagine trying to work with different projects that have different versions of ruby, different versions of rubygems and different versions of rails, some gems from github, some gems from source, some gems from rubygems.
A beginner would not be able to sort through the dependency mess this creates. Gemsets help you avoid this nightmare.
Gemfiles and bundler solve the same problem, in a way that works with Rails and gem development and that doesn't require extra stuff jammed into your shell.
I did the step up to "[[ -s $HOME/.rvm/scripts/rvm ]] && . $HOME/.rvm/scripts/rvm", and then tried "rvm install ruby-1.9.2-p290" but it said "rvm: command not found". Ideas?
I dont belive that bashrc is being executed on a mac as standard. Try:
source ~/.bashrc
If that worked add this to your .bash_profile
[ -f ~/.bashrc ] && . ~/.bashrc
Yes, that worked! I am on OSX Lion.
did you restart your terminal session? I believe that's the next step. did you make sure your bashrc wasn't returning before that bit was executed?
Yep to both.
A nice style, but for beginners, why would you suggest going into Vim (or any editor) with the potential for screwing up? Even RVM's actual installation documentation says to just do this:
echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
This seems a bit oversimplified and misses opportunities to teach a lot of the fundamentals about Rails as part of the installation process. I still recommend Agile Web Development with Rails for learning rails: http://pragprog.com/book/rails4/agile-web-development-with-r...
Quick tip: A Rails IDE like RubyMine (paid) or RadRails (free) is well worth the money if you are just starting out.
Why you added VIM and RVM into the mix? Those are distractions.
I agree with you on vim (gedit would have been a better choice), but RVM had been a huge help when I first started with Rails (and Ruby development) in general. It took away the need for sudo gem installations, for one.