My previous company built audioconferencing equipment, and, as toolsmith for the SQA group, I had written programs to automatically schedule large numbers of audioconferences, both to test the scheduling APIs, and to setup overnight stress tests of the audioconferencing equipment.

When the company decided to move away from its flat-file database system to using Informix and SQL, I knew these tools would have to be rewritten to schedule conferences using the new database.  Furthermore, a colleage and friend of mine was facing the onerous task of having to write a testplan for the quality-assurance of the new database, and, as he and I both had never done any SQL programming, he wasn't sure where to begin.

So I created a set of database interface scripts in Perl, as well as a couple of common modules, as an easy way of organizing reusable sets of data, so that we could create hundreds of thousands of conferences on-the-fly, for testing both the perfomance of the new database, and the audioconferencing bridge itself.  A number of the scripts would pipe data between themselves; for example, the script that stored conferencing parameters in "bulk-load" format had to pipe its data to the script which called the stored procedures for actually loading that data into the database.

Even the consultant whom we had hired to design the schema for the new database was impressed with how quickly Perl allowed new sets of functionality to be folded into the test environment.  The project, which had started as a simple way of helping me do my job (and helping my colleage get a handle on how to design his testplans) ended up becoming a major project, an informal product for use by a number of customers, and an integral part of the SQA group's suite of tools.

---

s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/