I know about Instant Rails (which I've used in the past), but it seems
so dated. I know everything can be updated fairly easy, but is
Instant Rails really the 'best way' to install rails? I know it might
be the easiest, but usually easiest and best are never the same. I'm
asking because I'd rather go through a couple more headaches up front
than encounter a lot of frustration down the road.
So, how do you recommend installing rails on vista? Would using
Instant Rails really prove that bad in the long run?
I don't use Vista any longer, but when I did I used the following URL
http://rubyforge.org/frs/?group_id=167 . This is an old version so you
will have to upgrade everything once it's installed. I'm not sure
whats all involved in the upgrade. Or you can try this link I found
for installing on vista...
Here's a link to a blog post on how to install it...
If you would rather go through a couple of headaches up front and
reduce frustration down the road then I would seriously suggest
setting up a dual boot with windows and Ubuntu (or similar). I took
this path six months ago and have wondered why I did not do it
earlier. It is fantastic to feel in control of the machine again. My
desktop is now almost a Windows Free Zone.
I second that Colin - I changed from windows to a mac about 3 months
ago and love it. I'm not advocating a mac because they are expensive,
but ubuntu is in all honesty very similar and just as capable. It will
probably be my next move after my mac dies. It makes rails development
way more seamless and integrated. Just an idea - I know it's probably
not the first thing you want to do.
Depends on how deep you want your knowledge to go.
One-click installs may be nice, but when issues occur, and they will,
who has the foundational knowledge of what pieces and parts are making
your application work?
When first exploring Rails (in Windows for curiousity), then through an
Ubuntu install in a VM, to installing on a headless server at work, I
kept a notebook of the install/maintenance steps for each platform.
I know what version of Rails, rubygems, this or that gem or library that
was pulled from apt-get, or built on that machine is on each platform.
Sure makes it easier to triage issues when I can google for assistance
on a specific version of a gem, or library.
I say "roll your own"... who knows, you might even learn something.
I used to be dead set on installing and developing on MySQL...no more
of that. SQLite is too easy to work with...lightweight, no
headaches. And the Firefox plugin is the complete interface to the
db....rocks.
I used to be dead set on installing and developing on MySQL...no more
of that. SQLite is too easy to work with...lightweight, no
headaches.
Except that it's unsuitable for production and (as I understand) has
somewhat different syntax from mySQL. Personally, I use PostgreSQL for
both development and production.
And the Firefox plugin is the complete interface to the
db....rocks.
I guess I didn't clarify that...I'm simply saying that I use SQLite
for development because it's so lightweight and easy to setup. The
firefox plugin is icing on the cake.
Incompatible with production DB? Rails/ActiveRecord is database
independent (as long as you aren't using proprietary functions in raw
SQL queries). The code you wrote in development against a SQLite
database will work with MySQL, Oracle, Postgresql, etc. in production
with simply a change to database.yml. That's one of the biggest
selling points of Rails.
Since SQLite is "serverless", it's the easiest to get up and running
for development. I'm sure that's why Rails defaults to SQLite. But
hardly anyone recommends SQLite for production, obviously.
Incompatible with production DB? Rails/ActiveRecord is database
independent (as long as you aren't using proprietary functions in raw
SQL queries). The code you wrote in development against a SQLite
database will work with MySQL, Oracle, Postgresql, etc. in production
with simply a change to database.yml. That's one of the biggest
selling points of Rails.
Personally I am uncomfortable with using different db servers in the
different environments, particularly between test and production. I
like the test environment to be as similar to production as feasible.
That logic applies to all the databases. The moment you use
proprietary database functions in your SQL, you have just locked
yourself in to using that database vendor. That same function may or
may not exist with another database vendor. Not that it's a bad
thing, just that your code is not database independent.
That logic applies to all the databases. The moment you use
proprietary database functions in your SQL, you have just locked
yourself in to using that database vendor.
I'm not talking about proprietary stuff. I'm talking about common stuff
that's implemented in both DBs with different syntax. Generally one
follows the SQL standard and one does not (e.g. standard and PG || vs.
mySQL concat()).
That same function may or
may not exist with another database vendor. Not that it's a bad
thing, just that your code is not database independent.
