Esther Derby has some great advice for managers…heck, for all of us.
1. Notice that what you are doing isnt working.
2. Notice what you are
feeling about that.
3. Center yourself.
4. Generate options.
5. Ask for
help if you need it.
6. Acknowledge your mistake.
7. Apologize if
necessary.
The non-billable hour has this great post on the idea of recovering costs for items such as printers, faxes, phones, etc.
Oh this is nice. What a great way to get your customers to come back to you. Lets bill them for everything we touch. Can’t wait for the cost-recovery implant that gets stuck into professional’s brains by their firms in order to capture the exact amount of brain-power a project took.
Ok, as Tim Bray does, I am here to expose the stupid with the great in all the code I write.
Mine was even more brain-damaged. I generate a series of aggregate Web Log stats,after filtering out bots/crawlers/images/css/robots.txt/etc., to generate meaningful information on the visitors to my sites.
However, the aggregate stats were not meshing with the drilldowns I was generating to examine data views, such as who hit what pages, who hit during what hour, etc.
Well, it helps if you look at the same data. The drilldowns used the following SQL filter:
ap.bytes != 0
Ummm…if I built the TEMP table for aggregate data view page using the same filter, the information would be aligned.
A Homer Moment…DOH!
Well, don’t have to worry about cooling my systems lately! Went downstairs last night and it was about 29F in the basement.
I figure since my main systems have two PIII processors, there should be no problem with them getting too cold!
I changed the info at Feedburner to reflect the new name of this blog. Please update your subscriptions.
Peter Lin has a Web performance paper here. Focuses on Java and Tomcat. Comments here.
Too bad he misses the point of external monitoring, because some of the other points he makes are very good. Too much focus on the data, not enough on how this improves performance.
Appears that he lives in the area. Peter, if you read this, say hi!
Watched Auschwitz on PBS tonight. It is terrifying to see this happening, but a historical perspective must be jarred to reality by the knowledge that the over-arching goals of the extermination camps still apears in human activity.
Sometimes I wonder if we are fit to consider ourselves the primary species on this world.
I have decided to change the name of this blog. This new title reflects what I do…as well as my personal philosophy.
It is also a great song by Husker Du.
Hang Around…fun ride ahead.
Ok, know that I have discovered the beauty of FULLTEXT indices, I know have discovered their dark side: even set for "IN BOOLEAN MODE", I get way more results than I was expecting.
Using the logic of the FULLTEXT search, it makes total sense. If I pass "/compression/" as a variable to the listing page, it returns everything that matches that string, including the sub-pages.
Time to haul out a regular expression. Using PHP’s ereg function, I perform a case insensitive match on the string.
if (ereg("^$page$","$row[DATABASE_URL]")) {
…
}
So I am skipping all of the overzealous returns, and displaying only the exact matches. And, believe it or not, this process is still far faster than using the REGEX engine in the MySQL query to start off with the exact matches.
If anyone has a less brain-damaged way to get MySQL to quickly return exact string matches, let me know.
Addendum: I found yet another brain-damaged thing with FULLTEXT searches: if you search to match against "/", exactly zero results are returned, even with "IN BOOLEAN MODE" turned off. This baffled me for a while, and is important enough for me to waste some mental energy on, as all requests for the root document in an Apache log file are referenced as "/".
After trying a few things, I actually had to write a corner-case "if" statement, that, if the passed URL exactly matches "/^/$/", use the REGEX method to pull the pages. All other pages are processed using FULLTEXT matching.
This behaviour is very weird.
I re-wrote the data inserting mechanism for the GrabPERF script. Previously, I had been looping through the measurements, then looping through the results to insert them.
Now I open two database connections, loop through the measurements and insert them after the data is collected. Much more efficient, although I am still a hack programmer.
I will be glad to share a sanitized version of the measurement script with anyone who asks.