Skip to main content

objects , abstractions, symmetry and pop corn???

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.


Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

Live Coding Exercises: How NOT to hire potentially Brilliant Engineers.

I've intimated this view before but, I abhor "live coding" exercises for engineering interviews and will never have them as part of any interview process I conduct. They are simply unrealistic to real world engineering in every possible way, they only test familiarity (or luck) with a tiny subset of solution methods to a specif subset of problems...that you either "nail" or get spectacularly wrong depending on who is observing you.

They are mostly entirely unfair to the candidate on top of the pressure of having a gun under them while coding, only in the most extreme cases is coding under the gun and that's just competitions where the code is far from real world engineering why test for general coding ability with such tests?? Stupid.

I posit, it is significantly more effective to see examples of a candidates finished working code in the form of a project or projects they've created. How long it took some one to get some uber algorithm work…