Whats your development environment

[hakkr]

What is the best environment to develop Perl code? Every coder here uses a different edit/compile/execute cycle

1. SSH to the remote server and use vi
2. Edit locally then FTP to server to execute
3. Edit directly over network (samba)
4. Use activestate and develop on windows then upload finished program to server
5. Develop locally

So win(apache/Mysql) or lin(Apache/Mysql) locally or remotely.

Should CVS/RCS be in this cycle somewhere?
cheers

[crazyinsomniac]

I try to avoid editing anything server side.

I do everything locally.

It is not limited to web stuff.

I do use CVS (i lose my head otherwise).

Apache everywhere (but I don't discriminate much).

Mysql everywhere (it just happens to be everywhere).

Activeperl and indigoperl (even crazyperl, as well as FreeBSD/RedHat... blah blah, even MacPerl).

What is the best environment to develop Perl code?

San Jose, California (or good indoor heating/ac), on a comfy chair, with low lighting, in my underwear.

Every coder here uses a different edit/compile/execute cycle

Yes, perl is a freak religion

 


______crazyinsomniac_____________________________ Of all the things I've lost, I miss my mind the most. perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[dsheroh]

Pretty similar here:
1. Edit (in vi) and test on local machine, preferably with comfy chair, low light, loud music, WindowMaker, and a minimum of 4-5 Eterms (home email, office email, main vi session, secondary shell/vi session, and, if I'm working on something web-based, tail -f /var/log/apache/error.log)
2. cvs ci
3. ssh production-server
4. cvs -q up
No test environment here aside from my development machines (home, office, and laptop), but that's mostly because I'm not at a software company and trying to buy more hardware is like getting blood from a stone. Last job I had as a developer (I'm supposed to be an admin now, but I end up writing internal-use apps anyhow), I fought hard to get proper test environments and bug tracking systems in place, but it just wouldn't be worth it at my current company.

[Juerd]

1. SSH to the remote server and use vi

When developing web applications and computer-specific applications.

5. Develop locally

For modules and normal scripts.

I'm not a Windows user, but Linux can be a great desktop OS too. I develop locally and remotely, but almost always with (a recent version of) vim. When developing web applications, I usually do so on the server it is going to run on, but not when it's a common module (like PLP) or the ssh connection is too slow.

When I need to move scripts away from my computer, I use e-mail if the script was meant for a customer, and I use scp (comes with ssh) for computer-to-computer copying. FTP is insecure and too much work.

Windows is now an emulated system on my computer, and only for electronic banking and some casual MSIE development. I have never used Windows to develop Perl scripts, though. Visual programming is something Windows is useful for, but I used an older computer for development back then, because IMHO, Perl for Win32, Apache for Win32 and MySQL for Win32 suck. I think the platform might be the cause :)

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[vek]

I used to do everything on the remote server (ssh in and fire up vim). Now my development habits have changed somewhat. I primarily use my desktop linux box for developing & unit testing. When I'm happy with my prog(s) I use scp to copy them to the Solaris servers so that QA can beat them up.

I try and set my box up to mimic the server (albeit a smaller version) i.e Apache, mod_perl, MySQL.

Seeing as I work in a multi-developer environment I cannot (and frankly do not want to) keep the source code on my box. Instead, it's kept in RCS on one of the Solaris boxes so that all developers have access to it. Source code is checkin in/out and copied (via scp) to/from my linux box for development.

-- vek --

[dreadpiratepeter]

Actually, with Emacs I work transparently over the network. Ange-FTP allows me to deal with remote files as if they were local.

The I get to use The One True Editor^tm and the wonderful cperl-mode without leaving home.
Remember you can't spell evil without vi.
It's a joke, son! I'm not trying to start an editor flame war.

-pete
"Pain heals. Chicks dig scars. Glory lasts forever."

[thraxil]

agreed. since i don't trust the network i'm on though, i prefer to use TRAMP instead of ange-ftp. you can run ange-ftp over ssh but i find that more complicated and error prone than TRAMP.

so my setup is: code lives on a dev box (linux + apache), emacs/TRAMP to edit, usually an ssh session to the dev box too. everything's managed with cvs. i keep a dev and staging directory on the dev box. once i'm happy with the code in dev, i cvs commit, then update in the staging dir and make sure it still works there. if that's all good, i do a cvs update on the production box (solaris + apache). Makefiles are useful for handling any differences between configuration on dev vs production.

anders pearson

[Aristotle]

vi sucks.

That's why I use vim.

:-)
____________
Makeshifts last the longest.

[FoxtrotUniform]

Remember you can't spell evil without vi.

I've always wanted to write an editor called evil; I've even backronymed it to "Editor, VI-Like". My plan is to make it super-easy to run the text through on-the-fly Perl code... of course, vim already does that. At any rate, I've never quite had the free time for it, especially since vim has most, if not all, of the features I want.

vim also does remote editing, of course. Still doesn't have a sexy BastardizedLISP interpreter, though... I'll have to concede that one to you Emacs guys, I guess.

--
The hell with paco, vote for Erudil!
:wq

[Molt]

My development cycle: Develop code fragments on local machine (Win2k, using Ultraedit for the text editing and Cygwin's Perl for the engine), then begin to develop on development server (Sun box) again using Ultraedit on local and it's nice FTP save/load features, and a simple telnet session to it.

Version control is Sourcesafe (We're mainly a Java environment here, and that interfaces well with JBuilder- or so I've been told), but isn't used overmuch as I'm maybe a bit too lazy in that respect.

I find this gives me a nice balance between total control of my environment to see just what modules I will need, and the final version on the test server. The reason I'm wary is that any module installed on test should really also get put onto production machines, and with the natural reluctance of the people running that server I'd rather not have to ask for too much.

The database I use is always the test Oracle box, and it's rare I use webservers but when I do it's Apache running on local and on the test machine.

Previously I've tended to SSH into the remote machine and use Vi, but just getting happy with the setup I have now. I have come to like Ultraedit.

[ajt]

I have NT desktop systems, and Linux servers (in-house and hosted), so like a lot of people here I get good use out of SSH!.

Editing Text: I use PFE on NT, and even though it's not very sophisticated I've used it for ages and I'm very happy with it. I use pico/nano on my Linux boxen, and nano on Windows Cygwin/XFree sessions.

Editing Mark-up: I use HTML-Kit for HTML on Windows, it's free (as in beer) and XML Spy for XML (not free). Both understand what they are doing and have built in FTP interfaces. I'm told that XEmacs and VIM work quite well on Windows, but I'm not so familiar with these tools.

Connecting to remote machines: I use PuTTY or TerraTerm SSH which are both okay (PuTTY is newer and supports SSH2). I also use Cygwin's SSH and X over SSH, which work quite well.

FTP: I just use scp/sftp from my Cygwin SSH suite, or WS FTP in house as it doesn't support SSH. At home I've found Samba works quite well.

Version Management: I have CVS set up on my both Linux and NT boxen, but I really need to read the instructions and use it, as it's currently idle.

Other Stuff: I have Apache/mod_Perl/mod_PHP on everything, pretty much to the same version. Cygwin proves very useful on NT, all those nice tools, very hepful when looking through log files of fixing things.

Philosophy: until I can run Linux for my desktop system, I develop on NT, and migrate to a Linux DEV server for testing, and additional work. Next code moves to a QA system (also Linux), and then finally on to a production Linux system.

Update:Extra Links added...

[jjdeterick]

I like to use a product called Ultra Edit.
It's a pretty solid tool for both server side and local editing.
Check it out at: Ultra Edit

~J

[Abigail-II]

Best environment? My own machine of course ;-) A Unix machine (I'm not picky, Solaris, HP-UX, Linux, BSD, it's all fine), running X Windows. And vile as my editor. What else is required? On a few occasions, I use make and m4. I use RCS and CVS often.

I do not understand what you mean by "the remote server". Do you have a development server? Or a vi server? Or do you think that all there is to develop is web applications? I can tell you, the world is more than web.

Abigail

[krujos]

Telnet or WRQ's reflection sessions to the server depending on how serious I am... The way were set up editing locally is a bigger hastle than opening a session on the server.
RCS is what we use, its great, with any big project I think its a must.
We are interfacing with lots of different db's here, Oracle, Informix, *sql... its great fun.
for editors, vim and vi get the job done.

--my .02

[Popcorn Dave]

For coding I use DzSoft's Perl Editor combined with ActiveState Perl. It integrates nicely and allows me to catch my stupid errors via the F12 key. :)

Some people fall from grace. I prefer a running start...

[greywolf]

At my last job I would ssh to the server and use NEdit. At home I develop locally, I only have 1 Linux box anyway, and I use NEdit. Apache and MySQL is the setup I use.

mr greywolf

[castroman]

I used to make important changes in a LINUX that has the same configuration as my host. So I can check everthing is correct and then connecto to my web server and transfer the files via FTP.

[DaWolf]

Well, I have to take part on this one. Great node, hakkr ++.

I use what I think is the simplest/easier to configure environment:
• Win2k Professional
• IIS
• Activestate Perl
• MySQL
• Activestate Komodo for editing/debugging
As an IDEAL environment I would say:
• Linux or FreeBSD
• Apache with mod_perl
• Oracle
• The editor I'll leave blank as I don't know much of developing in these platforms.
Just my two cents.

Best regards,

my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");

[Jenda]

Whenever I was developing anything on a unix I used an editor (usualy PFE at that time), FTP and a few telnets. (Pre ssh times or intranet.) I was not able to get used to any of the cool unix editors, much less wanted to spend hours seting them up.

Now even the production environment is Windows for me. So SciTE, ActivePerl, MS SQL, MS IIS, PVCS. With a "copy" of the production database on my machine as well (I am the one doing the SQL development anyway) and IIS set up as on the server. Using PVCS for version control (not my choice!) and a home made scripts&services to ensure the updates are complete. (Usualy you change several files when adding new features. Do you always remember which ones?)

  Jenda

P.S. on the updates: I run a service (daemon) on the servers and my machine that "indexes" all files, views, tables and stored procedures and creates DBM files with MD5 hashes of the objects. When doing an update I download the DBM files form the server, compare them with local DBMs and generate ZIPs with objects that need updating. For table and data related changes I keep a directory of update SQL scripts and keep track in the database which ones were already applied. Seems to work quite fine.

Comments welcome though of course :-)

[Aristotle]

Same as vek said, pretty much.

Makeshifts last the longest.

[Pug]

Considering that I do QA automation.

1) edit the files locally using vim.
2) test it on my computer.
3) check it in using CVS.
4) goto the production box (ssh or telnet depending on which one) and check it out and test it out. install any moduals required.
5) if needed (like the cgi scripts) put it in apaches cgi-bin directory.
6) remind the head developer to update his copy of the QA scripts tree. This is so that when he releases a build, no one has to check out the tagged version of the source tree , build the program, install it and then check out the recent version so that my code can test it.
7) if no new code drop is set to tested that day. Start it up and watch the bugs fly.*grin*

[nok317b]

i use linux (i prefer slackware), a local apache, nedit, yafc (ftp client), diff, perl -d, mozilla, opera, logtodo, changetrack and rpl.

i use perl for webdevelopment and do some shell scripting from time to time.