I've been reading and reading about rails and I'm eager to get started
- but I've got a question that no literature seems to address.
Every rails book tells you how easy it is to start a sample rails app
by starting up the server and goign to localhost:3000.
BUT -
what if I'm working from a client?
As a Dreamweaver user, I'm used ot working on the client - uploading
to the server (Apache on Linux) and then going to a browser to see my
result. However, every rails book I see tells you to go to localhost:
3000. I'm not on the localhost. I'm on the client.
It concerns me because if we have several developers working on one
rails app, they will not be able to work on localhost simultaneously.
So I would think that you would be able to program remotely from a
client - but then, I'm bothered by the fact that not a single book
I've come across tells you to go to /ipaddress:3000 - they all say go
to localhost:3000.
I can see myself loading a temporary server on my client and then
using capistrano to deploy it to my server, but this seems very clumsy
for a framework that touts simplicity.
technically you still can. Just substitute localhost witht the IP of
the rails server.
The better way is to setup a subversion repository where your
developers can check out a local copy (stops people breaking each
others code) and all run their own localhosts.
I'll check the firewall to help with this.
But I guess the bigger question is - it appears to me from reading the
guides that the actual programming has to be done on the server. Is
this true or am I reading this wrong? Dreamweaver lets me code on the
client - upload to the server and watch it run. It appears that rails
needs to be worked on in the server environment. I hope I'm wrong.
It sounds as though your mis understading what localhost actually is.
localhost is essentially what ever computer you are working on. So if
i visit localhost here I see a server running on my computer, if you
type it you will see yours.
Basicly everyone runs a developement server on their own computer,
once it's debugged etc then you upload it to the real server.
I guess I'm confused because Rails has a development-test-production
convention, and it also has versioning built in. So why would we need
to check out local copies - if we would have versions on the server
that each developer has made changes to and can roll back?
We currently program traditional software and we have a repository
where we have to check files out and lock them. My first reading of
Rails is that it has versioning built-it - and that since it is a web-
based framework - the updates are live. It makes no sense to me to
have to download and upload versions of the app to each developers
client. It would make much more sense to me to give developers the
power to develop from the client and upload to the server to a
development version, which can then be tested before going to
production.
-Rick
Most rails developers use a local development environment, and a
remote production server.
So while developing, they run mysql/apache/rails on their own computer
(client). There's no need to keep uploading, all you need to do is
refresh the page to see your changes. You can also develop without
network or internet access.
If you're working in a team, each developer runs their own local
development environment and source control is used to keep everything
in check. Subversion is the most common source control tool used I
think.
Once you have a version of your app ready for production, only then do
you upload it to the remote server.
It's a slightly different way of working to what it appears you're
used to, but it does work well once you get your head around the
differences. I have worked the Dreamweaver way before, and I much
prefer the Rails way to doing things (although this method of
development certainly isn't unique to Rails).
WebBrick (which comes with Rails) or Mongrel (which you can get from
http://mongrel.rubyforge.org/) are simple, small webservers that you
can run on your client if you don't have another web server. They
both listens for requests on port 3000. Most tutorials will teach you
how to launch WebBrick and that's why they are directing you to use
"localhost:3000".
If you have a Mac, you also have Apache installed. It, like most web
servers, listens on port 80.
1. Develop on your client, using a local web server.
2. Then upload the files to the hosted Linux/Apache web server.
Rails has absolutely no versioning built in. The development-test-
production stuff is whats known as staging.
Lets say version 1 is on the server and version 2 is on your computer.
If you upload version 2 then you will have version 2 on the server,
except it will use the production settings instead of the development
ones.
I think I get it. Although I'm a bit disappointed.
I don't see why a team cannot leverage the production server better by
doing the versioning on the server instead each developer having a
copy of the entire app & server on their computer. That seems very
inefficient.
When I first started conceptualizing RAILS, I got really excited
because of the ability to leverage the server - having each developer
access the server code - update it on the development folder - sending
it to the test folder and once it passes - on to production. It seems
very un-web-like to have each developer code and test on his own
computer and then upload to the server.
Perhaps the framework could be extended in the future to help teams
work together on the server instead of doing uploads.
Thanks. You guys are great and you answered my newbie question! I
will jump in and go for it on my own computer. I already have
everything on my own computer to do that - I was just not sure if that
was the way it was supposed to work.
We currently use StarTeam as a repository or (versioning) tool for our
Delphi software development with all our developers able to access and
run the TIP version from our server. Subversion will probably work in
a similar way.
