[31513] in Perl-Users-Digest
Perl-Users Digest, Issue: 2772 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jan 17 00:09:40 2010
Date: Sat, 16 Jan 2010 21:09:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 16 Jan 2010 Volume: 11 Number: 2772
Today's topics:
Re: a defense of ad hoc software development (Robert Maas, http://tinyurl.com/uh3t)
Re: a defense of ad hoc software development (Robert Maas, http://tinyurl.com/uh3t)
Re: a defense of ad hoc software development (Robert Maas, http://tinyurl.com/uh3t)
Re: a defense of ad hoc software development (Pascal J. Bourguignon)
Re: a defense of ad hoc software development <tkpapp@gmail.com>
Re: a defense of ad hoc software development <marc.girod@gmail.com>
Re: FAQ 9.1 What is the correct form of response from a <sysadmin@example.com>
Re: FAQ 9.1 What is the correct form of response from a <brian.d.foy@gmail.com>
Re: FAQ 9.16 How do I decode a CGI form? <hhr-m@web.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 15 Jan 2010 21:30:43 -0800
From: seeWebInstead@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
Subject: Re: a defense of ad hoc software development
Message-Id: <REM-2010jan15-001@Yahoo.Com>
> From: ccc31807 <carte...@gmail.com>
> No matter how precise the specifications, programming always involves
> a certain amount of exploration -- usually a lot more than anyone had
> anticipated.
There is one exception where very little experimentation may be
needed, namely implementing formal protocol specifications, such as
RFC822. It would be reasonable for a high-level API to be written
directly from the specs to implement each little piece of RFC822 as
a callable routine. Thus there might be a function/method to create
an empty RFC822 object, another for each type of header line to add
to the object, another to verify that all the required lines are
present, and then one to pass the completed object to some
receiver. Likewise there might be a parser for RFC822 which returns
an object showing each of the fields that was present, and then
accessors for each field separately.
The rest of the application would be as you quote, experimental
development, but this one module which does the RFC822 API
implementation would be from the specs rather than very
experimental.
> In my SwE classes, we spent a lot of time looking at process and
> processes, including MIL STD 498 and IEEE Std 830-1984, etc. My
> professors were both ex-military, one who spent his career in the
> USAF developing software and writing Ada, and both were firmly in
> the 'heavy' camp (as opposed to the lightweight/agile camp).
I'm less familiar with military specifications, but I would guess
these are like InterNet specs, where you might code an API module
for each set of specs, coding directly from the specs, then write
the rest of the application in a more experimental style.
> Of necessity I have learned to expect to write a number of
> versions of the same script before the user accepts it.
It is sometimes desireable to quickly write non-functional UI which
shows the user how it "looks", and get their approval of that,
before starting the real code under the UI.
------------------------------
Date: Fri, 15 Jan 2010 21:46:55 -0800
From: seeWebInstead@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
Subject: Re: a defense of ad hoc software development
Message-Id: <REM-2010jan15-002@Yahoo.Com>
> From: Tamas K Papp <tkp...@gmail.com>
> There is a market for programmers,
If by "programmer" you mean "somebody who is capable of designing
new software and implementing them", and if by "market" you mean
somebody wiling to hire, I don't believe you. I'm a "programmer"
per that defintion, and I challenge you to find even one person or
company willing to hire for what I do.
> and some employers/customers want programmers who can write
> software without being given super-specific formal requirements.
I would prefer to brainstorm with the employer to work out our
common idea of what they want that I believe is
possible/reasonable to implement.
> Programmers who can cater to this market by making an effort to
> understand the problem domain may enjoy an advantage.
How deeply must I understand the problem domain?? Can you give an
example of a currently open requirement, the problem domain it
involves, and some idea how deep I would need to understand it
before I even talk to the employer, and how much the employer can
explain to me to bring me up to the needed level of understanding?
------------------------------
Date: Fri, 15 Jan 2010 22:17:56 -0800
From: seeWebInstead@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
Subject: Re: a defense of ad hoc software development
Message-Id: <REM-2010jan15-003@Yahoo.Com>
> From: "MarkHanif...@gmail.com" <markhanif...@gmail.com>
> "Agile" has become a religion of its own, and the whole mission
> of sitting down with your "customers" and rapidly banging out
> mockups has been lost. It's the rapid-feedback that gave death
> to waterfall (communication).
Are you saying that software designer and customer/employer should
talk to the point where they think they agree what needs to be
implemented, then software designer quickly makes a mockup, and
shows it to the customer/employer to "try" to see whether it's what
c/e wanted or not, and if not then another round of mockup, until
c/e is satisfied, then do same for next requirment, etc. until the
whole application is mocked-up to the satisfaction of the c/e, then
the s.d. can integrate everything into an application? If so, I
agree, and I just wish I could find some c/e to hire me so that I
can try it with a real live c/e for the first time ever.
Note that for Web-server applications, PHP may be the best language
for rapid prototyping/mockingup, better even then Lisp because it
better integrates the HTML with the algorithms, with not much loss
of programming power compared to Lisp. Thus the time saved in not
needing to do any work integrating HTML with algorithms more than
makes up for the time spent figuring out how to do an algorithm in
PHP which was trivial in Lisp. On the other hand, for any really
serious new algorithms, I'd prefer to develop in Lisp, and not even
bother to interface to HTML until after the algorithm is working as
wanted by the c/e.
------------------------------
Date: Sat, 16 Jan 2010 08:38:31 +0100
From: pjb@informatimago.com (Pascal J. Bourguignon)
Subject: Re: a defense of ad hoc software development
Message-Id: <871vhqlcso.fsf@hubble.informatimago.com>
seeWebInstead@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t) writes:
>> From: ccc31807 <carte...@gmail.com>
>> No matter how precise the specifications, programming always involves
>> a certain amount of exploration -- usually a lot more than anyone had
>> anticipated.
>
> There is one exception where very little experimentation may be
> needed, namely implementing formal protocol specifications, such as
> RFC822.
In theory. But in practice, you still need to bump against other
implementations to learn how to treat the cases that are not covered
by the protocol. There are RFC that are specifically describing the
"best practices", which means that there are a lot of implementations
implementing "worst practices" or "good-enough practices".
It also depend on the specific protocol (and its specification) some
protocol specifications may lead to more variability and more "fun".
--
__Pascal Bourguignon__ http://www.informatimago.com/
------------------------------
Date: 16 Jan 2010 09:04:02 GMT
From: Tamas K Papp <tkpapp@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <7rddo1FmsjU1@mid.individual.net>
On Fri, 15 Jan 2010 21:46:55 -0800, Robert Maas, http://tinyurl.com/uh3t
wrote:
>> From: Tamas K Papp <tkp...@gmail.com> There is a market for
>> programmers,
>
> If by "programmer" you mean "somebody who is capable of designing new
> software and implementing them", and if by "market" you mean somebody
> wiling to hire, I don't believe you. I'm a "programmer" per that
That's your problem. Clearly there are employed programmers. And you
are a very special case, so your job market experience is not indicative
of anything.
> defintion, and I challenge you to find even one person or company
> willing to hire for what I do.
Whatever. I am not a job search agency. (BTW, these "I challenge you"-
type utterances must be a clear winner in job interviews).
> How deeply must I understand the problem domain?? Can you give an
> example of a currently open requirement, the problem domain it involves,
> and some idea how deep I would need to understand it before I even talk
> to the employer, and how much the employer can explain to me to bring me
> up to the needed level of understanding?
These things are project specific, and are usually decided between you
and your employer/customer. Eg if you are writing a library for
numerical applications, most employers would prefer that you have a
clear understanding of floating-point arithmetic (eg on the level of
"What Every Scientist Should Know ...").
But the more you know, the less your customer will have to explain.
And the flipside is that if you don't know anything, sometimes
introducing you to the problem domain is prohibitively costly, so
people become their own programmers (which happens in science very
frequently).
Tamas
------------------------------
Date: Sat, 16 Jan 2010 02:33:39 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <396f7412-aa7e-43b5-9964-c2180aa269bd@e37g2000yqn.googlegroups.com>
On Jan 16, 9:04=A0am, Tamas K Papp <tkp...@gmail.com> wrote:
> That's your problem.
And not the company's you mean?
That's a matter of trade-off. If 'the company'
chooses to hire somebody who matches some
non-programmer's pre-conceptions, rather than
somebody who would write better code, it
should be 'its' problem as well.
I don't like personalizing entities such as
'companies'. In practice, the issue is one of
power inside the company: what expertise is
valued, and what is not. The interests which
get optimized are those of individuals.
>=A0Clearly there are employed programmers.
Sure. But are they employed for what they
really do, or for the perception their
managers (or the HR department) have from it?
How good is the match?
> Whatever. =A0I am not a job search agency.
> (BTW, these "I challenge you"- type
> utterances must be a clear winner in job interviews).
This remark shows a worrisome asymmetry in
the contractual relationship. Again, such an
asymmetry does not optimize the interest of
-say- the share holders.
> These things are project specific, and are usually decided between you
> and your employer/customer. =A0Eg if you are writing a library for
> numerical applications, most employers would prefer that you have a
> clear understanding of floating-point arithmetic (eg on the level of
> "What Every Scientist Should Know ...").
You mean, of something *they* don't have...
The risk is this of the urban legend...
I believe concretely ones meets it with GUIs,
which are felt important by people who don't
use them, or comments in the code, by people
who don't read them, etc.
Floating-point arithmetic also shows a
view point, even if arguably a more educated
one.
> But the more you know, the less your customer will have to explain.
Optimizing communications by avoiding it.
I.e. relying upon the fact that it has
already happened: that the knowledge is
indeed shared, relevant, complete...
That's not cutting-edge stuff... No
competitive advantages to be gained.
Is it really relevant to software?
> And the flipside is that if you don't know anything, sometimes
> introducing you to the problem domain is prohibitively costly, so
> people become their own programmers (which happens in science very
> frequently).
Right. That's why Torvalds designed git,
and Behlendorf subversion: because they
felt it was less work to write from
scratch what they perceived they needed,
than to communicate with SCM people.
Marc
------------------------------
Date: Sat, 16 Jan 2010 00:39:58 -0800
From: Wanna-Be Sys Admin <sysadmin@example.com>
Subject: Re: FAQ 9.1 What is the correct form of response from a CGI script?
Message-Id: <zXe4n.1227$4n1.499@newsfe17.iad>
Marc Girod wrote:
> On Jan 14, 5:00Â pm, PerlFAQ Server <br...@theperlreview.com> wrote:
>
>> It is not
>> specific to Perl, and has its own FAQs and tutorials, and usenet
>> group, comp.infosystems.www.authoring.cgi
>
> I had a look, and it is not very promising...
> There is one message dated Jan 10, and it is about finding a new
> moderator.
> The previous message is dated Oct 18 2008
>
> Marc
No kidding there. Wow, I have checked that group on and off for several
years, and the only new messages I've seen, are all spam. I don't
think I've seen a legitimate question in the CGI authoring group for at
least 3 or 4 years or more. Perhaps it's not officially dead, but it
is very much dead for all intents and purposes. Perhaps there are a
few legitimate questions in an entire year, but I would agree that
while it (CGI) might not be a Perl question, pointing people to a
perfectly dead group is probably outdated. If it's about moderation
needs, I'm sure there are honest, unbiased people that would do this to
keep the group alive. Some people go on about how CGI is dead due to
PHP, etc., but I don't know any serious programmers that like PHP after
all of these years, more respected programmers I know still use Perl
(not that I'm saying PHP is awful or that everyone that uses it sucks,
to be clear, just stating the facts from what I've seen over the last
decade or more).
--
Not really a wanna-be, but I don't know everything.
------------------------------
Date: Sat, 16 Jan 2010 08:44:06 -0600
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 9.1 What is the correct form of response from a CGI script?
Message-Id: <160120100844068722%brian.d.foy@gmail.com>
In article
<17f16443-42a2-4fed-8daa-8c9dca7641f5@c34g2000yqn.googlegroups.com>,
Marc Girod <marc.girod@gmail.com> wrote:
> On Jan 14, 5:00 pm, PerlFAQ Server <br...@theperlreview.com> wrote:
>
> > It is not
> > specific to Perl, and has its own FAQs and tutorials, and usenet group,
> > comp.infosystems.www.authoring.cgi
>
> I had a look, and it is not very promising...
> There is one message dated Jan 10, and it is about finding a new
> moderator.
> The previous message is dated Oct 18 2008
Sadly, Alan Flavell, one of the guys who made that group worthwhile,
passed away a couple of years ago. I'll adjust the answer.
Thanks,
------------------------------
Date: Sun, 17 Jan 2010 00:04:44 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: FAQ 9.16 How do I decode a CGI form?
Message-Id: <Pine.LNX.4.64.1001162243220.4174@lxhri01.lrz.lrz-muenchen.de>
On Fri, 15 Jan 2010, Mumia W. wrote:
> I think you're trying to demonstrate a bug in CGI.pm, and you're doing that
> quite well,
Up to now, I was not able to say what exactly my problem is. This is in
part due to the fact that the CGI.pm documentation fails to say what
*exactly* CGI.pm does with UTF-8, so that I cannot check the behaviour
against the documentation. Let me try again.
The documentation http://perldoc.perl.org/CGI.html says:
| -utf8
|
|
| This makes CGI.pm treat all parameters as UTF-8 strings. Use this with care,
| as it will interfere with the processing of binary uploads. It is better to
| manually select which fields are expected to return utf-8 strings and
| convert them using code like this:
|
| 1. use Encode;
| 2. my $arg = decode utf8=>param('foo');
What does the first sentence mean: "This makes CGI.pm treat all parameters
as UTF-8 strings"? What is "treat as" in this context?
The only way I find for giving it a meaningful interpretation is the
following.
a. The handling of UTF-8 characters is documented in
http://perldoc.perl.org/perlunitut.html . The main lesson to be learnt
is that the writer of any perl program is responsible to know which of
his strings are bytestrings or textstrings. If he does not know, he
might try to output textstrings to a binary file (does not work for
"wide" characters), or output bytestrings to a UTF-8 encoded file
(renders "wide" characters as a sequence of two or more characters), or
compare a textstring with a bytestring (unpredictable whether equal
strings will be recognised as equal).
b. Hence, it is vital that the user of the CGI.pm module know whether the
result of param('param_name') is a bytestring or a textstring. If
bytestring, it has to be output with STDOUT as binary; if textstring,
as UTF-8 (that is, after binmode (STDOUT, ":utf8")). If bytestring, it
can be compared only with other bytestrings whose encoding is known to
be the same; if textstring, it can only be compared with other
textstrings. If bytestring, a default setting of a field in the form
must also be a bytestring; if textstring, it must be a textstring. If
one of the input string (the value of param() at the start) and the
output string (the default setting of the field in the form) is a
textstring and the other is a bytestring, then the user input will not
properly be reused in a subsequent iteration of the form.
c. The documentation does not say what kind of strings the param()
function yields or expects. It is plausible that they are bytestrings
in the absence of any specification, but what if the -utf8 pragma is
specified?
d. The first possible interpretation is that the param() still yields
bytestrings even with that pragma. Then the user of CGI.pm has to take
care that all other strings with which the parameter is defaulted or
compared (as described as item (b) above) are bytestrings as well. But
then the pragma simply has no effect at all.
e. The second possible interpretation is that, with the -utf8 pragma,
param() delivers the form input data as textstrings. Then they can also
be defaulted to textstrings, compared with other textstrings, and
output to a new form provided that STDOUT is in :utf8 mode. This would
not only be a reasonable behaviour but an extremely useful one.
Therefore I find this the most plausible interpretation.
f. Up to now, we have not considered uploading binary files. If behaviour
(e) is intended, which we do not know due to lack of unambiguous
documentation, then one could think of setting :utf8 mode also on
STDIN. However, this would be a very bad idea, as then the entire input
would have to be UTF-8 which is not the case for embedded binary files.
An alternative implementation would be to first extract uploaded files
from the input data, and then interpret the remainder as UTF-8 data
(which can be guaranteed if properly specified in the accept-charset
option of the <form> tag). Again: This would not only be a reasonable
behaviour but an extremely useful one. Therefore I find this the most
plausible interpretation.
That a call to decode() for decoding input data is mentioned in the
documentation as an *alternative* to the -utf8 pragma is another hint that
behavious (e) is intended, and that the documenation warns against
simultanous usage of -utf8 and binary upload is a hint in the same
direction, suggesting that the implementation is used which I called "a
very bad idea" under item (f).
Now what actually happens is:
1. The strings yielded by param() are unusable as textstrings. They are
UTF-8 bytestrings, exactly as if the -utf8 pragma would not have been
specified.
2. I was not able to produce any problems in the uploaded binary files
with or without the -utf8 pragma. The warning is futile.
The module thus works quite differently from what I expect from the
documentation. To sum up, the documentation says, it does something useful
with UTF-8 data but may garble binary data. In fact, it does nothing at
all with UTF-8 data, and because it does nothing, it does not do any harm.
The documentation is not clear enough to tell whether it is a deficiency
in the documentation or the program. The documentation should specify
exactly what to expect, and the actual behavious is far from optimal (so
fixing only the documentation is not the right solution).
> First, you can't post to an HTML file:
> http://www.lrz-muenchen.de/cgi/richter/test-utf.html . I changed that when I
> ran your program.
It's just the name of the file; it is the perl script I included. The
Apache where I ran it accepted the file as CGI script despite its name
(based on the directory where it is).
> Second, mutipart/form-data is supposed to be for binary files, and as such is
> not suitable for utf8 data /unless/ you wish to handle the convertion to/from
> utf8 yourself. I don't think that CGI.pm is misbehaving too badly.
Yes, this is how the documentation says, but that is not true, as
explained above in detail. And it *should* not be true: the CGI.pm module
has access to the entire input string *before* any code conversions are
done -- *this* is the right place for decoding the data, not in the perl
script on a parameter by parameter basis.
Thank you for looking into it.
--
Helmut Richter
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2772
***************************************
