Vish's Journey in Computer Science

recent posts

about

  • Sprint 3 Retrospective – Dependency Management and Frontend Updates

    During Sprint 3, I focused mainly on updating dependencies and improving the stability of the frontend in our LibreFoodPantry inventory system project. This sprint gave me hands-on experience with dependency management and understanding how different libraries interact in a real-world application.

    Here is the evidence of my activity on GitLab during this sprint:

    What worked well during this sprint was the ability to systematically update dependencies without breaking the application. I followed a step-by-step approach where I updated one set of dependencies at a time and tested the application after each change. This helped me quickly identify issues and fix them before moving on. I also improved my understanding of frontend tools like Vue, Vite, and Pinia, especially how they depend on each other.

    However, not everything went smoothly. One challenge I faced was dealing with version compatibility issues. Sometimes updating one dependency caused another library to break or behave unexpectedly. Debugging these issues took time because the errors were not always clear. Another issue was that I initially underestimated how much testing was needed after each update.

    As a team, we could improve by communicating more frequently about dependency changes. If multiple people update different parts of the system at the same time, it can create conflicts. Having a shared plan or assigning responsibility for specific updates would help avoid confusion and reduce duplicate work.

    As an individual, I could improve by planning my work better before making changes. Instead of directly updating dependencies, I should first review release notes and check compatibility requirements. This would save time and reduce errors. I also want to improve my debugging skills so I can resolve issues more efficiently.

    The Apprenticeship Pattern I selected is “Breakable Toys” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern encourages developers to build small, experimental projects where they can freely make mistakes and learn without fear of breaking important systems.

    I selected this pattern because it directly relates to my experience during this sprint. While updating dependencies, I was working on a real project, which made me more cautious. If I had applied the idea of “Breakable Toys,” I could have created a separate experimental setup to test dependency updates first before applying them to the main project.

    This pattern is relevant because it promotes learning through experimentation. In my case, I learned a lot about dependency management, but the process was slower due to fear of breaking the system. Having a safe environment to experiment would have allowed me to explore more freely and understand issues faster.

    If I had read and applied this pattern earlier, I would have created a separate test project or branch specifically for experimenting with updates. This would have reduced risk and improved my confidence. It would also have allowed me to try different solutions without worrying about affecting the main codebase.

    Overall, Sprint 3 was a valuable learning experience. I gained practical skills in dependency management and improved my understanding of modern frontend tools. Moving forward, I plan to apply what I learned and continue improving both my technical and teamwork skills.

  • Why Test-Driven Development Matters in Modern Software Engineering

    For this blog entry, I explored the article “Test Driven Development (TDD) Tutorial” by Guru99 (available at: https://www.guru99.com/test-driven-development.html). This resource provides a practical explanation of Test-Driven Development and emphasizes how it improves software quality through disciplined testing practices.

    The article explains that TDD is a methodology where developers write automated test cases before writing the actual code. It describes the process in a structured way, starting with identifying requirements, writing a test case, developing code to pass the test, and then refactoring the code. It also highlights key benefits such as improved code quality, better design, fewer bugs, and increased confidence when making changes. Additionally, the article discusses some limitations, including the initial learning curve and the perception that TDD may slow down development.

    I chose this article because I wanted a beginner-friendly yet detailed explanation of TDD that connects directly to how we implement testing in class. In our Software Quality Assurance course, we are using tools like JUnit for writing test cases, and I wanted to see how TDD fits into a real development workflow beyond just writing tests after coding.

    From this resource, I learned that TDD is not only about testing functionality but also about enforcing better design principles. Writing tests first forces developers to clearly define expected behavior, which leads to simpler and more modular code. I also found it interesting that TDD encourages minimal coding—only writing enough code to pass the test—which helps avoid unnecessary complexity. This idea changed my perspective, as I used to write large portions of code first and then test later.

    This article had a strong impact on how I think about my future programming practices. I now understand that TDD can act as a guide during development rather than just a validation step at the end. In my upcoming assignments, especially when working on Java classes such as Product, Customer, and Order, I plan to first write JUnit test cases that define expected outputs and behaviors. Then I will implement the code step by step to satisfy those tests. This approach will help me catch errors early and ensure that my code meets requirements more reliably.

    Overall, this resource reinforced the importance of Test-Driven Development as a core practice in Software Quality Assurance. It showed me that writing tests first is not a limitation but a powerful strategy for building high-quality, maintainable software.

  • Testing with Stubs in Software Quality Assurance

    As part of my Software Quality Assurance and Testing course, I recently explored the concept of testing with stubs. To deepen my understanding, I referred to the article “Test Doubles: Stubs, Mocks, and Fakes” from Martin Fowler’s website.
    Link: https://martinfowler.com/bliki/TestDouble.html

    This resource explains different types of test doubles, including stubs, and how they are used when testing dependent components. A stub is a simplified implementation of a class that returns predefined values, allowing us to test another class even when its dependencies are incomplete or not yet implemented. The article also distinguishes between behavior-based testing (checking interactions between objects) and state-based testing (checking outputs or state changes).

    I chose this resource because I wanted a clearer and more practical explanation of stubs beyond classroom slides. Sometimes lecture content feels abstract, and I was looking for something that connects theory to real-world software development practices. Martin Fowler is also a well-known expert in software engineering, so I felt his explanation would be reliable and insightful.

    From this resource, I learned why stubs are especially useful during early development stages. For example, if a class depends on a database or external API that is not ready, we can create a stub that mimics expected behavior. This allows testing to proceed without waiting for the full system. I also understood the difference between verifying outputs (state-based testing) versus verifying interactions like whether a method was called (behavior-based testing). This helped me connect stubs with other testing concepts like mocks.

    One important takeaway for me was how stubs improve productivity and support incremental development. Earlier, I used to think testing could only happen after everything was implemented. Now I realize that with stubs, testing can happen in parallel with development. This is especially useful in team environments where different members are working on different modules.

    I also found the idea of output capture interesting. By capturing console output or logs, we can verify whether the correct method in the stub was called. This gives a simple way to perform behavior-based testing without complex frameworks.

    Going forward, I plan to apply stubs in my own projects, especially in my capstone project where multiple components depend on each other. Instead of waiting for all modules to be complete, I can use stubs to simulate dependencies and continue testing early. This will help me write more reliable and maintainable code. Overall, this topic has changed how I think about testing. It is not just a final step, but something that can be integrated throughout the development process.

  • Sprint Retrospective – Dependency Management in NodeJS Backend

    During this sprint, our team focused on dependency management for a NodeJS backend system within the LibreFoodPantry project. My primary responsibility involved updating dependencies, fixing compatibility issues, and ensuring that the backend remained stable after changes. This sprint required both technical work and strong collaboration with teammates.

    Evidence of Activity

    What Worked Well

    One thing that worked well during this sprint was team collaboration. I received a lot of helpful feedback from my teammates, especially during merge request reviews. This helped me improve my code quality and understand best practices for dependency updates. Another positive aspect was breaking down dependency updates into smaller commits, which made debugging and tracking changes easier.

    What Didn’t Work Well

    Updating dependencies turned out to be more complex than expected. Some updates caused compatibility issues, especially with libraries like express-openapi-validator. Also, switching from Yarn to NPM required careful adjustments, and initially, it introduced some confusion in the build process. These issues slowed down progress.

    Improvements as a Team

    As a team, we could improve by planning dependency updates more strategically. Instead of updating everything at once, we should group updates and test incrementally. Better documentation of decisions (like switching package managers) would also help everyone stay aligned.

    Improvements as an Individual

    Individually, I could improve by researching dependencies more before upgrading them. Understanding breaking changes ahead of time would reduce trial-and-error debugging. I also want to get better at reading official documentation and changelogs more efficiently.

    Apprenticeship Pattern: “Use the Source”

    Summary:
    The “Use the Source” pattern encourages developers to rely on original documentation, source code, and primary references instead of guessing or relying only on others.

    Why I Selected This Pattern:
    I selected this pattern because dependency management heavily depends on understanding library behavior. During this sprint, I often relied on teammates for guidance instead of directly exploring documentation or source code.

    Relevance to My Experience:
    When updating packages like Express or MongoDB, I encountered issues that could have been solved faster by checking official docs or GitHub repositories. This pattern directly relates to those situations.

    How It Would Have Changed My Behavior:
    If I had applied this pattern more actively, I would have spent more time reading documentation before making changes. This would have reduced errors and made me more independent. It would also have helped me understand why certain fixes worked instead of just applying them.

    Conclusion

    Overall, this sprint was a valuable learning experience in dependency management and teamwork. While there were challenges, especially with compatibility issues, I gained practical experience in maintaining a NodeJS backend. Moving forward, I plan to improve both my technical skills and my ability to work more independently while still collaborating effectively with my team.

  • Boundary Value Analysis in Software Testing

    In my self-directed professional development this week, I explored the topic of Boundary Value Analysis (BVA) in software testing. We have discussed this topic under the tutelage of Professor Perez recently. The article I selected is titled “Boundary Value Analysis” from the QAble testing blog. The resource explains how testers can design effective test cases by focusing on input values that occur at the boundaries of acceptable ranges. The article can be accessed here:
    https://www.qable.io/blog/boundary-value-analysis

    The main idea presented in the article is that many software defects occur not in the middle of valid input ranges but at the extreme boundaries of those ranges. Boundary Value Analysis is therefore a testing technique that concentrates on validating the minimum, maximum, and values just inside and outside the boundaries of input constraints. For example, if a system accepts numbers between 1 and 100, the key test cases should include values like 0, 1, 2, 99, 100, and 101. By testing these edge cases, software testers can identify logical errors or validation mistakes that might otherwise remain undetected.

    I selected this particular resource because boundary testing is a fundamental concept in Software Quality Assurance, which is directly related to the course material. As someone studying computer science with a focus on software engineering, understanding systematic testing strategies is important for writing reliable and robust software. I wanted to better understand how professional testers design test cases efficiently instead of randomly trying input values.

    One thing that stood out to me while reading the article is how small variations near boundaries can expose serious system defects. For example, input validation errors might allow illegal values or incorrectly reject valid ones. This made me realize that testing is not just about checking whether software works in normal conditions, but also about identifying edge cases where systems may fail. The article also emphasized that Boundary Value Analysis is often used together with Equivalence Partitioning, which further improves the efficiency of test design. This connection helped me understand how multiple testing techniques can complement each other.

    Reflecting on this resource, I learned that effective testing requires both analytical thinking and structured methodologies. In many of my programming assignments, I usually test my programs with a few normal inputs just to confirm that the program runs correctly. However, after reading this article, I realized that I should also intentionally test boundary conditions. For example, when designing programs that accept user input such as age ranges, scores, or array sizes, I should verify the smallest allowed value, the largest allowed value, and values just outside those limits.

    In my future software development practice, I expect to apply Boundary Value Analysis when writing unit tests and validation logic. As a future software engineer, I believe this technique will help me produce more reliable software systems and reduce unexpected runtime errors. Overall, this article reinforced the importance of structured test design in improving software quality.

  • Sprint 1 Retrospective Blog Post

    The Software Dev Capstone Project related Theas Pantry has been very valuable to me as far as providing me with near real Software Engineering experience is concerned. I am part of ‘Dependency Management and infrastructure updates’ Team.  We started this project first by working on GuestInfoBackend Module. As part of my role, I have completed below tickets

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/45db754a21c8e50ea05ac80a41233d797e0e1388

    Above is the link demonstrating my work of updating ‘winston’ package to latest version.  Secondly, I worked on updating the package ‘amqplib’ as well as illustrated by the below URL.

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/a810da88d2f11508a7316c6bea61e80fbf717fdc

    We then moved to updating dependencies for the ‘Frontend’ System. As part of this Sprint, I worked on below tickets

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/986bcf7d9885d8e27e7c619e40f1c77a8c1134cd

    As part of the current work on ‘Reporting System’, I worked on updating dependencies related to ‘mongodb’, ‘mocha’ and ‘chai’.

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/3dc96afa9fc27da3d541380efa10c77d0a08eb4f

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/7dba17365f41ea870f909495e799b1049700d2f9

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/1cd1be00b0788c2e9ff89043b1590e42064c5156

    What worked Well?

    We came together as a team and were fully aligned with our goals. We established communication channels using MS-Teams and were constantly working as a synergized team. We rarely had any misunderstandings or misgivings about each other and always assumed good intentions from each other’s work. We supported each other when we made mistakes and it was a thoroughly cherishable experience working with this team.

    What didn’t work well?

    I think our unfamiliarity with the technology stack consisting of NodeJS, java script and the whole art and science of dependency management threw many curve balls at us. We would have been more productive had we had previous knowledge of this technology stack. However, we overcome insurmountable odds and were able to honor the timelines that were provided to us.

    what changes could be made to improve as a team?

    The team has overcome the initial fear and lack of confidence very fast. The team is improving each week in terms of understanding the scope of work and the deliverables both from a technological and functional point of view. I do not think we have any compelling area that calls for radical improvement currently.

    What changes could be made to improve as an individual?

    I am basically an introvert and reserved by nature. I realized that such characteristics will not gel well with team-based Software engineering projects. I am inspired by the soft skills and confidence demonstrated by my teammates. I must improve my soft communication skills, articulate my thoughts better and be more vocal about my issues and deliverables.

    Apprenticeship Pattern

    Pattern Selected: Concrete Skills (from Apprenticeship Patterns by Dave Hoover and Adewale Oshineye)

    The Concrete Skills pattern emphasizes the importance of developing practical, hands-on technical abilities that can be directly applied in real software development environments. Rather than focusing only on theoretical knowledge, the pattern encourages software apprentices to deliberately practice specific skills such as programming, debugging, testing, and using development tools. By strengthening these tangible skills, a developer becomes more effective in contributing to team projects and solving real problems. The pattern also highlights that mastery in software engineering is built gradually through continuous practice and improvement of these concrete abilities.

    I selected this pattern because it strongly relates to my experience during the spring sprint in this course. As a senior computer science student, I noticed that many tasks during the sprint required applying specific technical skills rather than only conceptual understanding. For example, working with version control systems, debugging code, and collaborating with teammates required practical knowledge that comes from hands-on experience. The pattern resonated with me because it reinforces the importance of actively strengthening these core technical competencies.

    If I had read this pattern before the sprint, it likely would have influenced my preparation and approach. I would have spent more time practicing the relevant tools and technologies beforehand, particularly debugging techniques and collaborative development workflows. This preparation could have helped me work more efficiently and contribute more confidently to the team throughout the sprint.

  • Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

    I thoroughly enjoyed reading the textbook “Apprenticeship Patterns”. I wish I had read it much earlier in life. It is very inspiring and inculcates enormous wisdom to young aspiring professionals across all trades but more particularly in Software Domain.

    I found it very interesting that the book discourages aspiring Software development practitioners to discard the path of aspiring to become middle managers or C-Suite honchos. It states in very clear terms that becoming managers would mean that we become armchair experts and lose the grip on ground realities soon. It emphasizes the fact that we should focus on becoming better in a consistent manner in our Software development craft without being greedy about material gains or false perspective on what conventional society considers as success. For e.g… Society considers a Senior Vice President or CIO more successful than a dedicated Staff Engineer. But the Staff Engineer has dedicated their life to becoming good at what they started in their youth and get a sense of fulfillment from their work.

    The reading has caused me to change my opinion. I now learnt that I should always strive to be in teams where I am the poorest or weak aptitude wise. This gives me opportunity to learn from professionals who are much better than me and gain from their enormous experience. Before reading this book, I aspired to find jobs that would provide me with a comfort zone. I cherished reading the quote by C.S. Lewis in “Learning in Wartime” in this book. The quote states that “The only people who achieve much are those who want knowledge so badly that they seek it while the conditions are still unfavorable. Favorable conditions never come”. This is a very inspiring quote that compels us to get into the grind without waiting for perfect weather.

    So far, I have not found anything that I disagree with in this book. However, I would be curious to know the author’s perspective on this topic in this age of Generative AI. How should Software Interns and apprentices hone their craft with the advent of Large Language models. This especially considers so many predictions in recent times that this entire skill and the demand for it will soon die down. Agentic AI will replace Software Engineers. I would still assume Software Engineers may be needed to provide human oversight. However, time will tell on this subject.

    I think all chapters are important and align well with the over-arching topic. I am going to read and read this book several times during my lifetime. I am grateful for this opportunity.

  • Getting Started with JUnit: Testing in Java

    As part of our course material on software quality and testing, I chose to read the blog post “Getting Started with JUnit Testing: The Path to Effective Java Automation” https://www.frugaltesting.com/blog/getting-started-with-junit-testing-the-path-to-effective-java-automation published on Frugal Testing. This resource directly relates to what we have been learning about unit testing and test-driven development, especially in Java-based applications. Since JUnit is one of the most widely used testing frameworks in Java, understanding its fundamentals is essential for any computer science student who plans to work in software development.

    The blog post provides a clear and structured introduction to JUnit, explaining what unit testing is, why it matters, and how JUnit supports automated testing in Java projects. It walks through key concepts such as test cases, assertions, annotations like @Test, and the general workflow of writing and executing tests. The author also emphasizes how automated unit tests help catch bugs early, improve code reliability, and support refactoring. Overall, the article serves as a practical starting point for developers who are new to testing or want to strengthen their testing practices.

    I selected this particular resource because I wanted a beginner-friendly yet practical explanation of JUnit that connects theory with real-world usage. While we often hear about the importance of testing in class, it can be difficult to visualize how testing fits into everyday development. This blog stood out because it focuses on hands-on testing concepts rather than abstract definitions, making it easier to connect course topics to actual coding practice.

    One of the most important things I learned from this article is how unit testing is not just about finding bugs, but about improving the overall design and maintainability of code. Writing tests forces developers to think more carefully about how their code is structured and how different components interact. The explanation of assertions helped me better understand how tests validate expected behavior, and the overview of JUnit annotations clarified how test execution is managed behind the scenes.

    This resource changed how I think about testing in my own projects. Previously, I viewed testing as something optional or done at the end of development. After reading this article, I see testing as an integral part of the development process. In the future, I expect to apply what I learned by writing JUnit tests alongside my Java code, especially for assignments and personal projects. This approach will help me catch errors earlier, write cleaner code, and build confidence in my software.

    Resource Link:

    https://www.frugaltesting.com/blog/getting-started-with-junit-testing-the-path-to-effective-java-automation

  • Introductory Blog Post for CS-443-01

    Hello, my name is Vishisht Seku. This is my Blog Post related to subject CS-443(Software Quality Assurance & Testing.) I am very glad to be a part of this class and learn more about the process of Software Quality Management.

  • Introductory Post on LibreFoodPantry and Thea’s Pantry

    One part of LibreFoodPantry that I found especially interesting was its mission to connect computer science education with real humanitarian impact. Rather than treating software development as an abstract or purely technical exercise, LibreFoodPantry shows how code can directly support local food pantries and the people who rely on them. The idea that free and open-source software can be adapted to meet the needs of different communities stood out to me, because it emphasizes flexibility, accessibility, and long-term usefulness instead of profit.

    I chose to write about this mission because it reframes how I think about computing as a field. As a senior at Worcester State University, much of my coursework has focused on efficiency, correctness, and performance. While those skills are important, LibreFoodPantry highlights another dimension of computer science: responsibility to society. By involving students and faculty in instructor-led, open-source projects, the organization creates a learning environment where technical skills are developed alongside empathy and civic awareness. This approach makes the work feel meaningful and shows that software can be a practical tool for social good, not just a career skill or academic requirement.

    The one thing that I thoroughly enjoyed reading about Thea’s Pantry was the Developer Documentation section. As an aspiring Software and Data Engineer this documentation was a revelation and a textbook. I liked the sections around ‘Code of Conduct’ and ‘Inclusive Language’ a lot. They inspire us to take a moral high ground and be kind and compassionate to our team members.

    I also enjoyed the technical sections that gave me a good grasp on managing Workflows using the Git Branch, Pull Request protocol. Other sections such as ‘Release Process’ and ‘Pipelines’ provide a rigid framework around the intended CI/CD Process. Regarding ‘Dependency Management’ I was surprised to find differences between ‘Dependencies’, ‘Dev Dependencies’ and ‘Peer Dependencies’. So far, I only assumed we need to manage ‘Dependencies’ as a single unit.

    I am very glad to be part of this Capstone Project with a noble mission.