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.

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.