Quality comes from design and implementation, not testing. Testing confirms that quality (or its lack). Testing is only one means of achieving that confirmation, and it's almost never the most effective of those means (assuming "effectiveness" is measured as number of defects removed per unit of effort expended).
I did just try to buy sendmail from sendmail.com for a someone for whom I was doing some work, and we couldn't figure out how to do it from the website. There's no product or price list, certainly no "purchase online" section. You have to engage a salesperson, and the guy for whom I was working thought it was too much trouble to have to do phone-tag just to find out how much it would cost. He's still a sendmail user, but only the free version.
Sendmail's default configuration is very conservative with respect to both your machine resources, and the resources of those with whom you exchange mail.
Run sendmail with
-o MaxRunnersPerQueue=10
(or something bigger, if you want) and you can get past the biggest hurdle in sendmail performance -- by default, sendmail will handle all outgoing messages in a single queue. (Both qmail and postfix use multiple queues and/or runners by default.)
Sendmail can relay messages without doing any disk I/O, thanks to the asynchronous I/O libraries; coupled with multiple queue runners, it's hard to get faster performance out of any MTA.
"Frell" was what made the show jump the shark, introduced as an expletive an alien might say. Shortly thereafter, the writers became unable to write 3 minutes of dialog without using the word.
Out of AOL's millions of users, only a fraction are Mac users. AOL probably doesn't give a hoot about them, but if Apple were to lose them to Windows over AOL compatibility, it would be a bad thing, so Apple is going to take some pressure off of AOL by doing some development for them, since AOL hasn't been doing a stellar job of MacOS X development on their own. It's not about sticking it to Gates; it's about scrambling to keep market share.
It's better than that. Tom came to Old Bay SAGE and talked about the process of writing the book, and he said they used TeX for content, make for assembling the chapters and the book, and CVS for coordinating changes. Tom and Christine applied SysAdmin principles to writing the book!
Suppose someone finds an exploit in the device that does your retinal scan. Your admins must now deny your retinal scan credentials, and you have to switch to the other eye (presuming you have a spare). If that credential is compromised as well, you're completely out-of-luck.
With a passphrase-based system, by contrast, you can just change your passphrase as needed.
I can't believe your answer to this is to get a new browser. Shoehorning all of the specialized UI functionality you need into a browser is a great way to add needless bloat. Repeat after me: The browser is not the only UI tool in the world.
Again, you're trying to tell me how HTML solves all your problems, and then you say that the spreadsheet example was done "in script." You're agreeing with me that HTML alone is not sufficient for forms-based UIs. Again.
Thank you for making my point for me -- HTML alone isn't enough if you need to supplement it with ECMAScript, JavaScript or something else that *isn't HTML*. Specific functionality I'd like? I'd like to be able to display a master-detail form, where the detail records show in a scrolling sub-window, and the visitor can edit a field in one row in-place, and commit the change. HTML just isn't designed to do this without a lot of round-tripping of the master-detail display, as well as requiring separate forms for sub-record work. Oh yeah, I dare you to do it in a way that doesn't tie itself in to a specific browser. You, fairly experienced web designer that you are, may reply that people should use standards-compliant browsers. There's a bunch of Lynx fanatics waiting to beat you over the head with their text-only displays. (By the way, folks used to do UIs like this in curses all the time before the web came along, so it's not a matter of text-only versus non-text.)
HTML forms are only good enough for forms UI work if you don't demand much of your UI. You can't provide a fluid interface that really takes advantage of the bandwidth of the human-computer interface if you're constrained by the limits of HTML forms. I have no idea if the new Flash will be able to do this either, and God-willing, I hope I don't have to find out. I'm not knocking HTML, either -- it's fine for what it does -- rather, I'm knocking your myopic assertion that HTML is "well-suited" to forms. You want to see a really good forms app? Try a spreadsheet like Excel. No, I don't want to write anything in Excel, but if you want an idea of what forms UIs should aspire to, there it is. You can't get anywhere close to this level of fluidity with HTML, even if you include JavaScript. People can take advantage of much more interactive bandwidth than you can give them with HTML. Any designer who asserts that HTML forms UIs are just as good as desktop UIs is either working with really crappy desktop UIs, or doesn't know much about human perception.
Do I do most of my UI work with HTML forms? Sure, but it's a marriage of convenience, because I can deploy to my customers quickly, and not worry about platform issues as long as I stick to a low denominator. If I wanted something better, I'd probably have gone Java or Tk, but if Macromedia is serious about this, Flash may be a contender.
HTML by itself is pretty miserable for forms. Its sole advantage is widespread deployment. HTML forms have less functionality than 3270 terminals vintage 1985. To create an app with any significant data entry requires some low-level interactivity of the kind which, at this point, is probably best done with a Java applet (or would be, if Java support in any browser were not unacceptably slow and flaky); you can approximate it with JavaScript, but even there it feels clunky. Any significant data entry app, or data mining app is just painful to use as a web application, because of the lack of interactivity in forms. I wish I knew Flash well enough to know if it offered a reasonable alternative for form-based apps.
HTML getting more standardized all the time? No, it's not -- the standard has been around for a while, we're just waiting ages for browsers to catch up with the standard. Macromedia has been pretty steady in upgrading Flash, though, so it's actually Flash that's getting "more standardized" (especially with SVG around to provide competition).
Slashdot Mirror
I send my wife messages, and she throws exceptions back at me.
The API docs are definitely not sufficient.
Quality comes from design and implementation, not testing. Testing confirms that quality (or its lack). Testing is only one means of achieving that confirmation, and it's almost never the most effective of those means (assuming "effectiveness" is measured as number of defects removed per unit of effort expended).
Also I notice this paper was funded in part by the USPS. What is the USPS doing with this type of research?
Not to mention his filmography:
http://www.imdb.com/name/nm0004979/
Lookee there! It's apparently a Slashdot-Certified Networking Guy!
I think the Darwin award winner from a few years back did this first -- you know, the guy who strapped a JATO unit to his Pinto.
I did just try to buy sendmail from sendmail.com for a someone for whom I was doing some work, and we couldn't figure out how to do it from the website. There's no product or price list, certainly no "purchase online" section. You have to engage a salesperson, and the guy for whom I was working thought it was too much trouble to have to do phone-tag just to find out how much it would cost. He's still a sendmail user, but only the free version.
It's supported on some ATI cards, too. Not the real low-end stuff, but it includes Radeons as well as some non-Radeons.
Sendmail's default configuration is very conservative with respect to both your machine resources, and the resources of those with whom you exchange mail.
Run sendmail with
(or something bigger, if you want) and you can get past the biggest hurdle in sendmail performance -- by default, sendmail will handle all outgoing messages in a single queue. (Both qmail and postfix use multiple queues and/or runners by default.)Sendmail can relay messages without doing any disk I/O, thanks to the asynchronous I/O libraries; coupled with multiple queue runners, it's hard to get faster performance out of any MTA.
It's 11 bits for blue, 11 bits for green, and 10 bits for red. People don't like red as much as the other colors.
See! Tobacco is deadly!
"Frell" was what made the show jump the shark, introduced as an expletive an alien might say. Shortly thereafter, the writers became unable to write 3 minutes of dialog without using the word.
Of the folks I know with severe RSI, the majority are emacs users rather than vi users. It's not scientific, but that's my data.
Out of AOL's millions of users, only a fraction are Mac users. AOL probably doesn't give a hoot about them, but if Apple were to lose them to Windows over AOL compatibility, it would be a bad thing, so Apple is going to take some pressure off of AOL by doing some development for them, since AOL hasn't been doing a stellar job of MacOS X development on their own. It's not about sticking it to Gates; it's about scrambling to keep market share.
Quick, someone needs to write a petition to open-source Mac OS 9! And then we can put Beowulf clustering into Mac OS 9 and...
Oh, nevermind.
Some guy at Exabyte need to change his pants now.
Did I read that right? Will this product convert Acrobat files to Flash? Why would you do something like that?
It's better than that. Tom came to Old Bay SAGE and talked about the process of writing the book, and he said they used TeX for content, make for assembling the chapters and the book, and CVS for coordinating changes. Tom and Christine applied SysAdmin principles to writing the book!
Dammit! Use spoiler alerts before giving away the ending!
Suppose someone finds an exploit in the device that does your retinal scan. Your admins must now deny your retinal scan credentials, and you have to switch to the other eye (presuming you have a spare). If that credential is compromised as well, you're completely out-of-luck.
With a passphrase-based system, by contrast, you can just change your passphrase as needed.
I can't believe your answer to this is to get a new browser. Shoehorning all of the specialized UI functionality you need into a browser is a great way to add needless bloat. Repeat after me: The browser is not the only UI tool in the world.
Again, you're trying to tell me how HTML solves all your problems, and then you say that the spreadsheet example was done "in script." You're agreeing with me that HTML alone is not sufficient for forms-based UIs. Again.
Thank you for making my point for me -- HTML alone isn't enough if you need to supplement it with ECMAScript, JavaScript or something else that *isn't HTML*. Specific functionality I'd like? I'd like to be able to display a master-detail form, where the detail records show in a scrolling sub-window, and the visitor can edit a field in one row in-place, and commit the change. HTML just isn't designed to do this without a lot of round-tripping of the master-detail display, as well as requiring separate forms for sub-record work. Oh yeah, I dare you to do it in a way that doesn't tie itself in to a specific browser. You, fairly experienced web designer that you are, may reply that people should use standards-compliant browsers. There's a bunch of Lynx fanatics waiting to beat you over the head with their text-only displays. (By the way, folks used to do UIs like this in curses all the time before the web came along, so it's not a matter of text-only versus non-text.)
HTML forms are only good enough for forms UI work if you don't demand much of your UI. You can't provide a fluid interface that really takes advantage of the bandwidth of the human-computer interface if you're constrained by the limits of HTML forms. I have no idea if the new Flash will be able to do this either, and God-willing, I hope I don't have to find out. I'm not knocking HTML, either -- it's fine for what it does -- rather, I'm knocking your myopic assertion that HTML is "well-suited" to forms. You want to see a really good forms app? Try a spreadsheet like Excel. No, I don't want to write anything in Excel, but if you want an idea of what forms UIs should aspire to, there it is. You can't get anywhere close to this level of fluidity with HTML, even if you include JavaScript. People can take advantage of much more interactive bandwidth than you can give them with HTML. Any designer who asserts that HTML forms UIs are just as good as desktop UIs is either working with really crappy desktop UIs, or doesn't know much about human perception.
Do I do most of my UI work with HTML forms? Sure, but it's a marriage of convenience, because I can deploy to my customers quickly, and not worry about platform issues as long as I stick to a low denominator. If I wanted something better, I'd probably have gone Java or Tk, but if Macromedia is serious about this, Flash may be a contender.
HTML by itself is pretty miserable for forms. Its sole advantage is widespread deployment. HTML forms have less functionality than 3270 terminals vintage 1985. To create an app with any significant data entry requires some low-level interactivity of the kind which, at this point, is probably best done with a Java applet (or would be, if Java support in any browser were not unacceptably slow and flaky); you can approximate it with JavaScript, but even there it feels clunky. Any significant data entry app, or data mining app is just painful to use as a web application, because of the lack of interactivity in forms. I wish I knew Flash well enough to know if it offered a reasonable alternative for form-based apps.
HTML getting more standardized all the time? No, it's not -- the standard has been around for a while, we're just waiting ages for browsers to catch up with the standard. Macromedia has been pretty steady in upgrading Flash, though, so it's actually Flash that's getting "more standardized" (especially with SVG around to provide competition).
...as I recently discovered while scratching my nose. No, wait!...