This week my team and I did our second sprint on our final project. I continued to extend out the needed functionality to save entities to our database. I had to read up on Springboot documentation to learn how to define OneToOne and OneToMany relationships in the entity classes so that entity data was saved to our database correctly. I quickly discovered the importance of TDD (test-driven development) as my tests allowed me to organize functionality before integrating the logic into a controller.
During our third sprint, we will continue testing and focus mainly on front end design — making everything look pretty. We’ll wrap up by creating a demo video of our finished product.

This week we began our group project and started and finished our first sprint. Our project, Food Flight, is an application like Postmates or Doordash that enables a user to order food for delivery from any participating restaurant.

Our application is built around microservices that:

• expose data to restaurants to get order information
• expose data for a delivery person to get order information
• expose data for the user to get order update information

Our team is rotating the Project Manager and Scrum Master roles weekly so that we each get a chance to experience at least one of these (we have a team of four). This week I was PM and led my team in prioritizing and assigning points to stories for the first sprint. I also set up our GitHub repos so that none of us can push directly to the master branch. This is to ensure that we all adhere to code review procedures before anything is merged to our master codebase.

I felt that communication was a little lackluster during our first sprint, which is understandable since we’re in a global pandemic and everyone undoubtedly has things going on. But I hope that now that we have an established codebase, communication will be a bit better moving forward.

When talking about requirements, SMART refers to the following qualities:

• Specific
• Measurable
• Achievable
• Relevant
• Timeboxed

Specific

Specific requirements are ones that pair a vague feature (e.g. The user can search for a movie) with a specific qualifier (e.g. by its title).

Measurable

Making a requirement measurable ensures that it is testable. For instance, we may have a requirement that an end-to-end response time for a feature should be less than 3 seconds.

Achievable

Achievable requirements are those that can be completed in a single sprint or iteration. Larger requirements can be made achievable by breaking them into smaller components.

Relevant

A requirement is relevant when it has business value to stakeholders. In order to drill down to what is most important for stakeholders, asking the “Five Whys” is key.

Timeboxed

Development on a requirement is timeboxed–all work stops at the end of the sprint. If the requirement was unachievable, the remaining work can be rescheduled as a new story. If necessary, the requirement can be further broken down into smaller requirements that are attainable. It is also possible to scrap the requirement.

Crafting good requirements or user stories means adhering to these SMART guidelines.

FIRST properties refer to the software testing properties:

• First
• Isolated/dependent
• Repeatable
• Self-validating
• Thorough/Timely

Fast

This is the idea that we want a quick feedback loop. If our tests aren’t fast, we won’t want to run them often. If we don’t run tests often, it becomes harder to isolate problems since we may have introduced several new additions to our code since we last ran our tests.

Isolated and Dependent

Tests should only invoke the method under testing. Other functionality should be stubbed out and asserted. By building the necessary state for your test case, it becomes easier to understand the situation that your test case describes.

Repeatable

Tests should have deterministic results. If test results are highly variable, then they are not reliable. The results of tests should not be affected by the order in which they are called or how many times they are run.

Self-Validating

This is the concept that tests should be able to automatically resolve whether a test has passed or failed. We shouldn’t have to manually inspect the results to determine a pass/fail.

Thorough/Timely

A test suite should do a thorough enough job in covering test cases in order to be confident enough to push the code to production.

Through test-driven development (TDD), writing test cases first can aid in making testing itself timely (i.e. when you need them!) If you let your test cases guide your implementation, you repeatedly test until you meet the expected functionality/behavior.

Additional Resource: https://hackernoon.com/test-f-i-r-s-t-65e42f3adc17

Test Driven Development (TDD) is about developing tests for your application’s functionality before actually writing any code. In this way, your tests guide how you approach implementation.

A mock is a way of stubbing functions/methods that you may or may not have developed yet and providing mock data and results for those functions. In this way, you are able to isolate testing on one defined function that depends on those stubbed out functions. This way, you can isolate any problem to the function you are testing without worrying about implementing those other functions OR (if those functions are already implemented) errors introduced from those other functions.

Before starting this course, much of my understanding about software engineering came from my summer internship with Qualcomm and my current internship at Achieve Internet. Software engineering is a way of applying engineering principles to software development in order to maximize software’s business value. There are several methods of doing this, as our text explains.

During my time at Qualcomm, I helped manage a product being developed by a business intelligence team in Hyderabad, India. We used Agile to develop product stories that would result in incremental prototypes.

But I also gained exposure to the Waterfall software development cycle while at Qualcomm in developing my own project — a RESTful web API. My mentor and I chose this development cycle so I could a) be exposed to multiple software development lifecycle methods and b) be able to take a good 6-8 weeks to scope out my project and develop a first working prototype (this choice was due to the length of my internship).

Since I’ve started interning at Achieve Internet, I have also been exposed to the Spiral development model and how the various people at Achieve (Project Manager, DevOps engineer, developers, etc) play a role at different points of this model.

While my definition of software engineering hasn’t changed since reading the text, I appreciate the solidification and verification of my existing knowledge and experience. I am looking forward to this class!

For our final project, we had to integrate everything we learned in the class to create a partial model of our solar system with the sun, Earth, and moon using JavaScript and WebGL.

The only lighting in this world comes from a diffuse point light situated at the position of the sun. The sun and background have emissive lighting to show the full color of their texture. The Earth and sun are only lit by the diffuse point lighting.

All of the celestial bodies rotate about their y axis, but at different rates. The Earth revolves around the fixed point of the sun, while the moon’s revolution around is a bit more complex since it revolves around the non-fixed position of the Earth.

Although the model can be improved, I am pretty happy with the result since I had zero experience writing shaders and have not taken math since Calculus I ten years ago. This class involved some understanding of Linear Algebra, which I was able to follow along well enough to to find success in this class.

In our penultimate week, we learned about shadow mapping–specifically, casting shadows from a single directional light. First, we had to render scene depth from the point of view of the directional light into a texture. Next, we had to re-render the scene from the eye, determining whether each pixel was in shadow (by using the depth texture created in the initial rendering).

Continuing with WebGL, we implemented directional lighting Phong shading–a combination of ambient, diffuse, and specular lighting. Each of these three components are computed as a function of the light and surface material properties.

Diffuse lighting is view independent since it is uniformly distributed. However, the orientation of the light impacts the intensity of its reflection. This is represented by the lambertian term (derived from Lambert’s cosine law). Specular lighting, being non-uniformly distributed, is view dependent.

To test the Phong shading, we can manipulate the viewing angle of the world as well as the orientation of the light. While the ability to manipulate the view matrix was previously completed, we added the ability to rotate the light orientation (a vector) about the X and Y axes using rotation matrices:

As a bonus implementation, we were given the challenge to implement point lighting with Phong shading:

This week, we covered texturing and transparency. We focused on applying textures to objects in the world space. In this world, we also had three spheres of varying transparency, and we had to use the painters algorithm for in order to render the entire scene correctly. You can see the results below!

In addition to the required assignment above, we also tackled some of the extra credit parts of the assignment, animating a texture and using multiple textures. You can see in the rendering below that the texture is not only animated (try not to get sick), but the original texture is blended with another cute bunny texture.