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.

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

I picked this blog post because because we’ve been utilizing mock objects in class lately, and this post explains in-depth the logic behind using them in addition to succinctly summarizing the different types of mock objects.

Using mock objects focuses a test on the specific code we want to test, eliminating its dependencies on other pieces of code we don’t care about at the moment. This way, if a test fails, we can be sure it’s because of a problem in the code under test and not in something called by it. This greatly simplifies searching for faults and reduces time spent looking for them.

Mock objects also serve to keep the test results consistent, especially when the real object you’re creating a mock of can undergo unpredictable changes. If you utilize a changing database, for instance, your test might pass one time and then fail the next, which gives you no useful information.

Mock objects can also reduce the time necessary to run tests. If code would normally call outside resources, running hundreds of tests which utilize the actual code could take a long while. Mocks of these resources would respond much more quickly. Obviously we want to test calls to the actual resources at some point, but they aren’t necessary in every instance.

“Mock” is also used as a generic term for any kind of imitation object used to replace a real object during testing, of which there are several. Fakes return a predictable result, but the result isn’t based on the logic used to obtain a result in the real object. Stubs return a specific result in response to specific input, but they aren’t equipped to handle other inputs. Stubs can also retain information about how they were called, such as how many times and with what data. Mocks are far more sophisticated versions of stubs which will return values in similar ways, but can also hold expectations about how many times each method should be called, in which order, and with what data. Mocks can ensure that the code we’re testing is using its dependencies the exact way we want it to. Spies replace the methods of the real object a test wants to call instead of acting as a stand-in for the object. Dummies are objects that are passed in place of another object, but never used.

Creating the most sophisticated type of mock seems like it might take more time than it’s worth, but existing mocking frameworks can take care of most of the work of creating mock objects for your tests.

In the future I expect to write tests that utilize mocking. This post, along with Martin Fowler’s article, has given me a good starting point in being able to utilize them effectively as well as decide how elaborate a mock needs to be for a particular test.

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

The blog post this information is sourced from can be found here.

I chose this blog post because it briefly summed up the general responsibility assignment software patterns, which I wanted to learn about. GRASP are patterns that serve as guidelines to which classes or objects should be assigned responsibilities. There are nine patterns in total.

A general method for deciding which class to assign a responsibility to is to assign it to the information expert: the class that has the necessary information to carry out the responsibility in full.

When trying to decide which object should be responsible for creating new instances of a class, the Creator pattern says that the responsibility of creating Class A instances should be assigned to Class B if Class B contains instances of Class A or gathers instances of Class A into one place, if Class B keeps a record of Class A objects, if Class B is closely associated with Class A objects, or if Class B has all the information necessary to create a Class A object – that is, it’s an information expert about the responsibility of creating Class A objects.

The controller pattern answers the question of what should handle input system events. Controllers can represent the entire system, device, or subsystem, in which case they’re referred to as façade controllers. They can also be use case or session controllers, which handle all system events of a use case. The controller doesn’t itself do the work, but instead delegates it to the appropriate objects and controls the flow of activity.

The low coupling pattern holds that responsibilities should be assigned in such a way that coupling remains as low as possible – that is, there is low dependency between classes, high reuse potential, and changes in one class have a low impact on other classes

High cohesion means the responsibilities in a class are highly related or focused on a single goal. The amount of work one class does should be limited, and classes shouldn’t do lots of unrelated things.

If behavior varies based on type, polymorphism holds that the responsibility of defining that variation should be assigned to the types for which the variation occurs.

Pure fabrication classes exist to maintain high cohesion when assigning responsibilities based on the information expert pattern would not. They don’t represent something in the problem domain.

Indirection maintains low coupling by assigning mediation responsibilities between two classes to an intermediate class.

The protected variations pattern assigns responsibilities that create a stable interface around points of likely variation or instability to protect other parts of the system from being affected by any variation/instability.

This post gave me ideas I can refer back to when solving the problem of which of several classes should be assigned a particular responsibility. The problems addressed by these design patterns exist in just about every software development project, so there’s no doubt I will find it useful in the future.

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

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.

Today I will be talking about the decorator pattern. I found a blog on the decorator pattern by Bambielli’s Blog. The decorator pattern, according to the blog, allows objects to have new responsibilities at runtime without changing any code in their underlying classes. The blog writer then makes a point to favor composition over inheritance because it can reduce the frequency of runtime errors. It also conforms to the “open for extension closed for modification” rule of good programming. Decorating a class is essentially extending objects to add functionality at runtime. This allows things to be more current and up to date for user demands. In the UML diagram provided by the blog, the abstract decorator class extends the abstract component, which gives the abstract decorator the implementations to be used in place of the component implementations. The decorator classes extend the abstract decorator class, and provide the abstract decorator class with the current overriden methods.

The blog uses a pizza shop as an example. Pizza can come in a variety of toppings and crusts. The decorator pattern allows us to construct any combination of pizza toppings. Concrete classes DeepDish and ThinCrust extend Abstract Class Pie. The decorator pattern comes into effect with the topping decorator. The Abstract Class ToppingDecorator extends Abstract Class Pie, and the ToppingDecorator class has two decorators, PepperoniDecorator and CheeseDecorator.

The blog points out some disadvantages to the decorator pattern, one being that decorating objects manually is a hassle due to the large number of parameters to pass. The solution to this? Use the factory pattern in combination with the decorator pattern to make the objects for you, eliminating you having to manually pass all the parameters.

I chose this pattern because I am always looking to learn how to improve my code and make it  more efficient. Learning different design patterns is a great way to help my cause. The only thing about design patterns is that they aren’t always widely applicable. Most design patterns are specific for a small number of cases, so learning more design patterns helps me to overcome more situations that I face when coding. I think this blog really helped my understanding of the decorator pattern. I had looked at a few before this one, and the decorator pattern seemed to be pretty vague to me. The pizza example in this one really helped solidify my understanding of this pattern. All the examples from the other blogs had lots of code samples, and not a lot of explanation. Though simple and basic, I really liked the pizza topping example. I hope to apply this in future practice. I would like to have a program that allows users to make a number of different combinations (such as a sandwich topping program, or a car customizer program (color, size, etc.)). This pattern seems to be really effective with being able to create whatever combination of choices the user asks for.

Here’s the link: http://www.bambielli.com/posts/2017-04-02-decorator/

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.

This week I read on article on Automated Testing. The article explains why Test Automation software is the best way to increase the effectiveness, efficiency and coverage of our software testing. As per the article, an automated testing tool is able to playback pre-recorded and predefined actions, compare the results to the expected behavior and report the success or failure of these manual tests to a test engineer. Once automated tests are created they can easily be repeated and they can be extended to perform tasks impossible with manual testing. Because of this, savvy managers have found that automated software testing is an essential component of successful development projects. Some of the major merits of using Automated Testing over the Manual software testing are:

Automated Software Testing Saves Time and Money: Once created, automated tests can be run over and over again at no additional cost and they are much faster than manual tests. Automated software testing can reduce the time to run repetitive tests from days to hours. A time savings that translates directly into cost savings.

Vastly Increases Your Test Coverage: Automated software testing can increase the depth and scope of tests to help improve software quality. Lengthy tests that are often avoided during manual testing can be run unattended. They can even be run on multiple computers with different configurations. Automated software testing can look inside an application and see memory contents, data tables, file contents, and internal program states to determine if the product is behaving as expected. Test automation can easily execute thousands of different complex test cases during every test run providing coverage that is impossible with manual tests.

Testing Improves Accuracy: Even the most conscientious tester will make mistakes during monotonous manual testing. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results. Testers freed from repetitive manual tests have more time to create new automated software tests and deal with complex features

Automation Does What Manual Testing Cannot: Even the largest software and QA departments cannot perform a controlled web application test with thousands of users. Automated testing can simulate tens, hundreds or thousands of virtual users interacting with a network, software and web applications.

Automated QA Testing Helps Developers and Testers: Shared automated tests can be used by developers to catch problems quickly before sending to QA. Tests can run automatically whenever source code changes are checked in and notify the team or the developer if they fail. Features like these save developers time and increase their confidence.

Source: https://smartbear.com/learn/automated-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.