81–90 of 100 posts
Earlier quoted context omitted.
There's a free 200MB download of the command line build utilities. Xcode proper (4+ GB) is also free ...
I was unable to find free versions of either of these, for Snow Leopard, when I looked a year ago. At that time, Lion was utterly unusable (not sure if it's any better), so I just gave up and got a Linux VM for that laptop.
Maybe I'm coming at this from a different perspective as I've spent a number of years doing that whole "NINJAS BUILD FROM SRC.TAR" thing, but installing Rails under Mac has always been pretty straight forward. Get RVM > Get Ruby Version X > RubyGems > Rails > then fork off for databases if I want something fancy. You are installing something that by it's nature requires a bit more understanding that just clicking on…
> You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe. Well the default installation shouldn't. The default installation should be for someone who just wants to try Ruby out, that will just set things up to work, and won't interfere with anything else on the system (except for integrating with the webserver you're using). Like PHP does. Then they can mess ar…
Ruby does come with Mac. Ruby is not Rails. The default installation allows anyone to try Ruby.
Earlier quoted context omitted.
I use and love Ruby every day, but this package management business is ... irksome. First the Ruby guys crapped all over package management from Debian, who, despite their shortcomings, have been doing it a while and know a thing or two about it. That wasn't entirely unfounded, because there were some messy things there, and the intersection of two different package management systems is bound to be a bit confused. N…
> Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does. But what it does moves at about 10% of the speed of the ruby community (at least post-Rails). I'm not saying that the ruby culture is better—it obviously has serious consequences for stability and leads to all manner of headaches. However it does mean that if a new and better idea of how to do something comes out, Ruby is p…
Earlier quoted context omitted.
> Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does. But what it does moves at about 10% of the speed of the ruby community (at least post-Rails). I'm not saying that the ruby culture is better—it obviously has serious consequences for stability and leads to all manner of headaches. However it does mean that if a new and better idea of how to do something comes out, Ruby is p…
Surely bundler helps solve some of these problems; at least it makes managing gems easier on a per-app basis.
http://serverfault.com/questions/405994/state-of-the-art-dep...
And you're either stuck with this Mongrel-derived nonsense that is incapable of utilizing the computing power of the server to dynamically (de)allocate resources, requiring you to pick numbers at setup time, or you've got Passenger, which gets that right, but basically nails your deployment to one and only one Ruby.
(Yes, I've not had the best of days...does it show?)
Maybe I'm coming at this from a different perspective as I've spent a number of years doing that whole "NINJAS BUILD FROM SRC.TAR" thing, but installing Rails under Mac has always been pretty straight forward. Get RVM > Get Ruby Version X > RubyGems > Rails > then fork off for databases if I want something fancy. You are installing something that by it's nature requires a bit more understanding that just clicking on…
I see this process somewhat analogous to learning a new musical instrument, like a violin. A professional violinist may care to customize many aspects of the instrument to meet his or her needs, including the turning of the instrument (perhaps he cares to set A to 416 to emulate Baroque turning). A beginner, by contrast, would just like to be handed a well tuned instrument ready to learn and experiment. Now, would it kill that beginner to set and tune his own set of strings, or maybe given the options to set his violin to Baroque turning as well? Certainly not - though the necessity and benefits of such an exercise would surely be lost on many beginners.
Earlier quoted context omitted.
Why on earth should you have to run a VM in order to run a programming language? This hasn't solved the problem of Ruby being difficult to install, it's just added ANOTHER problem of having to learn to install a VM manager and a whole new OS, plus using up far more system resources. Seems to me like that's just making things worse.
Why on earth should you have to recreate your sever stack on a desktop OS? Seems like you're just begging to be bitten by some OS-specific bug or quirk. It solves the problem of Rails being hard to install on OS X... because it obviates the need to install Rails on OS X. And there's no new OS to learn -- the VM runs the same thing as your server. If you don't know how to use the OS that's running on your production s…
Similarly, when you start a new web app, of course a monolithic framework like Rails is great and is flexible enough to roll in all your business logic. Somewhere around 50k lines though, you start getting that ball of mud feeling and managing changes across the entire code base starts to become onerous. At that point you realize the sysadmin overhead, and cost of defining and maintaining slow-moving services interfaces allows you to turn your ten-person team into ten ten-person teams and get a reasonable productivity multiple out of the deal.
Earlier quoted context omitted.
> Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does. But what it does moves at about 10% of the speed of the ruby community (at least post-Rails). I'm not saying that the ruby culture is better—it obviously has serious consequences for stability and leads to all manner of headaches. However it does mean that if a new and better idea of how to do something comes out, Ruby is p…
I didn't meant to say that Ruby should use Debian package management or anything like that: it needs its own stuff at its own speed. More that they should be a bit slower on the draw when it comes to pissing on other people's work.
Earlier quoted context omitted.
How is it any different from downloading any other code and running it? Are you saying you audit every piece of unsigned code you run? I admit that putting bit.ly into the chain of trust is quite a bold step, but is it really that different to, say, the rubygems server? Or your wireless router? EDIT: also, LOL at "mundanes."
Imagine Bit.ly gets backdoored, and that shortlink is repointed at a script that just contains rm -rf /
As a non-developer who has tried several times to learn, I can say with 100% confidence that setting up a dev environment and workflow is fucking maddening. It's a major barrier to learning and I hate that it's as complex as it is. Should be turn-key.
Now try installing rails on a windows machine; that's the real pain in the ass.
Unless you're planning to deploy to a production server running OS X, I don't see why you'd care about Rails running natively on your Mac. Why not develop against a VM running the same OS as your server?
Why on earth should you have to run a VM in order to run a programming language? This hasn't solved the problem of Ruby being difficult to install, it's just added ANOTHER problem of having to learn to install a VM manager and a whole new OS, plus using up far more system resources. Seems to me like that's just making things worse.