Author Archives: donna abayon

Sprint 1 Retrospective Blog Post

As a Computer Science major in my final year of college, I thought I had learned everything I needed to know. However, my Software Development Capstone class has proven me wrong. I’ve realized there’s still so much to learn, especially when it comes to working in a team and building a project from scratch. My team and I were tasked with creating a system to improve the University’s food pantry inventory management. This project has been both challenging and rewarding, and Sprint 1 was a great starting point for our journey.

GitLab Evidence

Throughout Sprint 1, my partner and I focused on creating the frontend prototype for the barcode scanner. Below are the links to our GitLab activities, along with a brief description of each:

  • Initial Front Page:
    GitLab Issue #7
    Description: Created the initial front page using HTML and CSS.
  • Scanner Page:
    GitLab Issue #9
    Description: Created the scanner page using HTML, CSS, and JavaScript to implement the barcode scanner.
  • Barcode Scanning Functionality:
    GitLab Issue #10
    Description: Implemented the html5-qrcode library to enable barcode scanning functionality.
    Library Link: html5-qrcode GitHub
  • Displaying UPC Results:
    GitLab Issue #11
    Description: Modified the scanner page to display the results of the UPC.
  • Aesthetic Improvements:
    GitLab Issue #12
    Description: Improved the aesthetics of the front page (index.html) and scanner page (scanner.html) by updating the color palette and fonts.

Despite being strangers at the beginning of the semester, my team has worked together seamlessly. We communicate effectively, both in and out of class, and support each other not only in this project but also in our other classes. Everyone feels comfortable asking questions and sharing ideas without fear of judgment, which has created a chill and productive atmosphere. Additionally, our scrum master assigned us to sub-teams, and each member knew exactly what they needed to do. This clarity helped us stay organized and focused.

While we used GitLab to track issues, we could have utilized it more effectively. For example, we sometimes forget to update issues or document progress in detail. Also, since my partner and I were new to frontend development, we spent a lot of time learning the basics of HTML, CSS, and JavaScript, which slowed down our progress initially. In Sprint 2, we plan to use GitLab more effectively to track issues, as we discussed during sprint planning. My team and I will make a conscious effort to update GitLab issues regularly and document our progress more thoroughly. This will help us track our work more effectively, avoid confusion, and ensure that everyone is aligned on the tasks and their status.

I want to dedicate more time outside of class to learn frontend technologies. This will help me contribute more effectively to the project and build a stronger foundation for my future career. In Apprenticeship Patterns by Dave Hoover and Adewale Oshineye, the pattern “The Long Road” emphasizes the importance of committing to a lifelong journey of learning and mastery. It encourages aspiring software craftsmen to focus on long-term growth rather than chasing quick success, promotions, or material rewards. The pattern reminds us that mastery takes time and that we should embrace the journey, even if it means being seen as unconventional. I selected this pattern because it resonated deeply with my experience during Sprint 1. As someone who is new to frontend development, I felt overwhelmed at times by how much I still needed to learn. However, this pattern reminded me that mastery is a gradual process and that I shouldn’t compare myself to others who may seem further ahead. It also reinforced my desire to focus on frontend development as a long-term career path, even if it means taking the time to build a strong foundation. If I had read this pattern earlier, I would have approached Sprint 1 with more patience and confidence. Instead of feeling pressured to produce quick results, I would have focused on learning and improving my skills at a sustainable pace. This mindset would have helped me enjoy the process more and reduce the stress of trying to catch up to others.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

The Software Craftsman’s Journey: Embracing Learning and Growth

Reading Apprenticeship Patterns was an eye-opening experience. Initially, I was confused by the book’s structure, particularly the sections labeled Context, Problem, Solution, and Actions. I assumed the book would be highly technical, filled with complex concepts. However, after I kept reading, I realized that it was quite the opposite. The book is structured in a way that real-life scenarios that apprentices(interns) or newcomers in the software field might encounter, followed by practical solutions and guidance.

One thing that stood out to me was how much I wished I had read this book earlier in my academic journey. As a senior in Computer Science who transitioned from Nursing, my early years in this major felt overwhelming. Learning my first programming language felt like being thrown into the ocean with just one pool noodle. Each new concept learned added another pool noodle, but the struggle to stay afloat was real. This book, had it been introduced in my freshman year, could have served as a guide for navigating challenges, understanding the learning process, and overcoming self-doubt.

What truly changed my perspective was how the book reframes the way we approach learning and problem-solving. It’s not just about memorizing syntax or mastering algorithms but about adopting the right mindset when facing challenges. One of the most impactful insights for me was the idea that learning is an ongoing journey, and it’s okay to struggle. I often get frustrated when I forget concepts I previously learned, but the book reassured me that this is normal. The phrase “You must unlearn what you have learned” resonated with me deeply. It reminded me that forgetting is not failure; it’s an opportunity to re-learn with better understanding. This realization has helped me become more forgiving toward myself when struggling with new skills or concepts.

Chapter two, in particular, resonated with me because it addressed the common issue of struggling to acquire new skills and knowledge retention. I often worry that if I don’t practice something immediately, I will forget it, leading to self-doubt. This chapter provided strategies to combat this issue, encouraging a more structured and patient approach to learning. By applying these principles, I feel more confident in my ability to retain knowledge over time.

Overall, Apprenticeship Patterns is an invaluable resource that I believe all Computer Science students should read early in their studies. It doesn’t just teach technical skills but also offers a roadmap for navigating the emotional and intellectual challenges of becoming a Software Craftsman. While I didn’t find anything in the book that I strongly disagreed with, I do wish it had been a part of my curriculum earlier. This book has reshaped how I view my learning journey, making me more comfortable with the idea that mastery takes time, patience, and continuous effort.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Exploring LibreFoodPantry and Thea’s Pantry

The LibreFoodPantry’s Mission page stood out to me for its dual focus on developing free, open-source software (FOSS) for food pantries and educating students on using tech to address social inequalities like food insecurity. By using coding as a tool for social good, the project transforms classroom learning into real-world impact for example, building inventory systems to help pantries distribute resources more efficiently. I chose this because, as I prepare to contribute until graduation, I want to see how my technical efforts can address community needs. LibreFoodPantry’s mission aligns with my goal to work on projects that prioritize purpose over profit, and it’s motivating to know my contributions at Worcester State could directly support local food pantries.

In Thea’s Pantry’s GitLab repository, I explored the Inclusive Language documentation and was surprised by its integration of the Alex linter—a tool that flags exclusionary terms in documentation, such as gendered language or ableist phrases like “crazy.” This was my first encounter with such a tool. I chose this because it reflects the project’s commitment to inclusivity at every level, ensuring contributors feel welcome. As a student entering the tech field in the future, this practice resonates deeply; it’s a reminder that ethical design isn’t just about functionality but also about creating spaces where diverse voices can thrive.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Intro to Software Quality Assurance and Testing

This blog will document my learning experience for CS-443, both inside and outside of the classroom. My goal is to reflect on my progress and provide a space to explore how the concepts learned in class apply to real-world scenarios.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Core Principles of Clean Code

In software development, writing clean code is essential for creating maintainable, scalable, and efficient applications. The article “The Core Principles of Writing a Clean Code” by Arthur Coudouy provides valuable insights into the fundamental principles that contribute to clean coding practices.

The article emphasizes that clean code is easy to understand, simple to modify, and efficient to maintain. It highlights key principles for achieving clean code:

  • Simplicity: Avoid convoluted logic; clear and simple code is easier to maintain and scale.
  • Consistency: Use consistent naming and structuring to make code readable and predictable.
  • Clarity Over Cleverness: Optimize for readability; complex solutions should not come at the cost of clarity.
  • Code Review Automation: Utilize automated code review tools to enforce standards and maintain consistency across the codebase.

I selected this article because it aligns directly with our course material on best coding practices. Another reason I chose this topic is that being a programmer is not just about writing code. There are many important factors, such as debugging, making your code efficient, and ensuring it is easy for other programmers to understand. Understanding and applying clean code principles is crucial for developers to produce high-quality software and collaborate effectively within teams.

The article reinforced the importance of writing code that is not only functional but also easy to read and maintain. I learned that simplicity and consistency in code structure significantly enhance its scalability and efficiency. I also appreciated that the article provided examples of how the principles of clean code can be applied. The emphasis on clarity over cleverness resonated with me, as overly complex solutions can make understanding and make future modifications more challenging.

Armed with these insights, I plan to apply several strategies to improve my future coding practices. I will prioritize simplicity by writing straightforward code, avoiding unnecessary complexity to ensure maintainability. Maintaining consistency will also be a key focus; I will use clear naming conventions and structured code to make my work predictable and easier to understand. Additionally, I will emphasize clarity over cleverness, creating solutions that are easy to grasp and effectively communicate their purpose. Lastly, I intend to to use the automated code review tools to uphold coding standards and streamline the review process, fostering better collaboration and consistency within a team. By adopting these practices, I aim to contribute to the development of robust, efficient, and maintainable software for my future career as a software developer.

Sources:
The Core Principles of Writing a Clean Code

Citations:
Coudouy, Arthur. “The Core Principles of Writing a Clean Code.” Axolo Blog, Axolo, 31 Oct. 2024, axolo.co/blog/p/core-principles-of-writing-clean-code.  

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Understanding Technical Debt

In software development, technical debt refers to the extra work required in the future when quick, easy solutions are chosen instead of more thorough, time-consuming approaches. This concept is explored in the article “What is Technical Debt & How Can Companies Manage It?” by Coder Academy.

The article defines technical debt as the accumulation of suboptimal code or design choices made to deliver projects faster. While these shortcuts may lead to quicker releases, they often result in higher maintenance costs and reduced code quality over time.

Key Factors Contributing to Technical Debt

  • Time Constraints: Meeting tight deadlines can lead to hasty decisions that prioritize speed over quality.
  • Evolving Requirements: As project requirements change, older code may no longer align with the current needs.
  • Lack of Documentation: Poor documentation can create misunderstandings and increase errors, contributing to technical debt.

Strategies for Managing Technical Debt

The article suggests several ways to manage technical debt effectively:

  • Regular Code Reviews: Consistently reviewing code helps identify and address suboptimal practices early.
  • Refactoring: Improving existing code without changing its functionality can enhance readability and maintainability.
  • Comprehensive Documentation: Thorough documentation supports better understanding and future modifications.
  • Prioritization: Address technical debt based on its impact on the overall project’s progress and quality.

I chose this article because technical debt is a common issue in software development and is closely related to our course material. For Computer Science students, learning how to avoid technical debt is critical. If technical debt becomes a habit, it can lead to poor time management, less active learning, and weak decision-making skills. Understanding its causes and management strategies is essential for maintaining code quality and ensuring project success.

The article provided valuable insights into technical debt and its consequences. I learned that while quick fixes may save time initially, they often lead to higher maintenance efforts and system issues later. The importance of regular code reviews and refactoring stood out, as these practices can help reduce technical debt and improve code quality.

I also appreciated the visual diagrams and tables in the article, which made it easier to understand what technical debt is and how to manage it. I particularly liked the advice on avoiding technical debt and understanding its long-term impacts as a programmer.

By adopting the strategies outlined in the article, I aim to contribute to developing sustainable, high-quality software solutions. This knowledge will help me avoid accumulating technical debt in my future work. I am motivated to build new habits, such as maintaining good documentation, participating in regular code reviews, and prioritizing refactoring. These practices will help me become a more effective and skilled programmer.

Sources:
What is Technical Debt, and how can you manage it?

Citation:
Academy, Coder. “What Is Technical Debt, and How Can You Manage It?” Medium, Medium, 18 May 2016, medium.com/@coderacademy/what-is-technical-debt-how-can-companies-manage-it-1af08992f6d0. 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

A Student’s Perspective: Comparing GitLab and GitHub in Software Projects

In the world of software development, effective version control and collaboration is very important. Two prominent platforms facilitating these needs are GitLab and GitHub. The article “Difference Between GitLab and GitHub” from GeeksforGeeks offers a comprehensive comparison of these platforms, highlighting their unique features and differences.

The GeeksforGeeks article delves into the distinctions between GitLab and GitHub, focusing on aspects such as:

  • Continuous Integration/Continuous Deployment (CI/CD): GitLab provides built-in CI/CD capabilities, enabling seamless automation of the software development lifecycle. In contrast, GitHub requires third-party integrations to achieve similar functionality.
  • Self-Hosting Options: GitLab offers a free community edition that supports self-hosting, granting users full control over their repositories. Conversely, GitHub self-hosting is available only through its paid enterprise version.
  • User Permissions and Collaboration: GitLab’s free version allows for more extensive user permissions, including role-based access controls and protected branches in private repositories. GitHub imposes more restrictions in its free tier, such as limiting protected branches to public repositories and capping the number of collaborators in private repositories.

I chose this article because it provides a clear and concise comparison of GitLab and GitHub, two platforms integral to modern software development. Understanding their differences is crucial for developers and teams aiming to select a tool that aligns with their workflow and project requirements. I also chose this article because we use both platforms in class. In the beginning of the semester, if someone was to ask me what the main difference is between GitLab and GitHub. I would not be able to tell them.

The article enhanced my understanding of the operational variances between GitLab and GitHub. I learned that GitLab’s integrated CI/CD pipelines can streamline development processes by reducing reliance on external tools. This integration allows a more cohesive environment for managing code changes, testing, and deployment.

Additionally, the flexibility of self-hosting with GitLab’s free community edition offers significant advantages for organizations concerned with data privacy and security. It allows for greater control over the development environment without incurring additional costs.

The article also shed light on the importance of user permissions in collaborative projects. GitLab’s comprehensive role-based access controls in its free version facilitate better management of team contributions and code integrity. In contrast, GitHub’s restrictions in its free tier may pose challenges for larger teams or projects requiring stringent access controls.

Recognizing the importance of these platforms in the industry, I am committed to deepening my proficiency with both GitLab and GitHub. I plan to engage with comprehensive tutorials and hands-on projects to master their functionalities. By dedicating time to explore and practice with these platforms, I aim to position myself as a proficient user, ready to contribute effectively in professional settings where these tools are integral. This proactive approach will not only enhance my technical skills but also increase my employability in a competitive job market.

Sources:
Difference Between GitLab and GitHub

Citation:

“Difference between GitLab and Github.” GeeksforGeeks, GeeksforGeeks, 23 July 2024, http://www.geeksforgeeks.org/difference-between-gitlab-and-github/. 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Backend Architecture

Back-end architecture serves as the backbone of modern web applications, enabling ideal and flawless user interactions and efficient data management. The Codecademy article “Back-End Architecture” provides an insightful overview of the fundamental components and design principles that make up the back end of web systems. It summarizes the key takeaways from the article, reflects on its relevance to software development practices, and outlines its implications for aspiring software engineers.

The article begins by explaining the primary purpose of back-end architecture to manage the behind-the-scenes functionality of web applications that the user can’t see. It underlines the importance of servers, databases, and APIs in creating a solid infrastructure. This is what the article key topics covered:

  • Servers: These handle requests from the front end and deliver the necessary responses. The article discusses server setups like dedicated, shared, and cloud servers.
  • Databases: Central to storing and retrieving data, the article explores relational databases (SQL) and non-relational databases (NoSQL), emphasizing their use cases and advantages.
  • APIs: Acting as the glue between the front end and back end, APIs enable seamless communication between various components of an application.
  • Scalability and Security: The article addresses the importance of designing scalable systems and implementing robust security measures to safeguard user data and maintain application performance.

One reason I chose this article is that we are currently learning about REST APIs in class. I wanted to deepen my understanding of how APIs are used in developing web applications and their role in back-end systems. As a Computer Science student, I aspire to build more complex projects in the future where I can apply this knowledge. The article’s clarity and engaging presentation made it both interesting and easy to understand, which further motivated me to select it as a resource.

Reading this article deepened my understanding of how back-end systems operate and how they connect with front-end components. One key takeaway was the example it provided about how a client makes a request to the server. The article gave a detailed yet digestible explanation of this process, which was different from the visual and interactive activities we did in class. For instance, the explanation of what happens during a client’s GET request clarified the flow of communication between the client and the server, making the concept more relatable and easier to grasp.

What I learned from this article will help me approach back-end development with confidence. For my upcoming project, I plan to focus on designing a system that effectively integrates APIs and databases. Ensuring scalability and security will be a priority to make the application robust and user-friendly. These insights will serve as a foundation for building more complex projects in the future.

Source:
https://www.codecademy.com/article/back-end-architecture

Citation:
Codecademy. (n.d.). Back-end web architecture. https://www.codecademy.com/article/back-end-architecture 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Understanding The Waterfall Methodology

At the start of the semester, we talked about Software Methodologies, and one of the topics we covered was the Waterfall Methodology. The article I chose focuses on the Waterfall Methodology, which emphasizes completing and approving each phase before moving to the next. This approach helps reduce errors, making the process more time-efficient and improving project documentation.

The Software Development Life Cycle (SDLC) is divided into six phases: requirement analysis, software design, planning, software development, deployment, and testing. When the Waterfall Model is applied to the SDLC, it adds structure by defining the time and duration for each phase. This helps developers and teams better understand how long the process will take and what to expect at each step.

The article also explains when the Waterfall Model is the best choice for a project. Since every methodology is different, this model works well for projects with clear concepts, less complexity, a solid and unchanging plan, and minimal room for errors (no repeated phases). It’s commonly used in industries like healthcare and banking. The article also discusses the advantages and disadvantages of the Waterfall Methodology.

One advantage I really like is that each phase is completed one at a time, providing a clear and straightforward plan for programmers to follow. However, a disadvantage I find inefficient is that progress can be slow, which might make it harder to estimate when the project will be completed.

The article outlines the distinct phases of the Waterfall Model:

  • Requirement Analysis: Gathering and documenting what the software needs to achieve.
  • System Design: Translating requirements into system specifications, including hardware and architecture considerations.
  • Implementation: Developing individual units or components based on the design.
  • Testing: Integrating and rigorously testing components to find and fix issues.
  • Deployment: Releasing the completed software to clients or the market.
  • Maintenance: Providing ongoing support, including patches, bug fixes, and updates.

I chose this article because it provides a clear and concise explanation of the Waterfall Model. I also wanted to learn more about this methodology and how it differs from others. Waterfall is one of the more popular choices among engineers and developers, and now I understand why. Its structured approach makes it appealing for certain types of projects, even though it may not always be the fastest.

Looking ahead, I want to apply what I’ve learned about the Waterfall Methodology to my future career as a software engineer and projects like my Software Capstone class next semester. Understanding how to plan and organize phases systematically will be important for delivering a successful project. I also want to explore other software methodologies to understand their strengths and weaknesses. Knowing when and what type of project each methodology works best for will help me decide how to approach different challenges in my career.

Source:
What Is The Waterfall Model?

Citation:
Team, Codecademy. “What Is the Waterfall Model for Software Development?” Codecademy Blog, 7 June 2024, http://www.codecademy.com/resources/blog/what-is-the-waterfall-model/. 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Microservices and Their Importance

The blog “Microservices Architecture for Enterprises,” authored by Charith Tangirala, provides a detailed summary of a talk by Darren Smith, a General Manager at ThoughtWorks Sydney, on implementing microservices architecture in large enterprises. The blog explores key considerations for transitioning from monolithic systems to microservices, including cultural, technical, and operational changes. It highlights critical topics such as dependency management, governance, infrastructure automation, deployment coupling, and the evolving role of architects in fostering collaboration between technical and business teams. By sharing practical insights, the blog offers a framework to assess whether microservices are suitable for specific organizational goals and challenges.

I picked this blog because we are currently learning about microservices and APIs in class. I wanted to explore how the concepts we are studying are applied in real-world scenarios and understand their practical importance. This blog stood out because it connects the theoretical foundation of microservices with the challenges and solutions encountered in large enterprises. By studying this resource, I aimed to gain insights into why microservices are a valuable architectural choice and what factors should be considered when implementing them.

One key takeaway from the blog was the explanation of “deployment coupling.” It was interesting to learn how monolithic systems often require synchronized deployments, while microservices, through the use of REST APIs, allow for independent service releases. This flexibility is one of the main benefits of microservices. At the same time, the blog points out operational challenges, such as the complexity of monitoring and managing numerous services, which requires a strong DevOps infrastructure. It reminded me that while microservices can provide agility, they also demand careful planning and strong operational practices.

Another important point was the emphasis on organizational culture. The blog highlights how the success of microservices depends on cross-team cooperation, education, and alignment. This reinforces the idea that architecture isn’t just about technology—it’s about how people and teams work together. It made me realize that adopting microservices is as much about communication and collaboration as it is about code. I’ve also learned that companies like Netflix and Amazon have already implemented microservices architecture, leading to significant success with their products. This real-world application of microservices by industry leaders shows how impactful this approach can be when implemented effectively, further inspiring me to learn more and apply these principles in future projects

As I move forward, I want to keep learning more about microservices and APIs and use what I’ve learned in future projects. My goal is to apply these concepts to real-world problems and build systems that are flexible and efficient. I also hope to use this knowledge in my future career as a Software Developer, where I can create scalable and innovative solutions.

Sources:

Microservices Architecture for Enterprises

Citation:

Tangirala, Charith. “Microservices Architecture for Enterprises.” http://www.thoughtworks.com, 13 July 2015, http://www.thoughtworks.com/insights/blog/microservices-architecture-for-enterprises. Accessed 23 Nov. 2024.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.