I'm very curious to see Bruce "Tog" Tognazzini's, him being an interaction design guru 'n' all. For that matter, I wouldn't mind seeing any of the alleged experts' from the Nielson Norman Group.
You may well have some good points there (though I'd love to hear more details, especially about what you mean by "security model"), but I would dispute a few points:
It's object model is worthless compared to real OOP languages.
As a criticism of PHP3, this is spot on. As of PHP 4, however, things have improved markedly. No longer are there lame limitations like the inability to call methods on an object that's in an array ($ary[$key]->doStuff()), and passing and referring to things by reference really works. Also, PHP 4 grew a garbage collector, so you no longer have to worry about an app going belly-up just because it makes and immediately discards a few thousand objects. PHP doesn't yet have all of Java's syntactic sugar, but it's pretty good, especially if people follow good coding and documentation practices.
PHP 5 is planned to be practically an interpreted version of the Java language (speaking loosely). For example, 4 is missing destructors, abstract classes, interfaces, access specifiers, class constants, and automatic pass-by-reference. 5 adds all these things. Now, unlike Java, PHP won't force you to use these things, but, as I said above, you are free to use good coding practices.
It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios.
Though convenient for error trapping, what does exception handling (assuming you mean try/catch sorts of things in particular) have to do with rolling back DB transactions? My app uses waterfall-style (functions return errors) error handling and manages to roll back bad transactions just fine. It does make you blow a lot of code saying "if this worked, then keep going", though, so I'm thrilled that PHP 5 plans to add exceptions.
It's database support is mediocre at best: third party classes are currently the best (but not only) DB interface PHP has.
This strikes me as absurd, unless you're talking about cross-DB abstraction layers, in which case it strikes me as only moderately silly. PHP can access just about any DB known to man using built-in functions. As for abstraction layers, I use and recommend the excellent PEAR::DB thingamajig. It goes so far as to abstract the concepts of sequences, transactions, and oh just read the documentation. PHP also supports ODBC stuff, though I haven't played with it.
Cheers!
This is ridiculous. Scroll wheels, scroll nipples, and embedded trackballs are a tendon-pain-inducing and unnecessarily complex and kludgey way to implement a hardware interface for scrolling. I second the suggestion of this guy, who would rather have a "grab button" on his mouse. Hold down the "grab" button, and you can scroll the contents of the focused (or perhaps the under-the-mouse) content by dragging in whatever direction you like. I used to have something like this rigged on my old Mac with Scrollability (shareware) and in OS X with uControl (GPL'd). I found both solutions far more comfortable than my scroll wheel, though I'd love to see this supported more seamlessly (e.g., scroll more smoothly, work everywhere (even in graphics programs), and don't make me kludge it together with mouse-button-triggered modifier keys). After all, we already have one perfectly good tracking device; why stack another tracking device on top of it? This solution should work even on trackballs. Whadday'all think?
Speaking of independent games, I sucked down the demo of Marble Blast Gold yesterday and have found it a lighthearted and interesting change of pace from my usual fare, the very dark Quake 3. It apparently runs on just about anything: Mac >=10.1, Windows >=98, and a bunch of x86 Linux distros.
Several months ago, I bought a Clie PEG-SJ20. I have used the daylights out of it since then, running third-party software and X-Master hacks (think old MacOS-style INITs) galore and even using a [Sony-built or at least Sony-endorsed] external keyboard. Every Palm app I've tried has run flawlessly; this includes even a few featherweight music composition apps which use the built-in piezo buzzer thingy to play tunes. Maybe the parent post was referring to sampled audio, which my unit doesn't support. I do want to assure the reader, though, that the buzzer interface is apparently compatible.
In all cases, my Clie delivers at least the functionality of a "normal" Palm handheld; in most cases, a superset thereof. My unit's screen is 320x320. Sony has a few (disable-able) hacks in place that can hi-res-ify some text in non-Clie-savvy apps, but, at worst, everything is pixel-doubled and looks just like it would on a normal, 160x160 Palm. I don't know what they have it do on 320x480 Clies. One would hope it wouldn't stretch things disproportionately. Can anybody chime in on this? (I must rave about the screen: it has stunningly good contrast and beautiful white LED backlighting. It looks like a sheet of paper, and I wouldn't trade it for anything. (Look at one in a store, making sure you have the brightness turned up to a reasonable level.) If you want to do high-framerate stuff like games or autoscrolling text, though, buy a different model, because it smears like mad.)
As far as the Clie-only apps Sony ships, I expect that restriction is due to the custom hi-res API's Sony has bolted onto Palm OS 4. If you circumvented the do-not-copy bit (try the Palm app "FileZ") and tossed them onto a non-Sony Palm, they'd doubtless fail because the API's they call aren't there. Now, with Palm OS 5, Palm has written a standard hi-res API, so I expect Sony's OS 5 handhelds use--or soon will use--that instead.
A couple other tidbits:
My unit is advertised as having 16MB RAM. 15MB of it are available to me. I don't know how much flash is in it.
This is my first Palm, but the general UI looks identical to that which I've seen in my Palm emulator, except where Sony's substituted hi-res stuff for low-res. They've also added 2 prefs panels--Hi-res and Jog--to let you disable and enable various hacks Sony offers to make non-Clie-savvy apps take advantage of the Clie's fancy screen and scroll wheel, respectively.
P.S. What do you have to do to post an — around here?
For further reading on the subject of our society becoming ever more entertainment-centric, I commend to you Amusing Ourselves to Death by Neil Postman. He argues logically from explicitly stated assumptions (something I always appreciate) and surprised me in several instances by bringing to my attention disturbing things to which, living in the culture I do, I had been desensitized.
I just had to let you know, Mr. Wiggle, that I enjoyed several dozen seconds of laughter thanks to your unusual combination of the words "unfathomable" and "catastrophe". Or maybe it's just real late at night....
Never mind; that won't work at all unless the client machine stays dialed-up/connected/whatever and at the same IP address. And besides, it'd be faster to just have the final relay check the original source, in any case. That's what I get for posting without thinking first.:-) Sanity check status: failed.
Re:email as we know it is the problem
on
ISP Chief on Spam
·
· Score: 1
As for unforgeable headers, as long as you require people to go through an ISP's mail servers and don't have an authoritative list of all mail servers in the world, you have to allow the client system to provide headers that your server accepts. If you allow that then anyone can forge headers
What if we implemented a sort of "dial back" where the receiving relay sends a checksum/messageid/whatever back to the sending one, asking it to confirm that yes, it did indeed send the message? Then we've got 'em by IP. One problem with that approach, of course, is that it's insecure if you only check the immediately preceding relay; you'd need to check all the way back to the source in order to be sure--an O(too much) algorithm (since every relay would have to do it). But then, what if we took shortcuts by keeping a list of "trusted" relays, relays which are known to do this backtracing themselves? If we did that, a receiving relay would only have to "backcheck" to the most recent trusted relay (which could then be trusted to have already backchecked the relays before it). Sanity check, anybody? *continues breakfast*
That's funny; I've been mousing left-handed on Macs since '84 (though I'm right-handed...), and I have no problems with any of those. For command-shift-0, I make use of the right-hand command key, and for the others, I just pick up my right hand (so as not to abandon the mouse).
Incidentally, if your workflow is anything like mine and you'd like a 20% speed increase, try binding a mouse button to command-W. You'll love it.:-)
Slashdot Mirror
I'm very curious to see Bruce "Tog" Tognazzini's, him being an interaction design guru 'n' all. For that matter, I wouldn't mind seeing any of the alleged experts' from the Nielson Norman Group.
As a criticism of PHP3, this is spot on. As of PHP 4, however, things have improved markedly. No longer are there lame limitations like the inability to call methods on an object that's in an array ($ary[$key]->doStuff()), and passing and referring to things by reference really works. Also, PHP 4 grew a garbage collector, so you no longer have to worry about an app going belly-up just because it makes and immediately discards a few thousand objects. PHP doesn't yet have all of Java's syntactic sugar, but it's pretty good, especially if people follow good coding and documentation practices.
PHP 5 is planned to be practically an interpreted version of the Java language (speaking loosely). For example, 4 is missing destructors, abstract classes, interfaces, access specifiers, class constants, and automatic pass-by-reference. 5 adds all these things. Now, unlike Java, PHP won't force you to use these things, but, as I said above, you are free to use good coding practices.
Though convenient for error trapping, what does exception handling (assuming you mean try/catch sorts of things in particular) have to do with rolling back DB transactions? My app uses waterfall-style (functions return errors) error handling and manages to roll back bad transactions just fine. It does make you blow a lot of code saying "if this worked, then keep going", though, so I'm thrilled that PHP 5 plans to add exceptions. This strikes me as absurd, unless you're talking about cross-DB abstraction layers, in which case it strikes me as only moderately silly. PHP can access just about any DB known to man using built-in functions. As for abstraction layers, I use and recommend the excellent PEAR::DB thingamajig. It goes so far as to abstract the concepts of sequences, transactions, and oh just read the documentation. PHP also supports ODBC stuff, though I haven't played with it. Cheers!This is ridiculous. Scroll wheels, scroll nipples, and embedded trackballs are a tendon-pain-inducing and unnecessarily complex and kludgey way to implement a hardware interface for scrolling. I second the suggestion of this guy, who would rather have a "grab button" on his mouse. Hold down the "grab" button, and you can scroll the contents of the focused (or perhaps the under-the-mouse) content by dragging in whatever direction you like. I used to have something like this rigged on my old Mac with Scrollability (shareware) and in OS X with uControl (GPL'd). I found both solutions far more comfortable than my scroll wheel, though I'd love to see this supported more seamlessly (e.g., scroll more smoothly, work everywhere (even in graphics programs), and don't make me kludge it together with mouse-button-triggered modifier keys). After all, we already have one perfectly good tracking device; why stack another tracking device on top of it? This solution should work even on trackballs. Whadday'all think?
Here
Speaking of independent games, I sucked down the demo of Marble Blast Gold yesterday and have found it a lighthearted and interesting change of pace from my usual fare, the very dark Quake 3. It apparently runs on just about anything: Mac >=10.1, Windows >=98, and a bunch of x86 Linux distros.
Several months ago, I bought a Clie PEG-SJ20. I have used the daylights out of it since then, running third-party software and X-Master hacks (think old MacOS-style INITs) galore and even using a [Sony-built or at least Sony-endorsed] external keyboard. Every Palm app I've tried has run flawlessly; this includes even a few featherweight music composition apps which use the built-in piezo buzzer thingy to play tunes. Maybe the parent post was referring to sampled audio, which my unit doesn't support. I do want to assure the reader, though, that the buzzer interface is apparently compatible.
In all cases, my Clie delivers at least the functionality of a "normal" Palm handheld; in most cases, a superset thereof. My unit's screen is 320x320. Sony has a few (disable-able) hacks in place that can hi-res-ify some text in non-Clie-savvy apps, but, at worst, everything is pixel-doubled and looks just like it would on a normal, 160x160 Palm. I don't know what they have it do on 320x480 Clies. One would hope it wouldn't stretch things disproportionately. Can anybody chime in on this? (I must rave about the screen: it has stunningly good contrast and beautiful white LED backlighting. It looks like a sheet of paper, and I wouldn't trade it for anything. (Look at one in a store, making sure you have the brightness turned up to a reasonable level.) If you want to do high-framerate stuff like games or autoscrolling text, though, buy a different model, because it smears like mad.)
As far as the Clie-only apps Sony ships, I expect that restriction is due to the custom hi-res API's Sony has bolted onto Palm OS 4. If you circumvented the do-not-copy bit (try the Palm app "FileZ") and tossed them onto a non-Sony Palm, they'd doubtless fail because the API's they call aren't there. Now, with Palm OS 5, Palm has written a standard hi-res API, so I expect Sony's OS 5 handhelds use--or soon will use--that instead.
A couple other tidbits:
P.S. What do you have to do to post an — around here?
For further reading on the subject of our society becoming ever more entertainment-centric, I commend to you Amusing Ourselves to Death by Neil Postman. He argues logically from explicitly stated assumptions (something I always appreciate) and surprised me in several instances by bringing to my attention disturbing things to which, living in the culture I do, I had been desensitized.
I just had to let you know, Mr. Wiggle, that I enjoyed several dozen seconds of laughter thanks to your unusual combination of the words "unfathomable" and "catastrophe". Or maybe it's just real late at night....
Never mind; that won't work at all unless the client machine stays dialed-up/connected/whatever and at the same IP address. And besides, it'd be faster to just have the final relay check the original source, in any case. That's what I get for posting without thinking first. :-) Sanity check status: failed.
Aye, Americans typically do. "Physician" has a more formal connotation here and is rarely heard in spoken language.
That's funny; I've been mousing left-handed on Macs since '84 (though I'm right-handed...), and I have no problems with any of those. For command-shift-0, I make use of the right-hand command key, and for the others, I just pick up my right hand (so as not to abandon the mouse).
:-)
Incidentally, if your workflow is anything like mine and you'd like a 20% speed increase, try binding a mouse button to command-W. You'll love it.
I've a pet phrase for this: it's a "disaster of almost noticeable proportions". :-)