Yay! The first project of the semester. The project guidelines were fairly minimal to promote exploration of the p5.js library. It's mainly an art piece for show! My initial plan was to plot some repeated, staggered sine waves across the screen to create some form of geometrical art. Alas, I didn't even know how to plot a sine wave in JS! Okay, who does one turn to in that case? God? Well yes, the Google Gods. "p5.js Sine Wave" took me right away to this Sine Wave by Daniel Shiffman . Oh my, quite pretty. But as Professor Faas states, the purpose of this class is not to yoink others' code but rather to promote self-innovation and algorithmic thinking.

     Daniel Shiffman's p5.js Sine Wave utilizes an algorithm which builds an array based on how many points need to be plotted on the screen, and then increments through it with each key being an X coordinate of a point. He then inputs that X coordinate into a sine wave function and uses that output to map the y coordinate. Ultimately, he also uses the innate loop nature of the p5.js draw() function to add a second increment directly into the draw call that actually animates the wave by slightly shifting the entire theta start value and then redrawing the entire frame.

     Tangent time! I used to be a Biology & Neuroscience major and something that I've seen over and over and over and over (you're lucky I didn't use a for loop to repeat this!) is the dual helical structure of DNA strands. Frankly it's mesmerizing and I couldn't think of anything better than a systematically evolved chain of pentose sugars and phosphates binding to another opposite chain utilizing nitrogenous bases and dipole-dipole interactions. One problem... I can't model anything that advanced.

     Okay then, let's start simple. What do I want to accomplish? The core of my program is to have a sine wave and an opposite sine wave and line segments linking them. Daniel Shiffman already built the main sine wave algorithm but to fully understand it, I reverse engineered it with variable titles that made more sense to me and added more parameters. To have the opposite wave, my first idea was to use a cosine wave which I then remembered is computationally equivalent to a phase shifted sine wave. Great! The Line segments were not difficult either, just plot a line from the wave particle of one wave to the corresponding particle of the opposite wave. I initialized arrays that ran simultaneously with the primary wave calculation and render functions. One issue, it was dull. To give it some visual oomph I added an inconsequential multiplier which I called the dilation that applied a slightly larger wave amplitude for the actual particles to build space. I also added a computation that adjusted the elliptical particles' height depending on it's rate of change compared to the previous frame. Interestingly, this had the pleasant and unintentional side effect of creating a specialization effect, as if the particles were rotating on disks rather than one dimensional vertical translations. Fantastic! Lastly I added a bit of color to the line segments with if statements depending on the size of the line segments.

     Future work on this project should optimize the code to increase FPS and allow for more dense waves as well as make more meaningful aspects of the animation such that it's less 'Proto' DNA and more like actual DNA. Anyways, I had a great time learning about some basics of p5.js in this project and I'm sure I can apply some lessons to future projects!

     Exercise #1 primarily covers the basics of p5.js and utilizing control structures to modify visual behavior such as changing object colors or object movement. I mainly chose exercises 1, 2, and 3 in chronological order, but I'm fairly certain the code in Exercise 3 can be easily expanded to accommodate Exercise 4. As for Exercise 5, while its novel, utilizes the same basic concepts of declaring variables, initializing them in setup(), and then modifying values after using a control structure within draw().

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files do contain a similar structure of declaring variables outside of the setup() p5.js function, initializing them with values within p5.js's setup(), and then drawing pertinent and dynamic elements within p5.js's draw() function.

     A critical portion of the work is the algorithmic development. While I did not struggle with the code itself, I realized how 'stuck' I am in my ways of algorithmic development. For example, it was painstakingly boring to me to write out comments for the code describing the details rather than just quickly declaring variables, if statements, and draw calls. The issue though, is that I was writing my comments practically as code but in natural language. While I'm sure this is acceptable at this stage, it may be detrimental when the project is more complex - fixating on the code can become an issue.

     I also came to realize two other insights: 1) Optimizing code before fully fleshing it out can make it difficult to modularize later 2) Writing code with clarity and proactively declaring variables can make it easier to modularize code and apply it elsewhere.

     Exercise #2 primarily covers the utilization of functions on top of the p5.js basics to modularize code and increase utility and readability. There were only 3 available exercises and 3 that needed to be done so all were written. Exercise 2.1 draws a rocket at the mouse position and modularizes the rocket draw calls into a single function. Exercise 2.2 draws an inner circle with a randomly-generated color and an outer circle with the same color but the red component eliminated. Exercise 2.3 I'm not quite sure what the purpose of it is, but roughly simulates a loop of circles drawn in polar coordinate space?

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files do contain a similar structure of declaring variables outside of the setup() p5.js function, initializing them with values within p5.js's setup(), and then drawing pertinent and dynamic elements within p5.js's draw() function. Functions are written in a separate section after the p5.js draw() section.

     A repeated insight I've encountered while doing the exercises is that modularization can be difficult to implement immediately. For example, with the 'Drawing Drawer' exercise that repeatedly draws a composition, the most difficult aspect for me was actually creating the 'composition' in the first place. To get a sense of scale, I went to a random pixel drawing website and began just putting shapes on the pixel grid to get a general sense of space. Frankly it was a bit difficult converting absolute positions of the shapes to relationships in two-dimensional space between shape positions. For example, 'noseconeHeight = rocketHeight - fuselageHeight - finExtraHeight' is conceptually more difficult than just plotting the point. However, it comes with the advantage of creating an easily scalable composition that sensibly scales itself to the size of the display window! I experimented with ratios and proportions until I was both satisfied with the composition and the function scaled the composition as expected with its scale argument. For future work, I'd like to be able to isolate the background animation and the rocket drawing to remove the strobing of the random star generation within the background.

     With Red Remove, the biggest issue I encountered was the nature of JS referencing the original object instead of assigning a copy of an object. While there were many ways I tried to troubleshoot the issue of why modifications to the outer circle's color affected the inner circle, even before the modification call actually occurred, ultimately it related to the aforementioned. Nevertheless, I rudimentarily converted the p5.js color object to a string, modified the string, and then parsed the string as a color once again.

     The final exercise for Polar Points was relatively easy as Professor Faas already outlined the algorithm and the exact steps in the exercise description. However, I'm still confused by what the aesthetic or mathematical purpose of the exercise is. I played around with it and also built a rectilinear to polar conversion function just for the sake of a computation demonstration, but ultimately it was not the most useful exercise. Though, I will employ the idea of using vectors to carry coordinates in future exercises.

     The Object Exercises includes two exercises that retrofit objects into previous exercises and a new exercise to draw a set of user-interactive objects. While the exercises themselves are not fundamentally different, especially Ex3.1 which retrofits objects to the already-modular function-based Ex2.1, there is vast functionality attained with an object-oriented programming approach. The functionality is attained with the ability of objects to both encapsulate data as attributes and functions as methods which allows for incredible modularity. While Ex3.1 retrofits the rocket function to a rocket object with a draw method, and Ex3.2 introduces the Rectangle Class, it’s Ex3.3 that is the highlight of this set of exercises! It introduces a Vector class and a Color Fade class on top of the Circle class.

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files do contain a similar structure of declaring variables outside of the setup() p5.js function, initializing them with values and potentially objects within p5.js's setup(), and then drawing pertinent and dynamic elements within p5.js's draw() function. Functions and Classes are written in a separate section after the p5.js draw() section. All Classes contain similar drawing properties which are added via the constructor and then stored within the object.

     With Ex3.1, the retrofit of the function-oriented Drawing Drawer into the object-oriented Drawing Drawer, there was not much initial difficulty. Any temporary variables that stored individual properties of the ‘parts’ of the Rocket were shifted into attributes. And this area contains the greatest potential for improvement—as it stands, the Rocket Drawer uses a single Rocket object to store all values. But in reality, several subsets of those values are parts of the Rocket. In the future, I’d like to revamp the object hierarchy and introduce sub-objects into the Rocket object with individual draw methods and then use the main Rocket’s draw method to call the parts’ draw methods. Or possibly even store the Rocket parts as an array of objects to be stored within the Rocket array and then use a foreach loop to call the individual methods.

     With Ex3.2, a novel exercise which introduces user input, the concept was simple enough. The complication was self-introduced—I wanted to introduce a vector system based on magnitude and angle rather than component vectors. While in theory it was fairly simple, I forgot I’m not working on a calculator but rather a computer. The Y axis is inverted, which I did initially account for, and the Math.trig functions accept arguments in radians, which I did not account for. I also mangled the actual draw method due to misplaced variables in a translate and actual rectangle draw call. The aforementioned radian error was easily fixed, but the mangled variables were a result of improper planning and poor variable naming. I used internal variables within the draw method that were titled x and y which corresponded to the center of the Rectangle object, but I also had Rectangle.x and Rectangle.y which corresponded to the position of the Rectangle object. Troubleshooting took a second, but the errors were corrected. Notably, the p5.js push() and pop() methods were also self-introduced here to limit issues with calling multiple objects’ draw methods.

     With Ex3.3, the criteria for the exercise could have been accomplished as simply as creating an object literal for the ball and possibly velocity to Ex1.4. Another issue was that I did not do Ex1.4, but rather Ex1.3. While I could have done the same to Ex1.3, Ex1.4 evolved with OOP seemed far more interesting. Ex3.3 refines previous functionalities, specifically the random color fade using p5’s lerpColor interpolation function as seen in Ex2.2 Red Remover, as well as Ex3.2’s Vector concepts. Capabilities afforded by OOP also allowed for a more readable canvas object literal which encapsulated canvas width, height, and bounds. The lerpColor implementation in Ex2.2 used an inputColor, outputColor, and an intermediateColor. The inptermediateColor would use lerpColor to approximate a value between the inputColor and outputColor, and then overwrite the existing input color and then proceed to the next loop. Overwriting p5 Color Objects also required extensive decoding the color object into an array and encoding back into a p5 color object. Repetitive approximations also required fuzzy checks for cycle completion. In Ex3.3, I followed Professor Faas’s suggestion of using the actual Intermediate Color as the display color and incrementing the mixture progression parameter. This worked far better. I also went with an OOP approach as I wanted to encapsulate the incremented variables inside the object itself rather than as global variables. I also internalized the parse color function into the Color Fade class. The next critical class was the Vector class which I used a contemporary method of establishing using the ‘class’ keyword and a constructor function. I also used a static method as an alternate way of building a Vector object. The primary Vector object constructor utilizes a directed magnitude whereas the secondary ‘constructor’ uses component vectors along the x axis and y axis. Since the object stores information for both the directed magnitude approach and the component vector approach, I also created ‘rebuild’ functions that rebuilt any affected attributes upon changing one attribute. This represents the greatest area for improvement in this exercise. In the future, I’d like to use official setters and getters to moderate this information flow and to limit any issues with direct variable assignment. Other than that, this lab went excellently. The circle class was also fairly easy to program. As a finishing touch, I went through and found some JS code I used last semester to dynamically generate multiple objects on runtime using properties of the parent ‘window’ object. With this in mind, I then repeated actions in both the setup() and draw() functions with a for loop to repeat the actions to several circle objects and their corresponding attributes which resulted in a beautiful barrage of chaotic ball bounces. In the future, I might like to do a collision system between the balls, however, I suspect it’s more difficult and resource-intensive than I imagine.

     The HTML DOM Exercises are the first set of exercises to discard the p5.js library and rely entirely on vanilla Javascript. The goal of the exercise set is to establish the basics of interacting with the HTML Document Model hierarchy and its corresponding JS Object Model. This particular set modifies style properties of HTML elements utilizing event listeners.

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files contain a similar structure of potential JS Classes followed by any general JS which is then ultimately followed by any JS functions.
     Within the specific exercise set, all exercises have the same program flow of defining a HTML object as a JS object and using signature methods within a corresponding HTML Event listener.

     Ex4.1 was the basis of all the other exercises. The core functionality developed in Ex4.1 could be extended to encompass the functionality required in Ex4.2 and Ex4.3. As such, it was developed somewhat modularly. Initially, the Exercise used an algorithm as seen as in the pre-Application algorithm above: Create a JS Object Literal to represent attributes and properties of a HTML Object, Create the HTML Document Entity with the attributes of the JS Object, Create a Function to accomplish the desired functionality and enact it on the JS Object, and lastly update the HTML Document Entity.

     The first issue came in the form of extraneous amounts of repetition. Each attribute and property was developed individually and the solution was to take advantage of the 'forIn' loop and iterate through Objects as if they were associative arrays. However, I needed to call specific JS Methods to alter the HTML element's properties. The only method I could gather from Googling was using the Window object and using array notation to call the methods. However, the Window object only stores global variables and usage of global variables created issues with scope. With Professor Faas's help, I realized array notation could be applied directly to objects and that rapidly improved my code.

     The final iterative stage came in the form of shifting from an 'object literal with paired functions' approach to a 'instantiated object with instance methods' approach. This would maximize the modularity and minimize unique code. This conversion was a bit troublesome due to typecasting and my realization that classes do not benefit from the same program flow exception that functions do. Nevertheless, the class's completion dramatically minimized code outside the class. Any methods with moderate utility, such as the scale method of Ex4.1 and the colorChange method of Ex4.3 were directly implemented into the class. Extending the code from Ex4.1 to Ex4.2 resulted in a few errors mainly from artifacts of the initial functional approach but they were quickly resolved. Ex 4.2's signature 'mcDiv' function was modified to accept the HTMLasJS object rather than an HTML element.

     Overall, I'm quite happy with my solutions to exercise set 4. While the final solutions do not look spectacular, and that is definitely an area for improvement, the backend is highly modular and can be iterated on for successive sets of exercises. The process in this week's code made me more intimate with the nature of JS and its objects. Functionality I thought that didn't exist was elucidated to me in the form of Objects and their array notation in JS. I'm very excited to see how this information can benefit my future exercises.

     The HTML Array & Loop exercises iterate on the previous DOM exercises but emphasize creating and updating HTML DOM entities using loops and arrays. The goal of the exercise is to apply iterative and recursive algorithms to HTML DOM entities.

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files contain a similar structure of potential JS Classes followed by any general JS which is then ultimately followed by any JS functions. Within the specific exercise set, all exercises have the same program flow of defining a HTML object as a JS object and using arrays and loops to reach the desired output.

     Ex5.1 simply requires one div with a list of incremented numbers. It simply requires a loop to generate the inner HTML content and place that content within a created div. The HTMLasJS class was used to generate the div and each loop increment iterated upon the previous inner HTML content of the generated div. This exercise was fairly easy. The only change in the future would be to make it more visually appealing.

     Ex5.2 is similar to Ex5.1 in that it is a div with a list of incremented numbers. The same logic applied as to the div generation and inner HTML generation. The distinction comes in form of the logic tree required to transform specific numbers to arbitrary strings based on their factors. Sequential conditional logic was used to perform the logic checks for the transformations. Other than that, this was a fairly streamlined exercise.

     Ex5.3 was perhaps the most difficult, but difficult of my own making. The original exercise calls for a previously-sorted array but I decided to generate a random array with a random order. As such, I needed an algorithm to sort through the elements of the randomized array. Creating a sorting algorithm was difficult but the one I’m most innately familiar with is the selective sort algorithm but I decided to try a bubble sort algorithm. The logic was not too difficult but there were small syntactical errors which were easily corrected. Once the bubble sort algorithm is applied to the randomized array, the sorted array is iterated through and a new HTMLasJS object is created for array element. Each object is created as a sub-object of the Window object. Some small conditional logic is

     Ex5.4 utilized the same logic as Ex5.3—an array iterated through with each array element having a corresponding div element. In this case, it was actually easier than Ex5.3 as there’s no sorting mechanism necessary. The same remarks about extending property functionality from a super class or extending functionality to a child class in Ex5.3 apply here as well.

     Overall, while the exercises in set 5 were not stunning, they demonstrated the functionality achieved from the HTMLasJS class initially built in exercise set 4. In that form, the exercises were a great success as there were only minimal modifications, mainly a setInnerHTML method, required to attain the functionality required to complete all exercises in set 5.

     The HTML Midterm exercises are relatively advanced exercises that take advantage of all the previous skills learned in the class—which includes but is not limited to: HTML DOM Manipulation, Array Iteration, Function Definition, and HTML Event Response. The exercises are more advanced, but both ultimately represent simple applications in which a program responds to user input and runs a one-step function to create change on the HTML page.

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files contain a similar structure of potential JS Classes followed by specific variable declarations, and then the general JS to complete the program. Within the specific exercise set, all exercises have the same program flow of defining multiple HTML objects as JS objects and then using that modify the page and respond to user ‘click’ events. They both log activity to a console of sorts.
     ...

     Ex6.1 is a bit rough around the edges compared to Ex6.2. Ex6.1 utilizes an extended class to implement the UI Buttons that will be the interactable buttons. The base class provides a majority of the functionality but the extended class allowed specific functionality for the GUI. The implementation is definitely convoluted with setHighlight and unsetHighlight Methods which are relatively simply but did not require the extension of a class. And perhaps they could have been integrated into a single method that toggles the Highlight status. Furthermore, the log method implemented in the UIButton Class is very specific and not scalable. As such, it’s not a great use of OOP principles. Nevertheless, Ex6.1 made me comfortable with extending classes. To improve it, I would add a mouseover event listener that sets the cursor to a pointer. This was implemented in Ex6.2, but definitely could be added to Ex6.1. Other than that, the application is pretty simple, and there are mostly GUI tweaks I would have done given more time or priority.

     Ex6.2 polished some of the functionality introduced in Ex6.1. Two such examples of polish include the discrete ‘Console’ Class that contains a class with functionality to log elements to an in-HTML console that is visible to the end user and also the slight CSS to switch the mouse cursor to a pointer on hover of the UI Buttons. Ex6.1 used some overly-complex code when the HTML as JS Class comes with a parameter called ‘extraAttributes’ that can store extra information that is extremely convenient in a situation where other buttons need to be deactivated on one button’s activation. While the Buttons did not implement the functionality to change colors on activation, the console elements do and that functionality could be mirrored to the buttons in future exercises. A fun aspect of Ex6.2 was the game logic itself. Using a 2D Lookup array, or in my case, a 2D Lookup object, can simplify the Boolean logic. In terms of saving time, a 2D array would have been faster to implement and I assume run, but the 2D object is simpler to understand as it’s in natural language. To advance exercise 6.2, I can’t think of much other than refining the GUI.

     TBD!

     The following is my pre-programming algorithms for Exercises 1, 2, and 3. Please note this button takes you directly to the '.js' file that contains comments.      All files contain a similar structure of potential JS Classes followed by any general JS which is then ultimately followed by any JS functions.
     ...

     TBD

     TBD

     TBD