5 ms·

and even if it were only 5 it would be worthwhile to make it easier Seriously? 1. Install XCode and homebrew 2. sudo brew install {postgresql,rbenv,ruby-buil

by moe 15y ago

and even if it were only 5 it would be worthwhile to make it easier Seriously? 1. Install XCode and homebrew 2. sudo brew install {postgresql,rbenv,ruby-build} 3. Close terminal. Open terminal. 4. mkdir proj && cd proj && rbenv install 1.9.2-p290 && rbenv local 1.9.2-p290 5. gem install rails && rbenv rehash 6. rails new foo Honestly, we can argue if this was 5 steps or 8. We can also argue if 'rbenv rehash' should be necessary (I'm not even sure it really is, wrote that down from top of my head). But if someone fails on these instructions that fit on a Post-It™ then they should overthink their ambitions towards a programming career. And if they run into bugs during that procedure then these bugs must be fixed. Because this is (and should be) the canonical way to install a vanilla Rails on OSX.

sanderjd 15y ago
Dude, take a step back and forget that you know this stuff already and do it professionally. That list is not easy and far from obvious, even for real programmers coming from other environments, let alone for actual programming beginners. Your list is far from canonical even at this very moment and hasn't even been common for very long. To figure out your list, I have to: 1) know that homebrew is the "right" way to install software that rails depends on, rather than MacPorts or Fink, or the Mac app store, or download.com, and oh yeah, there is this thing called sudo, and I should install homebrew recipes using it, or should I??, 2) know that rbenv and ruby-build are things that exist and that they are competitors to RVM but are either more or less in vogue depending on who I talk to, 3) understand that rbenv doesn't just work in the current shell without closing and re-opening it, 4) know that the "right" version of ruby to use is 1.9.2-p290 (I have to know the patch-number?!) and that I need to install it and set it as my local version (wait, what does that mean, why do I need a local version?), before I can get around to actually installing rails and using it. Now, I could just blindly follow someone's list from a blog post (randomly chosen presumably, because the theory here is that I don't know enough about these things to make an informed decision). Maybe I would even get lucky and find a list that works properly with the version of rails that the official documentation is talking about, but it would still be a much better experience by far to go to the official rails site and be told: "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!".
- rpwilcox 15y ago
  Exactly. It's frustrating. See http://rwilcox.tumblr.com/post/20094754364/its-hard-to-install-rails-on-os-x http://rwilcox.tumblr.com/post/20094754364/its-hard-to-insta.... It's a "story in 20 parts" about what can go wrong with a Raila install on OS X.
- toadi 15y ago
  Actually I agree with previous commenter. These steps are easy and only take like 10minutes and give great power handling versions and gemsets to projects. If you are someone who doesn't know what it means you should learn. Isn't that what a programmer needs to do?
  - sanderjd 15y ago
    The steps aren't hard, it's knowing which ones to do that is hard. And yes, you should learn what all those things mean and why everyone does them, but it shouldn't be the very first thing you learn.
- moe 15y ago
  To figure out your list, I have to No. You have to know none of that. You just have to copy/paste the steps from the rails-homepage (where they should be prominently listed, the lack thereof is the real bug). "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!" Wait, how is that different from above? Yes, you may be done 2 minutes faster. But you just deprived yourself of at least getting a glimpse on which parts are involved, even if you don't understand them yet. That means you're now even more hopeless when stuff breaks later (and stuff always breaks later). And as a fun fact: Any sane bootstrapper would use the exact same script behind the scenes anyway. There simply is no other way unless you plan to re-invent homebrew and rbenv along the way. I'm really troubled to understand who we're trying to care for here. It sounds like you want to make this Really Easy for absolute beginners who can barely setup a printer. That is a noble goal (for a printer driver), but if you want to teach someone programming then there's a point where you have to stop dumbing it down artificially. And that point is as early as possible. The worst you can do to a newbie is to put him into an opaque sandbox with different behaviors and errors from what the "big guys" are using.
talkingquickly 15y ago
But in practice it's almost never that simple. Install Xcode; 1) Install in App Store 2) Still not actually installed, start it, that finished the installation 3) You still don't have what you need, find where they've moved "install command line tools" to and install that 4)The compiler you have isn't the right one as Lion no longer has GCC as its default compiler and you want to use RVM 5) ...... Once you've done it a few times it's not that hard and you get used to knowing where to look for problems but the first few times it can easily be half a day lost just trying to get the environment working.
- moe 15y ago
  but the first few times it can easily be half a day lost just trying to get the environment working. The above steps are reasonably robust and implicitly teach you things about your programming environment that you must learn (or at least have seen) as early as possible. We should decidedly not dumb that down. There must be one canonical installation procedure for everyone and it must be as easy as above. There must not be "an easy way" and "a hard way". The above is as easy as you can make it without hiding crucial information from the user. Rails has plenty of harmful padding already, we need less of that, not more.
  - sanderjd 15y ago
    You don't need to learn those things as early as possible. You need to learn them eventually, as you're getting closer to gaining expertise. Accidental complexity early along the road to expertise is a hinderance not a help. The complexities of setting up a system so you can develop rails on it exist to solve problems that experts have discovered through years of working with the system, but which people coming to it fresh don't, and shouldn't need to, know that they have yet.
mechanical_fish 15y ago
I've just spent a few years being paid to maintain a lot of simple scripts exactly like this one, so I'm in a good position to say: These kinds of scripts really are incredibly simple. Until they break. But, they break. Would you like to start a pool on how long it will be until this recipe breaks, or becomes hopelessly obsolete because some portion of it is now out of date? Hint one: To get an idea, one could try the problem in reverse: How far back in time can you go before you reach a time when this script would not have worked yet? (Hint one, sub-hint A: The first commit to Homebrew's Git repo was in May of 2009.) Hint two: Homebrew formulae aren't guaranteed to build at all times. They sometimes have bugs, especially when any of their dependencies (including the version of OS X itself) has recently changed. Those bugs tend to manifest as scary messages from (e.g.) the linker. Hint three: Better get that version number out of the recipe before placing the bet. 1.9.2-p290 could become hopelessly obsolete at literally any minute; we're always just one zero-day away. It would be more reliable to pull that number from some canonical source like… um, any ideas? What is the answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" I don't know what your answer might be, but mine would be "pay someone like Yehuda Katz or the Rails core team to continuously recompute the answer, and to maintain the website that hosts the answer".
- moe 15y ago
  Well, that was the most reasonable response so far, at least you know what you're talking about. But, they break. The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters). Isn't rails the one with the 17 different testing frameworks and TDD kool-aid? How about adding structured tests for the installation procedure, too? Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable. Hint one, two, three The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?). answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies). The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation). It's not as hard as you make it out to be, really.

by moe 15y ago

sanderjd 15y ago

Dude, take a step back and forget that you know this stuff already and do it professionally. That list is not easy and far from obvious, even for real programmers coming from other environments, let alone for actual programming beginners. Your list is far from canonical even at this very moment and hasn't even been common for very long. To figure out your list, I have to: 1) know that homebrew is the "right" way to install software that rails depends on, rather than MacPorts or Fink, or the Mac app store, or download.com, and oh yeah, there is this thing called sudo, and I should install homebrew recipes using it, or should I??, 2) know that rbenv and ruby-build are things that exist and that they are competitors to RVM but are either more or less in vogue depending on who I talk to, 3) understand that rbenv doesn't just work in the current shell without closing and re-opening it, 4) know that the "right" version of ruby to use is 1.9.2-p290 (I have to know the patch-number?!) and that I need to install it and set it as my local version (wait, what does that mean, why do I need a local version?), before I can get around to actually installing rails and using it. Now, I could just blindly follow someone's list from a blog post (randomly chosen presumably, because the theory here is that I don't know enough about these things to make an informed decision). Maybe I would even get lucky and find a list that works properly with the version of rails that the official documentation is talking about, but it would still be a much better experience by far to go to the official rails site and be told: "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!".

rpwilcox 15y ago
Exactly. It's frustrating. See http://rwilcox.tumblr.com/post/20094754364/its-hard-to-install-rails-on-os-x http://rwilcox.tumblr.com/post/20094754364/its-hard-to-insta.... It's a "story in 20 parts" about what can go wrong with a Raila install on OS X.
toadi 15y ago
Actually I agree with previous commenter. These steps are easy and only take like 10minutes and give great power handling versions and gemsets to projects. If you are someone who doesn't know what it means you should learn. Isn't that what a programmer needs to do?
- sanderjd 15y ago
  The steps aren't hard, it's knowing which ones to do that is hard. And yes, you should learn what all those things mean and why everyone does them, but it shouldn't be the very first thing you learn.
moe 15y ago
To figure out your list, I have to No. You have to know none of that. You just have to copy/paste the steps from the rails-homepage (where they should be prominently listed, the lack thereof is the real bug). "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!" Wait, how is that different from above? Yes, you may be done 2 minutes faster. But you just deprived yourself of at least getting a glimpse on which parts are involved, even if you don't understand them yet. That means you're now even more hopeless when stuff breaks later (and stuff always breaks later). And as a fun fact: Any sane bootstrapper would use the exact same script behind the scenes anyway. There simply is no other way unless you plan to re-invent homebrew and rbenv along the way. I'm really troubled to understand who we're trying to care for here. It sounds like you want to make this Really Easy for absolute beginners who can barely setup a printer. That is a noble goal (for a printer driver), but if you want to teach someone programming then there's a point where you have to stop dumbing it down artificially. And that point is as early as possible. The worst you can do to a newbie is to put him into an opaque sandbox with different behaviors and errors from what the "big guys" are using.

talkingquickly 15y ago

But in practice it's almost never that simple. Install Xcode; 1) Install in App Store 2) Still not actually installed, start it, that finished the installation 3) You still don't have what you need, find where they've moved "install command line tools" to and install that 4)The compiler you have isn't the right one as Lion no longer has GCC as its default compiler and you want to use RVM 5) ...... Once you've done it a few times it's not that hard and you get used to knowing where to look for problems but the first few times it can easily be half a day lost just trying to get the environment working.

moe 15y ago
but the first few times it can easily be half a day lost just trying to get the environment working. The above steps are reasonably robust and implicitly teach you things about your programming environment that you must learn (or at least have seen) as early as possible. We should decidedly not dumb that down. There must be one canonical installation procedure for everyone and it must be as easy as above. There must not be "an easy way" and "a hard way". The above is as easy as you can make it without hiding crucial information from the user. Rails has plenty of harmful padding already, we need less of that, not more.
- sanderjd 15y ago
  You don't need to learn those things as early as possible. You need to learn them eventually, as you're getting closer to gaining expertise. Accidental complexity early along the road to expertise is a hinderance not a help. The complexities of setting up a system so you can develop rails on it exist to solve problems that experts have discovered through years of working with the system, but which people coming to it fresh don't, and shouldn't need to, know that they have yet.

mechanical_fish 15y ago

I've just spent a few years being paid to maintain a lot of simple scripts exactly like this one, so I'm in a good position to say: These kinds of scripts really are incredibly simple. Until they break. But, they break. Would you like to start a pool on how long it will be until this recipe breaks, or becomes hopelessly obsolete because some portion of it is now out of date? Hint one: To get an idea, one could try the problem in reverse: How far back in time can you go before you reach a time when this script would not have worked yet? (Hint one, sub-hint A: The first commit to Homebrew's Git repo was in May of 2009.) Hint two: Homebrew formulae aren't guaranteed to build at all times. They sometimes have bugs, especially when any of their dependencies (including the version of OS X itself) has recently changed. Those bugs tend to manifest as scary messages from (e.g.) the linker. Hint three: Better get that version number out of the recipe before placing the bet. 1.9.2-p290 could become hopelessly obsolete at literally any minute; we're always just one zero-day away. It would be more reliable to pull that number from some canonical source like… um, any ideas? What is the answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" I don't know what your answer might be, but mine would be "pay someone like Yehuda Katz or the Rails core team to continuously recompute the answer, and to maintain the website that hosts the answer".

moe 15y ago
Well, that was the most reasonable response so far, at least you know what you're talking about. But, they break. The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters). Isn't rails the one with the 17 different testing frameworks and TDD kool-aid? How about adding structured tests for the installation procedure, too? Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable. Hint one, two, three The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?). answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies). The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation). It's not as hard as you make it out to be, really.