php-general Digest 24 May 2005 08:53:20 -0000 Issue 3472
Topics (messages 215775 through 215786):
Learning PHP ... online courses?
215775 by: Bill McEachran
215777 by: Esteamedpw.aol.com
215778 by: Chris Shiflett
215780 by: Esteamedpw.aol.com
PHP Programmer Needed in Miami ASAP!
215776 by: Joey
Re: Free penetration test
215779 by: Chris Shiflett
Re: Image Verification - Problems in Safari, Mac OS X
215781 by: Richard Lynch
Re: Regex nightmares
215782 by: Richard Lynch
Re: __get() not reentrant?
215783 by: Richard Lynch
215785 by: Jochem Maas
Re: Can I prevent Server variables from being spoofed ?
215784 by: Richard Lynch
215786 by: Jochem Maas
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
I'm just learning PHP. If anyone knows of any affordable quality on-line
based PHP courses
please pass on the details.
Thanks.
--- End Message ---
--- Begin Message ---
_www.Lynda.com_ (http://www.Lynda.com) has a new Video tutorial... about 9
1/2 hours long.
Best one I've found for the price would be _www.VTC.com_ (http://www.VTC.com)
which is $30 a month and you can get like 25 total hours of PHP and
MySQL... They're good for Beginners - then check out books like Advanced PHP
for Web
Professionals.
Hope this helps!
- Clint
--- End Message ---
--- Begin Message ---
Bill McEachran wrote:
I'm just learning PHP. If anyone knows of any affordable quality on-line
based PHP courses please pass on the details.
php|architect provides a live, comprehensive online training course for PHP:
http://phparch.com/shop_product.php?itemid=89
Disclaimer: I'm one of the designers of the program as well as an
instructor.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--- End Message ---
--- Begin Message ---
The Manual is great - but most people seem to get the hang of PHP faster if
they Watch people in action - then move onto reading the Manual...
Chris Shifflett's link (where he's an Instructor) is great too
(phparch.com)...
--- End Message ---
--- Begin Message ---
You or someone you know maybe interested in the programming position we have
available.
We have the need for a part time / possibly contract PHP programmer.
We are looking for people that can work in our Miami office (even
contractors), so please do not try and sell us your services if the location
is a problem.
Our development environment is Linux, apache, PHP, mysql.
Knowledge of the smarty template system and Pear:DB are also required.
We are looking for a self managed person who is organized and detailed, can
follow through a project from start to finish, and comple it within
reasonable time limits.
Experience developing relational DB's and not just simple lookups of a DB is
required, classes, functions and oops are part of the expected knowledge.
Please send your resume, links to your work with an explanation of how much
of the project you were responsible for and contact information ( phone &
email ) to Joey at web56.net.
Thanks
Joey
--- End Message ---
--- Begin Message ---
Andy Pieters wrote:
I am looking at where I can get my system tested for penetration.
We offer penetration testing at Brain Bulb, but I always try to convince
clients to let us perform a security audit instead. Auditing the code
allows us to be much more productive and thorough, plus we can identify
theoretical weaknesses in addition to the practical ones.
In addition to being less useful, penetration testing tends to be much
more expensive, because it requires more time and effort. The only
reason we offer the service is that some companies are uncomfortable
sharing their code with anyone, regardless of NDAs and such.
You might want to check out the links Christophe mentioned, as these
provide free advice, which seems to be more along the lines of what you
want.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--- End Message ---
--- Begin Message ---
On Mon, May 23, 2005 8:46 am, Rahul S. Johari said:
> If I had misunderstood your method and you think your method is better
> then
> what I'm using now, I'd still really appreciate if you can clarify and
> explain.
Your method is fine.
In fact, it penalizes IE for some stupidity in its caching, which is Good
because maybe they'll fix it if their cache becomes increasingly useless
as everybody does this to avoid their stupid bugs.
In theory, the ?$random_string should have forced the browser to load a
new/different image each time... It's hard to imagine even Microsoft could
screw that up, but you never know with Microsoft on this issue...
One possible improvement, however, is this:
The random part of the URL that you need to use to make Microsoft *NOT*
cache an image doesn't have to be tied to the actual algorithm that
creates the image.
Consider this example:
---- index.html ---
<?php
$fool_microsoft = mt_rand(1, 2000000);
?>
<img src="random.php/<?php echo $fool_microsoft?>/example.png>
-------------------
---- random.php ---
<?php
$heads = mt_rand(0, 1) ? 'heads' : 'tails';
$image = imagecreatetruecolor(100, 100);
$white = imagecolorallocate($image, 255, 255, 255);
$black = imagecolorallocate($image, 0, 0, 0);
imagefilledrectangle($image, 0, 0, 100, 100, $white);
imagestring($image, $heads, 10, 60, $black);
header("Content-type: image/png");
imagepng($image);
?>
The HUGE random number in the URL that forces MS to never cache my
coin-flipping image has nothing to do with the heads/tails outcome.
I don't know if this will help you have less clutter in your images or
not, but it might be useful some day.
--
Like Music?
http://l-i-e.com/artists.htm
--- End Message ---
--- Begin Message ---
On Mon, May 23, 2005 8:43 am, W Luke said:
> I really struggle with regex, and would appreciate some guidance.
> Basically, I have a whole load of files (HTML) which are updated every
> few minutes. I need to go through each line, looking for the word
> CONFIRMED: (which is always in capitals, and always superseded by a
> colon). The line looks like this:
>
> 22.5 J.Smith at Thropton, CONFIRMED: more text here, including commas
> and info on the appointment etc
Is that always on ONE line?
If so, you sure don't need anything as fancy as RegEx to do that.
$file = file("/full/path/to/your/file.html") or die("Could not load HTML");
while (list(, $line) = each($file)){
if (strstr($line, 'CONFIRMED:')){
$parts = explode('CONFIRMED:', $line);
list($before, $after) = $parts;
echo "A CONFIRMED appointment!<br />\n";
echo "<p>$before</p>\n";
echo "<p>$after</p>\n";
echo "<hr />\n";
}
}
You may need RegEx some other day to pick out the other bits and pieces
from the line... Or not. I've done a lot of scraping of data like this
with just explode and strstr and substr.
RegEx is great when you need it; But when you don't it's a lot of overhead
and a bit of a headache.
[Course, when you *DO* need RegEx it's *more* than a bit of a headache.
More like a migraine :-)]
--
Like Music?
http://l-i-e.com/artists.htm
--- End Message ---
--- Begin Message ---
On Mon, May 23, 2005 8:43 am, Christopher J. Bottaro said:
You took my suggestions as flames, and responded in kind.
They were not intended as such.
I'm happy to assume that you're the best programmer on the planet, okay?
Let's cut the flames out.
> case. Its insulting to our intelligence as programmers.
PHP was initially designed for very much non-programmers.
It's kind of gotten away from that with all the OO stuff, especially in
PHP 5, but there is still a considerable faction that doesn't *WANT* the
complexity of a full-blown kitchen-sink language.
It's not because we think you're stupid; And it's certainly not that we
think we're stupid.
It's that we believe that simple tasks are best served by simple tools.
> I was making a point. I don't see why recursion is allowed in every other
> function except for __get(). I think your argument is weak about
> protecting people from typos. If PHP wanted to protect people from typos,
> it should force you to declare your variables.
Or maybe it should warn you when you use an undeclared variable. Oh wait,
it *DOES* that!
Rather like Lisp, actually.
But that feature is turned off by default installation.
> I was bringing the to the table a discussion of the current behavior of
> __get(). I proposed that I might be broken or maybe should be changed,
> and
> you start insulting my abilities as a programmer and suggest that we
> shouldn't consider "moving forward" and just deal with what we have?
I don't know why you took insult. None was intended.
You may want to take this discussion to PHP-Dev, however, where people who
actually made the decision you don't like, and who will be the ones to
decide what to do about your suggestion discuss these kinds of decisions.
You obviously don't accept my musings on possible reasons. [shrug]
>>> What is wrong with that? Why should PHP disallow that recursive
>>> __get()
>>> call? It is perfectly valid recursive code. It terminates for all
>>> cases.
You clearly don't like the answer I gave. Maybe there's a better answer.
Berating me sure won't find it. Try PHP-Dev.
>> What happens if you do:
>>
>> class example {
>> function __get($x){
>> return $this->recursive_get($x);
>> }
>>
>> function recursive_get($x){
>> /* paste your current __get function body here */
>> }
>> }
>>
>> I suspect it will work just fine at the expense of one (1) extra
>> function
>> call, which is not significant in recursion.
>
> I suspect it doesn't. If __get() is anywhere in the call stack, then
> $this->x won't invoke a 2nd __get() call.
You misunderstood my suggestion.
I was suggesting that you compartmentalize the __get() from the recursion,
such that there was NO $this->xyz in the function body of recursive_get().
>> A recursive __get() has some serious implications to performance and
>> design decisions that painted you into this corner.
>
> Well, it doesn't have any implication on the performance of my app,
> considering the code path is executed like 5% (or less) of the time.
>
> Painted myself into this corner? Why? Because I think its easier to
> write
> $this->myvar than it is to write $this->attrs['myvar']? Its PHP's job to
> make my life easier and more convenient.
The code you posted was doing quite a bit more than getting rid of an
array reference...
If that's all you want, you can do it without recursion.
>> Obviously, it's entirely possible that your Design is the most elegant
>> beautiful disciplined bit of code since John von Nueman... But it's
>> more
>> likely, without knowing anything about you, that you've come up with
>> this
>> as a result of some bad Design decisions.
>>
>> Review your Design. :-)
>>
>
> Wow, how pompous of you. Bad design, huh? Since when is it bad design to
> calculate attribute values on the fly? Many "cookbook" style books have
> idioms for doing this. In my case, one of the calculated values depends
> on
> other values accessible via __get(). So why shouldn't I use __get()? The
> syntax is cleaner. Btw, when I say "use __get()", I mean implicitly call
> __get() via $this->attribute syntax. This whole problem does not exist if
> you call __get() explicitly, but then whats the point.
You're not going to like my answer. Oh well.
It seems to me that you've decided to make your property references be
just as powerful, complex, and flexible as methods. At which point, I
have to wonder why they should be properties at all.
Why not just make it be a method?
$example->get($x);
There's not a lot of point to HAVING properties distinct from methods if
the properties are going to be so complex that they require all the power
of methods.
That's just *MY* opinion, based on a lot of different OO languages.
I expect you disagree with it, and that's fine.
But the point is there:
If you are going to put that much complexity into your property, it's not
a property any more; it's a method.
> Speaking of "good design", Python's __getattr__() behaves how I expect.
Okay. [shrug]
Perhaps you'd be happier coding your application in Python?
Nobody is forcing you to use this ill-designed PHP language. :-)
You're certainly not going to see something like this changed in hours as
a result of a thread on PHP-General.
--
Like Music?
http://l-i-e.com/artists.htm
--- End Message ---
--- Begin Message ---
Christopher J. Bottaro wrote:
Richard Lynch wrote:
On Sun, May 22, 2005 3:24 pm, Christopher J. Bottaro said:
And what would make it any different from a normal recursive function?
The fact that *ANY* attempt to access a mis-typed property would kick in a
__get() call, and that's too frickin' easy to happen in code that's too
easy to fly by QA in large-scale applications springs to mind...
don't forget the noob factor - a noob could spend days trying to figure out
WTF is going on in such a situation..... we might even lose him to ASP in
that time :-/
Not saying you're "wrong" or they're "right" just that it's not quite as
simple as a normal recursive function or loop iteration.
I completely disagree. I don't mean any offense to anyone here, but I find
it kind of ridiculous for a language to restrict itself that like in this
case. Its insulting to our intelligence as programmers.
er whatever, interesting to see how easily you are insulted - I mean its a
programming language with a certain kind of implementation, which may not
be perfect, but I don't think they we're thinking of you when they wrote it.
Every recursive function runs the risk of going into infinite loop if the
programmer doesn't understand the basic concept (or makes a silly
mistake).
Just saying it's an easier silly mistake to mis-type: $whatever->fooo
instead of $whatever->foo and have that escape QA somehow.
Loops run the risk of going on indefinitely as well. Maybe PHP should
disable all forms of loops/recursion to protect the programmers from
themselves.
That does seem a bit excessive...
I was making a point. I don't see why recursion is allowed in every other
function except for __get(). I think your argument is weak about
protecting people from typos. If PHP wanted to protect people from typos,
it should force you to declare your variables.
you think its a weak argument, maybe you are missing the point - ask yourself
what the average level of php programmers is? part of the php philosophy is
about
making/keeping php accessible.
I think you will find that if you we're forced to declare you [class] variables
that your __get() implementation would stop working they way it does now...
Maybe __get() should allow recursion and let the developer worry about
infinite recursion.
Is that the 11th commandment?
But, today, it doesn't, so deal with it and move on.
ditto.
I was bringing the to the table a discussion of the current behavior of
__get(). I proposed that I might be broken or maybe should be changed, and
maybe you are broken, hard to tell from here.
you start insulting my abilities as a programmer and suggest that we
shouldn't consider "moving forward" and just deal with what we have?
I think Richard is a fairly intelligent person, if he had been insulting
you I'm quite sure that he would have done a much better job ;-)
What is wrong with that? Why should PHP disallow that recursive __get()
call? It is perfectly valid recursive code. It terminates for all
cases.
if it bugs you that much, write a patch for the engine and submit it at
[EMAIL PROTECTED]
What happens if you do:
class example {
function __get($x){
return $this->recursive_get($x);
}
function recursive_get($x){
/* paste your current __get function body here */
}
}
I suspect it will work just fine at the expense of one (1) extra function
call, which is not significant in recursion.
I suspect it doesn't. If __get() is anywhere in the call stack, then
you didn't bother to test?
$this->x won't invoke a 2nd __get() call.
A recursive __get() has some serious implications to performance and
design decisions that painted you into this corner.
ditto.
Well, it doesn't have any implication on the performance of my app,
considering the code path is executed like 5% (or less) of the time.
Painted myself into this corner? Why? Because I think its easier to write
$this->myvar than it is to write $this->attrs['myvar']? Its PHP's job to
given the number of chars in the email you wrote you could have written the
extra "attrs['']" (9 chars) god knows how many times, besides if you admit
you can solve all your issues by writing the 'long' form then your argument
[below] that you need to call __get() from inside __get() in order to retrieve
1 or more calculated values to calculate the originally requested attribute
sounds bogus.
and yes this are of your implementation does seem flawed - btw we all have
flawed code running... sometimes you have to hack around a problem because
time/money is what it is, sometimes you write something that is suboptimal
because you didn't, at the time, know all there is to know about that part
of php
php isn't perfect, neither are you - find a balance, get over it.
make my life easier and more convenient.
I didn't realise php had a job, I thought it was me who had the job and
php was what I used to accomplish it....
Obviously, it's entirely possible that your Design is the most elegant
beautiful disciplined bit of code since John von Nueman... But it's more
likely, without knowing anything about you, that you've come up with this
as a result of some bad Design decisions.
Review your Design. :-)
notice the fecking smiley [hint: Richard is trying to help you, trying to
get into an argument with him is making you look bad.]
Wow, how pompous of you. Bad design, huh? Since when is it bad design to
calculate attribute values on the fly? Many "cookbook" style books have
and 'cooking' is the same as 'engineering'? (I think I'll try something
new with the cement today....)
idioms for doing this. In my case, one of the calculated values depends on
other values accessible via __get(). So why shouldn't I use __get()? The
syntax is cleaner. Btw, when I say "use __get()", I mean implicitly call
__get() via $this->attribute syntax. This whole problem does not exist if
you call __get() explicitly, but then whats the point.
the point is that that works - code that does what you want is usually
a step in the right direction.
Speaking of "good design", Python's __getattr__() behaves how I expect.
use it then?
-- C
--- End Message ---
--- Begin Message ---
On Mon, May 23, 2005 5:40 am, Jochem Maas said:
> your site would make you look less like monopolistic idiots (why is it
> that the
> organisations with the most freaking money are the least capable of
> providing a
> _proper_ site...?)
Because their expert friend company (the one with the most money) told
them it wasn't safe unless they only used their products.
[That was a Microsoft-bash for anybody who didn't follow it.]
--
Like Music?
http://l-i-e.com/artists.htm
--- End Message ---
--- Begin Message ---
Richard Lynch wrote:
On Mon, May 23, 2005 5:40 am, Jochem Maas said:
your site would make you look less like monopolistic idiots (why is it
that the
organisations with the most freaking money are the least capable of
providing a
_proper_ site...?)
Because their expert friend company (the one with the most money) told
them it wasn't safe unless they only used their products.
its a pity that the manager at my local branch [of 'the bank'] isn't
such a gullible ****. (give me a bigger morgage,... its safer ;-)
[That was a Microsoft-bash for anybody who didn't follow it.]
made me laugh :-)
--- End Message ---
