Rails - Sep 2009 - What's the best way to install Rails? (on vista)

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...

http://ganee.blogspot.com/2007/07/ruby-rails-keretapi-tanah-melayu-doesnt.html


Hope that helps,

Chris

On Sep 2, 2:43 pm, AlwaysCharging
<goodg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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?

2009/9/2 AlwaysCharging
<goodgets-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> 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

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

On Sep 2, 3:26 pm, Colin Law
<clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
> 2009/9/2 AlwaysCharging
<goodg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>
>
> > 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

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.
-- 
Posted via http://www.ruby-forum.com/.

AlwaysCharging wrote:
> So, how do you recommend installing rails on vista?  Would using
> Instant Rails really prove that bad in the long run?
1. Install VMWare
2. Install your favorite flavor of Linux
3. Install Ruby
4. Install RubyGems
5. gem install rails
6. There is no step 6.

I know... I couldn''t resist. ;)
-- 
Posted via http://www.ruby-forum.com/.

Thank you for that.  Through a link in that post, I found this:
http://allaboutruby.wordpress.com/2009/07/20/installing-rails-on-windows-3-years-later/
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.

Lee Smith 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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 Smith 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

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-
s.net> wrote:
> Lee Smith 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-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> --
> Posted viahttp://www.ruby-forum.com/.

Lee Smith 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

2009/9/3 JL Smith
<autiger02-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> 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
>
> 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-
> s.net> wrote:
>> Lee Smith 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-Koserhttp://www.marnen.org
>> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>>
>> --
>> Posted viahttp://www.ruby-forum.com/.
> >
>

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-
s.net> wrote:
> 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.

Lee Smith 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.