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.

https://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects

Seeing as we’ve started learning about design patters in class recently, I decided I’d explore a pattern further in depth.  Seeing as the singleton pattern was the last covered in class it was the one I chose.  Where most other sources would just condemn it as a bad practice, the article linked above does a good job of exemplifying both the pros and the cons of using the singleton design pattern.  One of the pros, something I learned as well, was how singleton classes can save memory by using lazy instantiation.  Opting not to assign memory to the variable until called; this method can create errors as well.  If multiple threads access the instance at the same time it will create multiple instances of the singleton class.  There are synchronizing techniques to get around the issue but it’d most likely be easier to use static initialization.  In static initialization, memory is allocated when the variable is declared.  The only difference this makes in the code is moving the creation of the object to where the variable is being declared.  Inheritance with singleton classes seems straightforward enough.   Any class inheriting from it will create more than one instance of the class thus violation the principle that only one instance can exist. However, if you wanted multiple singletons to inherit the same behavior, the code could be provided in an abstract class.  Although this may seem purely a shortcoming, it does prove itself when compared to static classes inability to work from interfaces.  One of the other major drawbacks that I learned about was that singleton classes couldn’t accept parameters which contributes to their limited flexibility.

The singleton pattern has me a bit conflicted with its use in java.  Although it seems like an easy way to create global variables in java, many of its drawbacks seem very limiting or painstaking with more complicated programs.  The linked article does, however, do a great job of showing and explaining how to create singleton classes and will differently be my go to for a reference.  Reading it was a great auxiliary to the lectures given in class.  Seeing how singletons work (and don’t), in depth, has also raised my confidence with working with them.  I’m sure that having a complete understanding of this design pattern will be useful as a tool to compare and understand the behaviors of other patterns.

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.