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.
Saturday, March 12, 2016
Wednesday, March 2, 2016
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.
Hunt. Peck. Think. Happy Coding.
Wednesday, February 24, 2016
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.
Hunt, Peck, Think, And Keep a Song in Your Heart!
The CABOOSE Team.
Saturday, January 30, 2016
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!
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!
Friday, January 15, 2016
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:
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
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
Sunday, December 13, 2015
Web Application Using CABOOSELibrary.jar | NetBeans ZIP Archive CABOOSEServlet | Export<->Import
Team. This evening we exported a simple web application which extends the caboose.core.extension.Servlet class, without any method overriding and after commenting out the primary processing method, in a servlet called Cabbie. It is a simple "Hello World" example of CABOOSE in action. This zip archive can simply be imported by NetBeans, and the application should run after adding the library dependencies. We will do our best and have a meaningful tutorial available online soon.
Hunt...Peck...Think...Happy Coding...The CABOOSE Team...
Hunt...Peck...Think...Happy Coding...The CABOOSE Team...
Saturday, December 12, 2015
CABOOSE | *.jar | JAVA archive
Team. We finished the first part of our JAVA archive for CABOOSE. This was the extensible servlet. The archive is available now and a tutorial describing its use will be placed online soon.
The CABOOSE Team
The CABOOSE Team
Subscribe to:
Posts (Atom)