Ramblings of a web guy

I got this via email.  I am not one to forward email to everyone I know so I figured I would post it here.  I love college football.  Its only 5 days away!

Stadium Size:

NORTH:  College football stadiums hold 20,000 people.

SOUTH:  High school football stadiums hold 20,000 people.

Campus Decor:

NORTH:  Statues of founding fathers.

SOUTH:  Statues of Heisman trophy winners.

Homecoming Queen:

NORTH:  Also a physics major.

SOUTH:  Also Miss America..

Cheerleaders:

NORTH:  If you are slightly coordinated, you make the varsity squad.

SOUTH:  You begin cheer camp at age two, complete with ballet, dance, & gymnastic training.

Getting Tickets:

NORTH:  5 days before the game you walk into the ticket office on campus and purchase tickets.

SOUTH:  5 months before the game you walk into the ticket office on campus & put name on the waiting list.

Women’s Accessories:

NORTH:  ChapStick in back pocket and a $20 bill in the front pocket.

SOUTH:  Louis Vuitton duffel with two lipsticks, waterproof mascara, and a fifth of Jack Daniels/Crown. Money is not necessary — That’s what dates are for.

Friday Classes After a Thursday Night Game:

NORTH:  Students and teachers not sure they’re going to the game, Because they have classes on Friday.

SOUTH:  Teachers cancel Friday classes because they don’t want to see The few hung-over students that might actually make it to class and throw up on their floor.

Parking:

NORTH:  An hour before game time, the University opens the campus for game parking.

SOUTH:  RVs sporting their school flags begin arriving on Wednesday for The weekend festivities. The really faithful arrive on Tuesday.

Game Day:

NORTH:  A few students party in the dorm and watch ESPN on TV.

SOUTH:  Every student wakes up, has a beer for breakfast, and rushes over to where ESPN is broadcasting “Game Day Live” to get on camera  and wave to the folks up north.

Tailgating:

NORTH:  Raw meat on a grill, beer with lime in it, listening to local radio station with truck tailgate down.

SOUTH:  30-foot custom pig-shaped smoker fires up at dawn. Cooking accompanied by live performance by “Dave Matthews’ Band,” who come over during breaks and ask for a hit off bottle of bourbon.

Getting to the Stadium:

NORTH:  You ask “Where’s the stadium?” When you find it, you walk right in.

SOUTH:  When you’re near it, you’ll hear it. On game day it becomes the state’s third largest city.

Concessions:

NORTH:  Drinks served in a paper cup, filled to the top with soda.

SOUTH:  Drinks served in a plastic cup with the home team’s mascot on it, filled less than halfway with soda, to ensure enough room for Jack Daniels/Crown.

When National Anthem is Played:

NORTH:  Stands are still less than half full.

SOUTH:  100,000 fans, all standing, sing along in perfect four-part harmony.

Smell in the Air After the First Score:

NORTH:  Nothing changes.

SOUTH:  Fireworks, with a touch of Jack Daniels/Crown.

Commentary (Male):

NORTH:  “Nice play.”

SOUTH:  “*#@&@, you slow *&%$@#! - tackle him and break his legs.”

Commentary (Female):

NORTH:  “My, this certainly is a violent sport.”

SOUTH:  “*#@&@, you slow *&%$@#! - tackle him and break his legs.”

Announcers:

NORTH:  Neutral and paid.

SOUTH:  Announcer harmonizes with the crowd in the fight song, with a tear in his eye because he is so proud of his team.

After the Game:

NORTH:  The stadium is emptying out.

SOUTH:  Another rack of ribs goes on the smoker while somebody goes to The nearest package store for more bourbon. Planning begins for next week’s game.

Update: As some people have pointed out, if this is on all the time in a production environment, it could be bad. We only enable it when debugging. But, in the interest of keeping the PHP world safe, I have edited the code.

Preface: I would not use this in a production environment on a full time basis.  When we do use it, we turn it on, gather some logs and turn it off.  Also, it has been pointed out to me that this will cause MySQL to not use the query cache in versions previous to 5.0.  That is another reason to not use this in a production environment full time.

So, on dealnews.com we often end up with a lot of queries that look kind of the same. It usually because we have a complex query that simply selects article ids from one or two tables and then a second query to select the data from the article table using those ids. If you have used MySQL much, you know that is often the better solution than doing a join where one table is huge and you need to order by the smaller table.

However, this becomes a problem when you start having a problem with a query or two. You can’t tell from a mysqladmin proc where the query is coming from. So, I came up with a solution.

We use a class that I wrote for all of our access to mysql. Its basically a wrapper for mysql_connect, mysql_select_db, mysql_query, mysql_num_rows(), etc. One method to handle all of that. Lots of you probably have one of these objects or libraries. Anyhow, what I did was add a comment into the sql just before I run the query:

if(!empty($_SERVER["REQUEST_URI"])){
    $uri = str_replace(”*/”, “%2A/”, $_SERVER["REQUEST_URI"]);
    $SQL = “/* $uri */\n$SQL”;
} else {
    $uri = str_replace(”*/”, “%2A/”, $_SERVER["SCRIPT_FILENAME"]);
    $SQL = “/* $uri */\n$SQL”;
}

Now, mysqladmin proc has the request URI for every query in it. The MySQL slow query log does as well. I know this is a simple little thing, but man, is it useful.

So, a while back, I did some tests with the mysql, mysqli and PDO extensions. In those tests, I found PDO to be much slower for selects than mysql and mysqli. Half as slow in fact. Santos mentioned these tests in a post about SDO. Wez has pointed out that the mysql API does not use the query cache when using prepared statements. Apparently, under the covers, PDO uses prepared statements for all queries. At least that is what I am taking from this. My tests showed the same speed whether I used the PDO prepared syntax or not.

So, I decided to try Wez’s trick of emulating prepared statements to see how PDO did. The results were interesting. Not sure if these are the “fair comparisons” that Wez wants to see, but I gave it my best shot. (Thank WordPress.com for the crappy font size)

extension         req/s
------------------------
mysqli              164
mysql               162
PDO (Wez Trick)     140
PDO (Wez+prepared)  127
PDO                  88
mysqli (prepared)    86
PDO (prepared)       81

So, this is good news. If I had seen these numbers the first time, I would not have been as shocked. There is still overhead obviously. But, its not nearly as big of a drop off.

To comlete the tests, I tried the same trick with inserts. You can see all the code at the link above. Basically, we do 10,000 inserts into a table with some random data.

extension          time
--------------------------
pdo (extended)     18.17s
mysqli (extended)  18.40s
mysql (extended)   18.46s
pdo (prepared)     25.04s
mysqli (prepared)  36.93s
mysqli             50.43s
mysql              53.09s
pdo                59.96s
pdo (Wez+prepared) 85.23s

I ran this several times. Maybe Wez or someone that works on PDO can shed some light on this. Seems like it would be tough to keep track of when to use this flag and when not to. Of course, most web applications are read heavy, not write heavy. My guess is there is more gain to emulating prepared statements than not.

So, one of the things I always use in Firefox is the auto Google Feeling Lucky feature. If you don’t know what I mean, then load Firefox and type php in the address bar. You will most likely go to http://www.php.net or a mirror of it. What is happening is Firefox is sending the words you type to the Google Feeling Lucky URL. That feature at Google then redirects you to the top ranked site for those terms. Its really handy for the PHP Manual for example. Just type php strtotime. You should be taken to the PHP Manual page for strtotime. Its really handy.

The only problem I have is that I like to use Yahoo! for search. There are a couple of reasons. One of the biggest is because they support the PHP community so much. Yahoo has Instant Search. They consider it to be an answer for Feeling Lucky, but it does me no good in this case.

I thought I was stuck until I discovered that Yahoo! offers RSS versions of searches. So, I wrote yahoo_luck.php. Its a simple little script that uses SimpleXML to grab a Yahoo! RSS search result and forward you on. I did put some backup in there for times when, for some reason, Yahoo! would not answer. Perhaps some of you Yahoo! guys in the PHP world can poke someone about that.

The one downside is that you will need your own web server. I tried to come up with some sort of javascript to do this. But, alas, I am not the JS wizard I wish I was. I am not even sure if the keywords.URL setting in Firefox could use JS.

To use this, just stick it on a server and replace keyword.URL in your Firefox about:config with http://www.example.com/yahoo_luck.php?s=. Enjoy.

From our jobs page:

As a dealnews web developer, you will help maintain our current stable of deal and price-tracking web sites, and build new features and new web sites as we continue to grow. You’ll be part of a small, fast-moving team of developers that are involved at every stage of product development, from concept to rollout.

We use Gentoo, Apache, PHP and MySQL.   While that does not need to be your expertise, it is a plus.  We have a little Perl and Python thrown in as well.  You will need to code on a non-Windows system as we run our development environment on our local machines.  Currently, we all use Macs.

A big plus, however, is disc golf.  We play weekly as an um, team building excercise. Yeah, team building.

Mark Cuban wrote a post about packaging.  He is so dead on.  I have always figured that this was done to prevent theft.  But, maybe it is a cool factor.  I use a pair of poultry scissors to open those hard plastic cases.  Still, they cause me lots of trouble and do occasionally bring blood.

Problem 1 in the article at IBM developerWorks kind of rub me the wrong way.

1. Using MySQL directly

Why not? How is the second code example in that post superior to the first? What I see is that the first example, that uses mysql_* directly, is more readable. The second snippet is a jumbled mess.

The article recommends using PEAR::DB. Is PEAR::DB even PHP5 ready? I don’t know, I don’t use it. The author could have at least used PDO. Still slower, but not as bad and is the future of PHP database abstraction IMO.

He uses a prepared statement to do the select. First, I have tested and I know is slower for MySQL. Second, it is not the end all be all of stopping cross site scripting that a lot of people believe it to be. You can only pass certain value parts of certain clauses. Many applications require more complex dynamic query creation.

As for the rest of the post, I agree with most of it. I would argue that many of the problems are not PHP/MySQL related, but just cases of bad programmers and/or new programmers that don’t know better. They read things written by big companies like IBM and follow one bad example (like using PEAR::DB when its not needed) and start off on the wrong road.

Update:  Seems I am not alone.  Peter, its not bad, you are right.  Kristian backs up my feelings about speed as well.

So, in the modern world, navigation in HTML often involves using lists.  You know, the ol and ul elements.  Most of the time, a list of navigation items have some sort of header.  I have done several things in the past to make that header look different.  That includes making it not part of the list, breaking specs and putting it outside of any li element, and using a class on the first element.  I was thinking, we really need an lh element like the th that tables have.  Its a handy way to have a heading that is still part of the document structure.

Well, on more than one occasion, I have found an element that I had forgotten or did not know existed.  I recently started using the dl, dd, dt tag elements for example.  So, I figured I would look to see if I had just missed it.  I check DevGuru for the <lh>, but no luck. So, I ran a search on Yahoo!.  Much to my surprise, there were many examples of this very element in use.  I got excited.  Maybe it was some deprecated HTML 2.0 element or something.  Upon more research, I found that <lh> was part of the HTML 3.0 spec which expired.  HTML 3.2 was later written and did not include<lh>.  HTML 3.0 was never more than a draft.  What a shame.  This little element could be making life a lot easier in a CSS world.

There is some good news though.  XHTML 2.0 will implement the <label> element for lists.  And if you if do not obsess about your page validating, Firefox, IE, Safari and Opera all recognize the label element inside and ol or li already.  If someone emails you telling you your page is not valid HTML, tell them you are ahead of your time.

I think I have finished the initial visual changes to the Phorum 5.2 template. I still have some logistic changes (like making all URL vars exist in a URL array instead of vars like another_thing_to_link_url). If you have a second, please give it a run though. Give me your thoughts and see if I missed any pages.

(Originally posted on the Phorum web site)

The recent post by SantosJ reminded me of a write up I did for the dealnews developer page. His post dealt with the good and bad of coding with PDO. For me, it was about speed, not ease of use. I will write any freaky code to save a cycle or two. In my tests (code is on the linked page), I found that PDO was slower than mysqli in every test except prepared inserts. Since the bulk of our application (and I suspect, most web apps) is read bound, that is not a big win for me. I was happy to see however that mysqli was in no way slower than the trusty old mysql extension. Good job to whomever did that extension.