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?
Hi,
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…
Hope that helps,
Chris
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.
2009/9/2 AlwaysCharging [email protected]:
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?
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.
Colin
AlwaysCharging wrote:
So, how do you recommend installing rails on vista? Would using
Instant Rails really prove that bad in the long run?
- Install VMWare
- Install your favorite flavor of Linux
- Install Ruby
- Install RubyGems
- gem install rails
- There is no step 6.
I know… I couldn’t resist. 
Thank you for that. Through a link in that post, I found this:
and it was really helpful.
Also, thanks to everyone else that chimed. I’ll definitely have to
look into virtual machines.
And don’t forget the SQLite Manager Firefox plugin:
https://addons.mozilla.org/en-US/firefox/addon/5817
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 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.
Chris
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.
Lee S. wrote:
And don’t forget the SQLite Manager Firefox plugin:
https://addons.mozilla.org/en-US/firefox/addon/5817
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.
That sounds neat. I’ll have to check it out.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
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.
On Sep 3, 12:04 am, Marnen Laibow-Koser <rails-mailing-l…@andreas-
Lee S. wrote:
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.
I figured that. But what good is it if its syntax is incompatible with
that of your production DB?
The
firefox plugin is icing on the cake.
And pretty interesting icing.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
2009/9/3 JL Smith [email protected]:
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.
Colin
Lee S. wrote:
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.
That’s true, of course. And I’ve used PostgreSQL for dev with mySQL in
production. However, I was under the impression that SQLite simply had
no equivalent for a lot of fairly common PG or mySQL tasks. I was also
under the impression that if you need, say, a custom :conditions string,
SQLite’s syntax is likely to be different from the other two. I could
be wrong.
In any case, it’s kind of a moot point for me, at least on my major
project ( http://quorum2.sf.net ), since that uses PostGIS.
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.
It’s a little easier to install, but I tend to think defaulting to
SQLite was a mistake.
On Sep 3, 12:04�am, Marnen Laibow-Koser <rails-mailing-l…@andreas-
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Lee S. wrote:
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.
Right.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
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.
On Sep 3, 9:55 am, Marnen Laibow-Koser <rails-mailing-l…@andreas-