In an earlier post, we mentioned the web apps being developed by Tony Butterfield. His web apps have a different structure than ours, and it is interesting to compare these two approaches. You can view the source code of the web apps by choosing View Source in your web browser.
Butterfield’s web apps have a single method that updates the state of the simulation at each time step, vs. our process unit objects, each of which contain a method to update themselves at each time step. For plotting, his web apps record variables values at each time step in each variable object, vs. our 3D numeric array that records the history of all variable values, with individual process objects storing only their current values.
Both approaches work, and it is valuable to have a choice for web app development.
I was interested to learn about the work of Margaret Hamilton, who was awarded the Presidential Medal of Freedom yesterday. As a young woman, she led a team that designed the flight control software for the Apollo moon landers. This period was during the early days of computer programming when software design practices were just starting to be invented. Hamilton developed a theory and methodology for “design before the fact” of fault-free and fault-tolerant, real-time software control systems. The class of systems considered are asynchronous, discrete-event systems. This includes chemical batch process scheduling and control. Our web apps simulate continuous processes. Design Before the Fact contrasts with the development strategy we use, as outlined in my last post, but we will learn from Hamilton’s work.
Also at the ceremony at the White House yesterday, Grace Hopper was posthumously awarded the Presidential Medal of Freedom. She was an early pioneer in computing, invented the first software compiler, and popularized the idea of machine-independent programming languages.
The goal of our Web app experiments is a toolbox that enables development of interactive web simulations (“labs”). Our development practice is as follows.
First, Get something up on the screen. Often this involves finding an example on the web and modifying it. Don’t spend a lot of time designing and thinking before something simple gets running. We believe that it is better to get something useful running than it is to have a beautiful plan and theory in development but nothing working to show for your time.
Second, repeat the following:
- Add functionality.
- As we observe repetition of code and see patterns developing, generalize the code. Have the objective of maximizing code in libraries and minimizing code needed to build new labs.
- As we observe patterns developing in the user interfaces, refine the design of a user interface guideline that is as simple and general as possible in order to speed development of new labs and speed user comprehension when entering new labs.