The podcast episode referenced in this blog post can be found here.

This podcast episode from CodingBlocks.NET discusses the SOLID design principles. I chose this episode because SOLID is a fairly early topic in the syllabus and appears to cover several important principles. The podcasters start by introducing SOLID as guidelines for well-designed code, defining “well-designed” as easy to change, easy to read, and easy to maintain. They suggest that you should usually code first and then refactor according to these design principles as the need arises, since following the principles can take a lot of work. Additionally, you probably can’t adhere to every single principle out there, so practicality comes first. Summarizing every principle discussed got long, so I’ll summarize the ones that affected me the most.

The Single-Responsibility Principle is fairly simple – it holds that a class should do one thing and do it well, i.e. objects should only have one reason to change. With this principle in mind, I will check my classes to see if I can think of two or more reasons I might need to modify them, and if I can, I’ll see if I can divide the responsibilities into multiple classes.

The Liskov Substitution Principle states that objects in a program should be replaceable with instances of their subtype. They talk about how making a square a subtype of a rectangle, while intuitive, would actually violate the Liskov Substitution Principle because of a square’s additional restrictions. You ought to be able to set a rectangle’s length and width to two different values, but this is impossible with a square. They conclude that if your subclass requires something a base class doesn’t, chances are you’ve violated this principle. This makes a lot of sense once spelled out, and in the future, I will make sure instances of my subclasses can be used whenever objects of the parent class are expected.

The Interface Segregation Principle holds that more specific interfaces are usually better than large, general interfaces. For instance, using a brake information interface where brakes are concerned would be more efficient than using an entire car interface. The podcasters say that according to this principle, if your interface requires a lot of methods in order to be implemented that often aren’t needed, your code smells. With this in mind, I will examine my interfaces for methods I’m not using most of the time and see if I can make smaller, more specific interfaces.

Additionally, the podcasters note that following the Single-Responsibility Principle and the Interface Segregation Principle make unit testing easier, so I’ll make sure to keep this in mind if I expect to do unit testing or pass my code on to a unit tester.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

For this blog i chose the podcast Making a better tester with Keith Klain from the testinginthepub podcast website. This is a website where there discuss various topics in the software testing field. I picked this podcast because it sounded interesting and seemed like a good starting point into the world of software testing. It discusses some of the downfalls in the testing field and areas to improve as well as an overview of the state of the industry today.

The podcasts starts with the guest of the show Keith Klain discussing one issue that seems to come up a lot in the testing field. This was that the testing teams objectives would not align well with the business side. He talks a lot about how often times when he consults for a company he will see that the testing team is effective, but simply that their goals to not match that of their business counterparts. He then goes on to state how important it is for the testing team to have good communication skills with the business team and to have their goals aligned to make testing as effective as possible.

The next section of the podcast builds where the previous section left off. This section talks about how one of the big things holding the industry back is that a lot of company’s still use very old ways of handling their testing. Most of this includes outsourcing all of their testing to independent firms and testing centers. Keith Klain states that as much as fifty percent of major financial firms and banks still outsource all their testing to large testing centers in other countries. This not only makes it harder to communicate and have everyone on the same page but also since this company’s treat this as an external service and  just get the results back they do not truly understand the data that they get from testing. The podcast also discusses that financial aspect of it ,stating that it is hard to completely phase these practices out because they are so deeply ingrained and these testing centers make a lot of money and employee a large number of people. Keith Klain also states that the reason a lot of these company’s are having a hard time updating their systems to agile or waterfall development is because of how heavily they rely on these large testing centers.

The last section of the podcast talks about the exposure and communication in the testing community. The podcast refers to a recent expo that the hosts had attended which was not testing expo but a more general tech expo. The podcast talks about how a lot of people seem the have misconceptions about what testers are and really do.Keith Klain talks about how the testing community needs to be a little more social in order to draw new people into the community.To finish up the podcast Keith Klain talks about the usefulness of experience reports and documenting some of the experiences you have in your testing job , and how this can be really helpful for figuring out which systems work in different contexts.

In conclusion i found this article to be very interesting and gave a good insight on where the industry is today and where it is going. To me it seemed to be plagued by a lot of the same issues as in other parts of tech, such as technology moving very fast and a lot of non tech companies having trouble keeping up. It also seems like the industry is held up by a lot of old infrastructure that is hard to remove because the amount of money that is tied up, which i would also say is a larger problem in the tech industry. One thing that interests me is seeing how the industry will grow, will the testing teams start working much closer with the development teams and how will this effect performance. If so will we then see a shift into developers writing their own tests and having the whole process be that much more unified, and if so how will this effect performance and the industry.There is a part 2 of the podcast which i am looking forward to listening to.

-Thank you for reading

-Dhimitris

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

The blog that caught my interest this week is Good Programmers Get Off Their Butts by Jeff Atwood on Coding Horror. This post was centered around the author’s experience with UML diagrams and his overall view about its practicality in the field. Jeff finds that spending too much time on the design results in very little time for implementation. Then if there is very little planning, there is also a drag in the time for implementation. Which leads to his overall idea that, even if the design is vague, it is better to write some code than furthering the designing process in UML. His experience with proper designing procedures is a great read for many of us, that have recently learned about UML diagrams.

I chose this blog post because after reviewing countless articles, it seems to conclude that UML diagrams are useful in certain environments/situations and not a definite approach to design. These include being used as documentation or to explain specific code to people. Jeff explains a couple that are concerns of mine. One would be repeatedly updating the UML diagram to keep the design up to date or coming across a large problem in the design during the implementation process and having to scrap the design because of it. I would consider these to be time-consuming tasks and would stall development.

However, his message wasn’t all bleak as he does believe that it is useful from his comment that “Coding without planning is just as futile as coding with too much planning”. This comes back around to having a short design plan, perform the implementation, and then pan out the rest of the design as you go. I do see this as a future tool I could use, as time is a valuable asset. Relying on completing a full UML diagram will show what you need to do in theory, but when it comes down to implementation, not everything will go according to plan. This will result in turning back to the diagram, in attempt to solve the various issues that could arise later. However, if you have a rough idea of what the direction the design should go in, during implementation the process of editing the diagram won’t be so painful as there is little to change. Overall, grasping the concept of UML diagrams and understanding that it is a useful tool in general, but can work against you if you are overdependent on them is great to know for future projects.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Creating efficient programs is very important, in that it allows processes to run faster and in some cases, with less memory. Program optimization is key in making fast and reusable code. Currently, we are learning about various ways to create efficient implementations of object-specific attributes. By doing these, we need to understand that we need to be careful and consistent with our designs because if, in the future, things need to be modified or added, it can be done with ease. Database querying is a process in which mass amounts of data are sifted through by algorithms to extract to inject specific data. The article I choose mentions that, not only do we have to be efficient with the database query algorithms, but also within other aspect such as power consumption.

The article explains how cache servers are very expensive because they use the “power-hungry” and expensive Random Access Memory modules. However, some cache servers are starting to implement and test Flash Memory databases. Since flash memory is so cheap and has much more storage density that RAM, it would seem like and obvious switch. However, along with the cheap speed comes slower performance than RAM.

I choose the article because working with efficient materials and hardware can lead to innovations and new implantation of design ideas. We discuss design principles so that we can understand the advantages and disadvantage to the better and worse outcomes of issues, respectively. From the article “The more important concern is keeping up with the requests flooding the data center. From the article, “The CSAIL researchers’ system, dubbed BlueCache, does that by using the common computer science technique of ‘pipelining.’ Before a flash-based cache server returns the result of the first query to reach it, it can begin executing the next 10,000 queries. The first query might take 200 microseconds to process, but the responses to the succeeding ones will emerge at .02-microsecond intervals.”

In the future, I expect to apply what was learned by finding ways to further conserve memory and creating the most efficient design principles for my projects. This is important because querying mass amounts of data can take very long (and can use a lot of power) and it is important in recognizing that there are certain design principles that work better in certain situations. The article also states that “A data center for a major web service such as Google or Facebook might have as many as 1,000 servers dedicated just to caching.”, and if you are performing that many calculations, you will need to have efficient modeling and understand good design patterns to handle all of the data correctly. This also made me realize that there are a lot of other factors, such as processing and energy costs, that are considered in certain stages of program modeling.

Source: (https://www.sciencedaily.com/releases/2017/08/170831115210.htm)

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.

For this blog I chose an article called “Performance Testing vs. Load Testing vs. Stress Testing” on BlazeMeter’s website. They are a software testing platform for developers but keep an active blog for their community as well. I thought this article sounded interesting because I get to compare three different types of testing versus just learning one. I like the comparison aspect because it can help increase your situational awareness on why or when you might use a specific type of testing over another.

First mentioned is performance testing. This kind of testing takes into consideration things like responsiveness, stability, speed, and resource usage. Satisfactory performance testing varies greatly between customers so it’s important to establish the requirements early on. This type of testing can be used to check things like website or app performance and report back specific key performance indicators (KPIs).

Next is load testing. This type of testing is checking a system under a large concurrent usage or heavy volume. It’s a good indicator of how many users a system can handle. It is a good idea to check a variance of places in a system and not just the system as a whole. For example a website may do a load test specifically on their checkout page. Its suggested load testing is something that should be done frequently.

Last is stress testing. This type of testing checks the upper limits of a system by putting it under a heavy load and also monitors how it returns to normal. Checking for security issues or memory leaks can also be a part of this testing. Two common methods of stress testing are spike and soak. Respectively they are either a sudden high increase in load or a longer period of growth leading up to a high load. This type of testing is most popular for applications that can see high volume events like a website that sells concert tickets.

In conclusion, I can see the importance of all the mentioned types of testing. I would say that performance testing would be your foundation and most important. The other types of testing won’t matter if you don’t have an efficient application under normal circumstances. I would then say that load testing is more important than stress testing. While they seem to be very similar I’d care more that my application can handle a heavy volume over knowing what my system breaking point might be under a heavy spike. After finishing the article I am more interested now in how these types of testing are performed and what kind of tools developers use. This will probably be the discussion of an upcoming blog.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

A topic that we recently discussed in class is Strategy Design Patterns which is defined as a family of algorithms that are each encapsulated and made interchangeable. Strategy lets the algorithm vary independently from the clients that use it. It is best to use when many related classes differ only in their behavior and when you need different variants of an algorithm.

https://www.madetech.com/blog/design-patterns-strategy

I chose to write this week’s post on a blog written by Scott Mason which is also on Strategy Design Patterns. I chose this blog because Masson explains Strategy Design Patterns by using a popular video game, Overwatch as an example and shows how Strategy Design Patterns are needed to make the game more efficient. This blog stood out to me because of the Overwatch example since I’ve played the game before.

The blog poses a problem. In Overwatch, players have the choice of playing as 21 different characters, and each character has 3 different attributes unique to them. During the game, the user is able to switch between characters when they die, so the game needs to run smoothly.

Mason shows what a poorly designed code would look like, where you have a class for each ability, but create an if statement for all 21 characters. This would result in 63 different cases which is too repetitive.

Mason poses the solution which is to create a series of classes known as strategies, one per unique character, that defines how each of the characters implements their abilities. This makes it so the Player class doesn’t need to know the specifics of how each character implements each of their abilities, and we can just pass a particular character to it. The new code that’s shown in the blog cleans up the program significantly so that new characters can be added with ease by creating different strategies with the same methods.

This was a nicely written blog that explains Strategy Design Patterns efficiently because it thoroughly went through transforming messy, inefficient code to code that uses strategy and is efficient. And what made this blog more appealing to me was that it used a video game I play as an example, which made it easier for me to understand everything going on in the code. This won’t appeal as much to people who haven’t played Overwatch though, but I enjoyed the blog and it helped me understand Strategy Design Patterns even more than I did before.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

For this blog I chose an article on DZone which is basically an online community for software development. I discovered them through the UML exercise in class because of their “refcard” we used as a guide. For the article, I went with “Decorator Pattern Tutorial with Java Examples” because I wanted to learn a design pattern I’d never heard of. Also, with Java examples it would be easiest to follow along for me.

To get started, it’s important to know that the decorator pattern allows class behavior to be extended dynamically at run-time. This means attributes can be added to Objects dynamically which the author relates to the concept of a wrapper object. The decorator pattern is more broadly considered a structural pattern which encompasses many different patterns that focus on identifying a simple way of implementing relationships between entities.

One of the principles of the decorator design is that classes should be open for extension but closed for modification. Two main instances which the decorator pattern is useful are 1) when object behavior should be dynamically modifiable or 2) when concrete implementations should not be coupled to behavior. While sub classing can achieve the same effect, decorator can decrease maintenance by preventing too much sub classing. The author suggests to only use the open/closed principle where code is least likely to change to avoid making the code too abstract and complex.

A good example of the decorator pattern would be a company’s email system. If an email is generated and sent out from a company employee the decorator pattern could account for different scenarios. If the email is sent internally nothing occurs, but if the email is sent externally the system could “decorate” the email with a copyright or confidential statement attached to it.

After reading about the decorator pattern I can see the benefits but I don’ t think I have come across a project thus far that I would have really been able to put this to use. After a quick google search it looks like Java’s I/O streams implementation is a good example for learning more about the decorator pattern. I will probably look more into this as I can’t see how this article really helped me much moving forward. I think after I play around with it I’ll be able to better understand how I could apply it to my own projects. This article was good for a general explanation but not for learning the actual implementation.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Writing Great Unit Tests

Unit testing was one of the types of testing that I had played a little bit before. Therefore, when I found this blog entry about Writing Great Unit Tests: Best and Worst Practices, I decided to choose it to understand more about unit testing and check if all the unit tests that I wrote in the past were good or bad. Below was the URL of the blog entry:

http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

In this blog, Steve Sanderson discussed about unit test and the tips to write great unit tests. He mentioned that it was overwhelmingly easy to write bad unit tests that add very little value to a project while inflating the cost of code changes astronomically. In his opinion, unit testing was not an effective way to find bugs or detect regressions. Unit testing was more about designing software components. He also compared good unit tests with bad unit tests, and provided some tips to write great unit tests.

Steve explained the reason he thought that unit testing was not an effective way to detect bugs or regressions. I agreed with him that only proving component X and Y both worked independently did not prove that they were compatible with one another or configured correctly. Therefore, bugs still might occur when the application was run. This absolutely reduced the effectiveness of bugs detection. Before reading this blog entry, I never realized that unit testing was not that suitable to find bugs like that. Furthermore, Steve provided a table to identify which type of test we should use for different purposes like finding bugs, detecting regressions, or designing software components.

Steve also gave some tips about writing good unit tests. In my opinion, some of them were very basic, but Steve still included them. I thought that was because he saw a lot of bad unit tests had those mistakes. He recommended not to make unnecessary assertions because unit tests were a design specification of how a certain behavior should work. Including multiple assertions only increased the frequency of pointless failures. Moreover, the unit tests’ names should be clear and consistent. Personally, I liked the way he used to name the example unit test. It helped you quickly identify the subject, the scenario, and the result of the unit test. This way of naming was more descriptive than the way I always used. I would apply it the next time I wrote tests.

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.