CST 499 Week 8

My initial, immediate thought when writing this is, "How the hell did time go so quickly?" It legitimately feels like just a few months ago, I was spam emailing Kayla questions about the program (thank you again for your patience). Granted though, I did double up for most of the program and was able to complete it early, but I'm still boggled by the experience. 

Getting to the main focus of this journal entry now: I'm immensely proud of what I was able to accomplish in the past 20 months. Not only was I able to do well on every course, but most importantly I developed a strong technical and professional foundation that I can continue to build upon during the next stage of my career. Thanks to my efforts and great recommendations by three professors in our program, I was recently accepted to Georgia Tech's MSCS program, and I will officially begin graduate school in January 2026. I know that the fundamentals acquired in the CSUMB CS Online program will serve me well, and I am looking forward to continue training hard and reaching new heights. 

Once again, thank you for the experience and I wish for nothing short of good health and happiness to all. 

CST 499 Week 7

What project milestones did you accomplish this week?

• I officially wrapped up the capstone portal with our needed revisions (there were some areas for improvement on the excel file related functions across our portal, as well as implementing tooltips on app buttons for extra clarity). 
• I successfully finalized the GitHub repository to be client-ready, which means it also includes developer onboarding documentation for future volunteers.   
• I also created the project presentation video for our festival, which was difficult (squeezing my giant project into a ~3 min demo was something else) but ultimately fun to complete. This involved creating a cloned and randomized dummy database (for demoing) which was yet another cool skill among many picked up this summer. 
• Finally, I took care of the rest of our course assignments, such as completing the ILP website, zipping all my project files and submitting them, and of course submitting the draft presentation video. I am officially ready for the festival.  

What is your plan for next week?

• This coming week I intend to reach back out to my client and ask if any more issues were found or if any last minute revisions need to be made. Technically we already thoroughly tested the project and found it to work well, but it's also good practice to constantly stay in communication because bugs are almost always present in some form when it comes to software. 
• Since I am going to technically keep volunteering with NTS, we are going to plan future features on our portal as well, such as the upcoming student attendance application and then most likely some type of student grading application. 

What challenges, if any, are you currently facing in project development? Do you need instructor assistance?

• No real challenges. I will be certain to reach out in case I happen to need help, thanks!

 

CST 499 Week 6

This week I made decent progress on my capstone project, which as a reminder is a solo project to build a staff portal for Nyamboyo Technical School (NTS). Technically, the planned features are already complete and I've been working on bonus features since then.

What project milestones did you accomplish this week?

• I finalized the mobile responsiveness update for the student manager app, which allows users to use the application from a mobile device. 
• I also standardized the application actions (the buttons that are above each table on the applications). This is very important to ensure a scalable portal and simplicity for users. We decided to go with 'download template' for blank excel files, 'download data' for downloading data from the frontend table, and 'download report' for a more comprehensive excel file including all relevant columns from the application (best for organization scaling purposes). 
• I also administered our client testing; the testing went overall well, although we did find areas for improvement (this will be detailed in the testing report).  

What is your plan for next week?

• This coming week I intend to implement the final revisions to improve the portal post-testing, of which there are several. 
• We are also sharing the portal with more NTS staff to figure out how we can further improve the portal, which I look forward to. 
• After implementing revisions, I will finalize the video script, create a parallel dummy database for the video, and create visuals for the presentation. My goal is to have the video ready by the end of this weekend (August 10). 

What challenges, if any, are you currently facing in project development? Do you need instructor assistance?

• No real challenges. I will be certain to reach out in case I need help, thanks!

CST 499 Week 5

This week I made decent progress on my capstone project, which as a reminder is a solo project to build a staff portal for Nyamboyo Technical School (NTS). Technically, the deliverable features are already complete and I've been working on bonus features since

What project milestones did you accomplish this week?

• Since the core features for the project are completed, I'm still developing bonus features for the portal.
• Completed the mobile responsiveness update for the student manager application. This will help staff who need to update student information from their mobile devices, especially if they're unable to access a regular computer.
• Updated the GitHub Readme which will significantly help future developers who volunteer with NTS.
• I also devised a testing plan that will involve observing my client/supervisor naturally using the app.

What is your plan for next week?

• This coming week, I intend to meet with my client so we can administer the testing plan. I will be certain to carefully note areas for improvement in the staff portal so I can hopefully build them before our course concludes. We are also going to discuss needed tweaks to the portal before testing, including standardizing our naming convention for app action buttons. Lastly, we are going to discuss future plans (since I will continue volunteering with NTS after the course).

What challenges, if any, are you currently facing in project development? Do you need instructor assistance?

• No real challenges, thankfully. I will be certain to reach out in case I need help.

CST499 Week 4

This week, some great progress was made on my capstone project. As a reminder, I am (solo) building a staff portal web application for Nyamboyo Technical School (NTS), a nonprofit African organization that educates rural youth in Kenya. 

What project milestones did you accomplish this week? If you're working in a team, please list what you personally contributed, not the project status overall. 

As another reminder, I am basically done with the core features in my capstone scope, but have been building bonus apps and features for the portal in recent weeks. Below is a list of milestones that were accomplished this week: 

• Designed, built, and deployed the Penpal Application, my second bonus application for the staff portal. This app will enable staff to manage their penpal program at the school (whereby each NTS student in the program is paired with at least one American student and each pair exchanges letters about once a month). 
• Began refactoring the code in the student manager app to be mobile responsive, so that staff can use it on smaller screens when quick edits can be made in a pinch. I have made good progress on this so far, and it is almost ready for deployment, but must meet with client/supervisor first to get some feedback first. 
• Began researching Render's capacity for automatic database rollbacks, so that we can hopefully plug the feature right into the staff portal frontend. This would again be quite helpful if any mistakes are ever made by staff with the database (which is definitely a nonzero chance occurrence). 

What is your plan for next week?

For this week, I had originally planned a testing phase by staff in Kenya, but it may be postponed until one of the next two weeks. The reason for this is that it will coincide far better with the testing report assignment that will apparently be released in a week or two for us capstone students. Thus, I have chosen to instead have a preliminary mini-testing phase with only my supervisor using the app naturally for several days and providing some more feedback and suggestions while we await the larger scale testing with Kenyan staff (and I will also be providing a tutorial session which will be great). 

In addition to undergoing our preliminary testing phase, I will continue making optimizations to the portal and its apps, especially finalizing the mobile responsiveness update to the student manager app and potentially at least one other app (need to consult my client first). Some more things I will work on are fixing up the GitHub repo readme for better maintainability, cleaning up some of the code across the project (for instance, I have several import statements that use long path names which can be improved with static variables), and figuring out how to plug in Render's native database rollback feature into our app, if it's possible. 

What challenges, if any, are you currently facing in project development? Do you need instructor assistance?

I am facing no real challenges at the moment, things are going very well in this project and I will be certain to reach out to instructors if I face any issues. Thanks!

CST499 Week 3

This week, decent progress was made on my capstone project. As a reminder, I'm in a solo project developing a staff portal for Nyamboyo Technical School, a nonprofit African org. 

What project milestones did you accomplish this week?

Since this week was our first phase of user testing (the core deliverables for the capstone are technically complete), we were able to thoroughly test the portal and applications, identifying several improvements and potential issues that need to be fixed, which is a big win for us. I went ahead and compiled the issues below (grouped by relevant app).

Staff Manager:

• It is preferred to have the 'staff manager' app permission be explicitly assigned and removed to staff users, which would allow them to give certain staff conditional admin privileges. Thus, we need to reconfigure the app to allow the student manager app to be an option in the permissions section for managing staff role users.

Student Manager:

• The wording on the actions should be changed. Right now, 'download template' and 'download report' overlap too heavily in their function. We can actually remove the 'download report' button for the time being, or change it to do what 'download' template currently does and then make 'download template' produce a blank excel file for adding new students. This may require additional research into finding the proper naming conventions for our features on the apps.
• The frontend has an issue with dates not properly displaying. Specifically, the table will display dates that are 1 day ahead of the actual value in the database. This is suspected to be an issue with one of our framework tools that can be patched. It is also unknown if Kenyan staff can see this issue giving their different timezone, so this is important to consider.

Student Health:

• Manual edits on health record entries would be very useful for the health app, this should work similar to the student manager application, with a modal appearing that allows the user to change any of the health entry details for the record (and it should of course automatically execute the health entry backend logic to re calculate BMI/percentile, flags, and notes).
• Additionally, the 'download report' function should work with the table displayed, meaning that if a user filters any column and narrows the data in the table, these entries only should be included in the generated excel file. It is important to note the wording updates that will occur on the student manager application before changing this, to keep the apps consistent (see above for more details).

I began working on these tasks and was able to complete the manual edits on the student health application in addition to UI/UX improvements. I also began working on the frontend date inconsistency, the staff manager change, and the actions wording update, but as I was programming, realized that the portal may more or less work better without the changes I was testing. For instance, in researching the frontend dating issue (a classic timezone bug), it was discovered that patching it would mean that Kenyan staff would now see the date in the US standard rather than their preferred Kenyan standard (day-month-year). Furthermore, it turns out that they should in fact see the correct date on their end since they are ahead of UTC. When it came to the staff manager change, I programmed this too but then realized it defeats the purpose of having separate user staff and admin type roles, so the changes were shelved to a separate branch for our next discussion with the client (along with talking about the date issue). 

What is your plan for next week?

In short, completion of most of the above updates (certainly the wording update) will require another meeting with my client/supervisor (she is doing additional testing right now for this), and it is likely that most of them will be scrapped for the best. I will attempt to set a meeting for later this week and in the meantime get ahead on our next bonus feature, the penpal application. This app will appear similar to the health application but involve far less backend logic (definitely not a complicated CDC health data table). It will be used to track penpal letters between Kenyan students and American students, which cycles monthly (part of NTS' Penpal program). I'm very much looking forward to completing this app and as many more as possible so that the portal can be very feature rich by the time our course concludes.

What challenges, if any, are you currently facing in project development? Do you need instructor assistance? 

Thankfully, no real challenges as of now. Honestly, after going through the hassle that was learning to deploy the portal to Render, I feel well equipped to deal with any future issues entirely independently - but if I get stuck on something for longer than usual, I will be certain to reach out. Thanks! 

CST499 Week 2

What project milestones did you accomplish this week? If you're working in a team, please list what you personally contributed, not the project status overall.

This week, I made big progress on my capstone project. As a brief reminder, I'm (solo project) building an online staff portal for Nyamboyo Technical School (NTS), an African nonprofit organization who strives to educate rural Kenyan youth and young adults adults modernized, technical and vocational skills.

Since I have officially completed the core deliverables for the capstone project and am currently awaiting user testing (more on that in the next section), I went ahead and began developing bonus apps that the portal can use as well as UI/UX updates to the portal. This week in specific, I completed the following:

• New application: Staff Manager. This app allows admin users to manage staff accounts, including creation and deletion of accounts and editing their details and app permissions.
• Updated the profile page to be far more modern and professional.
• Various UI/UX updates to portal, I will list them here:
•  The login page was updated to remove the arbitrary  ‘forgot password’ link.
• The login page login button was updated to include a dark/light dynamic onhover effect and to be triggered by the user pressing enter rather than having to manually click it.
• The global sidebar was updated to include light/dark dynamic onhover effects on items.
• The dashboard app cards were updated.
• Icons across the whole portal were updated to be more specific and suitable.
• The student manager and health app’s UIs were updated to be more consistent with each other and with future apps in the portal (for instance, a button that provides an Excel template file for the user to fill will always have text ‘Download Template’ and the lucide download icon

 What is your plan for next week?

Next week, I intend to begin developing a new app for the portal, though I am not 100% certain which idea I have would be most beneficial for NTS. Some ideas I have include:

• An app for admins that would allow them to "rollback" the database to an earlier state. I believe Render technically has this feature natively for paid database instances, though. Regardless, if staff can directly trigger this feature from within the app rather than dealing with Render's platform dashboard, it can be a powerful addition to the portal. 
• A messaging app, which could also lead to notifications and alerts features. For example, an admin can send a message to a teacher asking them to provide an updated list of students for a term, which could set an alert for the teacher when they log in (and potentially an email alert, too). 
• An AI-integration to the portal, for example, a chatbot that can assist Kenyan staff with technical questions. I'm excited to try implementing this at some point during our capstone timeline, although I need to iron out the details and consider ethical implications ahead of time, especially security-wise. 

In addition to beginning development of our next bonus app (pending client meeting/discussion), I will attempt to update our student manager and health apps to have more features (for instance, manual insertions/edits on the student health app records) and also be mobile responsive like the rest of the portal. At the moment, the two apps work flawlessly on desktop/laptop web browsers, but if they can work with mobile devices, too, that could be very helpful for staff who are in a pinch. 

What challenges, if any, are you currently facing in project development? Do you need instructor assistance?

Currently, I am thankfully facing no challenges and development is going smoothly. I am especially grateful for having so much support from instructors and mentors and will be certain to reach out if needed.

CST 499 Week 1

Since my last update (the status update at the end of CST489), I have thankfully made significant progress on the project. In fact, the core deliverables outlined in my project scope are essentially complete.

As a brief reminder, I'm (solo project) building an online staff portal for Nyamboyo Technical School(NTS), an African nonprofit organization who strives to educate rural Kenyan youth and young adults adults modernized, technical and vocational skills.

Here is the progress I made since the previous update:

• I finally deployed the portal via Render, as a single, monolithic service as was planned. I was experiencing significant challenges configuring my project structure in a manner that wouldn't trigger Render's error code for Node applications. Specifically, Render wants the 'app' folder to be in the same directory of the Next.js installation, which for me wasn't really feasible, given the custom structure I began with from the beginning of development. Even still, I tried refactoring everything into a more friendly structure for Render and it still failed. That's when I realized I could containerized the project with Docker and then deploy it to Render as a Docker app rather than a Node app without having to worry about the strict structural expectations on Render. After containerized containerized Docker, I successfully deployed to Render.
• I also completed and deployed the first version of the third and final core deliverable for my capstone, the student health application. The student health app was successfully plugged into the portals authentication system and deployed to the live service after preliminary testing.
• In deploying the student health app, I was also able to establish a proper continuous deployment pipeline for myself and future developers who work with NTS, solving the maintainability issue that NTS' original staff portal had (more details of this are in my proposal). Future developers will now simply branch off of main for building their features and configure the environmental variables. Then, when done with development and testing, they merge their branch into main, which will now automatically deploy the changes to the live service.
• The portal was of course tested further to confirm security, stability and functionality with the two live apps.

Looking forward, the next stage of my capstone is extensive user testing, debugging, and improvements to UI/UX. I know for certain that the portal can benefit from more features, such as expanding those in the profile page and perhaps adding specialized features for admins (for instance, to manage staff accounts).

I am currently in contact with my supervisor (the 'client') to set up a live training session with school staff in Kenya, to help them learn how to use the portal and discuss further improvements.

CST438 Week 8

This course was a ton of work, but also very fulfilling and rewarding in terms knowledge and skills gained. If I had to decide on my five favorite new things I learned, they would be as follows.

1. Git 

I believe that Git is criminally underrated in terms of skills that software engineers should master. Most people only know the very basics, such as git push, pull, commit, add, and fetch, without understanding the more complex stuff. When I first came into the course, I was in that boat, and it was a blast running into many errors with Git and learning the necessary skills to debug them. The crazy part is that Git goes so deep that I only went a bit deeper during the course. I will continue to learn more about Git.

2. Agile Method

From what I have heard, Agile is popular and very commonly seen in startups, which means that if I were to be hired at such a company, having the basics down already will put me in a great spot. I also think its fun to create epics and stories and complete stories during sprints. I am naturally extroverted so I might also be biased in favor of scrum meetings and teams with tighter communication.

3. React Basics

I am choosing this item because of how popular React is in today's tech industry. If I am not mistaken, it is the most popular frontend library which means that we are almost certainly likely to see it again as industry engineers. Being able to customize our project's React frontend was a thrill and I like the dark theme that I installed on it. I know that the skills I improved on in this course will almost certainly carry over well to that.

4. Service Oriented Architecture

Splitting our backend repo in two and having each part handle a different service was really cool. I especially like that this is something real, large companies do all the time, although apparently to far greater degrees (understandably). I'm not going to lie, it was confusing at first to wrap my head around the concept, but programming it directly really helped me to grasp the idea and now I am quite comfortable with the philosophy of and reasons for microservices. 

5. AWS Deployment

Admittedly, I thought that this was going to be complicated and possibly even dangerous considering the potential of being overcharged by AWS for unaccounted compute on our deployed project. However, as I worked through the assignment, re-read the document and re-watched Prof. Wisneski's video walk through, the process became clear and understandable. Furthermore, my application thankfully deployed successfully after debugging the manifest file error, which only took a few minutes extra. Last but not least, cleaning up was easier than I thought, and should prevent us from getting overcharged, which I'd wager is a great skill on its own. I am now open to learning more about AWS, especially since it's widely used in the industry these days and no doubt a great tool for contemporary software engineers.

CST 438 Week 7

Agile and Plan-and-Document, also known as Waterfall, are two software development processes with differing philosophy and organizational structure. Waterfall is a linear, sequential process where each stage—gathering requirements, designing, implementing, testing, deploying, and maintaining—is completed before the next is started. The process relies on detailed documentation and forward planning and so is ideal for the projects whose requirements and scope are clear and not expected to change. For example, defense or aerospace industries or manufacturing that need predictability, safety, and compliance are likely to employ the Waterfall model. Agile is the reverse because it is flexible and iterative. It breaks work down into tiny, manageable chunks named sprints, which take anywhere from two to four weeks. Agile requires ongoing feedback from the users and stakeholders in order to allow the product to be altered while it is still being developed. It emphasizes working software and collaboration over documentation and rigid processes. Agile is common where there is an acceleration in change such as in the case of the technology startups, digital product companies, and user experience or quick innovation-focused organizations. These companies are often forced to move at high speed because of market changes, and Agile provides the structure to do this without being bogged down by too much process. In general, Waterfall functions best in situations where requirements cannot change, times are limited, and there can be no acceptance of ambiguity. Agile, on the other hand, performs better in high-change environments where requirements from the customers and market demands will vary.

The choice between the two generally depends upon the project type, corporate culture, and how much adaptability the team is going to need to deal with change. A few contemporary organizations even employ hybrid strategies, using the planned design components of Waterfall and marrying them with the flexibility of Agile in order to fit more effectively with their own needs.

CST 438 Week 6

This week, we discovered a great deal about a new method of structuring services in software architecture. Before week 6, the project that we had been working on had a monolithic architecture—i.e., the backend was one app where all the services (such as the registrar, gradebook, and any future features) were bundled together and run inside the same server.

On the other hand, this week we studied microservices architecture, where each service is developed and deployed independently, typically on its own server or container. Each microservice typically has its own database, but some services will have additional tables specific to the function of their purpose. There are several reasons why one would want to use a microservices approach, including increased scalability—because each service can be scaled independently as necessary—and fault isolation, in that if one microservice fails, it does not necessarily bring down the whole system.

Another basic concept of microservices architecture is inter-service communication. Since each microservice is a separate application and often on different servers or containers, it is not possible to use direct function calls or shared memory (as in monolithic applications). Microservices communicate over a network instead, using protocols like HTTP or gRPC. This is called inter-service communication. Services normally expose APIs—typically RESTful endpoints—other services invoke to pass or receive data. In more complex systems, communication is asynchronous and through message brokers like RabbitMQ or Apache Kafka, where services subscribe and publish events. Asynchronous messaging further decouples and allows services to continue working even when a part of the system is behind or temporarily unavailable. The decision between synchronous and asynchronous styles is use-case dependent, trading performance, reliability, and complexity. Funny enough, we got to work with RabbitMQ in our own assignment, and it was an absolute blast to directly program an implementation of service oriented architecture using our pre-existing monolithic project.

Another advantage of microservices is that they are technology-agnostic. Because each service is decoupled, developers can choose the most suitable programming language, framework, or database for the problem that service is trying to solve. This can lead to better productivity and performance, as teams are not forced into a single tech stack. For example, one can construct a Python-based machine learning microservice using TensorFlow in one instance, and a high-performance user authentication service in Go. Provided that services adhere to pre-defined communication protocols—e.g., REST or gRPC—they can coexist beautifully in the overall system. This autonomy also enables parallel development across teams along with simpler integration of future technologies down the line.

A real world example of microservice oriented software is Netflix, which was originally a monolithic app, just like our own project. Netflix runs hundreds of microservices today that do everything from video encoding, user recommendations, and billing. Each microservice is deployed separately, communicates with APIs, and can be scaled based on usage patterns. This allows Netflix to achieve high availability, deploy highly frequently without downtime, and continue innovating at high velocity. Their use of asynchronous messaging and advanced DevOps tools also solves the complexity involved in such a large microservices ecosystem.

CST 438 Week 5

This week, we learned some fundamental concepts in the plan and document method for software engineering, also known as the waterfall method. As opposed to agile development, where teams have rough, generalized objectives (typically represented as stories) which are iterated upon at cyclical intervals, the waterfall method involves a very thorough planning phase where software requirements are extensively documented and followed through the entire development process, with perhaps only small adjustments here and there. We learned about the software requirements specification (SRS) document, which is a sort of blueprint for the software being developed, and how to write key sections in a typical SRS. It was fun learning all about UML case diagrams, use case documentation, and how to properly document database requirements. It's cool to know that the SRS, because of its indifference on exact implementation details, can serve as a type of generalized recipe for the software you are developing. For example, in our project, we do not (and should not) mention exactly what type of entry form we use for finding a student's schedule by year and semester, rather we simply mention that the student can select year and semester, and the frontend liberties are fully granted to the developer(s). I hope we can continue to train with the waterfall method and the agile method, and perhaps other methods in the future.

CST 438 Week 4

Admittedly, I was initially reluctant to learn about code reviews, because I thought they were too time-consuming. However, after having read about them in our textbook and especially collaborating with others in our course to accomplish software development tasks, I have grown very fond of them and would consider them to be my favorite thing learned so far, although I have much training to do myself before I become adept with them. The best part is that code reviews are a sort of safety mechanism to help ensure that your code works properly. Nobody is perfect, and we can certainly use a second set of eyes on occasion to keep our work in check. 

Another great benefit of code reviews is that they can help you maintain best practices and with maintaining good code readability. A seasoned developer once told me that your code should be as simple and as readable as possible, rather than being overly fancy or gimmicky. I certainly see the value in his advice now that we are working in a small team. I can only imagine how crazy it must be to work with very large teams, and how important code reviews are in those settings. Another benefit of code reviews they provide avenues for one to learn from more experienced developers. For instance, I was fairly rusty with Java after not using it for a while, but early on, my teammates were able to create some good examples of our code which helped me caught up to speed. 

Code reviews are so important that apparently they are a quintessential part of Google's culture, which is a key reason as to why their code is stable and maintainable in the long term. I hope we can continue practicing this process even after our course concludes.