CST 499 - Week 16

I loved being able to look at the journal entries over the last two years. Some interesting things I noticed:

• I set a goal and guessed that I would score 80-90% on the ETS exam and I achieved that ✔
• My capstone project idea was mostly the same from the very first class, so it was really cool to see it come to fruition. One post had an idea for and additional feature for the app -- in the future I think I would like to try to implement it.
• Some of my weaknesses are still my weakness -- computer architecture and database design. This is something I can definitely work on in the future to grow further as a computer scientist, especially with regards to database design. I would love to go into game or app development, both of which require a lot of database management.
• Seeing the posts about algorithms and logic made me especially nostalgic. I love the beauty of a good pattern and seeing these posts reminded me that a project or a job doesn't need to be stereotypically "fun" for me to love it. 
• One thing that I understood conceptually, but hadn't used too much in code at the time was the idea of concurrent tasks. If anything, the capstone project showed me just how important knowing how to manage asynchronous tasks can be.
• I don't think that I took the idea of a plan or design seriously enough when going through the classes. I would say that I was definitely "anti-Plan-and-Document". When learning about the Agile methodology, I thought "this is perfect for me", because it leans itself to short bursts of focus instead of laying out an overwhelming amount of things to get done. The capstone project really showed me the value of having a well-thought-out plan, because I cannot count the amount of times I had to re-factor code for this project because I ended up needing to pull additional data from the database or had stored it in a way that didn't make sense for access later.

  Overall, I loved this program. I learned a lot and made a lot of good connections with other classmates. I grew as a developer and a student. The only thing I'm nervous about now is starting a job search. I don't think that I'm one to perform well code-wise on the spot, but I'm excellent at getting any task accomplished with access to resources. My next steps will be building my portfolio and hopefully continuing work on my capstone project and figuring out how to get my can-do attitude translated onto a resume.

CST 499 - Week 15

 This week I focused mainly on updating the home feed and improving the UI. Based on tester feedback, I updated the home page to include color-based styling and a more obvious layout for showing information. I also added a recycler view at the top to display a user's last three matches and the result to play to the competitive side of most gamers. I wouldn't say we had problems this week.. But we did have several opportunities for improvement, so there have been a lot of re-factors and re-designs based on collaboration and feedback from others. Tonight and tomorrow we will continue to fine-tune the aspects that we can and hopefully implement at least a barebones version of our last feature (displaying user statistics).

CST 499 - Week 14

 My biggest accomplishments this week were re-designing the home feed and match view pages. The overall look feels cleaner, more informative, and more efficient. I'm still working on how to design the stat page, but I'm struggling to decide on a sleek design that gives the data, but maintains a fun delivery. This week, I plan to settle on the layout and implement at least one dynamic achievement per game. For example, figuring out how to create and award (appropriately) a "Played Azul for the first time" achievement when Azul is played for the first time by any user and extending this to work for all games on their first play. My struggles this week were less challenging and more tedious. For example, while re-designing the feed layout, I decided to include user avatars as part of the display. However, I did not originally include the users in the "Feed Activity Model", so I had to re-work some code to make sure that I was able to do that. That aspect now works well for any new Feed Activity, but I haven't backfilled old activities to include photo URLs yet. A bonus while testing this though.. I accidentally discovered (and have now fixed) a bug with the login metric that was preventing the login_count from incrementing when a user logs in for the first time.

CST 499 - Week 13

 This week I was able to modify the View Events activity to view active vs past events differently (which is closer to our desired Figma design). This involved calculating the duration of an event, pulling which users and which games were played at said event, and displaying them visually with the use of small icons in both the event landing page and the event display page. Additionally, I started work on the overall styling of the app so that the navigation from activity to activity would look more cohesive. Some of the challenges I faced involved how to differentiate between active and past events without having to write a lot of repetitive code with small differences. I ended up creating elements in the resource files that had the same IDs to avoid null pointer exceptions and then just set their visibility to "gone" in the views they didn't need to be in. Maybe not the best solution overall, but it works for now. As a side note, I'm very indecisive about the look and color scheme of the app, so I've been continuously re-doing certain aspects.

Next week I plan to work further on the per user stat page that will pull all user metrics and display them for an easy visual. I also plan to adjust the look of the home feed so that it's a little less uniform.

CST 499 - Week 12

 This week was a rollercoaster of emotions for me. I was able to fine-tune the feed display and get it working to update with new activities in real-time, which was exciting. However, at some point, when messing with my gitignore file, I did something to somehow break the gradle build and was unable to get my project to even build on my machine for a couple days. On top of this, because of the holiday season and attending a work event, I had less time than usual to work on fixing it, so I was moderately stressed about the mishap. In the end, I tried multiple strategies and finally got it working, but it cost me a lot of coding time. I should have different types of feed activities working by the end of tonight and luckily, because of the holiday, I have an extra day off this week, so I'm hoping to continue implementing different achievements and achievement types this week along with fine-tuning a lot of the UI design, especially when it comes to event creation/display. 

CST 499 - Week 11

 This week I implemented achievement tracking, which involved handling achievements by type (COUNT, STREAK, ETC.) and began work on refactoring some of our code for use in a social-media-like display feed on the landing page. This involved a bit of work on my part, just because I was unsure how to go about creating the feed without constant queries. I ended up using an approach recommended by geniuses on the internet that involved converting our already existing achievements to "activities" and denoting them by time, for example, ACHIEVEMENT_EARNED and displaying all activities on the landing page. Next week, I will continue this path and convert the events and friend relationships in a similar manner, while also working to make sure the design is consistent across multiple activities.

My biggest challenge was mentioned in the previous answer.. Trying to convert our existing database for use in a feed. Luckily, because social media apps are so common, this basically just involved me looking for examples I could use as a "template" for the desired behavior and adapting it to our use.

CST 499 - Week 10

 This week, I worked on implementing the display for the event page. You can now view events on an "events home page" with small previews for active and past events and the option to view all events of your chosen type. I also started the code for tracking and earning achievements. 

My goal for this week is to implement the remaining code for achievement earning and work on the display and layout for stat tracking. This will also involve changing the way we currently view the profile pages for ourselves and our friends. 

One of our challenges this week has to do with modifying our database tables for ease of use when accessed by our program. Databases is one of my weaker topics, and while I'm comfortable using them, I feel very inadequate when trying to design them. Other than that, most of the challenges I've run into have to do with me being unfamiliar with necessary libraries or functions. Luckily, because of this, I also am learning a lot with regards to Java and Firebase.

CST 499 - Week 9

 This week our team focused mainly on backend implementation. I got approval to use the BGG API and went through the steps for learning how to securely store and use the bearer token. I ended up modifying our service and interface code to use Firebase Functions instead of our original code design and enabling Google Secret Manager to securely handle the token.

 Our next steps will be to wire up the activities for creating an event, finalizing user registration, and being able to view user profiles/past game nights with the relevant information, while also working on the next version of our design.

 My biggest hurdle this week was unrelated to the work. A close family member passed away and I was having a hard time staying focused while driving back and forth out of town. Another challenge was the Google Secret Manager use, since it required a lot of steps to get it working. At this point, it seems we have been able to manage all challenges that have come our way and we will hopefully be able to catch up to our desired pace this week.

CST 438 - Week 8

The five most important takeaways from this course, in my opinion, were
1) The use of GitHub projects. I believe this will come in very handy for future jobs and also personal projects. It gave me a taste of what it is like to coordinate code with a group and resolve potential conflicts.

2) The Agile philosophy. Agile seems to be a trend with how companies organize projects these days and I know that many employers that I've been in contact with so far prefer a candidate with experience in the methodology. Learning the concept of iterations and sprints and how they relate to organizing a project is going to be invaluable for me on the job.

3) Code reviews. So far I've mostly worked on projects solo or with a single partner. Seeing the process of code reviews and how they can be used not only to comment on code functionality, but code design and even documentation is something I'd never really thought about in the past.

4) TDD. While I've always known that testing was an important part of software design, the idea of writing tests before implementation is very interesting to me and I can see how it would lead to better functionality. Any time I've written a test in the past, I've found myself having to refactor code in order to be able to test it in a way that makes the most sense. I think writing the tests first could make my code cleaner and save me a lot of time.

5) React. I have a major interest in web development and knowing React could prove invaluable to me when looking for a job. While I don't find it as intuitive as I found Node.js, I loved figuring out the interactions between the components and seeing how they came to life on screen.

CST 438 - Week 7

This week we learned a bit more about the Plan and Document process versus the Agile process. The Agile process that we're a little more used to involves more flexibility when it comes to the requirements surrounding a project. The timeline is broken up into small iterations or sprints where smaller, working chunks of code are created and delivered. In the Waterfall process, delivery of the complete project happens at the end and the requirements are more rigid. When we develop using the Agile process, feedback is often and expected, which can lead to a lot of re-working code and pivoting to accommodate design changes. When using the Plan and Document style, the planning happens up front and any design changes need to undergo a formal procedure to do so. I can see how there are benefits to both strategies depending on the scale and length of the project, but so far I like the flexibility of the Agile process as it is more in line with the way I naturally approach projects with many parts.

CST 438 - Week 6

 This week we spent time learning about how Google and how they handle the infrastructure for services on such a large scale. One of the solutions involved in managing this problem is by automating what you can. While some automations are simple, like executing a shell script or monitoring machines, automating scheduling becomes more involved and once you have multiple machines with different environments, you must create further strategies to manage processing at that scale. One concept that stood out to me in this chapter is the concept of containers. While I've used Docker for multiple classes now, I wouldn't say I have a firm grasp on the advantages of using it. For example, why couldn't you just provide me with the dependencies I need? In this current project, I've actually gotten a small taste of why having a contained environment would be useful. For example, when designing the CSS for this project, I just messaged my partners to tell them to install bootstrap and react-bootstrap for their projects. I can only imagine how complicated it would get with multiple engineers working on multiple processes that all require their own dependencies.

CST 438 - Week 5

This week was especially interesting to me. I got to learn all about how the different technologies interact to create a finished product. Aside from the Student View Schedule, View Assignments, and View Transcript routes, I was in charge of CSS for my group, so I learned how to install Bootstrap for React and how to implement those elements, which was slightly different than the way I've implemented them in the past. Because I had to implement style changes in a different way than I'm used to, I "accidentally" learned more about how React components work together and have a much better understanding of the different elements. While trying to adjust certain elements, I also learned some more about Javascript states, which is definitely a weak spot in my knowledge. Overall, I really felt that this has been the most beneficial for me from a growth perspective. 

CST 438 - Week 4

 One of the most interesting things I've learned from reading "Software Engineering at Google" comes from this week. I never really thought about the breakdown of how code is reviewed. So far in any group projects I have been a part of, one person sort of 'takes the lead' when it comes to managing pull requests. While I assumed that there would be a more complicated process for this when dealing with a larger team and more complex projects, I didn't realize that there are not only multiple people who review, but that these people are looking at different aspects of the code. For example, one of the people who reviews code is focused on readability and maintainability while another focuses on if the code is suitable for their portion of the codebase. This allows for division of responsibility so that no one person is responsible for checking every aspect of the code.

CST438 - Week 3

The most obvious benefit to using git as version control is being able to revert back to previous working version of your code. Before I learned to use git, there were times that I started re-writing code for a new feature, just to break everything that worked fine before. With git, I'm able to restore the file to a previous version in order to more easily figure out where I went wrong. Another thing I find useful about git is the ability to coordinate with team members on projects in parallel. I can work on one branch while my partner works on another and we are able to push and pull our code remotely without having to worry about copy and pasting or downloading files from each other.

One thing git merge does not solve is when two developers make changes to a file, but not to conflicting lines of code. What I mean by this is if two developers both modify line 15 of a program in different ways, git merge will find that problem and flag it as a conflict. However, if one developer writes line 15 to print a variable and line 14 defines it. But developer 2 changes the variable name or deletes line 14, we're going to run into problems that wouldn't necessarily be caught by git merge. Even though there is no merge conflict, the code will still not compile or work as expected.

CST 438 - Week 2

 This week we were introduced to React.js. React is a front-end framework that manages a virtual DOM to allow for increased performance. We used this to connect a visible webpage with our previous module's Java code. This allows users to interact with our database and related functions in an intuitive user-friendly way. I found the way the codebases connected to be really satisfying and I'm really looking forward to utilizing this in more depth as we move forward.

I think one strength of React is the way it promotes modular code by utilizing components. Similarly to the way we use partials in Node.js, I can see how the individual components allow for less re-writing and better efficiency.

On the other hand, I found learning the pattern of the React concepts a little intimidating and can imagine how much more intimidating it would be without a solid background in code. Alternatively, vanilla JS, HTML and CSS are more approachable and the structure is more easily understood.

CST 438 - Week 1

 I expected a course in software engineering to cover what goes into building a software from scratch, including the design, the technologies and the life cycle. After the first intro course to software engineering that we took last year, I expected it to include aspects of multiple courses from back-end to front-end, databases, and security. After the first week in this course, my expectations were met, but I also learned more about things like scalability and maintainability along with the importance of communication amongst not only developers but with the clients as well. In my coding experience so far, it has been easy to make changes or refactor code, because I've been primarily working alone or in small groups. Emphasizing the impact of project management and tradeoffs will be vital to working on larger scale projects 

CST 325 - Week 1

 Journal Week 1: Link to Doc

CST 462s - Service Site Reflections

 For this class, I spent my time serving at The Document Foundation doing bug testing. I signed up for this opportunity because I knew it would be a challenge for me and I wanted to expose myself to fields outside of what I normally lean toward. Even with this in mind, getting started with the service hours was difficult for me. I had to learn how to use the software first in order to test bugs along with how to go about the actual testing process. Sometimes I would get stuck trying to figure out if I was actually not able to replicate a bug, or if I was just misunderstanding the problem in question. Luckily, the site supervisor was very accessible for questions and troubleshooting problems and The Document Foundation had good resources via website for some of the problem-solving that needed to happen. Overall, I think the most impactful part for me was seeing how much goes into building "complete" software. Seeing the way that new problems arise or the way that old problems can come back during updates made me really have a lot more patience when dealing with small issues in the software I use regularly. I also gained a lot of respect for the development of software with regards to different operating systems.

My advice for future students would be to get started on the service hours early, as it can take some time getting used to the process and you don't want to be stressed about hours at the end of the semester. Also, communicate with your site supervisor and the other students (if any) who are at the same site as you. They can give you help and advice and save you a lot of wasted time. Lastly, don't get discouraged if you feel like you don't understand something or it's not "clicking" for you. Try to understand that this isn't an achievement-based service, but more an opportunity to learn something new and see if it's something you would want to participate in post-graduation.

CST370 - Week 7

 Studying for the final this week went smoother than expected. My biggest concern was getting a grasp on AVL and 2-3 trees. For whatever reason, constructing these trees just wasn't clicking for me, but after working through some practice problems, I'm feeling more comfortable with the material. The last module introduced Djikstra's algorithm, which determines the shortest path from a single source vertex to each of the other vertices. This algorithm is widely known and used for GPS, internet routing, etc. My favorite algorithm from the last two modules is probably Prim's algorithm. Something about finding the minimum spanning tree was just really fun for me to work through.

CST370 - Week 6

 For this week, we went over what makes an AVL tree, 2-3 trees, and heaps. Luckily most of this was familiar to me from my data structures class, as my biggest challenge this week was finding time to work on homework due to a busy holiday weekend at my job. Part 1 of the coding assignment had to do with "heapifying" a data set to maintain a max heap, or a heap where every parent is larger than both its children. The second part of this week's module had to do with hashing and how to handle collisions. We went over two strategies for handling collisions - "separate chaining" and "linear probing". For the coding assignment, we wrote a program that would take in user commands (for example, "insert 20") and hash/rehash the map as necessary. In the instance of a collision, it will simulate the steps of linear probing. I had a lot of fun with this assignment actually, even though I had to finish it in quite a rush. It was a good review of unordered_maps in C++ and I got a much more thorough understanding of how a rehashing works.