All the Perl that's Practical to Extract and Report
use Perl Log In
VSarkiss (704)
(email not shown publicly)
Yahoo! ID: vah3sark (Add User, Send Message)
I haven't really taken the time to set this up, but you can look at my home node [perlmonks.org] on Perl Monks.
Designing in a vacuum
Yesterday my client, a major metropolitan newspaper, told me they'd like to get an overall architecture designed for the ETL piece of the data warehouse I'm working on. (ETL stands for Extract, Transform, Load: it's how you get data into a warehouse.) So I wrote up a very general diagram and algorithm, and pointed out I really couldn't go any further: They've told me hardly anything about the source systems, and I've never worked in the newspaper business before. But I was told I need to finish up the document.
Well, now I'm writing up all possible ways of loading data. It's general enough to be a "HOWTO of data warehousing". Maybe I'll contact O'Reilly later to see if I can turn it into a book....
A hint for all the managers: you can't design something without knowing what it's supposed to do. It's usually called "requirements".
Clients, gotta love 'em.
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Ignorance can be bliss (Score:2)
I was in a roughly similar situation once where I was tasked with creating a program to summarize data in a system and dump the output for another process to grab, but I knew nothing about the systems involved. In this case, my ignorance paid off. I went to my boss and asked him what I should do. He had me make appointments with everyone involved and find out what their systems did, how they did them, what data formats they used, et cetera.
It was a long process, but eventually I wound up with a specs d
Re:Ignorance can be bliss (Score:1)
Humility pays off.