MVC 1.0 Ozark with CABOOSE

Team. We are making progress on the text. Our last step is merging our Netbeans tutorials which uses the latest edition of the CABOOSE JAVA archive. These are in progress. Whether one of the larger technical publishing houses accepts the work or it is self-published, a web-link for it on Amazon will be placed on the weblog and on the http://www.nuevoarchitect.com site. If it is self-published, that link will be coming sooner.

Happy Coding! Hunt...Peck...Think....Look For The Obvious...

Community Service Post - Swaddling Clothes Project

Over the past few years, the author of this weblog has participated in an annual project which supplies the local shelter network with warm clothes for the homeless in the city. This is particularly important in our vicinity where wind chills can dip below eighty minus Fahrenheit during mid and late January. If you would be interested in finding out more about the project and possibly donating, please visit the GoFundMe Campaign for Swaddling Clothes.You might considering starting this in your area of the country.

Freedom of Expression and Idea Exchange

Team. We have made some progress over the past few months. This effort started nearly a year before this weblog with a request of the JAVA Community Process (JCP). It is an incredibly enjoyable experience. In terms of computer speak, life is often an series experiential transactions forming the totality of its process. A popular American singer from the last millennium coined phrase in a popular song which said that, "The secret of life is enjoying the passage of time." plus all the undulations in happenstance which occur therein.

It should be noted that this was chosen as an open-source project. This was done so this development approach, which is useful in many areas of web application development but not universal, could freely proliferate. This framework for development lacks universal applicability since the "dynamic invocation" of methods through JAVA's Reflection API adds a time cost.

If not mentioned early, please freely use the ideas contained in this weblog improving and adapting them as needed.

Finally, Google's Blogger let's its writers know which geographic areas of the WWW are viewing the articles. So, for some of our newer viewers, the following message produced with an on-line translating service will be our closing:

Pour nos nouveaux visiteurs du Congo. Merci beaucoup pour votre intérêt. S'il vous plaît utiliser librement toutes les idées qui sont utiles. Puissiez-vous être richement bénis dans vos efforts de calcul.

Happy Coding! The CABOOSE Team.

Touching Base - Book + Source

Team. We are still working on the tutorial book and the source for CABOOSE. Oracle's Ozark Model-View-Controller 1.0 should be delivered soon. We have been lurking on their mailing list. Interestingly enough, it appears that the Ozark team has added support for template engines. We only glanced at the source for template support which can be found here.

Enjoy Your Coding Adventures! The CABOOSE Team.

CABOOSE, Asynchronous Methods, and Web-Services

Team. We have been rather busy for the past few months. We have found time for the CABOOSE-Ozark book which is still in progress and testing the CABOOSE JAVA archive. During testing with web-services which might not produce a timely response, we realized that client-side scripting with Asynchronous Javascript And eXtensible markup language (AJAX) might best satisfy processing responses from web-sources that might present a delay. A combination of AJAX and scripting which replaced the *.innerHTML property of a "span" or "div" element with any default information on the resultant view is necessary for achieving this. All of the AJAX scripting, markup elements, and default content would be provided by a rendering method which replaced any associated page concern described as a placeholder. This approach would allow for faster view display times.

A reusable instance of the needed client-side scripting for supporting these behaviors will be include in the CABOOSE package within its JAVA archive.

With all that said, I am reminded of the words of the wisest man in history that said "meaningless, meaningless, meaningless...all is naught more than a chasing after the wind." So, keeping everything in perspective, take time and enjoy some sunshine and crisp, clean air each day, if you can!

Hunt...Peck...Think...Enjoy Your Days!

The CABOOSE Team

Still Writing, Revising, and Proofing Ozark-CABOOSE Text and Source

Team. We are still writing, revising, and proofing the Ozark-CABOOSE Text and source code. With our other responsibilities, we have not had much time for the daily and weekly post which we were placing on-line at the outset of this project. We will keep you abreast of the key activities in this project. We appreciate any feedback which you might have. And, we will happily receive it at feedback@nuevoarchitect.com.

May Your Days Be Rich, Rewarding, and Restful,

The CABOOSE Team.

Happy Coding!

Light Bulbs Which Do Not Burn Out

Team. This is another CABOOSE side note. It is somewhat philosophical. When younger, a rumor was floating around that some wooly-headed fellow created a light-buld whose filament had a MTTF in excess of a century. MTTF is an engineering term which simply means that on average a device will last longer than a certain amount of time. I believe this fellow's name was Latimore. The following hyperlink shares a little about him and other such characters.

http://www.biography.com/news/african-american-inventors-20737249

I would hate coloring your perception of him, but it seems he was much brighter than one should be for his time and circumstances. It had been said that Thomas Alva Edison, the inventor for whom many an elementary school is named, decided that a light-bulb which lasts that long would be unprofitable. But, consider the cost savings in natural materials such as tungsten ore and sand which we might have saved this world community if such bulbs lasted longer. Not mentioning all of the petroleum spent in mining and transportation. Of course, fewer jobs in the lighting industry would have been created, and such an invention at this juncture in time would be disruptive likely causing numerous economic ripples. As bright and prolific as Edison was, he certainly could have filled this void with numerous other inventions. He was most probably tired of running like a hamster on a wheel generating ideas dreaming of a goose which would lay millions of golden glowing eggs.

With this said, much of this world's population claims that they follow a faith tradition stemming from the Book of Beginnings or Genesis. Is not one of the early teachings in this work stewardship? Ah so, koennen wir dass buchstabieren? S T E W A R D S H I P. Let us not miss the boat on this one! Plus, greed is one of the seven deadly sins. Would not a little of green thinking in the 1800s definitely had changed the course of history! But, it is not easy being green! Also, if hair color can change so can mindsets. So, time remains for improvement. But, is not it ever so sad when someone charged with tending something starts thinking that they own it. Here is a question for the old class...The earth is Whose and the fullness thereof?  We all must do better. A short pop quiz will be given later on. So, please be prepared. Your entire grade depends on it. Also, do not forget your portfolios. What is in a portfolio... you ask?  Here is a hint..."Would a portfolio by any other name be as neat?"

Hunt. Peck. Think... The CABOOSE Team.

Ozark-CABOOSE Book Progress

Team. We are progressing on our text about the new Ozark product from Oracle and our companion resource called CABOOSE. It will likely not be available in July 2016 as originally expected. We are currently looking for a publisher and have had some interest from a couple of large publishing houses. If they do not accept the work which they can including in their offering of technical texts, we will self-publish. We have adjusted our sights for late September or early October. Besides, Ozark 1.0 is still in flux. Visit ozark.java.net for more details and join the mailing list.

Before delivery of the source for use, we will modify the licensing. It currently does not allow for commercial use and only permits using CABOOSE for educational purposes or research. We have been busy. Our sweat is wearing grooves in this old grinding stone, but we are having fun!

Thank you for your interests in this project and this alternative approach for software development. Such plug-able architectures whether they are web-based MVCs or daemon-based interpreters offer a more flexible and easily organized method for building software than some traditional approaches.

Enjoy This Summer of Code! Do Not Worry! Be Happy!

The CABOOSE Team

Architectural Chicken Eggs

Team. Software engineering is a rather new field originating in the early 1970s. With reuse being a key concept in this discipline, we have borrowed numerous "best practices" from other engineering fields which are more mature plus have more stable and reliable engineering processes. This includes the formal methods used in "clean room" development.

Lately, the CABOOSE Team has learned that,  in other engineering disciplines which involve building construction, architectural concerns are considered from the early stages of requirements elicitation. This practice is somewhat different from "textbook" software engineering processes based upon the waterfall model which fixes architectural design in the later stages of development. Textbook software engineering teaches that one should determine a product's features and requirements before deciding upon an architecture. If one starts a project with a certain architecture in mind, this limits the possible implementations and the requirements which the development process can satisfy. Thus, the chosen architecture has a great bearing on the requirements. But, requirements can greatly limit architectural choices. So, the problem of desired features and chosen architecture is a classic chicken and egg problem in software development.

But, if we take a simple philosophical view of the nature of chicken and egg problems, we might realize why the centuries old building engineering discipline views architectural design plus feature and requirement determination as concomitant (concurrent) processes. Given a fertilized chicken egg, do we have a chicken; do we have an egg? The answer for each of these questions in "yes!". Since the egg contains all of the materials needed for producing the chicken and the genetic program for doing so, we have both a chicken and an egg. As the fetus matures within the shell, both the chicken and the egg evolve and experience many stages of their respective life-cycles. Once the chicken (architecture or requirements) reach a satisfactory state of development, the egg might be set aside.

The practice of building construction offers architectural options for its clients during the early proposal stages. These potential choices are an integral part of determining the building requirements, detailed design, and final implementation.

A agrarian (farmer) might consider the entire chicken and egg problem as a "horse-sense" test much like the famous question that a rural farmer once asked his grandchild when he visited for the first time. "Son, can you find a needle in the haystack behind the barn? I will pay for your college education if you can!" Apparently, the poor child spent most of the day searching for a sewing needle.

While acquiring advanced degrees, letters, and such, we can often forget the "common-sense" man has know for centuries as we "advance".

We are still working on our book and wrapping up the testing on CABOOSE. The Ozark Team is currently discussing some possible annotations which support its JAX-RS web services controller.

The release of the JEE CABOOSE products should coincide with the delivery of Ozark.

The CABOOSE Team. Enjoy This Weekend!

CABOOSE Status | Writing, Reviewing, & Testing

Team. We have simply been using the last few weeks for writing and reviewing the part of our text on Ozark and CABOOSE, plus we have been cleaning up the code and running a set of test cases. Our goal is delivering something for use with JEE when Oracle provides MVC 1.0 in Q3 2016.

Hunt. Peck. Think. Happy Coding. The CABOOSE Team.

Refocus | CABOOSE Vision, Methods, and Goals | The Ozark-CABOOSE Book

Team. Seeing that this also doubles as a general weblog for computing ideas we had a short note on mathematics recreation. The topic discussed, the Miller-Kovarik Secondary Method, can serve as an effective approach for finding the roots and extrema of various functions. As such, it is important in many of the optimization tasks used in computing. Optimization activities and web development do not overlap often, but the approach seemed worth stating. But, we shall now refocus of CABOOSE: it's vision, method, and goals. Plus, we will provide a rough outline of the Ozark-CABOOSE text.

The Vision of CABOOSE

Providing a methodology for rapid and accurate web application development which is compatible with modern agile techniques, consistent with the "best" practices in software engineering, and adaptable so it can accommodate future software development goals.

The Methods of CABOOSE

Through the use a reuse-able pre-written controller and dynamic invocation, the CABOOSE approach accelerates development. Front-end scripters can develop a "mock-up" of the web application in a standard mark-up language: XHTML, HTML 5.0, Dynamic HTML, or etc. Upon completion of the first draft storyboard, the client can approve it or request revisions. During the iterative refinement of the storyboard's appearance, engineers can write methods which return the dynamic String content that will populate the application "mock up". These efforts can occur in parallel. Also, if need be, a third parallel stream of develop can occur. This extra stream can be responsible for structuring all of the transactions between entity classes and the web application. The most critical step in development is the integration of these streams of development.

The directory.xml file integrates each view of the application and combines the storyboard and populating method streams. Finally, if the third stream of entity class transaction development exists, that code must be interwoven in the fabric of the methods which provide dynamic content for the storyboard.

The Goals of CABOOSE

Simplifying the "common case" of web development. The UNIX Philosophy states that one should make the "common case" simple and quick. This means that 95% of one's tasks will be easy.

Extracting out most of the "web-centric" development tasks in a pre-written controller lets one create a solution using the most common features of the development language. In the case of JEE, this means more Core-JAVA instructions for string handling, database transactions, and etc.

Providing a curriculum that produces well-rounded web developers who can complete full-stack development tasks: front-end, middle-tier business-logic, and back-end. Engineers can participate in CABOOSE development if they skills in any of these three layers and develop competitive skills in the others.

The Ozark-CABOOSE Book

The tentative outline for the Ozark-CABOOSE book is as follows:

A History of JAVA Plus its Urban Legend
A History of JAVA Enterprise Edition (JEE)
A History of Ozark (Oracle's MVC 1.0 [JSR 371])
A History of CABOOSE
Goals in Software Engineering
Goals in Web Development
Fundamental Programming Approaches
Software Architecture Fundamentals
An Ozark Controller Application
An Ozark ViewEngine Application
A CABOOSE Servlet Application
An Ozark-CABOOSE Application


We thought that we would get back on the software engineering track after that last post.

Hunt. Peck. Think. Enjoy this Week of Web Development.

The CABOOSE Team.

Math Recreation

Team. We have a recreational mathematician on our squad who is interested in honoring an old friend and teacher. The friend was blind, but amazingly gifted. He could play the piano and had a paper route. The teacher was always encouraging and had a gift for teaching college level subjects from Seth Werner's book on Modern Algebra and Oystein Ore's book on The History of Number Theory in simple ways. The procedure is called the Miller-Kovarik Secondary Method. It is useful in resolving Diophantine Equations. It partially answers Hilbert's 10th Problem. Given a Diophantine equation such as C = 2xy + x + y, one can find its solution by first setting it so it equals zero. Then, one must embed it in a parabolic function through composition, g(x) = ( 2xy + x + y - C )^2. Then, one determines the outer bounds of the solution in the first quadrant. Next, one defines a mesh describing the surface which has a single minimum. This mesh is n x n. This means that it has much fewer points than the total surface. It is an approximation of the surface. Afra Zomorodian wrote a wonderful dissertation on describing the salient features of a shape through decimation. It is a wonderful and interesting work in topology. Basically, the next step is taking some statistical measures of the mesh points. After finding the appropriate deviation of the mesh nearest zero, one has made a step at finding the minimum. This smaller mesh is your secondary. The original mesh was the primary. The process is repeated on the surface comprising the smaller mesh with the resolution of the original mesh. Find the third deviation and repeat until the lone root exist at zero or one find a space in which one can search all the points quickly.. Miller first presented the surface embedding idea in secondary school, hence the double entendre. Being blind, he could not fully visualize the mesh. But, during his presentation, he did say that all the points are not need; he had the surface described as a Bull's Eye with the target at zero. A peer, McQuiddy played the devil by confusing him which is sad and unfortunate, otherwise we might he might have reached this result. Kovarik said that some cleverness was needed for resolving this problem. After reading Afra's thesis around 2005, a moment of cleverness occurred. I know this is hand waving, but I imagine most undergraduate computing or math students might derive this quickly. This approach works well for monotonic Diophantine equations.


Hunt. Peck. Think. Happy Coding.

Writing In Parallel...

Team. We are working on compiling a short book on Ozark and its CABOOSE companion. This combined with the coding is time consuming considering other obligations. Hopefully, we shall have a first chapter ready for review soon and should publish the final work during Q3 2016. Thanks Oracle for enhancing these efforts with JSR 371. We will keep you informed of upcoming events and final deliverable dates.

Hunt, Peck, Think, And Keep a Song in Your Heart!

The CABOOSE Team.

Monolithic Methods and CABOOSE

Team. Hopefully, the past few weeks have been productive for you. Our last post summarized how CABOOSE simplifies the web application development process and associates a single method, module, function, or subroutine with a web page concern. Such an approach prevents web application developers from building one large, unwieldy monolithic routine for processing a response.

Around 2013 during an employment interview at a company in the top 25% of the Fortune 500, the hiring manager mentioned her frustration with the number of her engineers who wrote monolithic main methods in JAVA. These "Big Bang" applications are not easily verified or maintained and defy all of the fundamental teachings in elementary first-year computing courses. They arise from haste, a lack of discipline, and limited training. As a result of the demand for development professionals in the 1980s and 1990s, many IT workers entered the field with only a year's technical training and a certificate of completion. They could write a COBOL program and were capable of reasoning about business processes.

Few knew the rudiments of algorithmic analysis which most college computing majors learned in their freshman year in the 1980s and some high school students of computing learn now. Most of these "certificate" developers had not had the learning experiences of a college computing student. This was not a reflection of their natural intelligence. Many were exceptionally bright. They simply had not acquired many of the skills of majors in computing at that time. As such, the IT world has experienced and is still experiencing some dysfunctional development practices inherited from a era when IT managers simply needed "warm-bodies" on their teams for billing purposes.

Case in point, in the early 1990s, while working as a COBOL programmer with only a freshman computing elective in Pascal and COBOL training, management requested an estimate for the completion of a "controlled-break" program. After a few seconds of assessing the requirements, the response was one person-hour since some of us are only capable of hunting and pecking. The manger smiled and said that she usual gives her senior people "one whole day" for a report and her junior staff  "a couple of days". Sensing inexperience, she smiled and said let me know where you are in an hour.

Thirty minutes of coding, fifteen minutes of verification, plus a nested loop and well-placed conditional later, this inexperienced, young coder was done. Arriving fifteen minutes early at the manager's desk with a "green-bar" printout of the report, she simply smiled and said "let me see what you have". She desk-checked the details lines through the first few break totals and the grand total. Looking stunned, she said, "This looks correct!". And she asked if she could see the source listing which contained less that thirty lines of processing instructions. She said "No one around here does anything this fancy."

This "success" resulted in many a headache after being alienated by some of the senior staff who had "old school" training in computing. This whippersnapper with a semester of university training in Pascal and structured programming plus a COBOL class from a junior college had caused a stir in the department by using a COBOL PERFORM statement in its loop format. Most of the staff was still using this statement as an alias for a GOTO which is one of its capabilities. This is simply how they were trained. The pattern of their standard solution for a "controlled-break" report required a number of "goto-style" PERFORMs which transferred control between paragraphs which are the equivalent of compound-statements in JAVA. After being chastised by senior staff for writing such a program, being told the a professional COBOL programmer writes these programs a certain way, and realizing that this simple departure from workplace norms could cost a job, all future reports were in that "old-school" style which has its roots in assembly language programming.

In summary, old traditions resist fading away, we also view new concepts through the lens of past experiences, and societal pressures often stifle advancement. Many of the first COBOL developers where experienced assembly language coders. So, they wrote and taught COBOL in an assembly language style which rest upon the use of large monolithic programs with branching commands that redirect the flow of the control abruptly and sometimes unexpectedly. Although COBOL allows for PERFORM statements that behave like a for, do-while, or while loop plus link-edited subroutines which promote a better partitioning of concerns and serve the purpose of a method, most COBOL programmers simply wrote large single module program with numerous "goto-style" PERFORMS. Although COBOL has numerous standards, 68, 74, 85, and etc., plus has kept pace with advances in computing such as object-orientation, most of it developers are mired in old practices. And, many of these COBOLers are still around and coding the "new-COBOL" with the monolithic approach when they can get away with it. It is simply a comfortable dysfunction for them.

CABOOSE lets these developers have the best of both worlds since they can write a single method for handling each dynamic concern within a page. This instead of a single method for handling the entire page. This approach facilitates better engineering practices by helping developers identify and isolate the code associated with concerns at a single point of modification. This should be a comfortable notion for both the "old-school" COBOL and the "renaissance-age" student of Pascal, since COBOL had the notion of an ENVIRONMENT, FILES, PARAGRAPH, and WORKING-STORAGE section and Pascal required that all of its variables, functions, and procedures be placed in a unique place in the program. Plus, both languages use the concept of  "constant values" whose values are set in a single location and used throughout a program. Modify a single point and affect the entire program.

The process of creating an HTML Storyboard naturally produces a partitioning of the dynamic concerns. This frees the coder from the cognitive task of identifying these concerns while simultaneously writing his web-script which is often done without much forethought or planning, a common dysfunction in the world of development. In short, a CABOOSE coder can simply be given a list of dynamic page concerns which he must populate. For each concern, he can produce a single method. This might not be the "ideal" partitioning in that some of his methods should possibly be subdivided; however, it does prevent the enormous "monolithic, big-bang" methods which perform all of the processing needed for generating all of the content for a single web page response. Plus, if one of the dynamic concerns within a page is incorrect when it is verified or validated, simply cross-checking the Storyboard template with the XML "directory" mapping file will provide the name of the method which needs correcting. Hopefully, it will be less than fifty lines of source code. This will improve debugging time when compared with locating an error in method spanning a few hundred lines.

This post is somewhat monolithic itself. Hopefully, it was not over burdensome for the "millennial-coder" of JAVA, .NET, or the LAMP Trio. Keep hunting, pecking, and thinking... The CABOOSE Team. Bing!

CABOOSE Philosophy Review

We promised at the beginning of this weblog that we would follow the KIS (Keep It Simple) principle. At times, it might seem that we have deviated from this. This entry is an attempt at simplifying the CABOOSE approach for those who are somewhat befuddled by the software engineering jargon and concepts.



A CABOOSE system with a model-view-controller architecture has five basic parts:

• The view, or rendered markup page which one will see in a web browser or viewing container.
• The page concerns, stencil tags, replacement variable, or placeholders in a user-defined form such as: #IDENTIFIER_FOR_REPLACEABLE_TEXT#. They are dynamically replaced with content from bundled methods based upon an XML-based configuration file. 
• The prepackaged controller kernel in the form of a servlet or JAX-RS web service. This regulates the flow of information between the model and the view based upon this same XML-based configuration file. 
• The model which contains the markup content with the substitute-able stencil tags which a browser might render, other external data sources, and the bundle of rendering methods which replace the placeholders in each page of markup with the appropriate content.
• The XML-based configuration file which maps between requested views and stencils plus page concerns and content rendering methods.

 

Hopefully, this will clear up some of the confusion. CABOOSE is an example of code reuse, in that, the controller is pre-written. Also, this greatly simplifies code development since that rendering method bundle is composed of simpler routines which return a formatted string. In the realm on JEE, many of the non-core JAVA concepts are abstracted out of the rendering methods. So, if you can write "Hello World" - style JAVA methods, you can use CABOOSE for web application development after a short and easy learning curve.

We apologize for letting the weblog sit idle for a few weeks. We have been working on a couple of papers again. The source for this project is available as a NetBeans archive in an earlier post. So, review and modify it as seems appropriate.

Happy Coding...Hunt...Peck...Think...La..La!!!

The CABOOSE Team