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!
Tuesday, June 30, 2020
Sunday, June 28, 2020
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.
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.
Friday, June 26, 2020
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.
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.
Tuesday, June 23, 2020
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>
landing,#CREATE_DATE#,org.sharpe.sample.StencilHandler,createDateRenderer
landing,#CREATE_DATE#,org.sharpe.sample.StencilHandler,createDateRenderer
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,moduleRendererlanding,#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
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,moduleRendererlanding,#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
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"> </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.
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.
Monday, June 22, 2020
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!
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!
Friday, June 19, 2020
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!
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.
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.
Thursday, June 18, 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.
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.
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.
Subscribe to:
Posts (Atom)