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.
Tuesday, June 23, 2020
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.
Sunday, October 23, 2016
Coding Priorites
Team. This Rosetta Stone for popular computing languages is progressing slowly. No, we are not chiseling stones in Al Gore's garage. We simply have other priorities. That is the joy of being a hobbyist. One can pick up and put down projects when comfortable and convenient.
Please, forgive the source examples on STDOUT and STDIN which were promised and have been undelivered. It is not vaporware; it is simply in a very low-priority thread. Also, we are not abandoning this effort.
A few other Rosetta Stones for coding exist online. Most have cryptic code for esoteric processes. Our goal is simple, well-documented, highly-readable, and understandable programming sources.
We will do our best at keeping these as simplistic as we can. Many of the coding samples exist in literature and on the WWW. Some would work well for this effort. Others would not. These simple samples just have not been gathered and placed in one location, yet.
This process which we are undertaking is often described by an egg-headed English word, chrestomathy. In Zhongwen (Chinesse), 讀本, this word has a much simpler and shorter representation. And, from the perspective of a native English-speaker, any word which looks simpler in Chinese than English is likely any over-complicated word describing a process which can easily become overly complexified.
We will work on simplifying the current WWW computer programming language chrestomathy approaches.
Only touching base. The Rosetta Team.
Please, forgive the source examples on STDOUT and STDIN which were promised and have been undelivered. It is not vaporware; it is simply in a very low-priority thread. Also, we are not abandoning this effort.
A few other Rosetta Stones for coding exist online. Most have cryptic code for esoteric processes. Our goal is simple, well-documented, highly-readable, and understandable programming sources.
We will do our best at keeping these as simplistic as we can. Many of the coding samples exist in literature and on the WWW. Some would work well for this effort. Others would not. These simple samples just have not been gathered and placed in one location, yet.
This process which we are undertaking is often described by an egg-headed English word, chrestomathy. In Zhongwen (Chinesse), 讀本, this word has a much simpler and shorter representation. And, from the perspective of a native English-speaker, any word which looks simpler in Chinese than English is likely any over-complicated word describing a process which can easily become overly complexified.
We will work on simplifying the current WWW computer programming language chrestomathy approaches.
Only touching base. The Rosetta Team.
Subscribe to:
Posts (Atom)