I choose this topic because i wanted to know more about it, how it works and why developers choose to follow this style than our normal JavaScript style. Also to help me understand and do the coding for the duck simulator in typescript on design pattern.

TypeScript starts from the same syntax and semantics that millions of JavaScript developers know today. Use existing JavaScript code, incorporate popular JavaScript libraries, and call TypeScript code from JavaScript.

TypeScript compiles to clean, simple JavaScript code which runs on any browser, in Node.js, or in any JavaScript engine that supports ECMAScript 3 (or newer).

Types enable JavaScript developers to use highly-productive development tools and practices like static checking and code refactoring when developing JavaScript applications.

Types are optional, and type inference allows a few type annotations to make a big difference to the static verification of your code. Types let you define interfaces between software components and gain insights into the behavior of existing JavaScript libraries.

TypeScript offers support for the latest and evolving JavaScript features, including those from ECMAScript 2015 and future proposals, like async functions and decorators, to help build robust components.

These features are available at development time for high-confidence app development, but are compiled into simple JavaScript that targets ECMAScript 3 (or newer) environments.

Examples of typescript

The global variable foo contains the number of widgets present.

Code

console.log("Half the number of widgets is " + (foo / 2));

Declaration

Use declare var to declare variables. If the variable is read-only, you can use declare const. You can also use declare let if the variable is block-scoped.

/** The number of widgets present */
declare var foo: number;

Global Functions

Documentation

You can call the function greet with a string to show a greeting to the user.

Code

greet("hello, world");

Declaration

Use declare function to declare functions.

declare function greet(greeting: string): void;

Objects with Properties

Documentation

The global variable myLib has a function makeGreeting for creating greetings, and a property numberOfGreetings indicating the number of greetings made so far.

Code

let result = myLib.makeGreeting("hello, world");
console.log("The computed greeting is:" + result);

let count = myLib.numberOfGreetings;

Declaration

Use declare namespace to describe types or values accessed by dotted notation.

declare namespace myLib {
    function makeGreeting(s: string): string;
    let numberOfGreetings: number;
}

After learning and observing. I found out that this is way better than then normal javascipting coding. The reason why is say that is because with the typescript , i kind of like dealing with class (objects) like java coding which makes it easier for me. I like how things are organized and it also readable. I guess with this my coding will be javascript/typescript will be fun and cleaned. I really hope pupils enjoy this post and also research more about typescript.

link :: https://www.typescriptlang.org/

https://www.typescriptlang.org/docs/handbook/declaration-files/by-example.html

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

https://addyosmani.com/blog/decorator-pattern/
Design patterns are important for building software. It is equally important to know about for core Java interviews. So, it is always good to have a clear understanding of the various design patterns in Java. The decorator design pattern is a prominent core Java design pattern. In addition, it is used in JDK in IO packages. In the IO package it has the decorated Reader and Writer classes for various settings such as for BufferedReader and BufferedWriter. This blog post examines the decorator design pattern.

The decorator design pattern is used to extend or modify the behavior of an instance at runtime. While inheritance is an extension of class methods, for the decorator design pattern you can choose any single object of a class and modify its behaviour, leaving the other instances unmodified.

The article discusses the decorator pattern as being implemented by constructing a wrapper around an object. This is done by extending its behavior. In the decorator design pattern, you start with an interface. This becomes a blueprint for the class that will contain decorators, which can now contain basic functionalities. The decorator design pattern contains an abstract class which contains the aggregate relationship an attribute type of the interface. The constructor of the class assigns the interface instance to the attribute, which becomes the decorator base class. This class can be extended to contain as many concrete decorator classes with its own methods. Finally, the article gives examples of the implementation of the decorator design pattern as an ice-cream with decorative toppings. For the design pattern you have the basic ice-cream and as much toppings as you would like. So, you have ice-cream as an interface. Simple ice-cream and ice-cream decorators as classes and their inheritance are as much toppings as the developer would like.

I chose this post because it is always important to learn more design patterns. Design patterns helps to organize the code and it helps to make instantiations more efficient. In the case of the decorator design pattern the advantages is that it is more flexible than inheritance. The decorator method provides a more flexible alternative to subclassing for functionality and method extensions. The reason for this is that inheritance adds responsibilities at compile time and run-time. Another advantage is that it allows behaviors to be modified at runtime. This means that the behavior can be modified without going back to the existing code and modifying it. In addition, the decorator method provides a solution to permutation issues since components are wrapped by a number of decorators. Altogether, the decorator design pattern adheres to the principle that I have seen in all of the other design pattern thus far and is my most favorite principle in software engineering that is the principle of being open for extension but closed for modifications. So, I chose this blog post to learn more about design patterns in order to extend my knowledge and to incorporate in my own program for code organizations and efficiency. The decorator design pattern is used in the prominent core Java design pattern. It comes up often in core Java interviews. So, this is a design pattern that is important to learn about.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

https://blog.asana.com/2016/12/7-ways-to-uplevel-your-code-review-skills/
Code review is always my least favorite part of software engineering. Becoming one doesn’t come easy. So, this week we discuss 7 aspects that can help to improve coding review skills. The first is to prioritize the goals of code reviews with the team. It is suggested that all members should know about the primary goals of the project. So, a team should set up a time to meet to discuss the primary goals. The writer’s favorite part of code reviews are the following:
To help learn to negotiate with co-workers, to think like them and adapt to similar coding convention so that the writer can easily navigate and change the code.
To spread knowledge about files and features, and what has changed recently, in case there is a bug in the code, 2 people can help in diagnosing and fixing the problem. No one should have one view of their own code.
The writer’s least favorite part of code review are the following:
Catching bugs. Automated tests and using apps are good ways to see how code actually runs.
Enforcing basic style rules.
My most favorite part of code reviews are the sharing of knowledge and codes with team members. Code sharing allows for a broader view to help improve coding skills. My least favorite part is catching and debugging bugs.
The second recommendation to improve code review skills are to run the app and try playing with the features. Reading code is not the same as interacting with the code and it is unlikely that a programmer will catch most of the bugs from reading codes. Finding bugs through reading takes years of practice. It is better to run tests on the code and to interact with it rather than using your head. Chances are you will catch important cases that would have otherwise be missed.
The third method is visualizing method call hierarchies. This involves drawing and visualizing which methods call which other methods or which objects use which other objects. The key is to quiz yourself. Plain reading is not as effective as committing it to memory and writing it down.
The fourth way to improve code review skills is to do the code reviews as soon as you see the request. Even in large reviews, coders should try to make the first pass as soon as possible. However, code reviews are not always an easy task to do immediately. There may be barriers such as the code has been changed many times. Below are some tips to help speed along the progress:
Set a time limit, about half an hour. Spend the hour mapping out the changes and writing down questions. If not ready, then schedule and commit to a time when you can make more detailed pass and approve or request changes.
The final tip which I thought was very helpful and important when designing software is to keep 2 separate repositories on the machine, one for your own changes and one for changes you are reviewing. This allows your changes to stay in place so that compiling changes made by co-workers won’t destroy it.
I chose this blog post to compare it with my own experiences with software development and code reviews. I agree with the final comment about having 2 separate repositories as it would be easier to recover back files of packages that might have been disrupted by changes with other co-workers or with changes you made yourself.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Today I will be talking about a design pattern known as the observer pattern. In a blog put out by the website javapapers.com, the observer pattern is used when multiple objects depend on the state of one object. For example, Class A and Class B rely on the state of Class C and Class D to run. If Class C is in state 0 and Class D is in state 1, Class A will execute and Class B will not. If Class C is in state 1 and Class D is in state 0, Class B will execute and Class A will not. Class A and Class B need to be aware of the state of Class C constantly, and need to know when there is a change in the state of Class C. We can use do this by using observers for Class A and Class B. However, java does not support multiple inheritances; that being a class can’t inherit from more than one parent class. We can use the observer pattern to create observers for objects, which will help objects be aware of the state of different objects.

The blog uses an example using the relationship between a blog and a subscriber. The blog user subscribes to a blog for updates. When a new blog is added, users will be notified of the new blog. In this case, the user is the observer. The UML diagram for this example points out that a subject can have many subscribers. Both the subscribers and the users have implementation classes, which notify the classes of each other’s states. The implementation classes are “observers” in the UML diagram. The subject implementation observer gets and sets the state of the subject, while the user implementation observer updates to see if there are any new changes to the state of subject.

I selected this article to expand on my knowledge of software design patterns. I think they are useful tools to have, and each one has its ideal uses. The observer pattern is good for classes that are related and depend on each others states to function. I learned how I can implement observers for objects for these types of relationships. Now, instead of having the object looking for updates constantly working to search for updates, the observer will do it for them. This leaves the object totally out of the loop, and is only notified when the observer finds a change in state. I hope to implement this pattern in my future projects, as I think it is a great way to keep code efficient, neat, and organized.

Here’s the Link: http://javapapers.com/design-patterns/observer-design-pattern/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Since we (Me and Dan) are working as a team to build a web app (Remote Team Builder) for our final project in 343 class, I thought to learn how to test web apps would be essential. So, this week I read an article on Software Testing Help site, which was a guide about testing web applications.

As per the author, these are the most common web testing checklists:

1) Functionality Testing

Test for all the links in web pages, database connection, forms used for submitting or getting information from user in the web pages, Cookie testing etc.

Cookies Testing: Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies check for login sessions and user stats after session ends.

Validate your HTML/CSS: If you are optimizing your site for Search engines then HTML/CSS validation is the most important one. Mainly validate the site for HTML syntax errors. Check if the site is crawlable to different search engines.

Database testing: Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality.

2) Usability testing

Test for navigation: Navigation means how an user surfs the web pages, different controls like buttons, boxes or how the user uses the links on the pages to surf different pages.

Content checking: Check for spelling errors. Usage of dark colours annoys the users and should not be used in the site theme. You can follow some standard colours that are used for web page and content building.

3) Interface testing

Check if all the interactions between these servers are executed and errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to the users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to the web server is reset in between?

4) Compatibility testing

Compatibility of your website is a very important testing aspect. See which compatibility test to be executed such as Browser compatibility, Operating system compatibility, Mobile browsing, Printing options.

5) Performance testing

Web Load Testing:  You need to test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, simultaneous connection to DB, heavy load on specific pages etc.

Web Stress Testing: Web stress testing is performed to break the site by giving stress and its checked as how the system reacts to stress and how it recovers from crashes. Stress is generally given on input fields, login and sign up areas.

6) Security testing

Following are some of the test cases for web security testing:

• Test by pasting internal URL directly onto the browser address bar without login. Internal pages should not open.
• If you are logged in using username and password and browsing internal pages then try changing URL options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the URL site ID parameter to different site ID which is not related to the logged in user. Access should be denied for this user to view others stats.
• Try some invalid inputs in input fields like login username, password, input text boxes etc. Check the systems reaction on all invalid inputs.
• Web directories or files should not be accessible directly unless they are given download option.
• Test the CAPTCHA for automates script logins.
• Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.
• All transactions, error messages, security breach attempts should get logged in log files somewhere on the web server.

Although it was a quite a lengthy article, I enjoyed reading it. We may not get time to test every aspect of our web app, but I will definitely keep on eye on the security aspects. In our web app we have a login in screen for the members of a team. I will test the method as suggested in the article to browse internal pages then try changing URL options directly. I think it would be a fun to include CAPTCHA security measures to prevent automates script logins.

Source: http://www.softwaretestinghelp.com/web-application-testing/

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.

With our discussions in class about typescript and java script for use with Web-apps, I believe it is important to discuss the difference between web-apps and native apps and how our knowledge of them can help us decide which one is more preferable. I choose this article by Lifewire because it provides a great compare and contrast of web-apps and native apps.

There has been an ongoing debate over what type of app is better – Web Apps or Native apps. Firstly, I think it is important to distinguish the two. Typically, a native app is an app that is used local on a device. These apps are usually downloaded and installed on the device. For example, the camera app on an android phone or Microsoft word on a desktop computer. While native apps are usually local on a device, Web Apps are apps that are not installed locally on a device.

Let’s take for instance a locally installed app. That app can access almost all of the devices features (if permissions are granted). Snapchat, for example, is an instant messaging app using a smart-device’s internal camera. That is a native app using another native app. A web app only has access to a limited number of the device’s native features. This may seem like a bad thing, however, there are greater benefits to web-apps than you may think

The great thing about native apps is that since they operate specifically on software designed for a particular device, it can be greatly optimized and catered towards that device, thus enhancing the users experience. At the same time, this means whenever a native app needs to be updated, the device needs to keep downloading updates and bug fixes. With a web app, all updates are handled on the back-end, therefore no native changes or downloads need to be made.

Both web-apps and native apps are used everyday, and arguably, they can both be used hand in hand. Web apps can be developed for native apps and native apps can be developed for web apps. Paypal has a web-app in browser, however they also have a native app that can be downloaded and updated. I think as technology progresses, we will see more web-apps as cloud computing seems to be the future. Knowing this, I personally think that web-apps will continue to evolve because they require no user action to update and they do not need to be designed for a specific system, therefore making

Source: (https://www.lifewire.com/native-apps-vs-web-apps-2373133)

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 week’s blog I chose the article titled “Alpha Testing vs Beta Testing.” I chose this article because it covers two types of testing I haven’t read too much about. I also like the comparison type so I can see different situations why I might choose one over the other.

To start, alpha testing is a type of acceptance testing. It’s used to identify all the possible issues in a product before it gets released to users. The idea of this type of testing is to simulate real users by using blackbox and whitebox methods. The article mentions this type of testing is usually done by internal employees in a lab type environment. The overall goal is perform tasks that the typical user will be doing frequently. This testing is done near the end of the software development cycle but before beta testing if beta testing is being done.

Beta Testing is another form of acceptance testing done by real users in a real environment. It’s mainly used to gather feedback and limit product risks before the product gets released to anyone and not just a small testing group. This would be the last type of testing before a final product gets shipped to customers.

While beta testing and alpha testing share some similarities there are some key differences. The first being that in beta testing reliability, security, and robustness are checked which is not true for alpha testing. Another difference is how issues are addressed. For alpha testing it’s not uncommon to make code changes before an official release. With beta testing code changes will usually be planned for future versions after the product is released.  Lastly, with beta testing you are getting feedback from real users and this will usually be a more accurate analysis of how a product will perform over alpha testing.

For larger product firms, a product release will usually incorporate both alpha and beta testing. Below is a typical flow chart of the process.

To clarify, the pre alpha phase would be a prototype where not all features have been completed and the software has not been officially published. The release candidate phase is when any bug fixes are small feedback based changes have been made.

In conclusion, this article was really great comparing alpha and beta testing. It goes into more details with some advantages and disadvantages of the two as well as some entry and exit criteria however this goes beyond the scope of this blog. After reading about these two types of testing I would definitely want to include both in a product release strategy however I would choose beta testing if I could only choose one. I think real user feedback in a real time and natural environment is most valuable before releasing. At the same time it would be easy to argue that terrible feedback in a beta testing cycle could be prevented with prior alpha testing.

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

For this week’s blog I chose an article on the pipe and filter architecture appropriately titled “Pipe-And-Filter.” I chose this article after googling what some of the most common software architectures are and learning that pipe and filter was commonly implemented. This article seemed like a good length with straightforward information and diagrams to help with understanding the material so that is what I chose it.

To begin, this architecture consists of any number of components referred to as filters due to the fact that they filter data before passing it through connectors called pipes to other components. All of the filters work at the same time and this is usually implemented in simpler sequences although is not limited to that.

Above is a simple diagram to show how the architecture flows. It’s important to know that filters can transform the input data from any number of pipes. The pipes pass data between filters however it is unidirectional implemented by a buffer until the downstream filter can process it. The pump is where the data originates such as a text file or I/O device. Lastly the sink is the end target of the transformed data such as a file, database, or output to a screen.

One good example of this architecture would be a Unix program. One program’s output can piped into another program’s input.

Above is a more complex diagram to show how pipe and filter can start to become complex. Different sources or pumps can interconnect data into their respective streams. An application that uses this architecture will typically link all the components together and then spawn a thread for each filter to run in.

One interesting functionality of this pattern is a recursive filter technique. This is implemented by having a filter inside of another filter.

One common issue with this type of architecture concerns what kind of data types are allowed in a certain pipe. If only one type is allowed, filters need to parse for this which can slow an application down. You may also limit yourself to what pipes can connect to which filters.

After reading this article I have a good idea of pipe and filters main concepts. One thing I wished the article had discussed more in detail would be specific implementations of this architecture. I can’t directly see how I would need to use these concepts in any of the coding I’ve done so far. I can see a general use for this model for an application that takes in a lot of raw data and needs to output it in a useful format for making business decisions. In summary this was a well written article but I need to do some further reading on implementation examples.

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