[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meeting. March 3rd. Reuven Lerner



Hi, guy!

On Sun, Feb 20, 2000 at 11:40:18PM +0200, you wrote the following:

> > I'd most like to hear about development environments and techniques
> > for developing web applications. 
> [...]
> > -- but how do you do all this when you're writing code
> > that's going to run under a web server and you can't run it frontally?
> 
> i think you've hit an exposed nurve here... i'd be very surprised to hear
> about such a tool that exists for web development.

That's strange. But someone has already commented that open-source
programmers have written just about any software one could concievably
need, except for decent tools for themselves -- there'd been so little
advance in the last few years in the way people program, as opposed to
every other thing they do with their Linux computer. :-/

I'm told that Microsoft has tools to do that. It can't be *that*
complicated. What is the perl debugger, anyway? Isn't it just some
perl module? How hard can it be to create a way to debug code that's
running in mod_perl in apache? Perhaps Reuven has something to say
about it. Either now or at the meeting.

> i would guess, however, that debugging this simply requires some
> imagination, and a design that is easy for debugging. for example,
> with a large-scale application, you'll most likely use a back-end
> that runs as a daemon, with CGI scripts communicating with it, thus
> keeping the CGIs simple, and allowing you to debug that daemon just
> like you'd debug any unix daemon - attaching a debugger after it's
> launched, or running it in the forground for debugging sessions,
> rather then as a daemon.

Sometimes it's possible, and sometimes it isn't -- take Slash for
example. Admittedly I haven't looked at the code, but I'd guess that
it's not a daemon with simple glue CGIs, but rather the CGIs do all
the actual work themselves. Although such an application would be
still easier to debug than others -- the *real* problems begin when
you save session information between different pages (either by
writing under Apache::ASP[1] or by using one of the available perl
modules which do that) -- you can't forge session information easily,
and then there's *really* no way to debug it other than "print STDERR".

Your tips are good. If there isn't a complete and comprehensive
solution for developing & debugging web-server-running code, then lets
at least share tips & tricks of the kind you presented. I'm sure
Reuven has much experience in this, so IMHO it's a good topic for a
lecture for him, or maybe some kind of a workshop.


[1] For those of you unfamiliar with the Apache::ASP module, please
refrain from flaming that ASP is a Microsoft technology until you've
written an application or two with Apache::ASP. For a change, this is
a very nice Microsoft technology, open and supporting many languages,
not just VB as many seem to think. I write ASPs in perl with the above
module; ASP replaces CGI and provides stuff that CGI doesn't, such as
saving session information across many pages (implemented
transparently via cookies). It's also compatible with ActiveState
PerlScript which allows you to run the same perl/ASPs on IIS, if
you'll ever need to. And if you're ashamed to have pages named *.asp
on your web server, you can name them some other way. :-)


-- 
Alex Shnitman                            | http://www.debian.org
alexsh@hectic.net, alexsh@linux.org.il   +-----------------------
http://alexsh.hectic.net    UIN 188956    PGP key on web page
       E1 F2 7B 6C A0 31 80 28  63 B8 02 BA 65 C7 8B BA

/real/ kernel hackers
    dd if=/dev/urandom of=/vmlinuz
and influence the Universal Randomosity Field.
	-- Gaal Yahas

PGP signature