...more recent posts
Random shot of the day:
Random shot of the day:
Hmmm. I found a subtle bug last night I have to fix today. I found it because of the link I put up to ftrain (below.) Evidently somebody, we'll call him or her A (a signed in user here, but not me) followed the link to ftrain. Good. So then A shows up in Ftrain's referer logs (browser, ip address, OS, and the URL of the link they followed to get to the page.) The subtle part is that A got to my page from the front page, where my page was showing as having new posts. So A clicked through to my page by clicking on the [posts] which uses the /jim/index.php3?new URL which will print out only the new (to user A) posts on my page. The problem is that someone from ftrain followed the link back in order to check out my page and see who was linking to them. Cool. I'd like that guy (if it was him) to check us out. Unfortunately, he came back in with the /jim/index.php3?new (instead of just /jim/ or just /jim/index.php3) and because he didn't have the cookie there were in effect no new posts for him to read, so the page didn't show anything. D'oh. This is easily fixed. I just have to check if the URL contains ?new (which I look for anyway, of course, so that it can act on the ?new command) and then double check that the user is known. If not, it should just default back to index.php3. Easy. Something like:
if (isset($query_string)) {
if (!isset($dmtreecookie)) {
Location("header:http://www.digitalmediatree.com/jim/")
}
}
The problem, like so much else in this project, is not so much fixing something that is broken. The problem is seeing all the possible ways something might be quietly broken (that is: broken, but still working.) So, I'm sorry to have missed an honored visitor, but I did learn something. I'll have that fixed by later today.
Hmmm. I found a subtle bug last night I have to fix today. I found it because of the link I put up to ftrain (below.) Evidently somebody, we'll call him or her A (a signed in user here, but not me) followed the link to ftrain. Good. So then A shows up in Ftrain's referer logs (browser, ip address, OS, and the URL of the link they followed to get to the page.) The subtle part is that A got to my page from the front page, where my page was showing as having new posts. So A clicked through to my page by clicking on the [posts] which uses the /jim/index.php3?new URL which will print out only the new (to user A) posts on my page. The problem is that someone from ftrain followed the link back in order to check out my page and see who was linking to them. Cool. I'd like that guy (if it was him) to check us out. Unfortunately, he came back in with the /jim/index.php3?new (instead of just /jim/ or just /jim/index.php3) and because he didn't have the cookie there were in effect no new posts for him to read, so the page didn't show anything. D'oh. This is easily fixed. I just have to check if the URL contains ?new (which I look for anyway, of course, so that it can act on the ?new command) and then double check that the user is known. If not, it should just default back to index.php3. Easy. Something like:
if (isset($query_string)) {
if (!isset($dmtreecookie)) {
Location("header:http://www.digitalmediatree.com/jim/")
}
}
The problem, like so much else in this project, is not so much fixing something that is broken. The problem is seeing all the possible ways something might be quietly broken (that is: broken, but still working.) So, I'm sorry to have missed an honored visitor, but I did learn something. I'll have that fixed by later today.
I often check in over at ftrain, but I hadn't seen this great piece. Now robotwisdom is linking him a lot though, so I caught it that way (the RW link had it as "Totally uncalled-for Mahavishnu-Orchestra bashing.") Much good writing on that site.
I often check in over at ftrain, but I hadn't seen this great piece. Now robotwisdom is linking him a lot though, so I caught it that way (the RW link had it as "Totally uncalled-for Mahavishnu-Orchestra bashing.") Much good writing on that site.
Here's a very interesting rumor from MacOSrumors about Lucent/Apple wireless plans:
"Rumors are rapidly building regarding a new Lucent Technologies chipset that will not only shrink Apple's AirPort hardware and add 54Mbps (compared to today's 11Mbps) bandwidth support as previously reported, but would also support the popular Bluetooth wireless interface technology over standard and high-performance AirPort bands....allowing Apple to support Bluetooth without conflicting with its existing AirPort hardware or adding to the wholesale costs of its computers. If the rumors prove true and Apple does plan to be the first to market with this technology, it could be a major strategic advantage."AirPort (802.11b) and Bluetooth working together? That would be a very good thing.
Here's a very interesting rumor from MacOSrumors about Lucent/Apple wireless plans:
"Rumors are rapidly building regarding a new Lucent Technologies chipset that will not only shrink Apple's AirPort hardware and add 54Mbps (compared to today's 11Mbps) bandwidth support as previously reported, but would also support the popular Bluetooth wireless interface technology over standard and high-performance AirPort bands....allowing Apple to support Bluetooth without conflicting with its existing AirPort hardware or adding to the wholesale costs of its computers. If the rumors prove true and Apple does plan to be the first to market with this technology, it could be a major strategic advantage."AirPort (802.11b) and Bluetooth working together? That would be a very good thing.
And for my reference, here's the PHP/GTK+ project. Yes, that means PHP language bindings for GTK+ which will allow for building client side graphic user interfaces. Nice.
And for my reference, here's the PHP/GTK+ project. Yes, that means PHP language bindings for GTK+ which will allow for building client side graphic user interfaces. Nice.