I started the implementation of the very last impromptu addition to the features planned for the framework. I have been mulling the day on various aspects of the implementation for the optimal and most efficient approach, as is usually the case I found myself debating issues that might seem insignificant at first blush but upon deeper reflection reveal themselves as important points.
Case in point is how I will design the guest pm dashboard, of course before I can explain the problem that needed solving , some back ground. The framework has a built in collaboration API, within the design of the framework "API" has a different practical use from how it is defined by the acronym of the words "application programming interface", in the framework new classes are incorporated or assimilated into the foundations of a common base class. The software engineers among you realize that the hallmark of efficient OO programming is programming that employs the full tools of object orientation provided by a developers chosen language. My framework , has the core OO language of java as its foundation and the use of deep OO concepts like abstract base classes, polymorphism and encapsulation were key concepts that I had to master in order to ensure that the best (in my view) solution to the over all problem of "how do I reduce the code size that will be written by a client programmer in the future by designing the base class objects efficiently now?" Luckily for me, the concepts of object orientation are not new at all, in fact I have visited them in various ways in various areas of my life.
As a young child I spent a great deal of time with pencil and paper in hand, the reason was that I had an insatiable desire to draw what I saw. From the moment that I could hold a writing tool I was drawing, I noticed that I had an ability to render images a bit more accurately than my brothers and sisters and peers. I fed my desire to learn by reading comic books , I marveled at the lines and technique used by my favorite artists as a high school student. I was in love with MC Escher's geometrics and tessellations, I was in awe by the rendering of human and animal tone by Boris Vajello , Frank Frazetta and I was blown away by the effortless American reality expressed by Norman Rockwell. As I got deeper into comic book drawing I mixed the influences of these modern illustrators into my own style.
In my early college days I bought books on anatomy and composition to formerly learn the techniques of illustration and this is where OO was introduced full force. The evolution of a drawing proceeds very much like the solving of an OO programming problem. A problem is identified, aspects of the problem are mapped or abstracted to objects that describe the entity and its attributes (loosely, how it interacts with other entities) the mapping or abstracting stage to me is the most important , as it is here that the full mental introduction is made to the variables that must be manipulated to solve the over all problem. Knowing the objects in short, ensures development of efficient solution since the act of "knowing" involves understanding how those objects "fit" conceptually with one another by their attributes. In drawing the same thing is done, accept where in OO programming the objects are classes with attribute lists and return types, encapsulation keywords or scope specifiers in drawing the objects are the conceptualization of physical items, length, breadth , depth, curvature. No surprise that the principle method employed for learning to draw human figures , for example is rote memorization and drawing of human anatomy. The first task is to know the objects just as it is in OO programming, except in this case "to know" means to understand how a particular physical object will appear from various directions of view or under given modes of light. Once abstraction has been done, the bulk of the solution to the problem is already in place, the rest is simply what I like to call the popcorn, the implementation follows from simply putting the objects with known parameters and attributes together in the ways that they can, their "shape" constrains the final construction...just as the varied shapes of lego blocks constrain the types of objects that can be built from them.
In a drawing , the 'popcorn' involves rendering the objects (appendages, pelvis , thorax, head) according to the constraints of perspective on their "shape" as viewed from a particular vantage point. To people that don't draw this looks like magic, but it is nothing of the sort, it is the application of the vast database of point of view drawings that were done by any diligent illustrator during their "learning" stages. Obviously , once committed to memory the act of recalling these perspectives seems wondrous but it is simply a book keeping task, or rather a book reading task of going to memory, finding the view of an object (head, limb, torso..etc.) based on a desired perspective and then rendering it in place. As one gains facility with this task the act is no longer conscious in fact it becomes refined to the point that a given object can be manipulated in the mind. Objects that have various axis of symmetry can be exploited to rotate, translate or dilate them without having to recall a template, since most objects in the real world have at least one axis of symmetry this allows a great reduction in the number of memory references required and allows even more facile rendering of objects, eventually the skill is refined to the point that the object rendering is first preceded by a symmetry finding step which then allows dynamic manipulation in the mind prior to rendering, this is how entirely new views (which might have never before been rendered to paper in practice or otherwise) can be synthesized on the fly. In this way a new and unique drawing can result .
You are probably still wondering how this is similar to programming, the answer is in that great word abstraction; The object models for the shape of appendages, limbs or other animal body parts come from a collection of experiences of those shapes through previous practice coupled with a real time hunt for symmetries in the objects as viewed in the desired rendering. This is precisely analogous to the view of a solution for a given software problem, replace the physical objects by conceptual ones in the problem space with attributes and return types and you have in essence the same building blocks, the view of the final solution involves understanding the symmetries (again) of the objects and using them to efficiently construct the solution.
This takes me back to the problem I solved today, the issue revolves around providing a guest private message ability to the framework. All conversations have a type attribute, currently there are 3 types , private messages (IM), private conferences , and public conferences adding the private guest option might seem to necessitate a new conversation type. However each true conversation requires a row in a corresponding table to persist the conversation attributes. I wanted to allow Guests to engage a conversation without creating new conversations for each remote guest request which would be resource exhaustive. How to solve ? Rather than actually manage the guest conversation I decided to simply use an existing conversation as a mask or proxy, since all guest conversations are initiated by the remote guest only they have a unique symmetry from the perspective of the collaboration API from all other conversation types. If I associate this symmetry(the unique IP of the remote request) with the guest pm request I can denude the proxy conversation, repopulate its attributes with the unique guest attributes and then allow for designated users to engage the incoming guest requests. This solution to the problem would not have been obvious had I not recognized in a visual sense the symmetry of the guest conversation request when compared to the User requests.
Tomorrow I will continue with the implementation of this solution, I have to resolve the fine details but again that is just the dry pop corn, a little butter and salt brings the fun.
Comments