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.

Link to blog: https://blogs.msdn.microsoft.com/specexplorer/2009/10/27/what-is-model-based-testing/

There are many different ways to test software. This blog written by Nico Kicillof defines what model-based testing is and what it is used for.

Model-Based Testing is a lightweight formal method used to validate software systems. It is considered “formal” because it works out of a formal specification or model of the software system. It is “lightweight” since it doesn’t aim at mathematically proving that the implementation matches the specification under all possible circumstances. Here is an image below from the link:

(In the image above, Kicillof shows the diagram that illustrates model-based testing in a nutshell.)

The difference from considering a lightweight method from a heavyweight method is that it comes between sufficient confidence vs. complete certainty as Kicillof likes to put it.

The first step of the process is that it is important to know that the method starts off as a set of requirements that could be written from the development team, or you the developer. The next step is to create a readable model that shows all the possible behaviors of a system meeting the requirements that were given to you the developer. Keep the model manageable by creating the right level of abstraction. Kicillof says this because it makes sense to keep a model manageable. If a model isn’t manageable, then it is basically a bad model to use. It would be difficult to make edits or reconfigure your model if you run into a specific type of problem where your model doesn’t clearly highlight how to fix it.

Kicillof gives the example of model based testing through the use of Microsoft Spec Explorer. He explains that in Spec Explorer, models are written as a set of rules in the mainstream language of C# which makes it less difficult to learn in comparison ad-hoc formal languages.

Kicillof’s explanation on how model-based testing works made me understand the concept better than before. The image he provides, just like the one shown above, illustrates the process of model-based testing. The numbers near each part of the process in the image made it easy to follow. I chose this blog because I wanted to know a little more on model-based testing. I wanted to think on how it would be used in my future career of video game development since it is another great way to test software. Depending on what games I’ll be creating in the workplace, knowing model-based testing is important because I think it is an easier formal way of testing in comparison to other types of testing.

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.

Link to blog: http://blog.architexa.com/2010/04/determining-which-uml-diagram-to-use/

This blog gives an overview on choosing which type of UML diagram to use when it comes to designing software. Some software designers may encounter a problem where they’re coming to a choice on whether which UML diagram to use that is most efficient for a particular task given to them. I am one of those designers because sometimes, I come to a problem where I can’t decide on which UML diagram I should use.

First, there are 3 classifications of UML diagrams: Behavior diagrams, Interaction diagrams, and Structure diagrams.

Behavior Diagrams: 

These are types of diagrams that show behavioral features of a system. This includes activity, state machine, and use case diagrams. Examples of a behavior diagram would be an Activity Diagram and a Use Case Diagram. The activity diagram shows high-level business processes, including data flow, or to model the logic within the system. To simply put it, behavior diagrams, in general, breaks down processes into individual decisions, loops and chain of events.

Interaction Diagrams: 

Interaction Diagrams are a subset of diagrams which emphasize the interaction of objects. This includes communication, interaction overview, sequence, and timing diagrams. These diagrams fulfill the need of designing a system where there are complex relationships between code elements and provides a view on how the elements interact over time. Examples of interaction diagrams include Collaboration/Communication Diagram, Sequence Diagram, Interaction Diagram, and Time Diagram. 

Structure Diagrams:

Structure Diagrams show elements of a specification that are irrespective of time. This means that the elements are not affected by the nature of time. Examples of structure diagrams include Class Diagrams, Composite Structure Diagrams, Component Diagrams, Deployment Diagrams, Object Diagrams, and Package Diagrams. Structure Diagrams, in short, help break large projects or features into parts and specify which parts do what and how they interact within the system.

I chose this blog because I wanted to know the different types of diagrams within the three classifications of UML diagrams. I was aware of the three classifications of UML diagrams, but I didn’t know certain types within each classification such as the Deployment and Composite Diagrams within the Structure Diagram Classification. The author of the blog briefly highlighted each of the three classifications in detail with links pertaining to each of the example diagrams presented within each classification. This made it easier to understand how each example operated. It is important for me to understand the different classifications and their examples of diagrams because when it comes to programming video games, which would be my future career, I would have to implement and figure which diagram is necessary for each type of game design.

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.

Link to blog: https://testlio.com/blog/how-to-be-an-efficient-software-tester/

Currently as a college student majoring in Computer Science, I made the decision that I wanted to do a concentration in software development instead of data analytics. This is because my passion is to become a video game developer. While learning on the concepts of how software is designed and tested, I wondered what would be the necessary fundamentals of being an efficient software tester besides learning all of the test cases, techniques and terminologies. In this blog written by Willie Tran, he explains the seven tips on how an efficient software tester should be.

First, Tran identifies that sometimes, testing software can be chaotic and relates it to those who have experienced it in working in the field.

“Anyone who has been working in the field for any extent of time has experienced unreasonable lack of organization, poor scheduling, and daunting bug reports. Working through this mess is a task of its own. The best way to avoid this situation is to create order in your own habits. If you can create a common and consistent order for any work you touch, then you will set an example for your colleagues.”

Later, he highlights the tips that a software tester should do to be successful and efficient. These tips include organize everything, write detailed bug reports, write clear test cases, take part and communicate, ask yourself questions, be positive, and don’t test.

Organize Everything:

Creating an organize structure is important. When you create an organized structure to store all of the important details, it is easier to gather the relevant details and and perform the right testing strategy for the specific assignment you’ve been given.

Write Detailed Bug Reports 

Writing clean, detailed bug reports helps a lot, especially if you’re working in a team. This means that if you do this, your team will be able to understand more clearly on what it is you are writing and what bugs that you’ve identified in your project. Tran also adds that the three points that he stresses when it comes to writing these reports are:

1. Write with detail
2. Write with clarity
3. Write for others

Write Clear Test Cases 

Don’t create long test cases. Try to simplify as much as you can to avoid problems and save time.

Take Part and Communicate

If you are working in a team, communication is key. This makes it so that testing is a team effort. If everyone knows what they are doing with each other as well as what their tests do, the testing process will be successful.

Ask Yourself Questions

Asking questions to your self is also important in a sense that you are checking yourself as you go to see what can you do to improve the tests and make them more efficient. Ask yourself what the tests are answering and doing.

Be Positive 

Testing with a positive attitude, especially in a team can be a huge factor and contribution. If your team sees that you have confidence in your work, everyone can become successful in the effort towards creating tests.

Don’t Test

Don’t test at all at the start. Once you make the tests, see what parts of the tests need improvement. Once you’ve done that, then you can test.

This blog by Willie Tran helped me understand on what an efficient software testing looks like. I picked this blog because I wanted to know more about what makes a software testing efficient besides knowing all the concepts of software testing. Knowing these tips will help me in the future to become a video game developer because most of the time, I’ll be working in teams when testing and creating game software. It will be important for me to communicate with my team and stay positive throughout the process when I work and test the softwares.

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.

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

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

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

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

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

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

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

Link to blog: https://blog.codecentric.de/en/2016/01/writing-better-tests-junit/

In this blog written by Tobias Goeschel, he makes the arguement that in order to create a readable, maintainable, and useful test suite, we need to change our testing habits by focusing on behavior instead of implementation. Throughout his blog, he outlines some of the aspects that are needed to understand on how to write better tests with J-Unit.

The Value of Test Code

Goeschel states that writing fast, bug-free code is easy, if it’s not too complex, written once, and never touched again. In order to keep the code in high quality and maintainable as possible, you need tests because they allow you to makes changes in the design and architecture, without damaging the behavior. Well written tests will reveal how to access the API, what data is suppose to go in and out, what possible variations of an expected behavior exists, what kind of exceptions might occur, how the individual parts of the system interact with others, examples of a working system configuration, and what the customer expects the software to do.

Test Behavior not Implementation

Goeschel states that we create fragile tests if we set our testing focus on implementation. He then defines behavior as “the range of actions and mannerisms made by individuals, organisms, systems, or artificial entities in conjunction with themselves or their environment.” He specifically highlights that “range of actions and mannerisms” explicitly limits our view to what is observable from the outside. The tests will become more flexible if we refrain from disclosing internals and phrase the tests accordingly.

Group Tests by Context

In order to keep tests organized, we need to make sure that test methods should be grouped closely together. This is important because it helps find each single test, and to understand the behavior of the system much more quickly and easily.

Enforce a Single Assertion Rule

It is important that we try to limit each test method to a single assertion because it makes the code easier to read by assigning meaning to an anonymous block of assert statements.

Choose Meaningful Names

Applying variables and names to method names are important as well. This means that avoiding names like “a”, “test1”, “data” or anything like those names would be best.

Avoid Complex Configuration 

Avoiding complex or bloated configuration promotes fast tests. It applies to extensive use of dependency injection frameworks like Spring. A better way is to declare dependencies explicitly.

Avoid Test Inheritance 

If tests depend on each other, we make it harder and more tedious to change our system. We don’t want our tests to introduce additional dependencies to the code base we create. Inheritance introduces performance problems when working with JUnit.

Overall, Goeschel’s outline of writing better tests with JUnit was very clear and concise as he highlighted the six key actions when performing the JUnit tests. I chose this blog because I was a little unclear about the nature of how JUnit tests are done. This blog made me understand on how effectively test with JUnit. Understanding JUnit may help me in my future career field if video game development because it is another type of test that I can implement when I run and test my 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.

Link to blog: https://www.versionone.com/agile-101/agile-software-programming-best-practices/refactoring/

In this blog, it explains the breakdown about code refactoring. The aspects that this blog covers are the definition of refactoring, code hygiene, specific “refactorings”, refactoring to patterns, the flow of refactoring, and refactoring automation in IDE’s.

The author of the blog states that code refactoring ” is the process of clarifying and simplifying the design of existing code, without changing its behavior.” This basically means that you are just editing the code to make it look and work better without changing its features it implements. They also note that every time we change code without refactoring it, it cause the code to rot and gets worse every time we do so. Rot takes several forms such as having unhealthy dependencies between classes or packages, bad allocation of class responsibilities, excessive responsibilities per method or class, and duplicate code. The main purpose of refactoring is that it prevents rot, which makes the code easy to maintain and extend. Extending the code and refactoring it go hand in hand.

Code Hygiene

Code hygiene is another term that the author of this blog uses to understand the concept of keeping code clean or having “clean code.” In his blog, he provides the metaphorical use of the kitchen environment and that cleaning up the “dishes, the pots, the kitchen itself…” keeps the kitchen as a whole clean. The main message is that keeping our code clean is crucial when refactoring.

Specific Refactorings

Specific refactoring methods are useful such as “Extract method” which extracts a block of code from one method, and creates a new method for it.” Each refactoring method converts a section of code, whether it be a block, a method or a class.

Refactoring to Patterns

The author of the blog references Joshua Kerievsky’s book Refactoring to Patterns. He states that patterns are often over-used, and often introduced too early into systems. He also introduces concepts of refactoring “toward” a pattern, describing how many design patterns have several different implementations, or depths of implementation.

The Flow of Refactoring

The author outlines the simple process of refactoring first by doing automated tests. Next, the coder will refactor by making the smallest discrete change that will allow the code to compile, run, and function. Then the coder will make changes to the code. After the refactoring process is done and all the tests run perfectly fine, it is necessary to remove all of the redundant, smelly code.

Refactoring Automation in IDE’s

This section of the blog illustrates different IDE’s that support automated refactoring . The author talks about the Java IDE Eclipse, which has a built-in automated refactoring support as well as other IDE’s. The overall point is to know that automatically refactoring code is a lot easier to do than to do it by hand.

This blog overall clearly identifies the important points of refactoring code. The author of the blog showed the main importance of refactoring by highlighting that refactoring prevents smelly, rotting code, which no developer ever wants to have. I chose this blog because I wanted to see what else that refactoring does to structures of code. One thing new that I learned was that a lot of IDE’s have built-in automated refactoring support, which I’ve never noticed. Refactoring is an important topic for me to understand because in the future as well as for the rest of the code that I’ll write, it’ll be more efficient to refactor the code especially when designing video games.

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.

Link to Blog: http://it.toolbox.com/blogs/enterprise-solutions/object-oriented-testing-issues-21274

This blog explains the issues of object oriented testing. Craig Borysowich identifies the strategies of object oriented testing, the strategies for selecting test cases, and the levels of testing, which are all involved in analyzing the testing process. In the beginning of his blog, Borysowich states that testing in an object oriented context must address the basics of testing a base class and the code that uses the base class. Factors that affect this testing are inheritance and dynamic binding. Dynamic binding is also known as dynamic dispatch. Since the factors that affect this testing are inheritance and dynamic binding, it brings up the point that some systems are harder to test than others. For example, systems with inheritance of implementation are harder to test than inheritance of interfaces.

Some object oriented testing strategies include white-box and black-box testing. Two assessments that determine the strategies to select test cases include the assessments of “likely faults” and “likely usage.”

“Likely Faults” involve types of tests which are based on practical experiences of areas in which errors are most likely to occur. For example they can occur from certain syntax in a particular programming language or boundaries such as beginning and end conditions. “Likely Usage” involve types of tests that test to exercise the system in the ways that the user of the system will be likely to use the system, or aim to test completely the elements of the system most likely to be used. These strategies apply to structural and behavioral testing.

The levels of testing that object oriented testing undergoes are Unit, Integration, and Acceptance levels. The Unit test is more effective in the overall system than with procedural unit tests. Integration test focuses on interactions among classes. It is recommended that units be integrated in an incremental fashion at a steady rate. Acceptance test ensure that all of the use cases appear in a test.

I chose this blog because I wanted to know what the necessary processes are when it comes to object oriented testing and its pros and cons. Borysowich briefly explains what these processes and steps are when it comes to object oriented testing and how it can involve Unit, Integration, and Acceptance levels of testing. Knowing the two assessments of “likely faults” and “likely usage” helps determine what strategies to use when choosing test cases. Object Oriented testing will be useful to know, especially when it comes to video games. There are games that have implemented object oriented programming, and it is important to understand the issues and solutions when it comes to testing in thwe object oriented environment.

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.

Link to blog: http://www.programmr.com/blogs/5-solid-principles-object-oriented-software-design

This blog gives the description of the 5 different types of design principles. These principles include the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and the Dependency Inversion Principle. The acronym “SOLID” represents these principles in the given order:

S – Single Responsibility Principle

O – Open-Closed Principle

L – Liskov Substitution Principle

I – Interface Segregation Principle

D – Dependency Inversion Principle

Single Responsibility Principle:

“A class should only have one reason to change” is how the author of this blog describes this principle. This principle states that every class in your software should have one and only one responsibility.

Open-Closed Principle:

“Software entities should be open for extensions, but closed for modification.” This means that software systems should be available for change. Customers will request new features and changes to existing features. Designing a system such that changes or extensions in requirements can be done by adding subclasses instead of changing existing code is a way to avoid rewriting an entire system.

Liskov Substitution Principle:

“Derived classes must be substitutable for their base classes.” This means that there will be some implementation of inheritance from understanding inheritance hierarchies and traps that can cause the open/close principle to fail with certain hierarchies. This principle fixes the violation that a function causes towards the open/closed principle.

Interface Segregation Principle:

“Make fine grained interfaces that are client specific.” This means that client code should not be aware of such a non-cohesive class as one unit. The class should have multiple interfaces and the client code should only be aware of the interface which is specific to its needs.

Dependency Inversion Principle:

“Depend on abstractions, not on concretions.” This means that this principle attempts to prevent a tangle of dependencies between modules by stipulating that entities and high level modules must not depend on concrete implementations but should depend only on abstractions.

The author of this blog identified the five design principles in a way that is easier to understand. He highlights the main concepts by providing a brief one sentence description about each principle. The acronym S.O.L.I.D. also makes it easier to understand on which design principles are which. I chose this blog because I wanted to know more about certain design principles. I previously knew the Single Responsibility and the Open-Closed principle, but didn’t know the remaining three. Understanding these principles will help me in my future career because there will be many different principles I will need to apply as a video game developer considering that there will be many different design principles involved for coding games.

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.

Link to blog: https://blog.testlodge.com/levels-of-testing/

Before software is released and used, it has to be tested so that there are no flaws within its specification or function. In this blog by Jake Bartlett, he explains the stages or “levels” of testing that are completed prior to the release and use of software. These levels include Unit Testing, Integration Testing, System Testing, and Acceptance Testing.

Unit Testing: The first of level of testing is unit testing, which is the most micro-level of testing. It involves testing individual pieces of code to make sure each part or unit is correct. A unit is a specific piece of functionality, a program, or a certain procedure within an application. This type of testing verifies the internal design, internal logic, internal paths, and error handling.

Integration Testing: This level of testing comes after unit testing. Integration testing tests how the units work together. Individual units are combined and tested as a group. This overall process ensures that the application runs efficiently by thoroughly dissecting and analyzing how each each unit of code performs with one another. The three techniques to effectively conduct integration testing are Big Bang Testing, Top Down Approach, and Bottom Up Approach.

Big Bang Testing involves testing the entire code along with each group of components simultaneously. The downside to this technique is that since it tests the entire code altogether at one time, it makes it hard to identify the main cause of a problem if there is one.

The Top Down Approach tests the top units of the code and moves down to the lower set of codes in that sequence.

The Bottom Up Approach tests the bottom units first and moves up to the high set of codes in that sequence. Basically, it is the reversal of the Top Down Approach.

System Testing: This type of testing requires the entire application. It is a series of tests in order to test the application end-to-end and verifies the technical, functional, and business requirements of the software. This level is the last level of testing before the user tests the application.

Acceptance Testing:  This is the final level testing which determines whether or not the software is ready to be released and used. Acceptance testing should be done by the business user or end user.

I chose this blog on levels of testing because I wanted to know more about each levels. I had the basic concepts of certain types of testing that were discussed in my software testing class, however these terms such as system testing, and acceptance testing were the ones where I wanted to know more about. Bartlett highlighted the important aspects about each of the four levels of testing, which made me conceptually understand them a lot better. Understanding these levels of testing is important because as a future Video Game Developer, I will have to undergo many types of tests to efficiently test the software that I’d produce before releasing it. It is essential that I my tests allow my applications to run successfully.

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.