From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.
Libre food pantry
I was happy to work with the librefood pantry from Worcester state university because it gives me better picture on how I can work on Software problems and how to work as a team, At first was little bit confusing but after our first meeting I found it fun to work with but Also I read about the LIbreFoodPantry Main page about what is there mission, values, code of conduct, licensing , Acknowledgments and coordinating committee.
Additionally, exploring Thea’s pantry helped me to see how it was well organized the presentation of the valuable information how the user story can work this shows the step by step for the user interactions for example when the guest (student) visit the pantry information they can see when accessing the website
All in all the libreFoodPantry is a good website that helps or show user friendly interaction, Education and awareness
From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.
The Vital Role of Mentorship in Software Craftsmanship
Summary: The “Find Mentors” pattern emphasizes the importance of seeking guidance and mentorship from experienced individuals in the field of software craftsmanship. It acknowledges the challenges faced by apprentices in navigating their professional journeys and advocates for actively seeking out mentors who can provide valuable insights and guidance. The pattern highlights the rarity of finding a master craftsman but encourages apprentices to engage with a series of mentors, recognizing that mentorship can come in various forms and may not always be face-to-face.
Reaction: This pattern resonates deeply with me as it underscores the significance of mentorship in personal and professional development. It acknowledges the inherent challenges in finding suitable mentors but emphasizes the transformative impact that mentorship can have on one’s journey towards mastery. I appreciate the practical advice offered in the pattern, such as lurking in online communities to identify potential mentors and taking the initiative to reach out to them for informal advice.
Interest: What I find particularly interesting and useful about this pattern is its emphasis on the reciprocal nature of mentorship. While apprentices seek guidance from experienced practitioners, they are also encouraged to pay it forward by mentoring others who are earlier in their journey. This aspect highlights the collaborative and communal nature of the software craftsmanship community, where knowledge sharing and mentorship play vital roles in fostering growth and development.
Reflection: The “Find Mentors” pattern has prompted me to reflect on my own approach to mentorship and how I can leverage it to enhance my professional growth. As I navigate my career in software development, I recognize the importance of seeking out mentors who can provide guidance, feedback, and support. Additionally, I am inspired to contribute to the community by offering mentorship to others who may benefit from my experiences and insights.
Disagreement: While I wholeheartedly agree with the principles outlined in the pattern, I believe that it could provide more nuanced guidance on navigating the complexities of mentorship relationships. For example, it could delve into strategies for building meaningful connections with mentors and managing expectations within the mentorship dynamic. Additionally, the pattern could explore potential challenges or pitfalls that apprentices may encounter in their quest to find suitable mentors.
Conclusion: In conclusion, the “Find Mentors” pattern serves as a valuable reminder of the importance of mentorship in the journey towards software craftsmanship. By actively seeking out mentors and engaging in reciprocal mentorship relationships, apprentices can accelerate their learning, navigate challenges more effectively, and contribute to the growth of the software craftsmanship community. As I continue on my own journey, I am committed to embracing mentorship as a cornerstone of my professional development and to paying it forward by supporting others along the way.
From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.
Chapter 1-6 Reflection
As I dived into the narrative of the young philosopher and the Zen master, I found myself intrigued by the wise words. The metaphor of the overflowing cup resonated deeply, serving as an important reminder of the importance of humility and receptivity in the pursuit of knowledge. It prompted me to reflect on my own approach to learning, highlighting the need to set aside assumptions and take in new perspectives with an open mind.
The comparison of formal training certificates with the quest for genuine expertise struck a chord with me. Like the protagonist, Dave, I’ve often relied on certifications and accolades as markers of proficiency. However, the reading challenged me to reevaluate this mindset, showing the value of continuous learning and self-improvement over static credentials. It prompted me to shift my focus from external validation to internal growth, recognizing that true mastery is an ongoing journey rather than a destination.
There was a lot to agree on with the reading, but there was also some points that I disagreed with. The claim that small ponds and big fish can show the image of satisfaction seemed too simple to me. I believe that individual growth is complex, influenced by a a large amount of internal and external factors beyond the scope of pond size or fish scale. While exposure to diverse perspectives is undoubtedly valuable, it’s essential to recognize the inherent value of all learning environments, regardless of their perceived size or significance.
In terms of relevance, several chapters stood out to me. “Perpetual Learning” resonated with my desire to accelerate growth and deepen my understanding. The notion of embracing discomfort and seeking out new challenges spoke directly to my aspirations for professional development. Additionally, “Reflect as You Work” and “Create Feedback Loops” struck a chord with me, highlighting the importance of self-assessment and continuous improvement in my journey toward mastery.
In conclusion, the reading served as a step for introspection and growth by making me to reevaluate my approach to software apprenticeship. By embracing humility, fostering curiosity, and prioritizing continuous learning, I aim to navigate the complexities of the field with purpose and strength.
From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.
The Lifelong Journey: “Perpetual Learning” Week-2
Embracing Constant Evolution:
The “Perpetual Learning” pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye is a clarion call to software developers to embrace continuous learning. In an industry characterized by rapid technological advancements, this pattern stresses the importance of continuously updating and expanding one’s knowledge base. It’s about embedding a learning mindset into the fabric of your daily professional life, ensuring that growth and development are ongoing processes.
A Resonating Principle:
This pattern deeply resonates with me. It underscores a truth I’ve observed in my brief tenure as a developer: the only constant in technology is change. Adopting a mindset of perpetual learning isn’t just beneficial; it’s essential for survival and advancement in this field. It turns the career of a software developer into a journey of endless exploration and discovery.
Provoking Continuous Growth:
What’s particularly thought-provoking about this pattern is the idea of integrating learning into every aspect of work. It’s not limited to formal training or courses but encompasses learning from every project, every challenge, and every mistake. This approach transforms everyday tasks into opportunities for improvement and skill enhancement.
Shaping Professional Outlook:
“Perpetual Learning” has reaffirmed and shaped my approach to my software development career. It has instilled in me a sense of dynamism and adaptability. Embracing continuous learning means I’m always equipped to tackle new challenges and stay ahead in the ever-evolving tech landscape. This pattern has transformed my perception of learning from a phase to a fundamental career characteristic.
Agreeing Yet Balancing:
I wholeheartedly agree with the essence of this pattern. However, the challenge lies in balancing continuous learning with other professional responsibilities and personal life. It’s crucial to find sustainable and efficient ways to integrate learning into a busy schedule. Overcommitment to learning can lead to burnout, so it’s important to strike a balance.
In summary, the “Perpetual Learning” pattern is a vital mantra for anyone in the fast-paced world of software development. It’s a reminder that our professional development journey doesn’t have a final destination; it’s an ongoing path of growth, adaptation, and continuous improvement. By embedding a learning mindset into my daily practice, I am not just preparing for the challenges of today but equipping myself for the unknowns of tomorrow.
From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.
Black Box vs White Box Testing
In the ever changing and dynamic field that is Software development, understanding the nuances of different testing methodologies is crucial for ensuring quality and reliability. I would like to say that I stumbled upon the blog “Black vs White vs Grey Box Testing” on Shakebugs.com however, the truth is I was still a little confused after our last class and needed further clarification not only on the difference of the two testing methods but just what they do and when they are used. And well this article did just that it resonated with what we were learning and sparked several insights that I believe will impact future practices.
The article navigates through the concept of black, white and grey box testing (I did not even know grey was a thing.) Black box testing, as it explains, is an approach where the tester assesses the functionality without knowledge of the internal workings of the application. White box testing, on the other hand, requires a deep understanding of the code, as tester need to verify the internal processes and pathways. Grey box emerges as a hybrid approach, combining elements of both black and white box testing. It allows testers to apply their partial knowledge of the internal structures while examining the software’s external functionality.
As I mentioned before I chose this resource because it matched the topics we were discussing in class and further helped develop my understanding of the practical applications of the different testing methodologies. The clear and concise explanations paired with practical examples and visuals, provide a framework to differentiate and appreciate the unique attributes and applications
Reading this article was more delightful than I initially anticipated as when I saw a 13 minute read time I almost closed the tab however, I am glad I did not. I learned that while black box testing is excellent for validating user requirements and functionalities, white box testing is indispensable for internal code optimization and security assessments. Grey box testing , with its balanced approach, offers a valuable perspective for comprehensive testing.
Going forward, I intend to integrate these insights into my approach to software testing. In future projects, I will not only consider the functional requirements but also the internal code structure and security aspects when deciding on a testing strategy.
The blog post is a must-read for anyone in the field of software development testing. It offers clear and practical understanding of the different methods, guiding how to apply them effectively. You can read the full article here . This resource not only enhanced my understanding but has also equipped me with practical knowledge I am eager to apply in the future.
From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.
Apprenticeship Patterns Blog
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is a book covering a comprehensive overview of software testing meant to prepare the reader with the knowledge and skills necessary for working as a quality assurance tester.
In the beginning of the book, Hoover and Oshineye answer the important questions of “what” is software testing and “why” it is necessary in software development.
At the highest and most general level, software testing is a way by which a software’s quality is evaluated, estimated, and shared with stakeholders, providing an independent view of the software product. Furthermore, it is the goal of software testers to ensure that this quality meets and maintains the requirements. I found it interesting that the book mentioned the primary function of software testing to be for the stakeholders; however, it makes sense as software testing not only is needed to ensure that the program runs, but also that it runs smoothly for the user, and most definitely for its stakeholders. The best way to assure stakeholders of the product’s success is through software testing.
Chapter two of the book gives further reasoning for software testing stating that the U.S. government lost 60 billion dollars due to software defects in 2002, equating to 0.6% of the country’s gross domestic product. In a world that is so heavily dependent on technology, it becomes evident how important it is to ensure that this backbone of society remains reliably working.
So with the question of “what” and “why” out of the way, the book shifts gears into the essence of software testing. The fundamentals of software testing is split into three parts: testing basics, requirements, and test plans.
The most basic form of testing is checking expected output with the observed output based on a controlled input allowing for a clear comparison and analysis of the program’s behavior. Most patterns of software quality assurance are based on this fundamental strategy.
Before testing software, it is necessary to know what it is that needs to be tested. This is given by the software requirements. These specify exactly what it is a specific piece of software should do under certain conditions ensuring that developers know what to build and that testers know what to test. Requirements are laid out in a test plan, a collection of test cases ensuring that every requirement of a software is met.
Software testing is complex field with many moving parts. However, it all boils down to ensuring that the program works as intended, meeting all the requirements and expectations shared by stakeholders and users, which saves time and money for companies that use it effectively. It is a field of software development that I am very interested in and am excited to learn about more.
From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.
‘Your First Language’ Pattern
The ‘Your First Language’ pattern from chapter two consists of the idea that you are just starting out and only have a basic understanding of one or maybe even two languages. The problem which is presented is that you as an apprentice believe that your job depends on being able to produce the same quality of work in a specific language that the others around you can even if they may have more experience using said language or that getting any job will depend on your knowledge of one particular language. Then the solution presented it to decide on a ‘first language’ which you will dedicate to familiarize yourself with and when trying to solve a problem you will use this language and further your understanding of its inner workings. Then if an employer requires you to use a specific language you approach it by taking small steps at first and then exponentially grow your steps as you gain more knowledge in order to efficiently learn another language. This pattern encourages you to seek help from experienced friends in order to quickly progress through a problem as long as you do not grow a reliance on them for all the answers.
I have a great appreciation for this pattern as I feel it is something that many students and or apprentices may struggle with. Initial thoughts on a first language can be intimidating and heavily influenced by the schooling you go through if any or even others opinions online if you do not pursue technical training initially. You put a lot of consideration into a choice like this and it is important but this pattern highlights the thought that many people may have that they must fully master a language in order to be ‘employable’ in that said language when realistically even people that are considered to be ‘masters’ of a specific language are still learning. What really matters is that you take the steps in your first language and learn from the experience so that you can adjust the steps to learn other languages in the future as your first language is basically your jumpstart in the world of programming languages.
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.
Week 3 Blog
This week I chose a blog post that covers the difference between black box and white box testing. In general, testing a program is a vital pillar in producing reliable software to customers. Testing helps uncover and mitigate defects in programs. Blackbox testing refers to the testing technique where the tester has zero knowledge of how the internal source code works. This technique involves the tester executing the code and analyzing the behavior and functionality. The reason why this practice is referred to as “black box testing” is because you can’t see in the box, similar to the tester not having access to the code. The benefit of black box testing is anyone can be a tester. Since the tester does not need knowledge of the internal code, there is not limit to who can be a tester. Non-programmers can execute the code and verify the results. A major disadvantage of this testing is the inability to pin point what caused the error. Since the tester has zero access to the internals, the only thing they know is the program doesn’t function as intended.
White box testing, also referred to as clear box testing, is a testing method that involves having access to the internal workings of the code while testing it. This testing method requires the tester to have prior knowledge about programming to analyze the source code. White box testing focuses on the internal logic, code structure, and execution paths. This method of testing allows testers to pin point where the program failed, unlike black box. White box testing excels in scenarios where the accuracy and function of the program is crucial, because developers can easily debug. The main disadvantage to white box testing is it can be time consuming, since testers have to first understand the code’s intended function and analyze each line.
This information is very useful to know when we cover and simulate each type of testing method in class. It’s crucial to know the disadvantages and advantages to a testing technique before deciding the most suitable one. For example, if you’re testing the user experience of a website, white box testing wouldn’t be the best option because the user isn’t going to access your websites source code. Black box testing would be the most effective technique because it focuses on the functionality of the website. Both of these testing techniques help developers and organizations deliver software that is reliable, meets user expectations, and complies with industry standards and regulations.
Blog Post: https://www.bairesdev.com/blog/black-box-vs-white-box-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.
Structural Testing
https://unstop.com/blog/structural-testing
Structural testing is one of many types of software testing, although structural testing is directly testing the internal structure of the code which means it is important that the individual performing structural tests is very familiar with the language used for the code. This type of testing uses white box testing techniques and it is more concerned with how a system is running rather than its functionality which is the more common reason for testing. There are four different types of structural testing which are mutation, data flow, control flow and slice-based testing. Mutation testing is a type of structural testing which relies on changing small parts of the code’s structure in order to test for errors, there are different types of mutation testing which are based on changing different parts of the code’s structure in order to find possible errors. Data flow testing is used to analyze how data flows through a program and control flow is used to show the order in which statements will be executed. Slice-based testing takes a portion of statements which may affect the final value of a variable and uses those slices to test the change. There are three different techniques used while doing structural testing which are called statement, branch and path coverage. Some common open source tools for structural testing include Cucumber, JBehave, Cfix and JUnit.
I found this article interesting as it not only gives an in-depth explanation on structural testing but it also provides you with both techniques and tools which can be used to perform such testing. The advantages and disadvantages section particularly piqued my interest as one of the first advantages listed is that early defects can be easily identified which I would infer is due to the direct testing of the code structure versus testing its sole functionality. The cost of this type of testing however is a huge disadvantage as the time and money it takes to go through all of the testing necessary is much more than other types of testing. This article did teach me a lot about structural testing as most of the testing I have personally done has been testing what inputs get a certain output and testing direct implementation of a body of code versus actually testing the structure and being able to see how a piece of data flows through code which is a very important aspect of testing even if this testing is very expensive.
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.