Don't visit trusted web sites while visiting untrusted web sites or disable JavaScript.
Once again, for all you web masters out there who cannot code a simple <a href="foo"> without using Javascript:
SOME OF US RUN WITH JAVASCRIPT DISABLED BY DEFAULT, FOR GOOD REASON!
Yes, there are plenty of places where you CANNOT do what you need to do without Javascript - in those cases go ahead and use Javascript.
But for a simple link to another page, or to an image, or to simply DISPLAY you site's content (I'm thinking of bone-headed sites like the International Herald Tribune here who use JS to display otherwise hidden text for their stories), USE HTML DAMNIT! OK, if you want to "enhance" (pronounced "clutter up with needless crap") you site by overriding those behaviors IF Javascript is enabled, knock yourselves out (preferably with a large mallet). BUT MAKE STANDARD HTML WORK AS WELL!
Yes, you may WANT your image to be in its own window, without the standard decorations a browser will add. But if I have JS disabled, make the damn link just spawn a new window and be done with it.
The fact that these guys are using what looks like their kid brother's woodburning kit as a soldering iron (just look at the size of this thing compared to the size of the pad they are working on), the fact that they didn't prepare the coax (tin the leads) BEFORE they put it into place, or the fact that they are blithly ignoring the part 15 regs which DO NOT ALLOW an external antenna to be installed on a device like this.
Oh, let us not forget that the cable they are using is not rated for the Bluetooth frequency range, and will have a pretty significant attenuation at those frequencies, that the connectors they are using will not have a good impedance match at Bluetooth frequencies...
Maxwell's equations of electro-magnetic theory show the speed of light in a medium to be determined by 2 properties of that medium. For vacuum, those two properties are fundimental constants - thus the speed of light is fixed.
Now, if I take a squirt gun with a fixed exit velocity and squirt it at you, the water will be moving slower if I am backing away from you and quicker if I am running at you. That fits with our day-to-day experience.
But for light in a vacuum that does not happen - if I now use a light-gun, you will measure the speed of all three beams of light (me backing away, me standing still relative to you, me running at you) as the same.
And curiously, so will I - I will measure the speed of light leaving my light-gun as the same, no matter what.
Now, the ONLY way you can get both my measurements and yours to agree is if things like length, mass, and time change based upon my motion relative to you - hence the need for the Lorentz transformation.
Then, you get into the "twins paradox" - Take 2 twins. Kick one of them up to nearly the speed of light. Wait till the other one has aged 10 years. Bring the high-speed twin back.
From the stationary twin's perspective, the high speed twin slowed down. From the high speed twin's perspective, the stationary twin (who wasn't stationary from the high speed twin's perspective) slowed down. Yet both cannot be true.
So Einstein reasoned out that the ONLY difference between the twins was who felt the acceleration - that twin would slow down.
But if I lock you in a box, you cannot tell if you are setting on a planet or in free space being accelerated - so gravity must be like acceleration.
"Twisted pair" refers to both conductors being twisted together.
The idea is that the magnetic field (H-field) and electric field (E- field) from the one conductor, where the signal is travelling one direction, will cancel out the H and E fields from the other conductor, where the returning signal is traveling the other way, leaving no net signal at distances "far" from the conductor (where "far" is defined by the signal frequency).
In a power line, you CANNOT twist the two conductors into that kind of close proximity, as the insulator required to keep the power from going ZZAAP is too large and/or costly to deploy.
Furthurmore, one of the assertions of BPL - that by using BPL "every power plug is an Internet plug" is bullshit. The BPL signal will not cross a transformer - the transformer is designed to pass 60 Hz (US - 50 Hz in the UK) ONLY. Therefor, for the signal to pass the transformer there needs to be a device installed that takes the signal from one side, regenerates and amplifies it, and injects it on the other side.
The only "advantage" of BPL is the idea that you can carry the signal along the long haul high tension runs without extra infrastructure costs. However, that is being determined to be BS as well, as they are finding that they have to install signal repeaters every few km to boost the signal.
If the power companies want to get into the Internet business, great! Let them string fiber along the power lines - they will have MUCH more bandwidth than BPL gives them, much more reliability, much less interference to other services, AND they can apportion a section of the fiber for SCADA purposes (monitoring substations, controlling switching, reading your meter, etc. Note - that data would NOT be transiting the Internet, but would be in a seperate time slot or fiber, so it would not present a security risk.)
From Web WordNet 2.0: The noun "stooge" has 2 senses in WordNet.
1. flunky, flunkey, stooge, yes-man -- (a person of unquestioning obedience) 2. butt, goat, laughingstock, stooge -- (a victim of ridicule or pranks)
This jackass is not a "stooge" - he is an ACCOMPLICE. He does not deserve to "share a cell with Martha (Stuart)" in Club Fed, he deserves to be locked into stocks in a public place and to have rotten food items thrown at him. He deserves to be whipped until he shits himself, with the whole incident preserved on the Web and properly catagorized in all web search engines. To quote Hanover Fist: "Hanging's too good for him. Burning's too good for him. He ought to be torn into little bitty pieces AND BURIED ALIVE!"
This little shit knew what he was doing was "wrong" in the eyes of society - he simply has no care for such matters. Yes, in that his arguments are no different than a drug dealer, burgler, or hitman.
In fact, I'd rate a drug dealer over this asshole - a drug dealer is doing "bidness" with people who want his product. I'd sooner legalize drugs than allow this little shit to do what he is doing.
Well, if the front panel has a button for a CD jukebox and your car doesn't have one, you likely have an input for it, but would need an adaptor - check Precision Interface Electronics and see if your stereo is on the list.
Yes, several manufacturers have aux inputs of one form or another. My Sony stereo I had a decade ago had an aux input on the front of the unit. My current stereo (the factory-installed Alpine unit in my Mercury) does not have an aux input per se, but has support for a CD jukebox, and there is an aftermarket aux input box that fakes the head-end unit out into thinking it is a CDDJ - thus giving me tape, in-dash CD, and my OpenNEO35 80G MP3 player.
I agree with you on the FM transmitter and cassette adapter - they bite rocks and suck. The FM units are usually NOT crystal or synthesized and drift all over the place, as well as the built-in limitation of 15kHz due to the way stereo multiplex works, and the cassette adapters have neither good base nor good treble response. I could not believe the difference when I got the CDDJ box installed.
Personally, I'd like to see the high-end car stereo manufactures put in a 3.5mm aux jack on the front, a pair of RCA's on the back, and a Bluetooth receiver - but that is about as likely as seeing a good candidate for president. I've got the hot tea, anybody have an atomic vector plotter?
Back in the day, when computer parts weren't for sale at your local supermarket - back when you had to go to a special store just to be diskettes - ComputerShopper filled a need.
Barely.
It was always a bear to find, say, all ads for tape drives, and to compare the prices of each vendor. It was a PAIN to locate anything special - you spent more time than it was worth to flip through the 8000 pages of ads to find the ones selling what you want.
Now, you go to [Google/Froogle/Yahoo/eBay/...] and type in a quick search, and there you are.
Next you'll tell me that there are still people reading Byte!
First, you confuse "unit testing" with "application testing". You are writing the tests for a *part* of the app, not the whole. So, to use your example, you are writing the tests for parsing a customer's auto-pay entries - not the whole app.
SO:
Your first unit test is a simple "return pass"
You run your test framework and verify everything works.
Commit the changes into the main line branch.
You then change your unit test to "return fail". Run test framework and verify it fails. (NOTE: You do all of this IN YOUR PERSONAL DEVEL BRANCH, not in the mainline code.)
Now, define the first tests for your function - test that it does what is is supposed to do. In this example you would define some simple, correct auto-pay setups and submit them to your module, and confirm the module returns the correct data. At this point, you are now FORCED to give some consideration as to what the inputs, outputs, and API will look like - one of the benefits of this approach.
You now start on the module, creating a stub routine that does nothing.
Run the tests - they should fail as you are not yet "doing what you are supposed to be doing".
Implement the module. If, during this part you discover you have to change the API you also change the tests as needed. Run the tests as you go.
Eventually, you will have a pass - your module is "doing what is is supposed to be doing". Now you add more test data - different valid transactions, and different invalid transactions. You modify the test to pass IF the valid operations pass AND IF the invalid operations are detected and correctly failed.
Run the tests. Watch them fail as your module barfs on the bad data.
Fix the module to deal with the bad data. Run tests. Repeat until tests pass.
Do code review on module. Sally spots a potential problem. Add test case to test. Verify tests fail. Fix problem. Repeat until module passes review.
Merge module and test with mainline code branch and re-run tests.
Now, you have a set of tests for your "auto-pay setup" module. Meanwhile, the others who are implementing the "generate statement", "send bills", and suchlike modules have done the same, so your test framework validates each module. The idea is to limit the scope of failures - you prove each module behaves itself, so the number of possible failures AT THE APP LEVEL is greatly reduced.
Now, George finds a case that causes you module to barf, and writes a bug in the bug tracking system (you *ARE* using a bug tracking system, aren't you?).
You add the bad case to the tests, verify they break, commit change.
You fix the module, and verify the fix. Commit change, mark bug as FIXED.
Your Q/A guys verify that the run before the fix is broken, the run after the fix is OK, and VERIFY the bug, OR they suggest other possible tests that break the system. If so, repeat the last three steps.
Sure, this is no "silver bullet" that will eliminate all bugs. What this DOES do is catch the bugs as quickly as possible, when they affect as little of the project as possible, and VERIFIES that they are indeed fixed and STAY fixed.
You are damn right the problem is built-in to the system.
The scum create an account, and charge a bunch of crap to it from stolen cards. They then extract the money and run.
The people bilked bitch to the credit card companies.
The card companies attempt to reverse the charges.
The poor business who was impersonated gets stuck with the bill. At best, the company can establish its innocence, and the CC company writes the cost off its taxes.
If the *credit card companies* were the ones who had to suffer the costs of fraud, rather than shifting it to the companies or to the taxpayer, then they would be a HELL of a lot more motivated to add stronger authentication to the system.
As it stands now, if somebody is committing massive credit card fraud in the form of lots of small charges, and you try to bring this to the card company's attention, they blow you off because it just isn't worth their time - it is easier to just charge back to the merchants. A friend of mine who works in the order-processing chain for a large company ran into just that - he detected a fraud ring attempting to rack up a lot of charges, he called the card company and said "I'll give these guys to you with a ribbon tied around them - addresses, names, the works." "Not interested - bu-bye!"
The single best rule of comment is "Comment upon the WHY, not the WHAT".
Don't say:
double sum = 0.0;// zero sum
for (i = 0; i < len; ++i)// all samples
{
double signal = buf[i];// get value
sum += signal*signal;// add signal^2 to sum
}
return sqrt(sum/len);
say: // Compute RMS average of signal - // compute the sum of the squares of all values, // then compute the mean (sum/len), then the // root of the sum - hence Root-Mean-Squared
double sum = 0.0;
for (i = 0; i < len; ++i)
{
double signal = buf[i];
sum += signal*signal;
}
return sqrt(sum/len);
In other words, tell me WHY this code added the square of the signal, not THAT it added the square of the signal.
Moreover:
Every directory of the project should have a purpose, and should contain a short README describing the purpose of the code in the directory.
Every file should have a header that describes the purpose of the file.
Every function should have a header describing the purpose of the function, as well as any inputs and outputs (including global, static, and class variables), any exceptions thrown, and any assumptions made.
Blocks of code within a (large) subroutine should have a descriptive block comment describing the overall goal of that block (e.g. "Now we walk the list of conversations and update the call stats").
Comments on a line of code shouldn't be needed normally - the code should speak for itself. Only pretty tricky things ("use a shift and add rather than a multiply as this saves 3 clock cycles") should need a comment at end of line.
If more folks would follow these rules it would be a HELL of a lot easier to follow their code.
NOTE: If you can say it in the code, do so - if you can specify the exceptions to your function via a "throw(int code)" type statement, then do so rather than using a comment.
Remember - the code tells the COMPILER and the programmer what is going on, the comments tell the programmer WHY it is going on.
More importantly, write the tests FIRST. Then write the code, updating the tests for anything that is identified during the coding.
This has several important benefits:
You have to DEFINE what the module is to do so that you can write the tests. Granted, the first pass for the "tests" may simply return "failed" until something is written for the module, but at least you will have a chance to think about what you should be testing.
You actually DO write the tests, rather than blowing them off. If your manager says "Why aren't you working on $blarg?" you can say "I *am* working on $blarg" since the first step is writing the tests.
As you get funtionality working (as demonstrated by the tests passing) you can quickly determine if a later addition to the code breaks the working feature - and fix it while the change is still fresh in your mind (and hopefully BEFORE you commit your changes to the mainline code path (you ARE using a source code control system, aren't you?))
IF my equipment is operating per spec, and IF I am licensed to operate, and IF your equipment is unable to correctly filter out my signal, then YOU are the one who has a problem, not I.
Let's look at the 2 parts in the context of your TV.
This device may not cause harmful interference This says that your TV cannot interfer with anything else - if it does and somebody complains, you have to turn your TV off. No if, ands, or buts. So if your TV is throwing out a spurious emission at 146.52 MHz and thereby is interfering with my ability to talk on my 2 meter radio, upon my informing you of the interference you have to turn your TV off until you get it fixed. If you cannot get it fixed, you cannot use it. Equally, if your TV is interfering with MY TV, and I so inform you, the same thing happens.
OK, now let's look at the second part: this device must accept any interference received, including interference that may cause undesired operation.
Why is this here? OK, let's look at a scenario. Your TV has a badly designed front-end, and is interfered with by my transmissions on 146.52 MHz. You complain to me. I check my equipment, and determine that I am not generating any spurious emissions outside of the 2 meter amateur band. Your TV is at fault here, in that it is not correctly rejecting my signal.
You can *ask* me to stop transmitting. You cannot *order* me to stop transmitting, even though I am interfering with you - my part 97 amateur gear, operating properly in band, trumps your part 15 TV. (in reality, I am going to do everyting I can to help you resolve the problem, but I am not under any legal obligation to do so).
In short, the second part is to clarify where part 15 stands on the totem pole - at the very bottom.
I will beleive ATI will release decent drivers when I load the driver on my machine and it works.
X.org V6.8 has been out for how long now, and in pre-release for how long, and yet, ATI does not have a build of their drivers for it. All the major distros have gone to X.org over XFree86, and yet ATI is not supporting the current release of X.org - this would be like them not supporting DirectX 9 for Windows.
Their drivers do not support the tuner subsystem on their cards, nor is it possible to get the GATOS stuff to work with their drivers. Y'know, the tuners that are one of the big differentiators between the ATI cards and the nVidia cards?
In many ways, the only thing worse than no support is support which hath only one buttocks, to paraphrase the Boomer Bible. If you know you will get NO support, you can at least eliminate them from the list of cards you will get. But half-assed support makes you think that, just perhaps, if you give them another chance, they might just support you enough this time - like victim of spousal abuse giving their partner "one more chance because they really do love me, honest!"
It is truly unfortunate - you have the choice of binary-only support from nVidia, binary support from ATI, or source support for old cards.
Actually, you can hold a chunk of plutonium in your hand with little side effect.
When the plutonium core of the Trinity device was delivered to the site, the commander insisted that the courier open the case containing it - he said something along the lines of "I won't sign for anything unless I have actually seen it".
So, the courier opened the case, the BC took the sphere out, held it briefly (noting the warmth and "feeling of potential"), then returned it and signed for it.
Go read "The Day The Sun Rose Twice" for the details.
You have: grams*c^2 You want: tonnes-tnt
* 19487.022
/ 5.1316205e-05
So 1 gram antimatter + 1 gram matter is about 39 kT of TNT. Hiroshima was about 20 kT, Nagasaki was 13 kT, so one gram antimatter would release just a scosh more than both devices.
So let us use a bit more sensible units than "shuttle fuel tanks".
However, the costs of manufacturing the antimatter, and the size of the containment system, and the fail-null mode of antimatter vs. the fail-safe mode of a nuke (a nuke may leak, but it will not detonate without everything going just right), would lead me to wonder about the utility of an antimatter weapon.
"milometer"? What kind of abuse of the English language is that? The proper term is "odometer". Cannot these Englishmen speak English?
And I invite them to drive through southcentral Kansas in the summer - we need no puny "splatometer" - we need an "thudometer":
June Bug - THUD Grasshopper - THUD Cicada - THUD
And then you find that by some quirk of biochemistry, these bugs seem to be converting plant sap into some form of epoxy resin that resists removal, even with 1600PSI hot water and surfactant.
Slashdot Mirror
Sorry, but I didn't look closely at the cable or connectors. You are correct.
Once again, for all you web masters out there who cannot code a simple <a href="foo"> without using Javascript:
SOME OF US RUN WITH JAVASCRIPT DISABLED BY DEFAULT, FOR GOOD REASON!
Yes, there are plenty of places where you CANNOT do what you need to do without Javascript - in those cases go ahead and use Javascript.
But for a simple link to another page, or to an image, or to simply DISPLAY you site's content (I'm thinking of bone-headed sites like the International Herald Tribune here who use JS to display otherwise hidden text for their stories), USE HTML DAMNIT! OK, if you want to "enhance" (pronounced "clutter up with needless crap") you site by overriding those behaviors IF Javascript is enabled, knock yourselves out (preferably with a large mallet). BUT MAKE STANDARD HTML WORK AS WELL!
Yes, you may WANT your image to be in its own window, without the standard decorations a browser will add. But if I have JS disabled, make the damn link just spawn a new window and be done with it.
OK, I don't know what scares me more:
The fact that these guys are using what looks like their kid brother's woodburning kit as a soldering iron (just look at the size of this thing compared to the size of the pad they are working on), the fact that they didn't prepare the coax (tin the leads) BEFORE they put it into place, or the fact that they are blithly ignoring the part 15 regs which DO NOT ALLOW an external antenna to be installed on a device like this.
Oh, let us not forget that the cable they are using is not rated for the Bluetooth frequency range, and will have a pretty significant attenuation at those frequencies, that the connectors they are using will not have a good impedance match at Bluetooth frequencies...
OK, let's see if I can help.
Maxwell's equations of electro-magnetic theory show the speed of light in a medium to be determined by 2 properties of that medium. For vacuum, those two properties are fundimental constants - thus the speed of light is fixed.
Now, if I take a squirt gun with a fixed exit velocity and squirt it at you, the water will be moving slower if I am backing away from you and quicker if I am running at you. That fits with our day-to-day experience.
But for light in a vacuum that does not happen - if I now use a light-gun, you will measure the speed of all three beams of light (me backing away, me standing still relative to you, me running at you) as the same.
And curiously, so will I - I will measure the speed of light leaving my light-gun as the same, no matter what.
Now, the ONLY way you can get both my measurements and yours to agree is if things like length, mass, and time change based upon my motion relative to you - hence the need for the Lorentz transformation.
Then, you get into the "twins paradox" - Take 2 twins. Kick one of them up to nearly the speed of light. Wait till the other one has aged 10 years. Bring the high-speed twin back.
From the stationary twin's perspective, the high speed twin slowed down. From the high speed twin's perspective, the stationary twin (who wasn't stationary from the high speed twin's perspective) slowed down. Yet both cannot be true.
So Einstein reasoned out that the ONLY difference between the twins was who felt the acceleration - that twin would slow down.
But if I lock you in a box, you cannot tell if you are setting on a planet or in free space being accelerated - so gravity must be like acceleration.
That's GR in a nutshel.
Special, General, or both?
Special's not so bad, but General gets tricky...
"Twisted pair" refers to both conductors being twisted together.
The idea is that the magnetic field (H-field) and electric field (E- field) from the one conductor, where the signal is travelling one direction, will cancel out the H and E fields from the other conductor, where the returning signal is traveling the other way, leaving no net signal at distances "far" from the conductor (where "far" is defined by the signal frequency).
In a power line, you CANNOT twist the two conductors into that kind of close proximity, as the insulator required to keep the power from going ZZAAP is too large and/or costly to deploy.
Furthurmore, one of the assertions of BPL - that by using BPL "every power plug is an Internet plug" is bullshit. The BPL signal will not cross a transformer - the transformer is designed to pass 60 Hz (US - 50 Hz in the UK) ONLY. Therefor, for the signal to pass the transformer there needs to be a device installed that takes the signal from one side, regenerates and amplifies it, and injects it on the other side.
The only "advantage" of BPL is the idea that you can carry the signal along the long haul high tension runs without extra infrastructure costs. However, that is being determined to be BS as well, as they are finding that they have to install signal repeaters every few km to boost the signal.
If the power companies want to get into the Internet business, great! Let them string fiber along the power lines - they will have MUCH more bandwidth than BPL gives them, much more reliability, much less interference to other services, AND they can apportion a section of the fiber for SCADA purposes (monitoring substations, controlling switching, reading your meter, etc. Note - that data would NOT be transiting the Internet, but would be in a seperate time slot or fiber, so it would not present a security risk.)
From Web WordNet 2.0:
The noun "stooge" has 2 senses in WordNet.
1. flunky, flunkey, stooge, yes-man -- (a person of unquestioning obedience)
2. butt, goat, laughingstock, stooge -- (a victim of ridicule or pranks)
This jackass is not a "stooge" - he is an ACCOMPLICE. He does not deserve to "share a cell with Martha (Stuart)" in Club Fed, he deserves to be locked into stocks in a public place and to have rotten food items thrown at him. He deserves to be whipped until he shits himself, with the whole incident preserved on the Web and properly catagorized in all web search engines. To quote Hanover Fist: "Hanging's too good for him. Burning's too good for him. He ought to be torn into little bitty pieces AND BURIED ALIVE!"
This little shit knew what he was doing was "wrong" in the eyes of society - he simply has no care for such matters. Yes, in that his arguments are no different than a drug dealer, burgler, or hitman.
In fact, I'd rate a drug dealer over this asshole - a drug dealer is doing "bidness" with people who want his product. I'd sooner legalize drugs than allow this little shit to do what he is doing.
Well, if the front panel has a button for a CD jukebox and your car doesn't have one, you likely have an input for it, but would need an adaptor - check Precision Interface Electronics and see if your stereo is on the list.
Yes, several manufacturers have aux inputs of one form or another. My Sony stereo I had a decade ago had an aux input on the front of the unit. My current stereo (the factory-installed Alpine unit in my Mercury) does not have an aux input per se, but has support for a CD jukebox, and there is an aftermarket aux input box that fakes the head-end unit out into thinking it is a CDDJ - thus giving me tape, in-dash CD, and my OpenNEO35 80G MP3 player.
I agree with you on the FM transmitter and cassette adapter - they bite rocks and suck. The FM units are usually NOT crystal or synthesized and drift all over the place, as well as the built-in limitation of 15kHz due to the way stereo multiplex works, and the cassette adapters have neither good base nor good treble response. I could not believe the difference when I got the CDDJ box installed.
Personally, I'd like to see the high-end car stereo manufactures put in a 3.5mm aux jack on the front, a pair of RCA's on the back, and a Bluetooth receiver - but that is about as likely as seeing a good candidate for president. I've got the hot tea, anybody have an atomic vector plotter?
You man people still read ComputerShopper?
Back in the day, when computer parts weren't for sale at your local supermarket - back when you had to go to a special store just to be diskettes - ComputerShopper filled a need.
Barely.
It was always a bear to find, say, all ads for tape drives, and to compare the prices of each vendor. It was a PAIN to locate anything special - you spent more time than it was worth to flip through the 8000 pages of ads to find the ones selling what you want.
Now, you go to [Google/Froogle/Yahoo/eBay/...] and type in a quick search, and there you are.
Next you'll tell me that there are still people reading Byte!
"Oh, I'm sorry, but the correct answer is: What is goatse"
Does somebody have a link to the swf that does not go recursive and keep spawning frames within frames?
First, you confuse "unit testing" with "application testing". You are writing the tests for a *part* of the app, not the whole. So, to use your example, you are writing the tests for parsing a customer's auto-pay entries - not the whole app.
SO:
Your first unit test is a simple "return pass"
You run your test framework and verify everything works.
Commit the changes into the main line branch.
You then change your unit test to "return fail". Run test framework and verify it fails. (NOTE: You do all of this IN YOUR PERSONAL DEVEL BRANCH, not in the mainline code.)
Now, define the first tests for your function - test that it does what is is supposed to do. In this example you would define some simple, correct auto-pay setups and submit them to your module, and confirm the module returns the correct data. At this point, you are now FORCED to give some consideration as to what the inputs, outputs, and API will look like - one of the benefits of this approach.
You now start on the module, creating a stub routine that does nothing.
Run the tests - they should fail as you are not yet "doing what you are supposed to be doing".
Implement the module. If, during this part you discover you have to change the API you also change the tests as needed. Run the tests as you go.
Eventually, you will have a pass - your module is "doing what is is supposed to be doing". Now you add more test data - different valid transactions, and different invalid transactions. You modify the test to pass IF the valid operations pass AND IF the invalid operations are detected and correctly failed.
Run the tests. Watch them fail as your module barfs on the bad data.
Fix the module to deal with the bad data. Run tests. Repeat until tests pass.
Do code review on module. Sally spots a potential problem. Add test case to test. Verify tests fail. Fix problem. Repeat until module passes review.
Merge module and test with mainline code branch and re-run tests.
Now, you have a set of tests for your "auto-pay setup" module. Meanwhile, the others who are implementing the "generate statement", "send bills", and suchlike modules have done the same, so your test framework validates each module. The idea is to limit the scope of failures - you prove each module behaves itself, so the number of possible failures AT THE APP LEVEL is greatly reduced.
Now, George finds a case that causes you module to barf, and writes a bug in the bug tracking system (you *ARE* using a bug tracking system, aren't you?).
You add the bad case to the tests, verify they break, commit change.
You fix the module, and verify the fix. Commit change, mark bug as FIXED.
Your Q/A guys verify that the run before the fix is broken, the run after the fix is OK, and VERIFY the bug, OR they suggest other possible tests that break the system. If so, repeat the last three steps.
Sure, this is no "silver bullet" that will eliminate all bugs. What this DOES do is catch the bugs as quickly as possible, when they affect as little of the project as possible, and VERIFIES that they are indeed fixed and STAY fixed.
You are damn right the problem is built-in to the system.
The scum create an account, and charge a bunch of crap to it from stolen cards. They then extract the money and run.
The people bilked bitch to the credit card companies.
The card companies attempt to reverse the charges.
The poor business who was impersonated gets stuck with the bill. At best, the company can establish its innocence, and the CC company writes the cost off its taxes.
If the *credit card companies* were the ones who had to suffer the costs of fraud, rather than shifting it to the companies or to the taxpayer, then they would be a HELL of a lot more motivated to add stronger authentication to the system.
As it stands now, if somebody is committing massive credit card fraud in the form of lots of small charges, and you try to bring this to the card company's attention, they blow you off because it just isn't worth their time - it is easier to just charge back to the merchants. A friend of mine who works in the order-processing chain for a large company ran into just that - he detected a fraud ring attempting to rack up a lot of charges, he called the card company and said "I'll give these guys to you with a ribbon tied around them - addresses, names, the works." "Not interested - bu-bye!"
Don't say:
double sum = 0.0;
for (i = 0; i < len; ++i)
{
double signal = buf[i];
sum += signal*signal;
}
return sqrt(sum/len);
say:
double sum = 0.0;
for (i = 0; i < len; ++i)
{
double signal = buf[i];
sum += signal*signal;
}
return sqrt(sum/len);
In other words, tell me WHY this code added the square of the signal, not THAT it added the square of the signal.
Moreover:
If more folks would follow these rules it would be a HELL of a lot easier to follow their code.
NOTE: If you can say it in the code, do so - if you can specify the exceptions to your function via a "throw(int code)" type statement, then do so rather than using a comment.
Remember - the code tells the COMPILER and the programmer what is going on, the comments tell the programmer WHY it is going on.
This has several important benefits:
No, sorry, but no.
IF my equipment is operating per spec, and
IF I am licensed to operate, and
IF your equipment is unable to correctly filter out my signal, then
YOU are the one who has a problem, not I.
That's the WHOLE POINT of a part 15 device.
You misunderstand the reasoning for the wording.
Let's look at the 2 parts in the context of your TV.
This device may not cause harmful interference
This says that your TV cannot interfer with anything else - if it does and somebody complains, you have to turn your TV off. No if, ands, or buts. So if your TV is throwing out a spurious emission at 146.52 MHz and thereby is interfering with my ability to talk on my 2 meter radio, upon my informing you of the interference you have to turn your TV off until you get it fixed. If you cannot get it fixed, you cannot use it. Equally, if your TV is interfering with MY TV, and I so inform you, the same thing happens.
OK, now let's look at the second part:
this device must accept any interference received, including interference that may cause undesired operation.
Why is this here? OK, let's look at a scenario. Your TV has a badly designed front-end, and is interfered with by my transmissions on 146.52 MHz. You complain to me. I check my equipment, and determine that I am not generating any spurious emissions outside of the 2 meter amateur band. Your TV is at fault here, in that it is not correctly rejecting my signal.
You can *ask* me to stop transmitting. You cannot *order* me to stop transmitting, even though I am interfering with you - my part 97 amateur gear, operating properly in band, trumps your part 15 TV. (in reality, I am going to do everyting I can to help you resolve the problem, but I am not under any legal obligation to do so).
In short, the second part is to clarify where part 15 stands on the totem pole - at the very bottom.
Do they work with V6.8, or just V6.7?
When I tried them, they segfaulted at startup, repeatably.
I will beleive ATI will release decent drivers when I load the driver on my machine and it works.
X.org V6.8 has been out for how long now, and in pre-release for how long, and yet, ATI does not have a build of their drivers for it. All the major distros have gone to X.org over XFree86, and yet ATI is not supporting the current release of X.org - this would be like them not supporting DirectX 9 for Windows.
Their drivers do not support the tuner subsystem on their cards, nor is it possible to get the GATOS stuff to work with their drivers. Y'know, the tuners that are one of the big differentiators between the ATI cards and the nVidia cards?
In many ways, the only thing worse than no support is support which hath only one buttocks, to paraphrase the Boomer Bible. If you know you will get NO support, you can at least eliminate them from the list of cards you will get. But half-assed support makes you think that, just perhaps, if you give them another chance, they might just support you enough this time - like victim of spousal abuse giving their partner "one more chance because they really do love me, honest!"
It is truly unfortunate - you have the choice of binary-only support from nVidia, binary support from ATI, or source support for old cards.
Actually, you can hold a chunk of plutonium in your hand with little side effect.
When the plutonium core of the Trinity device was delivered to the site, the commander insisted that the courier open the case containing it - he said something along the lines of "I won't sign for anything unless I have actually seen it".
So, the courier opened the case, the BC took the sphere out, held it briefly (noting the warmth and "feeling of potential"), then returned it and signed for it.
Go read "The Day The Sun Rose Twice" for the details.
This raises an interesting question: why aren't "units" like "Library of Congress", "VW Bug", and "human hair" included in the "units" program?
Well, I was going to leave that for CleverNickName to say, but...
Containment breach - the containment system fails, the antimatter meets matter, BOOM.
units
1948 units, 71 prefixes, 28 functions
You have: grams*c^2
You want: tonnes-tnt
* 19487.022
/ 5.1316205e-05
So 1 gram antimatter + 1 gram matter is about 39 kT of TNT. Hiroshima was about 20 kT, Nagasaki was 13 kT, so one gram antimatter would release just a scosh more than both devices.
So let us use a bit more sensible units than "shuttle fuel tanks".
However, the costs of manufacturing the antimatter, and the size of the containment system, and the fail-null mode of antimatter vs. the fail-safe mode of a nuke (a nuke may leak, but it will not detonate without everything going just right), would lead me to wonder about the utility of an antimatter weapon.
"milometer"? What kind of abuse of the English language is that? The proper term is "odometer". Cannot these Englishmen speak English?
And I invite them to drive through southcentral Kansas in the summer - we need no puny "splatometer" - we need an "thudometer":
June Bug - THUD
Grasshopper - THUD
Cicada - THUD
And then you find that by some quirk of biochemistry, these bugs seem to be converting plant sap into some form of epoxy resin that resists removal, even with 1600PSI hot water and surfactant.