Python ICE | A "Full" Python In CABOOSE Prototype [ Just Below The Surface ]

Not a ZeroC Production

Team. Hopefully, the Gang's all here. This deliverable date has long since passed by. The realization of the "fifth" phase of this multilingual project is extremely overdue. It initially was scheduled for November 15, 2020. With the completion of the final phase projected near this time or mid-January 2021. 

Seeing that this architectural software pattern will not be woven in each of the fourteen languages chosen by then, one of the "simpler" implementations was chosen as a "deliverable" concession and completed "proof of concept". The implementation language was Guido von Rossum's Python. 

Since this past year has offered the author teaching opportunities in computer programming fundamentals, in particular, Python, he knew that "finalizing" the vision of a general-purpose controller which supported dynamic invocation would be quite simple in that language. 

So, he set aside a "vacation day" before the Winter holidays in America and spun the product. Between running errands and three meetings, including an academic interview, he found time for it on a Friday. It was about 4.0 person hours (PH) worth of effort. It is nearly a (0.5) KLOC coding effort with some repeated segments of code and ample comments, not including the generated "icemode.py" file which is produced by "icy.py" and of varying length. 

It includes a "simple-minded" and "non-optimal" code-generator that renders a "hard-coded" version of the logic file with a batch file called "iceman.bat". 

The primary script "caboose.py" will run using dynamic invocation for activating behaviors described in the CABOOSE logic file if the ICEMODE global in it is assigned a value of "False". If it is given a value of "True", then the script uses hard-coded logic in the "icemode.py" file generated by "iceman.bat" and ultimately "icy.py". 

It goes without saying that a Python 3 hybrid-interpreter must be installed and part of your system's PATH variable before this can run from the command prompt. 

Python ICE for Windows development is available on online. This is not the product from https://zeroc.com/products/ice with a similar moniker. That product is a framework for "microservices" based upon remote procedure call (RPC) and is architected and coded much like Oracle's Ozark controller product. This is called ICE for a different bi-fold reason. Firstly, ICE is an acronym for In CaboosE. 

CABOOSE is a very simple pattern for a controller which one can "spin" himself using a number of languages in a day or so each. Secondly, this product uses an architectural control file (ACL) whose mapping between page concerns and those methods which satisfies them can be "iced" or "frozen" in a programmatic "switching" structure for static invocation versus the default dynamic invocation. It is more of a "template-driven" system with a model of the view in a storyboard and behaviors that render each view in a "cab.py" file. 

Unlike ZeroC's product, this product version is not object-oriented, although it could be. 

And like the JAVA in CABOOSE project which integrates well with Oracle's Ozark, this ICE product likely will mate up well with ZeroC's ICE project. But, that is intuition with the different ICEs and not experience talking. 

And, it just so happens that the JAVA in CABOOSE project was considered by Oracle's JAVA Community Process (JCP) for adoption a full-year before the development of Ozark after it was pitched as a potential JAVA Specification Request (JSR). It was determined that Oracle had enough "view technologies" with servlets and JAVA Server Pages (JSP).

So, please do not get caught up in labels. These are different types of ICE, like "nilak" and "siku" for the Inuktitut of the Alaskan coastline. Certainly there is more than one Bill Joy, James Gosling, Mary Fitzsimmons, and Tom Johnson in this world. And, it is the case that more things in this life than Irishmen come with the same name. But, if one looks closely, they can easily see the differences between the products with the same "name".

This prototype of the controller runs from the command line, but can be easily adapted for "web-use". It can be invoked from the DOS prompt with "run [view_name]". Three templated HTML views exist in the StoryBoard model: home, landing, and error.

So, for instance, if one types "run home" at the prompt, then the populated HTML template for the homepage prints on the terminal. If one types "run foobar", then the error page prints since foobar is not a registered view in the CABOOSE logic file, directory.scsv. 

The HTML view templates are populated by functions found in "cab.py". This Python script must be created and customized for each Python ICE (Python In CABOOSE) application which one creates. If a non-existent view is requested, then the error view is returned as was the case with "foobar".

The CABOOSE Logic file "directory.scsv" unites all of this. It drive "caboose.py" which does not need modification, outside of the ICEMODE global which might be best housed in a the "cab.py" file.

A similar, yet not fully ICE'd version for JAVA is described in JAVA in CABOOSE by Abraham Vati James found on Amazon. This only is one of the pennames under which this author has worked in past years. Take it, tweak it, turn some web gears with it. It is under a MIT License for Open Source.

Hopefully, this shows how simple spinning and weaving the tapestry of a modern general-purpose controller is. It is the author's goal that he provide implementations in the other programming dialects of this multilingual project within a few month. PHP and PERL for the LAMP stack should be an easy task such a Python. This ease of development is driven by each of their individual mechanisms for dynamic invocation. Also, the Node.js and Typescript implementations each permit use of a function for statement evaluation. 

This greatly simplifies dynamic invocation in comparison with JAVA's Reflection tools and function pointers in C/C++. And, these tasks in C#, Rust, Clojure, Groovy, and Ruby will be a "new" undertaking for the author. But, this should not be an impossible task.

Upon taking his first computer fundamentals course at Vanderbilt during the Spring of 1989, he wondered about controllers in a model-view-controller architecture and whether a general-purpose one could be built with a means of "programming it" with a secondary "architectural control language".

This is what is found in the sectioned comma separated values (*.scsv) file which holds the CABOOSE logic.

The realization of this "trivial" project arises from the culmination of many years of learning and work. And, it should be said that such a revelation was quite novel at the time when print SPOOLing was new and revolutionary. In some ways, its time has passed; in others, it has not.

This could be a means of creating the "old" text-based and menu-driven command-line interface systems from which the author first harvested the abstractions of layered and model-view-controller architectures. Based upon his training in Pascal, he wondered if he could generate the "switch-case" or "if-then-else" ladder needed for logical processing of such a controller-based system. But, he knew little about lexical analyzers, interpreters, compilers, or code generators, at the time, other than what they did. He was far from understanding parse trees and the likes of grammars. These concepts still are not his strong points, seeing that he never took a course in compiler construction. In many ways, this might be considered a "kludge".

Yet, over the years, before the advent of markup languages and eXtensible Markup Language (XML) processors, work on mainframes with "on-lines" and a bespoke in-house system called integrated scripting produced by Jack Sprouse, a knowledge of International Business Machine's Customer Information Control System (CICS), and undergraduate study suggested that such a system with a "simple-minded" code generation step driven by a architectural control language (ACL) would be worthwhile. Life's circumstances did not allow for its production until now. 

But, the author kept it simple (KIS), plus he used the bird-foraging technique (hunting, pecking, and thinking) along with copying and pasting lines of code. And, Python ICE is likely the first nearly "full" rendering of this vision. It is a extremely simple "cold fusion" of sorts, since it connects view technology standards (markup) and a popular high-level language (Python) with some elements of fourth generation languages (code generators). 

It is a mezzanine generation for languages in this fifth generation, those running atop machine emulators, such as Python and JAVA. Using a mixture of declarative markup and imperative or functional languages, it is a generation 3 1/2 system when integrated with a third-generation language such as C/C++ and a 5 1/2 when combined with a modern fifth generation virtual machine dialect.

Occasionally, limitations on what one knows helps him develop simpler solutions. At times, one can "overthink" what he is doing and build a duplicate of Dr. Who's Tardis when all one needs in a Ruby Pearl Tercel DX or, better yet, a push cart.

The construction of an ICE system virtually permits for the abstraction of the C, controller, out of the MVC processing equation. So, ultimately, we now have a (model-view) MV architecture which is "best" described as (view-model) VM based upon the top-down layering. 

This, when run atop a virtual machine, produces a VM * VM system which experiences a magnification of its combined power and desirable engineering traits as emergent behaviors arise. And thus, one might call it a "VM-squared" or , basically s "VM^2", architecture.

The author fully knows that VM-squared or the equivalent VM-MV systems have been defined as something different in past years. Yet, it is quite true that few know where the anacronyms originated. It was in the author's college-ruled red Mead notebook which was originally purposed for his ENGL104W Prose Fiction course taught by Robert Bacon at Vanderbilt University during the Spring of 1989. 

Yet, it is oft said that “Truth is stranger than fiction, but it is because fiction is obliged to stick to possibilities; Truth isn't.” ― Mark Twain, Following the Equator: A Journey Around the World.

 And, although this misuse of personal academic notes was a violation of Vanderbilt's Honor Code, the  convolution of Flannery O'Connor's words in the phrase "everything which converges must rise." brings much comfort in this world of "360-degree" good fortune. 

"What goes around comes back around again..." - Grand Puba

The Iceman Cometh | Summary of Project Vision - Its Ultimate Goal

Team. The purpose of this project is spinning a "general-purpose" controller in fourteen different languages. This meets the goals of this "Google-based" web history, providing a modern "Rosetta Stone" describing common, widely-applicable software patterns in a myriad of languages. This project is built around four key architectural features: a "customizable" storyboard model of the view content, bundles of behaviors which populate the views of this storyboard, a file mapping between the storyboard content placeholders and these "invokable" behaviors, and dynamic invocation, which is a feature found in most "professional-grade", high-level computer programming languages. These four design decisions delineate this controller pattern from others such as Struts, Spring, and Laravel. Plus, this choice provides for its flexible, universal, and portable nature. Best of all. a single language instance of such a controller can easily be crafted and documented in forty person-hours or less by a seasoned software engineer.

So, when one builds a "web-based" system with this controller pattern at its core, he must follow the steps below. It is a "multi-cycle" process.

CYCLE A:

Front-End Developers:

• Build a complete "static" HTML-storyboard.
• Integrate its parts.
• Verify it internally.
• Validate it with the client.

Upon approval:

CYCLE B:

• Identify any content which should be dynamic.
• Assign each portion of content a unique user-defined placeholder, such as #E-MAIL#.

Front-End Developers:

• Replace any content which should be dynamic with user-defined placeholders.
• Reintegrate the annotated storyboard's parts.
• Verify it internally.
• Validate it with the client.

Back-End Developers:

• Build packages of invokable methods which will replace placeholders with appropriate dynamic content. 
• Follow a "sensible" naming convention for these methods based upon the placeholders they will replace.
• Unit test methods.
• Verify internally.
• Validate with the client.

Integrator:

• Build the mapping file based on the requirements document produced when identifying the dynamic content and defining the placeholders. This will represent an "architectural control language" (ACL) file in eXtensible Markup Language (XML) or a Segmented Comma Separated Values (SCSV) format.

[ NOTE : The front-end, back-end, and integration work for CYCLE B work can be completed in parallel. ]

CYCLE C:

• Unite the annotated storyboard, packages of methods, and ACL file with the pre-written and reusable general-purpose controller pattern rendered in the appropriate language for the target platform and method bundles.

After this integration step:

• Verify the system internally.
• Validate the system with the client.

CYCLE D: ( Technically Optional )

• "Freeze" the "liquid" nature of the dynamic invocation through the use of an integration completion engine (ICE).
• Perform "final" verification.
• Perform "final" validation.

An ICE is an extremely "simple-minded" code-generator that is not driven by a lexical analyzer and is not dependent upon the complexity of parse trees. In fact, a "bright" fifth grader could most likely build an ICE-machine which might be a "polyglot" code generator producing objects which differ from its native implementation language. Just ask Jeff Foxworthy.

An ICE-machine just will take a pre-written "static and templated" integration point in the target language for the "desired" platform and generate the require source code instance. Thus, it builds the appropriate logical switch for returning each view when requested. This is quite easily and naturally produced from the file mapping between the storyboard placeholders and the "invokable" methods that replace each of these with a string object. It just requires systematically building the appropriate "switching" structure for the description in the ACL file. Each "case of a view" results in the static invocation of the "associated methods" and the "appropriate string replacements". 

And, your final controller pattern could support programmatically routing its behavior through a dynamic channel or a static one which holds a flow of control "switch" built by an ICE-machine. For stability, it would be "best" if one sets the use of the dynamic or static channel before the controller's runtime cycle.

So, that is it, a more complete look at the "vision" surrounding a general-purpose controller (GPC) and a little "review" of software engineering and programming language fundamentals and their applications for those with a baccalaureate in computer science or software engineering.

Its Birth and Implausible Conception

Facts from this account has been given on-line before. During the Spring of 1989, the author of this web history was a freshman footballer at Vanderbilt University. 

He was a natural athlete just ten pounds away from the prototypical size for a professional defensive end in the National Football League at that time. He could generate a horsepower quite easily when deadlifting. And, was seventy pounds shy of the national record as a natural athlete in a large field of anabolic steroid users in his age group. He did set a state records for this group and weight class during competitions in 1987 and 1988. Plus, his overall NFL Combine score meet all of the target measurements for a defensive end, except his forty yard dash time. It was on the slow side at 4.9 seconds. The average professional at that position runs a 4.7. The "best" run a around 4.5 or 4.4. And, one tenth of a second is a lifetime at the speed of professional football. It is the difference between a completed touchdown pass and a quarterback sack. He was slated as the first defensive lineman that would enter the game lineup during what should have been his "freshman" football season in 1988-1989 and was on the first string goal-line defense, a six-man front. 

He was lots of brown brawn, and as such, he was not viewed as very bright, even with spectacles. But, when he opens his mouth, watch out! He had consistently tested among the top "one- percent" of students in America on national standardized test, since elementary school. He had worked as an NIH Scientific Apprentice while in high school and had been published as a contributing author on a research paper in the Journal of Organic Chemistry at the age of seventeen in 1988. 

His chosen field of pursuit at the time was physics, and he had scored among the top fifty respondents on the advanced placement physics exam during the Spring of 1988. A child of the 1970s, who had lived through the energy crisis, his goal was designing more efficient engines and generators. And, he is causally-related with the innovative braking system that is found in his 2014 Toyota Prius V and the vehicle's name.  

He likely should have been on an educational grant at Vanderbilt. Which would have covered all of his academic expenses for four years without requiring working as a student-athlete. Yet, life as a student-athlete was his situation and the only option that he was given for an education at the time, despite having a Stanford acceptance letter and the offer of a four-year early-entry academic scholarship at Southern California, the President's Scholarship. Woe was him. It is a rather long sad story of misguided parental control for selfish motives and frienemies who hated him "with a passion" but smiled sweetly in his face. But, it has some bright spots. And, with a coveted educational opportunity at the Harvard of the South, few, if any, would commiserate with him or mourn a river of tears at his "plight"..  

Some of these bright spots occurred on a sunny Spring weekend after mid-terms. He had requested a "super-single" dorm room in the quadrangle on the West End near the Fuddruckers far way from the shenanigans and antics of the freshman athletic dorm. And, on a whim, simply filling up a schedule which he had planned on building around physics courses, he took a course called "Introduction in Computers and Problem-Solving". Its course call numbers might have been CSE1340. But, he might have that confused with the C++ course which he taught, as an adjunct lecturer, in Carruth Hall at Southern Methodist, Vanderbilt's pretentious little sister, in 2004. 

He did not look at the course description and assumed that it would discuss using computers for completing college research papers and performing basic business tasks with some experiential learning. It was not. 

It was a course in Pascal, a popular "first" language taught in programming fundamental courses at the time. Pascal primarily was used as an academic language, although it had many of the features of a "professional-grade" language with exception-handling, pointers, and structures like C. 

The course was "well-taught" by a graduate student whose husband was a graduate student in physics who believed that he had unraveled the mystery of "cold fusion". She might have been the author's first and likely most efficacious and inspiring college instructor, based upon life's outcomes. Yet, she also might have been in violation of the illustrious Vanderbilt Honor Code during the Spring of 1989.

While in the midst of those "sunny spots" gleaming through a tall window with a almond drape, this author drafted a few "visionary" computing concepts in his primary red Mead notebook purposed for his prose fiction class, ENGL 104W, taught by professor Robert Bacon, an adjunct. 

In retrospect, this seems appropriate seeing that ENGL 104W was a writing, W, course required for all freshman and a prerequisite for graduation. Plus, the author, a dreamer, was unknowingly penning history at the time, as his back rested against the frame of his twin bed in a super-single dorm room.

Upon completing this list of ideas, he shared them in class. As was said, watch out! The graduate student who taught the class asked if she could see the notebook. She reviewed it and the "detailed" list of ideas. This visionary concepts drafted on that weekend were:

• programming by contract (rebranded design by contract by Dr. Bertrand Meyer)
• object-orientation with visions for inheritance, polymorphism, encapsulation, information hiding, access modifiers, and other primitive features of this concern partitioning approach.
• JAVA, which he code named Oak, a freely-distributed and universal virtual machine language that was object-oriented possessing product features like applets, servlets, and factories. Each of these features were implemented differently than he originally intended. Yet, it became a highly viable product. All of this was present along with an "original" tear-drop doodle titled the Duke of Earl and given the gender-neutral name of a freshman sweetheart from a "special" high school program called Horace Mann..
• action-orientation (AO) as a meta-concern separation paradigm based upon objects. The world met AO in a form that was much different than intended lacking "actionable" data types (ADTs)
• an action-oriented language based upon "interconnected and dynamic" object configurations called Python, since the arrangement of actionable data types in motion looked like a ball of writhing serpents in his mind's eye.
• a vision for the concept of architecture in software, based upon principles from mature engineering fields such as construction engineering.
• the notions of model-view-controller and layered architectures
• an idea for patterns and frameworks in computing inspired his grandmother's Jim Walter's home in Chattahoochee, Florida. 
• the plans for a research group called the Gang of Four.
• and much more...

It was hours of "intellectual" fun and a welcome respite from the weight room, agility drills, and that "hateful" Louisianan drawl and smokeless tobacco breath of his position coach, Greg Mantooth. 

The graduate teaching assistant likely had very little problem understanding these notes on the surface. The author often was called "simple" by his high-school sweetheart during his junior year, a tall-petite freckle-faced gal with stormy grey eyes and bushy burnt orange ringlets draping her neck. It was not that he was a dunce, think-headed, or could not comprehend academic material; she said that, when he explained the concepts in the physics lecture which they shared as juniors, the lessons that he weaved were super clear and easily understood. 

Although, in his mind, she was quite an enigma that only Alan Turing's genius likely could unravel. 

Yet, the graduate teaching assistant could not read between the lines of his writings. The most "powerful" concepts in those pages were "hidden" in his notes. They were personal engrams which only he can invoke upon remembering the contents of those "conceptually-rich"  pages with "interconnected" ideas. 

One of these is this approach for developing software systems. As a freshman, he sensed that certain behavioral abstractions were "archetypal" and "primitive" when constructing software. The controller is one. Mostly, an "underappreciated and hidden" step in the software development process, the controllers play a role as vital as compilers or  interpreters. In fact, in ways, they "interpret" the "desires of the end users" and "encode" these as "logical and salient responses" that it returns. And, in a very simplistic and primordial way they perform the system's "thinking".

He recognized the presence of these abstractions in the simple and elementary "menu-driven" systems which he built around a command-line interface on the IBM model 20 Personal System in his dorm room. It was while studying the general behaviors of a Pascal program written as an assessment for that course that he saw the fundamental features of the model, view, and controller architecture.

In fact, such systems would more naturally and logically be termed a view-controller-model architecture. This is based upon the innate organization of its layers. But, these terms were circularly permuted for a reason.

This was another of the "hidden" ideas in his notes which were misinterpreted by those who have "inherited" those visions. Hence, history and the world of computing have a "bastardized" rendering of this concept.

Thinking of languages, like JAVA, as a future generation of computing dialects built around virtual machine platforms in conjunction with the model-view-controller architectures which seemingly surround the core of every system's logic, he drafted the following acronym based upon algebraic reasoning.

VM * MVC  //Virtual Machines Running Systems with Model-View-Controller Architectures

VM * VCM //Re-Arrangement of Terms

VM * VM   //The C Represents Unity Since It Can Be Written Once and Run In Many Instances

                    // as a General-Purpose Controller ( GPC = 1 )

MV * VM  //An "Obfuscation" Step that has become a modern computing paradigm,

                   //Model-View - View-Model

(VM)^2      //This was the true vision for a "VM-Squared" Architecture. A System With A 

                    //View-Model Architecture Running Atop a Virtual-Machine

                   //A new generation of languages and paradigm for development built around the concept

                   //of WORM-driven General-Purpose Controller.

It be should mentioned that the "well-known" acronym WORM was birthed in those notes and had bi-fold meaning. Firstly, it reflected the universality found among a widely adopted virtual machine. Secondly, the dynamic "serpent-ballish" configurations envisioned as "his" Python programs, supporting innate concurrency, were the structural equivalent as a clump of interwound worms. This might have resulted in the concept of a WORM-architecture, seeing that the interconnected objects in an action-oriented configuration would be a cascade of activity after an "initial" method is invoked, much like an array of dominoes. And, it might be the case that a "vision" for a server based upon such action-oriented structures was born that day. In short, the phrase "domino server" might have been in those few pages of notes. 

This "MVC with a GPC on a VM" is not what has been recorded historically as a "VM-Squared" architecture. Why? Honor Code violations at Vanderbilt University. Do not get me started on "intended" projects name "Jovial" and "Jocund". These most likely are the only vocabulary terms distinctly remembered from lessons learnt while in grammar school. The author's six grade teacher suggested that her students learn a word per day. She said that doing so would enhance scores on college entrance exams. "Jovial" and "Jocund" were terms that she gave on one of her weekly vocabulary quizzes. These projects were intended in honor of her. Their original visions were never realized and simply are "misty" water-colored memories (in the key of Barbara Streisand).

In defense of this graduate teaching assistant, the author sent extended family members who were on the executive leadership team at Sun Microsystems these notes in the early-1990s. In fact, the phrase "Share with Gerald at Sun" was in those pages. The author was told that the computing corporation already had been pitched this JAVA idea; and, had he not sent the original writings on notebook paper, JAVA might have never been produced. His "family" members knew that a college student should not have a copy of a proprietary idea which was the property of Sun scribbled on notebook paper. So, the development of the project might have been reconsidered since they then knew that it originated with the author. This resulted in the proliferation of these ideas.

Not caring for the revelry of the football life, he left Vanderbilt after that Spring.

It was the case while an undergraduate at Grinnell College in 1991-1992, he took a course taught in Niklaus Wirth's Modula-II which used the notion of objects, imports, exports, and access modifiers. He does not know the "officially" recorded history of Modula. its objects, and origination; but it likely is "intentionally" pre-dated before the Spring of 1989. And, weeks after sharing his notebook with the graduate student at Vanderbilt, he heard a couple of academics, likely professors, enthusiastically discussing the potential for object-orientation and the concepts he had crafted in his notebook while walking the corridors of the hall were he attended his Pascal lectures. So, it seemed prudent that he share these visions with the intended recipients at Sun after attending Grinnell. Time was short.

Although, an "estimated error tolerance" exists in all of these historical dates. For those who were "well-versed" in the established practice in software development circa 1988 and might have attended a conference on Systems, Programming, Languages, and Applications (SPLASH) which spun-off OOPSLA or the first Software Architecture conference hosted by the ACM, you might see threads of plausibility in this account.

For those who know recently recorded computing history, this might seem far-fetched. But, for those who are in academics, understand the pettiness of the politics and grandiose egos, plus are familiar with the treacherous nature of corporate espionage, this account might seem somewhat reasonable. 

For one, successful "visionaries" in computing, such a Bill Gates, often say that one must separate the innovator from the vision early in the product development process. Many have been documented as saying that innovators are highly intelligent, chock full of ideas, and prolific; but, they do not understand business, which is ruthless. Innovators like dreaming up new and novel ideas. Businessmen enjoy making money primarily for themselves.

Innovators are nice guys. They are proverbially that "last guy in the line" at a chili feed. Why? They simply let the woman, children, and elderly go ahead of them. And, they do not fight with the aggressive males that push past them. What do they invariably get for their reward? A few cold beans, in oily, over-spiced tomato paste, that have been burnt and charred from the bottom of the pot plus unsatisfied hunger pains. Mmmmm! 

As a rule of thumb, businessmen are "type-A" personalities.

Enough about the author. He is simply thanks the Author and Finisher of his Faith, seeing that an athlete, an offensive lineman (S. Bishop) wearing #73, was driven by Vanderbilt's coaching staff until he perished in 1987 from heart failure. The author who wore this same number when he was on the team is simply thankful that he survived his hospital stay when the football staff, led by the strength and conditioning coach Brad Bates, drove him past his limits. Only experiencing mild heatstroke at the time, he has lived and seen his visions realized, although he has not been credited with them. One of his teammates whom he might have known during the 1988-1989 year was not as fortunate. The Lord and His Mercies are paramount. It is his prayer that his predecessor who wore #73 rests in eternal peace.

- Jamie Guertes' Husband (Forever In Love)

Delays, Delays, Delays, .... | Once Again

Team. Schoolwork is keeping this college adjunct quite busy. So, the next deliverable might become available around 11.15-30.2020 instead of 10.30.2020. His course load at the on-line university where he teaches has doubled. Plus, he is teaching a couple of "new" courses this term. And, one of these is at a "new" college. "New" courses always has an increased learning curve and require more person-hours. And, "new" work environments always require an adjustments.

The next phase is rather straightforward and many of your likely have completed it already and possibly the entire project. The end is clearly in sight.

For the next phase, we will be parsing the architectural control file and replacing the placeholder in our storyboard template with the name of the appropriate method for replacing its content.

In the final phase, we will invoke that method and replace the placeholder with the string value return from the associated method.

It likely would be wisest if the contents of the architectural control file were parsed and placed in an associative array, dictionary, hash map, or hash table. This would allow for the quick repeated access of associated method names, during the execution of the application. For web-based processing, such a "control" data structure should be placed in a session or application-level variable. As such, time would not be spent reparsing the architectural control language (ACL) file each time a server-side process runs.

These data structures already are available in most of the languages used in this development effort, except for C. And, for the sake of simplicity we likely will not roll our own hash table for this implementation. Most likely, we will simply reparse the file each time that we need a value. This will be highly inefficient, but this is a "proof of concept" prototype.

And, in the "post-final" phase, we might write a switch generator that will read the ACL file and produce a source file with the appropriate hard-coded logic for statically invoking the appropriate methods for the view that we will be returning.

The author's term at a couple of programs ends early, around the week of Thanksgiving in America. This we free up time for working on this project.

Controllers

Team. This project has manifold purpose. In other words, it is worthwhile for many different reasons. First, it is an exercise in "polyglot" programming, in that it provides fourteen functionally-equivalent software products. The author crafts each in a different high-level computer programming language. 

And, this also is a valuable exercise since it creates a general-purpose controller. This architectural software structure is very common and  found explicitly or implicitly in every interactive system. In terms of software engineering theory, it is an archetypal module for all systems that accept input and produce output. It is the locus of the system's logical processing.

For systems that are layered, usually with presentation, middle-ware, and data-entity tiers, the controller is a way of viewing the role of the middle-ware business logic.

This a fundamental structure in software engineering and system development. It is much like a compiler and interpreter. One does not write a "fresh" instance of one of these language tools each time he needs one. Unfortunately, in the "medieval" days of computing, 1970s - 1980s, a vision for the "pre-rolled" component that controlled the logic the logic of any system was not envisioned. So, the common function of the control unit was rewritten each time it was needed. This counters the principles of software reuse and write once run many (WORM).

The field of software architecture was conceived in the Spring of 1989 based upon the author's best recollection. The first conference on the topic was in the Fall of 1989 as modern records show. It was during this Spring that insight and innovation inspired the birth of the basic architectural assemblies of layered and model-view-controller systems. This was one catalyst driving the modern computing renaissance of the mid-1990s with its world-wide web and markup languages for "typesetting". 

With the advance of the discipline of software engineering during the 1990s and early millennium, the community was given various "prefabricated" controller products such as Struts, Spring, and Laravel. Yet, none of these are truly "general-purpose", nor can they as easily integrate functionality as the product under development in these fourteen languages. Plus, Struts and Spring are only compatible with JAVA and Laravel only supports PHP (the personal hypertext processor).

And, one of the most wonderful aspects of the current system implementation of this general-purpose controller is that it is very simple, a small coding effort, and one which you can build yourself and customize as needed.

Foreshadowing future software engineering practices, "general-purpose" controllers supporting dynamic invocation might soon be a standard language component much like compilers and interpreters. 

Oracle and Microsoft each have modern MVC products. The author is familiar with Oracle's Ozark product which provides a "flexible" controller product for use with RESTful web-services. Yet, outside the realm of web transactions, Ozark does not support the dynamic invocation of "user-defined" methods in other instances. At least, this is how the author understands this product. And, Ozark systems cannot be "wired-up" as easily as this "simple" products architectural control language (ACL) file. Ozark systems must have their logical flow described within the JEE controller's source file. In some sense, those logical concerns are tangled up with other source code concerns. It might be the case that this use of an ACL file provides a better partitioning of system concerns.

In short, this structure for architectural controllers might become a "de facto" standard. Primarily, because it is "simple" in design and "straightforward" in its use, much like HTML.

Phase V | Foreshadowing and Falling Action

Team. We have been working with a simple HTML template file and a CABOOSE logic file that are inconsistent and incompatible with each other. 

The architectural language instructions drawn from "directory.scsv" are from the sample website found within the pages of CABOOSE in JAVA, a text which is available on Amazon. Currently, they do not correspond with our single page site. 

Over the next few weeks, we will don our creativity caps and alleviate this problem. Once we have an HTML storyboard with a compatible controller logic file, Phase V will consist of replacing each placeholder in the HTML file with the name of the method or procedure that will eventually supply the appropriate string for that position within the markup file.

We are planning on the construction of a very simple system with a few pages, no more than five. We will settle on a theme over the next few days. It will be a "meaningful" solution that does not require database access. Plan on an October 31 deliverable.

It is envisioned that we will have a single phase after this one, when we utilize the features of dynamic invocation available in each of these language. The tentative deliverable date for that phase is December 31, 2020.

Phase IV Deliverable

 Team. We completed the deliverable for the fourth phase of this project over the weekend. Of the last few implementations, the only one which was troublesome was the one done in Ruby. The output from this language version during the current phase of our general-purpose controller's development is somewhat different than the others in this deliverable. A current archive with work from all of the phases is available on-line.

Hunt, Peck, and Think. The "perfect" solution will come more quickly, if you do.

Phase IV : Progress Report [ 08.31.2020 @ 7:45 A.M. PST ]

 Team. This past weekend saw a couple of four-hour "bird-brained" coding sprints. During this time, the first eight language instances of our general-purpose controller were constructed ( C, C# [.NET], C++, Clojure, Go, Groovy, JAVA[ JME, JSE, & JEE ], and Node.js ). 

The most time consuming was the Clojure instance. It required the fewest instructions; however, the author only has limited experiences with LISP-like languages and has not coded Clojure programs before this effort. The Clojure controller for Phase IV required about 1.5 PH. 

The remaining language instances ( PHP, PERL, Python, Ruby, Rust, and TypeScript ) will be coded this afternoon or during this week or weekend. So, we might provide this deliverable after is initial proposed date of availability, 08.31.2020. It should be here by the American holiday, Labor Day, Monday, September 7, 2020.

Road Running

Team. With the beginning of the university semester comes a flurry of activity. This is compounded by accepting a teaching assignment at a new college. New computing systems, administrative procedures, and a completely new pool of students with its own unique community culture. 

This coincides with the end of a term at the on-line program where the author teaches a programming fundamentals course in Python. Grading must be done and he must prepare for the next term before 08.31.2020. 

These are his deliverable items which coincide with the delivery of the next phase of this project. So, although he is working like a bird brain while coding (hunt-peck-think), he is running at light-speed between coding sessions. It is his goal that he can set aside a focused 16.0 PH for coding up the scripts. And, average of 1.0 PH per code snippet should be sufficient for the nature of the required enhancements for the phase.

In this step we are:

• we are reading the "directory.scsv" file 
• we are removing the blank lines in the file
• we are parsing the individual lines around commas
• we are ignoring lines which start question marks
• we are removing all of the white space around the line's tokens
• we are echoing this content along with the markup template file

In the next phase, we will process this "directory" file based upon the mappings that it describes. This will require the use of an associative array, dictionary, hash table, hash map, or similar structure. And, we will output the HTML markup with the placeholders replaced by the name of the method which will fill in that spot.

The last phase will involve using "dynamic" invocation for providing the proper content for the markup placeholder.

Hopefully, we can elude Wile E. Coyote and his proverbial ACME contraptions of doom which will scuttle our efforts.

Phase Completion - Extension [ 08.31.2020 ] : Course Preparation

Team. The next season of teaching offers four "lecture" courses. This includes a programming fundamentals course in Python for an international on-line distance education program, a couple of remote delivery courses for a local community college, which likely will include an information literacy course, and a freshman computing elective at a local Jesuit university. Over the next few weeks, the author must prepare himself for this upcoming term. A couple of these "specific" courses the author has not taught previously, although he has given many similar lectures. He could enter each class session and "wing it", but that does make for the occasional "poor" performance.

The long and the short of it is this, he must postpone work on the fourth phase of this project. Which is about a 16.0 PH coding effort. It also requires refreshing some "long-forgotten" programming skills in C. Many of the modern languages, such a JAVA, C#, and etc., provide memory management under the hood and automatically allocates space as needed plus comes bundled with many useful data structures.

And, although this effort's goal is providing a "proof of concept" prototype for the CABOOSE controller pattern and not an "optimized", "professional-grade" solution, each language's object file should handle a reasonably-sized input. This includes the one created in C, whose language features for dynamically resizing data structures is "messier" than many other "more modern" languages.

So, we will plan on delivery of this phase by 08.31.2020, and the final multilingual project in fourteen "unique" languages well-before 01.01.2021.

Keep Coding Like a Bird-Brain. Hunt...Peck...Think...And, Let HIM Provide.

[Mat 6:26 KJV] 26 Behold the fowls of the air: for they sow not, neither do they reap, nor gather into barns; yet your heavenly Father feedeth them. Are ye not much better than they?

[ Meta is Betta ] - Architectural Language for Controllers - [ The Compiler ]

Team. During a previous entry in this web history, we defined a "meta-language" for controlling a simple CABOOSE controller. As described in the text CABOOSE in JAVA by Abraham Vati James, these control files were specified using eXtensible Markup Language (XML).

When we started the implementation of this controller pattern for this multilingual project, we decided that we would use the simplest approaches available. The modules which process XML in these languages were not well-known; yet, it seemed that using them would produce a "wordier" solution than describing the control file using a format based upon Comma Separated Values (CSV).

CSV files can be properly handled with standard file processing and string functions. And, with some extra logic, our "bespoke", or custom, CSV format with sections is easily processable. It is below.

begin,  views

viewId,       stencil

landing,     /WEB-INF/model/xstencil.xhtml
exception,  /WEB-INF/model/exception.xhtml

end,     views

begin,  placeholders

?We can even implement comments on all lines prefixed with a "single" question mark

viewId,    placeholderId,    class,   method

landing,  #PROJECT#,   org.sharpe.sample.StencilHandler,  projectRenderer
landing,  #MODULE#,  org.sharpe.sample.StencilHandler,  moduleRenderer
landing,  #CREATE_DATE#,  org.sharpe.sample.StencilHandler,  createDateRenderer
landing,  #HIBERNATE_MESSAGE#,org.sharpe.sample.StencilHandler, hibernateMessageRenderer
landing,  #JAXWS_MESSAGE#, org.sharpe.sample.StencilHandler, JAXWSMessageRenderer
landing,  #JAXRS_MESSAGE#, org.sharpe.sample.StencilHandler, JAXRSMessageRenderer

exception,  #EXCEPTION_MESSAGE#,  org.sharpe.sample.StencilHandler,exceptionRenderer

end,     placeholders

And, with the proper conditions, we can permit extra white-space for readability. This controller file came with a sample CABOOSE pattern implementation for a JAVA Enterprise Edition servlet that pulls information synchronously from a Hibernate database, a JAVA JAX WS web service, and a JAVA JAX RS (RESTful) web-service.

For our project, we likely will create a control file in this CABOOSE meta language that will populate three of four unique views and a general-use exception view. This will be a proof of concept. The above CABOOSE file produces one test view called "landing" and an "exception" page.
On the landing page, all of the #PLACE_HOLDERS# are replaced with the string returned by the class and method named on the same line. In JAVA, these classes must be in the "classpath" of the web application.

We will produce a "naive" compiler for this language. Although we will parse each line and fill data structures, such as associate arrays, dictionaries, hash tables, or maps, with the information describing the process flow, this procedure will be much simpler than generating an object file from a C or C++ file. It will not require producing machine language or byte code instructions from a high level language specification. We will simply store the processing logic in data structures that will permit near instantaneous access. So, when one request a "view", its specification in HTML can be quickly found within the storyboard model along with a list of placeholders and methods which will replace them with content strings.

This compiled logic will depend upon the use of dynamic invocation when calling the placeholder replacement methods. Dynamic linking is a "tad" bit slower than the static linking that commonly is done. Yet, this approach allows for a much better partitioning of the system concerns. However, one might create a "naive" code generator that builds a "well-structured" and "well-formatted" switching statement from the description found in the CABOOSE meta-language file. Its logic could contain processing for reading the appropriate view and populating it with string replacement. Plus, it could contain statically linked methods which will render the content for the placeholders.

With the use of one's imagination, he can see how a "simple" text-based menu-driven system could be built with a CABOOSE pattern and its associated language. One can also obviously see that he could build a web-based system with an HTML storyboard. And, one could be a traditional client-side graphical user interface system, if he defined a declarative of markup type language for describing the windows and forms. This is the most flexible solution for application building.

Our next phase, will see use reading in the meta language file, placing its contents in a data structure, and then echoing these contents. The plan on a three week turn around on this step, although it probably could be completed in eight hours or less be an accomplished engineer.

Keep It Simple. Happy Hunting, Pecking, and Thinking.

Fourth Phase Completed - Rust Problems Resolved

Team. We resolved the trouble that we were having in terms of linking in the proper external Rust library for regular expression processing. These Rust libraries are called crates. Since we are using MS Visual Code as our editor and work environment, we had been compiling the Rust portion of this project with "rustc". The author does not have any "hobbyist" or "professional" experience using some of the languages in this project, including Clojure and Rust. Each of these has a "special" tool for building projects, compiling, and running them. Clojure uses "lein" short for "Leiningen" and Rust uses "cargo". Once we found some guidance on-line that outlined the use of cargo for creating, building, and running Rust projects, we had more success and the crates were added correctly. The hard-core "Rustaceans" who might be reading this are likely saying, "Duh!".

Yet, making a long story short, we have completed the fourth phase of our simple "general-purpose" controller project which is in this incremental archive.

Hunt. Peck. Think. Enjoy This Coding Day!

Tin Roof Rusted

Team. The next deliverable is about 4.0 PH from completion, conservatively. The HTML file which will be printed at this stage of evolution has a couple of placeholders that we shall replace. The Rust component requires linking in a specific library, regex. Since the author is a Rust novice, this process will require some on-line background reading. One can skin a cat in a number of ways. And, more than one method exists for linking in these regular expression(regex) subroutines. We must settle on one and get the code working. It will return the HTML with the placeholders, but we should "explicitly" replace them with "live" data. So, it has been a "Tin Roof Sunday".

Some of the source code modifications took less than 0.25 PH. Others required 0.75+ PH. The author has not regularly code the C language since 1998. And, it can be rather unforgiving for a misplaced pointers. Luckily, we found code samples which we could adapt and evolve.

Monday will be a "development-free" day. We should rap up the Rust component on Tuesday. If not, we shall deliver what we have on Wednesday as promised.

Hunt. Peck. Think. and Keep It Simple.

Plans, Plans, Plans

Team. We were planning on delivering the source code in each of the fourteen languages that we are using for the fourth phase of this project. During this step, we had planned on producing code snippets that return an HTML file with placeholders that had been replaced with "live" data.

We planned on having that done by this Friday, 06.26.2020, at the end of the workday. Life interrupted this week. The author did not get a start on the code until the late afternoon of this day. He completed part of the fourteen language samples by the early evening, but he is not done.

Give him this weekend and plan on having that deliverable by next Wednesday. He has about thirty Python assignments which he must grade this Saturday. Plus, he is preparing a short course called "Working Smart: With Smart Phones" for the Training and Development Department of the junior college where he teaches, which must be done by next Friday.

It will all fall in place.

Happy Coding. The Code Rosetta Team.

Special Control File(s)

Team. When we build the "general-purpose" controller and JAVA Enterprise Edition servlet for the do-it-yourself tutorial found in the book CABOOSE in JAVA, we used a control file. This structured file used an extensible markup language (XML) format for describing its contents and the interrelationships between its parts.

XML is a wonderful way of representing structured information and mappings between data plus the associated relationships. However, the software packages and libraries for processing XML often require "wordy" solutions. This is the case with JAVA. It seems that XML's flexibility as a file format promotes this "wordiness".

The author realized that whatever one represents in XML might also be well-organized in a relational database management system. And,  programmatic database access does not require as "wordy" of a solution. Yet, we sought a simple, highly-flexible, and universal solution for our controllers. And, if we chose a particular database management system for storing this information instead of XML files, we would curtail its "range of universality".

Yet, another way of "structuring" "flat" files is comma separated values (CSV). It is a little "wordier" than XML but will not irreversibly bind a database management system solution with our "controller" kernels. So, we have a trade-off. The controller files are more "verbose" than the equivalent XML, but the programmatic solution that reads and interprets them is more "terse".

As a result of extracting the control information from an XML file, we must produce a pair of CSV files.

A sample directory.xml file is below:

<?xml version="1.0" encoding="UTF-8"?>

<!--
To change this license header, choose License Headers in Project Properties.
To change this template file, choose Tools | Templates
and open the template in the editor.
-->

<!-- the model is for the entire application. one view associates
with one page of markup. As attributes this element has an id and a stencil
which is a the filename of the markup. Each view has zero or more replacement
tile child elements associated with it. The tile id attribute appears in the
markup and will be replaced by the String content rendered by the method
uniquely described by the class and method attributes of the tile element.
-->

<model>   

<view id="landing" stencil="/WEB-INF/model/xstencil.xhtml" content-type="text/html;charset=UTF-8">

            <tile id="#PROJECT#" class="org.sharpe.sample.StencilHandler" method="projectRenderer"/>
            <tile id="#MODULE#" class="org.sharpe.sample.StencilHandler" method="moduleRenderer"/>
            <tile id="#CREATE_DATE#" class="org.sharpe.sample.StencilHandler" method="createDateRenderer"/>
           
            <!--
               Uncomment the following three tile elements after deploying and starting the JAXRSHello
               and JAXWSHello web services plus creating the necessary database structure for the Hibernate operations.Take them one at a time.
            --> 
           
            <!--<tile id="#HIBERNATE_MESSAGE#" class="org.sharpe.sample.StencilHandler" method="hibernateMessageRenderer"/>-->

            <!--<tile id="#JAXWS_MESSAGE#" class="org.sharpe.sample.StencilHandler" method="JAXWSMessageRenderer"/>-->

            <!--<tile id="#JAXRS_MESSAGE#" class="org.sharpe.sample.StencilHandler" method="JAXRSMessageRenderer"/>-->

        </view>

        <view id="exception" stencil="/WEB-INF/model/exception.xhtml" content-type="text/html;charset=UTF-8">

            <tile id="#EXCEPTION_MESSAGE#" class="org.sharpe.sample.StencilHandler" method="exceptionRenderer"/>
</view>

</model>

First, the directory holds a mapping between the application level identifiers for the view specifications, "id", and the name of the file which holds the view's markup specification in client-side technologies, "stencil".

So, this information must be held in one CSV, under the headings viewId and stencil.

viewId, stencil

landing,/WEB-INF/model/xstencil.xhtml

exception,/WEB-INF/model/exception.xhtml

Second, the directory holds a mapping between data placeholders ids and the identifiers for the classes and methods that will render a string which eventually shall replace the placeholder in the appropriate markup stencil. 

So, this information must be held in another CSV, under the headings viewId, placeholderId, class, method.

viewId, placeholderId, class, method

landing,#PROJECT#,org.sharpe.sample.StencilHandler,projectRenderer

landing,#MODULE#,org.sharpe.sample.StencilHandler,moduleRenderer
landing,#CREATE_DATE#,org.sharpe.sample.StencilHandler,createDateRenderer

landing,#HIBERNATE_MESSAGE#,org.sharpe.sample.StencilHandler,hibernateMessageRenderer
landing,#JAXWS_MESSAGE#,org.sharpe.sample.StencilHandler,JAXWSMessageRenderer
landing,#JAXRS_MESSAGE#,org.sharpe.sample.StencilHandler,JAXRSMessageRenderer

exception,#EXCEPTION_MESSAGE#,org.sharpe.sample.StencilHandler,exceptionRenderer

It is easy seeing how these might be a pair of "simple" database tables with primary and foreign keys.

Yet, we would like it if we could keep all of this information in a single file. So, we will "create" a CSV with "sections" or a sectioned comma separated values (SCSV) file, using beginning and ending markers like XML elements and the Pascal language.

begin,views

viewId, stencil

landing,/WEB-INF/model/xstencil.xhtml

exception,/WEB-INF/model/exception.xhtml

end,views

begin,placeholders

?We can even implement comments on all lines prefixed with a "single" question mark

viewId, placeholderId, class, method

landing,#PROJECT#,org.sharpe.sample.StencilHandler,projectRenderer

landing,#MODULE#,org.sharpe.sample.StencilHandler,moduleRenderer
landing,#CREATE_DATE#,org.sharpe.sample.StencilHandler,createDateRenderer

landing,#HIBERNATE_MESSAGE#,org.sharpe.sample.StencilHandler,hibernateMessageRenderer
landing,#JAXWS_MESSAGE#,org.sharpe.sample.StencilHandler,JAXWSMessageRenderer
landing,#JAXRS_MESSAGE#,org.sharpe.sample.StencilHandler,JAXRSMessageRenderer

exception,#EXCEPTION_MESSAGE#,org.sharpe.sample.StencilHandler,exceptionRenderer

end.placeholders

This structure in our "special" control file will provide a means for representing all of the interactions that are seen on our view storyboard which is built using client-side technologies. It can be seen as a "meta" programming language for our controller, sitting atop the behavior of controller whose "near" cousin is a command shell or high-level language interpreter. 

Providing a "clearer" view of our controller system and how it works, the xstencil.xhtml file is below:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">

    <head>

        <title>CABOOSE Standard Stencil</title>

        <meta name="viewport" content="width=device-width, initial-scale=1.0"/>

    </head>

    <body bgcolor="F1F8FF">                

        <!-- 

        I chose that my tile replacement identifiers would

        follow the pattern #ALL_CAPS_JAVA_IDENTIFIER#. This

        is only a convention and not strictly enforced by the

        cab. Obviously, the string used should not collide with

        any other one that might be found in a markup document.

        -->

        <table width="640px" cellspacing="10px" cellpadding="20px">

            <tr><td align="center">&nbsp;</td><td align="left" colspan="2">CABOOSE Standard Stencil</td></tr>            

            <tr><td align="left">Project: #PROJECT#</td><td align="left">Page Handler: #MODULE#</td><td align="left">Create Date: #CREATE_DATE#</td></tr>

        </table>

    </body>

</html>

Basically, our controller reads in the entire markup file associated with the "requested" application view. Then, it uses simple programmatic repetition and replaces each placeholder, such as #PROJECT#, #MODULE#, and "CREATE_DATE# with the string produced by their associated class and method in the "directory.scsv" file. This creates the response for the client. The string which the class and method render might be "simple and flat", or it might be a string that describes client-side markup or another technology.

These are our next steps after "just" returning an HTML file.

Here it Be - The File Reads

Team. The MS Windows-based *.zip archive is available that contains the first three steps in this  multilingual project which will produce a kernel for a "general-purpose" controller using an incremental parallel build approach. The next step is rather trivial. It simply requires changing the filename of the file which is read and whose contents are returned by the programming scripts. It will likely take more time updating the comments than it will take making this single modification in each source code file.

Yet, we are planning on delivering this next step in three calendar days, based upon other teaching and development responsibilities.

Remember the scripts provided require the proper software environments before they can properly run. These are available on-line for the fourteen languages used in this development project: C, C#, C++, Clojure, Go, Groovy, JAVA, Node JS, PERL, PHP, Python, Ruby, Rust, and TypeScript.

File Reads

Code Rosetta Team. Just finished the file reads for the different languages represented in this "general-purpose" controller project. Most have error and exception handling, but some can "abend" if the file is not found.

Although the simple scripts have been tested, they have not been completely commented. Once they are, they will be placed online. Seeing that the author is not well-versed in all these languages, this effort took about 8.0 - 12 PH with ample rests.

Happy Coding!

Where is Bill and Ted? Do You Hear Those Air Guitars?

Team. This is definitely an "excellent" adventure. As corporate software engineering teams gain collective experience over many project life-cycles, they can become more productive with each iteration of this cycle. And, as well known, productivity follows quality. Quality is enhanced as project teams "mature" and become more "capable", producing repeatable, measured, managed, and optimized projects. They can leave behind those "big bang", "one time" ad hoc experiences where software is created that can only be used in a limited range of production instances.

It has been said by software engineering researchers that developers much like teams have a process, a personal one. And, one could reason that this personal engineering process can follow a capability maturity model (CMM)-like evolution.

This has been the case for the author with "simple" web-based controllers. During the late-1990s, in the first half decade of the WWW, he spent many hours writing common gateway interfaces, mostly using C on a UNIX platform. It was a frustrating experience. Although he is not a perfectionist, he is somewhat of a "purist".

Those early common gateway interfaces had a "poor-quality" architecture. The various concerns: the view elements composed of HTML and related technologies, the logical action of the controller, and the interaction with the entity classes where much like a "co-mingled" plate of "goulash". It was not "spaghetti" code, but it definitely did not have well-defined layers like a "lasagna": cheese, noodles, meat sauce, cheese, noodles, meat sauce, etc.

This made development tedious and frustrating. Yet, as a junior engineer with very "little" seniority, management would not consider the author's advice about "properly" structuring the controllers and partitioning the concerns. More emphasis was placed on using certain "buzz-word" technologies than building the company's products well.

Yet, the author felt that he could build a "small, simple" one well the could be the cornerstone of the company's web-based systems that secured financial systems for a Fortune 500 insurance company and a securities firm. But, he simply put his ambitious goals aside so he could keep receiving a paycheck.

Although not a "steady" effort over the past couple of decades, much thought has been given the idea of building a reusable "general-purpose" controller framework. For one, a controller is basically a "logic-switch" that sits between the presentation layer and its related view technologies and the model layer with its associated entity-class technologies. A controller represents that middle-ware glue that binds the view and model of a layered model-view-controller architecture. As such, it must be flexible and malleable.

It is an important enough software structure that it be studied, refined, and built well. For one, it, like the impostor Jared, has a number of talented personas. This includes a command shell, formal language script interpreter, network-based protocol handler, and etc. The controller is a powerful paradigm.

And, as part of future Rosetta Stone efforts, we might morph our "general-purpose" controller for use as a kernel for a command shell, interpreter, and "network-based" protocol handler.

Be a Bird-Brain. Hunt, Peck, and Think. It Makes for Better Code and Lowers Stress Hormones!

Phase - B

Team. We chose an incremental and evolutionary build model for our "general-purpose" controller. Its conception was in the embryonic form of a script or program which simply printed "Hello, World!" This was phase A of our nine step life-cycle. The next and current phase simply prints "Hello, World!", but it uses a function for doing so.

For those of you who understand the processing behavior of programming languages, you are well aware that the main routine must build and populate an activation frame for the subroutines that we invoke and place them upon the call stack in last-in first-out (LIFO) order. At a minimum, this will be the "sendResponse" procedure which echoes "Hello, World!" on the terminal's screen. This is above and beyond the "main" routine which invokes "sendResponse".

The building and population of an activation frame on the call stack takes time and memory space. Since it requires interacting with main memory, this time expended is rather large in comparison with time required for a single processor cycle. So, using these subroutines "slows" the processing of our scripts and programs some when they are not required. However, structuring the controller with them improves its readability and maintainability. This enhances other aspects of quality such as resilience, reliability, and robustness. These are all benefits of greater modularity and structure.

Phase B is simply our next nascent, naif-like step in the direction of a kernel for a "general-purpose" controller. Our final product might require some minor retrofitting before it integrates "smoothly" with the equivalent of a common gateway process, such as a JAVA Enterprise Edition servlet.

The archive for this phase was modified with comments after its behaviors were checked. Plus, the identifier for some of the "sendResponse" and "send_response" modules was modified from "sendingResponse" and "sending_response". These "typos" with the "ing" were introduced while coding the scripts and programs in parallel. As a result, an error might arise when compiling or interpreting these files. One can simply correct the module's identifier, and it should work without any issues.

Some of the languages, like Clojure did not integrate well with MS Visual Studio Code for the author. Others might see better results. As a "work-around", the author created Windows batch files for running and also possibly compiling the scripts. These are labelled "run.bat" in each language directory of the archive.

For the languages which normally use "camel-casing", such as "sendResponse", this was the name used for the identifiers. The only exception was the name of the class, when a class was used. In this instance, the first letter was lower-cased, and it was named "caboose". Classes were used for the languages which are commonly known as object-oriented. This includes C#, C++, and JAVA. Eventually, all of the languages which will support objects will have an object-oriented solution. The classes simply have not been integrated yet.

For the other languages who do not "usually" use camel-casing, the traditional "snake-casing" such as "send_response", was used.

Future Directions

Phase - C will read the phrase "Hello, World!" from a text-file and print it. This will require handling all of the possible file-handling exceptions that might occur. This might simply be done at the level of the general exception class for simplicity. Yet, processing the individual sub-classes of exception might be "wise" and produce a more "user-friendly" product.

Phase - D will simply read an HTML-template with a data placeholder in its body from the file-system and echo it on the screen. In this step, all we must do is replace the filename and path of the "Hello, World!" text-file with that of our HTML-template in the Storyboard folder.

Our tentative goal is completing this pair of phases by the end of June 22, 2020.

Polyglot-Project Plan - [ "Hello, World!" ]

Team. The grandest of romances starts with a simple word, "Hello" or "You have an ant in your hair!". And, the most potent program from which one can build any other is just as simple. It is that canonical first program in every modern freshman computing course, "Hello, World!" It is simple and tests one of the most fundamental processes in computing, producing output. The other pair of primitive processes is accepting input and transforming that data which a program receives when producing worthwhile information for output.

Some of the skills needed for completing the project listed in this web history are not described herein. These include installing and configuring the simple, free integrated development environment, MS Visual Studio Code, for use. We use this product since it supports each of the chosen languages. If this configuration process is a mystery, one must search on-line for instructions at Microsoft or other sites with software development tutorials. Also, one simply can install interpreters or compilers for each of these languages and then use a command shell for running each script or object file.

This source archive contains all of the instances of the simple "Hello, World!" program which we will use as a starting-point for our multilingual "general-purpose" controller project. One can rewrite the scripts as he chooses becoming familiar with this process for using each language in Microsoft Visual Code.

The nine step process for developing the "general-purpose" controller components in various languages is below:

NuevoArchitect - [General-Purpose Controllers] -  07.01.2020

(9-Step) Evolutionary Development Plan for a CABOOSE Server

Step A. Hello World (on a single line)

Step B. Hello World (from a subroutine)

Step C. Hello World (in a text-file from a subroutine with exception handling)

Step D. Hello World (in an html-file from a subroutine with exception handling)

Step E. Directory.scsv (echo from a subroutine with exception handling)

Step F. Directory Dictionaries (built with a subroutine from *.scsv and echo)

Step G. Directory-Driven Hello World (with classes called CABOOSE and SCSV)

Step H. Directory-Driven Storyboard with VUE.js web-components and text-replacements.

Step I. Quality Assurance

Nothing in this project requires any advanced programming skills. The abilities used are acquired by most students who take a course in programming fundamentals as a high school or college student. We will be using the common output command used in the "Hello, World!" program that we created. We also will use subroutines. These can be called modules, functions, procedures, or methods depending upon the language used. Yet, they all perform the same basic tasks. They are subprograms. We will open and read files plus use the exception handling associated with these processes. We will echo and dynamically modify hypertext markup files based upon processing directives in the directory.scsv files. We will interact with a "novel" comma-separated values format that defines segmented sections within it. That is what a "*.scsv" file is, sectioned command separated values. And, we will integrate view components, using VUE.js, with our product showing how flexible and universal it is.

The author should note that the dates on the copyright are set in the future by a couple of weeks. It was initial intended that this project would reach this on-line venue after July 01. 2020. The dates were not rolled backwards. So, we are ahead of schedule. Ironically, the first few posts on this Rosetta Stone weblog were in 2016.

Picking UP An "Old Project"

Team. Over the course of the past few years, the author completed a software project and related book on general-purpose "web-based" controllers for MVC architectures in his spare time. The  development weblog for that project spans three months or more of regular posts. The associated book can be found on Amazon.

His primary work role is that of a college adjunct. He teaches a mixture of courses in information technology that focus on computer literacy and office productivity suites plus programming fundamentals in JAVA and Python. Designing a "simple" Rosetta Stone for modern computing languages has long been a goal of his. Others have taken on this project, but such efforts have historically been provided over-complicated descriptions of "primitive" software structures. It is his goal that he improve upon these attempts.

The experience gained from building a simple "general-purpose" controller (GPC) plus working with the fundamental computing elements found in numerous imperative languages over the past few decades has produced an "opportunity" for a "unique" convergence of his goals and ideas in the form of a "multi-language" development project that produces a GPC framework.

This polyglot-project will produce the equivalent of the JAVA servlet described in his text on "general-purpose" web-scripts, CABOOSE in JAVA. A CAB is a controller application bundle. This is a packaging of functionality that contains supporting methods and entity classes which customize a GPC for use in a particular application. The OOSE simply implies that these controllers are naturally fit for use in object-oriented software engineering. However, at least one of the GPC instances in the current multi-language project will use a non-object-oriented language, straight C.

Our development will be done in Microsoft Visual Code, since it supports the editing, compilation, and execution of many different modern languages. We will be building a component which one can integrate with a common gateway interface (CGI) process or its equivalent. It is our goal that we complete this project in at least JAVA (which has previously been done), PHP, PERL, Python, C#, C, C++, Ruby, Groovy, and other languages.

And, like an ancient builder explaining how one cast a brick from a slurry of limestone, sand, plus papyrus and other plant matter, that can withstand a load sufficient for supporting a Great Pyramid, we will complete our work in more than one "engineering" language. If one would like a "natural" language translation of any of these pages visit Google Translate.

We are picking up this web history after a few years hiatus and heading in a slightly different direction by choosing a "specific" project one which we will work.