Category Archives: CS@Worcester

Sprint Retrospective

Sprint 2 Retrospective

Introduction

  • In this sprint we were focused on scaling up our productivity and getting the UI underway.
  • This sprint lasted longer than sprint 1 but ended up feeling very back heavy because we were delayed on working on the front end until we had access to the new template.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well?
  • Like the last, In this sprint I found that communication as a group was key to our success. Any problems that we faced were made much easier when we tackled them as a group instead of alone. I think that our review process was good and allowed us to effectively tackle our goals.
What Didn’t Work Well?
  • I think that the main thing that we struggled with was managing the time of this sprint, considering that we were halted in our efforts to make the front end until we had a working template to base ours off of. In the end we got it done after a busy end of sprint.

Improvements for Team Performance

The team’s ability to communicate and tackle problems collectively was a strong point during this sprint. It was an effective carry over from the last sprint and will hopefully be reflected in the next sprint as well with some of the following improvements:

  1. Keep a consistent schedule: In hopes to avoid a repeat of the last sprint where everything was stacked at the back of the sprint, It would be beneficial to manage our time better as a group with a more consistent meeting time.
  2. Division of Labor: we continue to ensure that one person does not get stacked with to much to do while others get left with little to work on.
  3. Streamlined Communication Channels: Same as the last sprint, ensuring that all discussions, especially those related to problem-solving and decision-making, are logged in an accessible and organized manner would help maintain clarity and continuity.

Personal Improvements

Reflecting on my personal challenges during this sprint, specifically around managing merge requests correctly, I see valuable opportunities for growth:

  1. Gitlab Use: I still struggle with some aspects of gitlab and hope to improve that for sprint 3.
  2. Proactive Communication: To prevent and swiftly address any uncertainties or errors in my work, I commit to being more proactive in seeking feedback and clarifications from team members.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

Sprint 2 planning

Throughout our team discussions, we addressed several key points:

Some tasks (OL-1) weren’t completed by another group, who claimed they were done or unnecessary. We need to inform the professor (#26).

We need to ensure that the guestinfofrontend knows which server address it’s using. Adjusting the Gitpod ci.yaml file can help with this.

The backend server is encountering issues and isn’t running properly, especially affecting weight increment functionalities.

Creating a Gitpod initialization task will automate setting up the workspace’s address, streamlining our workflow.

We should utilize environment variables to manage URLs, distinguishing between local and Gitpod environments for better configuration.

Setting a backend base URL will prevent hardcoding and make it easier for the frontend to access.

We need to troubleshoot module not found errors, which may be related to exports or syntax issues.

Enhancing our debugging capabilities with JavaScript tools will improve error detection and resolution.

Conducting experiments and documenting findings will help guide our future actions and decisions.

Thorough documentation is crucial for the benefit of future teams, especially if time is limited.

We must prepare for presentations during exams, focusing on showcasing our team’s progress.

Improving our planning and testing processes will lead to smoother project execution and fewer setbacks.

Providing clear integration examples and deployment instructions will facilitate seamless implementation.

Utilizing collaborative tools will enhance efficiency in task management and communication.

Lastly, we should compile promising solutions into a shortlist for further evaluation and consideration.

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

Chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman”.

In Chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,” called “Emptying the Cup,” the focus is on the notion that effective learning requires individuals to recognize and accept their current shortcomings and biases. The chapter emphasizes the significance of maintaining an open mind and welcoming new concepts, even when they contradict what one already knows.

In the opening of the chapter, the idea of an “empty cup” is explained using a story about a martial arts student who seeks guidance from a master. However, the student’s mind is already filled with his own beliefs and assumptions, making it difficult for the master to impart knowledge effectively. The student must metaphorically empty his cup, shedding his preconceived notions, to be receptive to genuine learning.

The key lesson is to embrace humility and openness in career advancement, acknowledging constant room for improvement and discarding outdated habits, assumptions, and biases to facilitate growth.

The chapter offers useful guidance on how to embrace the concept of “emptying the cup” by urging readers to actively pursue experiences that push the boundaries of their current understanding and beliefs. This might entail taking on projects that are unfamiliar, soliciting input from colleagues, or deliberately practicing to enhance skills in weaker areas.

What’s interesting about this chapter is its emphasis on the importance of mindset in the learning process. It underscores that achieving mastery isn’t solely about amassing information and abilities, but also hinges on cultivating a receptive attitude toward learning and development. Embracing the notion of the “empty cup,” readers are motivated to approach their evolution as software craftsmen with curiosity, humility, and an open-minded outlook.

This chapter proves useful as it provides actionable methods for overcoming cognitive biases and constraints that may hinder personal development. By acknowledging the significance of embracing new perspectives, readers can foster a mindset conducive to ongoing progress and expertise. This approach can enhance creativity, innovation, and effectiveness in software development, while also fostering personal fulfillment and satisfaction in one’s professional endeavors. Ultimately, “Emptying the Cup” serves as a beneficial reminder of the essential role humility and open-mindedness play in striving for excellence.

Reflecting on Chapter 2 of “Apprenticeship Patterns,” I recognize the need to critically assess my choice of programming language. Considering factors like ecosystem, learning style alignment, and industry relevance, I understand that my initial assumptions may require reassessment. Embracing this change in perspective prompts a more intentional approach to learning, potentially leading to greater mastery and fulfillment in my profession.

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

CS448 – Sprint 2 Retrospective

Our second of three sprints for CS448 – Software Development Capstone concluded and was reviewed last Tuesday (4/7/2024). My team worked very well together this sprint and we helped each other as we stayed flexible and adaptable as changes were rolled out that affected our repo and issues. Additionally, most of our issues focused on FrontEnd tasks including the design, development,  and integration of a user interface for the CheckoutGuestFrontend repo. UI design and particularly implementing Vue.js framework was mostly unfamiliar for our group, so we learned a lot from what we accomplished this sprint.

While we didn’t quite finish all of our initially planned tasks, we did successfully reorganize issues into smaller/more manageable and defined issues mid-sprint and we completed all of our issues up to testing the front-end we built:

“Get in touch with Team: 01-2 and discuss Frontend Tests and their findings” – When we took on the task of developing the CheckoutGuestFrontend repo, we found Team 2 had already taken on some responsibilities and begun researching front-end testing. So our first order of business was holding a meeting with them to decide on a starting point for our group. Our notes from the meeting are recorded here.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/92

“Review GUI Mockup” – For this task, we all met as a group to go over a basic on-paper mockup of what we envisioned and had in mind for the CheckoutGuestFrontend GUI and break down the task of coding the GUI into smaller, more manageable and well-defined issues. In the issue, we document our hand-written mock-up as well as our meeting notes and the smaller issues we refactored to. The “Consider Interaction Boundaries” and “Modify/Improve GUI Framework” issues were encompassed in the preparation and execution of this Review task.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/45

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/44

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/42

Main issue:

“Coding UI to place components on the screen where we want them (“layout”)” – This task encompasses the overall processes of creating the Vue.js, integration, and other resource files and code to actually implement our mock-up. This was our first time working with Vue.js, and we are also less experienced with JavaScript as compared to other languages like Java and Python, so we hit some setbacks and delays as we explored and learned more about using these. There were also some minor steps involving communication protocols that were learning experiences.

Another obstacle we traversed involving this issue is the rollout of the new frontend model by Dr. Wurst. When we first tackled this problem, it was not yet released so we struggled to get a working baseline/framework to edit and build off of.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/43

“General – Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” – This was a task from last sprint which we did not quite complete. This sprint we finished it up by verifying the necessary components. Once the working model was rolled out, we managed to build ours out to a stable state with an attractive UI by holding several full-team code reviews. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12 

In review, our second sprint for CS448 – Software Development Capstone was driven by patience, teamwork and adaptability. Despite encountering challenges, particularly in navigating unfamiliar territory with UI design and Vue.js implementation, we emerged stronger and more knowledgeable. While we didn’t fully complete all initially planned tasks, our ability to reorganize issues mid-sprint into smaller, more manageable ones allowed us to focus on essential aspects. Key achievements included productive collaborations with Team 01-2 on frontend testing, thorough review and refinement of GUI mockups, and overcoming hurdles in coding the UI with Vue.js. We also successfully addressed pending tasks from the previous sprint, ensuring all projects within Thea’s Pantry ecosystem met required standards.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

This was our second sprint of the semester and I would say we definitely did better in some aspects as a team while we still need to work on other aspects. I personally worked on one issue on my own while we did all the other issues completed during the sprint as a team during our meetings. These issues included ensuring the proper linters and pipeline stages in a repo, researching how to write vue code and implementing said code as well as developing the frontend with buttons and input fields to prepare for a confirmation page next sprint. Our group issue that we completed included researching vue as well as redesigning the wireframe for the addInventory frontend.

Overall I did not have any trouble with my individual issue during this sprint. My issue I worked on regarding the addition of linters and pipeline stages was straightforward and I was able to complete it without much delay as there were not many issues in any of the files after implementation of the necessary linters. The first issue that we worked on as a team regarding the research of vue code and making an example button also went well and did not take us long during our meeting. The second issue we worked on as a team included working on the frontend which was rather challenging as we do not have much experience with the frontend between us but we were able to add two buttons along with input fields in order to have a displayable frontend. Our last issue as a team was to redesign the wireframe for the frontend in order to prepare for sprint 3 which went very well as we are planning on adding a second page to the frontend which confirms the addition to the inventory.

We did not have many problems during this sprint but I still feel as though there are things we could work on to improve as a team. One thing we can improve on is everyone making it to scheduled meetings, during the sprint we had meetings where we were not all in attendance and the team members in attendance did not know that others would not be making it to the meeting so I believe we need to work on communicating more when it comes to having to be absent from a meeting so the team knows what to expect. Another problem we had during the sprint was being willing to ask for help when needed, although we all have little experience when it comes to frontend coding we still can bounce ideas off of each other in order to work through issues faster as it is more useful to the team if we all understand what we are working on and we all agreed when writing our working agreement that we would all be available and willing to help eachother or answer questions as needed. In my opinion we worked well together during our second sprint and I hope we are able to work together even better during our final sprint of the semester.

Issues worked on:

Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – CheckInventoryFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/35

Research code for `button` implementation in Vue and HTML

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/40

Develop `Submit` button Vue and HTML files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/45

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #2

Overall I think the second sprint went well. Like the last sprint, I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. For this sprint, we worked on a lot of the issues as a group. We also were open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. Unfortunately, there were a couple of times when we didn’t keep up with issues that were in the “Needs Review” column. This resulted in a lot of merge conflicts that need to be resolved for those issues. We continued to display aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. For this issue, we examined the file types on the project, made a list of linters that were needed based on the files, added any linters, made sure the new linters passed, checked which stages were needed, and fixed the stages accordingly. I worked on verification for GuestInfoBackend, GuestInfoAPI, and GuestInfoSystem/General. I worked on the first two issues with the group and worked on verifying GuestInfoSystem/General by myself. We also had an issue for talking to group 3 about InventoryFrontend and InventoryBackend because they decided to work on some issues for it. Towards the end of the sprint, I realized they didn’t reach out so our group initiated a conversation to confirm if they were all set. Once that conversation finished I moved that issue to the done column. I also worked on reviewing the issue for getting InventoryBackend test working and getting the InventorySystem General test and build working. The issue for getting the InventoryBackend working was an issue that was left in the  “Needs Review” column for an extended amount of time and needed an extensive amount of work to resolve merge conflicts.

As a team, I think we did fairly well but we needed to keep up with the issues that need review more. We also did not rotate reviewing issues as we originally planned when creating our working agreement and or set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. Because a lot of the issues involved us working together, we didn’t address how we would make sure to stay on track of issues that needed review. As an individual, I need to make sure I can review issues as soon as possible to prevent the possibility of having a team member work through multiple merge conflicts. I think as a group we could benefit from a specific plan for keeping up with completed issues. For the next sprint, I plan on picking a schedule to check on the needs review column.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

CS-448: Sprint 2 Retrospective

Sprint 2

What worked well this sprint

Sprint 1 was a good opportunity for the team to become familiar with each other, how we like to work individually, and the general workflow that we were to follow. After Sprint 1, Sprint 2 was much easier in terms of knowing what the team wanted to accomplish and how to accomplish it. During this sprint, we continued our weekly meetings because it was a good way for everyone to go over what was done the past week, and what needed to be done for the current week. Last sprint, we ended up leaving all of our merge requests open until the end of Sprint 1 which resulted in many conflicts which created extra work to resolve those conflicts. This sprint we decided to review and merge as issues are completed rather than leaving them until the end of the sprint. Reviewing as issues are completed helped the team to avoid merge conflicts.

What did not work well

Throughout the sprint, the team had issues that were dependent on the completion of other issues. An example of these issues were when the team were adding to the AddInventoryFrontend. The goal of the issue was to implement the functionality of actually adding inventory to the database which required multiple components to be added such as text fields, buttons, etc. Because the team as a whole had limited experience with frontend work, we spent time together researching implementation. When spending time together for research, we realized that implementation would be easier with the approach of mob programming. Utilizing mob programming rather than each of us being assigned an issue and completing individually helped save time. This is because if we were all assigned an individual issue then we would have to wait until the first person finishes their issue, then the next person could start their issue, and so on. Each of us would also have to pull the changes the previous person made. This process seemed inefficient, so the team decided to group the issues together and do them at once in one meeting where everyone was present.

Last sprint we also came across problems where there was miscommunication about when we would be meeting, which we aimed to resolve this sprint. However we still faced attendance issues regarding the team’s weekly meetings.

Changes to make as a team

One change that we tried to resolve last sprint was the issue of some team members not attending the weekly meetings. Unfortunately this issue was not fully rectified. In hopes to settle this issue for the next sprint, the team should have a discussion to clearly restate expectations which were initially defined at the beginning of the semester.

Changes to make as an individual

A change that could be made as an individual is having a better grasp of what needs to be done. Mainly due to having spring break in the middle of the sprint, there were a couple instances where I would forget a standup message to inform my team on the progress I have made individually. Although this sprint was longer than the previous, it actually felt shorter to me because of spring break and canceled classes which contributed to me having to rush at the end of the sprint to get my work completed in time. I plan to manage my time better, so this does not happen for Sprint 3.

Activity on GitLab

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

A Guide to Unit Testing

Unit testing is an important method that hammers out bugs in our code and verifies its behavior. Every line of code is critical to keep our projects functioning, so we must understand the benefits and best practices for unit testing to maintain our code correctly. As the title suggests, this blog post, “Unit Testing | What it is, How it Works, Types & Top Benefits”, lays out the principles of unit testing, the different types, and the benefits for software development.

 Diane Wong’s blog is a concise guide to unit testing and its benefits. It covers the types, techniques, advantages/disadvantages, and best practices of unit testing, giving an overview for newcomers to coding and those well-versed in it. I chose this resource due to its simplistic coverage of many essentials to unit testing. The blog is organized with a table of contents that leads those seeking information on a particular aspect of unit testing. It was a good start for my understanding of unit testing, and those new to the method would benefit from the blog.

I found the information concise and direct when reflecting on the blog post. This isn’t a blog that will delve into specifics on any technique or method of testing but will give you a general overview, which is what I wanted. We discussed many aspects of unit testing in class, including testing techniques like Black Box, White Box, Gray Box, Mocking, and Stubs, so some information was a refresher. The main benefit I got from this blog is a better understanding of the advantages unit testing brings, best practices, and why we use it. It lowers overall costs, allows for automation, makes debugging more manageable, and increases the team’s efficiency. The best practices were short but something to remember when conducting unit testing, like focusing on one module at a time or using conventional naming practices. The blog recommended unit testing tools besides JUnit, like Jasmine, TestNG, PHPUnit, and Mocha, which I may look into if they have better features than JUnit. Overall, the blog filled in gaps in my knowledge, and it was something I could quickly go back to or recommend to people new to the concept.

 I intend to use that knowledge for future software development projects and teach those who are unaware so we can effectively build and debug our code. Before using unit testing in practice, developers must understand the fundamentals, best practices, and advantages so they can develop good habits from the beginning. 

Link to the blog: https://testsigma.com/blog/unit-testing/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Week 13

The next classes will be about Software technical review it would be great to get a step ahead by delving into the concept. We only started with the review section of the code but fully understood it before the class could skip the barriers of never implementing this idea. Whenever doing something new there is always a barrier which can be difficult at first but with practical knowledge, it can be implemented with a greater effect.  

This article first talks about why there is a technical review. There are technical reviews for the company’s higher-ups who may not be fully aware of the coding process and the difficulties that come with it. They have to understand the developer’s importance to the business because they are spending a lot of money with ineffective results. Many times deliveries aren’t are time and come in fault states having several bugs. This is where a technical review comes in handy it’s a deep dive that provides a suitable perspective. Their definition of a technical review is a deep dive assessment of your software that provides findings and recommendations that be later adapted or discussed amongst your team. Common finds inside a technical review include slow or late deliveries which are just not meeting the due date, random or persistent bugs an example would be fixing the same thing over and over again, and sleepless nights because of worrying too much. These aren’t the end be it all every technical review is different and should be focussed on your team’s goals. The main discussion should be of pain points the things that keep you up at night to make the software complete. Process and team review is another key ingredient that makes sure everyone is working on the right task or if there are changes that need to be made plus an idea to every team member’s contribution to the project. The last thing the team should do is an effective summary that can be graded with a brief description. Detailed findings and recommendations that can be read by people not in depth with coding so they can get an idea of what is being done behind the scenes and can tell the team what needs to change.

Reading this article gave me an idea as to why we do technical reviews because when doing mine I was stuck trying to figure out problems in the code. I didn’t want to nitpick and find small issues that would seem redundant because at times it is better to keep it clean and simple. But understanding that this needs to be done to prove to people on the other side of the business that work is being done is a great insight. It makes a lot of sense that other people in a company would want to know what is happening on other sides of the department.

Technical Review: A Trusted Look Under the Hood

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 13 Blog

This week’s blog post topic covers Pairwise and Combinatorial Testing. I chose this topic because we will soon cover it in class and having some background information prior to any activities involving this method will be useful to relate back to.

Pairwise Testing, also known as All-Pairs Testing, focuses on efficiency by testing every possible pair of input parameters, rather than every single combination. For instance, if you have a form with fields for name, email, and phone number, Pairwise Testing would cover combinations like name and email, name and phone number, and email and phone number. It’s a straightforward way to catch potential bugs without an overwhelming number of test cases. With Combinatorial Testing, it builds on Pairwise Testing by considering combinations of three or more parameters together. Using our form example, Combinatorial Testing would include triples like name, email, and phone number. This comprehensive approach aims to uncover bugs that might only appear with specific combinations of inputs. This testing method aims to optimize efficiency and coverage. Software testing can be time-consuming, especially with numerous parameters and scenarios. Pairwise and Combinatorial Testing streamline the process, allowing you to detect more bugs in less time.

The key benefits to this method is it helps in reducing the number of test cases needed to achieve “good” coverage. Instead of exhaustive testing, you’re strategically covering the most important combinations. Secondly, it helps in identifying interactions between parameters that might lead to unexpected behavior. By testing these combinations, you’re better prepared for real-world usage scenarios.

Of course, there are disadvantages to Pairwise and Combinatorial Testing. One, It can become tedious due to the large number of test cases required to cover all input combinations. Two, It relies on the interaction of pairs of parameters to determine outcomes, but this assumption may not always hold true, potentially missing bugs. And three, additional tests might be necessary to complement pairwise testing, adding extra time and effort to the testing process.

The main challenge when using this method is selecting the correct input parameters. The choice of relevant parameters impacts software behavior. Careful selection ensures thorough test coverage and defect detection. However, accurately determining parameter interactions is equally as difficult, because it could potentially result in the selection of incorrect combinations.

Some of the tools used by teams are PICT, IBM FoCuS, ACTS, Hexawise, Jenny, etc. These tools help automate the test case design process by generating a compact set of parameter value choices as the desired test cases. This is done by applying the all-pairs testing technique, which involves testing all possible combinations of two parameters.

Blog Post: https://testsigma.com/blog/pairwise-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.