Yep! Tell me about it. One of my domains is a simple dictionary word. I have it set so that all email, whatever the recipient address, comes directly to me.
This was swell until some dolts made things like wpoison, which put up spambot bait pages with randomly generated email addresses made up from dictionary words.
Yesterday, I got 149 spams thanks to the not-clever-enough efforts of anti-spam activists. Thanks, guys!
A few years ago, long after my primary address started getting a fair bit of spam, I started using tagged addresses so that I could see where leakage is happening.
Much of my spam still goes to my primary address, which is still up in many places on the web. But a substantial portion now goes to tagged addresses. I haven't run any stats, but my impression is that web-harvested addresses are the biggest source, followed closely by Usenet news posts. A vigorous runner-up is addresses taken from WHOIS records.
Occasionally I also find that a vendor has sold my address improperly, but that's pretty rare.
I'd be happier if Spamhaus was doing this debate. They run things the right way.
Amen. Having read a bunch of the Spamcop code, I can't imagine that its author will be able to make clear, coherent arguments against a professional smooth talker.
But I will also say that math and science are completely useless to a LOT of people who could not care less about it, and in fact, it's OKAY that they don't care. Very few things in this world require science or high-level math past arithmetic.
Bzzzt! Public schools should, among other things, turn out competent voters. It's impossible to be a competent voter these days without some reasonable understanding of statistics, economics, and the scientific method, along with some basic grasp on some funamentals of science.
Reading and writing are infinitely more important, because they underpin everything, including critical thinking.
I think you can learn critical thinking in a lot of ways. Some of the sharpest critical thinkers I know are not literary types but practical people, like small business owners or automotive mechanics. You certainly haven't made the case that writing is infinitely superior for learning cricial thinking.
If you wanted to pay Bowie for some service he performed, how would you go about doing it?
If I worked for the Recording Industry Association of America? Then gosh, I would call up the record companies that are members and funders of my organization and say, "Hi, Vigin? It's Bob at RIAA. I need to get ahold of David Bowie. Yeah, he's under B. Sure, I'll wait."
I'm guessing that since they do millions of dollars worth of business with him, they'll have some idea of how to get ahold of him.
This might not always be easy to do and might be time consuming per artist.
Did you note the part about $50 million? If they put that in a regular bank account, they can get $1m per year in interest. So it's not like they couldn't find the funds to hire a clerk to look into this. Their, "Gosh, honey, look at this $50 million I found under the couch cusions," line is not particularly plausible.
What we REALLY need is for some court ruling to take all those fucking provisions, and declare them illegal.
No, what we really need is to restructure things so that artists can get good distribution without signing a contract with companies like this. Even if you get laws to declare certain provisions illegal, record companies will still have all the power, so they'll just find new, different ways to screw the artists.
And if I sue a giant company and do my own legal work, and lose, I could end up costing them lots of money whilst I only accrue little legal fees. How much would they get from me? Especially if the case is a frivolous one?
If your point is that my suggestion isn't perfect, I already said that, but thanks for helping clarify the details. If your point is that this is enough to make it workable, I'm dubious; I can think of several easy remedies for this, and I'd bet you can, too.
This statement says nothing about them not writting a test, it says if you see code you don't understand.
Read the rest of my post, not just that one sentence. I'm talking about having complete unit test coverage for a code base. If you have that, you can indeed safely delete code you think to be useless.
the case of a rewrite that fixes a security hole, it's possible but unlikely the test would be an exploit,
It's perfectly likely if you write it that way. If you don't test it, how would you know if you've fixed it? That's the basic theory behind all test-driven development: You write the test, then you make it pass. You write no code unless you have a test that requires it. This goes for both the initial coding and for bug fixes.
It doesn't guarantee that your code is perfect, of course; it's still possible to have bugs. But it does reduce the odds drasically. For example, two years ago we launched a web site with about six man-months of development. Since then there have been two substantial upgrades, and in all that time we've had two valid reported bugs, neither of which was in the main code base. (One was in a server config file; the other was a malformed HTML template.)
Now that I'm skilled at test-first development, I spend an average of 5 minutes a week in the debugger, and I never work late. It's great! I recommend it to everybody. For a good introduction, check out the recent book Test-Driven Development: By Example.
Because a loser pays system would prevent a small company from ever filing suit against a big evil company. The costs of losing would be exponentially larger if they had to cover the evil corp's lawyers too....and being in the right hand having a solid case never guarantees victory.
Then you make it so that you only have to pay them for legal fees up to the amount you incurred. That still wouldn't level the playing field completely, as the giant company could still outspend you. But it's better than the current system.
hmm ok, but what if the reason you don't know what it was, is because it was a fix for a security hole you personally don't even know exists. And thus you delete it, reintroduce the security hole (because there was no visible "breaking", or because there was and you rewrote the same flawed code as before).
Then the person who put the code in without adding a unit test first failed to do their job properly. As important as this is for regular code, it's doubly so for a bug fix; how could they possibly know the bug was better unless they tested it?
On the other hand, the larger the team, the more structure is required; you don't want one person breaking what another person took four weeks to complete.
Well, more structure is one option. Or you could just write self-defending code. A good unit test suite combined with a Continuous Integration tool means that if somebody breaks something, they'll get an email a few minutes later.
On my last few projects, we've ended up with about a 50/50 ratio between test code and production code. You'd think that it would slow things down, but it really makes development faster. I spend about ten minutes a week using the debugger, and very little time wondering what something does.
On the rare occasions when I can't figure out what some chunk of code does, I'll just comment it out and run the tests. If nothing breaks, then I delete it and move on. And if something does break, then I delete it and write something clearer in its place. It's very freeing!
Sure, I've tried instituting "processes" and management's alwasy keen on the idea. But when push comes to shove, poof.
Then institute a process that works with their desire to change things, rather than against it. All of the agile processes, especially Extreme Programming, are designed to embrace change, rather than resisting it.
For developers, it's much more fun. With a traditional spec-driven process, the developer's job is to say no. With an agile process, you get to say yes. Or, more accurately, you get to say, "Yes, but pushing that feature to the top means you'll see other features later." It makes scope control their problem, rather than yours.
The only perfect language for software specs is an unambiguated, testable, logical language.
Yes! So write your specs in code. Make automated tests for your features in parallel with development. And while you're at it, use test-driven development and build unit tests as you go.
In the business world, you are going to have to come up with a budget for your software projects. A project whose scope or length is not defined does not lend itself well to budget forecasting.
Have you looked at the stats on how many software projects actually come in on time and on budget?
As a profession, we'd be better off being honest about the fact. But it doesn't fit tidily into management spreadsheets, so an awful lot of people just make up numbers. Or worse, they are browbeaten into making the estimate match what the businesspeople want to hear.
That's not to say you can't take an initial stab at the budget. But good development is essentially exploratory; it's a rare product that is exactly like the initial spec, and those products generally suck. Better to get an initial budget and then tune your process so you can stop development when you run out of money.
The best trick I've ever seen for setting project goals is to sit developers down with business users or the end users of the product and have them observe work in action. This understanding can go a long way when a developer is back in the 'cube' for long hours of coding. Domain knowledge is critical to a developer. Otherwise you end up with some trully epic program that bears little to no pracitcal value.
There's an even better trick: put your development team in a shared workspace. Then make a domain expert the product manager and put them in the same room, so that if developers have questions they just have to look up and raise their voice a bit.
It's fantastic. The closest we get to specs is whiteboard sketches and the occasional UI mockup. And that's all we need. The developers love it, because there's no guesswork involved. And the product manager loves it because he gets exactly what he wants without having to write phone-book-sized spec documents.
On the topic of knowing the domain, I also strongly recommend the book Domain-Driven Design. It's a brilliant book on how to base your OO model on the thing that is least likely to change: the business domain.
I mean really, you're making a promise to spend your life with someone and they basically make a joke of it. Why would you do that? It's supposed to be a solem occasion.
Supposed to be solemn? Sez who? When you get married, you're welcome to have whatever wedding you want, of course. But I think it's more important that weddings be serious and meaningful to the participants. Serious doesn't have to mean traditional, boring, or solemn.
A friend of mine got married a few years back. He is a delightful, creative freak, as are many of his friends. A traditional, solemn wedding would have made him and his friends miserable. Why would they dedicate their lives to making interesting art and causing lively trouble, only to pretend otherwise on their wedding day?
Answer: they wouldn't. As with everything else they do, they took traditional answers and shook them up. They had a wedding that was serious, heartfelt, and quirky, filled with love and laughter. It might have been their wedding but it was also their wedding.
Google never writes to the filesystem -- it's all in memory and temporary. They only use the disk to boot the system.
For their production service, I understand that they keep it all in memory. But it's hardly temporary.
Hardly anyone is like Google.
For now. Google was one of the first companies to take advantage of the fact that RAM and procesing power have become ridiculously cheap. SQL databases arose in an era when 32k was a fair bit of RAM, and where a business computer was one or more refrigerator-sized units kept in a sacred temple.
Now computers are cheap and disposable. I can fill a rack with cheap 1Us and get processing power that Sun can't match at 10 times the price. The only trick is to write your apps in such a way that you can tolerate hardware failures. That's a little hard, but it paid off handsomely for Google. Others will learn this trick.
You can bet they'll be using RAID (etc) for the GMail service.
You'd lose that bet. They already have built their own distributed network filesystem, GFS, that holds at least hundreds of terabytes. It has performance and reliability levels well above any RAID installation I've ever heard of, and it uses cheap commodity hardware to do it. I'd bet that GMail will be built on top of a variant of GFS or some other in-house technology.
If you actually generate a kind of good publicity for a company that sells a high margine product, like oh soft drinks or post-its, they'll likely go a little farther.
I never have and never will film a movie with a camcorder. I do sneak in food and drinks all the time though. I sure hope I can't get a year in jail for that.
You realize that criminalizing one makes as much sense as the other, right?
In both cases, somebody (studio, theater) does something (makes, shows a movie) with a particular plan about how to make money from it. Then somebody else finds a way to get the value without coughing up like the producer expected.
Videotaping a movie happens to be illegal, while bringing in your own drink is only against the rules. But that's only because the MPAA has more money to lobby. They're both equally wrong (or right, depending on your choice of moral frameworks).
Good for you. And I'm sure you'd welcome a system hardcoded to automatically fast forward over stuff that someone else found boring.
I already do. That's the standard DVD edit. The stuff they only found marginally boring is put on the DVD as "extra scenes". The stuff that they thought really boring never even made it on the DVD.
This is censorship. It is censorship because by using the machine you are not deciding what you want to see and hear, the machine is doing that for you.
Wrong. By using the machine, I'm choosing to let another human edit the movies. Of course, by choosing to watch any movie, I'm letting another human edit the movie; your average movie shoots ten times as much film as they use, and documentaries may shoot eighty times as much film.
Personally, I don't read many blogs; I instead let a human editor pick the good stuff for me and put it in a magazine. Is that censorship? If it is, then we need another word for the really sinister thing where the government paternalistically tells me what I can and cannot see.
Slashdot Mirror
Yep! Tell me about it. One of my domains is a simple dictionary word. I have it set so that all email, whatever the recipient address, comes directly to me.
This was swell until some dolts made things like wpoison, which put up spambot bait pages with randomly generated email addresses made up from dictionary words.
Yesterday, I got 149 spams thanks to the not-clever-enough efforts of anti-spam activists. Thanks, guys!
A few years ago, long after my primary address started getting a fair bit of spam, I started using tagged addresses so that I could see where leakage is happening.
Much of my spam still goes to my primary address, which is still up in many places on the web. But a substantial portion now goes to tagged addresses. I haven't run any stats, but my impression is that web-harvested addresses are the biggest source, followed closely by Usenet news posts. A vigorous runner-up is addresses taken from WHOIS records.
Occasionally I also find that a vendor has sold my address improperly, but that's pretty rare.
From the jargon file entry for field circus:
Q: How can you recognize a field circus engineer with a flat tire?
A: He's changing one tire at a time to see which one is flat.
Q: How can you recognize a field circus engineer who is out of gas?
A: He's changing one tire at a time to see which one is flat.
Q: How can you tell it's your field circus engineer?
A: The spare is flat, too.
I'd be happier if Spamhaus was doing this debate. They run things the right way.
Amen. Having read a bunch of the Spamcop code, I can't imagine that its author will be able to make clear, coherent arguments against a professional smooth talker.
I can't understand why people are saying that it allows any type of activity that was previously not allowed.
Perhaps because it overrode state antispam laws, which were more strict?
couldn't understand that they cannot order a medium in a 4 size index
S, M, L, XL
But I will also say that math and science are completely useless to a LOT of people who could not care less about it, and in fact, it's OKAY that they don't care. Very few things in this world require science or high-level math past arithmetic.
Bzzzt! Public schools should, among other things, turn out competent voters. It's impossible to be a competent voter these days without some reasonable understanding of statistics, economics, and the scientific method, along with some basic grasp on some funamentals of science.
Reading and writing are infinitely more important, because they underpin everything, including critical thinking.
I think you can learn critical thinking in a lot of ways. Some of the sharpest critical thinkers I know are not literary types but practical people, like small business owners or automotive mechanics. You certainly haven't made the case that writing is infinitely superior for learning cricial thinking.
If you wanted to pay Bowie for some service he performed, how would you go about doing it?
If I worked for the Recording Industry Association of America? Then gosh, I would call up the record companies that are members and funders of my organization and say, "Hi, Vigin? It's Bob at RIAA. I need to get ahold of David Bowie. Yeah, he's under B. Sure, I'll wait."
I'm guessing that since they do millions of dollars worth of business with him, they'll have some idea of how to get ahold of him.
This might not always be easy to do and might be time consuming per artist.
Did you note the part about $50 million? If they put that in a regular bank account, they can get $1m per year in interest. So it's not like they couldn't find the funds to hire a clerk to look into this. Their, "Gosh, honey, look at this $50 million I found under the couch cusions," line is not particularly plausible.
What we REALLY need is for some court ruling to take all those fucking provisions, and declare them illegal.
No, what we really need is to restructure things so that artists can get good distribution without signing a contract with companies like this. Even if you get laws to declare certain provisions illegal, record companies will still have all the power, so they'll just find new, different ways to screw the artists.
Capitalist bastards.
Well, to be fair, I think they're more accurately oligarchic bastards. They really don't seem to get the whole market economics thing.
And if I sue a giant company and do my own legal work, and lose, I could end up costing them lots of money whilst I only accrue little legal fees. How much would they get from me? Especially if the case is a frivolous one?
If your point is that my suggestion isn't perfect, I already said that, but thanks for helping clarify the details. If your point is that this is enough to make it workable, I'm dubious; I can think of several easy remedies for this, and I'd bet you can, too.
This statement says nothing about them not writting a test, it says if you see code you don't understand.
Read the rest of my post, not just that one sentence. I'm talking about having complete unit test coverage for a code base. If you have that, you can indeed safely delete code you think to be useless.
the case of a rewrite that fixes a security hole, it's possible but unlikely the test would be an exploit,
It's perfectly likely if you write it that way. If you don't test it, how would you know if you've fixed it? That's the basic theory behind all test-driven development: You write the test, then you make it pass. You write no code unless you have a test that requires it. This goes for both the initial coding and for bug fixes.
It doesn't guarantee that your code is perfect, of course; it's still possible to have bugs. But it does reduce the odds drasically. For example, two years ago we launched a web site with about six man-months of development. Since then there have been two substantial upgrades, and in all that time we've had two valid reported bugs, neither of which was in the main code base. (One was in a server config file; the other was a malformed HTML template.)
Now that I'm skilled at test-first development, I spend an average of 5 minutes a week in the debugger, and I never work late. It's great! I recommend it to everybody. For a good introduction, check out the recent book Test-Driven Development: By Example.
Because a loser pays system would prevent a small company from ever filing suit against a big evil company. The costs of losing would be exponentially larger if they had to cover the evil corp's lawyers too....and being in the right hand having a solid case never guarantees victory.
Then you make it so that you only have to pay them for legal fees up to the amount you incurred. That still wouldn't level the playing field completely, as the giant company could still outspend you. But it's better than the current system.
hmm ok, but what if the reason you don't know what it was, is because it was a fix for a security hole you personally don't even know exists. And thus you delete it, reintroduce the security hole (because there was no visible "breaking", or because there was and you rewrote the same flawed code as before).
Then the person who put the code in without adding a unit test first failed to do their job properly. As important as this is for regular code, it's doubly so for a bug fix; how could they possibly know the bug was better unless they tested it?
On the other hand, the larger the team, the more structure is required; you don't want one person breaking what another person took four weeks to complete.
Well, more structure is one option. Or you could just write self-defending code. A good unit test suite combined with a Continuous Integration tool means that if somebody breaks something, they'll get an email a few minutes later.
On my last few projects, we've ended up with about a 50/50 ratio between test code and production code. You'd think that it would slow things down, but it really makes development faster. I spend about ten minutes a week using the debugger, and very little time wondering what something does.
On the rare occasions when I can't figure out what some chunk of code does, I'll just comment it out and run the tests. If nothing breaks, then I delete it and move on. And if something does break, then I delete it and write something clearer in its place. It's very freeing!
Sure, I've tried instituting "processes" and management's alwasy keen on the idea. But when push comes to shove, poof.
Then institute a process that works with their desire to change things, rather than against it. All of the agile processes, especially Extreme Programming, are designed to embrace change, rather than resisting it.
For developers, it's much more fun. With a traditional spec-driven process, the developer's job is to say no. With an agile process, you get to say yes. Or, more accurately, you get to say, "Yes, but pushing that feature to the top means you'll see other features later." It makes scope control their problem, rather than yours.
You're close, but your conclusion is wrong.
The only perfect language for software specs is an unambiguated, testable, logical language.
Yes! So write your specs in code. Make automated tests for your features in parallel with development. And while you're at it, use test-driven development and build unit tests as you go.
In the business world, you are going to have to come up with a budget for your software projects. A project whose scope or length is not defined does not lend itself well to budget forecasting.
Have you looked at the stats on how many software projects actually come in on time and on budget?
As a profession, we'd be better off being honest about the fact. But it doesn't fit tidily into management spreadsheets, so an awful lot of people just make up numbers. Or worse, they are browbeaten into making the estimate match what the businesspeople want to hear.
That's not to say you can't take an initial stab at the budget. But good development is essentially exploratory; it's a rare product that is exactly like the initial spec, and those products generally suck. Better to get an initial budget and then tune your process so you can stop development when you run out of money.
The best trick I've ever seen for setting project goals is to sit developers down with business users or the end users of the product and have them observe work in action. This understanding can go a long way when a developer is back in the 'cube' for long hours of coding. Domain knowledge is critical to a developer. Otherwise you end up with some trully epic program that bears little to no pracitcal value.
There's an even better trick: put your development team in a shared workspace. Then make a domain expert the product manager and put them in the same room, so that if developers have questions they just have to look up and raise their voice a bit.
It's fantastic. The closest we get to specs is whiteboard sketches and the occasional UI mockup. And that's all we need. The developers love it, because there's no guesswork involved. And the product manager loves it because he gets exactly what he wants without having to write phone-book-sized spec documents.
On the topic of knowing the domain, I also strongly recommend the book Domain-Driven Design. It's a brilliant book on how to base your OO model on the thing that is least likely to change: the business domain.
I mean really, you're making a promise to spend your life with someone and they basically make a joke of it. Why would you do that? It's supposed to be a solem occasion.
Supposed to be solemn? Sez who? When you get married, you're welcome to have whatever wedding you want, of course. But I think it's more important that weddings be serious and meaningful to the participants. Serious doesn't have to mean traditional, boring, or solemn.
A friend of mine got married a few years back. He is a delightful, creative freak, as are many of his friends. A traditional, solemn wedding would have made him and his friends miserable. Why would they dedicate their lives to making interesting art and causing lively trouble, only to pretend otherwise on their wedding day?
Answer: they wouldn't. As with everything else they do, they took traditional answers and shook them up. They had a wedding that was serious, heartfelt, and quirky, filled with love and laughter. It might have been their wedding but it was also their wedding.
Google never writes to the filesystem -- it's all in memory and temporary. They only use the disk to boot the system.
For their production service, I understand that they keep it all in memory. But it's hardly temporary.
Hardly anyone is like Google.
For now. Google was one of the first companies to take advantage of the fact that RAM and procesing power have become ridiculously cheap. SQL databases arose in an era when 32k was a fair bit of RAM, and where a business computer was one or more refrigerator-sized units kept in a sacred temple.
Now computers are cheap and disposable. I can fill a rack with cheap 1Us and get processing power that Sun can't match at 10 times the price. The only trick is to write your apps in such a way that you can tolerate hardware failures. That's a little hard, but it paid off handsomely for Google. Others will learn this trick.
You can bet they'll be using RAID (etc) for the GMail service.
You'd lose that bet. They already have built their own distributed network filesystem, GFS, that holds at least hundreds of terabytes. It has performance and reliability levels well above any RAID installation I've ever heard of, and it uses cheap commodity hardware to do it. I'd bet that GMail will be built on top of a variant of GFS or some other in-house technology.
If you actually generate a kind of good publicity for a company that sells a high margine product, like oh soft drinks or post-its, they'll likely go a little farther.
There's margarine in soft drinks? Eeeew!
I never have and never will film a movie with a camcorder. I do sneak in food and drinks all the time though. I sure hope I can't get a year in jail for that.
You realize that criminalizing one makes as much sense as the other, right?
In both cases, somebody (studio, theater) does something (makes, shows a movie) with a particular plan about how to make money from it. Then somebody else finds a way to get the value without coughing up like the producer expected.
Videotaping a movie happens to be illegal, while bringing in your own drink is only against the rules. But that's only because the MPAA has more money to lobby. They're both equally wrong (or right, depending on your choice of moral frameworks).
Good for you. And I'm sure you'd welcome a system hardcoded to automatically fast forward over stuff that someone else found boring.
I already do. That's the standard DVD edit. The stuff they only found marginally boring is put on the DVD as "extra scenes". The stuff that they thought really boring never even made it on the DVD.
This is censorship. It is censorship because by using the machine you are not deciding what you want to see and hear, the machine is doing that for you.
Wrong. By using the machine, I'm choosing to let another human edit the movies. Of course, by choosing to watch any movie, I'm letting another human edit the movie; your average movie shoots ten times as much film as they use, and documentaries may shoot eighty times as much film.
Personally, I don't read many blogs; I instead let a human editor pick the good stuff for me and put it in a magazine. Is that censorship? If it is, then we need another word for the really sinister thing where the government paternalistically tells me what I can and cannot see.