Category Archives: Blog

Sprint 2

During this sprint, I switched up the work I did compared to the last sprint instead of working on the backend I was given the task to oversee the front end. First going into the front end blindly I didn’t know exactly how far the front end was already and had to accommodate myself to the code. First opening the frontend I noticed it was missing several files that would hold great importance in starting the frontend. One of my first fixes was the docker-compose file left by the other group was the backend file the same so I created a new file that would hold both servers of the front end and the backend. I updated some of the documentation that had been outdated compared to what we were working on currently. I created a new way to start the frontend server because it was missing that and added an up.sh, down.sh, and rebuild.sh for the front end. I also updated the outdated docker file. After I had a basis for what was needed I decided to go in and organize it better to read the new files in an organized manner to see what files were missing. Had to add new assets and components including new pictures of Libre food pantry and any other ones that were needed. 

During this sprint, I worked well working alone but I should have checked more often with my teammates because of the issue that would later fall upon me. I was making progress every week but I hadn’t yet seen the biggest fault was the backend would crash on me. Next time I should check in with my teammates sooner instead of making progress on my own. I just didn’t want to slow down my teammates with my work. That is a fault in itself I shouldn’t be scared for help because the team will fail if I do this. 

This time around the apprenticeship pattern that resonated with me the most was breakable toys because it is the basis of each sprint. You must create a small project where you can make mistakes in order to learn and be better. During this spring I was learning the ins and outs of the front end on something someone else created that I had to update and fix. This pattern could have made me more confident in messing up because it’s now wrong to mess up. Failing would help with issues that would come up that would show me what to do in other scenarios. Another pattern I would choose is to learn how you fail. I had many times during this sprint where I was head scratching to find an answer or come to an understanding of something but picking up on the patterns of how I failed I could change for the next issue that would come up. This issue opens my mind to being more intentional with my work and picking up on my common mistakes even if sometimes simple mistakes are the biggest headaches. Errors can be preventable by understanding why you do something and adapting to catch them next time. During this sprint, I learned a great deal about my project and I hope in the next sprint I will be able to learn more.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Gitlab activity:

The most important thing that worked well during this sprint, as addressed in all of the Team Project Effectiveness Reports, was communication. Our team communicates really well in person, and online after class. We use discord as our primary source of communication and everyone is really prompt in responding, whether it be in regard to simple questions or chronic issues that one of the systems is causing a team member. The use of the issue board in Gitlab improved during Sprint 2, which allowed the team to keep better track of what was happening, and more importantly, getting completed during the sprint. This allowed us to easily showcase our work during the Sprint Review because we were able to just look back at the issue board. 

The primary thing that didn’t work well this sprint was a clear idea of the work that should actually be getting done. Plenty of work was completed, but it was done on a basis that should have been pre-defined. Doing work as we find issues or come up with ideas is not the most efficient way to make beneficial changes to the “InventorySystem – Weight Based” and we need to work on this. 

Establishing stricter goals for the sprints will allow us to complete more meaningful work. This is the biggest change I think that needs to be made as a team. Personally, I think my best traits are ensuring that everyone’s voices are heard, and I’ve gotten positive feedback in this regard, and that my teammates are always informed of the work I’m doing. The team has decided that I should remain scrum master, and to fulfill my role, I will encourage us to define the stricter work goals that I previously mentioned.

Relevant Apprenticeship Pattern:

The pattern I have chosen to describe Sprint 2 is “Rubbing Elbows.” This pattern states that the act of collaboration can be referred to as “rubbing elbows” and if you reach a plateau in your individual abilities, collaborating with others may help you continue making progress. It is obvious that collaboration is taking place as this is a group project, but sometimes it is apparent that team members, myself included, struggle with our own work. I chose this pattern because I noticed the prevalence of it today actually. I was working on updating the design elements of AddInventoryFrontend and couldn’t figure out why my changes weren’t being made in the browser. I would’ve pondered over this issue for more minutes than I’d like to admit, but I “rubbed elbows” with Guilherme and was able to notice that merely a single line of code needed to be changed. Being more aware of this pattern during Sprint 2 probably would have encouraged more pair-programming, the use of the TV, or rubbing of elbows to navigate issues. The work doesn’t have to entirely be done alone. Overall, if stricter goals are defined for work that needs to be done, and we emphasize a greater sense of collaboration in class, Sprint 3 will hopefully reap the most benefits in terms of code contributions compared to Sprints 1 and 2.

Source of pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html?_gl=1*1gf7b0t*_ga*MTQzNTk4ODQ5OC4xNzQ0NzQxNTgz*_ga_092EL089CH*MTc0NDc0MTU4Mi4xLjEuMTc0NDc0MTcyNC40MS4wLjA.#rubbing_elbows

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Code Reviews

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

A code review is code that is peer-reviewed, which helps developers validate the code’s quality before it is merged and shipped to production. Code reviews are done to identify bugs, increase the overall quality of the code, and to ensure that the developers of the product understand the source code. Code reviews allow for a “second opinion” on the functionality of code before it is actually implemented in the systems. This prevents non-functional code from being implemented in the product and potentially causing issues or bottlenecks in performance. Ensuring that code is always being reviewed before merging encourages the developers to think more critically of their own code, and allows reviewers to gain more domain knowledge regarding the systems of the product. Code reviews prevent unstable code from being used by customers, which would lead to poor credibility and overall act as a detriment on the business. The benefits of code reviews are as follows: knowledge is shared among developers, bugs are discovered earlier, establishment of a shared development style/environment, enhanced security, increased collaboration, and most importantly, improved code quality. As with everything, there still are disadvantages. Code reviews lead to longer shipping times, pull focus/manpower from other aspects of the process,and large code reviewers equal longer review times. But the benefits far outweigh these disadvantages.

Code reviews can be implemented in multiple ways, through pair programming, over-the-shoulder reviews, tool-assisted reviews, or even email pass-around. Gitlab offers an interesting feature where developers can require approval from reviewers before their code can be merged. I chose this article because I use this feature frequently in my capstone class. My teammates and I review each other’s changes in the codebase through this Gitlab feature and, if needed, go over these changes in class whether it be through pair programming or over-the-shoulder reviews.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Behavioral Testing

Source: https://keploy.io/blog/community/understanding-different-types-of-behavioral-unit-tests

Behavioral unit tests validate how code units operate under certain conditions, allowing developers to ensure that the software/application is working as it should be. Behavioral unit tests focus on specific pieces of code. They help developers find bugs early and work based on real scenarios. They lead to improved code quality because this unit testing ensures that the software is up to the expectations of the user, and allows for easier refactoring. The key types of behavioral unit tests include happy path tests, negative tests, boundary tests, error handling tests, state transition tests, performance driven tests, and integration-friendly tests. The one that caught my attention was the performance-driven test. These tests validate performance under specified constraints, such as handling 10,000 queries. The test is run to ensure that performance remains acceptable under various loads. This test caught my attention because in my cloud computing class, I was loading files with millions of data entries, and the performance suffered, which highlights the importance of unit testing under conditions such as these.

The difference between functional and behavioral unit tests is that functional tests validate the system’s function overall, whereas behavioral tests focus on specific pieces of code to make sure that they behave as expected under various conditions. Behavioral unit tests should be run every time code is built to make sure changes in the code don’t cause problems. Tools that can be used for this kind of testing include JUnit/Mockito for Java, pytest for Python, and Jest for JavaScript. I chose this article because we use JUnit/Mockito in class and thought it’d be wise to expand my knowledge on other unit tests. It’s good to get reassurance that unit testing is important from all of the sources I’ve been learning from, because it is very apparent that many different scenarios can cause many different problems in regard to the production of code/software/applications.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Data Flow Testing

Source: https://www.testbytes.net/blog/data-flow-testing/

Data Flow Testing, viewed as a nuanced approach in software testing, is the process of examining data variables and their values through the use of the control flow graph. Data Flow Testing is an example of white box and structural testing. By targeting gaps that become prevalent within path and branch testing, data flow testing aims to locate bugs from the misuse of data variables/values. 

Data flow testing is used on both static and dynamic levels. In static levels, data flow testing involves the analysis of source code without actually running the application. The control flow graph in this instance represents execution paths of the code from the application. Errors that can be found on the static level include, definition-use anomalies (a variable is defined but is never used), redundant definitions (variable is defined multiple times before it’s used), and uninitialized use (a variable is used before a value has been assigned). 

On the dynamic level, the application is executed, and the flow of data values/variables is analyzed. Issues that can be found on this level include, data corruption (value of a variable is modified in an unexpected way, leading to undesirable behaviors), memory leaks (unnecessary memory allocations, memory consumption becomes uncontrolled), and invalid data manipulation (data is manipulation in an unpredicted way, causing many outputs).

The steps of data flow testing include identifying the variables, constructing a control flow graph, analyzing the flow of data, identifying anomalies in the data, dynamic testing, designing test cases and executing them, resolving anomalies, and documentation. I decided to read about data flow testing because I thought it’d be valuable to learn about how this type of testing allows for early bug detection and overall improved code quality and maintainability. The obvious downsides however are that not every possible anomaly can be caught, the process can be time consuming, and other testing techniques should also be used.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Static vs Dynamic Testing

Source:
https://www.browserstack.com/guide/static-testing-vs-dynamic-testing#:~:text=Static%20testing%20focuses%20on%20reviewing,to%20find%20bugs%20during%20runtime.&text=It%20is%20performed%20at%20the%20later%20stage%20of%20the%20software%20development.

This article is titled “Static vs Dynamic Testing” and explains the differences between them and how they allow for the development of quality software. Static testing is testing where the application isn’t being actively used. Code is manually read through to search for errors. As a result, a computer is not necessarily required for this form of testing as design documents containing the code can be reviewed. This kind of testing is done before the code is executed and early in the development process. The benefits to static testing are that defects are able to be found earlier in the process, it’s usually more cost-effective than other testing techniques, leads to more maintainable code, and encourages collaboration between team members. However some disadvantages of static testing are that not all of the issues could be found until the program/application actually runs, it depends on the experience of the reviewers for it to be effective, and it usually has to be done alongside dynamic testing to uncover other potential issues.

Dynamic testing involves giving an application input and analyzing the output. Code is being compiled in a run-time environment. This form of testing also relies on the expertise of the reviewers as deep knowledge of the system is required to understand how and why a system reacts based on the input. The advantages of dynamic testing are that runtime errors, memory leaks, and other issues that only come to fruition during code execution are revealed, helps verify that the software is working as intended by the developers, and ensures that all parts of the system work together appropriately. However some disadvantages of dynamic testing are that it can be time-consuming, may not cover all possible scenarios, and may be difficult to test uncommon instances in the program. 

Overall it is important to realize that static and dynamic testing are both important in their own ways and emphasize the importance of performing various kinds of testing methods to ensure an application works as intended. I chose this article because we discussed these topics in class and figured learning more about them would be beneficial. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Gitlab activity:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/37

This was my first task I worked on during sprint 1. I updated AddInventoryPage.vue to match the design elements of Main.vue from CheckOutGuestFrontend to foster consistency in design layout.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/38

This merge request involved the refactoring of a few files so AddInventoryFrontend was able to load on port 5173 in the browser and connect to InventoryBackend, I submitted this merge request as an update on my work before the sprint 1 review, as complete implementation wasn’t done yet, the adjusted total weight of the inventory wasn’t working in this request.

These next two merge requests fix the issue of the previous one (adjusted total weight of the inventory is now being returned):
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/59
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/39
There was an issue in InventoryBackend’s updateInventory.js file where the value was being returned incorrectly, so this was fixed and allowed the adjusted total weight of the inventory to be displayed in backend calls and in AddInventoryFrontend.

What worked really well in this sprint was the communication between all of the teammates. I acted as scrum master and there was no push back for getting work done. Everyone was able to work on their tasks independently and utilize teammates for help during class sessions. Discord was a big help in terms of ensuring we were keeping track of each other’s progress outside of class and was a good place to pose questions or ask for help. What didn’t work that well was the way in which we established goals for the sprint. This is our first one so it was to be expected, but going forward with sprints 2 and 3 we are aiming to establish more focused issues to work on. The goals of sprint 1 were too broad and made it feel as though not much progress was made even though we worked diligently.

Overall, as time goes on we continue to work better as a team. As a result, I don’t have many suggestions for improvement. However, establishing more focused goals as previously mentioned would improve our workflow, maintaining positive and consistent communication is obviously valued, and increasing how often we show each other what we’re working on are all things that can be considered. The biggest fault of our team is that sometimes teammates won’t really know what others are working on, even though they are contributing to the project. It’s important going forward to help visualize how everyone is contributing by ensuring there are consistent check-ins. Personally, since I’m still acting as scrum master, I should try to promote these check-ins myself instead of relying on teammates to initiate this. Having conversations going forward about who should be the scrum master, for how long, etc., is also something that I could mention. 

From Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, the most prevalent pattern for this sprint may be “Expose Your Ignorance,” just today we were shown the value of this pattern. One of our team members was able to solve two separate issues that were preventing merge requests from being made. The basic idea of exposing your ignorance is that you’re showing those around you that you don’t necessarily know everything, you’re open to receiving help, and you want to learn throughout this process. Instead of feeling the need to appear competent, you are fostering a learning environment for everybody. I selected this pattern to mention because if we as a team were consistently exposing our ignorance, we could have potentially accomplished a lot more. Yes, individual work is important, but the hours spent on your own trying to fix an issue to no avail is not always worth appearing competent to your peers. If this pattern was read during the sprint, more questions could have been asked and answered, and more contributions to the project could have been made. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Beginning the reading of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, I can say that I was expecting this book to be a lot more technical. However, the entirety of this reading was very thought-provoking. The idea of apprenticeship has always been interesting to me, and applying those principles in the modern era workforce of software development makes complete sense. Striving to continuously learn, receive guidance from your seniors, and actively indulge yourself in new technologies, will allow someone just starting their career to surely become the biggest fish in their pond, and ultimately cycle through the process of starting as the smallest fish and yet again becoming the biggest. This metaphor from the reading offers a vivid illustration of the importance of not becoming too complacent with your work and learning. Being the biggest fish in a small pond will not grant you any opportunity or growth, you have to surround yourself with individuals who are able to teach you something. Many people, including myself, have been led to believe that you should accept the highest paying job and quickly pursue roles in management. In reality the most meaningful aspect of the job is what you can learn from it, prioritizing this will pay off far greater than the short-term satisfaction of the high-paying job. The reading shifted my perspective from this cash grab mindset to a “knowledge grab” mindset. In regards to workflow on the job, the reading showcases the importance of utilizing your team to achieve a greater sense of productivity and insight into how methodologies and systems really work. Software development is a field of collaboration where everyone should be contributing to the pursuit of knowledge. There’s nothing in the reading that can really be disagreed with unless you are not truly meant for, or passionate, about the field of software development. The idea of creating your own curriculum might frustrate some people as it alludes to bringing your work home with you, however, in an ever-changing field such as this, self study is completely necessary. This is probably the most important chapter because it points to the idea that if you do not possess the inner motivation to study new material on your own terms, you may not be cut out for the job.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

CS-443 Intro Post

Hello, this is my first post for my Software Quality Assur & Test Course (CS-443). I’ll be making posts related to this course in the upcoming weeks.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

LFP Blog Post

One thing I found interesting from the LibreFoodPantry was found in the “Values” section and it was the link to FOSSisms. A FOSSism is a maxim for free and open source culture, and these are used to explain the benefits of open source values in computer science education. The article lists 16 of these. The most important FOSSism is the first one listed. It references “it’s all about community” and this is most definitely the entire point of open source software. Incorporating students with open source projects involves a lot more than simply working on a software project, it requires getting involved in a community of like-minded individuals who are all contributing to the project. These projects are mostly contributing to a greater social good. I chose to write about this because community is a huge part of the workforce and emphasizing this in open source projects is really important for effective collaboration.

One thing I found interesting from the Thea’s Pantry was the “Architecture” section. If we as students in this capstone class/project are going to be contributing to this software, it is definitely important to understand its architecture and all of its individual components. It was interesting to read that the client solution is composed of systems such as:

  • GuestInfoSystem
  • InventorySystem
  • ReportingSystem
  • IAMSystem (Third-party)
  • EventSystem (Third-party),

and that each of these systems has a multitude of features. The integration and deployment diagrams were a good piece of visualization to help understand the scope of the project. I chose to write about this because I recognized the importance of understanding the architecture of a project that one is working on.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.