Team. Inspired after a brisk walk on a treadmill, we felt enough motivation for zipping a couple of Microsoft Windows folders and placing them on Google Drive. The PHP archive contains the CABOOSE Type-II MVC and the StoryBoard archive holds the multi-page XHTML 1.0 CABOOSE site.
You will see that some trade-offs exist when the site is implemented as a CABOOSE MVC. First, a slight increase in the total number of lines of code occurred; however, the total man-hours were less. For one, each of the views share a single XHTML template. This provides a single location for any needed modifications. When building the storyboard, we started with a standard XHTML template and built the CABOOSE HomePage. After we produced a product with which we were satisfied, we replicated it and modified the core body content. Then while testing, a short revision cycle occurred. But, since we had a number of webpages, tweaking was required in more than one place so each page would have an identical header and footer. This increased the effort more than writing a couple of PHP methods in a page handler for returning the body content. The second downside of CABOOSE development it the computational overhead associated with using dynamic invocation in certain languages. In PHP, this in minor and only requires a couple of extra steps when evaluating an expression. We believe that it is not as expensive as using the reflective invoke in JAVA; however, this itself is not overly costly. Initially, JAVA reflective capabilities were extremely expensive in terms of computation cycles. The engineers at Sun greatly improved upon this time cost over the years. It is now minimal. But, a cost still exists; however, using the reusable CABOOSE kernel as a servlet or ViewEngine with Ozark has the potential for greatly reducing development effort. Consider structuring an development team as a tree after the initial storyboard which defines all of the dynamic content areas has been developed. The tier of team leads can partition the needed handler methods and any associated data transactions among their subordinates. Each of these subordinates is a leaf in a communications tree which resembles a top-down development architecture. Requests travel downward and the responses that result in the assembly of a complete system travel upward. This structure alleviates some of the communication overhead found in teams whose structure is a clique as described in the Mythical Man-Month. Trees are the sparsest of all connected graphs having at most n-1 edges which represents the bi-directional communication channels for n nodes or employees. In contrast, a clique structure has n(n-1)*0.5 bi-directional communication channels which lessen the effectiveness of crash cost when additional developed resources are placed on a team near a deliverable date. More communication pathways increase the possibility of miscommunication and added confusion in those last few hectic hours of a project. With the proper structure, the CABOOSE approach might lessen communication overhead and by supplying a better organization of concerns reduce time cost.
Also, although building a CABOOSE MVC might not be extremely simple for a novice developer, using this approach when provided the reusable controller likely has a lesser learning curve than other MVC products.
That is Enough Effort For This Weekend. Happy Coding.
The CABOOSE Team
Sunday, December 6, 2015
The CABOOSE XHTML StoryBoard Site as a CABOOSE-style MVC
Team. Hopefully, your week has been enjoyable without more fun than
you can handle. We are delivering a port of our PHP proof of concept
CABOOSE prototype MVC available on Google Drive as listed in an earlier
weblog entry. This port is a PHP CABOOSE MVC interpretation of our main CABOOSE site which is a storyboard of a few pages.
On the "home" page a hyperlink for the storyboard is along the bottom
which will place you in the PHP controller, and in the 'home' view of
the PHP MVC is a hyperlink which will teleport you out of the controller
and place you back on the storyboard. The source for the storyboard and
the PHP CABOOSE MVC will be available as zip archives soon. You will
notice that the PHP CABOOSE has been architected slightly differently
that out JAVA CABOOSE system. The PHP MVC was a quicker implementation
with more pecking and less thinking. So, some redundancy exists in the
structure of the xml mapping files. We will improve this in future
editions of the PHP CABOOSE which will serve as a point from which we
can nearly directly translate and produce our PERL and Python editions.
The core of a CABOOSE system is rather small and easily implementable in
a few hours. Feel free and experiment with the source code developing
your own CABOOSE-style systems in your own favorite language(s). Also,
as mentioned earlier this same type of dynamic invocation is useful in
developing reuse-able kernels for rapid application development.
This CABOOSE journey arose from a need for a more rapid and better organized web development paradigm for a single engineer or small team than was available during experiences working in corporate website development in the late 1990s. Over the following decade, while obtaining a pair of graduate degrees and staying somewhat abreast of web development approach, the initial idea of using dynamic invocation and a better partitioning of software concern that would "dazzle them all" still seemed viable, feasible, and needed. Reading Spring and Strut text plus creating simple tutorial applications produced the intuitive feeling that these approaches were missing something and were overly complex. Keep It Simple (KIS) is the first principle which most computing students learn. CABOOSE requires little beyond the web standards which already exist plus reinforces the notion that all we are really doing in web development is passing around strings of text. All of what we must be certain is simply that the strings are formatted properly and arrive in the proper place. Some might say that this is an oversimplification, but this is the essence of the principle KIS and the teaching of top-down architectural design. One can easily miss a forest when intensely focused on the branches, twigs, leaves, and trees.
The time seemed right for building a general-purpose extensible controller. Consider the general-purpose central processing unit which resides in the computing which you are using when you read this note. It can can process any computable function, but it must first be given the function as input. A CABOOSE controller can perform the processing for "any" MVC application on its platform when it receives as input (is extended by) the proper view handler classes.
This style of controller abstracts out a common core of behavior found in Type-II Model-View-Controller architectures and places it in a reuse-able package. In many instances, software engineering teams with "immature" development processes spending costly develop effort rewriting these behaviors. This effort could be expended in requirements elicitation, verification, validation, or documentation which are more crucial and often overlooked engineering tasks. We are not highly versed in agile methods which seemingly represent a compromise between the "ad hoc" status quo of development and the "mature" best practices which are formally taught. But, as is championed by many software engineering purist, module reuse is highly valued for agile teams who often must meet the demands of short project cycles.
Hopefully, CABOOSE will reduced the stresses of software development by providing a reusable product which is easily understood and used, reduces implementation effort, plus provides a foundation for developing a competency of repeatable development projects which will eventually produced measured, managed, and optimized levels of maturity.
We will have those storyboard and PHP CABOOSE archives available soon.
Hunt... Peck... and Think... Some is watching the sparrows...
The CABOOSE Team
This CABOOSE journey arose from a need for a more rapid and better organized web development paradigm for a single engineer or small team than was available during experiences working in corporate website development in the late 1990s. Over the following decade, while obtaining a pair of graduate degrees and staying somewhat abreast of web development approach, the initial idea of using dynamic invocation and a better partitioning of software concern that would "dazzle them all" still seemed viable, feasible, and needed. Reading Spring and Strut text plus creating simple tutorial applications produced the intuitive feeling that these approaches were missing something and were overly complex. Keep It Simple (KIS) is the first principle which most computing students learn. CABOOSE requires little beyond the web standards which already exist plus reinforces the notion that all we are really doing in web development is passing around strings of text. All of what we must be certain is simply that the strings are formatted properly and arrive in the proper place. Some might say that this is an oversimplification, but this is the essence of the principle KIS and the teaching of top-down architectural design. One can easily miss a forest when intensely focused on the branches, twigs, leaves, and trees.
The time seemed right for building a general-purpose extensible controller. Consider the general-purpose central processing unit which resides in the computing which you are using when you read this note. It can can process any computable function, but it must first be given the function as input. A CABOOSE controller can perform the processing for "any" MVC application on its platform when it receives as input (is extended by) the proper view handler classes.
This style of controller abstracts out a common core of behavior found in Type-II Model-View-Controller architectures and places it in a reuse-able package. In many instances, software engineering teams with "immature" development processes spending costly develop effort rewriting these behaviors. This effort could be expended in requirements elicitation, verification, validation, or documentation which are more crucial and often overlooked engineering tasks. We are not highly versed in agile methods which seemingly represent a compromise between the "ad hoc" status quo of development and the "mature" best practices which are formally taught. But, as is championed by many software engineering purist, module reuse is highly valued for agile teams who often must meet the demands of short project cycles.
Hopefully, CABOOSE will reduced the stresses of software development by providing a reusable product which is easily understood and used, reduces implementation effort, plus provides a foundation for developing a competency of repeatable development projects which will eventually produced measured, managed, and optimized levels of maturity.
We will have those storyboard and PHP CABOOSE archives available soon.
Hunt... Peck... and Think... Some is watching the sparrows...
The CABOOSE Team
Monday, November 30, 2015
The Time And Place For A PHP CABOOSE
Team. We have been working on developing our JAVA Enterprise Edition CABOOSE product which integrates with Oracle MVC 1.0, Ozark. Over the past weekend, we hand-drafted the CABOOSE site
which is currently a few static XHTML pages that have not been validated. If
one examines these carefully, one will realize that the header and
footer for each page are the same. The only unique content is in the
body of the documents. This "primitive" content can be factored out of
each page which will leave the base template. We can then supply this
template and the appropriate body content when a browser requests that
view.
In other words, the CABOOSE site is a good candidate for the model-view-controller (MVC) architecture. Unfortunately, the web hosting package for this site does not support JAVA Enterprise Edition development; however, it supports the LAMP technologies. So, we will spin a quick MVC for the CABOOSE site over the next week using the PHP Hypertext Processor (PHP). We already have the source since we used PHP as a prototyping language for the CABOOSE concept when we proposed a JAVA Specification Request (JSR) for a general-purpose web-script. We shared this PHP prototype with members of the JAVA Community Process(JCP) with a few instructions. Although not immediately accepted, the way in which CABOOSE project partition concerns creates a more cognitively accessible development approach. It also allows for a greater use of existing web standards.
The current PHP prototype is not highly robust; however, it is reliable enough for simple view handling. So, we have started making a few entries on our PHP CABOOSE weblog.
Have a Great Week.
The CABOOSE Team
In other words, the CABOOSE site is a good candidate for the model-view-controller (MVC) architecture. Unfortunately, the web hosting package for this site does not support JAVA Enterprise Edition development; however, it supports the LAMP technologies. So, we will spin a quick MVC for the CABOOSE site over the next week using the PHP Hypertext Processor (PHP). We already have the source since we used PHP as a prototyping language for the CABOOSE concept when we proposed a JAVA Specification Request (JSR) for a general-purpose web-script. We shared this PHP prototype with members of the JAVA Community Process(JCP) with a few instructions. Although not immediately accepted, the way in which CABOOSE project partition concerns creates a more cognitively accessible development approach. It also allows for a greater use of existing web standards.
The current PHP prototype is not highly robust; however, it is reliable enough for simple view handling. So, we have started making a few entries on our PHP CABOOSE weblog.
Have a Great Week.
The CABOOSE Team
Subscribe to:
Posts (Atom)