Data::Maker - Simple, flexibile and extensible generation of realistic data

Data::Maker does not know why kind of data you need, but it will help you make lots of it.

And if you happen to need one of the various types of data that is available as predefined field types, it can be made even easier.

The big difference between Data::Maker and modules you may have seen before is that Data::Maker is specifically designed to make it easy for you to generate realistic random data.

ROADMAP

• Some type of "Person" class that would automatically `use` all of the Person subclasses and generate all fields related to one Person while taking into account other fields of the same person (if that makes sense)
• Data::Maker::Field::Company: to generate realistic, but not necessarily real, company names, based on multiple word lists
• Data::Maker::Field::Address::Street: to generate realistic street names, based on multiple word lists
• Data::Maker::Field::PhoneNumber: to generate realistic phone numbers, preferably for multiple locales
• I wonder why most of the code needed by the Format class is in Data::Maker::Field? I need to answer that question of fix the problem.
• I also wonder why I made the decision to make fields() take a list of hashrefs instead of list of blessed Field objects. I'm pretty sure my first stab at this took blessed objects and there was some reason that I went to this. But I'm sure somebody will eventually ask the question, so I would like to know the answer. This is something I should maybe get to the bottom of.
• There is likely some usefulness in the ability to have Data::Maker generate something other than perfectly-clean data. A defined amount (or a random amount) of dirty or incomplete data is something that might make some sense, for the purpose of testing scripts whose job is to identify bad data.
• I would like to make Data::Maker::Field::Person a separate distribution, particularly because of the Gender class's dependency on Text::GenderFromName. I think a reasonable rule of thumb about what to include as a built-in field and what to make a separate package is any field class that has an external CPAN dependency. For example, Data::Maker::Field::Currency is a perfectly-valid built-in class, but when I decided to outsource the work to Data::Money and its dependencies, I had to either commit all Data::Maker users to currency dependencies or commit myself to maintaining a separate distribution (and inconveniencing Data::Maker users who want to use the Currency field by making them download a seperate distribution). Obviously there's a lot of philosophy involved here.
• Using that same rule of thumb, Data::Maker::Field::DateTime should also be a separate distribution.