Who needs testing servers?

Meep3d

We have a very strange system at the place I work for writing code (PHP). Here's the rough process.

Open a file stored on a local network share, edit then save it in place.
Use an FTP program to upload the just edited file to a webserver.
Reload remote server in your browser to see what you broke.

There is no CVS involved, the network share you have to save it on first is just literally a file dump, but is mandated it must be kept 100% up to date, so simply editing the remote FTP folder directly is a no go. Obviously save, click-drag, wait for ftp, refresh gets a bit annoying after a while so my idea was to replace the network share that we are saving everything on anyway with a testing environment (which I even set up) so that changes could be tested and verified before uploading (often straight to a live site!) and to save the hassle of uploading absolutely everything, since our internet connection is erratic at best anyway. There would be no difference to the process if you still wanted to upload before testing (for whatever daft reason) as the network share would still exist, only it would now have a copy of apache looking at it.

Yet for some reason my idea is apparently too complicated (despite already being implemented and active) - that's right, a web development company can't have an internal testing server as it's 'too complicated'.

:)

morbiuswilters

How about making a copy of the file on the production server, editing it in vim over ssh, making a backup copy of the file when you are ready to test and then copying the new file over the old? And having the only form of revision control be files like file_name_backup_jan_10-2004.php?

rohypnol

@morbiuswilters said:

How about making a copy of the file on the production server, editing it in vim over ssh <...snip...>

And there you have TRWTF: using or recommending people to use things like vim.

*ducks*

dtech

@rohypnol said:

And there you have TRWTF: using or recommending people to use things like vim.
*ducks*

That's right. Every distro should just make /usr/bin/vim a symlink to /usr/bin/emacs. Everybody will be much happier!

DOA

Damn... you should have named this post Complete Fail.

Maybe if you automated the ftp upload somehow and offered that to management bundled with the test enviroment idea? Or maybe source control set to update the network share automatically on commit just to keep the idiots happy?

Heron

@Meep3d said:

Yet for some reason my idea is apparently too complicated (despite already being implemented and active) - that's right, a web development company can't have an internal testing server as it's 'too complicated'.

Something similar happened to me last September. I suggested that we stop paying someone else to host our forums, since we already had a webserver and could do it for free. The response was "it'd be too hard, too expensive, etc etc to move it." So I took half an hour and copied the existing forum to our own webserver, and migrated it to SMF (from IPB) without losing any users, posts, or attachments.

The answer was still no, despite already having a working, migrated forum. They hadn't paid the renewal fee yet, either... *sigh*.

Zemm

@dtech said:

That's right. Every distro should just make /usr/bin/vim a symlink to /usr/bin/emacs. Everybody will be much happier!

ithere's nothing wrong with me<esc>bdwavim<esc>:wq

tdb

@dtech said:

@rohypnol said:
And there you have TRWTF: using or recommending people to use things like vim.
*ducks*

That's right. Every distro should just make /usr/bin/vim a symlink to /usr/bin/emacs. Everybody will be much happier!

No, ed!

On a more serious note, I prefer Vim. Emacs is just too unwieldy with its extravagant use of modifiers and key sequences.

aflag

@rohypnol said:

@morbiuswilters said:
How about making a copy of the file on the production server, editing it in vim over ssh <...snip...>

And there you have TRWTF: using or recommending people to use things like vim.
*ducks*

You're right. Everyone knows ed is the only true editor.

morbiuswilters

@aflag said:

@rohypnol said:
@morbiuswilters said:
How about making a copy of the file on the production server, editing it in vim over ssh <...snip...>

And there you have TRWTF: using or recommending people to use things like vim.
*ducks*
You're right. Everyone knows ed is the only true editor.

inb4 "magnet and a steady hand"

cconroy

@morbiuswilters said:

Filed under: If anyone posts that fucking "butterfly" xkcd I will murder them.

You know, there's an emacs command to do that. M-x kill-matching-xkcd-posters, IIRC.

aflag

@morbiuswilters said:

@aflag said:
@rohypnol said:
@morbiuswilters said:
How about making a copy of the file on the production server, editing it in vim over ssh <...snip...>

And there you have TRWTF: using or recommending people to use things like vim.
*ducks*
You're right. Everyone knows ed is the only true editor.
inb4 "magnet and a steady hand"

That was more of a reference to: http://www.gnu.org/fun/jokes/ed.msg.html

TwelveBaud1

@aflag said:

That was more of a reference to:

yeah, we saw the link. But all religious wars over editors end when someone talks about how they open their hands, let a butterfly's wings flap once, disturbing eddy currents in the upper atmosphere, causing a cosmic-ray-deflecting lens to form, which, when hit, focuses the rays on a desired bit on the hard drive to flip.

And then someone quotes the emacs command to invoke that.

Damnit, emacs. >_<

As for my personal preference, PINE for the win.

tdb

@TwelveBaud said:

As for my personal preference, PINE for the win.

Pine is a mail reader. Perhaps you meant pico, which it uses as an editor?

Burnstreet

@aflag said:

@rohypnol said:
@morbiuswilters said:
How about making a copy of the file on the production server, editing it in vim over ssh <...snip...>

And there you have TRWTF: using or recommending people to use things like vim.
*ducks*
You're right. Everyone knows ed is the only true editor.

Ya'll unix folks, let me tell you: EDIT.COM reigns. Notepad.exe is its righteous son. And the holy Word will guide your destiny.

TwelveBaud1

@Burnstreet said:

Ya'll unix folks, let me tell you: EDIT.COM reigns.

Oh, the special backdoor mode to the QBASIC IDE? Yeah... no... I'm not really into going in the back door.

[code]edlin[/code] ftw!

bjolling

@TwelveBaud said:

@Burnstreet said:
Ya'll unix folks, let me tell you: EDIT.COM reigns.
Oh, the special backdoor mode to the QBASIC IDE? Yeah... no... I'm not really into going in the back door.
<font size="2" face="Lucida Console">edlin</font> ftw!

c:\>copy con newfile.txt
This is a new file. Copy con FTW. Control Z for the EOF
^Z
c:\>type newfile.txt
This is a new file. Copy con FTW. Control Z for the EOF
c:\>

CDarklock

We had a similar system at a client site once. We handled it like this:

- Install Apache on local machine
- Copy entire file share to local machine
- Make changes and test
- If test works, rename local copy to reflect date
- Copy changed files from local shadow to file share
- Upload changes from file share to production server

Unfortunately, there was a race condition here, where we might be testing changes to file XYZ at the same time the client's own developers were working on XYZ.

So they might alter the file between us making the copy and copying the changes to the file share.

Eventually this broke something, and the client complained. We pointed out that what he really needed was a source control server. He insisted this would be too complex. We pointed out that there was no way to prevent this; between the time I opened the file and the time I saved it, anyone could have done anything to the file, and the same problem would happen.

His "solution" was that you should never change any files - just make new ones. We despaired of ever explaining just how big a WTF this was, and simply agreed to the new policy... which we never followed, and when he called us on the carpet for it (not because something bad happened, but because he noticed we were changing files) we pointedly remarked that we were in the process of trying to close out his contract and remove him from our client roster.

The policy disappeared immediately. Instead, a new policy was instituted for the client developers: to never save files while our contractors were on site. We discovered this when one of the developers was haunting our team and asking when we were going home... he wanted to correct a typo on a form, but under this policy, he couldn't do it until we left for the day.

WTF begets WTF.