Category Archives: Week 11

Java: The Factory Method Pattern

In this blog post, Justin Albano talks about the Factory Method Pattern and gives us an example.

The Textbook Definition

According to the Gang of Four book that defined the technique, the intent of the Factory Method pattern is as follows:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Using the Factory Method involves creating two sets of interfaces: “(1) the product interface that constitutes the object to be created and (2) the creator interface that constitutes the object that will instantiate the product.” The UML diagram for the Factory Methods is below:

The author explains the UML diagram as the following:

Using the general pattern, we build a Creator interface, which includes one or more Factory Methods, as well as any number of other methods. This interface may also be an abstract class with defined methods or even a default implementation of the Factory Method that returns a default instance of Product. From this interface, a set of ConcreteCreator classes are created that return desired ConcreteProduct instances that implement the Product interface.

An Example in Java

  • We create an encryption mechanism that allows the user to supply a string of text and a file name, which is then encrypted and written to disk. Using the Factory Method allows us to use multiple encryption algorithms.
  • We create implementations for two encryption algorithms: (1) SHA-256 and (2) SHA-512. “For both implementations, we will use the Apache Commons encryption implementations (org.apache.commons.codec.digest.DigestUtils).”

    • In the end you should be able to do something like this:
    PersistedFile file =
       new PersistedFile("/foo/bar/text.txt", "Hello, world!", new Sha256Encryptor());
    View complete example here

    Colloquial Definition

    A method whose sole responsibility is to abstract the creation process of an object and return that object.

    I chose this resource because I am interested to learn new implementations of popular design patterns such as the Factory Method. This resource gave a detailed explanation along with other patterns that can be good alternatives to the Factory Method pattern like the Template Method pattern and Strategy Pattern. I believe the content of the article is very detailed and informative. The example they used is very interesting and I’m going to implement the code myself to test it out. I plan to use this and many other design patterns in the future. I learned more about the Factory Pattern method and when it is appropriate to use it.

    The post Java: The Factory Method Pattern appeared first on code friendly.

    From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

    AB Testing – Episode 10 by Brent Jenson and Allen Page.

    Episode 10 by Brent Jenson and Allen Page.

    In this week’s testing podcast episode, Brent and Allen begin by discussing changes that Microsoft made during the absence of Allen in the testing department. Microsoft decided to shift their focus to a quality assurance based system instead of emphasizing on a testing based platform. Although these concepts are closely related in the field of software testing, they each specifically represent something different. Software testing is usually the process of executing a system with the intent of finding defects. By process of testing, we are able to assess or evaluate the capabilities or attributes of a software program’s ability to adequately meet the applicable standards and customer needs but quality assurance on the other end refers to a set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. These new implementations by Microsoft forced engineering managers to move between teams and successfully understand the overall product specifications that need to be accomplished. After this talk, they moved over to duties and abilities of a manager the drives a QA team into either being successful or a failure. Inadequate technical skills and bad manners often lead to the demise of a team according to Brent. He believes that a manager that falls into this category only knows how to “demand more from the sausage crank”. This not only damages the crank but also shifts the focus of the operation. Increasing the fire under the meat provides more desired result. The fire is resource and help that is needed to get the task accomplished. The sausage is the software and the crank is the team members. To be a good testing and QA manager, you have to task the team members with things you would do yourself if you were the worker. Understanding that consistency and confidence in you by your employees pushes the team momentum forward. Another big factor is that product quality directly relates to the team adequacy. The best products more likely than not comes from the best QA and testing teams. Understanding that the well being of a team affects the product they are able to produce is one of the first steps to succeeding in creating a great QA and testing team. Good organizational health has to be the focus of every organization that supplies products and services to users.

     

     

     

    Sources

    https://testingpodcast.com/category/ab-testing/page/7/

    http://www.mosaicinc.com/mosaicinc/rmThisMonth.asp

     

    From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

    The Decorator Design Pattern

    What is the Decorator Design Pattern?

    The Decorator pattern applies when there is a need to dynamically add as well as remove responsibilities to a class, and when the sub-classing would be impossible due to the large number of sub-classes that could result. Also, use it when you want the capabilities of inheritance with sub-classes, but you need to add functionality at run time.

    Intent

    • Attach additional responsibilities to an object dynamically.
    • Decorators provide a flexible alternative rather than making many subclasses to extend functionality.
    • Client-specified embellishment of a core object by recursively wrapping it.
    • Wrapping a gift, putting it in a box, and wrapping the box.

    Discussion

    Say, you are working on a UI and you want to add borders and scroll bars to your windows. You could define the inheritance like… Window class interface, then you have concrete objects WindowWith_Scrollbar, WindowWith_Border etc..  This type of architecture creates a lot of subclasses and not much room for modularity.  It will be hard to change the concrete classes if you want to add some additional functions to them.

    The Decorator pattern suggests giving the client the ability to choose what features they want.  There might be a problem of chaining features together to produce custom objects as well. The solution to such problem is to encapsulate the original object inside an abstract wrapper interface. Both the decorator objects and the core object will inherit from the abstract interface. Then the interface uses recursive composition to allow an unlimited number of decorator to be added to each core object.  One thing to note is that the interface must remain constant when successive layers are specified using the decorator pattern.

    The decorator pattern hides the core components of the objects inside the decorator object. Trying to access the core object directly would be a problem.

    UML Diagram

    400px-Decorator_UML_class_diagram.svg

     

    Example

    One example is making a pizza ordering system. You can use the decorator pattern to implement a simple pizza ordering system by creating a pizza(component) and a plain pizza(Concrete Component) that is just the base or dough. Then the decoratorPizza(Decorator) which has the plain pizza and other functions. Lastly, the toppings(Concrete Decorators) for your pizza like: mozzarella, the sauce, pepperoni, etc.

    In this example, you have an interface pizza and a plain dough. The decorator then adds the desired toppings to the pizza.

     

    Conclusion

    I chose this particular topic since we are creating a simple web app for scheduling classes. I thought that it was helpful since we might be adding pop up windows to our web app.

    The Decorator Pattern is useful when you see yourself making something that is extensible and where you can interchangeably choose which components/functions you want on your object.  I think that with the decorator pattern, there is a lot of potential when using it. You could create something that has many functionality and is still easily changeable.

    source: decorator pattern

    From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

    The Decorator Design Pattern

    What is the Decorator Design Pattern?

    The Decorator pattern applies when there is a need to dynamically add as well as remove responsibilities to a class, and when the sub-classing would be impossible due to the large number of sub-classes that could result. Also, use it when you want the capabilities of inheritance with sub-classes, but you need to add functionality at run time.

    Intent

    • Attach additional responsibilities to an object dynamically.
    • Decorators provide a flexible alternative rather than making many subclasses to extend functionality.
    • Client-specified embellishment of a core object by recursively wrapping it.
    • Wrapping a gift, putting it in a box, and wrapping the box.

    Discussion

    Say, you are working on a UI and you want to add borders and scroll bars to your windows. You could define the inheritance like… Window class interface, then you have concrete objects WindowWith_Scrollbar, WindowWith_Border etc..  This type of architecture creates a lot of subclasses and not much room for modularity.  It will be hard to change the concrete classes if you want to add some additional functions to them.

    The Decorator pattern suggests giving the client the ability to choose what features they want.  There might be a problem of chaining features together to produce custom objects as well. The solution to such problem is to encapsulate the original object inside an abstract wrapper interface. Both the decorator objects and the core object will inherit from the abstract interface. Then the interface uses recursive composition to allow an unlimited number of decorator to be added to each core object.  One thing to note is that the interface must remain constant when successive layers are specified using the decorator pattern.

    The decorator pattern hides the core components of the objects inside the decorator object. Trying to access the core object directly would be a problem.

    UML Diagram

    400px-Decorator_UML_class_diagram.svg

     

    Example

    One example is making a pizza ordering system. You can use the decorator pattern to implement a simple pizza ordering system by creating a pizza(component) and a plain pizza(Concrete Component) that is just the base or dough. Then the decoratorPizza(Decorator) which has the plain pizza and other functions. Lastly, the toppings(Concrete Decorators) for your pizza like: mozzarella, the sauce, pepperoni, etc.

    In this example, you have an interface pizza and a plain dough. The decorator then adds the desired toppings to the pizza.

     

    Conclusion

    I chose this particular topic since we are creating a simple web app for scheduling classes. I thought that it was helpful since we might be adding pop up windows to our web app.

    The Decorator Pattern is useful when you see yourself making something that is extensible and where you can interchangeably choose which components/functions you want on your object.  I think that with the decorator pattern, there is a lot of potential when using it. You could create something that has many functionality and is still easily changeable.

    source: decorator pattern

    From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

    Documentation Testing

    Documentation Testing

    When I was searching for different types of testing, I found a type of testing that I never heard about, which was documentation testing. I was curious since I only knew documentation that testers/developers added at the beginning of the methods/classes/test cases to give others enough basic information about them. I wanted to know more about this type of testing, therefore, I chose a basic introduction of documentation testing to read. Below was the URL of the post.

    http://blog.e-zest.com/why-is-documentation-important-in-software-testing/

    In this blog, Kirti Mansabdar explained the definition of documentation testing and some common documents that should be used and maintained regularly, the importance of documents. According to her, documentation testing was a non-functional type of software testing. Poor quality documentation showed badly on the quality of the product and vendor. She also provided some advantages and disadvantages of preparing documentation. Some of the advantages were making project testing easy and systematic, saving time and cost, maintaining good relationship with the client, making the client satisfied, etc.

    Kirti said that in many cases, projects could be rejected in the proposal/acceptance phase for lack of documentation. This should be highlighted to get the attention since I thought that being rejected just because of lack of documentation was unworthy. In the beginning of the blog, she mentioned that one of the reasons people did not talk much about documentation in software testing was they did not want to waste time preparing documents. They wanted to spend all their time on the more functional aspects of their jobs. I disagree with them. In my opinion, even though testers knew what they were doing, but their projects would be presented and used by people who knew a little or nothing about the projects. Without documents, it would be hard for others to fully understand what the projects were and how useful they were.

    In some important documents that Kirti recommended to use and maintain regularly, there were some of them that I never heard, never did, and wanted to try when I had a chance, like Test Plan Document, Weekly Status Report, User Acceptance Document. Test Plan Document included testing schedule, team structure, H/W-S/W specification, environment specifications, risk analysis and scope of testing among other points. Weekly Status Report included the status of all bugs and requirements. It could help in improving the quality of the product. This one would be useful for me since I rarely report anything weekly. It was also good to know that these documents could be used as evidence for the delay when having problem regarding product delivery.

     

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

    Post #14

    As a follow up to my previous post about our upcoming group-code-review, I thought I would review another article I found that compares group code reviews to peer code reviews.  “Peer Review vs Group Review: Which Is Best For A Code Review?“, written by Stephen Ritchie, provides an answer to this question as it is often asked by clients in the field.  Ritchie begins by stating that that both methods have advantages over the other, depending on the development team’s particular circumstance.

    Ritchie defines a group code review as a code review in which a portion of the development team comes together to review code while the rest of the team provides feedback for improvement.  He believes that group code reviews engage the individual developer, the team, and the team’s leaders in ways that evoke experience and judgment to find and fix problems.  As I mentioned in the previous post, Ritchie also believes that effective group code reviews let tools perform fundamental review and let the focus of the developer review to be a spotlight on parts of the code that do not utilize the best practices and designs.  Ritchie feels that discussing code, as a group, serves as an excellent transfer of knowledge from the more experienced to the less experienced.  If a group code review is conducted properly, it opens up a healthy dialog between developers about the chosen conventions and why adherence to them is important.  The main advantage of group code reviews is that it allows for a group of developers to learn and grow together, improving relationships and cultivating the transfer of knowledge and experience.  The main disadvantage of group code reviews is that it can be challenging to get all group members up to the same working pace.  Group code reviews can suffer if group members become diverted or distracted.  This can potentially lead to a worsening of relationships among developers.

    Ritchie defines a peer code review as a code review in which one developer’s code is reviewed by another developer.  A pair of developers would meet and one developer would review the code of the other, and provide constructive feedback.  Peer code reviews are similar to group code reviews but their personal nature generally ensures a thorough and properly done review.  The main advantage of peer code reviews is that pairs of developers who conduct peer code reviews have likely collaborated and formed a bond in the past that allows for issues to be better-handled and addressed immediately.  The is also somewhat of a disadvantage in that it necessitates that you have a decent relationship with the person you are reviewing with, if you wish to conduct the review effectively.  A bad relationship between the reviewer and the developer being reviewed can result in a lack of collaboration and dialog and, inevitably, a poor review overall.

    Ritchie believes that, for teams that have many developers with years of experience, it is more efficient to conduct peer code reviews.  This is because the time of identification to resolution of an issue is much shorter, due to the personal relationship between peers.  Ritchie prefers peer code reviews to group code reviews because they quickly improve the developers’ skills while simultaneously making progress in the implementation.

    I agree that peer code reviews are more personal and allow for faster feedback and resolution to issues but I also appreciate the fact that group code reviews bring many resolution strategies and points of view to the table.  For the small projects I have worked on, I have always found peer review to be more effective – but I think that, because larger projects generally require more developers, a group code review is necessary to get all the developers on the same page.  I think that the code we are reviewing could be done by a pair of developers, but I am looking forward to seeing if the group review will provide better solutions and insight.

     

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

    Code Quality: Fighting Primitive Obsession Code Smells

    In this blog post, Anna Makowska talks about primitive obsessions code smells and what you can do to fix them. The author chose to focus on primitive bbession code smell because some smells are harder for developers to detect intuitively.

    “Primitive data types are basic built-in building blocks of a language. They’re usually typed as int, string, or constants. As creating such fields is much easier than making a whole new class, this leads to abuse. Therefore, this makes this smell one of the most common ones.”

    Examples

    • Using primitive data types to represent domain ideas. For example, using an integer to represent an amount of money or a string for a phone number.
    • Using variables or constants for coding information. An often-encountered case is using constants for referring to users roles or credentials (like const USER_ADMIN = 1).
    • Using strings as field names in data arrays.

    Consequences

    • Code becomes less flexible because of use of primitives instead of objects.
    • Primitive data types are much harder to control. As a result, we may get variables that aren’t valid (supported by the type) or meaningful.
    • Primitives are often related to dedicated business logic. Therefore, leaving this logic unseparated may violate the Single Responsibility Principle and the Open/Closed Principle.
    • When data type logic is not separated in a dedicated class, adding a new type or behavior makes the basic class grow and get unwieldy.
    • By using primitives, the developer loses the benefits that come with object-oriented design, like data typing by class name or type hinting.

    Replace Data Value With Object

    • Instead of a set of primitive values, the programmer has full-fledged classes with all the benefits that object-oriented programming has to offer (typing data by class name, type hinting, etc.).
    • There is no need to worry about data validation, as only expected values can be set.
    • When relationship logic extends, it will be placed in one place dedicated to it.

    I chose this resource because it had plenty of good information on the primitive obsession code smell, when it’s going to lead to problems and how to fix that. I learned two more fixes, Replace Type Code With Subclasses, State, or Strategy (patterns) and Replace Array With Object for when “values of a coded type aim to control the behavior of the program.” I felt the content to be quality content from a author who has experience with spotting and fixing code smells. I will use this information in the future, by keeping an eye out for primitive obsession code smells.

    The post Code Quality: Fighting Primitive Obsession Code Smells appeared first on code friendly.

    From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

    Benefits of Using Angular and TypeScript

    What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

    1. Consistency
    2. Productivity
    3. Maintainability
    4. Modularity
    5. Catch Errors Early

    There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

    Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

    Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

    Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

    Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

    I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

    Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

     

    From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

    Blog 7

    Soft Qual Ass & Test

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

    The Testing Show: Episode 43: Machine Learning

    For this weeks blog i will be doing a podcast from The testing show on machine learning, which can be found here.  The podcast starts with a discussion of a recent tech story by facebook on their AI chat boxes developing their own language and having to be shut down. To understand this story the podcast goes into some detail about what machine learning is. The guest on the show Peter Varhol defined it as follows: machine learning works on the feedback principal, which is how we can produce better results by looking and comparing the results produced by the machine learning algorithm to the actual results and then feeding that back in to adjust the algorithm and produce incrementally
    better results. After this they discuss what they think might of happened with the facebook chat bots, they went through multiple views such as being intrigued , to skeptical , to really questioning if the bots actually developed a language at all or just gibberish.

    Although the podcast does not come to some big conclusion , the final view on the topic was the most thought provoking. The last view was disputing if the chat boxes really created their own language , and if so how? In the podcast the hosts were talking about how language is semantic and that it would be impossible right now for a computer to be able to understand semantics ,let alone creating a new language. The host theorizes that the chat bot created a language of gibberish to make up for the fact that it could not fully understand what was being asked of it semantically. I thought this was a really interesting point, i had never considered the semantics of language and shows how far computer scientists have to go for real artificial intelligence.

    In the last part of the podcast we dive deeper into how machine learning works and some of the pros and cons. One pro is that we can set up a series of algorithms and iterative processes to achieve something we simply couldn’t do on our own. The example given here is the Facebook chat bot again, they talk about how even if Facebook released the source code for the bots, the algorithms would likely be to complicated to understand for almost everyone, and so it would be hard to verify the results for the chat bots. As maybe you can see from the example , our pro also becomes our con. This is because once we get what seems like a reasonable result from our machine learning algorithm, it becomes very hard to trace our answer back through the code.

    The last part of machine learning covered in this podcast is the difference between supervised and unsupervised learning. Supervised learning is pretty straight forward we know the result from out training data and try to get a result close to our known result. Unsupervised learning is more difficult to explain, we don’t know the expected result and are just trying to optimize something. The example given for this is airline ticket sales online, the algorithm is built to maximize profits for the airline company. Roughly 3 times a day online ticket sale prices change, there is no exact formula to how the airliners change their prices, the algorithm is simply trying to optimize the amount of money made.

    This was a very interesting listen on a topic which i don’t know a whole lot about, but seems to be the way of the future in tech. I picked this article because it was an interesting topic which comes up all the time in articles and discussion boards and i wanted more information, as well as how to test it. Although the podcast did not get around to talking about how machine learning is tested, there is a second part which was recently released which should go into more detail on that. This first section however gave a good overview on the topic and the issues that may arise, this gives you somethings to think about in terms of how testing will be affected compared to testing a standard algorithm. I enjoyed this article quite a bit and will be listening to the 2nd part to see how to go about testing Machine learning, i will be looking out to see what my expectations for testing using machine learning are before and after listening to part 2 of the podcast.

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