I think the important issue is the degradation behavior as more traffic is added. Essentially, if you add 1% more traffic to a particular network route, it may overload it so much that the average speed drops by much more than 1% (say 10%). Thus, everyone would go faster if they didn't insist on trying (and therefore overloading) the fastest route.
To use a droll real-world example, consider the following:
You get given a new project on top of your two existing projects.
You spend some time on the new project, attend some meetings, etc.
You fall behind on the second project because you're doing some work on the third.
The second project manager schedules a meeting to find out why you're behind schedule.
You catch up on the second project, but fall behind on #1 and #3
The first and third project managers now schedule meetings to find out why you're late.
Soon, you have no time to do any work because you're busy explaining why you're so busy!
The article is suggesting that if some people used alternate routes, then the primary routes wouldn't get overloaded and therefore would get more done.
In our current project, we've achieved a reliability improvement of almost 2 orders of magnitude based on our XP methodology, and it's increasing every day.
It's actually difficult to track because the original project didn't monitor error rates particularly well. We do know that they had more than 1000 errors over 14000 "processing cycles" (a defined chunk of work.) Our current system has had 7 errors over 7000 "processing cycles".
The vast majority of these improvements come from Pair Programming and Test-Driven Development.
And - of course - we now have tests for those 7 errors!!!
(For those who care, a "processing cycle" has about 10 feature-points that are executed - so the original error rates are somewhere around 1% (pretty dang high) and ours is around.01%)
I wrote a test program to test this module. But then I remembered that I forgot to write a program to test the test module!
Actually, test-first development tackles this case specifically. You write the test first - which has to fail since you haven't written the code yet. (Technically, it even fails to compile. You then create stubs for the methods you call so that it compiles.) This is the state known as "Red". If the test passes when you first create it, you know that you have a bad test.
Once the test fails, you then write the code so that the test passes. This is the state known as "Green".
In practice, I do find that I occasionally write insufficient tests - which means that bugs get into the final product. But once a bug report comes back in and we find the problem, the first thing we do is write a test that fails (ie, back to the red state.) Then we fix the bug so that we move to the green state. And voila, we have a regression test for that particular bug.
(In the hope that you read replies to your own messages...)
Just curious - the description doesn't include anything about the cutoff device. What was the cutoff device and how did you trigger it from a program (ie, after you detect the presence of the/etc/cutoffdevice file)?
It's definitely not trivial - it's one of the reasons that people continually mention how to arrange office space to help XP.
We put the computers on a wide table in the center with enough space for two people to sit. When someone wants to switch, the other person slides to the side.
The other key element is to provide breath mints at every station.My personal belief is that pair programming is best done when there's enough space and breath mints for everyone involved.:)
For those who haven't read the judge's decision, it's definitely worth reading (as mentioned in another comment, it's online here. )
3) MS adds extensions for Windows only development, which are optional to developers depending on their target market (HINT: Apple has Cocoa extensions in Java......samething......they are optional)
Actually, the issue is that Microsoft was intentionally attempting to propagate a non-standard version of Java in order to kill it off. As emails from Microsoft state, their strategy was to:
"Kill cross-platform Java by grow[ing] the polluted Java
market." Microsoft, 253 F.3d at 76-77 (quoting Government Ex. 259).
The key issue is that Microsoft was deliberately trying to kill off Java using their OS monopoly to distribute a polluted version of Java and thereby fragment the Java market (as indicated by internal documents brought up in the court case.)
Have you ever walked around the fashion district in New York City? They throw out these cardboard tubes that make FABULOUS lightsabers. They're about 1.5 inches in diameter, but they're made of thick cardboard. And they're about 4 feet in length. They really stand up to a pounding.
Even though I'm now 33, I still can't walk by them without thinking "oohh... those would be cool!"
I entirely agree with Anonymous Brave Guy, that it's really tricky to get a real supervisor. But there is a way around it! Here's what I do when I get stuck and need a real supervisor.
1) If possible, get the name of the person you're talking with. 1) Hang up on the current person (politely or angrily, your choice.) 2) Make up a complaint/problem that can be easily resolved (ie, you want to check your mailing address, etc.) 3) Be very pleasant, and when the person helps you, say "You've been really great. You're such a change from the other people I've talked to. I really appreciate it. Do you have a supervisor or someone I can mention this to?" 4) You'll be transferred to a manager without fail.
Speaking from experience on both sides of the counter, the number one rule for "getting a refund" is to get angry. No venue wants an angry customer yelling in their lobby. On the other hand, quiet upset customers are perfectly acceptable. So don't be afraid to be loud and upset.
If I were in your shoes, I would 1) Show up at 11:30 PM - ignore the "12:00 midnight means noon" sign. 2) Get very loudly angry at the usher who says "there is no midnight showing." Start saying "I don't understand. I have tickets that say 12:00 midnight." 3) If the manager does not come over, ask the usher to get the manager. 4) Again, be loud and demand a refund. Say loudly things along the lines of "I have these tickets that say 12:00 AM. You're saying you don't have a film at this time. I want a refund for these worthless tickets." Be very upset. Refuse to be consoled.
I've used this technique when I've forgotten the credit card I used to purchase the tickets with. In both cases, the manager has told the usher to let me be seated.
The above solution worked at my company - except we needed to convert them to PDF so we sent them to a PDF-converting printer.
The trick is to set up a macro to print all the documents in a folder/whatever. The easiest way is the following:
1) Create a new word document. You have to store the Macro somewhere, and a word document is simplest. Call the document "ConvertDocumentsToText".
2) Add some instructions in the actual text of the document (Notice how you can combine the documentation with the code! ) Generally, the instructions include:
How do you start the macro
Where do the files need to be?
3) Start writing the macro. (Alas! I don't have my Word macro handy, so the best I can do is pseudo-code.):
Dim ofsFileSys as New FileSystemObject Dim theFolder as Folder Dim theFile as File Dim theDocument as Word.Document
set theFolder = ofsFileSys.getFolder("c:\mypath") for each theFile in theFolder.files
theDocument =open(theFile, _lots of parameters to the open call.)
theDocument.print
theDocument.close next
3) That's pretty much it.
4) Be careful with TWO issues:
Don't use background printing - use foreground printing. Otherwise the print function kicks off a background thread and you'll get thousands of documents open and the machine will grind to a halt.
Also, be careful with the parameters to the open command. We forced the open even if there were conversion questions (otherwise you get a dialog box that you have to click ).
According to the article, the scientist demonstrated that the laser could cut his hand without causing pain!
Heck, if they could make it cheap enough, that would be great in hospitals. Can you imagine if patients didn't need to be constantly pricked for blood?
(Based on the fact that I've been in this position before and chose the wrong path, I offer this advice.)
First, given the lack of IT resources, you should be extremely wary of switching to a new technology (such as Zope). When you leave in January, there's no guarantee that anyone will understand Zope and it's likely that it won't be stable (or scalable). You may leave the company in a worse position than it is now.
Instead, I would offer two alternatives that could leave you in a more stable position:
Remove/reduce all dynamic content - move to a static site. Focus on building a simple system that allows non-technical people to push to the website (for example, via a network shared drive.) Bear in mind that a lot of places call for "dynamic content" when they really mean "content that changes a lot".
If the administration kicks and screams about removing dynamic content, tell them it's the same as downsizing their staff. If they're broke, they can't afford dynamic content (as evidenced by the fact that they can't afford the people to maintain it).
If they still resist, I would recommend outsourcing the system rather than rewrite the thing. There are any number of companies that could build/host/maintain the system, and they'll probably do it cheaper than 1 full-time admin.
Now when you step on a land mine, you'll get stung as well!
-Peter
PERL, XP, and test-driven development
on
Ask Larry Wall
·
· Score: 4, Interesting
One of the big methodologies in vogue at the moment is eXtreme Programming and closely-related Test-driven Development (where you write your tests before writing your code.)
Considering that XP is a "high-discipline, low formality" methodology, how do you think XP and Perl fit together? How would you go about doing test-driven development in Perl? Is Perl a good language for XP?
The Highlift website suggests "Travelling at average speeds of anywhere from 120 km/h to 160 km/h, the length of a voyage to low Earth orbit might be as brief as four hours." Considering that here in NYC, we have people who commute 3 hours each day, we should consider anchoring one near Grand Central Station. I can just hear the talk:
"Yeah, well, we were looking at a place in Poughkeepsie, but then we realized the commute would only be about 30 minutes longer. Plus you should see our views!
Well, you've got a ready-made list of messages to filter *out* of your other mailboxes
This doesn't work because spam messages are not identical. That's the whole problem in a nutshell - how do you determine that one email matches another?
Spammers routinely change the wording/spacing/non-essential elements in a message so that they don't match exactly.
If you cut down to searching for "parts of a message", then you're back to "content-filtering".
the same thing occurs if you check for email address, etc.
Also, it's worth noting that BrightMail and other companies have been using "spam honeypots" for years. Their effectiveness isn't very good.
What is interesting, though, is that you could use this technique extremely powerfully with the Bayesian filter. Instead of writing a script for yourself, have the script automatically move the message into your "spam" corpus. You'll get your spam blocking up hugely without every having to see spam.
I've encountered this issue in a number of places, and have only been satisfied with homegrown systems. Here are some of the issues we've tackled (but entire books have been written on this topic.)
Requirements
First, here's my short list of requirements of a build/config system:
All config files must be under version control. Given a release of software, you must be able to find the appropriate config files for that release.
Config files MAY change when the software doesn't - this should still count as a release (ie, a release is not just 'when the developers have new code.')
Config files may vary depending on the environment (ie, stage, development, production, backup production.)
In an environment where you may have to rebuild machines (ie, WebServer1 just bit the toilet), you need to be able to build a new machine with the correct config file. Thus, your "build routine" for new machines needs to hook into the system.
You need some kind of script that can check the validity of a machine's configuration - (eg, run 'select 'x' from dual' against the database, read/write to the appropriate directories, check that you can connect to server X on port Y, etc.)
Some solutions:
Generally we've "rolled our own" because the good config packages cost a lot of money and still eat up a lot of resources to maintain them.
The Redhat Package approach
We build a package of all appropriate config files - one for each type of machine in each environment. The machine contains a "well-known file" which indicates which kind of machine and what type of environment it's in. The package checks to ensure that it's being installed on the appropriate type of machine.
Advantages:
the wrong config files can't get onto a machine.
You can use rpm commands to check if config files are installed.
Disadvantages:
It's a pain in the neck to write the build script.
There are a lot of tricky issues around how to write the Redhat package, ensure the deployment works, etc.
Centralized Perl 'Config Server'
In this approach, you write a centralized Perl server that keeps track of all config files. If you write it correctly, it can even be 'heirarchical' (ie, there are default config files, then webserver config files, and Webserver1 inherits all default config files and all webserver config files.)
Each machine then asks the Perl server for its config files.
The perl server ensures that config files are checked into CVS
Advantages:
One centralized location for config files.
the ability to determine which machines have which config files
Disadvantages
Someone has to write the Perl server- it took us about 3 months, but once it was done, it worked great.
1) As other people have mentioned, the biggest decision is which pay service to use in the first place. The wrong package will result in you:
implementing strong security on a system, which is difficult to do right
implementing a lot of customer service tools (to look up credit card numbers, issue refunds, track chargebacks, etc.)
generally spending more time than necessary in order to poorly implement something that another company has already done.
Remember, the billing services are the ones who should be figuring out how to store credit cards, be secure, etc.
3) Be sure to understand the Customer Service issue. It is quite reasonable to expect that Customer Service will ask to be able to "look at" Credit Card numbers, but consider carefully whether they need to see the Credit Card numbers or just search on the credit card numbers.
In my experience, you may end up spending more time writing the customer service interface than writing the customer interface - they may need to issue refunds to a card, they may need to investigate chargebacks (a BIG issue - especially with recurring charges.)
4) Avoid storing the credit cards if at all possible (but understand how you'll issue refunds and search for credit card numbers). As everyone states here, the security required in order to make this secure is easily weeks worth of effort. Again, picking the right payment service can eliminate this effort.
5) Remember, the client probably doesn't care about security enough to jeopardize payment - this is a clear case where the client probably wants his money more than he cares about preventing "potential attacks".
Slashdot Mirror
To use a droll real-world example, consider the following:
The article is suggesting that if some people used alternate routes, then the primary routes wouldn't get overloaded and therefore would get more done.
In our current project, we've achieved a reliability improvement of almost 2 orders of magnitude based on our XP methodology, and it's increasing every day.
.01%)
It's actually difficult to track because the original project didn't monitor error rates particularly well. We do know that they had more than 1000 errors over 14000 "processing cycles" (a defined chunk of work.) Our current system has had 7 errors over 7000 "processing cycles".
The vast majority of these improvements come from Pair Programming and Test-Driven Development.
And - of course - we now have tests for those 7 errors!!!
(For those who care, a "processing cycle" has about 10 feature-points that are executed - so the original error rates are somewhere around 1% (pretty dang high) and ours is around
Actually, test-first development tackles this case specifically. You write the test first - which has to fail since you haven't written the code yet. (Technically, it even fails to compile. You then create stubs for the methods you call so that it compiles.) This is the state known as "Red". If the test passes when you first create it, you know that you have a bad test.
Once the test fails, you then write the code so that the test passes. This is the state known as "Green".
In practice, I do find that I occasionally write insufficient tests - which means that bugs get into the final product. But once a bug report comes back in and we find the problem, the first thing we do is write a test that fails (ie, back to the red state.) Then we fix the bug so that we move to the green state. And voila, we have a regression test for that particular bug.
(In the hope that you read replies to your own messages...)
Just curious - the description doesn't include anything about the cutoff device. What was the cutoff device and how did you trigger it from a program (ie, after you detect the presence of the/etc/cutoffdevice file)?
-Peter
It's definitely not trivial - it's one of the reasons that people continually mention how to arrange office space to help XP.
:)
We put the computers on a wide table in the center with enough space for two people to sit. When someone wants to switch, the other person slides to the side.
The other key element is to provide breath mints at every station.My personal belief is that pair programming is best done when there's enough space and breath mints for everyone involved.
Actually, the issue is that Microsoft was intentionally attempting to propagate a non-standard version of Java in order to kill it off. As emails from Microsoft state, their strategy was to:
The key issue is that Microsoft was deliberately trying to kill off Java using their OS monopoly to distribute a polluted version of Java and thereby fragment the Java market (as indicated by internal documents brought up in the court case.)
You know, the World Weekly News has been writing about brain transplants ("Elvis alive but in different body!") for years.
So all we have to do is get those reputable scientists to talk to the guy in Italy and we'd have a cure for brain cancer!
You can read up on brain transplants here.
Have you ever walked around the fashion district in New York City? They throw out these cardboard tubes that make FABULOUS lightsabers. They're about 1.5 inches in diameter, but they're made of thick cardboard. And they're about 4 feet in length. They really stand up to a pounding.
Even though I'm now 33, I still can't walk by them without thinking "oohh... those would be cool!"
-Peter
I entirely agree with Anonymous Brave Guy, that it's really tricky to get a real supervisor. But there is a way around it! Here's what I do when I get stuck and need a real supervisor.
1) If possible, get the name of the person you're talking with.
1) Hang up on the current person (politely or angrily, your choice.)
2) Make up a complaint/problem that can be easily resolved (ie, you want to check your mailing address, etc.)
3) Be very pleasant, and when the person helps you, say "You've been really great. You're such a change from the other people I've talked to. I really appreciate it. Do you have a supervisor or someone I can mention this to?"
4) You'll be transferred to a manager without fail.
Very interesting and tempting!
How do you get work visas in other countries such as Scotland and Australia?
I always thought that was a substantial issue in moving outside the US.
Speaking from experience on both sides of the counter, the number one rule for "getting a refund" is to get angry. No venue wants an angry customer yelling in their lobby. On the other hand, quiet upset customers are perfectly acceptable. So don't be afraid to be loud and upset.
If I were in your shoes, I would
1) Show up at 11:30 PM - ignore the "12:00 midnight means noon" sign.
2) Get very loudly angry at the usher who says "there is no midnight showing." Start saying "I don't understand. I have tickets that say 12:00 midnight."
3) If the manager does not come over, ask the usher to get the manager.
4) Again, be loud and demand a refund. Say loudly things along the lines of "I have these tickets that say 12:00 AM. You're saying you don't have a film at this time. I want a refund for these worthless tickets." Be very upset. Refuse to be consoled.
I've used this technique when I've forgotten the credit card I used to purchase the tickets with. In both cases, the manager has told the usher to let me be seated.
The above solution worked at my company - except we needed to convert them to PDF so we sent them to a PDF-converting printer.
The trick is to set up a macro to print all the documents in a folder/whatever. The easiest way is the following:
1) Create a new word document. You have to store the Macro somewhere, and a word document is simplest. Call the document "ConvertDocumentsToText".
2) Add some instructions in the actual text of the document (Notice how you can combine the documentation with the code! ) Generally, the instructions include:
How do you start the macro
Where do the files need to be?
3) Start writing the macro. (Alas! I don't have my Word macro handy, so the best I can do is pseudo-code.):
Dim ofsFileSys as New FileSystemObject
Dim theFolder as Folder
Dim theFile as File
Dim theDocument as Word.Document
set theFolder = ofsFileSys.getFolder("c:\mypath")
for each theFile in theFolder.files
theDocument =open(theFile, _lots of parameters to the open call.)
theDocument.print
theDocument.close
next
3) That's pretty much it.
4) Be careful with TWO issues:
Don't use background printing - use foreground printing. Otherwise the print function kicks off a background thread and you'll get thousands of documents open and the machine will grind to a halt.
Also, be careful with the parameters to the open command. We forced the open even if there were conversion questions (otherwise you get a dialog box that you have to click ).
-Peter
According to the article, the scientist demonstrated that the laser could cut his hand without causing pain!
Heck, if they could make it cheap enough, that would be great in hospitals. Can you imagine if patients didn't need to be constantly pricked for blood?
-Peter
(Based on the fact that I've been in this position before and chose the wrong path, I offer this advice.)
First, given the lack of IT resources, you should be extremely wary of switching to a new technology (such as Zope). When you leave in January, there's no guarantee that anyone will understand Zope and it's likely that it won't be stable (or scalable). You may leave the company in a worse position than it is now.
Instead, I would offer two alternatives that could leave you in a more stable position:
Hope this helps.
-Peter
Oh great!
Now when you step on a land mine, you'll get stung as well!
-Peter
One of the big methodologies in vogue at the moment is eXtreme Programming and closely-related Test-driven Development (where you write your tests before writing your code.)
Considering that XP is a "high-discipline, low formality" methodology, how do you think XP and Perl fit together? How would you go about doing test-driven development in Perl? Is Perl a good language for XP?
-Peter
The Highlift website suggests "Travelling at average speeds of anywhere from 120 km/h to 160 km/h, the length of a voyage to low Earth orbit might be as brief as four hours." Considering that here in NYC, we have people who commute 3 hours each day, we should consider anchoring one near Grand Central Station. I can just hear the talk:
This doesn't work because spam messages are not identical. That's the whole problem in a nutshell - how do you determine that one email matches another?
Also, it's worth noting that BrightMail and other companies have been using "spam honeypots" for years. Their effectiveness isn't very good.
What is interesting, though, is that you could use this technique extremely powerfully with the Bayesian filter. Instead of writing a script for yourself, have the script automatically move the message into your "spam" corpus. You'll get your spam blocking up hugely without every having to see spam.
As far as books go, you can check out A Guide to Software Configuration Management (Artech House Computer Library) as a reasonable book on the concepts and issues around CM.
There are at least two lists on Amazon of books on this issue: here's one
And of course, Google has a whole directory on configuration management.
HTH -PeterI've encountered this issue in a number of places, and have only been satisfied with homegrown systems. Here are some of the issues we've tackled (but entire books have been written on this topic.)
RequirementsFirst, here's my short list of requirements of a build/config system:
Some solutions:
Generally we've "rolled our own" because the good config packages cost a lot of money and still eat up a lot of resources to maintain them.
The Redhat Package approach We build a package of all appropriate config files - one for each type of machine in each environment. The machine contains a "well-known file" which indicates which kind of machine and what type of environment it's in. The package checks to ensure that it's being installed on the appropriate type of machine.Advantages:
Disadvantages:
- It's a pain in the neck to write the build script.
- There are a lot of tricky issues around how to write the Redhat package, ensure the deployment works, etc.
Centralized Perl 'Config Server'In this approach, you write a centralized Perl server that keeps track of all config files. If you write it correctly, it can even be 'heirarchical' (ie, there are default config files, then webserver config files, and Webserver1 inherits all default config files and all webserver config files.)
Each machine then asks the Perl server for its config files.
The perl server ensures that config files are checked into CVS
Advantages:
Disadvantages
A decent pool cue can cost about $125 - get a two-piece cue with a metal joint, nothing fancy, and a simple case.
Then get her Byron's Book of (on?) Billiards and Pool. A great book to describe how to play the game.
Guaranteed to help any college student wonder whether the main purpose of college is studying.
-Peter
Don't you remember? That's where we buried the radioactive waste the first time!
Personally, I always thought turtles preferred Pilsner - but it is a COOL solution to the "how do I keep enough beer in the apartment" problem.
implementing strong security on a system, which is difficult to do right
implementing a lot of customer service tools (to look up credit card numbers, issue refunds, track chargebacks, etc.)
generally spending more time than necessary in order to poorly implement something that another company has already done. Remember, the billing services are the ones who should be figuring out how to store credit cards, be secure, etc.
2) The place to look for payment systems is: here
3) Be sure to understand the Customer Service issue. It is quite reasonable to expect that Customer Service will ask to be able to "look at" Credit Card numbers, but consider carefully whether they need to see the Credit Card numbers or just search on the credit card numbers.
In my experience, you may end up spending more time writing the customer service interface than writing the customer interface - they may need to issue refunds to a card, they may need to investigate chargebacks (a BIG issue - especially with recurring charges.)
4) Avoid storing the credit cards if at all possible (but understand how you'll issue refunds and search for credit card numbers). As everyone states here, the security required in order to make this secure is easily weeks worth of effort. Again, picking the right payment service can eliminate this effort.
5) Remember, the client probably doesn't care about security enough to jeopardize payment - this is a clear case where the client probably wants his money more than he cares about preventing "potential attacks".
Right! Use the supposed "Space telescope" to prove that the "Moon landing" was real...like we'd believe that you have a telescope in space!
:)
Will the conspiracy never end?