Forum: Ruby on Rails The perfect development environment?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
905e2cc8f988c9d09c5efae6b4c48856?d=identicon&s=25 Nick Hird (Guest)
on 2006-05-05 17:28
(Received via mailing list)
I am trying to create the perfect development environment for rails
and i dont know exactly which way to go. Do i create a windows
environment or a *nix environment. If i go *nix, what distro is best
suited for rails. I would be using mysql, so that would come in to
play. If i go *nix, i would use apache. Any ideas for the right
environment would be greatly appreciated. I guess the major choice is
what environment. The what web server and so on.
Thanks,
-Nick
4ae3c0b56fcf66f8383ecb73cc8d956e?d=identicon&s=25 Chris Winslett (supasta)
on 2006-05-05 17:33
RadRails w/MySQL on a Windows machine.

Dual monitors makes it better to.  If you can, but a beverage caddie
that brings free beverages.

That would be a good development environment.
E774b0336459ccf859777acfa27b57b8?d=identicon&s=25 Matt Heagney (Guest)
on 2006-05-05 18:17
(Received via mailing list)
Nick Hird <nrhird@...> writes:

>
> I am trying to create the perfect development environment for rails
> and i dont know exactly which way to go.


Mac OS X or Linux on a 17" powerbook G4.
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-05-05 18:43
Develop locally against WEBrick. Don't develop remotely and don't
develop against Apache. Apache is for deployment. If you don't already
know how to configure Apache by hand when it comes time to work on
deployment, consider Lighttpd.

Use RadRails as your IDE. Check your code in and out of Subversion,
beacuase not using version control is foolish and because when you want
to download some plugins to use in  building your app, you'll find most
of them are most easily installed vis SVN anyway. The only reason to
consider any other version control system should be because your company
policy dictates something else, or you're a guru in it.

Install the core of Ruby 1.8.4 and the Gems core however you want,
either as a package on your choice of *nix or via a pretty installer for
Windows.

Install Rails via the command-line "gem install [pkgname]" because it
will be much easier to maintain that way than with .debs, RPMs or WSI
installers. Besides, doing it that way works exactly the same on Windows
and *nix.

Have at least 512MB of RAM, prefereably more.

Using MySQL? Use MySQL 4.1 or 5 for compatibility, ubiquity and to have
things like transaction support available if you want to use them at
some point.

Unless you're working with a legacy database, do not use a MySQL client
for anything beyond creating the bare, empty schema and assigning
privileges. Use Migrations from the very start to create and maintain
the schema itself.

I repeat: don't create your database with a MySQL management tool or
schema designer, unless you have a specific reason for doing so.

If you're pretty sure you're going to deploy your app on Apache, then
use 2.0, because 1.3 can't host Subversion repositories and because 2.1
and 2.2 aren't very widely used and thus lag in support for things like
mod_fastcgi that compile correctly.

Do not. DO NOT. DO! NOT! DEVELOP! AGAINST! APACHE! unless you're
developing something that uses Apache for key application functionality,
like an external authentication module. If you're not absolutely certain
this is your situation, DO NOT DEVELOP AGAINST APACHE. Doing so, except
in the aforementioned edge case, is a waste of time, gains you nothing,
and may in fact hinder you. Later, if circumstances dicate, reevaluate.

Deploy on Apache? Sure!

When you're a week away from having an app far enough along to try
deploying, start reading up on Capistrano for automating deployment.

As for Windows vs. *nix, it's a matter of what you prefer to spend your
day using. Rails is Rails and with with RadRails and version control
your development experience as far as Rails goes is going to be
identical. I happen to be on Windows for development (and FreeBSD for
deployment, which is painless) because I need Windows for other apps
during my day. It also happens to force me to avoid putting
platform-specific pathnames in my code, which keeps me honest. But if
you don't need Windows for anything and are comfortable in *nix and make
good use of the commandline, go ahead and use that. Use an up-to-date
distro of whatever you like best. It doesn't matter.

Oh, and if you're on FreeBSD, use the no-pthreads version of Ruby. It's
much faster than the default one.

Nick Hird wrote:
> I am trying to create the perfect development environment for rails
> and i dont know exactly which way to go. Do i create a windows
> environment or a *nix environment. If i go *nix, what distro is best
> suited for rails. I would be using mysql, so that would come in to
> play. If i go *nix, i would use apache. Any ideas for the right
> environment would be greatly appreciated. I guess the major choice is
> what environment. The what web server and so on.
> Thanks,
> -Nick
316c03a99e8ed311e5462d94f085fc2e?d=identicon&s=25 John Ivanoff (Guest)
on 2006-05-05 19:16
(Received via mailing list)
Ruby Development Tools
RDT is an open source Ruby IDE for the Eclipse platform.
http://rubyeclipse.sourceforge.net/

You will need a Java runtime environment (JRE) to use Eclipse

eclipse http://www.eclipse.org/
you can can do alot of other dev in eclipse as well
http://www.eclipse.org/downloads/index_project.php
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-05-05 19:32
(Received via mailing list)
I've been investigating the benefits of a Mac Mini Duo 1GB RAM with the
Boot
Camp (dual-bootable) beta functionality.  If I ever *have* to utilize
something in Windows, I can...  Otherwise I can take advantage of the
sweetness that is OS X.  And I agree with the previous commentary;
Eclipse /
RadRails is a pretty good combination.  It even gives you a happy GUI
for
all the WEBrick stuff.  You wouldn't even need Apache installed if you
didn't want it.  Though I think it would be useful to "test-deploy" to
Apache locally...  And it's useful for other things...

-Curtis
5d15c6821f3c3054c04b85471824ba7c?d=identicon&s=25 Kevin Olbrich (Guest)
on 2006-05-05 20:22
(Received via mailing list)
On Friday, May 05, 2006, at 11:29 AM, Curtis wrote:
>
>> what environment. The what web server and so on.
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>

Parallels workstation does a pretty good job with this too, with the
added benefit of not having to reboot into windows and the potential for
running the server on your windows virtual machine (if you need to test
against something like MSSQL).  Being able to switch back and forth is
kind of nice, even if it is slower.

_Kevin
4ba4bb954bcfec077d9708b540558926?d=identicon&s=25 Guido Sohne (Guest)
on 2006-05-05 20:28
(Received via mailing list)
If you have any doubts at all, get the Mac mini. You can always run
Windows on it. With the mini and OS X, you get to run TextMate. I've
developed and deployed RoR on Windows, Linux and Mac, and I can say
that it's a royal PITA on Windows, Linux is faster when launching
Rails scripts etc, but Mac is great for productivity.

InstantRails sounds fine but I don't really like it. It bakes in
Apache and MySQL, so if you have those installed already, then it
becomes unwieldy. It's no substitute for an IDE, lots of the things in
Rails that are scripts have been updated to become .BAT files (ughh!)
and in short, you never know when you are going to miss out on
something due to a Windowism.

It's not an IDE at all either, just a glorified installer/launcher for
Rails. On other platforms, it just installs (aka JUST WORKS). The only
decent IDE on Windows is RadRails, which is basically Eclipse and just
as RAM hungry without a lot of the nice stuff that TextMate has.

I would pick Linux or Mac OS X over Windows for Rails development AND
deployment. That's just my personal opinion, though, YMMV.

-- G.

On 5 May 2006 18:21:43 -0000, Kevin Olbrich
Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2006-05-05 20:31
(Received via mailing list)
Zed Shaw mentioned no-pthreads and I built one on Darwin, but there are
some
caveats that the no-pthreads version may break other Ruby functionality.
Does anyone know whether this is a big deal?

>> Oh, and if you're on FreeBSD, use the no-pthreads version of Ruby. It's
much faster than the default one.

--
View this message in context:
http://www.nabble.com/The-perfect-development-envi...
Sent from the RubyOnRails Users forum at Nabble.com.
678aa0aabf79a4933b7efc6d585dc141?d=identicon&s=25 Matt White (Guest)
on 2006-05-05 20:41
(Received via mailing list)
I bought a MacBookPro for this very reason. I developed using
RadRails/Eclipse/RDT for a while, and I got tired of the bloated
Eclipse.
Also, dealing with line endings/shebang issues/executable file problems,
etc, just made working on Windows more of a headache. It's not
impossible,
and most of your problems can be solved in one place with the correct
Subversion settings and Capistrano settings, but I just found that I had
more deployment issues on the PC that made me bang my head against the
wall
when I could have been developing. Plus, Textmate really IS good, and
I've
found that I'm much happier (there's the DHH buzzword) in Textmate. It's
lightweight and speedy.

I also like running against Lighty on my Mac, because it's a little
closer
to production. And finally, I just dig the Mac interface. I was a Mac
disser
until about 6 months ago, but that's all over.

All of that said, RadRails + Webrick + Subversion is a perfectly valid
dev
environment, but you'll have more stupid little deployment problems than
you
would on a *NIX dev box.

Matt
F3f738ecc0ae99d54c4e2842cf3d520a?d=identicon&s=25 Louis Erickson (Guest)
on 2006-05-08 20:55
(Received via mailing list)
Hi, Steve.

You wrote some strongly worded advice, such as:

On Fri, 5 May 2006, Steve Koppelman wrote:

> Develop locally against WEBrick. Don't develop remotely and don't
> develop against Apache. Apache is for deployment. If you don't already
> know how to configure Apache by hand when it comes time to work on
> deployment, consider Lighttpd.
<snip>
> Do not. DO NOT. DO! NOT! DEVELOP! AGAINST! APACHE! unless you're
> developing something that uses Apache for key application functionality,
> like an external authentication module. If you're not absolutely certain
> this is your situation, DO NOT DEVELOP AGAINST APACHE. Doing so, except
> in the aforementioned edge case, is a waste of time, gains you nothing,
> and may in fact hinder you. Later, if circumstances dicate, reevaluate.

I'm curious as to why this is such an imperative?  This is not to say
that
I disagree with it, but that I don't see what is so critically difficult
about working with Rails and Apache versus any other platform.  Is Rails
FCGI so different than any other FCGI?  Or is this merely a warning that
working under a persisted FCGI environment can be a pain?

How would you suggest developing applications that require multiple
connections back to the server?  WEBrick is single-threaded and won't
handle simultaneous requests.  Is this one of the edge cases that
requires
development under Apache or is there a method to do this I simply
haven't
seen yet?

--
Louis Erickson - lerickson@rdwarf.net - http://www.rdwarf.com/~wwonko/

The best thing about growing older is that it takes such a long time.
6f7c877de704c7cc03c8a3b2dc52df92?d=identicon&s=25 Carmen --- (carmen)
on 2006-05-09 08:22
>> Do not. DO NOT. DO! NOT! DEVELOP! AGAINST! APACHE! unless you're
>> developing something that uses Apache for key application functionality,
>> like an external authentication module. If you're not absolutely certain
>> this is your situation, DO NOT DEVELOP AGAINST APACHE. Doing so, except

> I'm curious as to why this is such an imperative?  This is not to say
> that

its just fear-mongering. i used apache for years (not all of it with
rails, mainly mod_python, and about 5 years ago, PHP). works just fine

as for the perfect development environment? i think id want something
more squeak-like. im a fan of building Tk GUIs with the inline tkcon
editor, theres something about getting it right _then_ exporting it to
source code, rather than the other way around. i guess we won't see this
in rails at least until you can manipulate the entire DOM from ruby (i
think maybe kazehakase can do this now? im not sure ruby-gtkmozembed
can..) and someone builds an editor in it first..
Ca5bbfca97ef73fbaca16b1bd1aab5ad?d=identicon&s=25 paw (Guest)
on 2006-05-09 09:08
if u want to join ror
this a good website for u begin
http://www.rorlearn.com
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-09 09:32
(Received via mailing list)
paw wrote:
> if u want to join ror
> this a good website for u begin
<link snipped to avoid adding to pagerank>
So far, I'm counting plagiarised (or at least unattributed) content
from:

  - Curt Hibbs (The Tutorials section)
  - Kevin Clark (The Articles section)
  - Kyle Maxwell (RadRails 0.6.2 announcement)

Anyone I've missed?

The rails screencasts are hosted without attribution, too.  Is there any
reason to think this isn't linkfarming scum?
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-05-09 17:34
(Received via mailing list)
On May 9, 2006, at 12:29 AM, Alex Young wrote:

>
> Anyone I've missed?
>
> The rails screencasts are hosted without attribution, too.  Is
> there any reason to think this isn't linkfarming scum?


No, this looks pretty low. Definitely a link farm spammer.

-Ezra
D90ef6808433e63203e15a5c2dadb0bb?d=identicon&s=25 Ben Reubenstein (Guest)
on 2006-05-09 17:44
(Received via mailing list)
Direct complaints to:

Domain Name: RORLEARN.COM
   Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
   Whois Server: whois.melbourneit.com
   Referral URL: http://www.melbourneit.com
   Name Server: YNS2.YAHOO.COM
   Name Server: YNS1.YAHOO.COM
   Status: REGISTRAR-LOCK
   EPP Status: clientDeleteProhibited
   EPP Status: clientTransferProhibited
   EPP Status: clientUpdateProhibited
   Updated Date: 21-Apr-2006
   Creation Date: 21-Apr-2006
   Expiration Date: 21-Apr-2008

Domain Name.......... rorlearn.com
  Creation Date........ 2006-04-21
  Registration Date.... 2006-04-21
  Expiry Date.......... 2008-04-21
  Organisation Name.... CHEN YUTENG
  Organisation Address. 2135A des Laurentides Blvd., Suite 250
  Organisation Address.
  Organisation Address. Laval
  Organisation Address. H7M 4M2
  Organisation Address. Qc
  Organisation Address. CANADA

Admin Name........... Wu Hu
  Admin Address........ 2135A des Laurentides Blvd., Suite 250
  Admin Address........
  Admin Address........ Laval
  Admin Address........ H7M 4M2
  Admin Address........ Qc
  Admin Address........ CANADA
  Admin Email.......... rorlearn@yahoo.com
  Admin Phone.......... +1.6198813096
  Admin Fax............

Tech Name............ Wu Hu
  Tech Address......... 2135A des Laurentides Blvd., Suite 250
  Tech Address.........
  Tech Address......... Laval
  Tech Address......... H7M 4M2
  Tech Address......... Qc
  Tech Address......... CANADA
  Tech Email........... webmaster@rorlearn.com
  Tech Phone........... +1.6198813096
  Tech Fax.............
  Name Server.......... yns1.yahoo.com
  Name Server.......... yns2.yahoo.com


On 5/9/06, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
> >  - Curt Hibbs (The Tutorials section)
>
> -Ezra
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Ben Reubenstein
303-947-0446
http://www.benr75.com
6f7c877de704c7cc03c8a3b2dc52df92?d=identicon&s=25 Carmen --- (carmen)
on 2006-05-10 06:18

http://www.rorlearn.com

complaining about propagation of rails-evangalism content? too funny. i
was always skeptical of the 'openness' of the whole thing, with the
obvious Mac bias of the creators' marketing and attitude, and 'we'll
make a hosted app for $12.95 that does the same thing that 3 dozen free
Gnome apps that will also do the same thing' , but this seals it :)

i also thought id never live long enough that people would be fighting
over table scraps of ad revenue. can the apocalyps be far off?
7f023e9ef20f259eebbda8f5d7a88d6b?d=identicon&s=25 Ben and Kaz Askins (Guest)
on 2006-05-10 09:30
(Received via mailing list)
On 5/9/06, Alex Young <alex@blackkettle.org> wrote:
> Anyone I've missed?

Noticed some content there from Why The Lucky Stiff as well.

cheers,
Ben
6e1223f66357c249aff81e08e6cc5384?d=identicon&s=25 Andrew Duncan (Guest)
on 2006-05-10 09:42
(Received via mailing list)
On 6/05/2006, at 3:25 AM, Nick Hird wrote:

> I am trying to create the perfect development environment for rails

Locomotive and TextMate on OS X is a sweet combination.

There are good package installers for MySQL and PostgreSQL too!

Why make it harder that necessary? :o)

Andrew Duncan
------------------------------------------------------------------
tel:  +64 9 623 2926
blog: http://www.webwerks.co.nz/weblog/
------------------------------------------------------------------

Programmers do it while (1)
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-05-10 16:18
My recommendation against developing on Apache is twofold:

1. When you're new to Rails, setting up Apache+FCGI (which is what most
people do when they set out to use Apache with Rails) is often a huge
time-sink. It involves quite a few steps, especially if you don't
already have FCGI installed and configuired for something else, and it's
got several tricky bits and gotchas. You can waste a couple of days
easily trying to get FCGI working, especially if you don't understand
the Rails directory tree and how the Rails dispatch scripts do their
job.

2. Assuming you've got FCGI or SCGI set up, you've got persistence
issues to deal with. You'll be restarting those FCGI processes
frequently, a whole lot more frequently than someone developing with
WEBrick or plain CGI.

The overwhelming majority of Rails apps only need one server connection
in development mode. Development ususally only involves the individual
developer hitting the app with her/his browser. Things that require
multiple connections for development are edge cases, and by the time you
need it if you ever need it, you've probably been working with Rails
long enough and are enough of a HTTP server tweaker that running Rails
under Apache will be much easier than it would be for someone still in
the early learning stages.

My point is not that running Rails under Apache in a development
environment is evil and wrong, but that if you're not sure why you need
it, you probably don't need it and your time will be much better spent
on developing your app. If you do need it, you're probably better
equipped to set it up and deal with the idiosyncracies anyway.

I think too many people come in with a CGI and quick-and-dirty PHP
mindset, in which so much of an app leans on server functionality and
server configuration because of so many years of server-handled
authentication, config.php files full of absolute file paths and so on.
I know that when I code PHP or other CGI-style conventional web stuff, I
want my development environment to closely mirror the production server
and yes, I run Apache on my laptop, because so much that I do references
the server environment. Rails has a lot less of that. If you use
migrations and AR find helpers and you keep your machine-specific path
info to a minimum, you can usually develop on one combination of OS,
database and HTTP server and deploy on entirely another with minimal
fuss.

To each her/his own.

Louis Erickson wrote:
> Hi, Steve.
>
> You wrote some strongly worded advice, such as:
>
> On Fri, 5 May 2006, Steve Koppelman wrote:
>
>> Develop locally against WEBrick. Don't develop remotely and don't
>> develop against Apache. Apache is for deployment. If you don't already
>> know how to configure Apache by hand when it comes time to work on
>> deployment, consider Lighttpd.
> <snip>
>> Do not. DO NOT. DO! NOT! DEVELOP! AGAINST! APACHE! unless you're
>> developing something that uses Apache for key application functionality,
>> like an external authentication module. If you're not absolutely certain
>> this is your situation, DO NOT DEVELOP AGAINST APACHE. Doing so, except
>> in the aforementioned edge case, is a waste of time, gains you nothing,
>> and may in fact hinder you. Later, if circumstances dicate, reevaluate.
>
> I'm curious as to why this is such an imperative?  This is not to say
> that
> I disagree with it, but that I don't see what is so critically difficult
> about working with Rails and Apache versus any other platform.  Is Rails
> FCGI so different than any other FCGI?  Or is this merely a warning that
> working under a persisted FCGI environment can be a pain?
>
> How would you suggest developing applications that require multiple
> connections back to the server?  WEBrick is single-threaded and won't
> handle simultaneous requests.  Is this one of the edge cases that
> requires
> development under Apache or is there a method to do this I simply
> haven't
> seen yet?
>
> --
> Louis Erickson - lerickson@rdwarf.net - http://www.rdwarf.com/~wwonko/
>
> The best thing about growing older is that it takes such a long time.
B11589d2872aa2f284980d9f5ef08f65?d=identicon&s=25 Andrew H. Johnson (Guest)
on 2006-05-10 16:25
(Received via mailing list)
cdr wrote:
> http://www.rorlearn.com
>
> complaining about propagation of rails-evangalism content? too funny. i
> was always skeptical of the 'openness' of the whole thing, with the
> obvious Mac bias of the creators' marketing and attitude, and 'we'll
> make a hosted app for $12.95 that does the same thing that 3 dozen free
> Gnome apps that will also do the same thing' , but this seals it :)
>
> i also thought id never live long enough that people would be fighting
> over table scraps of ad revenue. can the apocalyps be far off
It's about giving credit where credit is due.  The author deceitfully
takes articles and pastes them into his site without any cite of where
they have been taken from.  I can go to the original article sites
without sitting through disruptive advertisements and pop-up ads as
well.

My $.02
This topic is locked and can not be replied to.