Cody Codes Code

This week, we learned about software requirements in the context of Agile, how they are created and changed throughout the software life cycle, and methods of tracking them. In Agile or behavior-driven design, requirements take the form of user stories, which are basic high level statements, often short, that describe functions in a program. User stories are accessible to both stakeholders and developers and can theoretically change and update often due to continual conversations between stakeholders and developers. A acronym to follow for writing good user stories is SMART, which stands for: Specific - User stories should state application/program behaviors clearly without any vagueness.  Measurable - Each user story should be testable, with expected outputs for a given set of inputs. These can also be performance requirements as well. Achievable - Ideally, each user story should be completed in one Agile sprint. If not, stories should be split into smaller ones. Relevan...

This week, we learned about basic project management and the basics of team collaboration in software engineering, including using VCS services such as git, GitHub, and BitLocker.  We also continued our discussion on test-driven development, including test automation. At work, I know several of my team members who have been working on automation efforts for certain tests for a long time, yet as far as I know it has not been an easy effort due to how complex some of these software items are. Five key principles in creating automated tests are FIRST, which is an acronym that stands for the following: F ast: Test cases and test subsets should be relatively quick and easy to run, as well as relevant to current coding tasks. I ndependent: Tests should not rely on preconditions created by other tests so only the subsets needed can be run. R epeatable: Tests should not rely on external factors that cannot be controlled, or values that cannot be controlled. S elf-che...

This week, we learned about test-driven development, different phases of software testing and methods, and how to write unit tests for Java programs using JUnit.  Test-driven development is about creating requirements for a piece of software, writing tests to pass those requirements, and then developing said software. If the software does not pass these tests, then development resumes until it does or requirements change, which means both tests and software will change. Compared to more traditional methods of "build now, test later", test-driven development ensures software meets requirements and quality standards for customer usage. In JUnit, "MOCKs" are simulated objects or variables that allow program testing without reading or writing real data, which could cause problems. They are also useful for testing invalid inputs without actually crashing a deployed application or live server (which nobody wants). 

I'm back to writing journal entries again! For all my readers who have missed me, it's good to be back. Currently, I am taking CST 438, which is the Software Engineering course. This week, we learned about the principles of software engineering, SaaS (Software as a Service), RESTful APIs, and wrote a program as an introduction to Spring boot with Java. Before taking this class, I was aware of some commonly used software engineering methodologies used today, such as Agile and Waterfall - in fact I believe most of the software development teams at work I know of use Waterfall, while I have heard of other groups in separate divisions following Agile practices. However, I was unaware of other ones such as RUP and Spiral, and I didn't fully understand how SaaS became widespread across the industry. After this first week's assignment and reading, I now understand that software engineering is more than just following Agile or Waterfall practices - the industry has chan...

This week, our class learned about implementing shadows in WebGL, how shadow maps and shadow volumes work, and the underlying math behind shadow maps. I found understanding how object space is transformed to light space and so forth somewhat difficult compared to previous modules where we worked with other parts of the rasterization pipeline, and it's something I need to spend more time on in the future. However, I was able to get my Utah teapot correctly lit and in shadow for this week's assignment, and I am satisfied with the final results. Overall, I learned a lot in this class, especially about linear algebra and how to think of it as transformations in space - I think that was the most important lesson I learned over the past eight weeks. Computer graphics are still fascinating to me, and I'm glad I understand the principles behind them now, as my whole computing life has involved interacting with graphics in some form yet I had never understood the mechanics of...

This week, our class learned about the principles of shading, including the physics behind light, different shading models, and how light interacts with different types of materials to produce colors human eyes see. I found this week's assignment more enjoyable and pleasant to create compared to last week, where I felt as if I spent a significant amount of time fighting JavaScript instead of implementing a solution. I enjoyed learning about the math behind Phong shading and how it is still used today in computer graphics due to its efficiency and ease of implementation relative to other shading techniques, even though it does not produce the most accurate results. I am looking forward to learning about shadows next week, as one of personal programming heroes, John Carmack, created a neat algorithm for shadow rendering in Doom 3, and since then it has become an industry standard technique. I didn't understand much of the technical detail behind it at first, but I'm sur...

This week, our class learned about texturing and shaders in OpenGL, along with how depth testing works and the visibility problem in computer graphics. From this week's material, I am now able to understand the principles behind projects such as replacing all textures in a video game with Nicolas Cage's face: Textures and filtering methods are more complicated than I thought, and I feel as if I need more time to understand them and implement them in future programs. Combining this with how textures interact with the model-view-projection matrices I learned last week, I felt as if this week's assignment was narrower in scope but more difficult than the introductory assignment in WebGL. However, I was able to get this week's assignment to produce the expected results by reading through the WebGL programming guide and plenty of resources on the internet (thanks Mozilla for your great documentation!).  My favorite part of this week was learning about all the differen...