31–40 of 40 posts
Why you added VIM and RVM into the mix? Those are distractions.
Earlier quoted context omitted.
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-ra…
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…
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.
Earlier quoted context omitted.
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-ra…
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 gemse…
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.
I'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
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.
Earlier quoted context omitted.
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.
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'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.
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 com…
Earlier quoted context omitted.
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…
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
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).
Earlier quoted context omitted.
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 com…
Why is your ebook more expensive than the print version on Amazon? (Amazon is $10 cheaper)