Author Archives: Shawn Budzinski

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.

Code Review

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

This article is titled “What is a code review?” As clearly stated by the title, the article explains the processes of code reviewing. “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Code reviews help in the identification of bugs, increase the overall quality of code, and enhance understanding of the source code. Code review, as suggested in the name, happens after a software developer has finished coding. Code needs to be checked before it is merged into an upstream branch for bugs or conflicts. A code reviewer “can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, two experts should review the code.” Adhering to a solid code review process allows for continuous improvement of code and aims to ensure that faulty code isn’t being implemented for customers/users to see and use. This process isn’t just important for the code itself, but also for all of the team members of a software development project. Whilst reviewing the code, meaningful knowledge of the source code is shared between team members to ensure that it is being implemented properly. The main benefits of the code review process are: the sharing of knowledge, discovering bugs earlier, maintaining compliance, enhancing security, increasing collaboration, and improving code quality. Code reviews allow for maintaining compliance because different developers have different backgrounds and thus different personal processes when they are developing. Code reviews allow these people to get together and maintain a standard coding style. Security is enhanced because “security team members can review code for vulnerabilities and alert developers to the threat. Code reviews are a great complement to automated scans and tests that detect security vulnerabilities.” There are many benefits to code review, but there are some disadvantages, including: longer time to ship, focuses being pulled from other tasks, and large reviews mean longer review times. These can be described as necessary evils due to the sheer amount of positives that code reviews offer in software development.

I chose this article because it was published by GitLab, a software that we are heavily using in class for version control, and I thought that it would be interesting to read this specific topic from the syllabus. Version control softwares such as GitLab allow code reviews to happen, so diving deeper into the topic in an article published by this popular software company was tempting. Before reading this article I understood that code reviews were important to pinpoint any bugs or difficulties before merging code into the upstream, but I never really thought about the implications of security or different development styles. I’ll definitely keep this information in mind during future code reviews on the job to remind myself that bugs aren’t the only important thing during a code review.

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.

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

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.

Software Maintenance

Source: https://www.geeksforgeeks.org/software-engineering-software-maintenance/

This article is titled “Software Maintenance – Software Engineering.” Software maintenance “refers to the process of modifying and updating a software system after it has been delivered to the customer.” There are many different aspects involved in this including: fixing bugs, adding new features, and keeping up with new hardware and software requirements. Maintenance is very important for ensuring that software is able to last long. This process can be expensive and complex, so these factors must be taken into account during the planning of a software development project. The important tasks in regard to software maintenance are: bug fixing, enhancements, performance optimization, porting and migration, re-engineering, and documentation. Summarizing these tasks, it is important to find and fix errors quickly, add new features/improve existing ones, improve the performance of the software, adapt the software to run on different hardware, improve the design, and maintain accurate documentation of all of these processes. There are quite a few different types of software maintenance, but they can be categorized into proactive and reactive types. “Proactive maintenance involves taking preventive measures to avoid problems from occurring, while reactive maintenance involves addressing problems that have already occurred.” Maintenance can be done by stakeholders, the development team, a third-party, and they can be both planned or unplanned. Planned maintenance can be described as regular maintenance (bug fixes) while unplanned maintenance can be described as reactive maintenance that occurs when something unexpected happens. Maintenance can fall into these different categories: corrective maintenance, adaptive maintenance,  perfective maintenance, and preventive maintenance. Corrective refers to fixing bugs and enhancing performance of the system. Adaptive refers to modifications being made when a customer needs the software to run on a different system. Perfective refers to the adaption of the software when a customer has a demand. Lastly, preventive maintenance refers to modifications that focus on the prevention of future issues with the software. Software maintenance is important but there are some things to consider: the cost, complexity, possibility of new bugs, users not updating the software, compatibility, technical debt, and end-of-life (where maintenance isn’t possible anymore or cost-effective).

I chose this article because I found it in the syllabus and thought the topic to be interesting. We are always learning about the development of software, but the idea of maintaining it over the long term isn’t as heavily considered. A large part of the work of a software development team is to obviously develop software but it is also important to learn about how it can maintain a sense of longevity free from error and customer complaints. I will keep the information I learned from this article in mind in future projects and when I’m working with a team to ensure that I’m developing software all the while keeping maintenance in mind. If it is considered during the development process, the maintenance process will be much easier.

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.

Introduction to Pattern Designing

Source: https://www.geeksforgeeks.org/introduction-to-pattern-designing/

This article is titled “Introduction to Pattern Designing.” In regards to software development, “pattern designing refers to the application of design patterns, which are reusable and proven solutions to common problems encountered during the design and implementation of software systems.” These reusable design patterns showcase relationships that occur between classes or objects. They are language dependent, so they can be described as an idea that makes code flexible and overall speeds up the process of development. Their purpose is to solve common problems. There are three main kinds of design patterns, creational, structural, and behavioral. “Creational design patterns abstract the instantiation process.” Creational design patterns offer a sense of flexibility in regards to “what gets created, who creates it, how it gets created, and, when.” Knowledge about which concrete class is being used is encapsulated and the way instances of classes are created is hidden. “Structural design patterns are concerned with how classes and objects are composed to form larger structures.” Inheritance is used to create interfaces/implementations. Structural design patterns are good for when you want to make independent class libraries collaborate effectively with one another and offer flexibility regarding object composition. “Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects.” Patterns of communication are being described here. Inheritance is used to divide behaviors between classes, object composition is used for behavioral object patterns, and the object patterns encapsulate behaviors in objects. Overall, the benefits of pattern designing are reusable solutions, scalability, and abstraction/communication. The downfall of it however is that there is a learning curve while you try to understand the patterns, there may be concerns with when you should apply the patterns in your code, and if patterns aren’t implemented consistently and in correlation with the advancement of the system, maintenance issues may occur. But regardless, they are a great way to solve common problems during the development process.

I chose this topic because the idea of design patterns was in the syllabus and it interested me. We learned about design patterns such as Factory, Strategy, and Singleton, but reading about the larger terms of creational, structural, and behavioral patterns offered deep insight into the topic. The supposed benefits of common methodologies in software development are always presented but it is also good to know about the downfalls, which I am glad this article showed about the design patterns. When I am working on a team or in the workforce, I will definitely reference these design patterns to improve the maintenance capability and scalability of my code, and do so in a way which I am able to avoid the downfalls of implementing them incorrectly. 

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.

Version Control

Source: https://www.spiceworks.com/tech/devops/articles/what-is-version-control/

This article is titled “What Is Version Control? Meaning, Tools, and Advantages.” The main purpose of version control is to “track the progress of code across development and iterations and also aids in managing changes during the life cycle.” Records are kept of all changes with names, timestamps, and other important information. So, the process by which software code is monitored and the way in which changes are made is called version control. A huge benefit of version control is being able to look at the revision history and determine where problems originated from, and who caused them to happen. This allows for increased efficiency regarding workflow considering that the time required to locate problems is greatly reduced. Another benefit of version control is branching. “Branching is a distinct approach to version control where development programs are duplicated for parallel versions of development while keeping the original and working on the branch or making separate modifications to each.” This allows for enhanced collaboration where development is increased, issues are resolved, and code remains organized. A couple very popular version control tools are Git and GitHub. The creator of Linux, Linus Torvalds, created Git. The memory footprint of Git isn’t vast and is able to follow changes in any files. It is a very simple version control system and as a result is used by top companies such as Google. GitHub is a service that enables development teams to collaborate and keep track of all their code changes in a cloud environment. GitHub is secure and reliable, and as a result is also widely used. Through the use of a version control system the following can be achieved: “streamline merging and branching, examination/experimentation with code, the ability to operate offline, creation of regular/automated backups, communication through open channels.” Overall version control aids in the maintenance of reliable code bases and enforces accountability for effective collaborative development. 

I selected this article because we are actively learning about version control in class right now so I figured it’d be the perfect time to read up on it more. Reading the GitKit chapters has exposed me to different git commands and GitHub usage. It was interesting to read in this article about all of the in-depth benefits that version control offers and clearly showcases why even top companies such as Google use it to optimize their workflow. In future practice, whether it be at a job or while working on an individual project, I will use version control to improve collaboration and the ease of maintenance of my code.

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.