- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This is funny to me personally because I just wrote an article on PHP templating.
Admin
I could just see the conversation:
"70656, why are you so behind in your tickets? I just talked to 72586 and he finished all of his before lunch!"
(Yes, the numbers sound awkward, but it was the best I could do to represent the salepeople :P)
The other thing that comes to mind is, does a ticket give you permission? If so, did 70656 have any influence on the code? :P
Admin
Doh,
-permission
+commission
It's late and I'm not thinking while I'm typing :/
Admin
Who gets the ticket when Rand draws 0.5 :)
Admin
Well, the behavior would depend on what language that's in wouldn't it? If it's Perl (which I believe it could be), 72586 could have twice as much work as 70656 (depending on how the system handles multiple owners.
Admin
So approximately 1/4 of all tickets just dropped down a rathole somewhere?
Admin
Oh dear... I didn't even notice the hugeness of that WTF until you made fun of it. I guess neither of them get the ticket if rand returns exactly 0.5 twice in a row....
Admin
The first one Has a posible recursion problem (it gives a new meaning to the word panic).
second one, I really see no problem with except that the whole function is pointless.
The thrid one it is posible that both will get it the job and even sometimes nun of the them would get the job.
Admin
No, it's two calls to rand.
There's a 50% chance that 70656 gets the ticket.
Of the other tickets, there's a 50% chance that 72586 gets it.
All other tickets are left unassigned.
Admin
Admin
rand() is being called 2 times, if the first call returns a value less than 0.5 and the second returns a value greater than 0.5, the ticket is not assigned to anyone.
Admin
no, it does something simular to this
$A = rand();
@yv.. I just realize stuffed up
Admin
it's possible for both of them to get the job if the first call returns >0.5 and the second call returns < 0.5
and BTW
$A = rand();
$A = rand();
if ($A > 0.5) {$Owner->LoadById('70656');}
$A = rand();
if ($A < 0.5) {$Owner->LoadById('72586');}
Admin
Where's the link to the printable version? Shame.
Admin
That depends on the system, but it's probable that only the owner that was assigned last gets the actual ticket; so it's not really possible for both to get the ticket. It is, however, possible, that none get the ticket.
The following code is correct, but illustrates why the previous code is wrong (the initialization doesn't always happen):
Admin
That would be the case if it was an if/else-if pair. However, it's two if's, so what you said there is incorrect. There's a 50% chance the first guy gets the ticket, and there's a 50% chance the second guy gets the ticket. Hence, altogether, there's a 25% chance that both of them claim the ticket, 25% that neither, and a 50% chance that only one of them will claim the ticket.
Admin
The real WTF is that apparently no one has ever heard of 'else'. Not knowing what those functions do, the above could well assign the ticket always to 70656 and in addition half the tickets to the other guy.
Captcha = null, which the above code does not test either, nor FileNotFound, but is it less than 0.5?
Admin
Nah, it's clearly one of those languages without else statements.
Admin
Oooh, my bad. I was thinking I saw a "else if".
That'll teach me to drink and comment.
But at least I wasn't drinking and programming.
Admin
I think the domain name of that site is pretty funny, you already know why.
Admin
This kind of so called "PHP templating", you wrote about in your article, should be avoided in any case! It is the same s..t as Smarty!
Admin
You're obviously a troll but here goes anyway:
Yes well: while presenting that code I explicitly stated the assumption that the ticket would only be assigned to the last owner loaded. I challenge you to find fault with the code under that assumption.
Futhermore, I have two reasons to suspect the assumption is correct:
1. The code doesn't look to assign anything... $owner->loadById()... this simply loads something, and doesn't assign anything. An assign action would include both an owner and ticket entity. Okay so it's obfuscated code, so that's not really strong.
2. If tickets actually got assigned to two people, odds are the bug would have been discovered much earlier as Biff and Cliff noticed they both owned the same ticket. On the other hand, lost tickets are quite a lot harder to discover.
Finally, the use of "else" is not the issue here. Sure it should have been used in the original code, but I only posted the above code to illustrate the bug more clearly.
Admin
Admin
Good haul for a CodeSOD. :)
As for the random allocation...
if ( ($hour >= 7) && ($hour <= 18) )
{
$id = ( rand() > 0.5 ) ? 70656 : 72586;
$Owner->LoadByID( $id );
}
Done.
Admin
Admin
Actually no,
there is a 25% chance for 70656 and a 50% chance for the second and in a quarter of all cases no one gets it.
Admin
Thats just not fair, in this case dude #2 would have to work more. Whats about
do{
$a=rand();
}while( a!=0.5)
$owner =getById( a>0.5? 1 : 2 ) // is this kind of conditional assignment legal in Perl?
Admin
I get it. The code was originally written in haskell, and since no functions can produce side effects, calling rand() twice will yield the same result. Still doesn't explain what happens on a perfect half.
Admin
it's even funnier cos your "templating" system sucks
Admin
My first thought too, was that 25% of the tickets were vanishing into the aether. So that's a WTF all on its lonesome, but there is another one....
If this is PHP code, 70656 will get the vast majority of the tickets. In PHP, rand() returns an integer between 0 and RAND_MAX (on win32, this is 2^15 -1). About 1 in 32,000 tickets will disappear into the aether.
Lucky/poor old 72586 will only get one out of every billion or so tickets, as to give him a ticket, rand() has to return 0 twice in a row. While this should be technically possible, I'm willing to bet that the nature of psuedo-random number generator code means that he actually gets none.
Admin
Naw, looks like Perl, with the # comment. And rand() in that case does go from 0 to 1. Not that there aren't enough WTF's there already
captcha: mustache, ironic for reasons I won't go into
Admin
I thought I might have got that wrong, as I'm not experienced enough with Perl or PHP to distinguish them ; but having just checked, the PHP manual says that it does support Perl style comments (and a brief test shows it to be true), so it's entirely plausible that this could be PHP code.
I'm also under the impression that PHP is more popular than perl, so it's even more likely....
Admin
OK, let's analyze once more:
1. rand() gets called twice, can result in two different values that get checked.
2. If this got fixed with an assignment to a variable, what if rand() would return 0.5?
3. It will never return 0.5 since its result is an integer (http://de.php.net/manual/en/function.rand.php)
4. Without arguments the function returns an integer between 0 and RAND_MAX (32767 on my system).
So if you fix nothing, user 70656 will always get the ticket.
Admin
Um.... why don't you just call them Biff and Cliff in your conversation? :P
Admin
The first example is just great. I'd like to disconnect the database server or anything like that from time to time just to screw up the clients.
If snipped #3 is actually php, all tickets will be assigned to '70656' as rand(); in php doesn't return a float but a int from 0 to system specific maximum. But maybe it got simplified by the sender.
BTW: I'm curious about what you guys would call the best php templating strategy if plain php files and smarty both suck badly.
Captcha: mustache - smells more like dirty sanchez
Admin
Dude, this is not PHP. :-)
(From the looks of it, I'd guess this is code from a Request Tracker module; RT is written in Perl.)
To consider your points one by one:
Admin
IMHO you're missing the point here.
It makes two separate rand() calls, so tickets most probably often don't get assigned.
Admin
The system you describe is just PHP; in particular, you describe content pages as pulling in formatting (headers, footers, etc). Typically when people talk about "templating engines" they are referring to a top-down organisation where _content_ is pulled in and requires no cargo-cult boilerplate.
The real WTF is that I fell for your obvious self-pimping :-)
Admin
Admin
http://www.perlmeme.org/howtos/perlfunc/rand_function.html
Admin
template file:
Admin
I suppose
use define SALESPERSON1_ID => 70656; # Biff
use define SALESPERSON2_ID => 72586; # Cliff
is considered too obvious to bother pointing out explicitly?
Admin
Even if the logic around rand() was correct - WTF are they randomly assigning for anyway?
Imagine if the tickets take an hour for a sales guy to process and they only get 10 or so a day...
Admin
The realest WTF is that the ids were hard coded yielding a fun to maintain bit when there's a staffing change. He should have had the ticket assigned to a random person in the sales group. . .and of course, if there's no sales group, or the ticketting system doesn't support it then clearly those things must be added.
** Martin
Admin
"The system you describe is just PHP"
Well, PHP is a templating language. Otherwise those pesky <?php tags wouldn't be necessary.
Any "templating engine" powerful enough to handle the needs of most complex web apps will end up reimplementing most of PHP anyway, so the way to protect yourself against mixing logic and presentation is to become a better programmer/hire better programmers, not put blind faith in the fact you've put another layer of templating on top of your templating engine.
Admin
Since PHP 5: XSLT
Admin
Is there any reason to be randomly assigning tickets? It could very well happen, even with a perfectly random ticket assigning process, that, out of 100 tickets, Person #1 could get 1 ticket, Person #2 could get 5 tickets, and Person #3 could get 94 tickets. That'd be unlikely, I suppose, but it could happen. Ideally, shouldn't such a system, upon receiving a new ticket to assign, check to see who has how many tickets, and then assign the new ticket to the guy with the fewest tickets already? I've never worked on a ticketing system before, so I'm speaking out of ignorance here, but it seems to me that randomly assigning tickets is an odd way to go about things.
Admin
I'm really curious why you feel this way. Can you give me some well-reasoned points to support your argument?
Admin
Admin
You're missing half the humor. I actually thought the same thing when I first looked at it, but it's even worse than that. Notice that the "rand()" function itself is being called in both spots rather than utilization of a "rand" variable. This will cause two different random values to be generated. As such, it might be < 0.5 for the > 0.5 test (meaning it won't get assigned to the first person), then it might be > 0.5 for the < 0.5 test (meaning it won't get assigned to the second person).
This is going to happen even more often than what you thought about the equals case! :)