Author Archives: lynnnsubuga

Sprint 3 Retrospective Blog

This sprint, my colleague and I focused on improving the security of our user identification process by applying the bcrypt algorithm to hash user UUIDs. This enhancement ensures that sensitive user data is protected, even if our data storage were to be compromised. Gitlab activity included integrating bcrypt hashing into the backend to hash user UUIDs using a cost factor of 10, modifying bcrypt configuration to use a fixed salt, ensuring consistent hashes across runs, and submitting final changes to incorporate one-way hashing of UUIDs into the main codebase. Collaboration was a strong point during this sprint. My teammate and I divided the responsibilities clearly: while I explored and tested the technical implementation of bcrypt, they focused on integrating the updated code into the overall architecture and ensuring compatibility with existing endpoints. The decision to use a cost factor of 10 proved ideal, it gave us a reasonable level of security without compromising performance. Our communication also worked well. We checked in frequently and held short meetings to keep each other up to speed. As a result, we were able to rapidly troubleshoot issues and make decisions quickly, like choosing to use a fixed salt instead of a randomly generated one to produce consistent UUID hashes.

One issue we ran into was a lack of documentation around the UUID hashing logic. Initially, we assumed the random salt provided by bcrypt would be fine, but after seeing inconsistent hash outputs during tests, we realized the need for a predictable result. This led to a mid-sprint pivot toward using a fixed salt. We had to backtrack, re-implement, and update our test cases, which took us some time. This could have been avoided with better planning. Additionally, we ran into some confusion around git merge conflicts when integrating our changes into the main branch. While we resolved them, it highlighted the need for more careful branch management and communication before pushing large updates. As a team, we could benefit from implementing a more structured approach to testing and reviewing security features. If we had written our unit tests alongside the feature development instead of afterward, we could have caught edge cases and salt inconsistencies earlier. Pair programming or doing short walk-throughs of each other’s code before merging would also help with smoother integration. We also realized the importance of having centralized documentation. Creating a shared sprint wiki or README update plan could help future developers (and our future selves) understand our design decisions, especially when it comes to something nuanced like hashing algorithms.

Personally, I’d like to improve on anticipating the implications of the tools I use. Initially, I took for granted that bcrypt’s built-in salting behavior was the best option without considering how it would affect UUID. Doing more research ahead of implementation or even reaching out for guidance from more experienced developers, could have saved us time. I also want to get more comfortable with conflict resolution in Git. While I understand the basics, more practice and familiarity with rebase, stash, and other tools would make collaboration smoother. In Apprenticeship Patterns, the pattern “Dig Deeper” encourages developers to go beyond surface-level understanding and truly learn the underlying mechanics of a technology. It’s about investigating not just how something works, but whyit works that way. I chose this pattern because it reflects exactly what I failed to do at the start of this sprint. When I implemented bcrypt, I understood it hashed securely, but I didn’t dig into how it used salt or how to configure it for consistent output. Had I taken the time to explore bcrypt’s inner workings, I would have realized the random salt would cause each hash to differ and planned for a fixed salt approach from the start. If I had read and applied “Dig Deeper” earlier in the sprint, I believe our implementation would have been more efficient and less prone to last-minute changes. This pattern reinforces the importance of understanding the tools we depend on.

References.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/143

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/142

From the blog CS@Worcester – Lynn'sBlogs by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog

During Sprint 2, my main task was to update our REST API by replacing the use of WSUIDs with UUIDs. Our sprint planning phase for this sprint was good, we broke down the tasks into what everyone would be doing for the sprint. Our communication was effective, especially during our team meetings in class. To implement the switch from WSUID to UUID, I updated the open API specification to reflect the new identifier structure. One of the key wins in this sprint was the successful refactor of the API to use UUIDs instead of WSUIDs for identifying guests. This transition improved the design by making guest identifiers more secure and consistent. I gained a deeper understanding of Open API specifications and how to maintain consistency across the schema definitions and endpoint parameters. Using UUIDs helped eliminate potential conflicts or collisions that may have occurred with custom WSUIDs. Collaboration also worked well with my team. Once I communicated the change to my teammates, everyone was supportive in reviewing related files and helping test the changes locally. This made integration and deployment less stressful.

At first, I underestimated how widespread the WSUID field was across the codebase. I initially thought I could change a few lines in the schema, but it quickly became clear that the change had to be made in multiple endpoints, error responses, and even test data. I had to backtrack several times to hunt down instances of WSUID that I missed earlier, which slowed down progress and created some confusion. Additionally, I didn’t write enough tests initially. As a result, one of the updates to the /guests/{uuid} path temporarily broke until I realized the mock data still used WSUID formatting. In the future, I need to write and run tests as I go rather than treating it as a final step. As a team, I think overall we have worked well and collaborate well with each other. Personally, I need to improve at assessing the scope of tasks more accurately. I underestimated the time and complexity involved in replacing WSUID to UUID. I want to become more consistent about writing tests early in the process.

“Be the Worst” from Apprenticeship Patterns (Chapter 2) encourages developers to seek out teams where they are the least experienced. The idea is that being surrounded by more skilled developers pushes you to grow faster through mentorship, observation, and collaboration. During this sprint, I didn’t have as good experience working with API design and backend architecture. At first, I felt a bit behind, especially when I didn’t account for all the areas affected by the WSUID-to-UUID switch. This pattern reminded me that growth often comes from being challenged by your environment and teammates. Had I internalized this pattern from the start, I would have asked more questions earlier instead of assuming I had to figure everything out solo. I would have scheduled a quick check-in to confirm I was on the right path before updating the spec. By embracing being “the worst,” I could’ve saved time and avoided some of the errors that slowed me down mid-sprint. This sprint taught me that meaningful growth comes from deep work, reflection, and surrounding myself with teammates who challenge and support me. I look forward to carrying these lessons and complete sprint 3 successfully.

References.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/142

From the blog CS@Worcester – Lynn'sBlogs by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective blog

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/merge_requests/49

This is the link showing merged changes into main branch after testing. During this sprint, our team collaboration was strong, with regular meetings during class checking on our progress and open communication that helped us stay aligned. Additionally, our task management system in GitLab was highly effective, helping us track progress and ensure that every team member had a clear understanding of their responsibilities. Another success was our ability to quickly adapt to challenges. When any of my teammates encountered any problems, we worked together to identify solutions and implement fixes efficiently. This adaptability was important in maintaining our project’s momentum and meeting our sprint goals. Despite the successes, there were areas where I struggled. One significant challenge was time. Some tasks took longer than anticipated due to unforeseen problems, particularly when dealing with the display of the First Entry Date in the frontend. I made some changes in the GuestInfoComponent.vue and at first it wasn’t displaying the entry date. With more research, I figured I also had to make changes in the VerifyPage.vue file. With these changes, my Date of first Entry was displayed after making my changes. Looking ahead, there are several ways our team can improve. One is better estimation of task complexity, where tasks can be broken down further and allocate time for unexpected challenges. Reflecting on my own contributions, there are several areas where I can improve. One is time management. Allocating more time for testing will help ensure deadlines are met more comfortably. This I would say is something I am going to do better at in the next sprint, as I believe it will help enhance my own skills as a developer.

The Apprenticeship Pattern I chose is “Expose your Ignorance” pattern which encourages developers to openly acknowledge what they don’t know and actively seek knowledge. Instead of pretending to understand everything, developers should ask questions, collaborate with teammates, and use resources to expand their expertise. I chose this pattern because it closely aligns with my experience during this sprint. When working on merging my work to GitLab after I had completed my issue, I struggled with this and came across many blocks. Instead of immediately asking for guidance, I spent too much time doing it on my own. Eventually, when I reached out to a teammate, I realized how quickly I could have resolved the issue with just a simple discussion. This experience reinforced the importance of embracing learning opportunities rather than trying to figure everything out alone. Had I fully embraced this pattern from the beginning, I would have immediately sought help. This approach would have saved me valuable time and reduced frustration. Moving forward, I plan to be more open about my knowledge gaps, actively seek advice, and continue improving my problem-solving efficiency. This sprint was a valuable learning experience that highlighted both our team’s strengths and areas for improvement. While our collaboration and adaptability were commendable, we also identified opportunities to enhance efficiency and communication. On a personal level, recognizing the importance of seeking knowledge earlier will help me grow as a developer. By implementing these improvements, both individually and as a team, we can ensure even greater success in future sprints. I look forward to working on the next sprint and implementing more changes that will make this sprint easier.

From the blog CS@Worcester – Lynn'sBlogs by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

This reading presents an insightful perspective on software craftsmanship, emphasizing apprenticeship, perpetual learning, and skill mastery. The concept of learning through mentorship and practical experience, as illustrated in Dave’s story, was particularly interesting. It highlights the importance of hands-on work, exposure to real-world challenges, and the necessity of a growth mindset in becoming a great developer. The reading has influenced my perspective on professional growth. It reinforces the idea that mastering something comes from deliberate practice, seeking out mentors, and embracing failure as a learning opportunity. I believe this is what makes a good developer. One point I disagree is the romanticization of craftsmanship. While the focus on individual skill development is inspiring, modern software development requires collaboration with teams. Balancing skilled craftsmanship with effective teamwork is important. In chapter 2, I find the story of the Zen master and the young philosopher was provoking. It talks about the importance of maintaining a beginner’s mindset, or “emptying your cup,” to fully absorb new knowledge. I think this is important in apprenticeship. The idea that experience can sometimes be a barrier to learning is interesting and that applies to many fields, including software development.

Dave’s realization that true mastery comes not from credentials but from continuous learning and engagement with a community of experts is highly relevant. The story also highlights the importance of humility in learning. Even the most skilled developers acknowledge that they are still learning, which serves as both an inspiration and a challenge to those just starting out. The idea that learning is a lifelong journey rather than a destination is a valuable takeaway. I resonate a lot with this point because I often feel like this is a lifelong journey of continuously learning and adapting to new technologies. In terms of how I work, the idea that certifications and formal training are only steppingstones, not the final proof of competence is true. I’ve learnt that while training can provide foundational knowledge, real expertise comes from practice, engagement with peers, and continuous learning. One thing that I found interesting was the analogy of “the big fish in a small pond”. It is a powerful way to describe the risk of complacency for those who learn quickly. It’s a reminder that achieving success in a limited environment may feel rewarding, but true growth comes from recognizing the wideness of the field and challenging yourself to bigger things. I’ve learnt that it’s important to stay challenged and continuously learn. It’s easy to become comfortable in an environment where your highly competent, but it’s important to seek out mentors that can further challenge you to be even better than you already are.

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Exploring REST API Implementation

In this blog, I’ll talk about the process of implementing REST APIs, their significance, and the key considerations for building good APIs. REST API implementation involves creating a structured interface for applications to interact with. Using HTTP methods like GET, POST, PUT, DELETE, and PATCH, REST APIs facilitate operations on resources. These resources are typically represented as URLs for example /users, /products, and the interactions follow stateless communication principles where each request is independent and self-contained. A simple example of a REST API might include GET /users: Retrieve a list of users. POST /users: Create a new user. PUT /users/{id}: Update details of a user with a specific ID. DELETE /users/{id}: Remove a user. It’s important to know why REST API implementation is important.Communication. REST APIs provide a consistent framework for systems to interact, regardless of their underlying technologies. This universality enables integration across diverse applications and platforms. Scalability and Performance.REST APIs are designed to scale easily, as their statelessness allows servers to handle multiple requests without maintaining client-specific sessions. This makes REST ideal for cloud-based applications. Business Value
Exposing services through REST APIs enables businesses to monetize their platforms by integrating with third-party applications or creating ecosystems like app marketplaces.

Some key steps in implementing REST APIs include Defining Resources and Endpoints. Identify the data and operations required by the API. For example, a library system might need endpoints like /books, /authors, and /borrowers. Choose the Right Tools
Use frameworks like Express.js (Node.js), Django (Python), or Spring Boot (Java) to streamline development. Ensure Proper Security.Implement authentication and authorization mechanisms like OAuth, API keys, or JWT to protect sensitive data. Document the API. Tools like Swagger can help generate comprehensive, developer-friendly documentation. Test and optimize.
Use automated testing tools to verify functionality, and monitor performance to identify bottlenecks. Some of the best practices for building REST APIs include Designing clean and meaningful resource URLs. Properly utilizing HTTP methods for specific actions. Using status codes to convey response status and errors. Implementing authentication and authorization mechanisms. I chose this topic because it talks about different aspects of implementing REST APIs. In conclusion, by understanding the key principles and specifications of REST APIs, developers can design APIs that facilitate seamless communication between clients and servers.

References.https://medium.com/@zappy_cordovan_shark_864/exploring-restful-apis-building-implementing-and-best-practices-4003a19df798

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Specifying Rest Api Calls

In the world of modern software development, rest API’s enable seamless communication between systems, services and applications. Specifying REST API calls is equally important for ensuring clarity, functionality, and integration efficiency. Rest APIs provide a way for two applications to communicate, which enables your software to interact efficiently with various other services, thereby enhancing its capabilities and user experience. Rest APIs work by fielding requests for a resource and returning all relevant information about the resource, that is translated into a format that clients can easily interpret. Clients can also modify items on the server and even add new items to the server through a REST API. The six rules of REST APIs include client-server separation. The client sends a request to the server, then the server sends a response back to the client. Servers cannot make requests and clients cannot respond, and all interactions are initiated by the client. The second rule is uniform interface where all requests and all responses must follow a common protocol, or a way of formatting their messages. The third rule is stateless which means that every interaction is independent, and each request provides all the information required to complete the interaction. One important thing we need to understand is why use REST APIs. Rest APIs are flexible where they can handle many types of requests and send data in many different formats. Rest APIs are scalable. They are designed for communication between any two pieces of software, regardless of size.

Benefits of REST APIs help systems and applications communicate with each other. They are simple to use and implement. You can scale REST APIs easily and this is because they are stateless, meaning each request from a client has all the information your server will need to fulfil it. There are a few different types of APIs. One is private APIs.These are internal to an enterprise and only used for connecting systems and data within the business.Public APIs 

These are open to the public and may be used by anyone. There may or not be some authorization and cost associated with these types of APIs. Partner APIs.These are only accessible by authorized external developers to aid business-to-business partnerships. Composite APIs. These combine two or more different APIs to address complex system requirements or behaviors. Some of the steps to create an API are plan the API, build the API, test the API, document the API, and then market the API. I chose these resources because they explain REST APIs in more detail and how they are used in the real world.

References.

https://aws.amazon.com/what-is/api/

https://blog.hubspot.com/website/what-is-rest-api

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Exploring FrontEnd

Front end development, often described as the face of a web application, plays a crucial role in shaping how users perceive and interact with digital platforms. Front end development basically creates the user interface (how the website looks like) of a website. Users directly see and interact with buttons, menus, text, and images, making it crucial for delivering a positive user experience and influencing how people perceive a digital product. This is important because it directly impacts user engagement, and overall website functionality by ensuring it is visually appealing. Some of the key points about front-end development are focusing on user interface. Developers primarily focus on creating the visual layout and design of the website, including how users interact with them. Another key point is core technologies. The primary languages used in front-end development are HTML (for structuring content), CSS (for styling elements), and JavaScript (for adding interactivity). I think it’s also important to know some key differences between software development in the front end and back end. Backend development is the process of building the components for running the application behind the scenes. Some examples are components for data storage, infrastructure, and code written in one or more programming languages. Users can’t access the back end. Front-end development is the process of building components that interact with users. Examples are the user interface, buttons, user-entered data, websites, and user experience (UX) features. The front end aims at meeting user requirements and delivering a positive user experience.

Pros of front-end development include improved user experience where websites are well crafted, functional, and visually appealing on any device and this attracts more users. Low maintenance cost where you can have websites that work seamlessly across all devices. Faster web pages that optimize your website’s performance, ensuring fast experience across all devices. Some cons of Front-End Developmentare Steep Learning Curve. With numerous tools, frameworks, and libraries available, staying updated can be overwhelming. Browser Compatibility Issues. Ensuring a site works seamlessly across multiple browsers and devices can be tedious. Rapidly Changing Technology. The fast pace of technological advancements requires constant learning, which can be challenging for developers. I chose this article because it goes further into detail about what we talked about in class. It talks about front end development in depth. In conclusion, front end development is an essential aspect of modern web and application development. It’s rewards in terms of user engagement, satisfaction, make it an exciting field.

References.https://cloudinary.com/guides/front-end-development/front-end-development-the-complete-guide

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Implementing New REST API Calls

APIs are integral to building scalable and flexible applications. They allow communication between clients and servers using HTTP methods such as GET, POST, PATCH, and DELETE. Adding new endpoints to your REST API can improve functionality, meet user requirements and support new features. To understand new endpoints, take an example if you need a GET/ inventory endpoint to retrieve the current stock levels and a PATCH/ inventory endpoint to update the stock based on things like adding or removing items. Some steps to implement a new endpoint include plan the endpoint. This starts by defining the endpoint’s purpose, required input, and expected output. For example, Endpoint: GET /inventory, Purpose: Retrieve total inventory in pounds, Response: JSON object with the current inventory count. Another step is to test the endpoint where you write test cases to verify the endpoint works as expected. Documenting the endpoint is important because this is where you use tools like swagger to document your API and you include details like input, response codes. Another important topic about rest API calls is error handling. It is essential for any API to provide meaningful feedback to users and developers while maintaining a secure system. Best practice is to use HTTP status codes effectively. For example, 400 Bad requests for issues like missing parameters or invalid input, 404 not found for requests to nonexistent resources, 500 internal server error for unexpected server issues.

When building REST APIs, adhering to strong design principles is important to creating scalable, maintainable, and user-friendly interfaces. There are three principles that include resource-oriented design, HTTP method semantics and consistency. For resource-oriented design REST APIs treat resources as primary entities representing objects in the application domain. For example /users to represent user data, /orders to represent order records, /products to represent items available for purchase. Another principle is HTTP method semantics. Each HTTP method has a specific purpose and using them correctly is critical. For example, GET fetches data and retrieves a list of users. GET/users/{id} gets the details of a specific user. POST creates a new resource for example POST/users creates a new user. PUT updates an entire resource for example PUT/users/{id} replaces all data for the user with the specified ID. DELETE removes data for example DELETE/users/{id} deletes the specified user. All this is to say that using HTTP methods correctly simplifies the developer experience by creating a predictable pattern. I chose this resource because it talks about API as an entirety, it lists the pros and cons, principles of rest APIs, shows examples of how they work.

References.

https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Introductory Post CS-343

Hi my name is Lynn and this is my new blog for CS-343. I am a senior at Worcester State majoring in Computer Science.

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

System Testing

System testing is a form of black box testing that assesses the complete functionality and performance of a fully integrated software system. This type of testing is the last stage before the software is released to the end users. The black box testing technique focuses on the system’s overall functionality. By this testing, you can identify any defects or errors in the system and fix them before the software is released. This testing can help improve the software’s quality by identifying and fixing defects and errors. This can help to prevent problems and improve the user experience. You can save time and money by identifying and fixing defects and errors early in development. This is because fixing defects early on is less expensive than fixing them after the software has been released. The purpose of system testing is to ensure that the system meets all requirements and behaves as expected by the end users. Some specific tasks typically performed during this testing include verifying that the system meets all functional requirements, testing the system’s performance under different load conditions, testing the system’s scalability to handle increasing numbers of users, and testing the system’s security against unauthorized access.

It’s also important to know some basic requirements of system testing. Some include functional requirements where the system must meet all its functional requirements, performing all of the tasks that it is intended to perform. The system must be tested in a realistic environment. It must be tested in an environment like the environment in which it will be used which ensures the system works correctly in the real world. The system must be tested thoroughly. The system must be tested properly to ensure that all potential problems are found and fixed. A variety of users must test the system to confirm that it is usable by everyone who need it. Below are some steps to do system testing manually. Analyze the requirements, create a test plan, write test cases, execute the test cases, log the defects, retest the defects and finally generate the test report. Some examples of system testing techniques include functional testing. Under this testing, we have black box testing which focuses on the inputs and outputs without knowing the internal code. White box testing which helps in validating the flow of data and control within the system. I chose this resource because it goes in depth about system testing, why it is used and important, and different types of testing methods.

References.

https://testsigma.com/guides/system-testing/

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.