Here's the rub: people who want to commit suicide are ill. It's like having a serious physical illness that could kill you, only its not physical. Legislating against suicide is tantamount it illegal to have a serious physical illness.
Why do I say they are ill? Because mental health is defined around the ability to function in society. Suicide is about as far as you can get from being a functionality individual, so if you want to commit suicide, then you're ill.
So why not get treatment? Professional help is not always about getting talked out of suicide. Real professionals can offer a variety of biological (i.e. drugs), behavioural and cognitive interventions that treat the cause of the problem, where "talking you out of it" only treats the symptom.
You can only respect someone's decision to commit suicide if you know that the decision has been taken with full understanding of the consequences, and full understanding of the alternatives. Of course if you are ill enough to contemplate suicide, then who can expect you to have the presence of mind to take an educated decision on the matter?
Actually there are several merits to the author-pays model. As many people have already pointed out, the payment is not about the costs of publishing the material and making it available, but to cover the costs of editing and proper academic review.
So the author-pays model is about paying for the stuff you submit to be reviewed to ensure that it is of high enough quality to be disseminated via that channel.
Authors often have a reason that they are publishing research, for example they need to publish a paper as part of an Honours, Masters or Doctoral degree. Given this the author would be paying for his/her research to be vetted by a panel of experts. A benefit to reviewers would be that authors would need to be very careful about the quality of their submissions, otherwise they're wasting their money. i.e. author-pays should improve the signal-to-noise ratio (STN).
Low STN is a big problem for journals. You have thousands of hopefuls submitting papers, and have to sift that down to a few candidates for formal review, then cover the cost of the review. Up the STN by increasing the barrier to entry, and you reduce your costs while maintaining or increasing quality.
A trade-off could be to have an author-pays system, but authors who have already shown competence (i.e. by having a reviewed paper published in a recognised journal) can volunteer to review other papers in their field and thereby reduce or offset the cost of publishing theirs.
I've found prototypes are more useful in a JAD context. They're at least as effective as use cases at gathering requirements for applications that are mostly interactive.
Currently I use specifications because we're working with non-interactive software than integrates with a number of other systems, and needs its processing behaviour to be very precisely understood.
That's a fairly specialised environment, but for more general contexts I have found use cases to be particularly effective. Of course, I could a use case plus the documentation you need to understand it as part of a requirements specification;)
Re:Requirements?
on
QA != Testing
·
· Score: 4, Informative
There are two parts to quality. The second part of the IEEE definition is "The degree to which a system, component, or process meets customer or user needs or expectations".
Although Feldman leaves out the second part (I believe it comes from another standard), he alludes to its importance in his discussion of how stringent QA must be, indicating that software for different purposes will have different quality requirements according to the needs of its users.
Quality Assurance is not possible in the absence of requirements and specifications. Although we (the company I work for) often receive requirements with minimal detail, we have addressed the quality problem by writing a (relatively) detailed specification up front, and presenting it to the customer. Effectively we're saying "this is what you're going to get for your money, okay?". It's just prudent practice, but it gives us a goal and a way to achieve quality (by both definitions).
You can find more on the combining the technical and business approaches to quality in my essay The Quality Gap.
writing clear code is a given and was before this nonsense about self documenting code came about. The problem is comment avoidance.
The essence of self-documenting code is to write in a style that reduces the need for comments. Don't obfuscate your code in the name of efficiency or of proving how damn good you are. Use straightforward control structures and meaningful names, and all of the comments that describe what the code is doing go away, leaving you with high-level descriptions of what a block of code is intended to achieve and the approach that it takes.
I suspect your one of those coders who hates taking the time to update comments.
You suspicion is incorrect. Unless of course you're referred to the/* add 1 to i */ comments, which do (understandable) piss me off.
Also, it may come as a shock but unless a program is poorly written, any code change that does not change an API should have NO effect that is not within a screenful of text from the code being changed.
This is one of those things I hear all the time from juniors. The fact is that the only time this statement is true is when you are rewriting part of a function to make it more clear or more efficient. Both are relatively uncommon activities. Bug fixes or additional functionality, which are far more common, do result in a change in the API (even if it is too subtle to be readily noticed).
Believe it or not a coder should not have to become intimate with your project to change "Initializing Floogenbooper..." to print "Go go gadget Floogenbooper...".
Ah, so the User Interface and/or contents of a log are not part of what you consider an interface? You have chosen to believe than an API is merely a set of calls and their parameters. But it's not. It's also the effect those calls have on supposedly unrelated parts of the system.
Does the log parser know about your change? Have all User Interfaces been updated to ensure you use "Go go gadget" consistently? This is stuff that many programmers don't think about because they've convinced themselves that "black box" programming is the solution; but they forget that there is more going into and coming out of the black box than a C function call.
Thank you for succinctly illustrating why we need licenses for Software Engineers. Let's take a closer look:
Dear god no, mixed case leads to gobs of errors from nothing more than incorrect case.
This is a style issue. Everyone has their own idea of what is (or is not) most readable. What is more important, however, is that the chosen style is applied consistently.
What this also tells me is that you aren't particularly thorough and are prone to making assumptions, which are really bad traits for a developer. You should work on that.
Next is this BS about self-documenting code. Code is not meant to be self documenting.
Perhaps you need to find out what self documenting code is. It is about making code obvious and readable, so that you don't need to *gasp* COMMENT code everywhere. And it does consider notions of scoping and choosing sensible variable names within the context.
Write the most efficient function you can
Write the simplest function you can. It is always the easiest to get right, and the easiest to maintain. If you have a performance issue, chose a better algorithm first, and only then move on to improving code effeciency. Otherwise you end up with a huge and hard-to-maintain code base, that requires lots of *gasp* COMMENTS so that you can understand what's going on, because "efficient code" tends to be less readable.
code is not a spoken language and is a poor medium to use to express messages between people who speak one
Code is in fact an excellent language for communicating accurately at a low level. Spoken language is often poor at this level, but is excellent for conceptual communication. Thus a comment should describe in spoken language the algorithm that is implemented, but the implementation should be (largely) self documenting and easy to follow (assuming you are familiar with the algorithm).
By_using_variable_nms_that_dnt_lk_like_this 40 times in 6 lines of code you will save enough time writing those 6 lines that you can add a nice comment that says # vnameshort is used...
But there is trade-off between the time you take to write your function, and the time it will take many different maintainers in the future to figure out what it does. Trying to remember the meaning of half dozen short variable names while you interpret someone else's code is not a recipe for efficiency.
Meaningful variable names don't have to be long; in fact the best ones are short, accurate and unambiguous.
Believe it or not, I do not want to read your 100,000 lines of source to make one change. I want to be able to look at the main routine and b-line right from there to the portion of the code I need using the commented function calls
This is not surprising. It is what most developers want to do. Dive right in and fiddle. Without knowing what's going on, of course: you have no idea what effect your change is going to have on the other 99,800 lines of code.
To have a choice you have to be educated about the product you are considering, and about the options.
HP, Lexmark, and others have gone out of their way to prevent customers from knowing what they're up to. They don't tell you "this printer will actively detect and prevent the use of third-party refills", they recommend that you use OEM ink to prevent damange to your precious possession. They don't tell you that the "free ink" with the printer looks like a regular refill but is only 1/3 full, or that you will be actively prevented from using the ink after its expiry date even if you would like to choose otherwise.
A lot of cheaper cartridges coming out now aren't marked with an ink volume, and/or the printers don't have estimated ink usage -- making comparison with other products difficult. And I haven't seen an MTBF on any of the low-end printers.
In short I have very little idea what I am buying, only that I can expect to replace it in a few years when it breaks, runs out of ink, or gives me a "Printer too old - buy a new one" error message.
None of which gives me the information necessary to consider a high-end printer instead, since I can't work out the long-term TCO compared to a series of cheapies.
I second the suggestion of "User Interface Design for Programmers". It is a brilliant book that covers most of the suggestions already made here. The book is short and very readable, and succinctly gets across the good and bad of UIs, plus how to go about testing usability effectively.
It would... but then the site and the advertiser would have to take this into consideration into terms of click fees, etc, so that it is beneficial to both parties.
I have to add 2c to this, because its 10% truth and 90% bullshit.
You need to understand the jobs of the people you are managing, and be able to know when they are talking technical bullshit to serve their own agendas.
Knowing how to do their jobs, as in being able to do it in their stead, is not desirable.
It leads to all sorts of political problems when you start asking "why don't you use X approach instead of the Y you are proposing?" Then they spend time dredging up and explaining the background that you weren't fully informed about (because it is, after all, their job), and justifying why they took the technical decisions that they did, and were theirs to take (because it is, after all, their job).
This is a common problem with managers that have a strong technical background. After a short time (few months to a year) they are out of touch with the day to day realities of a specific project, but they still try to bring themselves down to the technical level in managing the project.
The worst part of it is when they make time estimates based on mistaken understandings of the requirements, skills, or implementation issues (especially the reusability of existing technology) -- often such a manager will believe unequivocably that they are right on the basis of their past technical experience.
Yes, I'm speaking from experience. I've dealt with two such issues and managers in the past week alone. I am in a senior technical position and have tertiary management studies behind me.
The hallmark of a good project manager is the ability to let the technical lead provide the technical detail and the time estimates for technical activities, and to know when you are being bullshitted. Then you make sure that progress is being made, but leave the details to the people best qualified to deal with them.
Advertising is a love/hate relationship. Its irritating to get the adverts in the middle of our content, but on the other hand it funds the content provider, meaning that we get content (or get more content, or get better content).
I haven't seen advertising in RSS, but I've been expecting it for some time. The problem in my mind is how it is achieved. In my opinion, there should be no way to place image links or automatically downloaded content into an RSS feed (unless they are merged on the server side, i.e. the client must never get anything except the RSS file).
If you could encode image data inline in an RSS file, I think that would be the ideal delivery system. Specifically images -- nothing executable! Sure, the client software can be updated to not show advertising, but will that happen? The image is part of the feed, you can't get one and not the other (as you do with web sites), so you don't save bandwidth by not displaying the adverts. They're simply there, and inert (they don't intefere with you reading).
A delivery system like this would be good for consumers and advertisers, so it's a good thing IMHO.
Hmm, I don't know who you work for, but I suggest hiring someone with a Clue.
Banks, by and large, do not use asymmetric cryptography like RSA to secure their transactions. The standard for retail and wholesale banking environments is Triple DES, and it's not likely to change for some time, since they've only just finished moving there.
Keys are distributed by loading them into secure, tamper-responsive devices in a trusted environment where no sniffing can occur; then the devices are sent to where they are needed. Key derivation and exchange protocols ensure that these initial keys are minimally used and difficult to compromise, and that limited amounts of data are protected by each session key.
The whole point of quantum key distribution is that you can transfer a key in a manner that is impossible to compromise without the sender and/or intended recipient knowing. From the article: "any interloper tapping into the stream of photons will alter them in a way that is detectable to the sender and the receiver".
So A randomly generates a key K using normal cryptographic techniques, and sends it to B over a "quantum channel". If E or M attempt to listen in or modify the channel, they will necessarily destroy the data and B will not receive what A sent (which is also why you cannot use amplifiers or repeaters). Moreover, since A and B also communicate via a regular electronic network, they are both aware of the attack, and will not use key K.
The end result is that A can send a random key K to B, with perfect knowledge that B and only B is the recipient of K. No need for asymmetric crypto -- everything can proceed using symmetric key cryptography.
Problem is, quantum computers will likely be able to break strong symmetric keys (128 bits plus) long before they can factor RSA keys; but that's still under debate.
I have to admit that the name and colour scheme put me off, but on the other hand langoustines flambed in sambuka is a really great dish -- you should try it sometime!
The answer is, as always, to take a holistic view. Graduates with no experience often have just enough knowledge to make them dangerous and belligerent. Long-time developers with no formal training sometimes end up egotistical, inflexible, and lacking the skills necessary to move from a development mindset to an engineering mindset. What you need is a degreed professional with experience.
And you may want to read goto considered harmful; you'll find out that, in many cases, it's not.
Not the same as a jail, but in the Windows world it may be useful to check out Microsoft Virtual Server.
VS is a little like Bochs / VMWare in that is virtualises several independent systems on top of one hardware platform; but it is designed specifically for a server environment in which you want to have applications running "on their own server" without having extra hardware.
You can establish a virtual network between the servers, or allow them to connect to a real network. A packet filter on one of the virtual servers will allow you to use a filtered virtual network that restricts communication on a simple source-destination port basis.
Yes, but did you check the Microsoft Baseline Security Analyzer? I've had it report missing critical updates that Windows Update never bothered to mention
Interesting -- I hadn't heard this before. Rather disturbing;/
Actually yes, I use MBSA rather than Windows Update to stay up to date. In fact the problem was that I got nailed by something new, and Spybot had an update within a week that detected and removed it.
Dude. The other day, a porn site popped up on my computer. Just popped up ; I didn't click anything. I ran Norton Anti-virus. I ran AVG. I ran ad-aware and spybot. I checked Windows update, I rebooted, I swore. Everything told me my computer was fine. Clearly it is, and I am mistaken.
Slashdot Mirror
Here's the rub: people who want to commit suicide are ill. It's like having a serious physical illness that could kill you, only its not physical. Legislating against suicide is tantamount it illegal to have a serious physical illness.
Why do I say they are ill? Because mental health is defined around the ability to function in society. Suicide is about as far as you can get from being a functionality individual, so if you want to commit suicide, then you're ill.
So why not get treatment? Professional help is not always about getting talked out of suicide. Real professionals can offer a variety of biological (i.e. drugs), behavioural and cognitive interventions that treat the cause of the problem, where "talking you out of it" only treats the symptom.
You can only respect someone's decision to commit suicide if you know that the decision has been taken with full understanding of the consequences, and full understanding of the alternatives. Of course if you are ill enough to contemplate suicide, then who can expect you to have the presence of mind to take an educated decision on the matter?
Actually there are several merits to the author-pays model. As many people have already pointed out, the payment is not about the costs of publishing the material and making it available, but to cover the costs of editing and proper academic review.
So the author-pays model is about paying for the stuff you submit to be reviewed to ensure that it is of high enough quality to be disseminated via that channel.
Authors often have a reason that they are publishing research, for example they need to publish a paper as part of an Honours, Masters or Doctoral degree. Given this the author would be paying for his/her research to be vetted by a panel of experts. A benefit to reviewers would be that authors would need to be very careful about the quality of their submissions, otherwise they're wasting their money. i.e. author-pays should improve the signal-to-noise ratio (STN).
Low STN is a big problem for journals. You have thousands of hopefuls submitting papers, and have to sift that down to a few candidates for formal review, then cover the cost of the review. Up the STN by increasing the barrier to entry, and you reduce your costs while maintaining or increasing quality.
A trade-off could be to have an author-pays system, but authors who have already shown competence (i.e. by having a reviewed paper published in a recognised journal) can volunteer to review other papers in their field and thereby reduce or offset the cost of publishing theirs.
I've found prototypes are more useful in a JAD context. They're at least as effective as use cases at gathering requirements for applications that are mostly interactive.
Currently I use specifications because we're working with non-interactive software than integrates with a number of other systems, and needs its processing behaviour to be very precisely understood.
That's a fairly specialised environment, but for more general contexts I have found use cases to be particularly effective. Of course, I could a use case plus the documentation you need to understand it as part of a requirements specification ;)
There are two parts to quality. The second part of the IEEE definition is "The degree to which a system, component, or process meets customer or user needs or expectations".
Although Feldman leaves out the second part (I believe it comes from another standard), he alludes to its importance in his discussion of how stringent QA must be, indicating that software for different purposes will have different quality requirements according to the needs of its users.
Quality Assurance is not possible in the absence of requirements and specifications. Although we (the company I work for) often receive requirements with minimal detail, we have addressed the quality problem by writing a (relatively) detailed specification up front, and presenting it to the customer. Effectively we're saying "this is what you're going to get for your money, okay?". It's just prudent practice, but it gives us a goal and a way to achieve quality (by both definitions).
You can find more on the combining the technical and business approaches to quality in my essay The Quality Gap.
The essence of self-documenting code is to write in a style that reduces the need for comments. Don't obfuscate your code in the name of efficiency or of proving how damn good you are. Use straightforward control structures and meaningful names, and all of the comments that describe what the code is doing go away, leaving you with high-level descriptions of what a block of code is intended to achieve and the approach that it takes.
You suspicion is incorrect. Unless of course you're referred to the /* add 1 to i */ comments, which do (understandable) piss me off.
This is one of those things I hear all the time from juniors. The fact is that the only time this statement is true is when you are rewriting part of a function to make it more clear or more efficient. Both are relatively uncommon activities. Bug fixes or additional functionality, which are far more common, do result in a change in the API (even if it is too subtle to be readily noticed).
Ah, so the User Interface and/or contents of a log are not part of what you consider an interface? You have chosen to believe than an API is merely a set of calls and their parameters. But it's not. It's also the effect those calls have on supposedly unrelated parts of the system.
Does the log parser know about your change? Have all User Interfaces been updated to ensure you use "Go go gadget" consistently? This is stuff that many programmers don't think about because they've convinced themselves that "black box" programming is the solution; but they forget that there is more going into and coming out of the black box than a C function call.
That raises an interesting thought. Has anyone tried to combine source code with a Wiki?
Surely it would be more readable to have STR_EQ, STR_GT and STR_LT macros?
Thank you for succinctly illustrating why we need licenses for Software Engineers. Let's take a closer look:
This is a style issue. Everyone has their own idea of what is (or is not) most readable. What is more important, however, is that the chosen style is applied consistently.
What this also tells me is that you aren't particularly thorough and are prone to making assumptions, which are really bad traits for a developer. You should work on that.
Perhaps you need to find out what self documenting code is. It is about making code obvious and readable, so that you don't need to *gasp* COMMENT code everywhere. And it does consider notions of scoping and choosing sensible variable names within the context.
Write the simplest function you can. It is always the easiest to get right, and the easiest to maintain. If you have a performance issue, chose a better algorithm first, and only then move on to improving code effeciency. Otherwise you end up with a huge and hard-to-maintain code base, that requires lots of *gasp* COMMENTS so that you can understand what's going on, because "efficient code" tends to be less readable.
Code is in fact an excellent language for communicating accurately at a low level. Spoken language is often poor at this level, but is excellent for conceptual communication. Thus a comment should describe in spoken language the algorithm that is implemented, but the implementation should be (largely) self documenting and easy to follow (assuming you are familiar with the algorithm).
But there is trade-off between the time you take to write your function, and the time it will take many different maintainers in the future to figure out what it does. Trying to remember the meaning of half dozen short variable names while you interpret someone else's code is not a recipe for efficiency.
Meaningful variable names don't have to be long; in fact the best ones are short, accurate and unambiguous.
This is not surprising. It is what most developers want to do. Dive right in and fiddle. Without knowing what's going on, of course: you have no idea what effect your change is going to have on the other 99,800 lines of code.
To have a choice you have to be educated about the product you are considering, and about the options.
HP, Lexmark, and others have gone out of their way to prevent customers from knowing what they're up to. They don't tell you "this printer will actively detect and prevent the use of third-party refills", they recommend that you use OEM ink to prevent damange to your precious possession. They don't tell you that the "free ink" with the printer looks like a regular refill but is only 1/3 full, or that you will be actively prevented from using the ink after its expiry date even if you would like to choose otherwise.
A lot of cheaper cartridges coming out now aren't marked with an ink volume, and/or the printers don't have estimated ink usage -- making comparison with other products difficult. And I haven't seen an MTBF on any of the low-end printers.
In short I have very little idea what I am buying, only that I can expect to replace it in a few years when it breaks, runs out of ink, or gives me a "Printer too old - buy a new one" error message.
None of which gives me the information necessary to consider a high-end printer instead, since I can't work out the long-term TCO compared to a series of cheapies.
I second the suggestion of "User Interface Design for Programmers". It is a brilliant book that covers most of the suggestions already made here. The book is short and very readable, and succinctly gets across the good and bad of UIs, plus how to go about testing usability effectively.
Take a look at the alternatives to PayPal. There is also e-gold.
Take a look at the alternatives to PayPal. There is also e-gold.
It would ... but then the site and the advertiser would have to take this into consideration into terms of click fees, etc, so that it is beneficial to both parties.
I have to add 2c to this, because its 10% truth and 90% bullshit.
You need to understand the jobs of the people you are managing, and be able to know when they are talking technical bullshit to serve their own agendas.
Knowing how to do their jobs, as in being able to do it in their stead, is not desirable.
It leads to all sorts of political problems when you start asking "why don't you use X approach instead of the Y you are proposing?" Then they spend time dredging up and explaining the background that you weren't fully informed about (because it is, after all, their job), and justifying why they took the technical decisions that they did, and were theirs to take (because it is, after all, their job).
This is a common problem with managers that have a strong technical background. After a short time (few months to a year) they are out of touch with the day to day realities of a specific project, but they still try to bring themselves down to the technical level in managing the project.
The worst part of it is when they make time estimates based on mistaken understandings of the requirements, skills, or implementation issues (especially the reusability of existing technology) -- often such a manager will believe unequivocably that they are right on the basis of their past technical experience.
Yes, I'm speaking from experience. I've dealt with two such issues and managers in the past week alone. I am in a senior technical position and have tertiary management studies behind me.
The hallmark of a good project manager is the ability to let the technical lead provide the technical detail and the time estimates for technical activities, and to know when you are being bullshitted. Then you make sure that progress is being made, but leave the details to the people best qualified to deal with them.
Advertising is a love/hate relationship. Its irritating to get the adverts in the middle of our content, but on the other hand it funds the content provider, meaning that we get content (or get more content, or get better content).
I haven't seen advertising in RSS, but I've been expecting it for some time. The problem in my mind is how it is achieved. In my opinion, there should be no way to place image links or automatically downloaded content into an RSS feed (unless they are merged on the server side, i.e. the client must never get anything except the RSS file).
If you could encode image data inline in an RSS file, I think that would be the ideal delivery system. Specifically images -- nothing executable! Sure, the client software can be updated to not show advertising, but will that happen? The image is part of the feed, you can't get one and not the other (as you do with web sites), so you don't save bandwidth by not displaying the adverts. They're simply there, and inert (they don't intefere with you reading).
A delivery system like this would be good for consumers and advertisers, so it's a good thing IMHO.
Hmm, I don't know who you work for, but I suggest hiring someone with a Clue.
Banks, by and large, do not use asymmetric cryptography like RSA to secure their transactions. The standard for retail and wholesale banking environments is Triple DES, and it's not likely to change for some time, since they've only just finished moving there.
Keys are distributed by loading them into secure, tamper-responsive devices in a trusted environment where no sniffing can occur; then the devices are sent to where they are needed. Key derivation and exchange protocols ensure that these initial keys are minimally used and difficult to compromise, and that limited amounts of data are protected by each session key.
The whole point of quantum key distribution is that you can transfer a key in a manner that is impossible to compromise without the sender and/or intended recipient knowing. From the article: "any interloper tapping into the stream of photons will alter them in a way that is detectable to the sender and the receiver".
So A randomly generates a key K using normal cryptographic techniques, and sends it to B over a "quantum channel". If E or M attempt to listen in or modify the channel, they will necessarily destroy the data and B will not receive what A sent (which is also why you cannot use amplifiers or repeaters). Moreover, since A and B also communicate via a regular electronic network, they are both aware of the attack, and will not use key K.
The end result is that A can send a random key K to B, with perfect knowledge that B and only B is the recipient of K. No need for asymmetric crypto -- everything can proceed using symmetric key cryptography.
Problem is, quantum computers will likely be able to break strong symmetric keys (128 bits plus) long before they can factor RSA keys; but that's still under debate.
I have to admit that the name and colour scheme put me off, but on the other hand langoustines flambed in sambuka is a really great dish -- you should try it sometime!
Kant's "categorical imperative". Ask yourself "what if everyone did this" before taking an action.
Seriously, some of us don't have Paypal accounts, and can't get them. Paypal isn't available in all countries. It sucks. Any suggestions?
The answer is, as always, to take a holistic view. Graduates with no experience often have just enough knowledge to make them dangerous and belligerent. Long-time developers with no formal training sometimes end up egotistical, inflexible, and lacking the skills necessary to move from a development mindset to an engineering mindset. What you need is a degreed professional with experience.
And you may want to read goto considered harmful; you'll find out that, in many cases, it's not.
Password Safe is your friend.
Check out the i-Name initiative at Identity Commons. It's standards-backed by XDI.
Not the same as a jail, but in the Windows world it may be useful to check out Microsoft Virtual Server.
VS is a little like Bochs / VMWare in that is virtualises several independent systems on top of one hardware platform; but it is designed specifically for a server environment in which you want to have applications running "on their own server" without having extra hardware.
You can establish a virtual network between the servers, or allow them to connect to a real network. A packet filter on one of the virtual servers will allow you to use a filtered virtual network that restricts communication on a simple source-destination port basis.
Interesting -- I hadn't heard this before. Rather disturbing ;/
Actually yes, I use MBSA rather than Windows Update to stay up to date. In fact the problem was that I got nailed by something new, and Spybot had an update within a week that detected and removed it.
Dude. The other day, a porn site popped up on my computer. Just popped up ; I didn't click anything. I ran Norton Anti-virus. I ran AVG. I ran ad-aware and spybot. I checked Windows update, I rebooted, I swore. Everything told me my computer was fine. Clearly it is, and I am mistaken.