CST438 - Week 5

Summarize in a few sentences what you have learned this week.

This past week was fun getting to put together the UI frontend to the group project. It helped reinforce the previous week's lessons of using React. I think what I learned most this week was how it's important to have a group project planned out so everyone is on the working towards the same end result. In a group project such as this, where everyone is making tiny tweaks towards a UI, it's easy to get into a state where one person's work is visually much different than other group members work. And while logically and functionally correct, these little differences can add up to make the project feel sloppy or disconnected. Maybe it's why a more structured approach to UI design (using templates, or css bootstrap, etc) is used across bigger projects with multiple contributors.

Read More

CST438 - Week 4

What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?

 I think one of the biggest take aways from reading "Software Engineering at Google" thus far for me is all the work and effort around programming without actual programming, but it makes sense.  When programming in school, your program is one assignment long, or maybe one course long, but in a professional setting that program you write or edit, that's probably going to go on needing to being used and depended on for a long while. Or when programming for yourself, you don't need to worry as much about things like readability or styling, but working in a larger group you need other people to be able to understand your programming your thought process so they can utilize your work.

Read More

CST438 - Week 3

Describe what are the good points about using Git for source code management.

• Helps enable distributed development by allowing multiple developers to work on the same file/project at the same time. Services like GitHub or GitLab build a whole ecosystem around Git to foster a more productive workflow for all
• Git allows people to create branches of a repository so one person's development doesn't interfere with another's
• When it's time to bring those changes back into the main code branch, Git handles merge the changes in. Most of the time it's fairly automatic, but even when there are merge conflicts Git helps show the differences and helps you make a choice on how to proceed.
• Enables tracked revision history - so it's easy to see changes to a file over time by what author

What are possible problems that Git merge does not solve when merging code from different developers?

• For one, even after a clean successful merge, the code could still not work correctly. Changes from one developer can effect the changes from another developer and have unintended consequences. Or changes from two different branches can effect the logic of the overall method/program.
• Git merge doesn't enforce any syntax conventions or style conventions amongst developers
• Dependencies - a Git merge doesn't enforce any dependencies that might be different between two branches.

Read More

CST438 - Week 2

In lab 1 on Junit you used a Mock.  In your own words describe what a Mock is and why it is useful in unit testing. 

In lab1, after creating our API endpoints we needed a way to verify that they were working properly as expected; meaning when we hit the end point we got the expected/proper data returned, or when we supplied bad data to the end point it returned with the correct failure response. You can manually test this during development of course, but as your API grows larger and has more complex interactions, it becomes harder and harder to quickly and reliably test changes that you make haven't broken anything. That's where unit testing can help out. Creating small, narrow, specific tests to ensure that changes a developer might make don't break things (in sometimes unexpected ways). In order to perform unit testing for a REST API end point, we need to have a functioning sever (and database) and have it populated with known data. What we're doing is using a Mock of a real world setup of a server and database where it contains valid (or sometimes invalid) data that we know about ahead of time. This way we can write small, targeted tests against that data ensuring our API endpoints are working as expected. Mocking up this fake but valid data is often much quicker than setting up a real server and database. It also lets you muck with data that you don't have to worry about if you accidentally mess up and delete or corrupt a database because of a new change you where implementing.

Read More

CST438 - Week1

What did you expect a course in Software Engineering would cover?

I'd expect a Software Engineering course to focus on covering how programming works in a professional environment. Learning how to program and programming for your own enjoyment is much different than understanding how to programming on a team, or how to plan out a project, or how to handle the multitude of issues that will crop up with programming in a business environment. Things you probably don't often thing about or associate with programming.

After completing week 1, how has your opinion changed? 

After the first week, I think my opinion remains about the same. After reading the first chapter of Software Engineering at Google, it reinforces my belief that the actual work of a programming, in a progressional environment, involves a lot of working that isn't actually programming.

Read More