Archive for debugging

the holy grail of bug reportage

I’m a programmer. Which means I get to fix my code (sometimes) and others’ code (far more often than I would like). As such, through my work, my projects and occasionally through this blog, I get numerous requests to fix this or that thing.

Believe me, I want to fix the issue. Never doubt that.

However, I can’t fix the bug if I can’t reproduce it on my end. This is the first and foremost rule to remember when sending in bug reports to anyone.

Read the rest of this entry »

del.icio.us:the holy grail of bug reportage  digg:the holy grail of bug reportage

Comments (1)

rendering engines revisited

No! Don’t groan! I can be long winded, yes, but this one’s short and sweet. There was a point I had wanted to add to the last post but as happens, it got left out. But it is a good one… why, exactly, do I care so much about which browsers user which rendering engines? Or even on their general history?

When I’m checking to see if my web pages work across various platforms and various browsers, I don’t have to start out by going through and checking how they appear in an all encompassing, exhausting review using each and ever on any and all. If I hit the four main engines in the order of their percentage of use: Trident, Gecko, Presto (Opera), and KHTML, I’m in a very good position. Granted, for more troublesome nit picky detail, it is possible for two different gecko-based browsers to have different problems with some bit of HTML or CSS or JS or other, but in the main, I’ve likely shaken out all the major glaring problems in the most efficient manner.

Knowing that Safari has the lion’s share of the Mac OS lets me ensure that I’ve taken care of the majority of Mac users by checking with that one. If there’s some issue with MacIE, I can pretty much leave it alone or let it degrade. Or if I’m pressed for time, I can choose Safari over MacIE or Camino or Mac Firefox and get pretty good Mac coverage.

Speaking of which, I’m aware that this blog doesn’t display well in Safari. I’m hoping to have some time on a borrowed Mac soon to figure out why.

del.icio.us:rendering engines revisited  digg:rendering engines revisited

Comments (3)

rethinking form/post conventions

Ever since I first started scripting cgi to process forms I’ve used the two file format: the first file puts up the form and such and calls the second file to process the results of the form.

But it really doesn’t have to be like that. At work, I have a single program that lets you search through our database and display things, setting options and so on, and paging through the results. It only uses one executable (well there are a few more, but each one encapsulates a certain kind of function and as long as you’re doing that, you stay within that executable). Now admittedly I’ve torn my hair out more than once debugging this thing, so this idea can go too far in the other direction, but keep it to simple pairs of form/post and I’m liking it.

So I’ve started looking at my old sites and in particular the old one of mine that was offline for six years and rethinking how I did this stuff. And I’m thinking the single file form/post is a much better way to go. It’s fewer files for one thing. I’m not left having to grep through the file to see what it calls to trace down problems. They’re all there in one spot.

So for example I just redid the mail form which started out in mail.php that called sendemail.php (that’s another thing, it simplifies naming conventions — at another site of mine I’ve been trying to standardize to action_form.cgi and action_post.cgi but still it’s all a mess.

But this comes out nice and slick in one file. Start up the headers, check whether it’s a submit and the form goes in the first half the if statement, the post in the second half. Close off with the footers and it’s all set.

Now, let’s see, just how many more files are lurking around on this site? Sigh…

del.icio.us:rethinking form/post conventions  digg:rethinking form/post conventions

Comments (1)

the horror that is MSIE 6

I know this is a bad browser. But when I’m on the user end, it’s easy enough to ignore, especially when I use Firefox or Opera or even Konqueror. However on the web author side, it really makes me tear my hair out. And I just found a beaut of a bug, where it doesn’t like plaintext http in certain situations. I played around with it for a while, and finally just excluded the call to the plugin based on browsers. So, if you’re reading this with MSIE 6, you are not seeing the recent comments in the sidebar. (And if you’ve got XPSP2 and/or plan to upgrade to Vista, definitely snag IE7. I’ve been pleasantly surprised with how many standards compliance issues they actually fixed…)

My coworker isn’t very helpful: telling me I should put in an activex control that shuts down IE6 if someone tries to open DR in it :-D Oh, the temptation…

del.icio.us:the horror that is MSIE 6  digg:the horror that is MSIE 6

Comments

wp-CaTT modifications

I use the wp-CaTT plugin for a simple Technorati hook. All it does is add Technorati links straight off the WordPress categories I choose for each article. I like it because it is simple, focused, and fast. I don’t have to do anything extra — always a bonus, I’m very lazy — to get it to work, and it doesn’t slow down my website either (generally, DreamHost does that just fine all by itself). Other plugins I looked at got all complicated with specialty tags where I’d have to remember not only the syntax, but to do it at all while scribbling my notes down. Or, they had so many (admittedly very impressive) bells and whistles that I simply wasn’t utilizing all of them which always seems a waste. Or worse of all, they slowed the site down.

However, in my mad theme-a-thon of yesterday and in my subsequent tweaking of each theme to standardize them a little bit and so on, I noticed this plugin really didn’t handle different theme’s varying separators. When I print out the categories for each post, I do so via a call like this:

<?php the_category('<br />') ?>

What this does is it prints out the list of category links (linked to my own WP’s database of categorized posts). The parameter tells it how to separate each category, in the above case with br’s, so in that example, all the categories will be on their separate lines (this is from the Barthelme theme). There are all kinds of possibilities: Chocolate Bar uses vertical bars as separators, and DR’s default theme uses commas.

The wp-CaTT plugin, however, is set up so that when I drop it in and use it, I need to edit its php file to set a variable to the same value used in the call to the_category.

Obviously when I started using multiple themes, that became a problem. So I went poking about in the plugin’s code, and found this:

    // 1. SET THE Delimiter TO THE CHARACTER YOU'RE USING TO SEPARATE MULTIPLE CATEGORIES APPLIED TO THE SAME POST.
    // FOR EXAMPLE, IF YOUR INDEX.PHP FILE CONTAINS the_category(', ') YOUR Delimiter IS ", ".
$Delimiter=", ";

which I replaced with (after tinkering with several other ideas):

    if (preg_match("/,/", $url))
            $Delimiter = ", ";
    else if (preg_match("/<br ?\/>/", $url))
            $Delimiter = "<br />";
    else if (preg_match("/ \| /", $url))
            $Delimiter = " | ";
    else
            $Delimiter = ", ";

There’s probably a better way to gracefully handle it if none of the matches work. I thought of defaulting to a simple space, but the problem is the $url variable is basically a list of href’s so there’s plenty of spaces, and such a default if it got used would result in a mess on my screen. I suppose that would be one way to alert me to the need to add another check.

I’ve been trying to think of a nice way to allow wp-CaTT to be flexible about what it can recognize and match against. One issue is that the $Delimiter variable needs to be set to whatever the actual delimiter is. I can’t just use a longer regexp that combines all the terms, because the plugin reassembles the original href’s with the added Technorati tags, using the delimiter. In addition, I can’t just use the list of delimiters straight, I have to regexp-ify them. In other words, the delimiter " | " has to be escaped because the vertical bar carries special meaning in regexp’s. Or the br took an optional space (” ?”) because some people put down <br /> and others <br>. Hmmm…I suppose people also put down just <br>, too… ‘k…

   else if (preg_match("/<br ?\/?>/", $url))

that fixes that…

I suppose I could take the tack that the Technorati bubbles themselves become the separators, and leave the delimiter empty. But then a theme like Barthelme points out the need to preserve it anyway, because Barthelme prints each category out on its own line and the cleanness of that presentation is spoiled if the categories start wrapping instead.

del.icio.us:wp-CaTT modifications  digg:wp-CaTT modifications

Comments

« Previous entries · Next entries »

Bad Behavior has blocked 1096 access attempts in the last 7 days.