Interesting, just the other day I had a similar idea. However, we don't need plants, they take too long to grow, and they require too much space.
What we need to do is make use of photosynthetic microbes. The potential for energy production using microbes has many upsides.
Reproduce very quickly.
Can be engineered to produce usable/valuable biproducts (ie. methane, alcohol, etc.), and to tolerate a wide range of environmental conditions.
Highly efficient use of light energy.
Aging populations could be harvested into biomass. AFAIK, no processes exist currently to transform biomass into petrochemicals, but such a process seems plausible (possibly by the aid of other microbes?).
Of course, it may be some years until biotechnology and bioengineering mature to make such a vision practical and cost-effective, but it is an interesting ponder, IMHO.
It appears that the author of this presentation has read a bit on cochlear function, but the premise of his argument is purely speculative, offering nothing of scientific value.
Immediately, my skepticism made me think, your eye and brain make similar tuning adjustments, so why has nobody made this argument against the CRT? The fact that is missing here, is that the ear and eye and all sensory systems of the human nervous system make tuning adjustments continuously, in real-time, and have proven themselves time and time again to be remarkably plastic and resiliant.
Perhaps if you grew a person inside a box where only audio that suffered lossy compression was avaiable, you'd get a person who can't process the generally unnoticeable differences (note: unnoticeable != impercievable).
This is analogous to persons who attempt to learn foriegn languages beyond early childhood for which there is limited overlap in sounds relative to the native language of the speaker. The end result is, certain sounds are simply not processed correctly.
The problem I see with the author's premise is that proliferation of lossy compression schemes will result in this type of immersion, only it fails to indicate that *any* sound a person hears that is not compressed is still processed by the ear and brain. I doubt that a child who has listened only to MP3 music wouldn't be able to tell the difference when first introduced to live music.
Of course, I offer no scientific proof to refute this article that offers no scientific proof.
One question: in what way could this system possibly prevent somebody from creating a bot that would read SPAM all day long and get paid for it? If this goes into place, I'm sure to make zillions as my computer gladly signs up for SPAM, opens it, and deletes it for me.
"This confirmation verifies that ECFS has received and accepted your filing. However, your filing will be rejected by ECFS if it contains macros, passwords, redlining, read-only formatting, a virus..."
What? I can't include a virus in my submission? What's this country coming to? (and why do they need to state such a restriction so clearly? Did the word "implied" lose its meaning?)
Transition to DTV is not hindered because content providers are reluctant to provide material without digital rights management. Such a hypothesis is most certainly a farse given in efforts to enact governmental regulations aimed at gauranteeing the establishment of a powerful yet unregulated national industry. Television as it is today provides no copy protection, yet there is no dearth of content. That in and of itself proves the sentiment above to be phony. In fact, the prevalence of the home video recorder in American living rooms evidences this claim, and VCR production has developed into an industry in and of itself. By the guiding hand of the free market, content providers will produce high quality digital content for television when consumers demand it and will accept none other.
There is no mandate for such regulation as the Broadcast Flag issue, and there is no saleable avenue by which to present such a work to the American people as something that is in the best interest of the country. The fact of the matter is, DTV rollout has been slow due to the expense of HDTV equipment. Manufacturer and retailer propaganda has clearly illustrated the superiority of the high definition format to the American consumer, yet in our current state of economy, the American consumer simply cannot afford to take out a loan simply to purchase a television. Take heed not to enact regulations that our nation cannot afford during this troubled time, and take action to preserve the free enterprise that has built our nation from a dream.
Can a free website live in a nation without freedom?
I was just wondering if the "unfair governmental-sponsered competition" that the article references was lifted from the the pages of NAFTA. Does anyone have any further info/links on the PubScience shutdown? I recall public debate over NAFTA's broad authority in such situations, and (in reference to yesterday's article: "leaky abstractions") was thinking that this could be a case in which NAFTA "leaks".
Swapping Values Without Using a Temporary Variable
on
The Python Cookbook
·
· Score: 2, Offtopic
I have to ask (given my Python illiteracy), does Python have built-ins for such an operation? Or is this just "how to implement an old trick" to "get your feet wet" with Python?
If my coffee is working correctly this morning, I'd assert that any language with an XOR-assign could accomplish this feat (with the added restriction that the vars be of the same size, or operations are performed iteratively on byte pointers).
Isn't he the king of live tomb excavating adventures? One bust, two busts, how many busts can we handle? Seriously, archealogy really isn't made for live TV. Save the hype for when something is *found*, not *expected*.
What kind of interview question is that? FRIENDSHIP BREAKS ENCAPSULATION, A TENET OF OO DESIGN! Obviously, if your candidate speaks volumes on friendship, than he is a hack who will run rampant through your code and leave spaghetti in his wake.
Seriously, a better question would be, "How would you approach writing a program that does X"
LOL! I also had a mysterious software bug that I eventually proved to be hardware (with great satisfaction;).
Anyway, I was working on a robotic lid for a Thermocycler (used in wet labs). Thing is, every few hundred iterations through the open/close test cycle would show a dropped command. Communication was I2C written by some third-party hacks, and the boss figured it was the problem. In all honesty, the implementation was pretty crappy, so I poured over every minute detail (small protocol I2C, not much to go wrong). I even gouged out a good portion of the code to put in retries and good failure behaviours. After about a week of reimplementing the server and client end of the bus I decided to go downstairs and get an O-Scope from production. I had to beg for the thing. Finally, when I traced the lines it was all too obvious what was causing the drops. Some engineering bozo placed the I2C lines adjacent to the power lines, and failed to shield the power lines.
The result: 60-cycle induction across the bus (slow compared to I2C, so collision happened rarely, and my failure adjustments were pretty darn good at rectifying them). Anyway, knowing this I was able to tune the code and save the release date, though the designer of the hardware should've known better in the first place and saved me some headaches!
I think that's the problem source for all the bickering in this forum. The purpose of the Jam is to get talented people together to bounce ideas off each other and hopefully come up with some new ideas, not to create saleable games (four days isn't much time to polish the work).
Perhaps the developers could have chosen a different source for their sprites, but I'd have to say from experience that the amount of time in question here is certainly not enough to design sprites from scratch (if you want to code the game at all)! I haven't really looked, so I wonder if anyone is putting their art out for free (as in beer) on the web??? An open-sourced art gallery, anyone? (Sadly, most free art I've seen is worth the price you pay for it)
Anyway, I thought some of these concepts were clever, though I did wonder why so many of them were based on numerous hordes and gods (Must have been the caffiene).
The parent of all of this was certainly in err, but this still isn't a very good experiment. Look at the number of testers that were used. Most tests numbered in the 30s with respect to the number of subjects. While that number may be sufficient for small sample statistical tests, it is not a sufficient sample to test for such a normative value across the human population, such as judging music quality represents. Having achieved a small variance of opinion must not be determined to prove that the sample size was large enough to account for variance in opinion for the greater population, and while these tests are interesting, they are incomplete IMHO.
LOL! That's quite a reward for finding errors in Knuth's brain child. While Knuth professes Computer Science and the French language have changed significantly since vol. 1, the Economics of error-finding have remained the same... What about inflation Prof. Knuth!?
This suggestion should be worth $0.32
Re:In Case It's Slashdotted (+4, Funny)
on
Built For Use
·
· Score: 2
LOL, You've got to be kidding me. Exactly who is moderating in here!?
Re:And one of the reasons why flash...and xml...
on
Built For Use
·
· Score: 2
While HTML is here to stay, Flash does have a market, IMHO. Pizzaz may not be appropriate for corporate sites, but for diversions, its not so bad. You're right though, Flash is disappearing from corporate sites, so I agree with you on that end.
As for XML, while it may not *replace* HTML, I don't think I shall ever need to hand write HTML (or have a design app write it for me) again. Given the extensibility of XML in defining an object model custom to the needs the business, the advance of schema and transformation technologies, and the push for W3C standard XML support in all web browsers, XML is here to stay, and will maintain a strong presence in corporate sites. Frameworks that take advantage of XML to generate HTML web sites integrate better with other corporate software systems, most prominently databases, if simply for the reason that HTML is clumsy and loosely enforced, whereas XML has a strong definition, can be validated to a schema, can represent a complex DOM, can be parsed efficiently, etc.... A handful of XML initialization files can define an entire site if the framework is shrewdly designed, making the site more extensible and more maintainable than would be if HTML were the only choice. A couple of bioler-plate XSL transformations (+ a few custom) can represent your data in more meaningful and modifiable ways than you can have with rote HTML. Server-side, big players Java and Microsoft both have excellent support for XML, and it is ever-growing.
HTML has stagnated, because it is too sloppy to fix at this point, and object model standards were clobbered by Microsoft. That is why sites feed you 'Minimal-tag-HTML', and in most cases, I'd suspect it has been transformed from XML ala XSLT.
XML + XSD + XSLT + CSS = better than HTML alone.
Completely aside: if anyone who contributes to Mozilla in the XML - XSLT newsgroup, I've noticed that Mozilla doesn't recognize a transformation on an XSD if the extension is.xsd (it does if you rename the file to.xml), though XSD is valid xml syntax. Why would I do this? It makes for a nice documentation resource, and a transform on XSD requires almost no maintenence. I tried to post to the newsgroup, but here at work there is no news server, for security purposes, so alas, I could not.
Take it farther... (this is not Troll, IMHO)
on
The Wireless Arcade
·
· Score: 2
Some points made in previous posts:
Enjoyable gameplay is not necessarily dependant on flashy graphics (just as enjoyable movie viewing is not necessarily dependant on flashy graphics - see Hollywood.)
Multiplayer games on PDAs, cell-phones are somewhat limited by
cost in phone minutes
People-on-the-run finding the setup time inconvenient
The tremendous market I see is in multiplayer games of chance, for money. That is to say, let's set up a multiplayer poker game for real stakes (or head-to-head Pong tourney for cash). GAMBLE ON YOUR PDA/PHONE, my friends! All human opponents! Best odds! Get your fix on Route 66 (literally)!
Hmmm.. how to authenticate though... sadly, 'wireless security' is an oxymoron, and where there's a bill, there's a way.
I was working on a project using VB *sigh* a few years ago when I discovered a very peculiar bug. In order to get a form to appear, I was forced to call DoEvents() - TWICE IN A ROW!!!! I guess VB thought I didn't mean it the first time.
I submitted this link to a CNN article before reading the/. front page today, and given its "Popular Press" status, I'm sure it won't make it through the Slashdot editors. However, it seems the popular media has taken an anti-Palladium stance for now, perhaps to cool the flames of this article.
Given the reliance on hardware encryption, Palladium requires everybody to buy a new computer to use it.
Given that an encryption system that can stand up against attack through time has never been accomplished in history, the MS plan has little chance for truly ensuring "private data".
Given that the United States government want to be able to look at your data because you might be a terrorist (or just an enemy of the state), "private data" opposes Big Brother, and is therefore not likely to give any *real* privacy at all (unless you just have blind trust in the govenment;P).
The good news is, I don't think the 'commons' are buying into Palladium, at least not yet. Besides, real paranoids don't use Windoze.
BTW, It's illegal in the US for telemarketers to call cell phones. If it happens to you, get the company name, and report them to the proper authorities. The offense carries a stiff fine, I believe.
How could testing less possibly solve your problem!?
Test smarter, not less. Many of the above posts have shrewdly indicated good method of preventing bugs (an ounce of prevention, anyone?), and below I have some ways you may want to consider in testing your software. Sadly, the poster didn't give a whole lot of information to go on, so this offering is a bit vague, I'm afraid.
At our shop, we invest a good amount of time in developing test modules for all interfaces in the project, almost as much time as it takes to write the modules themselves. Every night, an automated build machine builds and installs the latest version from source control, and initiates a test script that invokes the test driver suite which loads and tests all public interfaces. Every function is tested with expected input versus expected output, and further by sending unexpected input (like that of a malicious user, or failed communication). All exceptions, assertions, and incorrect output is checked as well, as any memory leaks, by the C-runtime debugging utilities, and Bounds Checker will soon be in use as well.
This approach serves 3 purposes:
It readily finds crashes that human testers may not find, since it checks every public function with varietal input.
It aids regression testing for modules that have been changed.
It checks for leaks, which can cause problems that may be evident only after extended execution times (doesn't apply if your language is garbage collected)
Further, by having an automated build every night (that emails everyone on the project, including the project manager, ehhem), developers are careful not to "break the build", and thus pay attention to details before committing their code.
This method is only a preliminary test; however, and it cannot find every bug that may or may not exist. All code is audited to ensure it meets coding standards. You'd be surprised how failing to meet standards often evidences a piece of code that was written in haste, and as such, is a good place to looks for bugs. Also, we employ code testers who run the software through use cases (which are sequences of actions determined to be general ways in which users want to use the software). These testers also put the software through non-use cases, in which the actions do not follow expected sequences.
I hate to point out the obvious, but it is important to test software freshly installed on "clean machines", not development machines.
In the end, if it is at all possible, it is nice to have users who are in some way affiliated with the software company to give a "field test" so-to-speak on alpha and beta versions of the software. In any complex piece of software, there will be a chance for hard to find bugs (relative to the developer) to occur. Tolerant users are the best and last resort to finding any obscure bugs before the general public gets their click-happy hands on the software.
Conclusion: design smart, code smart, follow standards, test smart, test everything, and track all bugs (as if that is news to anyone).
PDAs! Yikes, doesn't that open up new avenues for *cheating* !? At least with calculators, a wise instructor can design the test problems so that the calculator is of little actual help, and that conceptual understanding is what is being measured.
With a PDA, you have the risk of the entire class linking up to the nerd who actually worked problems and listened in class.
According to WaSP, modern browsers are a necessity. The problem is, WaSP doesn't have the power the impose such a mandate, and my grandma uses whatever browser came bundled with her machine (how did IE win the browser war?)
IMHO, standards are great, but only if they are, in fact, standards. Thus, everything I write for the web follows the LCD (lowest common denominator) philosophy. Heck, I don't need tricks to put something that looks good on the screen (I'll do the alpha blending during graphics production, not at runtime). I don't like rewriting everything for a new browser (neither do the WaSP gurus), and that is why I'll stick to plain ole' minimal tag set HTML.
HTML is not the problem for me; the problem in getting a site to work properly on any browser comes in when you try to use JavaScript. An standard object model for *JavaScript* is what I really need, and that is just not a reality yet.
Some have pointed out IE's tolerance for mistakes is a problem, and I couldn't agree more. As a development browser, IE is a big mistake, unless you don't care about users of other browsers at all. Thank goodness for Mozilla.
Slashdot Mirror
What we need to do is make use of photosynthetic microbes. The potential for energy production using microbes has many upsides.
Of course, it may be some years until biotechnology and bioengineering mature to make such a vision practical and cost-effective, but it is an interesting ponder, IMHO.
It appears that the author of this presentation has read a bit on cochlear function, but the premise of his argument is purely speculative, offering nothing of scientific value.
Immediately, my skepticism made me think, your eye and brain make similar tuning adjustments, so why has nobody made this argument against the CRT? The fact that is missing here, is that the ear and eye and all sensory systems of the human nervous system make tuning adjustments continuously, in real-time, and have proven themselves time and time again to be remarkably plastic and resiliant.
Perhaps if you grew a person inside a box where only audio that suffered lossy compression was avaiable, you'd get a person who can't process the generally unnoticeable differences (note: unnoticeable != impercievable).
This is analogous to persons who attempt to learn foriegn languages beyond early childhood for which there is limited overlap in sounds relative to the native language of the speaker. The end result is, certain sounds are simply not processed correctly.
The problem I see with the author's premise is that proliferation of lossy compression schemes will result in this type of immersion, only it fails to indicate that *any* sound a person hears that is not compressed is still processed by the ear and brain. I doubt that a child who has listened only to MP3 music wouldn't be able to tell the difference when first introduced to live music.
Of course, I offer no scientific proof to refute this article that offers no scientific proof.
This system is pure fantasy.
One question: in what way could this system possibly prevent somebody from creating a bot that would read SPAM all day long and get paid for it? If this goes into place, I'm sure to make zillions as my computer gladly signs up for SPAM, opens it, and deletes it for me.
"This confirmation verifies that ECFS has received and accepted your filing. However, your filing will be rejected by ECFS if it contains macros, passwords, redlining, read-only formatting, a virus ..."
What? I can't include a virus in my submission? What's this country coming to? (and why do they need to state such a restriction so clearly? Did the word "implied" lose its meaning?)
FCC, listen up.
Transition to DTV is not hindered because content providers are reluctant to provide material without digital rights management. Such a hypothesis is most certainly a farse given in efforts to enact governmental regulations aimed at gauranteeing the establishment of a powerful yet unregulated national industry. Television as it is today provides no copy protection, yet there is no dearth of content. That in and of itself proves the sentiment above to be phony. In fact, the prevalence of the home video recorder in American living rooms evidences this claim, and VCR production has developed into an industry in and of itself. By the guiding hand of the free market, content providers will produce high quality digital content for television when consumers demand it and will accept none other.
There is no mandate for such regulation as the Broadcast Flag issue, and there is no saleable avenue by which to present such a work to the American people as something that is in the best interest of the country. The fact of the matter is, DTV rollout has been slow due to the expense of HDTV equipment. Manufacturer and retailer propaganda has clearly illustrated the superiority of the high definition format to the American consumer, yet in our current state of economy, the American consumer simply cannot afford to take out a loan simply to purchase a television. Take heed not to enact regulations that our nation cannot afford during this troubled time, and take action to preserve the free enterprise that has built our nation from a dream.
Can a free website live in a nation without freedom?
I was just wondering if the "unfair governmental-sponsered competition" that the article references was lifted from the the pages of NAFTA. Does anyone have any further info/links on the PubScience shutdown? I recall public debate over NAFTA's broad authority in such situations, and (in reference to yesterday's article: "leaky abstractions") was thinking that this could be a case in which NAFTA "leaks".
I have to ask (given my Python illiteracy), does Python have built-ins for such an operation? Or is this just "how to implement an old trick" to "get your feet wet" with Python?
If my coffee is working correctly this morning, I'd assert that any language with an XOR-assign could accomplish this feat (with the added restriction that the vars be of the same size, or operations are performed iteratively on byte pointers).
Below is chapter 1 of my new C cookbook:
A ^= B;
B ^= A;
A ^= B;
Short chapter.
Isn't he the king of live tomb excavating adventures? One bust, two busts, how many busts can we handle? Seriously, archealogy really isn't made for live TV. Save the hype for when something is *found*, not *expected*.
What kind of interview question is that? FRIENDSHIP BREAKS ENCAPSULATION, A TENET OF OO DESIGN! Obviously, if your candidate speaks volumes on friendship, than he is a hack who will run rampant through your code and leave spaghetti in his wake.
Seriously, a better question would be, "How would you approach writing a program that does X"
LOL! I also had a mysterious software bug that I eventually proved to be hardware (with great satisfaction ;).
Anyway, I was working on a robotic lid for a Thermocycler (used in wet labs). Thing is, every few hundred iterations through the open/close test cycle would show a dropped command. Communication was I2C written by some third-party hacks, and the boss figured it was the problem. In all honesty, the implementation was pretty crappy, so I poured over every minute detail (small protocol I2C, not much to go wrong). I even gouged out a good portion of the code to put in retries and good failure behaviours. After about a week of reimplementing the server and client end of the bus I decided to go downstairs and get an O-Scope from production. I had to beg for the thing. Finally, when I traced the lines it was all too obvious what was causing the drops. Some engineering bozo placed the I2C lines adjacent to the power lines, and failed to shield the power lines.
The result: 60-cycle induction across the bus (slow compared to I2C, so collision happened rarely, and my failure adjustments were pretty darn good at rectifying them). Anyway, knowing this I was able to tune the code and save the release date, though the designer of the hardware should've known better in the first place and saved me some headaches!
Especially for four days of work
I think that's the problem source for all the bickering in this forum. The purpose of the Jam is to get talented people together to bounce ideas off each other and hopefully come up with some new ideas, not to create saleable games (four days isn't much time to polish the work).
Perhaps the developers could have chosen a different source for their sprites, but I'd have to say from experience that the amount of time in question here is certainly not enough to design sprites from scratch (if you want to code the game at all)! I haven't really looked, so I wonder if anyone is putting their art out for free (as in beer) on the web??? An open-sourced art gallery, anyone? (Sadly, most free art I've seen is worth the price you pay for it)
Anyway, I thought some of these concepts were clever, though I did wonder why so many of them were based on numerous hordes and gods (Must have been the caffiene).
The parent of all of this was certainly in err, but this still isn't a very good experiment. Look at the number of testers that were used. Most tests numbered in the 30s with respect to the number of subjects. While that number may be sufficient for small sample statistical tests, it is not a sufficient sample to test for such a normative value across the human population, such as judging music quality represents. Having achieved a small variance of opinion must not be determined to prove that the sample size was large enough to account for variance in opinion for the greater population, and while these tests are interesting, they are incomplete IMHO.
LOL! That's quite a reward for finding errors in Knuth's brain child. While Knuth professes Computer Science and the French language have changed significantly since vol. 1, the Economics of error-finding have remained the same... What about inflation Prof. Knuth!?
This suggestion should be worth $0.32
LOL, You've got to be kidding me. Exactly who is moderating in here!?
While HTML is here to stay, Flash does have a market, IMHO. Pizzaz may not be appropriate for corporate sites, but for diversions, its not so bad. You're right though, Flash is disappearing from corporate sites, so I agree with you on that end.
.xsd (it does if you rename the file to .xml), though XSD is valid xml syntax. Why would I do this? It makes for a nice documentation resource, and a transform on XSD requires almost no maintenence. I tried to post to the newsgroup, but here at work there is no news server, for security purposes, so alas, I could not.
As for XML, while it may not *replace* HTML, I don't think I shall ever need to hand write HTML (or have a design app write it for me) again. Given the extensibility of XML in defining an object model custom to the needs the business, the advance of schema and transformation technologies, and the push for W3C standard XML support in all web browsers, XML is here to stay, and will maintain a strong presence in corporate sites. Frameworks that take advantage of XML to generate HTML web sites integrate better with other corporate software systems, most prominently databases, if simply for the reason that HTML is clumsy and loosely enforced, whereas XML has a strong definition, can be validated to a schema, can represent a complex DOM, can be parsed efficiently, etc.... A handful of XML initialization files can define an entire site if the framework is shrewdly designed, making the site more extensible and more maintainable than would be if HTML were the only choice. A couple of bioler-plate XSL transformations (+ a few custom) can represent your data in more meaningful and modifiable ways than you can have with rote HTML. Server-side, big players Java and Microsoft both have excellent support for XML, and it is ever-growing.
HTML has stagnated, because it is too sloppy to fix at this point, and object model standards were clobbered by Microsoft. That is why sites feed you 'Minimal-tag-HTML', and in most cases, I'd suspect it has been transformed from XML ala XSLT.
XML + XSD + XSLT + CSS = better than HTML alone.
Completely aside: if anyone who contributes to Mozilla in the XML - XSLT newsgroup, I've noticed that Mozilla doesn't recognize a transformation on an XSD if the extension is
- Enjoyable gameplay is not necessarily dependant on flashy graphics (just as enjoyable movie viewing is not necessarily dependant on flashy graphics - see Hollywood.)
- Multiplayer games on PDAs, cell-phones are somewhat limited by
- cost in phone minutes
- People-on-the-run finding the setup time inconvenient
The tremendous market I see is in multiplayer games of chance, for money. That is to say, let's set up a multiplayer poker game for real stakes (or head-to-head Pong tourney for cash). GAMBLE ON YOUR PDA/PHONE, my friends! All human opponents! Best odds! Get your fix on Route 66 (literally)!Hmmm.. how to authenticate though... sadly, 'wireless security' is an oxymoron, and where there's a bill, there's a way.
Very Brittle is an understatement.
I was working on a project using VB *sigh* a few years ago when I discovered a very peculiar bug. In order to get a form to appear, I was forced to call DoEvents() - TWICE IN A ROW!!!! I guess VB thought I didn't mean it the first time.
The strong arguments made in the Register article are completely lost on AP/CNN.
Hah! That's a real surprise!
- Given the reliance on hardware encryption, Palladium requires everybody to buy a new computer to use it.
- Given that an encryption system that can stand up against attack through time has never been accomplished in history, the MS plan has little chance for truly ensuring "private data".
- Given that the United States government want to be able to look at your data because you might be a terrorist (or just an enemy of the state), "private data" opposes Big Brother, and is therefore not likely to give any *real* privacy at all (unless you just have blind trust in the govenment
;P).
The good news is, I don't think the 'commons' are buying into Palladium, at least not yet. Besides, real paranoids don't use Windoze.I agree with you; I hate cell phones. :)
BTW, It's illegal in the US for telemarketers to call cell phones. If it happens to you, get the company name, and report them to the proper authorities. The offense carries a stiff fine, I believe.
Test smarter, not less. Many of the above posts have shrewdly indicated good method of preventing bugs (an ounce of prevention, anyone?), and below I have some ways you may want to consider in testing your software. Sadly, the poster didn't give a whole lot of information to go on, so this offering is a bit vague, I'm afraid.
At our shop, we invest a good amount of time in developing test modules for all interfaces in the project, almost as much time as it takes to write the modules themselves. Every night, an automated build machine builds and installs the latest version from source control, and initiates a test script that invokes the test driver suite which loads and tests all public interfaces. Every function is tested with expected input versus expected output, and further by sending unexpected input (like that of a malicious user, or failed communication). All exceptions, assertions, and incorrect output is checked as well, as any memory leaks, by the C-runtime debugging utilities, and Bounds Checker will soon be in use as well.
This approach serves 3 purposes:
- It readily finds crashes that human testers may not find, since it checks every public function with varietal input.
- It aids regression testing for modules that have been changed.
- It checks for leaks, which can cause problems that may be evident only after extended execution times (doesn't apply if your language is garbage collected)
Further, by having an automated build every night (that emails everyone on the project, including the project manager, ehhem), developers are careful not to "break the build", and thus pay attention to details before committing their code.This method is only a preliminary test; however, and it cannot find every bug that may or may not exist. All code is audited to ensure it meets coding standards. You'd be surprised how failing to meet standards often evidences a piece of code that was written in haste, and as such, is a good place to looks for bugs. Also, we employ code testers who run the software through use cases (which are sequences of actions determined to be general ways in which users want to use the software). These testers also put the software through non-use cases, in which the actions do not follow expected sequences.
I hate to point out the obvious, but it is important to test software freshly installed on "clean machines", not development machines.
In the end, if it is at all possible, it is nice to have users who are in some way affiliated with the software company to give a "field test" so-to-speak on alpha and beta versions of the software. In any complex piece of software, there will be a chance for hard to find bugs (relative to the developer) to occur. Tolerant users are the best and last resort to finding any obscure bugs before the general public gets their click-happy hands on the software.
Conclusion: design smart, code smart, follow standards, test smart, test everything, and track all bugs (as if that is news to anyone).
PDAs! Yikes, doesn't that open up new avenues for *cheating* !? At least with calculators, a wise instructor can design the test problems so that the calculator is of little actual help, and that conceptual understanding is what is being measured.
With a PDA, you have the risk of the entire class linking up to the nerd who actually worked problems and listened in class.
According to WaSP, modern browsers are a necessity. The problem is, WaSP doesn't have the power the impose such a mandate, and my grandma uses whatever browser came bundled with her machine (how did IE win the browser war?)
IMHO, standards are great, but only if they are, in fact, standards. Thus, everything I write for the web follows the LCD (lowest common denominator) philosophy. Heck, I don't need tricks to put something that looks good on the screen (I'll do the alpha blending during graphics production, not at runtime). I don't like rewriting everything for a new browser (neither do the WaSP gurus), and that is why I'll stick to plain ole' minimal tag set HTML.
HTML is not the problem for me; the problem in getting a site to work properly on any browser comes in when you try to use JavaScript. An standard object model for *JavaScript* is what I really need, and that is just not a reality yet.
Some have pointed out IE's tolerance for mistakes is a problem, and I couldn't agree more. As a development browser, IE is a big mistake, unless you don't care about users of other browsers at all. Thank goodness for Mozilla.
http://slashdot.org/article.pl?sid=02/04/09/124226 &mode=thread&tid=95
Deja Vu
Castanza, you killed my mother.
This is not troll, I am a human and make funny jokes, haha.