Always Improving Software

In this post, I’ll be discussing my thoughts primarily on Chapter 1 of Apprenticeship Patterns, a book I had to read parts of for another class. I really like the idea of being a “Software Apprentice,” as I think it is a good representation of the attitude I have adopted over the years. I’ve always viewed myself as someone who is constantly learning and evolving in this field, and the apprenticeship model seems to align perfectly with that. It’s not about arriving at some endpoint but about growing, making mistakes, and improving.

What stood out to me the most was the idea of viewing the development process as a journey, not a destination. Chapter 1 introduces the concept of “Software Craftsmanship” as more than just technical skill, but also as a mindset of continuous learning. This was particularly thought-provoking because I think there’s a tendency, especially early in our careers, to think of coding as a task to be completed or a skill to be mastered and then moved beyond while in pursuit of some computer science career. However, the idea that becoming a Software Craftsman is an ongoing process—a commitment to constant improvement and a mindset that thrives on learning—is something that I think is a better description. It shifted my perspective on what it means to be good at coding- it’s not enough to know how to do something today, it’s about always finding a way to improve your code in the future.

In the past, specifically in my career, I’ve often gotten caught up in the day-to-day rush of just getting whatever piece of code done. I’ve rushed to get things coded, with the focus being on completing projects rather than developing deeper expertise or refining my approach to coding. After reading this chapter, I think I’m more likely to focus on the long-term value of writing quality code and the importance of standards. It’s not just about writing code that works; it’s about writing code that lasts, is readable, and contributes to a more sustainable project. I’m going to start to approach my coding tasks with a deeper goal, rather than rushing through them for the sake of completion.

I think this is particularly applicable to Software Quality Assurance and Testing because QA is, in essence, a form of ensuring that our code is always improving. Not only do we need to find a balance between constantly improving before release and actually releasing, but even after releases, we still need to be looking for future requirements and improvements. There is no end in sight for software testing, ever. I think this constant forward motion, driven by constantly increasing requirements, is inseparable from the idea of being a software apprentice.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Always Improving Software

In this post, I’ll be discussing my thoughts primarily on Chapter 1 of Apprenticeship Patterns, a book I had to read parts of for another class. I really like the idea of being a “Software Apprentice,” as I think it is a good representation of the attitude I have adopted over the years. I’ve always viewed myself as someone who is constantly learning and evolving in this field, and the apprenticeship model seems to align perfectly with that. It’s not about arriving at some endpoint but about growing, making mistakes, and improving.

What stood out to me the most was the idea of viewing the development process as a journey, not a destination. Chapter 1 introduces the concept of “Software Craftsmanship” as more than just technical skill, but also as a mindset of continuous learning. This was particularly thought-provoking because I think there’s a tendency, especially early in our careers, to think of coding as a task to be completed or a skill to be mastered and then moved beyond while in pursuit of some computer science career. However, the idea that becoming a Software Craftsman is an ongoing process—a commitment to constant improvement and a mindset that thrives on learning—is something that I think is a better description. It shifted my perspective on what it means to be good at coding- it’s not enough to know how to do something today, it’s about always finding a way to improve your code in the future.

In the past, specifically in my career, I’ve often gotten caught up in the day-to-day rush of just getting whatever piece of code done. I’ve rushed to get things coded, with the focus being on completing projects rather than developing deeper expertise or refining my approach to coding. After reading this chapter, I think I’m more likely to focus on the long-term value of writing quality code and the importance of standards. It’s not just about writing code that works; it’s about writing code that lasts, is readable, and contributes to a more sustainable project. I’m going to start to approach my coding tasks with a deeper goal, rather than rushing through them for the sake of completion.

I think this is particularly applicable to Software Quality Assurance and Testing because QA is, in essence, a form of ensuring that our code is always improving. Not only do we need to find a balance between constantly improving before release and actually releasing, but even after releases, we still need to be looking for future requirements and improvements. There is no end in sight for software testing, ever. I think this constant forward motion, driven by constantly increasing requirements, is inseparable from the idea of being a software apprentice.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Software Testing Thinking Hats

The blog post I’ve chosen talks about the different mind sets that you should use when tackling different situations. When writing tests, it helps to write tests with different goals so that you don’t forget to test every aspect of some section of code. The blog author talks about how trying to do the tests out of order or without any order in mind you can forget things and cause it to take more time in the long run. The author categorizes these as “hats” to wear during each progressive stage. There is the ambitious hat which is for when you are testing the code in the way the customer will be using the code. There is then an uncomfortable hat which is for when your tests are failing, and you need to fix what you can in your testing. The confident hat is the one you can wear while you are refactoring your code and running just to confirm everything passes. The author also makes specific mention to not try and wear multiple hats at once.
From my experience in the classes I’ve taken so far, I’ve done some built in testing in files for whole programs that I myself have written, and so I know exactly what the code should do, what I need to have pass in order to meet the homework criteria. In these cases, because I am both the author of the code and the author of the test cases, I am able to make edits in both parts with the knowledge of exactly what the test cases should be. This has helped in my current class so far but as we move forward, we will be approaching testing like it is done in the workplace and when the people testing the code are a separate group that has not touched the program code. I’ve definitely seen myself as the coder that the author describes who frantically moves around the code and tests trying whatever I can to get everything to work instead of approaching it with any methodology. I want to become both better and more efficient at testing code as it will help me write code also and further my understanding of what makes a complete program. Testing is a big part of working in the computer science field and I know that quality assurance is very important, so I look forward to both learning more about this within the course and doing more blogs about the industry.

Chris James – The TDD Thinking Hats

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

Software Apprenticeship Patterns

Although my capstone course CS-448 focuses on mimicking a live agile setup to understand how software engineers work, there is still a focus on understanding how to become industry professionals outside of hands-on experience. Part of this extraneous understanding is reading the book on Software Apprenticeship Patters, most notably the first chapter on understanding the stages of craftsmanship.

I was hooked immediately into this chapter, as what I found my knowledge lacked in the most; was that I had very little understanding of some soft-skills Software Engineers should have. What was first apparent to me was that I am firmly in the apprentice stage of craftsmanship. I am focused on trying to become better at not only completing my tasks assigned and problems to solve, but understanding how to do them faster. Being an apprentice means to share this focus, and often I find myself forgetting (along with many others) that we will continue to learn after our graduation.

The understanding I’ve gained on patterns to work with my apprenticeship has driven me to change my mind on how to approach work in computer science. I have always had a drive to learn, but learning even as I work will be important for my growth. The reading has helped me to understand I should want to experiment and be proven wrong especially, rather than getting something wrong being treated as a failure.

I disagree with the software pattern about walking the long road. While I greatly enjoy coding and computer science, the idea of consistently dedicating myself to learning every day seems daunting. I value competence and pride in my skillset, and of course learning is required for that; however I worry that such dedication removes my ability to balance other hobbies along with my work.

Overall what seems most relevant to me is the first chapter. It is the most robust of those I read, and it contains the most information to introduce software apprenticeship. It covers what apprenticeship is, as well as the levels of software craftsmanship. With understanding these, it also introduces the idea of Software Apprenticeship Patterns, which is the focal point of the book.

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Finding A Way

Comparing software development to an apprenticeship like blacksmithing makes a lot of sense. The analogy can work for other professions but I think it works especially well with software development. The reason being that software development compared to other fields offers a lot of freedom and different ways of doing things. In other fields, you often only have a few ways of doing things. For programming there are often many ways to solve problems. Not every solution is good, but it can be used. I think it is a lot black smithing in that way. Many techniques are capable of getting the job done. You can go your whole life without knowing about them, but still be component enough to do good work. In the beginning, you are capable of doing very little or bare bones work. But as you increase your knowledge and experience you become more capable of doing much more. And maybe most importantly create work that can last in the most efficient way. Smithing a sword and building good software are not so different.

One of the most profound patterns to me was the “Exposing Your Ignorance”. Accepting that you are not perfect and there is no way to know everything. Especially, as a beginner it feels like a need to master so many things in such a small time. I feel like I never know enough. I often feel like “how can I get a job like this, I know so little”. Everyone seems to know more than me so it can get discouraging. But I like what this pattern is trying to instill. Accept that you are a beginner and that you will need help. This also goes into the finding mentors pattern. Having someone who can guide or help out of a tight spot. 

I think I like all the patterns about finding your own way. Like the long road pattern. Accepting that maybe you learn in a different way or approach something in a way that best suits you. No one person floors the same path. The software field is so diverse with some many different areas of specialization. There’s no one path that suits the goals you have in mind. Overall the biggest lesson I took away was not criticizing myself for not being a master. Accept that proficiency comes with time and no road is without bumps.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Microservice Architecture

In today’s fast-paced digital natural world, software systems are required to be scalable, adaptable, and powerful. Microservice architecture is one architectural approach that has gained significant popularity in answering these objectives. Recently, I discovered a helpful document named “Microservices Architecture” on Microsoft’s Azure Architecture Center website, which offered a full description of this technique.

The article describes microservices architecture as a design pattern in which applications are developed as a collection of small, independent, and loosely linked services. Each service is liable for an independent function and may be built, launched, and expanded separately. This differs from monolithic systems, which have all components tightly integrated into a single codebase. The article highlights the advantages of microservices, such as increased scalability, shorter development cycles, and the option to utilize various technologies for different services. It also addresses difficulties like increased complexity in managing inter-service communication, data consistency, and deployment pipelines.

The reason I chose this article is because Microsoft Azure is a cloud computing platform that I am familiar with and am learning more about how it is within microservice architecture. The article’s clear explanations and practical insights make it an excellent pick for learning about microservices in a real-world setting.

Reading the article was an eye-opening experience. I was particularly struck by the emphasis on independence and modularity in microservices. The thought of each service being created and deployed individually appealed to me since it enables teams to work on different areas of an application without stepping on each other’s toes. This method not only accelerates development but also makes it easier to discover and resolve problems.

However, this article also made me aware of the issues that come with microservices. For example, maintaining communication across services necessitates careful design, while guaranteeing data consistency between services can be challenging. This helped me realize the value of solutions like API gateways and message brokers, which assist to speed these operations.

One of the most important lessons that I learned is that microservices aren’t a one-size-fits-all solution. The article highlights that this architecture is best suited for big, complicated applications that demand a high level of scalability and flexibility. For smaller projects, a monolithic approach may be more suitable. This sophisticated viewpoint helped me comprehend that the correct architecture is determined by the project’s individual requirements.

In the future, I plan to apply microservices architectural ideas to my own projects. I’m particularly looking forward to exploring containerization technologies like Docker and orchestration platforms like Kubernetes, both of which are commonly used in microservices setups. I’ll also remember how important it is to build clear APIs and implement effective monitoring mechanisms to handle the complexity of distributed systems.

https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

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

Effective Exception Testing in JUnit 5: Boundary Value Testing and AssertThrows

Introduction

In modern software development, ensuring that a program handles exceptions correctly is crucial for building robust applications. Exception testing in JUnit 5 allows developers to verify that their code properly handles error scenarios, improving reliability and maintainability. This blog post explores key techniques such as Testing for Exceptions in JUnit 5, Boundary Value Testing, and using AssertThrows to create effective test cases.

Testing for Exceptions in JUnit 5

JUnit 5 provides a streamlined way to test exceptions in Java applications. Unlike JUnit 4, which required using the expected attribute or @Rule, JUnit 5 introduces Assertions.assertThrows(), offering a more flexible and readable approach.

Example of Exception Testing in JUnit 5

Consider a method that calculates the square root of a number. If a negative number is provided, it should throw an IllegalArgumentException.

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class MathUtilsTest {

    double calculateSquareRoot(double number) {
        if (number < 0) {
            throw new IllegalArgumentException("Number must be non-negative");
        }
        return Math.sqrt(number);
    }

    @Test
    void testCalculateSquareRootException() {
        IllegalArgumentException exception = assertThrows(IllegalArgumentException.class, () -> {
            calculateSquareRoot(-5);
        });
        assertEquals("Number must be non-negative", exception.getMessage());
    }
}

This test verifies that the method correctly throws an exception when given invalid input, ensuring robustness.

Boundary Value Testing

Boundary Value Testing (BVT) is a technique used to test the limits of input values. It focuses on edge cases, such as minimum and maximum values, where software is most likely to fail.

Example: Boundary Testing for Age Validation

Consider a function that validates a user’s age for registration, allowing only ages between 18 and 65.

boolean isValidAge(int age) {
    return age >= 18 && age <= 65;
}

Boundary tests should check values just inside and just outside the valid range:

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class AgeValidatorTest {
    
    @Test
    void testAgeBoundaries() {
        assertTrue(isValidAge(18)); 
        assertTrue(isValidAge(65));  
        assertFalse(isValidAge(17)); 
        assertFalse(isValidAge(66)); 
    }
}

BVT ensures the system correctly distinguishes between valid and invalid inputs.

Testing for Exceptions with AssertThrows

The assertThrows method in JUnit 5 simplifies exception testing, making tests more readable and maintainable. It helps validate that methods correctly handle invalid inputs by throwing the expected exceptions.

Example: Division by Zero Handling

Consider a simple method that performs division:

int divide(int dividend, int divisor) {
    if (divisor == 0) {
        throw new ArithmeticException("Cannot divide by zero");
    }
    return dividend / divisor;
}

We can use assertThrows to verify proper exception handling:

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class DivisionTest {

    @Test
    void testDivideByZero() {
        ArithmeticException exception = assertThrows(ArithmeticException.class, () -> {
            divide(10, 0);
        });
        assertEquals("Cannot divide by zero", exception.getMessage());
    }
}

This ensures that the division method correctly throws an exception when dividing by zero.

Conclusion

Testing exceptions effectively is a vital part of software quality assurance. JUnit 5’s assertThrows method, combined with Boundary Value Testing, enables developers to create thorough test cases that improve the reliability and robustness of applications. By writing well-structured exception tests, developers can prevent unexpected failures and ensure their applications behave as expected under various conditions.

For further reading, check out:

#JUnit5 #ExceptionTesting #AssertThrows #BoundaryValueTesting

From the blog Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

On Being a Software Apprentice

 In this post, I’ll be discussing my thoughts primarily on Chapter 1 of Apprenticeship Patterns. I really like the idea of being a “Software Apprentice,” as I think it is a good representation of the attitude I have adopted over the years. I’ve always viewed myself as someone who is constantly learning and evolving in this field, and the apprenticeship model seems to align perfectly with that. It’s not about arriving at some endpoint but about growing, making mistakes, and improving.

What stood out to me the most was the idea of viewing the development process as a journey, not a destination. Chapter 1 introduces the concept of “Software Craftsmanship” as more than just technical skill, but also as a mindset of continuous learning. This was particularly thought-provoking because I think there’s a tendency, especially early in our careers, to think of coding as a task to be completed or a skill to be mastered and then moved beyond while in pursuit of some computer science career. However, the idea that becoming a Software Craftsman is an ongoing process—a commitment to constant improvement and a mindset that thrives on learning—is something that I think is a better description. It shifted my perspective on what it means to be good at coding- it’s not enough to know how to do something today, it’s about always finding a way to improve your code in the future.

In the past, specifically in my career, I’ve often gotten caught up in the day-to-day rush of just getting whatever piece of code done. I’ve rushed to get things coded, with the focus being on completing projects rather than developing deeper expertise or refining my approach to coding. After reading this chapter, I think I’m more likely to focus on the long-term value of writing quality code and the importance of standards. It’s not just about writing code that works; it’s about writing code that lasts, is readable, and contributes to a more sustainable project. I’m going to start to approach my coding tasks with a deeper goal, rather than rushing through them for the sake of completion.

As for the chapters that seem most relevant to me, I’d say Chapter 2 and Chapter 3 are particularly interesting. Chapter 2 addresses the Apprentice phase, which is where I find myself right now. It talks about how to build your foundational skills, seek out learning opportunities, and adopt the mindset of a lifelong learner – things I’m actively working on. Chapter 3, which discusses the Journeyman phase, is also relevant to me because it’s about expanding your skill set and finding ways to deepen your experience. I’m interested in how this phase encourages finding ways to take on more responsibility and become a more well-rounded developer, which is exactly where I want to focus next in my development journey.

From the blog Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

On Being a Software Apprentice

 In this post, I’ll be discussing my thoughts primarily on Chapter 1 of Apprenticeship Patterns. I really like the idea of being a “Software Apprentice,” as I think it is a good representation of the attitude I have adopted over the years. I’ve always viewed myself as someone who is constantly learning and evolving in this field, and the apprenticeship model seems to align perfectly with that. It’s not about arriving at some endpoint but about growing, making mistakes, and improving.

What stood out to me the most was the idea of viewing the development process as a journey, not a destination. Chapter 1 introduces the concept of “Software Craftsmanship” as more than just technical skill, but also as a mindset of continuous learning. This was particularly thought-provoking because I think there’s a tendency, especially early in our careers, to think of coding as a task to be completed or a skill to be mastered and then moved beyond while in pursuit of some computer science career. However, the idea that becoming a Software Craftsman is an ongoing process—a commitment to constant improvement and a mindset that thrives on learning—is something that I think is a better description. It shifted my perspective on what it means to be good at coding- it’s not enough to know how to do something today, it’s about always finding a way to improve your code in the future.

In the past, specifically in my career, I’ve often gotten caught up in the day-to-day rush of just getting whatever piece of code done. I’ve rushed to get things coded, with the focus being on completing projects rather than developing deeper expertise or refining my approach to coding. After reading this chapter, I think I’m more likely to focus on the long-term value of writing quality code and the importance of standards. It’s not just about writing code that works; it’s about writing code that lasts, is readable, and contributes to a more sustainable project. I’m going to start to approach my coding tasks with a deeper goal, rather than rushing through them for the sake of completion.

As for the chapters that seem most relevant to me, I’d say Chapter 2 and Chapter 3 are particularly interesting. Chapter 2 addresses the Apprentice phase, which is where I find myself right now. It talks about how to build your foundational skills, seek out learning opportunities, and adopt the mindset of a lifelong learner – things I’m actively working on. Chapter 3, which discusses the Journeyman phase, is also relevant to me because it’s about expanding your skill set and finding ways to deepen your experience. I’m interested in how this phase encourages finding ways to take on more responsibility and become a more well-rounded developer, which is exactly where I want to focus next in my development journey.

From the blog Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

On Being a Software Apprentice

 In this post, I’ll be discussing my thoughts primarily on Chapter 1 of Apprenticeship Patterns. I really like the idea of being a “Software Apprentice,” as I think it is a good representation of the attitude I have adopted over the years. I’ve always viewed myself as someone who is constantly learning and evolving in this field, and the apprenticeship model seems to align perfectly with that. It’s not about arriving at some endpoint but about growing, making mistakes, and improving.

What stood out to me the most was the idea of viewing the development process as a journey, not a destination. Chapter 1 introduces the concept of “Software Craftsmanship” as more than just technical skill, but also as a mindset of continuous learning. This was particularly thought-provoking because I think there’s a tendency, especially early in our careers, to think of coding as a task to be completed or a skill to be mastered and then moved beyond while in pursuit of some computer science career. However, the idea that becoming a Software Craftsman is an ongoing process—a commitment to constant improvement and a mindset that thrives on learning—is something that I think is a better description. It shifted my perspective on what it means to be good at coding- it’s not enough to know how to do something today, it’s about always finding a way to improve your code in the future.

In the past, specifically in my career, I’ve often gotten caught up in the day-to-day rush of just getting whatever piece of code done. I’ve rushed to get things coded, with the focus being on completing projects rather than developing deeper expertise or refining my approach to coding. After reading this chapter, I think I’m more likely to focus on the long-term value of writing quality code and the importance of standards. It’s not just about writing code that works; it’s about writing code that lasts, is readable, and contributes to a more sustainable project. I’m going to start to approach my coding tasks with a deeper goal, rather than rushing through them for the sake of completion.

As for the chapters that seem most relevant to me, I’d say Chapter 2 and Chapter 3 are particularly interesting. Chapter 2 addresses the Apprentice phase, which is where I find myself right now. It talks about how to build your foundational skills, seek out learning opportunities, and adopt the mindset of a lifelong learner – things I’m actively working on. Chapter 3, which discusses the Journeyman phase, is also relevant to me because it’s about expanding your skill set and finding ways to deepen your experience. I’m interested in how this phase encourages finding ways to take on more responsibility and become a more well-rounded developer, which is exactly where I want to focus next in my development journey.

From the blog Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.