The “Find Mentors” pattern is explained as the search for when beginners start looking for developed craftsman to show them a specified path. The book explains that the first step is to find someone who is already ahead of you and try to learn as much as you can from them. Eventually, someone will take on an apprentice and you will be able to establish a better idea of your future from there. It can be difficult to get attention from a single master as they try to teach you and try to work on their own projects. This can lead to having multiple people looking over your growth to make sure that there are multiple inputs to your learning experience. The important part of this step is to make sure to not get frustrated or confused with the multiple sources of information. Masters also have their own weaknesses, so make sure that you understand exactly what those weaknesses are and how you would change your learning methods to accommodate those weaknesses such that they aren’t mirrored onto you.

          I found the Find Mentors pattern interesting because it explains the benefits of having someone who can guide you while also explaining how to further enhance your learning with multiple masters. It taught me to understand the issues of having a working mentor when it comes to workloads. I had never thought about how the masters have their own lives to juggle while also trying to teach their students. I found that the idea of getting multiple master was useful but that it could also come with its own drawbacks in some scenarios. It would be tough to find a reliable master and the more masters you have, the more likely it is that one of them may be leading you astray. This idea is what I don’t like about this pattern and I intend to apply it to my own learning. I don’t mind finding a master as long as I feel comfortable double checking them to make sure that everything, I’m learning is correct and won’t harm my growth. Other than those drawbacks, I understood and enjoyed this pattern. It’s repetitive nature of the learning process for students is easy to grasp which makes that much easier to apply.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Similar to last week, I continued to read through Chapter 5: Perpetual Learning. This time, the pattern I am writing about is Learn How You Fail, and I’m finding it extremely relevant to my independent study at the moment. The pattern itself discusses that the path to success isn’t just all about learning and knowledge acquisition, but that it is equally important to pay attention to how your learning progresses and analyze why it stalls when it does — because it will stall. Sometimes we have behavioral patterns that negatively influence our ability to learn and perform. Once we become conscious of these behavioral patterns, we’re faced with a choice. You either accept that you will not change and attempt to collide with the issue forever, or you work to fix the problem. In the world of software development, this pattern may come up where there are gaps of knowledge in things that you have failed learning before. When you come across this, try sitting back and examining the trajectory you were on when you originally attempting to learn it and recognize what caused the interference. Try to reiterate on what mistakes you made originally, and intentionally spend time on those issues.

This pattern was particularly good for me to read at the moment because I’m attempting to tinker with the MINIX 3 operating system for my independent study and feel as though I’m struggling to make progress. I’m a fairly reflective person and I try to recognize any mistakes I’m making so I can work on them, but sometimes when something causes much stress and feels overwhelming it is very easy to get sucked in and forget the bigger picture. Taking time to step back, create a new plan of attack, and going at things from a different angle is key to overcoming obstacles. There is always an angle that will work, and it does just take finding it sometimes.

This, perhaps above any other patterns so far, may be the most important lesson to take from this book. It can be applied to every aspect of life and is absolutely critical for success in a field. Not only for success, but for staying in the right mindset (and for staying humble) in your advancement. Recognize that everyone, including yourself, has made and will make mistakes. It is precisely how you proceed forward from those mistakes that makes the difference in the long run.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

This method talks about how there are tools that we need to master but we may not always understand how to master them. A lot of the times we try to be a master of all, when in reality that doesn’t necessarily work all of the time. What I mean by this is that when we are faced with  a task, sometimes we think we understand each little aspect of the specifications. However, upon actually tackling that task, we aren’t really sure where to go. Like one of my previous entries on “Exposing Your Ignorance”, confronting your ignorance really focuses on selecting on skill, tool, or technique and really honing in to fill gaps in your knowledge about it. One of the points in this method that really caught my attention was it’s mention of humble, ignorant, and dependent team building. If you are working with a team of developers and each team member has this ideology that everything is “just because of the way it is”. this can lead to a multitude of problems.

One of these problems is bad team building. When you assemble a team of people for some sort of project, you want to be able to work together to share ideas. If a problem arises you all want to be able to come together and understand what the issue is so you can solve it as a team. If you all think that things are just the way they are because they are, this can often lead to disagreements among team members. Some team members might even think you are against them just because you disagree with them on something. It’s this idea of confronting your ignorance that is vitally important to understand. You should learn one thing at a time, that way when a problem arrives, you can put aside  what you know, and focus on what you don’t know. Failure in a public place can be embarrassing, but it is exactly these failures that make it better. If you failed at something, you wouldn’t want to be ridiculed for it. Instead, you should learn from it and always be willing to learn more and more about the issue.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

To continue with chapter four “Accurate Self-Assessment”, int his chapter we learn how to assessment ourselves. We learn our value in the team, how to work with each other. Everyone is beginner of craftsman at one point. We all at some point is a new apprentice on a project. This is where you’re unsure of your place on the team, and the team is unsure of you. This is not just when you are new software developer, its also apply to you are new to the group.

“Sweep the Floor”, a job not a lot of people want to do. Everyone in the group should contribute same amount of work, but that’s not always the case. Most people would want to be the best craftsman, but there are other important job that need to do. One way I discover while at school, to get group trust when you are newbie to the group is be active volunteer for work. We want to show our desire to work, it is the easy way for group get to know you. Also, a great way gets to know how the group operate/code design from bottom up. For example in the book, task as “maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.” This is do so for the group benefit. There are also a few negative consequences, your teammate also takes you wrongly as someone who doing job that no one else will do. You will not have opportunity to do changeling one. If we know our value, though our hard work we can earned their trust. With this mentality, we have the flexible to be in any environments. This also apply when there is other new addition to the group, you can understand them and show them the right way.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

This week, I read all about an apprenticeship pattern titled Be the Worst. This pattern details the benefits of being surrounded by people who are smarter than you and have more experience than you. The idea behind the pattern is that the more time you spend around others, the more information you can learn from them. Why spend your time figuring out a problem somebody already solved when you can learn the veteran’s way of handling it from a colleague? Surrounding yourself with more advanced developers can help build your skills and gain experience in ways you wouldn’t if you were learning concurrently with them.

This is a pattern I can absolutely relate with from experience. Some of my best classes where I learn the most are the ones where there are a few peers above my level to help me learn what they already have. Sometimes, the way someone explains something to you is difficult to make sense of, but another peer can explain it in a way that makes more sense and is easier to understand. Similarly, working with many people above your level gives you a wide variety of different methodologies and ways of doing things, which can help illuminate best practices and start insightful conversations.

The alternative, being the smartest person in the room, can be very unchallenging and doesn’t give you any room for development. It is nice to Share What You Know, but if that is all your doing it can be hard to progress your personal goals. A large disparity in the skill level of developers causes more time to be spent on closing that gap rather than working on the project at hand.

The challenge with this pattern is more the emotional toll it can take on you to be surrounded by smarter people. Being the dumbest person in the room can be beneficial from a self-centered learning perspective, however it can definitely feel a little embarrassing to be so far behind everyone else. Being able to swallow your pride for the development of yourself and the team is a challenge, but the rewards are worth it.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

After finishing our final project I was still curious on many things about angular and how we would use it in future projects if we were to transition over to becoming a front end developer. This blog ‘Why should you learn Angular in 2018?’ by Aman Goel talks about Angular is, the different types, and the advantages.

From what I’ve learned, Angular is a framework that developers use to build applications (a simplified view). Goel talks about the development of angular applications and how it incorporates Typescript along with HTML and CSS. I know I built my project with the latest version of angular when I created it with the @angular-cli/@latest command but apparently there are versions from Angular 1 to Angular 7 and skipping Angular 3.

Some advantages of using Angular is that it supports Single Page Applications which is what we did for our project. A single HTML page that is updated dynamically according to the interaction of the user.

He lists the advantages of using Angular as seen down below:

– Supports Single Page Applications
– Two-way data binding
– Modularity in Angular
– Reduced coding
– Declarative User Interface
– Easy Integration
– Cross Platform

Before reading this blog I did not know how much we learned from doing this project but after reading it, I realized that all of the advantages listed in this blog were used in the process.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

In the final exam, there were a few questions on mutation testing which I was very unfamiliar with so I decided to look into posts/blogs about mutation testing. One interesting blog I came across was written by James White – ‘Mutation Testing – Who will test the tests themselves?’.

The very first sentenced stated “this is aimed at people who are not familiar with mutation testing” and it was all over from there; I had been sucked into the article since I had no idea what mutation testing really was.

White starts off by describing what mutation testing really is and his definition was “Very simply mutation testing is a way of testing the quality of your tests by introducing changes into your code and seeing if your test suite detects them”. Very straight forward. He then gives an example written in java and a scenario seen below:

private static final int MARGARINE_WEIGHT = 100;
private static final int COCOA_WEIGHT = 25;
private static final int EGG_COUNT = 2;
private static final int ORANGE_JUICE_VOLUME = 15;

Cake createCake(CakeType cakeType) {
Cake cake = new Cake();
cake.setMargarine(MARGARINE_WEIGHT);
cake.setSugar(MARGARINE_WEIGHT);
cake.setEggs(EGG_COUNT);
if (CakeType.CHOCOLATE.equals(cakeType)) {
cake.setFlour(MARGARINE_WEIGHT - COCOA_WEIGHT);
cake.setCocoa(COCOA_WEIGHT);
} else {
cake.setFlour(MARGARINE_WEIGHT);
if (CakeType.ORANGE.equals(cakeType)) {
cake.setOrangeJuice(ORANGE_JUICE_VOLUME);
}
}
return cake;
}

As well as different test cases:

@Test
public void canCreateVictoriaSponge() {
Cake actual = testee.createCake(CakeType.VICTORIA_SPONGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(0, actual.getOrangeJuice());
}

@Test
public void canCreateOrangeCake() {
Cake actual = testee.createCake(CakeType.ORANGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(15, actual.getOrangeJuice());
}

He then shows us the results of his tests as well as his mutation tests. So I learned that mutation testing works on the principle that since the test code is there to ensure that the code works, if mutating a test, at least one test should fail. Mutation killed means all your tests pass and mutation survived indicates that the mutation survived and there is a potential area where a bug could arise.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

As I take my first step towards my journey in Software Quality Assurance and Testing I dive into Unit Testing. After searching the web found a really good podcast named “Unit Testing With Test Driven Development” by Beej Burns this podcast is about Unit Testing and focuses most on Test-Driven Development (TDD). I will be using this podcast to help me write this blog.

In the podcast they had two guess John and Clayton. They went on the podcast and talked about their book ‘Practical Test-Driven Development Using C# 7: Unleash the power of TDD by implementing real world example under .NET environment and JavaScript’. I personally have not read this book. According to the podcast this book is meant for Software Developers with a basic knowledge of TDD. This book is intended for those who wish to understand the benefit of TDD. This book is beneficial for individual who know C# basic since all the examples are in C#.

The Following Q&A are the Question asked in the podcast and the guest answer. The answer I am writing are summarized in my own words but originally derived from the guest on the podcast. Also I am not doing all the Q&A just the ones I found interesting and liked how the guest answer the question. If you want to hear the original question and answer visit the podcast site: https://completedeveloperpodcast.com/episode-140/, Lets start.

What is Unit Testing?

Unit Testing is the ability to test in isolation. That is to simply test an application without affecting the rest of the other test.

Why is Unit Testing important?

We use unit testing to make sure each unit performs as intended. Unit testing is important because it minimizes the risk of error in your software, but it also forces you to have better code structure. It also allows major changes in your code to happen at a lower risk. Another reason it is important is because it allows new developer to understand your software structure.

*Note that naming convention is very important so developers can understand what is being tested.*

What is the point of Test-Driven Development (TDD)?

The point of TDD is doing the right thing without making a mess. That is short iteration cycle reassuring that you and your application are doing the right thing.

According to one of the guests when writing Test-Driven Development there are 3 stages/steps:

• Red cycle to see test fail
• Green phase when you make the test pass
• Refactor production code and test code.

The idea of TDD is to build the test before the code.

Other benefit for TDD other than code in an organized level is:

• Reduces the overall bugs and make bug resolution quicker.
• Less down time.
• Better requirement
• Can find problems with just running the test which it shows where code went wrong.

What are some of the things people get wrong about unit testing and TDD?

Testing your test too close to your implementation. “Test should represent the business rules not how you decided to implement the business rule. That way when you go and change stuff later on like the implementation. You want to refactor and remove thing into a different class. This doesn’t break what your test does because you will be restructuring how it is doing it”.

How do you manage complexity on a unit test, and how do you structure your overall testing projects?

“Form an overall method uncle bob (Robert Martin) suggest only having method that are five lines or less in size”. The guest that answer this question take Robert Martin suggestion to heart. He goes on and explains that if a method has more then five lines then he’ll brake it down into more than one method. If a class has more than five method then he’ll brake that down into more than one class. If a folder has more then five class than he’ll brake that down into more than one folder. If a project has more then five folder he’ll consider braking it down into more than one project. He goes on and say that he will do the same exact thing when testing except he doesn’t care much about the line length because most test case are usually 3-4 lines long. He has the arrangement where he set up the pre-content of the test and then have the action are 1-2 lines. These tests are pretty small to start with but within a test class he won’t have more than five things overall that he is testing within a test class, no more then five unit, and no more than five logical assertion which tends to reduces the size of any one thing within a test project.

What are some good practices you can use to make sure your test is maintainable on the long run?

• “Don’t forget to refactor your test, because your test suit is just as important as your production code”.
• “Remember you are testing small unit or small pieces that should have never enter connective dependency so that you feel comfortable substituting a mock, spy, or fake implementation. Be careful not to test your fake, mock, or spy.”
• “Where ever the code end that’s where the test should end”.
• “Make sure we abstract all third-party code”.

I will wrap this up by saying unit testing is a very important skill to have no matter what. It helps in creating clean code and reduces the risk of error. Unit testing allows software developers to make large changes in the software code at a minimal risk rate and it allows code structure to be understandable by new developers. One thing to note is when creating unit test and developing software you must make sure to have good naming convention. When developing software, its best to start with writing the test first.

My name is Yesenia Mercedes-Nunez and this has been YessyMer in the World Of Computer Science, thank you for your time until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

In the second part of Brandon Gregory’s blog post “Coding with Clarity: Part II“, he starts with the assertion that “Good programmers write code that humans can understand”. In the spirit of clarity, Gregory continues to elaborate on solid design principles that are helpful in software engineering.

The first principle is the Law of Demeter, or as Gregory puts it “the principle of least knowledge”, and describes this principle as an application of loose coupling, another design strategy that states one part of a program should not rely on others. Adhering to this principle will help ensure flexibility if new features are added or modified.

An example Gregory uses that demonstrates this principle is the use of getter/setter methods to provide access to class data as opposed to allowing classes to directly access data. By applying this tactic, it ensures that future modifications do not mess up any other parts of your program, as all modifications will be in the getter/setter methods.

The next programming practice is the Interface Segregation Principle. This is to make sure no object contains methods it doesn’t use. If a class has a bunch of methods, and not all methods are used for each instance, the better strategy is to separate that class into specific interfaces or sub classes. This is a similar goal as the strategy design pattern that we discussed in class.

However, Gregory warns us that abstraction can be taken too far. It is possible to abstract so much that the program contains an excessive number of interfaces or sub classes. The author reminds us that the goal of abstraction is to reduce complexity.

The final principle in the article is the open/closed principle. This assertion is that software should be open for extension but closed for modification. If the program is designed correctly, the implementation should perform as specified and should not be modified. Instead, to change functionality of the program, all that should be done is adding functionality, and not changing any of the existing code.

I very much found this two part series of “coding with clarity” helpful.  Almost all of the principles Gregory explains have been applicable to content we have covered in class. I found his writing style easy to follow and the particular examples he uses to demonstrate the principles are cogent and illuminating.  I recommend them to everybody looking to improve their design knowledge.

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