Do you develop stuff locally or on a server?

Sorry if this is an obvious question but I’ve been searching around for
an hour with no luck. As a novice programmer, I have no idea what good
programming practice is.

I’m trying to code a web app with a friend, and we’re not sure how we
should set up our development environment. Is it preferable to

a) edit files on the local machine and test it there, submitting changes
to our production server when they’re ready?

or b) to have test apps on the same server as our production app, and
edit files through some FTP-capable editor?

How do you set up your development environment? As a followup question,
do you prefer IDEs or editor + console? I’m using RadRails now but I’m
not sure how I’d get it to work with option b above.

to our production server when they’re ready?

or b) to have test apps on the same server as our production app, and
edit files through some FTP-capable editor?

How do you set up your development environment? As a followup
question,
do you prefer IDEs or editor + console? I’m using RadRails now but I’m
not sure how I’d get it to work with option b above.

If it were me…

I’d develop on my local box (osx in this case, but it doesn’t really
matter). Everything I do is checked into version control (subversion
or git). Version control will make it much easier for you and your
friend to work simultaneously without overwriting each other’s changes.

Then use Capistrano to deploy your application to production (after
testing of course).

-philip

Philip H. wrote:

to our production server when they�re ready?

or b) to have test apps on the same server as our production app, and
edit files through some FTP-capable editor?

How do you set up your development environment? As a followup
question,
do you prefer IDEs or editor + console? I�m using RadRails now but I�m
not sure how I�d get it to work with option b above.

If it were me…

I’d develop on my local box (osx in this case, but it doesn’t really
matter). Everything I do is checked into version control (subversion
or git). Version control will make it much easier for you and your
friend to work simultaneously without overwriting each other’s changes.

Then use Capistrano to deploy your application to production (after
testing of course).

-philip

Thanks for the answer Philip. When I was coding PHP I edited all the
files directly on the server, and checked changes into the repository
from there. I figured working directly on the server cuts out all the
extra variables introduced by my local machine (Windows, different
database)… Why do you suggest working locally?

As a possible scenario, say me and my friend are working in different
places and he has a problem in his code that he wants to show me - he’d
need to either check it in or e-mail me the file for me to be able to
see it, right? Seems a bit cumbersome.

Personally, I develop on a windows box using rad rails, but I have a
copy of
andLinux running in the background that has access to my rails
environment.
This way I can test on linux and windows at the same time (I actually
run it
on linux more than windows since the gd2 gem will only work correctly on
linux).

I definitely wouldn’t code without subversion, even if you are going at
it
alone. Your friend could check in his code as a branch and that would
allow
you to have a completely separate environment that mirrors his. Rad
rails
(aptana or eclipse) even has a plugin called subclipse that allows you
to do
all the version control stuff right from your IDE. I love how rad rails
does
syntax highlighting and hierarchy browsing, but I personally use the
console
for running the server or script/console. All you need to set up a
subversion server is a computer that is always running (I bought an old
server from craigslist, but before that I just used an old p3-800 box
with
ubuntu server on it - but you could even put it on your windows box).

I think once you learn a little subversion, you will be amazed that you
ever
coded without it… especially the first time you realize that you wish
you
knew what you did that caused some particular bug.

Hope that helped

On Tue, Jul 1, 2008 at 11:11 PM, Ro Ma
[email protected]

P.S.

Another thing you might want to look into is trac. It is a subversion
front
end and a wiki. It is great for tracking what is going on in your
project,
plus it gives you diffs between each check in so you can know exactly
what
changed when.

Its always advisable to work locally…then there should be a
testing server on which things should be tested and finally if every
thing goes well it should be made live…

This is wat most people follow

Hope this helps

thanks

Dhaval P.
Software Engineer
Ruby on Rails

sales(at)railshouse(dot)com

Setting up a development environment is a personal thing, especially
when you’re not required by a company to do certain things. That said,
I’d agree with several people that it is easier to work locally and
with a version control system. You’ll have a larger range of tools you
can use, and once you ‘go-live’ on the server, you can continue
developing locally without changing the live version until you want to
release the new features.

Since nobody has mentioned distributed version control systems (eg.
git/mercurial) I’ll put in a plug for them here…You and your friend
can use the same repository as a baseline, and they both have
mechanisms to transfer changes by the network (you could even use this
to deploy to the ‘production’ server if you’re careful)
Both git & mercurial are dirt-simple to setup…while other revision
control systems require a bit more care/time to setup.

-Dale

On 02 Jul 2008, at 05:28, Joe K wrote:

Another thing you might want to look into is trac. It is a
subversion front end and a wiki. It is great for tracking what is
going on in your project, plus it gives you diffs between each check
in so you can know exactly what changed when.

That said, we’ve ditched Subversion completely in favor of git and it
was the best decision ever made. Branches finally make sense, we don’t
need to commit to a central repository anymore if it’s just calling in
for help (and my fellow programmer lives 100 km away from me), it
doesn’t litter every folder with .svn files, it’s more logical and we
can use it offline without a problem (i.e. I commit more and then push
a handful of commits to the main remote repository). Subversion has
had it for us.

Best regards

Peter De Berdt

I work with Ruby on Rails. Why I work locally ?

  1. Work locally can use many IDE’s as you like
  2. Work locally doesnt take any bandwith
  3. Work locally can test any script in console
  4. Work locally can use any System Operation

About your friend in another place that wanted to see your script or
work, you can save your local working to subversion online. Joe has
given a clue, it’s nice. What Philip and Joe Said are the same to what
we do here. I think you should know CakePHP, it is the same like Ruby on
Rails, you develop locally or develop in development environment then
use capistrano to move your develop job to production environment (Real
World Server) Your friend can download repository or Subversion of your
development files remotely online where ever they are without effect any
risk to files in production server or real-world server.

Reinhart
http://teapoci.blogspot.com

not sure how I�d get it to work with option b above.
testing of course).

Thanks for the answer Philip. When I was coding PHP I edited all the
files directly on the server, and checked changes into the repository
from there. I figured working directly on the server cuts out all the
extra variables introduced by my local machine (Windows, different
database)… Why do you suggest working locally?

In addition to the reasons others have posted a couple more are…

  • The Internet doesn’t matter. It can go down you don’t care. You
    could take your laptop out into the woods, doesn’t matter. That’s a
    nice feature.

  • By developing locally you may perhaps avoid some “os specific” cases
    where something works on “RandomLinux 4.3.2 Patch Level Fubar” that
    you don’t realize is specific to that distro. Of course that can cut
    the other way when dealing with Windows where a lot of things won’t
    run properly :/, but still I like removing any platform specific
    tendencies.

As a possible scenario, say me and my friend are working in different
places and he has a problem in his code that he wants to show me -
he’d
need to either check it in or e-mail me the file for me to be able to
see it, right? Seems a bit cumbersome.

Or setup/use some sort of screen sharing and there is a lot of options
there. For the last two years I’ve worked remotely with a small team
(4 developers, 2 designers, one qa) of mostly remote people and I
can’t think of the last time I had to look at one of their sites.
Which probably means they’d check it in and I’d look at it locally.

-philip

Joe K wrote:

Personally, I develop on a windows box using rad rails, but I have a
copy of
andLinux running in the background that has access to my rails
environment.
This way I can test on linux and windows at the same time (I actually
run it
on linux more than windows since the gd2 gem will only work correctly on
linux).

hi joe I read that you are using andLinux on developing rubyonrails.can
you please give me an instruction on how to install ruby on rails on
andLinux.I try to googling to find the instruction on how but I didn’t
find.
I’m using windows xp for developing php website that why I need to
install andlinux for RoR.

Your response will give an good idea to thus how want to try ruby on
rails on linux without changing their win os.

thank you n advance

On Tue, Jul 1, 2008 at 10:11 PM, Ro Ma
[email protected] wrote:

Why do you suggest working locally?

  1. Because emacs/vim over SSH sucks (or will on a bad day).

  2. Your hosting provider doesn’t want you running your test suite on
    their production server.

  3. Developing locally adds the ability to code while on a plane, at a
    baseball park or the nudy bar.

Match up gem list --local locally with your remote server and your
dependency issues are 99% resolved.


Greg D.
http://destiney.com/