Is there anything preventing building automated test suites?
Automated testing sucks. Don't think it's going to save you any time or catch defects any more reliably or faster. It's tempting, and can be useful, but it's usually a big waste of time.
To do it right, you need to basically duplicate everything that the target program does, and verify it's output. When the code changes, your scripts often break. Guess how many people on a project of 30 people will code that?
Now, how many people will want to do automated test scripts on a project with often and early release schedule?
Having said that, limited automated testing can be very valuable. Usually testing protocols or data manipulation...ideal to catch some security issues.
The following is dry, and opinionated, from the POV of an old-timer VV&T/QT/Tester.
I'm big on specifications, and will argue both sides of a contract when a spec is violated. I've even been in a couple shouting matches over them, fighting for the correct implementation, not supposed "flexibility" though they do need to be bent at times.
Fortunately, the shouting matches are rare and as a Contractor Scum(tm), I never take them personally...only as a barganing point and to help stiffen the backs of those who are easily swayed. It's a shame when good projects go bad, but that's other people's money!
Good specifications are invaluable in eliminating all sorts of conflicts and allow projects to actually end without different groups wanting to kill each other.
Unfortunately, specifications are by necessity limited in scope. If it's not in the spec, it can't easily be added. If it's in the spec, it can't be modified easily.
On a formal contract, adding in goals like "The system shall be fast" don't work well, so more detail is usually specified; "The system shall retrieve a query on the client stations within 4 seconds at all times".
There's always a few details that slip by, and if the people on the project aren't reasonable the details will cause quite a few social and technical problems.
Even relying on an outside specification is a problem...since APIs/protocols/... are usually vauge on some level.
The people who implement it and the environment have a much greater impact on the results; there will be good and bad free software / open source projects...as there are good and bad commercial projects.
From what I've seen, I'll trust open source as much or more in most cases...but I'll test it first.
Agreed. VMware does this, and I gladly gave them $$ for the product they made. No paper invoice, no packaging, all electronic. I heard about the product by word of mouth, tried the full-featured -- but time limited -- "demo", and just couldn't not give them money.:/
I worked for a once-proud DOS/Windows utility company. For a few months we even had a top 10 selling product in terms of retail and in bulk licence sales.
The company's package evolved from a spiral-ringed binder, to a slim plastic spiraled manual with a disk insert, to a small box, to a full-page sized box two inches thick.
Retailers *hated* the huge box...but we sold much more after changing formats. For one, you couldn't turn the box on it's edge. It begged to be placed face-out. It demanded more shelf space...the one thing the retail stores have a limited supply of.
We even tried sending out upgrades in a no-fuss package; disks plus manual in a slim carboard shipping box, but got complaints and a bad write up in a trade magazine. Because of that, we shipped the full box after that point.
One product was even targeted for sale at the register, so we scaled the package down below the size of a CD case. After getting next to no sales on that, we dumped minimal packaging attempts entirely.
In the end, we decided that a brochure-style box with a full-color description was necessary. It was a glossy, heavy, and cardboard re-inforced package -- even though the manual was only a little bigger and one more diskette was added.
The only environmental concessions we were able to get away with were vegtable dyes and no plastic except shrink wrap.
# All known email sent to the Good folder :0 * (^TO one@good.hk) Good
# This dumps all the rest from *.hk into Spam :0 * (^TO *.hk) Spam
Adjust these as necessary. Once you're happy they are working, you can change the "Spam" folder to/dev/null and the mail will be discarded. It's good to log Procmail transactions so that you can catch defects in your scripts more easily.
Procmail can be easily adapted to read a user-specific file. The file could be edited using a web page form to keep users from messing up the syntax. Procmail is easy to use, but will fail to process some or all of the script commands if the syntax isn't correct!
It's practical adopt a simple set of rules, easily created with a Procmail script, and use them as a general filter. Using a specific filter is just one form of security-through-obscurity and is easy to thwart.
1. All mail from known addresses is let through.
2. (optional) Mail from known senders is sent to a specific mail folder for that user (Business, Friends, Family, Natilie_Portman,...).
3. All mail addressed to the user directly -- but not as a BCC list -- is sent through to the user's INBOX.
4. (optional) All remaining mail is sent to either/dev/null or a Probable_Spam mail folder.
I'm not talking about the costs of wasted power from hot CPUs, multiple 7200rpm drives, and 3D video cards...but the fans to cool them. In a new machinee, I have 5 fans costing a minimum of $30...and these are the cheap ones not the good quality (and quiet) PC-Power and Cooling equipment.
To cut the sound some, it would easily double or tripple the costs.
Well if you work in an environment where people keep sending you that MS document in their emails, how much choice do you have?
Mmmm...send them files in TeX format?
Seriously though, knowing what the person can read on the other end and sending them that is courtious. Unfortunately, too many people think that everyone uses what they do.
I'd tell you I was sorry for the mistake...but I checked them before I submitted the Ask/. a few weeks ago. Back then, they were valid and worked for me!
This one had the first easter egg I ever encountered.
You had to find three grey dots hidden in the walls of certian rooms. If you gathered all three together, you could walk through a special wall that lead to a room with the easter egg. If you didn't have the three dots, you'd just see another (empty) room.
I think the easter egg had the names of the programmers, but don't quote me on that.
Shortly after finding this, I proceeded to tourture the machine with a screwdriver...and "programmed" a few new games.
I am betting on HP-UX going next, and Sun keeping going to its last dying gasp.
HP does have an incentive to go head-to-head with IBM by using thier minis to support virtual webservers -- at a mini-computer price, not a mainframe cost.
Yet, with the Intel+HP aliance merging the PA-RISC and I86 processors, HP might make more $$$ by focusing on retooled versions of Win2K to do the same thing. Sure, NT/2K isn't as portable as [insert favorite Unix variant], but with the CPUs being identical they could munge something together, make obnoxious money on reselling the Win licences, and still have hpux for other users.
Slashdot Mirror
Automated testing sucks. Don't think it's going to save you any time or catch defects any more reliably or faster. It's tempting, and can be useful, but it's usually a big waste of time.
To do it right, you need to basically duplicate everything that the target program does, and verify it's output. When the code changes, your scripts often break. Guess how many people on a project of 30 people will code that?
Now, how many people will want to do automated test scripts on a project with often and early release schedule?
Having said that, limited automated testing can be very valuable. Usually testing protocols or data manipulation...ideal to catch some security issues.
The following is dry, and opinionated, from the POV of an old-timer VV&T/QT/Tester.
I'm big on specifications, and will argue both sides of a contract when a spec is violated. I've even been in a couple shouting matches over them, fighting for the correct implementation, not supposed "flexibility" though they do need to be bent at times.
Fortunately, the shouting matches are rare and as a Contractor Scum(tm), I never take them personally...only as a barganing point and to help stiffen the backs of those who are easily swayed. It's a shame when good projects go bad, but that's other people's money!
Good specifications are invaluable in eliminating all sorts of conflicts and allow projects to actually end without different groups wanting to kill each other.
Unfortunately, specifications are by necessity limited in scope. If it's not in the spec, it can't easily be added. If it's in the spec, it can't be modified easily.
On a formal contract, adding in goals like "The system shall be fast" don't work well, so more detail is usually specified; "The system shall retrieve a query on the client stations within 4 seconds at all times".
There's always a few details that slip by, and if the people on the project aren't reasonable the details will cause quite a few social and technical problems.
Even relying on an outside specification is a problem...since APIs/protocols/... are usually vauge on some level.
The people who implement it and the environment have a much greater impact on the results; there will be good and bad free software / open source projects...as there are good and bad commercial projects.
From what I've seen, I'll trust open source as much or more in most cases...but I'll test it first.
Yep. I misconnected power to a floppy drive a few weeks ago, and *pop*, same thing. Easy to do on some drives; the power connectors aren't keyed!
Either way, here's a list to chew on;
Agreed. VMware does this, and I gladly gave them $$ for the product they made. No paper invoice, no packaging, all electronic. I heard about the product by word of mouth, tried the full-featured -- but time limited -- "demo", and just couldn't not give them money. :/
The company's package evolved from a spiral-ringed binder, to a slim plastic spiraled manual with a disk insert, to a small box, to a full-page sized box two inches thick.
Retailers *hated* the huge box...but we sold much more after changing formats. For one, you couldn't turn the box on it's edge. It begged to be placed face-out. It demanded more shelf space...the one thing the retail stores have a limited supply of.
We even tried sending out upgrades in a no-fuss package; disks plus manual in a slim carboard shipping box, but got complaints and a bad write up in a trade magazine. Because of that, we shipped the full box after that point.
One product was even targeted for sale at the register, so we scaled the package down below the size of a CD case. After getting next to no sales on that, we dumped minimal packaging attempts entirely.
In the end, we decided that a brochure-style box with a full-color description was necessary. It was a glossy, heavy, and cardboard re-inforced package -- even though the manual was only a little bigger and one more diskette was added.
The only environmental concessions we were able to get away with were vegtable dyes and no plastic except shrink wrap.
You'd be right if Sun were charging $40 for a single CD. But they're not, so you're wrong.
If you want "just the media", it's $10, as Sun offers just below the $40 CD+printed manual offer.
It looks like sun.com is having it's little . kicked.
/pub.
The obvious ftp site has nothing in
Anyone want to offer alternatives?
# All known email sent to the Good folder
/dev/null and the mail will be discarded. It's good to log Procmail transactions so that you can catch defects in your scripts more easily.
:0
* (^TO one@good.hk)
Good
# This dumps all the rest from *.hk into Spam
:0
* (^TO *.hk)
Spam
Adjust these as necessary. Once you're happy they are working, you can change the "Spam" folder to
Procmail scripts -- for the novice to the expert -- are in abundance at these sites (listed in order of importance);
http://www.ii.com/internet/robots/procmail
http://www.ling.helsinki.fi/~reriksso/procmail/m ini-faq.html
ftp://ftp.rubyriver.com/pub/jhardin/antispam/pro cmail-security.html
Procmail can be easily adapted to read a user-specific file. The file could be edited using a web page form to keep users from messing up the syntax. Procmail is easy to use, but will fail to process some or all of the script commands if the syntax isn't correct!
It's practical adopt a simple set of rules, easily created with a Procmail script, and use them as a general filter. Using a specific filter is just one form of security-through-obscurity and is easy to thwart.
1. All mail from known addresses is let through.
2. (optional) Mail from known senders is sent to a specific mail folder for that user (Business, Friends, Family, Natilie_Portman, ...).
3. All mail addressed to the user directly -- but not as a BCC list -- is sent through to the user's INBOX.
4. (optional) All remaining mail is sent to either /dev/null or a Probable_Spam mail folder.
Actually, adding more fans, but running them at a slower speed using resistors, would cut the noise and not cost too much more per machine.
It sure beats going to a high-priced ultra quiet power supply and expensive ($25+) fans.
I'm not talking about the costs of wasted power from hot CPUs, multiple 7200rpm drives, and 3D video cards...but the fans to cool them. In a new machinee, I have 5 fans costing a minimum of $30...and these are the cheap ones not the good quality (and quiet) PC-Power and Cooling equipment.
To cut the sound some, it would easily double or tripple the costs.
Someone please give him an extra point for the 404 message; it's a classic. I'm saving that just for future reference.
Mmmm...send them files in TeX format?
Seriously though, knowing what the person can read on the other end and sending them that is courtious. Unfortunately, too many people think that everyone uses what they do.
I'd tell you I was sorry for the mistake...but I checked them before I submitted the Ask /. a few weeks ago. Back then, they were valid and worked for me!
OK, but you tell Steve he's wrong...I know him, and there's no chance I'll do it.
You had to find three grey dots hidden in the walls of certian rooms. If you gathered all three together, you could walk through a special wall that lead to a room with the easter egg. If you didn't have the three dots, you'd just see another (empty) room.
I think the easter egg had the names of the programmers, but don't quote me on that.
Shortly after finding this, I proceeded to tourture the machine with a screwdriver...and "programmed" a few new games.
HP does have an incentive to go head-to-head with IBM by using thier minis to support virtual webservers -- at a mini-computer price, not a mainframe cost.
Yet, with the Intel+HP aliance merging the PA-RISC and I86 processors, HP might make more $$$ by focusing on retooled versions of Win2K to do the same thing. Sure, NT/2K isn't as portable as [insert favorite Unix variant], but with the CPUs being identical they could munge something together, make obnoxious money on reselling the Win licences, and still have hpux for other users.
...thanks for the info. So who did John Socha get his ideas from?
OK. {Shuffles through old software boxes} Thanks Peter Norton!
Yes, yes I do remember OS/2. Ever try and get an IBM-brand laptop or desktop computer with OS/2 pre-installed? Lots of them, right? Plenty of choice?
I wonder what's going to happen in 2038 when 32-bit time_t runs out...
It'll be a catastrophy! Worse then Y2K...well...er...ah...never mind.
"...and after all, in his old age, he can't kill too many more people...so why bother stopping him?"
...because unlike the book that was over 1,000 pages of redundant foot dragging, after only 2 hours the movie was over.
I wonder if I can upgrade those to Linux. Imagine a Beowulf cluster of toys screaming "Daddy!"
I could handle it...up to the point that they start calling me Dave.