This week, I will be preparing a tutorial on the Observer Design Pattern and I figured I could assist my own understanding of the pattern by writing a blog post to accompany it.  This post will be a summary of the Observer pattern as it is described on this page of the Object Oriented Design website.  The motivation behind the Observer pattern is the frequent need of objects, in object oriented programming, to be informed about the changes that occur in another object.  An exemplification of this concept in the real-world can be imagined as a stock system which provides data for several types of client; the subject(stocks server) needs to be separated from its observers(client applications) in such a way that adding a new observer would be transparent to the servers.

The intention of implementing the Observer pattern is to define a one-to-many dependant relationship between objects so that when an object’s state is altered, its dependants are notified and updated automatically.  The Observer pattern is effectively adhered to with the implementation of 4 classes:

• Observable/Subject(GOF) – interface or abstract class; defines operations for attaching/de-attaching observers to client
• ConcreteObservable – concrete Observable class; maintains state of an object and notifies Observers when a change occurs
• Observer – interface or abstract class; defines notification operations
• ConcreteObserverA, ConcreteObserver2, etc. – concrete Observer implementations

How it Works:

• ConcreteObserverable object is instantiated in main framework
• ConcreteObserver objects are instantiated and attached to ConcreteObservable object via methods defined in the Observable interface
• ConcreteObserver objects are notified each time the state of the ConcreteObservable object is changed
• ConcreteObservers are added to the application by simply instantiating them in the main framework and attaching them to the ConcreteObservable object

This allows for classes, that are already created, to remain unchanged.

The Observer pattern is applicable in situations where the change of a state in one object must be reflected in another object without keeping the objects coupled, and in situations where the main framework needs to introduce new observers with minimal changes.

The Observer pattern is often used, in conjunction, with other design patterns:

• Factory – A Factory pattern can be utilized to create observers so no changes will be required in main framework
• Template – An Observer pattern can be utilized to make sure that Subject state is self-consistent
• Mediator – A Mediator pattern can be utilized in cases of many subjects and many observers

The Observer pattern is so well-known because its implementation has proven to be quite powerful in event handling systems of languages such as Java and C# and in the model-view-controller architectural pattern.  I am excited to put together a tutorial on how to use this pattern and I believe that having a good grasp on its motivations and intentions will aid me in future if I ever consider using it.

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

Link to blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

Throughout the time the I spent as an individual when it comes to coding, it takes me awhile to write the perfect code that I need for my college homework assignments. Sometimes, I would try and write code during my free time if I’m bored and implement a certain design that I would attempt to do. After I finish writing the code, I feel that I could’ve done it more quickly and efficiently without having to write so much code, or try to edit and fix the code so many times. I know that I have a tendency to repeat code and make it more difficult than it already was. As I’m trying to improve on being an efficient programmer I know that I have to stop myself from repeating code, and to keep it simple when it comes to a specific design pattern while fulfilling the necessary specifications.  In this blog written by Jonathan San Miguel, he identifies three principles to keep the life of a developer simple as possible. These principles are KISS, DRY, and YAGNI.

KISS: This acronym stands for “Keep it Simple, Stupid!” It basically means that try to keep your code clean and simple as possible. The simpler the code is, the simpler it’ll be to maintain it in the future in case if you want to edit it. Miguel also adds “avoid using fancy features from the programming language you’re working with only because the language lets you use them…use them only when there are perceptible benefits to the problem you’re solving.”

YAGNI: This acronym stands for “You Aren’t Gonna Need it!” This means that as the programmer, you need to focus on your specification and write the code that does that particular task without adding anything extra such as features you think you might need in the future.

DRY: This acronym stands for “Don’t Repeat Yourself!” Try and prevent yourself from writing code that is similar to others that you previously wrote. “Maintain the behavior of a functionality of the system in a single piece of code” as Miguel noted in his blog. This principle is useful especially in big applications where they are constantly maintained, changed, or extended by many programmers.

Among these three principles, I think I need to focus on the DRY principle the most because I do have the tendency to repeat code. If I can improve on that, I’ll be golden, and coding won’t be that much difficult for me. Jonathan San Miguel briefly explained that main points of each principle, which made it easy to understand. He also gave his advice on some of the principles and identified which principle was useful for certain circumstances. Understanding these three principles will help me in my future career as a video game developer because when I write the code for video games, I’ll have to condense and simplify as much as I can within the design so the software can run smoothly and efficiently. It will also help me save time to do other things with the code too.

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

I decided to write this week’s blog on Observer Design Patterns because I am going to be writing a tutorial on this in class next week. I chose a tutorial posted by author Santosh Kumar on the blog “WalkingTechie”. I chose this blog about the Observer Design Pattern because Kumar gives an in-depth explanation of what an Observer Design Pattern is, how it’s implemented and gives UML and code examples of it which I found to be extremely helpful.

Kumar starts by giving a definition for the Observer Pattern, which he states “defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.” He also states that this is a part of the Behavioral Design Pattern.

Kumar furthers explains the Observer Design Pattern by giving a real-world example with a newspaper subscription. There are two variables – Subject and Observer. In this example, the newspaper publisher is the subject and goes into business by publishing newspapers. The observer is the subscriber who subscribes to a particular publisher, and everytime a new edition comes out it gets delivered from them. A user can unsubscribe which will stop papers from coming.

Kumar then implements the Observer Design Pattern. He defines a Subject interface that has a method to register, remove/unregister user and notify users when the object changes state. There is also a DisplayElement interface that has a display method, and an Observer interface and all concrete classes – BinaryObserver, OctalObserver, and HexObserver.

After constructing a UML diagram, Kumar goes through the code implementation step by step.

In the first step, the Subject interface is created. This contains the registerObserver and removeObserver and notifyObserver methods.

In the second step, the Observer interface is created. This includes the update method,

In the third step, the DisplayElement interface is created, which has the display method.

In the fourth step, a concrete class DecimalData is created and implements the Subject interface. Then a concrete class is created that implements the Observer and DisplayElement interface. And finally, the ObservePatternDemo class is created to use DecimalData and concrete objects to test observer design patterns.

I enjoyed Kumar’s blog explaining the Observer Design Pattern because he went in depth by defining the Observer Design Pattern, giving a real-world example, and implemented it by creating a java project. This really helped me understand the Observer Design Pattern more and it will come in handy when I do my tutorial on it.

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

Test-Driven Development

This week, I choose Test-Driven Development (TDD) as my topic. After reading many articles, I realized that I only knew a little bit about it, which was the part that I needed to create test before writing functional code. Therefore, I thought that I should research more about it through an introduction article. I chose this article below because it had detailed information about TDD. Below was the URL of the article.

http://agiledata.org/essays/tdd.html

In this article, Scott Wambler explained the definition of TDD, the two levels of TDD, the advantages and disadvantages of TDD, the importance of documentation, the Test-Driven Database Development, the Agile Model-Driven Development, the myths, and misconceptions about TDD. He also provided the adoption rates of TDD and a list of TDD tools.

The basic idea of TDD is dividing the coding process into smaller steps: writing one test first for a small bit of corresponding functional code at a time. According to Scott, taking TDD approach required great discipline because it was easy to “slip” and write functional code without first writing a new test. I agreed with him, since I still sometimes forgot creating test first when coding. There were two levels of TDD: Acceptance TDD (ATDD) and Developer TDD. The goal of ATDD, also known as Behavior Driven Development (BDD), was to specify detailed, executable requirements for the solution on a just in time basic. Developers only needed to write acceptance test and enough functional code to fulfill that test. The goal of developer TDD, or simply called  TDD, was to specify a detailed, executable design for the solution on a just in time basic. Developers only needed to write developer test (unit test) and enough functional code to fulfill the test. Developers could apply both levels or one of them for their projects. I usually applied developer TDD for my projects, therefore, I would consider using the other level as well.

According to Scott, there were three challenges that made Test-Driven Database Development (TDDD) not work as smoothly as application TDD: the lack of tool support, the lack of motivation in taking a TDD approach, and the popularity of model-driven approach. I understood the challenges that TDDD had when it was a “new” approach in many data professionals’ eyes. In my opinion, if we could overcome the lack of tool support, the situation would be better. With enough tool support, we could encourage people to try taking this approach.

Scott also said that TDD worked for both small projects and “real” projects. He used his experience and Beck’s report to support for his statement. Personally, I doubted that I could even use it for “real” projects, since the adoption rates of TDD (mentioned in the article) was not high. Moreover, most of my previous partners did not even use TDD for our small projects. Therefore, it might not be useful right now for me, but I would consider it in future.

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

In the blog post Common TypeScript Error Messages, Sarah Higley provides examples of several common error messages in TypeScript and details how to fix them. The potential issues demonstrated are as follows:

• Type fails to narrow
• Flexibly typing objects
• Third-party libraries and ambient type declarations
• Conflicting function overloads
• <any> or as any

One of the more simple errors occurs when trying to assign a number to a unique type:

• Type ‘number’ is not assignable to type ‘Answer’.

In order to avoid this error, you must simply explicitly type it when its created

const answer: Answer = 42;

or cast it when it’s used.

const result: Answer = answer as Answer;

One of the more complicated errors and potentially more time-consuming to figure out involves a missing declaration file when using third-party libraries, from which not all will necessarily be written in TypeScript. The error looks something like this:

• Could not find a declaration file for module ‘moduleName’. ‘/path/to/moduleName/lib/api.js’ implicitly has an ‘any’ type.

This can be solved by finding the library you want to use and install it.

She also describes how the overuse of <any> could end up causing errors and that while type casting is powerful because it forces the compiler to interpret the value as the provided type, it’s dangerous because you will no longer see type errors when you missed something.

The reason I chose this particular resource because we’re going to be using TypeScript for our final project so it’ll be useful to know common TypeScript error messages and some of their potential solutions as it’s likely we’re going to be running into these errors in the near future.

As I haven’t done much programming at all in TypeScript yet, I wasn’t able to use this blog to solve any issues that I was running into. But if I were to run into any of these errors in the future, I would be able to save a lot of time compared to if it was my first time encountering the problem. Also, I learned how to cast variables, how to use index signatures and the pros and cons of using them (greater flexibility at the cost of reduced control), how to install third-party JavaScript libraries, how to avoid conflicting function overloads, and to avoid using <any> or “as any” for everything, because even though it could turn out fine there’s a high likelihood that something will end up breaking.

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

Software and technology continues to grow at increasing speed and developers must grow with it. This week i read the article “The new normal for software development and testing” on the stickyminds blog. This article talks about the ever changing world of software development and testing, and the new normal for development and testing in this digital age of agility and continuous integration and deployment.

The article is broken up into a few a sections with the first one being “Development and testing are a team sport“. Development and is not just for developers and testing is not just for testers any more. The article talks about the increasing role of developers and testers working together through out the product lifecycle. This is also something we have touched on in class and seems to be a trend in the field. The next section “Data and analytics are now playing an increasing role” which talks about the importance of data and analytics in development and testing. Analytics can be used to affect the whole development lifecycle , from development and testing , to integrating and deployment.

“TestDev thinking is pervasive” this next section was similar to the first one regarding team work. This section talks about traditional roles becoming more collaborative with testers advising the development team from early on and vice versa. Also talks about how those with experience are contributing to the automation of development , testing , and release for the whole project. “Testing in production is a frequent practice”  this next section talks about why today we must test in production. As systems grow much larger it is impossible to emulate the real world in test cases which leaves us with no choice but to test in production. As a result new features can be added to the code but not enabled, allowing the team to control the exposure to new or modified code.

“Deeper skill sets are a requirement” in this section it explains that those in the development require more analytical knowledge and deeper technical skills are traditional roles become more blurred.“Automation is pervasive” extensive automation yields consistency and repeat ability. This allows the team to focus on more technically advanced areas, automated testing dominates the teams and environments that are deploying frequent updates and changes. “Near real-time measures and metrics are expected” with most of today’s lifecycle tools , we can produce real time information and data very quickly. The last section “The tolerance for risks may change” talks about quality engineering.  There are now more ways to avoid defects , or to apply small changes in batches to limited users and roll changes back if there are errors found.

I though that this article was a pretty interesting read although it might have been a little broad, i would have liked for them to include more details or talk longer about certain subjects. A lot of the things that were talked about in the article i feel like we have discussed in class, which i thought was nice to see. My big take away from this article was the blurring of traditional roles in the development fields and how people have to work together much closer now. This is something we talked about in class early on and it was interesting to read another perspective on the matter. In conclusion i think that i have been exposed to the information of this article already through the Computer science program but it was nice to get another view on the matter as well as positive reinforcement that i am on the right path.

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

In the blog post Common TypeScript Error Messages, Sarah Higley provides examples of several common error messages in TypeScript and details how to fix them. The potential issues demonstrated are as follows:

• Type fails to narrow
• Flexibly typing objects
• Third-party libraries and ambient type declarations
• Conflicting function overloads
• <any> or as any

One of the more simple errors occurs when trying to assign a number to a unique type:

• Type ‘number’ is not assignable to type ‘Answer’.

In order to avoid this error, you must simply explicitly type it when its created

const answer: Answer = 42;

or cast it when it’s used.

const result: Answer = answer as Answer;

One of the more complicated errors and potentially more time-consuming to figure out involves a missing declaration file when using third-party libraries, from which not all will necessarily be written in TypeScript. The error looks something like this:

• Could not find a declaration file for module ‘moduleName’. ‘/path/to/moduleName/lib/api.js’ implicitly has an ‘any’ type.

This can be solved by finding the library you want to use and install it.

She also describes how the overuse of <any> could end up causing errors and that while type casting is powerful because it forces the compiler to interpret the value as the provided type, it’s dangerous because you will no longer see type errors when you missed something.

The reason I chose this particular resource because we’re going to be using TypeScript for our final project so it’ll be useful to know common TypeScript error messages and some of their potential solutions as it’s likely we’re going to be running into these errors in the near future.

As I haven’t done much programming at all in TypeScript yet, I wasn’t able to use this blog to solve any issues that I was running into. But if I were to run into any of these errors in the future, I would be able to save a lot of time compared to if it was my first time encountering the problem. Also, I learned how to cast variables, how to use index signatures and the pros and cons of using them (greater flexibility at the cost of reduced control), how to install third-party JavaScript libraries, how to avoid conflicting function overloads, and to avoid using <any> or “as any” for everything, because even though it could turn out fine there’s a high likelihood that something will end up breaking.

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

Soft Qual Ass & Test

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

Continuing with series of articles written by James Sugrue, taking each design pattern one by one, this week I read about the Facade Pattern.  Since Facade has some similarities with the Adapter, so it’s a logical next step in for me to know about the differences between the two design patterns.

I am really starting to like Sugrue’s “In the Real World ” part more as it helps me to visualize the design pattern. The example he provided for the facade Pattern is about Operating Systems. We don’t see all the inner workings of our computer, but the OS provides a simplified interface to use the machine. Another example he provides is about the buildings architecture as: buildings also have a facade – the exterior of the building. In architecture, the facade of a building is often the most important from a design standpoint, as it sets the tone for the rest of the building.  In a nutshell, a Facade aims to make things look cleaner and more appealing.

Like the Adapter pattern, Facade is known as a structural pattern, as it’s used to identifying a simple way to realize relationships between entities. The definition of Facade states: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

The UML diagram definition of the Facade pattern is given below:

In the diagram all we’re really doing is insulating client from the subsystem. Like the adapter pattern, the Facade can be used to hide the inner workings of a third party library, or some legacy code.  All that the client needs to do is interact with the Facade, and not the subsystem that it is encompassing.

As the concept behind facade is to simplify an interface, service oriented architectures make use of the facade pattern. For example, in web services, one web service might provide access to a number of smaller services that have been hidden from the caller by the facade. Similarly, a typical pattern in OSGi bundles is to provide an interface package that is exposed to users of the bundle. All other packages are hidden from the user.

As per the author Sugrue, by introducing the Facade into our code, we will be hardwiring subsystems into the Facade. This is fine if the subsystem never changes, but if it does, our Facade could be broken. Therefore, developers working on the subsystem should be made aware of any Facade around their code.

After reading the article, I came to conclude the main key difference between Facade and Adapter design pattern is that: Facade defines a new interface, whereas Adapter uses an old interface. Adapter makes two existing interfaces work together as opposed to defining an entirely new one. I found the Facade can be implemented to produce a simpler interface, whereas the Adapter to design to an existing interface.

I will definitely be using one of these design patterns, when I need to link two or more interfaces.

Source: https://dzone.com/articles/design-patterns-uncovered-1

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

More companies are gravitating towards practicing continuous development. When it comes to a DevOps and delivery model where software is constantly being developed, it is important to know that there’s is a difference  between test automation and automated testing.  Automated testing is the act of conducting tests via automation as opposed to doing them manually. Test automation is automating the process of tracking and managing different test. in this article, Kyle McMeekin explains how test automation is a huge when it comes to continuous testing.

If something stalls or break down during the development pipeline, this can drastically delay the delivery of the following releases. This is a roadblock in a continuous testing environment because speed and consistency is imperative to support a continuous testing model as McMeekin describes. Test automation eases the burden of tracking which environments have deployed new code, when each piece needs testing and how those requirements integrate back into the moving process of continuously delivering software; it does all that through automation leave more time for testers. The extra time can be focused on creating effective test cases to ensure the quality of the software since they’re no longer bogged down in managing all the minutia of testing needs. Continuous development and DevOps are becoming the norm and so will continuous testing. with the help of test automation, managing the changes that comes with injecting testing throughout the entire development pipeline can much easier.

https://www.qasymphony.com/blog/test-automation-automated-testing/

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