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. Can anybody help with this?
on 2007-06-01 05:02
on 2007-06-01 05:16
riverdog wrote: > > Can anybody help with this? Sure. You just go to theclient:3000, i.e., you add the port to the URL. http://www.someclent.com:3000 You have to make sure that whatever firewalls are in between will pass that port through. --Al Evans
on 2007-06-01 05:17
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.
on 2007-06-01 05:33
Thanks Al, 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. -Rick
on 2007-06-01 05:39
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.
on 2007-06-01 05:43
Thanks flukus. 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
on 2007-06-01 05:44
On Jun 1, 1:32 pm, riverdog <r...@vestanotes.com> wrote: > Thanks Al, > > 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. > > -Rick Hi 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).
on 2007-06-01 05:49
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. HTH, Kevin Skoglund
on 2007-06-01 05:51
On Jun 1, 1:43 pm, riverdog <r...@vestanotes.com> wrote: > Thanks flukus. > > 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? 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.
on 2007-06-01 05:52
Okay. 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 for your input. -R
on 2007-06-01 06:04
Kevin, flukus and Al, 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. Thanks again, -Rick