Currently in class we are learning about the tools and functionality of Angular. Angular is a JavaScript based open source web application framework. It is currently being maintained by Google and some other developers. Angular is open source which attracts many users and continually increases the framework’s growth in popularity. Recently, we have seen just this. Developers are choosing Angular because of its great framework and because it enables Progressive Web Applications. Progressive Web Apps (PWAs) is a term that is being universally accepted by developers across the world. It is a way of creating the best web and mobile apps and taking advantage of the most recent technologies in order to make for more efficient and fast web apps. Google has been leading the initiative for Progressive Web Apps by dedicating their design philosophy behind and distributing public data and toolkits in order to help people get started on their web apps as well. I chose this article because I think it is a great example of how Angular is a great framework to work with because it is forward thinking relative to Progressive Web Applications. It will also help further my understanding of Angular and allows me to see the greater benefits of the framework.

Developers want their apps to be more efficient and they also want them to be scalable. This goes for both desktop and mobile apps. By creating web apps that are user friendly  and provide the scalability that allows multiple types of users to interact with it, you can create a very successful platform because it gives users a reason to keep using your app. Angular is great because it is an open-source framework that has a ton of support for it.

Angular has gone through many great changes that improve its functionality, sustainability, and reliability. These are also the main keys of a Progressive Web App, which is why a lot of developers tend to like it. The first version of AngularJS released in 2012. Until this time, no one has ever really seen a web app infrastructure that was this reliable and easy to understand. Angular has the ability to reduce boilerplate and also greatly improved code testability. Angular then make a great leap in 2014 with the team’s announcement of Angular 2. Angular 2 was the newest version of Angular and it was written with Microsoft’s superset of JavaScript and TypeSript. As you can imagine, these language are two very popular and easy languages. Angular 2 was also focused on being more compact and extremely fast.

As we can see, Angular 2 is becoming the fastest growing environment for web app development upon many developers. This affects me personally because Angular is a great tool to utilize when designing and planning out Web Applications. I also learned that the future of Progressive Web Applications is quickly evolving and how Angular 2’s infrastructure is a great resource to consider. In the future, I hope to expand my experience with Angular and wish to apply that knowledge towards the development of reliable and easy to use web apps.

Source: https://jaxenter.com/angular-progressive-web-apps-2018-139076.html

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.

While researching AngularJS for the final project, I came across a really useful blog post written by Todd Motto, owner of Ultimate Angular, entitled “Ultimate guide to learning AngularJS in one day”.  I was intrigued by this post because it contains a section solely devoted to defining the terminology that is commonly-used in AngularJS development, which I found to be incredibly helpful.  In this blog post, I will reiterate the definitions of the most important terms, in hopes that it will aid me in the development of my team’s application.

The article begins by defining what exactly AngularJS is and what it is used for.   Motto defines AngularJS as a “client-side MVC/MVVM framework built in JavaScript, essential for modern single page web applications (and even websites)”.  MVC is short for Model-View-Controller, and MVCs are used in many programming languages as a means of structuring software.  Model refers to the data structure behind a specific portion of an application, usually ported in JSON; View refers to the HTML and/or rendered output of an application.  By using an MVC, you’ll pull down Model data which updates your View and displays the relevant data in the HTML; Controller refers to a mechanism, within an application, that provides direct access from the server to the view so that data can be updated on the fly via communication between the server and client(s).

Motto then explains how to set up an AngularJS project with the bare essentials.  The essential elements that make up an AngularJS application are a definition, controllers, and binding and inclusion of AngularJS within an HTML file.

Controllers, as defined by Motto, are the direct access points between the server and view that are used to update data on-the-fly .  The HTML of an AngularJS application should contain little to no physical text or hard coded values – this is because all of that data should be pushed into the view from a controller.  Web-applications should be as dynamic as possible and, by pushing values to the view from a controller in the back-end, we can achieve this.  Motto then emphasizes that Controllers are to be used for data only, and creating functions that are used in communication between the server and JSON.

Directives, as defined by Motto, are small pieces of templated HTML that should be used multiple times throughout an application’s development.  Directives are the easiest way to push data into the view.  Directives consist of a list of properties, including: restrict (restriction of element’s usage), replace (replaces markup in view that defines directive), transclude, template (allows declaration of markup to be injected into the view), templateURL (similar to template but kept in its own file).

Services, as defined by Motto, are stylistic design patterns.  Services are used for singletons, and Factories are used for functions.  Filters are used in conjunction with arrays to loop through data and filter specific findings.

Two-way data-binding, is a full-circle of synhronized data; update the Model and it updates the View, update the View and it updates the Model.  This implies that data is kept in sync without issue.

A lot of the results of my research into AngularJS, at first, were of no use because I had little understanding of the terminology and concepts described in them.  I believe that this post gave me a good understanding of the fundamental concepts of AngularJS and I now feel more confident as I continue development of my own application.  I will likely refer back to this article as I make progress in my project and, inevitably, conduct more research.

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://thinkapps.com/blog/development/what-is-code-review/

In this blog written by Dario Macchi, Macchi explains what is code review and why it necessary to do. He identifies what it is, its purpose, What is peer review, what do peer reviewers look for, what is an external review, what do external reviewers look for, and a few scenarios on what should code reviewers do if something goes wrong or if something is missed within the the code review process.

Code Review: is systematic examination … of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.”

Purpose: to validate the design and implementation of features within the code. Macchi identifies that there are two levels of code Review. These are the peer review and the external review levels.

Peer Review:  focused on functionality, design, implementation, and usefulness of proposed fixes for stated problems. Macchi explains why it is neccessary to perform a peer review within his company because in his company, they expect developers to talk to each other about their design intentions and receive feedback throughout the design and implementation process. Macchi’s real life experience gives us an example about the working field of software development and testing and how peer review is necessary. Peer Reviewers look for feature completion, potential side effects, readability and maintenance, consistency, performance, exception handling, simplicity, the reuse of existing code, and test cases.

External Review: addresses different issues and focuses on how to increase code quality, promote the best practices, and remove “code smells” or poorly written code. This review process looks at the quality of the code itself and its effects on the overall project. External reviewers look for readability and maintenance, coding style, and code smells.

A scenario that Macchi illustrates is “What is an external reviewer misses something?” The answer he gives is that we do not expect the external reviewer to make everything perfect. There is always something that would be missed. In this case, it is better to have more than one external reviewer. Another set of eyes always helps.

I chose this blog because I wanted to know the right process on reviewing code. I also chose this blog because it relates to my Software Quality Assurance and Testing Class since I was given an assignment to review code with my group of classmates which emulates the peer and external review process and emulates the real life workplace. Macchi definitely outlines the aspects of code review very well when he identified the two levels which were peer review and external review. Knowing code reviews will definitely help me apply myself in the future to many software development and testing jobs as well as my video game development career because there is always a 100% chance that I will review code with a team of other programmers no matter where I work at, especially when it comes to creating video gaming software.

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.

Code Coverage

“Did my tests cover all the code?” – this would be a question that absolutely popped up in testers’ mind often when they were writing their tests. Code coverage could answer this question for them. Code coverage helped testers understand how much of their code was tested. Since I had not used any code coverage tools before, I thought that it would be a good idea to start learning about them through an introduction post. Below was the URL for the post.

https://www.atlassian.com/continuous-delivery/introduction-to-code-coverage

In this post, Sten Pittet, who had been in the software business for ten years in various roles from development to product management, introduced the definition of code coverage, the common metrics in the coverage reports, a tip to choose the right tool for different projects. He also discussed about what percentage of coverage that testers should aim for. Moreover, he thought that testers should focus on unit testing first, use coverage reports to identify critical misses in testing, make code coverage part of their continuous integration flow.

Sten mentioned a few metrics that testers should pay attention to when reading coverage reports They were function coverage, statement coverage, branches coverage, condition coverage, line coverage. Function coverage showed how many of the functions defined had been called. Statement coverage showed how many of statements in the program had been executed. Branches coverage showed how many of the Boolean sub-expressions had been tested for a true and a false value. Line coverage showed how many of lines of source code had been tested. The example given in the post helped me understand the terms easier.

In Sten’s opinion, 80% code coverage was a good goal to aim for. Trying to reach higher coverage might turn out to be costly, while not necessary producing enough benefit. He also said that it was normal to have low coverage for the first run, and testers should not feel pressure to reach 80% coverage right away. To be honest, I really surprised that he only recommended 80% coverage. But when I thought harder, it made sense that getting higher coverage might be costlier, less benefit since real-life projects were usually bigger than school projects. He also highlighted that testers should write tests based on the business requirements of the applications rather than write tests that hitting every line of the code.

Furthermore, Sten emphasized that good coverage did not equal good tests. Code coverage tools could help testers understand where they should focus next, but they would not tell if their existing tests were robust enough for unexpected behaviors. Therefore, beside achieving great coverage, testers should have a good robust test suite and verify the integrity of the system. I agreed with him. Looking at his example, I could see clearly how bad it was if we only relied on the tools to write tests. Beside information about code coverage, I could apply his advice whenever I wrote tests.

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

Link to blog: https://blog.ngconsultant.io/learn-angular-software-enginner-patterns-architecture-4836ef304b40

In this blog, Tomas Trajan gives his insight about what differentiates Angular from other frameworks. From the given title of his blog “How does Angular teach you to be a better Software Engineer?” he highlights some of the key characteristics of using the Angular framework. In his blog, he organizes his argument into a few aspects about considering Angular.

First, Trajan briefly gives a summary of his experience as a software engineer, taking part in a few software engineering interviews by being both the interviewer and the interviewee. He claims that along with him and his colleagues, there have been many talented front-end developers. Next, Trajan explains the differences between a developer vs. an engineer and how to set yourself apart from the rest of the software developers/engineers by learning frameworks and libraries.

Trajan states that “Registering and cleaning up of click handlers to prevent memory leaks by hand can be quite tedious and error prone activity.” Since we don’r want to spend our time dealing with everything on the lowest level, it makes sense. Trajan also states that “What we want is to abstract away everything unessential so that we get to a level where we can focus on what really matters – delivering useful features to our users – while still preserving flexibility to get our hands dirty when necessary. ” This goes back to the acronym YAGNI since as a programmer, you don’t need to include things or abstract things that you think you may need.

According to Trajan, Angular is an opinionated framework that can teach you many of the industry’s best practices. It also helps you to adopt the mindset to implement nontrivial web applications. “Angular has a concept of ‘Module’ which can group and hide (encapsulate) its internal parts while clearly defining interface with imports /exports for the outside world. This can significantly reduce the amount of code you have to read and understand before you can see a big picture of the particular codebase because you don’t have to deal with unnecessary details. It will make you ask yourself questions about what functionality should you expose when creating a new module.”

I chose this blog because it gives an overview about how and why Angular is good framework to use, especially in terms of working with software. I’m also getting to know how to use it in my Software Design Class, which also sparked my intention on knowing a little bit more about Angular in the general sense. Trajan gave his good insight about Angular and provided his own experience on how it would be efficient in knowing how to use frameworks such as Angular. His brief explanations gave me the understanding on why Angular is great to work with. Angular will definitely help me in my future career as a video game developer because it is a good framework to grasp concepts about abstraction, import/exports, and modules.

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.

In this blog post, Erik Dietrich goes over creating a code review checklist. If you were to Google “Code review checklist”, the author lists results that may show up:

• Does every method have an XML comment?
• Do classes have a copyright header?
• Do fields, methods, and types follow our standard naming convention?
• Do methods have too many parameters?
• Are you checking validity of method parameters?
• Does the code have “magic” values instead of named constants?

He then goes on to list two problems with going through a sometimes lengthy checklist:

• You can’t keep 100+ items in your head as you look at every method or clause in a code base, so you’re going to have to read the code over and over, looking for different things.
• None of the checks I listed above actually require human intervention. They can all be handled via static analysis.

His suggestion for stream-lining the process of going through a big checklist is to automate the easy stuff. “Get static analysis tools that developers can install in their IDEs and run prior to delivering code, which will flag violations as errors or warnings. Get static analysis tools that run on the build machine and fail the build for violations.”

Code Review for the Important Stuff

The author lists an example checklist for a code author:

• Does my code compile without errors and run without exceptions in happy path conditions?
• Have I checked this code to see if it triggers compiler or static analysis warnings?
• Have I covered this code with appropriate tests, and are those tests currently green?
• Have I run our performance/load/smoke tests to make sure nothing I’ve introduced is a performance killer?
• Have I run our suite of security tests/checks to make sure I’m not opening vulnerabilities?

The author lists an example checklist for a code reviewer

• Does this code read like prose?
• Do the methods do what the name of the method claims that they’ll do? Same for classes?
• Can I get an understanding of the desired behavior just by doing quick scans through unit and acceptance tests?
• Does the understanding of the desired behavior match the requirements/stories for this work?
• Is this code introducing any new dependencies between classes/components/modules and, if so, is it necessary to do that?
• Is this code idiomatic, taking full advantage of the language, frameworks, and tools that we use?
• Is anything here a re-implementation of existing functionality the developer may not be aware of?

I chose this resource because it had very useful information on code review, which ties into QA. I feel the content of the article is very informational and useful to my future career. It is a good starting point for making sure you have thoroughly checked the quality of your code and automated tests are only going to increase in use, so it makes sense to automate what you can.

The post Creating Your Code Review Checklist 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.

So for this week I have decided to read “Brief Introductions to Design Patterns” from the Technical Blog by Future Processing. The reason I have chosen this blog is because I want to have a simple, clear understanding of the design patterns. It will help in which pattern should I utilize mostly for the rest of the patterns to implement easily after using it.

This blog post basically goes over selected patterns using the division that was proposed by the Gang of Four. The division goes from Creational patterns, Structural patterns, and Behavioral patterns. For creational patterns, they are supposed to prevent from occurring problems and introduce more control over creating objects. The three selected patterns from Creational are Singleton, Factory Method, and Abstract Factory. Singleton provides global access to at most one given class references, Factory Method provide an interface to generate objects, and Abstract Factory provides an interface for creating groups of objects without exact implementation. For Behavioral patterns, they are meant to introduce flexibility to solutions connected with inter-objects communication. The two selected patterns from Behavioral are Observer and Strategy. Observer is used to inform the group of objects to change the state of another specific object while Strategy is used to isolate algorithms, encapsulate them, and make them interchangeable. Structural patterns are to facilitate the operation and design applications through finding an easy way to realize dependencies between entities. The two selected patterns from Structural are Facade and Adapter. Facade is a simple pattern that makes code more legible and comfortable to use by stitching intricate references. Adapter seems similar to Facade, but is to introduce a new interface that hides the previous one.

Based on the contents of this blog, I would say this was a very intriguing read on the take of the design patterns. The author provided some UML diagrams and code written in a variety of programming languages to show each of the differences from the patterns. It was simple and easy to follow once looked closely. What I did before to understand the design patterns was that I tried to stick with only one programming language which was Java and implement each pattern in a way to utilize in future practice. It has helped me understood some of the patterns that was confusing at first with glance of the UML diagrams.

What I learned from this blog about certain design patterns is that the Singleton pattern should not be used too carelessly as it breaks two principles of SOLID and is problematic when implementing in multi-threaded environment. The idea I got from this blog is that while Singleton Pattern might be helpful in some ways, it is not what should be used every time before utilizing the other patterns.  For future practice, I shall try to use the Façade Pattern more often as it will help in making better designed API and will give a better start that the other patterns can be utilized easily.

Link to the blog: https://www.future-processing.pl/blog/design-patterns/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

The article this blog post is written about can be found here.

I decided this week to research the Law of Demeter, also known as the principle of least knowledge. I chose this article specifically to write about because it provides a source code example in Java, it gives examples of the sort of code that the Law of Demeter is trying to prevent, and it explains why writing code like that would be a bad idea.

The Law of Demeter, as applied to object-oriented programming, is a design principle consisting of a set of rules about which methods an object should be able to call. The law states that an object should be able to call its own methods, the methods of arguments that are passed to the object as parameters, the methods of objects created locally, the methods of objects that are instance variables, and the methods of objects that are global variables. The general idea behind it is that objects should know as little as possible about the structure or properties of anything besides itself. More abstractly, objects should only talk to their immediate friends, not to strangers. Adhering to the Law of Demeter creates classes that are loosely coupled, and it also follows the principle of information hiding.

The sort of code that the Law of Demeter exists to prevent are chains of function calls that look like this:

objectA.getObjectB().getObjectC().doSomething();

The article explains that this is a bad idea for several reasons. ObjectA might get its reference to ObjectB removed during refactoring, as ObjectB might get its reference to ObjectC removed. The doSomething() methods in ObjectB or ObjectC might change or get removed. And since your classes are tightly coupled when you write code like this, it will be much harder to reuse an individual class. Following the law will mean your classes will be less affected by changes in other classes, they’ll be easier to test, and they will tend to have fewer errors.

If you want to improve the bad code so it adheres to the Law of Demeter, you need to pass ObjectC to the class containing the original code in order to access its doSomething() method. Alternatively, you can create wrapper methods in your other classes which pass requests onto a delegate. Lots of delegate methods will make your code larger and slower, but it will also be easier to maintain.

Before reading this article, seeing a chain of calls like that probably would have made me instinctively recoil, but I wouldn’t have been able to explain exactly what was wrong. The bad examples given in this article clarified the reasons why code like that is weak. The article also gave me concrete ways I can follow the Law of Demeter in future code.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

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.