Monthly Archives: February 2021

Apprenticeship Patterns Introduction (Ch1, Ch2-6 review)

For my Computer Science Software Development Capstone course, we are reviewing the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. Before discussing different patterns themselves, I would like to review and discuss the introduction chapter and the smaller introductions to the first six chapters of the text. The entire beginning of the book attempts to explain and introduce us to what exactly we will be learning throughout the semester. It goes over what apprenticeship patterns are and where they came from. It tells us what exactly software craftsmanship is and what apprenticeship is. Lastly, it tries to answer the question “what next?” after learning these things. To start, the book makes it clear that there is no simple definition for software craftsmanship (at least how it is using it), and it tries defining it as a “community of practice united and defined by overlapping values.” To see those values, I would read page four and five in the text. Next, the book defines what it means to be an apprentice. It states for the most part that it is the state of looking for more efficient ways or better solutions including looking for better resources to help because anything being done could be being done faster or better. It defines apprenticeship as the state of learning the craft (in this case, software development). In the conclusion of chapter one, the book discusses where apprenticeship patterns even come from and what we should be doing with them. It claims they come from “many working systems that have used the same solution to solve similar problems.” Basically, after learning all of these patterns, I should be able to take what I have researched and mix and match the patterns where I see fit in real life as if I am the apprentice right now and the book is my tool for learning my craft. Before I conclude this blog entry, I would like to briefly discuss the introductions to the five chapters after this first one (especially since I will be reviewing patterns from them over the course of the rest of this semester). Chapters two through six will cover patterns ranging from self-assessing, resilience training, working patterns, working with others, perpetual learning, and constructing my curriculum, etc. I am extremely excited to get into my assessments of these different patterns and learning about my craft. I actually have researched a couple of the subjects covered in these chapters and it is incredibly valuable information for my future as a software developer. I look forward to reviewing at least eight (if not more) of the different patterns and sharing my experience learning them with anyone who will be reading these blog posts now or in the future!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Blog Post #1 (JUnit 5 Testing)

For my first reflective blog entry on my Software Quality Assurance and Testing class, I decided to further research Java JUnit 5 testing. JUnit 5 testing was the topic of my first assignment in this course, and a lot of the assignment involved researching. I wanted to do even more research now that I finished my assignment and record it as this blog post. One of the biggest takeaways from the assignment was learning the differences between JUnit 5 and JUnit 4 to see why we use JUnit 5 now. I decided to find a good source on the differences and discuss them here. The best source that I found was from HowToDoInJava.com, and this website was actually one that I referred to for help on my assignment earlier. The source describes eight major differences. The first change from JUnit 4 to JUnit 5 is the change in annotations. Many syntax changes occur when switching to JUnit 5 (not every one changes). Next, it discusses the architecture which changes from one single jar file to three separate sub-projects (Platform, Jupiter, and Vintage). The SDK version requirements change from one to another as well as assertions and assumptions slightly differ as well. Test Suites and tagging both change as well. Lastly, JUnit 5 finally allows for third party integration while JUnit 4 never did. Most of these changes are not game-changing or extremely different from each other, but all combined manage to prove that JUnit 5 is a step forward from JUnit 4. I am happy that we went over this topic as an assignment in my course because I did not even know that JUnit had separate versions like this until now! If I were you, I would definitely give my source for this blog post a read. It was very interesting, and it did a great job explaining the differences I was trying to uncover! I will put a link to it at the conclusion of this post.

https://howtodoinjava.com/junit5/junit-5-vs-junit-4/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Testing With JUnit 5

Photo by Markus Spiske on Pexels.com

Recently I was introduced to JUnit 5 as a testing framework for Java programs, mainly for the purposes of one of the courses I am taking currently. While I have in the past used methods such as print statements (to test for expected outputs and debug) or using the built-in IDE debugging functions (breakpoints mainly), this was often time-consuming and not easy to scale. When trying to test for a number of different conditions or desired results from a section of the program, I would often end up writing conditional logic just for testing purposes which would end up getting deleted later on in the finished program.

JUnit seems like a relatively logical progression from this process, instead of writing numerous checks and conditional statements into the working code of the program, test classes can be used to rapidly test many different conditions or input/outputs at once. This allows for me to keep the main code of the program neater and to avoid the time consuming process of having to continually write tests or print out values in order to test that everything is functioning properly. JUnit overall is a more efficient way to go about the process.

In the past, I had used an older version of JUnit (JUnit 4) to test an older project from a number of years ago. I found this blog post from Java Magazine (https://blogs.oracle.com/javamagazine/migrating-from-junit-4-to-junit-5-important-differences-and-benefits) was able to highlight many of the major changes and differences between JUnit versions 4 and 5 clearly. Generally, JUnit 5 differs the most in it’s organization into various modules, while older versions of the framework would include all features irregardless of which ones might actually be needed at the time.

Additionally, more recent Java features such as lambda functions (absolutely useful within the context of running tests) make this version of JUnit more powerful than earlier editions.

I would consider JUnit 5 to be one of the better options at present for testing and debugging Java programs and will likely continue to utilize this framework until it inevitably sees a version 6 release.

Article Referenced: https://blogs.oracle.com/javamagazine/migrating-from-junit-4-to-junit-5-important-differences-and-benefits

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

Blog Post #1: JUnit 4 vs JUnit 5

For my first post, I got the idea to look more into the differences between JUnit 4 and 5 after the video and questions from the first Advanced Assignment for CS-443.

JUnit 4 was first released in 2006, and was the prior main framework for Java developers. 4 built upon assertions and annotations for methods and testing, and was used for over a decade. However, a big change was needed because of growing issues with JUnit 4 with modularity and extensions. This big change came in the form of JUnit 5.

JUnit 5 was then released in 2017, and JUnit 5 is meant to improve on JUnit 4, so it has multiple advantages over the latter framework, such as:

  • Divided into three bundles: Platform, Jupiter, and Vintage, instead of being a single jar file.
  • With JUnit 5, you can import what is necessary, while JUnit 4 imports the whole library.
  • Multiple test runners can run at a time on JUnit 5, while JUnit 4 only allows one at a time.
  • Additional annotations, such as annotations for nested loops and custom extensions
  • Lambda expressions
  • JUnit 5 uses Java 8 and higher, while JUnit 4 stops at Java 7.

JUnit 5 is the main framework that is used today for Java, and continues to get updated to this day. JUnit 4 was efficient for many years, but JUnit 5 is the better framework by improving on 4s flaws and continuing to improve as time goes on.

https://howtodoinjava.com/junit5/junit-5-vs-junit-4/

https://blogs.oracle.com/javamagazine/migrating-from-junit-4-to-junit-5-important-differences-and-benefits

https://www.baeldung.com/junit-5-migration

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #2

The second apprenticeship pattern from the textbook that I would like to discuss is the one described as “Unleashing your Enthusiasm.” For the most part, the book is trying to say that some students learning software development are not up to speed with knowing all they need to know yet but have great enthusiasm towards the subject. This often times holds them back in succeeding and learning primarily because of others with countering attributes. Many people have more knowledge of software development but much less enthusiasm toward it, and these people sometimes will hinder the success of the less knowledgable enthusiastic learners. The book primarily describes examples of this hindering with the different members of groups having less enthusiasm and not appreciating the ideas of the others. Groups in software development tend to think normally and about finishing their sprints and nothing else. The extra enthusiasm and ideas from the member of the team is often seen as just an annoyance to the other members when they are in a rush to finish their work. The book describes ways of getting around this by talking to people you trust about your ideas and edging them to give their feedback. Suppressing your enthusiasm and ideas is the worst thing you can do because you could have small amounts of knowledge and lose your enthusiasm entirely. Do not let your possibly great ideas go never proposed. It is your job to energize your team and not let them fall into the lapse of simply doing the work to do it.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Software QA Log #1: Understanding Quality Assurance

Even though we don’t consciously think about this fact, many products that we use in our daily lives are made with particular specifications and go through rigorous testing and quality assurance before they are put out for public use. Regardless of the complexity, every product that we use is expected to go through particular standardized procedures that will ensure that the product can fulfill certain specifications before it is put out for any kind of use. Essentially, everything created that is meant for use goes through the process of Quality Assurance (QA) and Quality Control (QC) in order to ensure that quality specifications are met and that the end result of a product is satisfactory.

Components of computer systems, specifically software (as it is the focus of this blog), are among those products that go through the process of QA and QC testing before they are released to the end consumers in order to ensure that quality specifications are met and that the products released are the best that they can possibly be in regards to performance, security, and whatnot. Essentially, QA and QC testing in regards to software are what separate a good product of code from a defective code of lesser quality. Though both QA and QC testing are important parts of software development, it is important to properly define each terms and to make a distinction between the two. Though I will be using this blog to discuss Software Quality Assurance Testing specifically, I believe it would be helpful to understand the distinctions between Quality Assurance and Quality Control.

In software engineering, quality assurance is a set of standardized procedures whose aim is to ensure that certain specifications of quality are being met during development, therefore making this process a core part of software development. On the contrary, quality control is a process of software engineering which evaluates the quality of the end product, meaning that this process occurs after development and before a product is distributed rather than alongside it. While both processes make sure that quality standards of software are met, their difference lies on which part of development they typically occur in. Moreover, in the context of software development, QA ensures that certain defects, such as bugs, are properly taken care of during development, whereas QC might address less technical issues that could still impact the quality of the end product if left unaddressed and ensure that improvements to the end product are made accordingly.

There are multiple methods of QA Testing which may be divided into two types, functional and non-functional. Functional QA testing ensures that the software works as intended depending on the inputs or overall interactions an end user has with it. On the other hand, non-functional QA testing aims to conduct tests regarding (but not limited to):

  1. Vulnerability/Security: such testing ensures that there are no security risks that would result in the system the software was installed on to be compromised by any means (i.e. hacking, data leaks)
  2. Compatibility: such test ensures that the software is fully compatible with and can be implemented on the system it was created to run on.
  3. Usability: such test ensures that the software is intuitive and can be used by end users with minimal difficulty (i.e. user-friendly GUI)
  4. Performance: such test ensures that the software can work in a variety of situations on the system it is implemented on, along with making sure that it can operate within the system’s limitations

In order to make sure that software performs well on a functional level, it often goes through rigorous unit and integration testing, both of which are used to ensure that software can perform by examining how parts of code (i.e. functions) work both independently and in union. Though these kinds of functional testing may often be slow and repetitive, they can often help uncover bugs and glitches that may occur when software executes and can help resolving any defects much easier.

Quality assurance is (or should be for some) an integral part of software development. It is not simply enough to write code that can be compiled and executed without error. It is important, however, to ensure that the software that is being developed meets certain quality standards both on a functional and a non-functional aspect in order to create a competent piece of software.

Articles I read that discuss this post’s topic in greater depth:
1) https://www.tiempodev.com/blog/what-is-qa-in-software-testing/
2)https://mycrowd.com/blog/what-qa-testing-methodologies-are-there/
3)https://www.thebalancesmb.com/definition-of-quality-assurance-2533665

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

Context

The following post will be in reference to Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye chapter 1 and the introductions to chapters 2 to 6.

Opinion

“Most people won’t have an opportunity to work in a formal apprenticeship where they are being mentored by software craftsmen. In reality, most people have to claw and scratch their apprenticeships out of less-than-ideal situations. They might be facing overbearing and/or incompetent managers, de-motivated coworkers, impossible deadlines, and work environments that treat novice developers like workhorses, storing them in small, rectangular stalls with a PC and a crippled Internet connection. (Apprenticeship Patterns)”

This is an incredibly true statement. Due to the current state of the economy, it is very hard for people to gain work experience in any field, let alone in software development. One will frequently see requirements for years of experience in an entry level position, but how can one achieve years of experience if every entry level job requires it? In my opinion, this is the product of many things; moreover, it is an incredibly complex issue, as all issues are. One such thing is the abundance of college degrees. As with many of these possible causes, they are often both positive and negative. Every good action has negative consequences and every negative action has positive consequences.

The positive that comes with the abundance of college degrees is likely self-evident – average people are educated and have more opportunities. However, consider the issue of student loan debt. Many people put themselves into massive debt to get a degree they might not even use. Anyway, it is basic economics at play; you cannot fight supply and demand. The hiring process is simple. Now, the world we live in isn’t perfect but suppose it were an actual meritocracy where everyone has equal opportunities. How can we hire? If we assume that someone who has spent years in college dedicated to studying a topic we work with, we can discriminate based on degree in order to discriminate on skill set. It is important to note that discrimination is not inherently bad. In a meritocracy, discrimination is necessary; in fact, in any value hierarchy where object A has more value than object B, discrimination is necessary. The problem with discrimination is when we discriminate based on irrelevant characteristics. For instance, race has no influence on a person’s ability to be a good doctor. So it is unfair to discriminate based on race when deciding a doctor. However, suppose you need brain surgery and you have the choice of a doctor with twenty years of experience, or a new hire without any experience. In that case, in order for society to function at all, it must be considered fair to discriminate based on experience since that directly affects the chance of success and, in this case, survival. Thus, jobs fairly discriminate based on perceived ability and understanding to find the best for the job. However, the more people that have a degree, the less worth a degree has relative to employment. Having a degree is less of a discriminating factor and so jobs have to create other means of determining skill – hence the absurd amount of experience required.

It is a catch-22; employers use college degrees to discriminate to determine those best fit for their position so average people push their kids to go to college. Then, college degrees become worth less but people still think they are necessary so despite the immense cost, they push their kids to go anyway. Obviously, college is not bad. However, their is a failure to have the necessary discussion with kids. They have to decide whether the career they want is going to be worth the investment. They also need to consider that they might not even find a job in their field after college. It would help the issue if parents and schools viewed college as more of a tool rather than a necessity, and if they introduced kids to trades. Trades also aren’t for everyone, but they are a very founded career path. What society needs overall is a balance and a discussion. In my estimation, the entire education system needs an overhaul; but that is for another blog post.

I would go into the other things I think are causes of such a job environment, but I’ll save that for another day. Instead, I’ll focus on the immense power of environment. First and foremost, people like to view their environment as separate from their minds. However, just think about it. As an example, when you’re lazy, you create clutter in your environment and when your environment is cluttered, it can cause stress or discomfort. Your environment affects your mood and your mood affects your environment, so the distinction between the two isn’t as clear as people might like to think it is. A good working environment is crucial to doing good work. Think back to primary or secondary school and think about the old books and uncomfortable desks with pencil carvings in them. It might go without saying but, if you want to improve your work, put some effort into ensuring your work environment is designed for you to be productive.

Work Cited

“Apprenticeship Patterns.” Accessed February 22, 2021. https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

The book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye gives great solutions/patterns for problems often faced by software developers, mainly apprentices or beginners of the craft. I have enjoyed reading up to where I have gotten so far (Chapter 1 plus 2-6 introductions) and it has taught as well as clarified many ideas and methods. One thing I have never thought of is how your first language will affect how you will think and learn other languages in the future. While this may be the case, the more diverse knowledge you have, the more you will improve upon this fact. For example (given by the book), people who are more comfortable with object-oriented languages should explore functional languages. This will broaden your understanding and problem solving. Another pattern I found interesting was the Be The Worst pattern. This discusses your environment and its relation to your growth. Being on a team where you are the best or most skilled does not give you much room or motivation to improve as you will not be learning from your peers. It suggests keeping yourself in an environment/team where you are the least skilled. This forces you to catch up to your teammates so that you don’t hold them back as well as forces the habits, ideas, and information of your higher skilled teammates upon you. A few patterns that addressed things I already “knew” but clarified the process at which I should take are Expand Your Bandwidth and Reading List. If you want to be a software developer then you should already know that you will be constantly learning. Expand Your Bandwidth gives solutions on how to learn more than what your job teaches you. It gives examples such as joining online academic courses, following influential developers on social media, contacting authors and more. This gives you a starting point from which you can come up with your own ways of learning or just to boost you in the right direction. The other pattern, Reading List, gives great methods on organizing your book backlog. The first suggestion is to not only keep a list of books you wish to read but the ones that you have read as well. This allows you to keep track of the books you’ve read from which you can review and find gaps or trends in your learning. This can direct you/help decide what you should read next. The pattern also suggests that you keep your book list as a priority queue. If you find a book on a topic that would be more useful or has a higher urgency then put it at the top of the list. If the bottom of the list gets to the point where you will probably never read the books in those spots then thats okay because it clearly is not a priority. I like the way this book structures these patterns too. The authors organize these patterns into Context, Problem, Solution and Action. This makes it easier to understand rather than if they were just put into normal paragraphs.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Introduction

            In reading the introduction to the Apprenticeship Patterns book, I found a great deal of the material to be interesting. Looking at the learning curve of a software developer in the style of the apprenticeship to journeyman to master stages provided a much better framework for progression than I had seen before and putting it in these simple and recognizable terms makes a career feel more tangible. Beyond this, I was quite interested in a couple of the chapter introductions. Chapter 4 focuses on “Accurate Self-Assessment,” specifically the concept of complacency of being a big fish in a small pond. I do a fair amount of reading online about careers in software development, mainly focused on entry-level positions, competitive internships, etc. It stands out to me that many people in the field push and push to start at the highest level that they can, which makes sense in such a competitive environment. Whether this means working at a FAANG company or maximizing total compensation as fast as possible, the focus tends to shift away from becoming the best the one can be and instead on landing in what is generally perceived as the best environment/position. While I can’t say this is at all unreasonable as people have themselves to worry about and not just their software development skills (I know I definitely have this focus too), it can come to the expense of their long-term career. By this I mean we find a place where we want to be in the present and allow this to perpetuate for however long, not to the detriment of our skills as a developer necessarily, but not really broadening our skills either. The book elaborates on this, saying, “You must fight this tendency toward mediocrity by seeking out and learning about other teams, organizations, journeymen, and master craftsmen that work at a level of proficiency that an apprentice cannot even imagine.” This means that getting comfortable is easy, and for most, it’s preferable to be within one’s comfort zone. Getting outside of our comfort zone is so valuable though. I think it’s inevitable to play the game of comparisons with one’s immediate peers, even at our level of being students. It’s saying, “Well, I could go on and learn x, y, and z, but I’m doing better than most of the class at the current topic, so I don’t really need to.” It’s a trap I’ve definitely fallen into. But our class, our little sector of the computer science world is just that: a tiny little sector. It’s more valuable to focus on what we don’t know than what we do know at any level of skill. I love this concept, intimidating as it is, and it provides great motivation.

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Software Craftsmanship raises some of the thorniest and most sensitive questions about software development and comes to the controversial conclusion of finding answers in a system that has thrived for hundreds of years: technology. Software Technology is a systematic expression of the author’s ideas and attempts to answer the difficult questions that have been plaguing the software industry. How should we restructure the process of building software, such as we want it to be effective?

 

The author of Software Craftsmanship has been emphasizing the role of the craftsman in the project. Craftsmen sounds is a very old word, the craftsman in other industries is a what kind of person I want to say, must be done in the field of a good man, I explain the below mentioned software process artisans do what kind of person, craftsman is mentioned there is a very rich in the process of software development experience, after years of development, products are well received by customers, has a certain reputation, they can submit a robust, high quality of the user application. A good craftsman can make or break a project. This shows that the human factor plays a very important role in the development of the project. Someone I have been thinking without learning software engineering in software development has a very important role in understanding of software engineering make me realize software can also like assembly line engineering, development mode, people do not development process, mainly the development process of software engineering control, a relatively fixed process, as long as people do some mechanical work can complete this project. In the current environment, software engineering ideas are still dominant, but software technology ideas also have their base of support, such as workers in the open-source community.

 

Software technology of the main pressure is a very important role in the whole project, software process is very strict requirements of the team, the team first small number, no more than 15 people, the general team is three people, but for the team of personal ability request, the other teams also are in high demand of health, a more stable team, team members can develop the tacit understanding.

 

The book Software Craftsmanship gives us a good development model, but many projects in the current environment are developed using software engineering ideas. Why is this? In my analysis, the main reason is that software technology requires too much of the team, and there are too few excellent craftsmen, so it is difficult for many companies to organize such an efficient team. Right now, the idea of software craftsmanship can only be seen in the open-source community, where many of the true craftsmen are gathered.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.