The regex filters in sendmail can be triggered before the body is read.
Is that allowed in the RFCs? I thought that once the DATA command was in progress, you couldn't interrupt it. So you'd probably have to take the data, anyhow unless you were willing to just drop the connection. And if you do that, the originating server is likely to just try again.
Better just to accept the whole message and return a 5xx. Unless you want to cause trouble for the spammer, in which case you should just keep returning a 4xx and waste his bandwidth.
I wonder if I can get an Oregon phone line and have all my calls forwarded to California. That's probably cheaper than spending the time dealing with telemarketroids.
There must be a balance of power between those who order the work and those who do it.
The best balance of power setup I've seen is part of Extreme Programming. In XP, the suits can ask for whatever they want, and they can change their mind every week. The developers get the final say on estimates, and the suits can only order as much work for the next week as was done last week. The developers deliver a new version every week, so everybody can see exactly how the project is going.
This sounds too simple, but it works really well. Every week, the businessfolk are forced to balance their desires with the reality of the development situation. With only a week between data points, nothing can get too far out of whack.
Of course, some bosses are just unwilling to face the fact that for X dollars, they can only get Y features; they will refuse to implement any system that makes that clear. But most people just want to get good software, so they will come around if you put it to them properly.
The point is, don't go on a diet. Just eat less crap, get smaller servings and excercise more. It's far less painful and more healthy than some nutty diet.
That's swell in theory. When I've tried it, I coudln't get it to work so well. The main obstacle was being hungry all the time; when I'm hungry, my concentration goes to hell, which means I can't code. I'm also much more irritable.
The thing I like about the low-carb diets is that I get hungry like normal (or perhaps a little less often) but I'm still losing weight as if I were eating circa 1400 calories a day.
But I agree that looking at it as a lifestyle change is important. Even when I reach my target weight, I'll never go off a diet; I'll just shift the composition of it to be more balanced.
I would recommend that anyone going on any diet start off with at least 2 weeks on Atkins. It really brings home how pervasive "junk carbs" have become in your personal diet. So much food is made of or coated or stuffed with starch and sugar.
Amen. When I heard the term "sugar addict" before, I always took it as hyperbole. But starting on the diet let me kick the habit. Now I recognize that I met the DSM IV criteria for addiction. That's spooky! Now I can sit next to an open candy jar and not touch it. I no longer have to run out and get a candy bar. And my moods are much, much more even.
It is bogus that "they" won't study Atkins properly. It isn't like they would have trouble finding volunteers. I only know it has to be better for me than being massively overweight - even with the risk of kidney stones.
No shit. I'd love to read a good anti-Atkins article, but this one wasn't it. It's the same warmed-over collection of stuff. Did it address any of Taubes "Endocrinology 101" stuff? Nope. Did it have any serious evidence that the risks of the Atkins diet even come close to the risks of staying obese? Nope.
Now I rarely talk about it with my friends. They just say, "Hey, you're losing weight!" And I just say, "Yep! I feel much better, too!"
Since you're an expert, could you tell us how much weight you've lost on your recommended diet?
It's funny, but since I started on a low-carb diet, a lot of people who have never lost weight have been giving me an awful lot of tips on thoretically better ways to lose weight.
Let's be frank, here. The same nutritionists who shrink in horror at Atkins and his ilk have been warning us for years of the huge health dangers of obesity. And they are the same ones pushing the same eating and diet regimens that have worked so well that obesity is way up. I'll listen respectfully to them, but their track record is so far pretty poor, and their unwillingness to investigate low-carb diets and steal their good parts doesn't impress me either.
The short- and long-term dangers of obesity are well-known. The short-term risks of low-carb diets seem minimal. The long-term effects are unknown. I'm not telling anybody else what to do, but it's working for me where a number of other things haven't.
Last I looked, Usenet had mainly devolved into a vast collection of spamers, people utterly dedicated to a topic, and frothing nutters. That's a shame; circa 1991 it was actually pretty swell.
The thing I like about Ask Slashdot is that it gets a broad audience. The point isn't so much to extract particular information; it's to have a bunch of smart people talk something over. And the moderation mechanism means that I can easily see the relatively useful bits without having to wade through a lotta garbage.
So Google Groups, like Google, is often a good way to get answers to particular questions, but I hardly see it as a replacement for Ask Slashdot.
This is certainly true, but you should consider the flipside of it. The typical way it works with IT departments is that they are given unfunded mandates right and left. There is no possible way they can do everything with the money they have. What should happen is that some stuff should be taken off their plate. But they rarely have the political pull needed to do that, so what actually happens is that either everything is done poorly or the IT guys work on what they think is important.
So before you go pointing fingers at the IT department's attitude, it would be good to ask, "Did they tell the managment that they needed a way to back up those machines? And did the managers give them the necessary time and funds?"
Every IT person I know with a bad attitude has didn't start that way; they acquired it through years of crappy management.
Yep! If it's the latter, you *might* want to publish the fact that they haven't paid you on your site, so that anybody who searches on them can find it. But you have no moral obligation to the VCs in particular.
You should be very careful in doing this kind of pseudo-threatening yourself. Hire a lawyer with teeth and have them lean on the deadbeat. A good lawyer will know exactly what they can get away with.
If you're on a W2, then you have a lot of leverage. In California, at least, businesses are required to pay wages first, before other obligations. Not paying wages can get them in a whole heap of trouble with some state department, resulting in really impressive fines.
When a company tried to welch on three months of W2 contract work, I got a lawyer to write a mean letter. If you are in Cali and on a W2, send me an email to the obvious address and I'll send you a copy of the letter for you to show to your lawyer.
I agree that it is hard to automate UI Testing; you cant automate usability tests.
I think that's true generally, but I've been thinking we can make some progress in that direction. There's an automated software design analysis tool called Small Worlds that offers opinions on OO design. It's pretty good.
I suspect that similar metrics could be calculated for web UIs so that we could help UI designers focus on dangerous areas, and so that they could be alerted if areas get worse. Even basic things like "links per page", "fields per form", and "percentage of page below the fold" would give you reminders to find pages that were unusually complicated for your site.
If I'm going to spend x amount of man-weeks (yes, weeks) to create an automated test suite, am I going to get the cost savings back when I know v2.0 is 8 months away?
About 30% of my time and 50% of my code goes into automated testing. I write unit tests, integration tests, and end-to-end functional tests.
So you're right that testing takes time. But they payback is immense. If I write the tests as I go, I spend almost no time debugging. I have almost no bug reports. And when v2.0 comes, I don't throw out the old source code; I get to use it all again, as I know it's solid, and thanks to the test suite, I can change it radically without fear of breaking anything.
I don't want anyone who doesn't understand the value of testing -- and isn't willing to put in the effort to test -- on my team.
I'd agree with that, but manual testing takes a lot of time. Much better to spend that time on automating the tests. People are bad at doing boring, repetitive things; computers are good at it. Teach them how and let the developers focus on developing!
Your entire question, well, sucks. If you think you can test at the end of a product cycle, you're smoking the kind of crack cocain[e] that leads to things like this.
Amen!
If you find a bug at the end of a development cycle, you have months of changes to rummage through and try to find the problem. This sucks; you'll never get them all out; you just get the biggest ones and then you ship.
The right way is to write the tests first, before you write the code. Going back and retrofitting good tests will take time and careful thought, two commodities in short supply in the pre-ship rush.
The only automated testing tools you can find is for regression tests.
Excluding, of course, things like HttpUnit, where you write code that drives a simulated browser and then check the results.
I've used it for automated testing of a couple of sites, and I like it plenty. Between HttpUnit, JUnit, and Test-Driven Development, we launched a complicated web site and have had it in production for six months with a total of one user-reported bug. And that bug was when the graphic designer broke a link.
I guess the factor I was forgetting is that most large companies have terrible records developing software. Ergo, what seems obvious to me (that doing it Google-style will save money and get better results) must seem awfully scary to them.
As long as you're here, I've got a question: Why do people buy systems like this?
I design and build software for a living, including stuff for banks, and I've been trying to imagine a system where I really need 50 TB in one place. Email for 10 million? Customer records for 50 million? A search engine for the entire web? For all of these, my designs would end up like Google: an array of cheap, commodity boxes that each are responsible for a portion of the data.
So is it that there are applications that really require this? Is it that some architects are used to drawing the one single "storage" icon and a $20 million bill isn't enough to make them say, "Gosh, is there a better way to do it?"
Or is it that the sysadmin costs and pain associated with maintaining 25 racks of gear make it worth coughing up for the centralized system in the long run?
The most productive coders in my experience of managing are the ones who are at work fewer hours. I have had my share of reports who consistently work sixteen hour days but are also consistently late on their work once the QA cycle kicks in. A fully rested well balanced programmer makes better decisions and fewer mistakes.
You may be able to help them by having the QA cycle kick in earlier, then. The sooner feedback comes, the easier it is to recognize and learn from your mistakes.
Personally, I'd use a lot of XP practices; between pair programming, continuous integration, and test-driven development you can get a lot of developers to learn the difference between "feels faster" and "is faster".
It's very hard to challenge what people believe to be true, be it management theories, religion, C++ vs. Java, whatever. All the statistics, reports, copies of Peopleware you wave at your managers won't make a difference if they believe "more work" is the magic bullet.
This is true. It's easy for them to say, "Oh, that doesn't apply here." One solution to that is to measure it at your company. If you can prove that increased hours doesn't help, then they'll stop. Either that or they are insane, in which case you should quit.
And unfortunatly, sometimes it's the only bullet available. Time Slip = Lost Chance at Revenue, Feature Slip = Lost Customer, etc.
I agree that an occasional bit of targeted overtime can occasionally help. But most of the time people, it actually hurts. Quality goes down, meaning that you are saving up trouble for later. But when you get to "later", guess what? There are still time and feature pressures, so the cleanup gets put off, and new bugs get added, because it has to ship NOW.
The engineers out there will recognize this as a classic positive feedback loop. And we all know where those lead, right?
These days, many XP people call this "sustainable pace" rather than "Forty Hour Week". The notion is that instead of pursuing some magic number, you measure your progress and work the number of hours that produces the most value over the long haul.
I heard one person say that calling this "Optimal Pace" went over even better with the management. Who could argue with finding the optimium pace?
No offence, but the XP guys didn't invent the wheel.
Don't worry; the XP guys won't take offense. I was just down at PARC listening to Kent Beck, one of the XP gurus, and he's both humble and very generous with the credit.
On the other hand, they were the first people to put a bunch of different ideas together in a way that is, curse the marketroids who ruined this term, synergistic. So they should get a little credit for brainpower, too.
If you're smart, you'll do an experiment. Do a single, small-scope project, and track it carefully. Work at a burn-out rate (eg. > 40 hours a week). Pick another project, work at an easy rate.
If you're on an XP team, you can actually do this experiment even more easily. Every week you end up with a number known in the XP jargon as "velocity". If you work crazy hours for a few weeks, your velocity will indeed go down, not up.
I certainly did not like my programmers working extended hours; at least not routinely. It made them tired, irritable, and a pain in the ass to have around the office. The code got sloppy, too.
That last one is the real killer.
Whenever I see one of these if-you-aren't-sweating-you-aren't-working projects, I can guarantee that they will spend a lot more time fixing bugs than is sane. Of course, many of those bugs won't surface until the last part of the project, so it looks like more progress is being made.
This is the same mistake a lot of people make with credit cards. For the first few months they have them, they're rich! And then suddenly, they're screwed; all their income goes to interest charges, so they're suddenly poor. Some people will make minimum payments for years; some will just declare bankruptcy; a very few will get a clue, pay off the debts, and then never use credit cards again.
most coding you are just following the script or plan.
Then you're doing the wrong programming. The whole point of computers is to automate things that are boring and obvious. If you're letting your brain go slack developing, you're wasting your employer's money and--even worse--your time.
Slashdot Mirror
The regex filters in sendmail can be triggered before the body is read.
Is that allowed in the RFCs? I thought that once the DATA command was in progress, you couldn't interrupt it. So you'd probably have to take the data, anyhow unless you were willing to just drop the connection. And if you do that, the originating server is likely to just try again.
Better just to accept the whole message and return a 5xx. Unless you want to cause trouble for the spammer, in which case you should just keep returning a 4xx and waste his bandwidth.
I wonder if I can get an Oregon phone line and have all my calls forwarded to California. That's probably cheaper than spending the time dealing with telemarketroids.
There must be a balance of power between those who order the work and those who do it.
The best balance of power setup I've seen is part of Extreme Programming. In XP, the suits can ask for whatever they want, and they can change their mind every week. The developers get the final say on estimates, and the suits can only order as much work for the next week as was done last week. The developers deliver a new version every week, so everybody can see exactly how the project is going.
This sounds too simple, but it works really well. Every week, the businessfolk are forced to balance their desires with the reality of the development situation. With only a week between data points, nothing can get too far out of whack.
Of course, some bosses are just unwilling to face the fact that for X dollars, they can only get Y features; they will refuse to implement any system that makes that clear. But most people just want to get good software, so they will come around if you put it to them properly.
is the Slashdot audience really such a fat, lazy, gullible, stupid bunch
Speaking of trolls...
The point is, don't go on a diet. Just eat less crap, get smaller servings and excercise more. It's far less painful and more healthy than some nutty diet.
That's swell in theory. When I've tried it, I coudln't get it to work so well. The main obstacle was being hungry all the time; when I'm hungry, my concentration goes to hell, which means I can't code. I'm also much more irritable.
The thing I like about the low-carb diets is that I get hungry like normal (or perhaps a little less often) but I'm still losing weight as if I were eating circa 1400 calories a day.
But I agree that looking at it as a lifestyle change is important. Even when I reach my target weight, I'll never go off a diet; I'll just shift the composition of it to be more balanced.
I would recommend that anyone going on any diet start off with at least 2 weeks on Atkins. It really brings home how pervasive "junk carbs" have become in your personal diet. So much food is made of or coated or stuffed with starch and sugar.
Amen. When I heard the term "sugar addict" before, I always took it as hyperbole. But starting on the diet let me kick the habit. Now I recognize that I met the DSM IV criteria for addiction. That's spooky! Now I can sit next to an open candy jar and not touch it. I no longer have to run out and get a candy bar. And my moods are much, much more even.
It is bogus that "they" won't study Atkins properly. It isn't like they would have trouble finding volunteers. I only know it has to be better for me than being massively overweight - even with the risk of kidney stones.
No shit. I'd love to read a good anti-Atkins article, but this one wasn't it. It's the same warmed-over collection of stuff. Did it address any of Taubes "Endocrinology 101" stuff? Nope. Did it have any serious evidence that the risks of the Atkins diet even come close to the risks of staying obese? Nope.
Now I rarely talk about it with my friends. They just say, "Hey, you're losing weight!" And I just say, "Yep! I feel much better, too!"
Since you're an expert, could you tell us how much weight you've lost on your recommended diet?
It's funny, but since I started on a low-carb diet, a lot of people who have never lost weight have been giving me an awful lot of tips on thoretically better ways to lose weight.
Let's be frank, here. The same nutritionists who shrink in horror at Atkins and his ilk have been warning us for years of the huge health dangers of obesity. And they are the same ones pushing the same eating and diet regimens that have worked so well that obesity is way up. I'll listen respectfully to them, but their track record is so far pretty poor, and their unwillingness to investigate low-carb diets and steal their good parts doesn't impress me either.
The short- and long-term dangers of obesity are well-known. The short-term risks of low-carb diets seem minimal. The long-term effects are unknown. I'm not telling anybody else what to do, but it's working for me where a number of other things haven't.
Yeah, a friend of mine just build a 15 x 100-foot RGB audio Vu meter. He used a lot of rope light, and it's great stuff, very easy to work with.
Last I looked, Usenet had mainly devolved into a vast collection of spamers, people utterly dedicated to a topic, and frothing nutters. That's a shame; circa 1991 it was actually pretty swell.
The thing I like about Ask Slashdot is that it gets a broad audience. The point isn't so much to extract particular information; it's to have a bunch of smart people talk something over. And the moderation mechanism means that I can easily see the relatively useful bits without having to wade through a lotta garbage.
So Google Groups, like Google, is often a good way to get answers to particular questions, but I hardly see it as a replacement for Ask Slashdot.
This is certainly true, but you should consider the flipside of it. The typical way it works with IT departments is that they are given unfunded mandates right and left. There is no possible way they can do everything with the money they have. What should happen is that some stuff should be taken off their plate. But they rarely have the political pull needed to do that, so what actually happens is that either everything is done poorly or the IT guys work on what they think is important.
So before you go pointing fingers at the IT department's attitude, it would be good to ask, "Did they tell the managment that they needed a way to back up those machines? And did the managers give them the necessary time and funds?"
Every IT person I know with a bad attitude has didn't start that way; they acquired it through years of crappy management.
Yep! If it's the latter, you *might* want to publish the fact that they haven't paid you on your site, so that anybody who searches on them can find it. But you have no moral obligation to the VCs in particular.
You should be very careful in doing this kind of pseudo-threatening yourself. Hire a lawyer with teeth and have them lean on the deadbeat. A good lawyer will know exactly what they can get away with.
Are you there on a W2? Or a 1099?
If you're on a W2, then you have a lot of leverage. In California, at least, businesses are required to pay wages first, before other obligations. Not paying wages can get them in a whole heap of trouble with some state department, resulting in really impressive fines.
When a company tried to welch on three months of W2 contract work, I got a lawyer to write a mean letter. If you are in Cali and on a W2, send me an email to the obvious address and I'll send you a copy of the letter for you to show to your lawyer.
I agree that it is hard to automate UI Testing; you cant automate usability tests.
I think that's true generally, but I've been thinking we can make some progress in that direction. There's an automated software design analysis tool called Small Worlds that offers opinions on OO design. It's pretty good.
I suspect that similar metrics could be calculated for web UIs so that we could help UI designers focus on dangerous areas, and so that they could be alerted if areas get worse. Even basic things like "links per page", "fields per form", and "percentage of page below the fold" would give you reminders to find pages that were unusually complicated for your site.
If I'm going to spend x amount of man-weeks (yes, weeks) to create an automated test suite, am I going to get the cost savings back when I know v2.0 is 8 months away?
About 30% of my time and 50% of my code goes into automated testing. I write unit tests, integration tests, and end-to-end functional tests.
So you're right that testing takes time. But they payback is immense. If I write the tests as I go, I spend almost no time debugging. I have almost no bug reports. And when v2.0 comes, I don't throw out the old source code; I get to use it all again, as I know it's solid, and thanks to the test suite, I can change it radically without fear of breaking anything.
I don't want anyone who doesn't understand the value of testing -- and isn't willing to put in the effort to test -- on my team.
I'd agree with that, but manual testing takes a lot of time. Much better to spend that time on automating the tests. People are bad at doing boring, repetitive things; computers are good at it. Teach them how and let the developers focus on developing!
Your entire question, well, sucks. If you think you can test at the end of a product cycle, you're smoking the kind of crack cocain[e] that leads to things like this.
Amen!
If you find a bug at the end of a development cycle, you have months of changes to rummage through and try to find the problem. This sucks; you'll never get them all out; you just get the biggest ones and then you ship.
The right way is to write the tests first, before you write the code. Going back and retrofitting good tests will take time and careful thought, two commodities in short supply in the pre-ship rush.
The only automated testing tools you can find is for regression tests.
Excluding, of course, things like HttpUnit, where you write code that drives a simulated browser and then check the results.
I've used it for automated testing of a couple of sites, and I like it plenty. Between HttpUnit, JUnit, and Test-Driven Development, we launched a complicated web site and have had it in production for six months with a total of one user-reported bug. And that bug was when the graphic designer broke a link.
Thanks for posting! That's very interesting.
I guess the factor I was forgetting is that most large companies have terrible records developing software. Ergo, what seems obvious to me (that doing it Google-style will save money and get better results) must seem awfully scary to them.
As long as you're here, I've got a question: Why do people buy systems like this?
I design and build software for a living, including stuff for banks, and I've been trying to imagine a system where I really need 50 TB in one place. Email for 10 million? Customer records for 50 million? A search engine for the entire web? For all of these, my designs would end up like Google: an array of cheap, commodity boxes that each are responsible for a portion of the data.
So is it that there are applications that really require this? Is it that some architects are used to drawing the one single "storage" icon and a $20 million bill isn't enough to make them say, "Gosh, is there a better way to do it?"
Or is it that the sysadmin costs and pain associated with maintaining 25 racks of gear make it worth coughing up for the centralized system in the long run?
The most productive coders in my experience of managing are the ones who are at work fewer hours. I have had my share of reports who consistently work sixteen hour days but are also consistently late on their work once the QA cycle kicks in. A fully rested well balanced programmer makes better decisions and fewer mistakes.
You may be able to help them by having the QA cycle kick in earlier, then. The sooner feedback comes, the easier it is to recognize and learn from your mistakes.
Personally, I'd use a lot of XP practices; between pair programming, continuous integration, and test-driven development you can get a lot of developers to learn the difference between "feels faster" and "is faster".
It's very hard to challenge what people believe to be true, be it management theories, religion, C++ vs. Java, whatever. All the statistics, reports, copies of Peopleware you wave at your managers won't make a difference if they believe "more work" is the magic bullet.
This is true. It's easy for them to say, "Oh, that doesn't apply here." One solution to that is to measure it at your company. If you can prove that increased hours doesn't help, then they'll stop. Either that or they are insane, in which case you should quit.
And unfortunatly, sometimes it's the only bullet available. Time Slip = Lost Chance at Revenue, Feature Slip = Lost Customer, etc.
I agree that an occasional bit of targeted overtime can occasionally help. But most of the time people, it actually hurts. Quality goes down, meaning that you are saving up trouble for later. But when you get to "later", guess what? There are still time and feature pressures, so the cleanup gets put off, and new bugs get added, because it has to ship NOW.
The engineers out there will recognize this as a classic positive feedback loop. And we all know where those lead, right?
Forty Hour Week
These days, many XP people call this "sustainable pace" rather than "Forty Hour Week". The notion is that instead of pursuing some magic number, you measure your progress and work the number of hours that produces the most value over the long haul.
I heard one person say that calling this "Optimal Pace" went over even better with the management. Who could argue with finding the optimium pace?
No offence, but the XP guys didn't invent the wheel.
Don't worry; the XP guys won't take offense. I was just down at PARC listening to Kent Beck, one of the XP gurus, and he's both humble and very generous with the credit.
On the other hand, they were the first people to put a bunch of different ideas together in a way that is, curse the marketroids who ruined this term, synergistic. So they should get a little credit for brainpower, too.
If you're smart, you'll do an experiment. Do a single, small-scope project, and track it carefully. Work at a burn-out rate (eg. > 40 hours a week). Pick another project, work at an easy rate.
If you're on an XP team, you can actually do this experiment even more easily. Every week you end up with a number known in the XP jargon as "velocity". If you work crazy hours for a few weeks, your velocity will indeed go down, not up.
I certainly did not like my programmers working extended hours; at least not routinely. It made them tired, irritable, and a pain in the ass to have around the office. The code got sloppy, too.
That last one is the real killer.
Whenever I see one of these if-you-aren't-sweating-you-aren't-working projects, I can guarantee that they will spend a lot more time fixing bugs than is sane. Of course, many of those bugs won't surface until the last part of the project, so it looks like more progress is being made.
This is the same mistake a lot of people make with credit cards. For the first few months they have them, they're rich! And then suddenly, they're screwed; all their income goes to interest charges, so they're suddenly poor. Some people will make minimum payments for years; some will just declare bankruptcy; a very few will get a clue, pay off the debts, and then never use credit cards again.
most coding you are just following the script or plan.
Then you're doing the wrong programming. The whole point of computers is to automate things that are boring and obvious. If you're letting your brain go slack developing, you're wasting your employer's money and--even worse--your time.