2011/03/24

Is There An "App" For That?

So, I've been developing a workflow for quite some time. I have SQL tables feeding data into Perl-generated web sites and JSON feeds feeding AJAX pages using jQuery, and if I think about it, I could probably feed two or three more technology buzzwords into there, too. CSS, for sure.

A big problem is that, as I proceeded, I had no idea what I was doing for a lot of it. What I know about writing Perl modules, I know due to this workflow. Well, I knew "start with Package and end with 1 ;", but beyond that, not a whole lot. The web has helped this process a lot, and now I'm not too ashamed at what I have.

(Object orientation. Moose. It could use improvement and I would learn from the experience. But that isn't today's topic.)

So, by and large, I have modules handling the SQL queries, then passing hashes or hashrefs, depending on what I want. But, as I said, I was figuring out what I'm doing as I go along. I'd get the problem, think "I need these tables", write modules to interface with the tables, write programs that use the modules, fail to write tests for the modules because what tests I could imagine are either trivially stupid or highly dependent on the state of the database (I have Perl Testing on my desk and have worked through the first two chapters, so I know it's a failing, but see the note on object orientation.)

In a practical sense, if I'm dealing with a foo, I will have a table foo and maybe foo_attributes connecting with it. Then I'd write the module Foo.pm with create_foo, update_foo, delete_foo, read_foo and get_foo_list for a list of all the foos in the table. I can tell which tables I'm dealing with from the function name, for the most part. When it gets to the interaction of foos, bars and blees, it gets hairy, but that's why I get paid the big bucks, right?

Right now, I'm looking to document the schema and DROP TABLE cruft before adding a few more features, which means what I'd like to do is look through my code base for all the modules I'm responsible for, search for all the functions I'm calling in each, and give me a list that might look something like this:
  • list_foo.cgi
    • VarLogRant::Foo
      • get_foo_list
      • read_foo
Now, I have a naive text-parsing concept of how I could do this, but honestly, I can't imagine that I'm the first person who would want something like this, and I know that the Perl community loves to build tools for building tools, so is there something I should be looking at before I dive into this myself?
Post a Comment