This week’s reading was Code Smells written by Jeff Atwood, on Coding Horror. As the title of the blog suggests, the message that the reader should get from the post is to familiarize themselves on the common smells to prevent design problems. With that, he lists the different type of smells into two categories, “Code Smells within Classes” and “Code Smells between Classes”. The first category deals with simplifying, removing or splitting code where its due to make reading methods easier. This idea is also applied to classes, which should reduce unnecessary classes or makes sure encapsulation is applied properly.

There is no definite reason as to why I chose this topic but it is said that developing your code nose early is useful for the future! From what I have gathered so far, the idea behind this topic is to have a good design where the earlier choices of methods/classes will not have conflicting issues for later additions or improvements to the code. Many of these code smells are already taught in earlier introductory CS courses such as, duplicated code and making useful comments.

After reading about the different types of code smells, I have noticed a couple that code be smells in previous school projects. One would be the overuse of comments, as I sometimes find myself not remembering what a certain function was used for, which compels myself to leave a comment here and there. Another would be oddball solutions, where sometimes issues mysteriously fixes itself as you continue with your code. This usually leads to problems in the future while adding newer functions. However, there are a couple of smells that are useful to remember now then later such as Speculative Generality. After being taught to prepare for future problems in life, it’s also sometimes applied to writing code but is a wrong mindset. Only implementing things when you need it will reduce clutter and seems to apply to the dead code smell, where you should delete unused code.

By exercising or having an open mind to these design problems will help prevent simple problems from appearing while working on projects. Having clean code benefits myself and others while reading the different classes/methods we each produce. Which should entail a better experience for group work, and saves time solving problems that should not have existed in the first place. There is no way to remember all the different smells, but being aware of them will help myself produce cleaner code in the future.

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.