perlmeditation
princepawn
Welcome to the other side of the open source coin.
<p>As many of you know, I threw Oracle to the curb recently because I
felt
they were not using Perl as a community language and thus were not
leveraging open source code and collective mindshare. The advantages
of Open Source are obvious -- 10,000 people using something as
opposed to 10 or 100. Many people encountering and fixing problems
before you hit them. Forcing you to see your problems as not
completely unique, but simply having a few differences in how a
general module/package is configured/instantiated/scripted.</p>
<p>So Open Source starts to be the big end-all and do-all for me. So
much so that I leave a place of such high repute in a huff given this
completely depressed job market. Now for the other side of the
coin</p>
<p>All of this started about 3 days ago when Dave Rolsky did the thing
we open source people see as so important: extracting tidbits of
"branded" functionality as a more generic module for re-use in other
circumstances. So, I took a look at the modules he had up for
re-architecture and settled on the Alzabo::ObjectCache::* part of
[cpan://Alzabo] as something to decouple from Alzabo for usage
anywhere that someone needed a synchronizing object cache with
numerous backends for storage of the memory and disk kind.</p>
<p>So, I get going on this and lo and behold, he is making use of that
cool module of his [cpan://Exception::Class]. So I think, "hmm, since
this is a general module, should I force them to use his exception module?
There are a few choices here: (1) force them to use Exception::Class
(2) just remove all of his [cpan://Exception::Class] code and replace
it with <code>die</code> (3) redo exception class so that it is just
another set of hooks that may be thrown when a standard die or warn is
called and then die throughout the code, but put in hooks so that if
[cpan://Exception::Class] is in <code>%INC</code> then it sets of
<code>SIG{__DIE__} and SIG{__WARN__} </code> to use them. And it is choice number 3 that get's up hippied out, organic, Open Sourcey type of people in trouble. There's more than one way to do it. Everyway should be supported. Democracy. Peace. Love. You can have it your way, I can have it mine. Either way is fine.....</p>
<p>So this whole project goes on hold for a bit as I start to write up
the docs for it, because I am going to write up a document on how it
is useful. So the document is going to be called "ObjectCache: a
flexible caching and synchronizing layer for development of business
application layers, separating business operations from technical
(database) manipulations". So that's all cool and I start to code up
my business objects, then I realize that the business objects should
actually be able to work with the database by calling queires by label
and passing them "business arguments" and <b>no</b> database-ish code
should be present in their layer..
</p>
Enter [cpan://SQL::Catalog]. What is SQL::Catalog? Well, SQL::Catalog
is the class that I created to make, label, and catalog queries so
that they are on disk and completely separate from your Perl code? Why
is this important? Why , so that the database experts can work on SQL
queries while you work on business logic. And so that each query can
be individually unit-tested and then , YES, then, themselves stored in
a database so that when that time comes and someone else needs to find
a query, they can query for a query and so that when the boss says
"how many queries are hitting table such-and-such, you can query for a
table."
<p>Do I seem to chasing my own tail? Oh, it's not over yet.. because
guess what? It turns out the second you think of making a SQL::Catalog
you have to ask, well what if 30 parallel proceses all want the same
query from the catalog? Oh, then its obvious! Use the new ObjectCache
to serve queries from one of the memory stores instead of hitting the
database... but wait! This all started because you were going to
document ObjectCache!!! I know but I need ObjectCache to correctly and
properly server queries for the SQL::Catalog which are serving data
for the database and storage-agnostic business layer...</p>
<P>Oh and [cpan://SQL::Catalog]? That has to be open to use with any database. Which means that in terms of schema creation we have to use the db-independent [cpan://DBIx::Renderer] and for SQL queries we have to use [cpan://DBIx::Recordset].
<p>So the problem with open source is: you are far too open!
You spend too much time creating hooks and callbacks and wrappers and mappers and open
frameworks with no preconceptions as to order of execution or package
of implementation and you never come to full circle on a damned
thing.
<P>I almost feel like tucking my tail in and running back to Corporate
America for that fat paycheck. For the copy-and-paste software re-use
practice. for the <i>do it now like i said. I dont' care what Bertrand Meyer or Grady Booch or any other over-decoupled, overly academic, overly intellectual person said. we have a deadline and that better work even if it will never make into "Programming Perls"</I>
<P>
for the opposing viewpoint visit
[id://114715|This node]
<p>
<font size="small"><strong>Edit</strong> [kudra],
2001-10-25
Changed link to [] syntax</font>
</p>