Cody Codes Code

It's the end of a long, four year journey, and what a journey it has been. I never thought I could pull off finishing my second bachelor's degree four years ago when I first went to that introduction to programming class at my community college. I would like to thank all the friends I've made along the way and the people who have helped me through the last two years. Although it was difficult at times taking class while working 40+ hours a week, I'm proud of myself for making it through. I don't think I'll be a student enrolled in classes anytime soon, but I'll always be a lifelong student. See you all around.

This week, our group finished recording and editing our capstone project video and prepared our presentation for the capstone festival. Although I wish the capstone festival was held in person (and it could not due to current circumstances), I am excited to show off our project and hard work to other computer science students, friends, and family. I hope they'll enjoy it and learn something cool while doing so. 

This week, our group made the last touches to CONVEE, our AAC application for our capstone project, and then we proceeded to record and publish the (first) draft of our video (if it's approved, it'll be the last draft). I'm very proud of the three of us and what we have accomplished a little over eight weeks. It's been rewarding to watch our application grow from the initial planning stages to what it is now. Abby plans to take over CONVEE after capstone and expand on it further, and I'm positive she'll do great things with it in the future. I might still help out with development and other related stuff once in a while. I also took the ETS Computer Science Field Test, which was a very disappointing experience. First, the test is too wide in scope, and it is littered with questions about specific niche topics not always taught in classes. Second, setting up the testing application was slow and awkward, and I had to wait 30 minutes for the proctor to set everythi...

This week, our group completed a major milestone in our project by finishing the front end of our application, marking it as a "feature complete". We also conducted our initial round of user acceptance tests and received plenty of useful feedback, comments, and suggestions for the final stages of development and eventual deployment.  As a test engineer, I also interact with end customers doing software system test, so I understand quite well the process of conducting tests and then signing off said tests if they meet all requirements as specified. Since my company must comply with Department of Defense standards, the "rules of engagement" for testing and product acceptance are much stricter than our standards for capstone, but I can imagine similar rules would be applied to other students doing industry projects. Also, I got my first experience writing a test procedure from scratch by myself, as even at my job I am not responsible for writing procedures but I am acc...

This week, our team finished most of the major features of our application, CONVEE - aside from front end style components and changes to the user settings page, our application is almost feature complete. I am proud of our group for our accomplishments and making it this far in the program. Additionally, we also finished updating our ILP pages and put together our video outline for the project video. As I have a good amount of experience now in video production (I have edited almost every single required video in each class I've taken so far, both solo and group), I am looking forward to producing this one. This week's topic covered job interviews. I don't have much experience as an interviewer myself, but one of the tips I received from my manager about interviews was to answer each question confidently, even if you feel like you don't know the answer. I feel as if that approach can backfire at times, however it's always good to approach a new or unknown situa...

This week, we finished our ILP portfolios and turned in the final versions of our resume and cover letter. My group also completed the first part of the capstone report. I'll admit that creating a portfolio showcasing my past work was not at the top of my priority list when I first started studying computer science, although at this point in my educational and professional career I've learned how important it is to have such a portfolio. Like other creative professions, having a solid body of work to show to a potential employer, or even for personal documentation is one of the best ways to display your talents as an engineer. Also, all the assignments I've completed during my academic career, both at CSUMB and elsewhere, have given me a good start to my portfolio. I tend to prefer classic, plain styling like  Brian Kernighan's  home page (he has a pretty nice portfolio too), although I've come to appreciate highly stylized portfolios that make use of WebKit ani...

This week, our group continued working on the current iteration of our capstone project. Sebastian has done a fantastic job so far setting up the baseline code/master branches for both the client and server, and we have a good starting point to expand on. Progress is going well and development continues. For our group meeting this week, there were several items/tips/good practices from the "Effective Meetings" week that we followed:  1. The purpose of the meeting was clear: similar to a Scrum meeting, we discussed current work in progress and what was finished last week, along with any technical issues in development. 2. Agenda was clear and on topic. 3. Action items were discussed and assigned. Since I've been back to work in the office and lab and attending daily scrum meetings for software test over the phone, I've been making note of what I think is effective regarding teleconferences and trying to implement them into our own group meetings.  Resume ...

This week was the official start of CST 499 and our group's capstone project. I'm working on an AAG application along with Abby Packham and Sebastian (Juan) Delgado, and our project is off to a good start. For this week's reading, I read an article on how to conduct effective meetings. As a full-time software test engineer, I attend daily scrum meetings about thirty minutes long and have attended many types of work meetings, both long, short, formal, and informal, in the almost three years I've been at my current job. The most common pitfall I witness in meetings is getting sidetracked and losing precious meeting time, or conducting meetings that weren't necessary. I find this tends to happen less at work during large meetings that feel more like announcements or seminars and more often with groups of two to twenty people. However, in my career as a student, this has happened in meetings all the time. Although the majority of meetings I've attended at...

This week marks the end of CST 438, and a short, yet intense learning experience about software engineering. Although the work load was tough at times, and especially during unprecedented events happening in the world at the same time, I feel proud of myself for making it this far. I learned a lot of useful things in this class that will definitely help me out in my current job working as software test, and in any other future jobs/careers I might pursue in software. Five things I considered the most important are: 1. Always create requirements that are clear and concise, along with getting all stakeholders to agree on these requirements. This allows for efficient development and realistic goals when making an application, and also wastes less time and resources if conflicts arise over what requirements are/aren't wanted, or in the worst case having to change requirements and lose time by starting over on certain aspects of the project. 2. Microservices are powerful, modular ...

This week, our team finished the third iteration of our project and got all the basic functionality, front end, and back end components working. We had some initial problems with front end form submission and querying our database for certain data fields, but we eventually solved these problems which finally lead to our front end and back end services communicating correctly. 

This week, our team continued with our third sprint to get the third iteration of our project up and running. We focused on finishing our application's primary functions, such as searching for restaurants, displaying menu items as a list, and adding items to a cart to check out and place an order. Our next sprint will focus on front end styling such as CSS and HTML items, as well as refining some back end 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...

This week, we learned about rasterization, OpenGL and WebGL basics, and how the graphics pipeline works. Learning about each step in the graphics pipeline took quite some time to understand, but I found the process of learning it rewarding. Rasterization forms the basis of how most real time computer graphics are generated, and it's something that I have heard much about throughout my years using a computer and interacting with graphics, but didn't understand until now. What was the most difficult for me at first was understanding how transformation matrices, which we covered last week, work together to "convert" 2D primitives into 3D objects in an arbitrary world, and how they are also responsible for determining what a user sees on a screen and how they can manipulate that view. Working with OpenGL/WebGL was much easier relative to the ray tracer from Module 2, even though the code I worked on this week wasn't as concise and elegant as the ray tracer's...

This week involved learning about matrix math, how matrices are used in graphics programming, and how matrices are especially important to graphics programming as they are used to represent transformations of 2D and 3D space - which is the very nature of computer graphics. Implementing matrix3.js and matrix4.js was more difficult to me relative to vector3 and vector4 due to my little experience working with matrices, but once I figured out the mathematical concepts both APIs came together smoothly. I still need to spend more time wrapping my head around the more abstract concepts of matrices and thinking of them as representations of space transformations other than rows and columns of numbers to be multiplied, but after watching 3blue1brown's videos and reading some resources online I feel as if I have a better understanding and appreciation of them than I did before. Out of curiosity, I looked up Unreal Engine's 4x4 matrix API documentation  and I was pleased (and surp...