We’ve recently conducted “group code reviews” on a given project, where the goal was to identify any issues and/or bugs we could find within the project’s code. I found this to be a good exercise because I will likely be doing many code reviews during my professional career.

My ultimate goal regarding code reviewing at this point is to learn how to do it as efficiently as possible. Sara Tansey has a great blog on the topic, entitled 7 ways to up-level your code review skills. She identifies several strategies in particular that she feels are important when reviewing code. I will outline a few of these strategies that I found especially relative to our course’s content, along with my personal thoughts and takeaways.

“Prioritize the goals of code reviews with your team.”

I feel this is an important topic which I am glad Sara mentions in her blog. The main idea here is to make sure your team is up to speed with what each individual team member should be looking for. One example I can think of is the following: perhaps “Person A” could be looking specifically for bugs while “Person B” concentrates on code style. Then perhaps each team member can go through the code together and see if there is anything they have missed.

“Run the app and try playing with the features.”

Sara brings up potential difficulties of trying to perform effective code reviews solely on the basis of reading the code. I agree with her stance that code reviewers ought to run the program and “play with” the features as well. I believe this is a good strategy because seeing the program in action may provide some clarification on what the code is doing, and what it is intended to do.

“Always give approval, unless you can prove that there is a bug.”

I believe what Sara is referring to here is a code reviewing team that has the responsibility of either approving or denying a developer’s request to continue with production. Giving approval to proceed barring the existence of bugs makes sense to me. There doesn’t seem to be much of a reason to halt production on the sole basis of “less than optimal code style” in my opinion. I feel if the code works, certain style inefficiencies can easily be addressed based on the feedback of code reviewers.

I enjoyed reading Sara’s blog and feel she brought up many good strategies to conduct efficient and high-quality code reviews. I especially like her suggestion that we ought to be running and going through the apps themselves, rather than just reading the code alone. Running the program might give us some context that we may have missed if we relied on simply reading code lines without actually seeing the app in action. During my professional career, I will adhere to Sara’s suggestions while conducting code reviews for given projects. I will run through the actual program as well.

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

My teammate and I are currently working on a Blackjack card game, which we will present to our class during finals week. I’ve spent the last few weeks trying to become more familiar with Angular and TypeScript for this project, and I believe I am starting to make some good progress. For instance, I have figured out how to build a card deck, shuffle it, and display images of these cards to the user.

There is a great online instructor named Mosh Hamedani with a series of tutorial videos for both Angular and TypeScript. I’ve already watched several of his videos and found them extremely useful and informative. The instructor has a personal blog as well. I would like to discuss one of his blog entries in particular, entitled Angular 4 in 20 minutes.

First, a disclaimer. I certainly did not learn Angular in 20 minutes, but Mosh’s insight and clear explanations are helping me understand Angular and TypeScript concepts more than any other tutorial I’ve tried so far. 

Mosh’s blog entry is a synopsis of one of his free tutorial videos, which is approximately two hours long. I’ve watched the entire video twice already and I believe it is definitely worthwhile to anyone who is trying to learn Angular and TypeScript. Here are a few important points that Mosh brings up in his video synopsis:

He explains that Angular is a framework for building applications in HTML, CSS and TypeScript/JavaScript. He also answers the question of why a developer would want to use Angular rather than other alternative methods. I have to agree with Mosh here that learning TypeScript with the Angular Framework seems a whole lot easier than, as he puts it, “vanilla JavaScript.” I believe this is due to the “IntelliSense” offered within Angular and TypeScript which is currently unavailable in JavaScript alone. When comparing TypeScript code side by side with JavaScript, in my opinion, the former is much easier to understand than the latter.

Mosh also goes through a step-by-step process on how to install everything needed to run the Angular framework, including how to create a new application project from the terminal. Next, he uses MS Visual Studio to go through the project layout and explains every single file that was created, including their functions and purposes. He then demonstrates how to generate new components within the project and how to connect them with the main application module.

The free video posted in Mosh’s synopsis blog entry is part of a 30+ hour long Udemy course video compilation that typically costs at least $200. Fortunately, there is a great “Black Friday” sale going on where I was able to purchase this entire course for just ten dollars. I feel I am making great progress in learning Angular and TypeScript; I honestly believe it would have not been possible without his videos and blogs. I am certain I will continue to reference Mosh’s insightful blog entries and tutorial videos, and apply what I’ve learned from him during my professional career.

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

We’re beginning to work on our final class projects using Angular and TypeScript, both of which I was previously unfamiliar with before this semester. Since our projects will be implemented using the Angular framework and the TypeScript programming language, I want to learn more about the concepts behind these applications. I found an informative blog on the subject; it is entitled Angular: Why TypeScript? by Victor Savkin. The main topic here describes the benefits of using TypeScript in general, and how it is an efficient means of producing quality Angular projects.

Victor points out that while using TypeScript for Angular projects is not required, but is encouraged to be used within the framework for several reasons; many of which I will summarize here. I will also offer my personal thoughts and takeaways regarding the content.

Prior to reading Victor’s blog, I was not familiar with the fact that Angular was written in TypeScript. Now it makes more sense to me why we are going to be using TypeScript to code our projects; since Angular was written in TypeScript, it ought to have high compatibility with that particular language.

Another encouraging aspect brought up by Victor is the fact that TypeScript is equipped with many useful tools, such as “auto-completion, navigation and refactoring.” Based on his explanations, I feel that TypeScript is a very flexible language; for example, if we need to rename an instance, it seems that TypeScript will automatically change all implementations of that instance to its new name without having to do it manually. I find this to be a very powerful and efficient feature that I look forward to using while coding future projects.

Victor also eludes to the fact that TypeScript is actually a superset of JavaScript, something I was completely unaware of. I find this fact very interesting in the sense that it suggests that anything that can be done in JavaScript can be implemented in TypeScript. Victor even suggests we can rename a JavaScript .js file with the .ts extension, and with the proper annotations, the program could theoretically run completely in TypeScript.

Victor further explains that TypeScript simply makes code “easier to understand” rather than other languages such as JavaScript. I tend to agree with him in the sense that it seems that TypeScript offers explicit declarations, such as that of parameters, interfaces and abstractions. It seems that JavaScript does not offer much of this functionality. Victor offers sample code, first implemented in JavaScript, and then again in TypeScript. In my opinion, the TypeScript code is much easier for me to comprehend due to the explicit declarations that are lacking in JavaScript.

Reading Victor’s blog has made me further intrigued with the capabilities of TypeScript; I learned that it is even more flexible and powerful than I originally thought. Based on Victor’s insights, I feel that learning TypeScript will be useful to me during my professional career, since he states that it is widely used in the field of Computer Science.

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

We’ve been discussing the differences between stubs and mocks, along with the fact that many software testers may initially assume the two are the same concept. But as we have learned, mocks and stubs are not synonyms; they are two different techniques used within unit testing.

I wanted to learn more about some specific differences between stubs and mocks, such as potential advantages and disadvantages of using each of these techniques. Wojciech Bulaty has an informative article on the subject. Before getting into the pros and cons of each aforementioned technique, Bulaty explains the main concepts of stubs, mocks, and service virtualization.

He asserts that stubs use hardcoded data within the testing program itself, where the tests depend on this data. Based on Bulaty’s description of stubs, it seems it would be most beneficial to me to apply stubs when testing simpler code where no more than minimal implementation of an interface is required.

Mocks on the other hand seem to be most useful in situations for larger, more complex tests to “verify output against exceptions.” In my opinion, mocks ought to be used in addition to stubs to further satisfy the integrity of our testing. For instance, mocks may produce findings that stubs could not, due to the limitations of the hardcoded data within stubs. On the other hand, I feel it may be useful to use stubs as well, to help compare its findings with that of the mocks within our tests.

Bulaty introduces a third method to use within our unit tests: service virtualization. I found this particularly interesting because we haven’t discussed much about service virtualization in class yet, and this article helped me learn more about it. He explains that service virtualization supports testing through multiple protocols, and employs “test doubles” which are usually offered as Software as a Service (SaaS). It seems to me that service virtualization relies more on recorded data from a wide scope of different projects, whereas stubs and mocks are typically written by developers of their own projects.

My main takeaway from this article was recognizing some differences in particular between mocks, stubs, and service virtualization that were previously a bit unclear to me. Whereas stubs seem to concentrate on state verification, mocks tend to be more focused on behavior interactions within our code. I also learned which testing techniques may be most appropriate in regards to the particular code we are testing. For instance, if I am testing simpler tests with limited resources, based on what I’ve learned from this article, I will likely use stubs for my testing. But for larger, more complex tests, I feel I ought to implement mocks within my testing as well. Finally, when I am involved in large scale projects during my professional career, Bulaty’s article has convinced me that I should look into using service virtualization in addition to stubs and mocks when performing unit testing.

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

Over the past few weeks reading about unit testing, I’ve come across a few articles and blogs claiming that unit testing is not the most efficient way to ensure code accuracy and quality. I’ve been under the impression that unit testing is always a good idea, so I wanted to read about Robert Martin aka Uncle Bob’s input regarding this subject. He is a reputable computer programmer and the author of the well-received book “Clean Coder.” The following is a brief summary, along with my personal takeaways, from one of Bob’s blogs entitled First-Class Tests.

Bob is critiquing a TechBeacon blog where the author is condemning unit testing as bad practice. It seems to me that the TechBeacon blog author has claimed to “give up” unit testing for something that he calls “system testing.” But Bob insists that the TechBeacon author is not only running his tests in an inefficient way, but using improper terminology as well.

Bob gives a few definitions of different types of testing, some of which seem to contradict the views of the TechBeacon blog author. First, he explains that unit tests are written to ensure that the code is doing what the programmer intends it to do. Bob then gives his definition of system testing, stating it is not what the TechBeacon author believes it to be. System testing, according to Bob, are “plumbing” tests to ensure the internal workings of the entire integrated system is working as expected. This is in contradiction to the TechBeacon blog who claims he is running “system tests.” Bob claims what is actually being run here is “user-interface to database” functional tests, which are, in actuality, slow unit tests. I agree with Bob’s terminology here; it seems to coincide with what we’ve learned in class regarding unit testing thus far, some of which I’ve discussed in some of my previous blogs.

I believe the main point that Bob is trying to get across is that it seems many people tend to have the wrong idea of what unit testing is. If someone is writing unit tests that rely too heavily on outside resources, for example, it can slow down and hinder the whole purpose of testing software. It can make unit testing seem inefficient, when in actuality is the result of badly written unit tests. He stresses that programmers should not be trying to think of ways to circumvent unit testing. Instead, we should find ways to write unit tests as efficient, clean, and self-sufficent as possible.

I truly enjoyed reading Bob’s blog regarding his opinion on unit testing. I found it both amusing and informative. Bob leaves us with a final thought; we ought to treat our unit tests as “first-class citizens.” I will strive to do this throughout my professional career based on the advice he has given in his blog: I will avoid coupling unit tests with outside resources and make great efforts to always keep my unit test code “clean” and up-to-date.

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

We have an assignment coming up where we have to choose a particular design pattern and write a tutorial about it. I chose the Observer Design Pattern because the whole concept, a “Subject” notifying its “Observers” of changes, looked quite useful to me in real-life situations. To learn more about this pattern, I found a great multimedia article entitled Observer Design Pattern Tutorial by Derek Banas.

Derek states that the observer pattern is comprised of a Subject and Observers. Based on his explanations, I feel this a great design to use when we need objects to continuously receive updates when something changes, such as another object. He uses the stock market as an example, where the Subject is the “publisher” sending information of various stocks to the Observers (“subscribers”). The Observers can choose which stocks to view and if any of these are updated by the Subject (“publisher”), the Observers are notified. Using this scenario as an example was helpful to me because it helped validate the “real-life” necessity and importance of this design.

Derek provides a video giving a step-by-step procedure of how to translate his “stock market” example into an “observer pattern” code implementation. I found it very easy to follow and his explanations of the code very informative. Based on his explanations, I will give my interpretation of the related classes created and used within his code:

Subject is an interface that handles registering, unregistering and notifying observers of any changes.  StockGrabber is a concrete class that implements Subject’s given methods, along with ways to set and update a few example stock prices.

Observer is an interface that provides an update method which is called whenever the Subject changes. StockObserver is a concrete class implementing Observer. It allows the ability to assign each observer with a unique ID as they are created. Furthermore, the constructor keeps track of the total number of observers. This allows the Subject to know how many “subscribers” (Observers) it has, and what stocks they are subscribed to. The importance of this is that the Subject (“publisher”) must know which observers it should send updates to when necessary, and what updates it should send.

Finally, there is a main class GetTheStock that puts the above classes to use in such a way that we can see what the Observer pattern code is doing.

I have a few ideas of how I could implement my own version of the Observer pattern. Right now I am thinking of using this design pattern to keep track of the creation and updates of blog entries. For example, perhaps I will have a “BlogPublisherSubject” notify each “SubscriberObserver” whenever a blog entry has been updated.

Based on what I have learned reading Derek’s article and watching his provided video, I feel I have a solid understanding of the Observer pattern, which will surely help me in my upcoming project. I am confident that I will frequently implement this design pattern during my professional career as well.

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

We’ve been going over the concept of design patterns during the past few weeks, so I thought it would be appropriate to do some research on those most commonly used. Subham Aggarwal has an informative blog on the topic entitled Top 3 Design Patterns in Java. We’ve been examining design patterns written in Java, so I feel that Subham’s blog is a great one to discuss. He provides excellent examples written in the Java programming language.

Subham first explains that design patterns are generally creational, structural or behavioral. He then introduces three design patterns that he speculates are the “top three” used in Java.

1. Singleton Pattern
2. Factory Pattern
3. Decorator Pattern

I covered the Singleton pattern in a recent blog so I will try not to duplicate anything posted in that entry. One aspect that stands out in Subham’s explanation that I ought to mention is his assertion that Singleton is one of the most “inappropriately used” design patterns in Java. Based on what we’ve learned so far, it seems to me that the true intent of Singleton is to have just one instance of each Singleton class. But Subham states that many developers seem to manipulate the pattern in an attempt to have Singleton classes act as global variables, which is not what this pattern is intended to do. Based on Subham’s breakdown and what we’ve learned in class, I would have to say that I believe the Singleton design pattern seems to be a creational one.

Next discussed is the factory pattern, which Subham describes as a way to create certain objects based on the user’s specification. For instance, he provides the following code as an example:

public class ShapeFactory {
 
 // use getShape method to get object of type shape 
 public Shape getShape(String shapeType) {
     if (shapeType == null) {
     return null;
     } 
     if (shapeType.equalsIgnoreCase("Quadrilateral")) {
          return new Quadrilateral();
     }
     else if (shapeType.equalsIgnoreCase("Parallelogram")) {
          return new Parallelogram();
     }
     return null;
     }
}

Something I’d like to add on the subject is perhaps it would be a good idea to develop an enumeration type to define the names of the above given shapes as constants. Also, based on the fact that we are offering a way to create objects here, I would have to say that the factory design pattern is a creational one as well, along with Singleton.

Last but not least, Subham describes the decorator design pattern as one commonly used in Java. The idea here is to “add new functionality to an existing object without changing its structure.” Thus I would have to agree with Subham that this design pattern seems to be a structural one. I do not think we’ve discussed this in CS-343 yet, but I remember using the decorator pattern in a previous course, so I see how it can be useful.

I feel that Subham provides great examples that have helped me better understand these design pattern concepts. The code he provides is well detailed and easy to follow. His blog will be a good reference to me in future projects during my professional career.

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

Considering we’re discussing JUnit in class, I want to learn how to use it as efficiently as possible. For those who are not aware, JUnit is a popular unit testing framework for the Java programming language. Since unit testing is an important concept in Software Development, learning more about the workings of JUnit should not only help me with my studies, but also with my professional career.

I found a good blog offering some tips and pointers on the subject, entitled JUnit Best Practices by Kyle Blaney. The main point seems to focus on the importance of performing efficient unit testing with the JUnit program.

Before going into JUnit specifics, Kyle starts off by stressing that unit tests ought to be “extremely fast” and “extremely reliable.” Due to present technologies, we seem to expect computers to run at the proverbial speed of lightning. Because of this, I believe it is considerable to expect each test to be completed within milliseconds. Also, I agree that unit tests should be reliable in the following sense: they should be failing when the code is broken and passing when the code is not.

In regards to JUnit, Kyle brings up quite a few points, the following of which I felt specifically relate to the course material. This pertains to what we’ve previously discussed about unit testing so far, and what we will likely be covering in the near future.

Kyle explains that we should be running our JUnit tests completely in memory. This means we should not be accessing outside resources during our testing. I agree, because if we cannot get a reliable connection on these outside resources, it will only slow down or possibly halt our unit testing completely.

Another important point that Kyle brought up is that unit test methods should only be performing one assertion. His reasoning is as follows: we cannot be certain that all the assertions occur even if the method appears to have passed. This seems to be in relation to something we’ve learned in our school’s computer science program: “Methods should do one thing and one thing only.” That way, it is much easier to trace our code and figure out what it is supposed to be doing.

We’ve also discussed in class that we should be using JUnit assertion methods that best match the context of our testing. One example Kyle gives is when to use assertTrue versus assertEquals:

Use assertTrue(classUnderTest.methodUnderTest()) rather than 
assertEquals(true, classUnderTest.methodUnderTest()).

Kyle goes into great details within his blog. Along with the points that I’ve discussed in my own blog, he offers code samples of what not to do, and most importantly, what we should be doing to perform the most efficient JUnit testing possible. I found his blog to be quite helpful and learned a lot from reading his take on JUnit “best practices.” Because of this, I expect his strategical insights and sample code will be useful to me in my future career in software development.

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

We’ve discussed quite a few different testing techniques, so I would like to offer some personal reflection on what we’ve learned so far. Udemy has a great blog highlighting many of these techniques; it is entitled Test Design Techniques You Need to Know. I will summarize some points from Udemy’s blog which I feel directly relate to what we’ve discussed in class so far.

Udemy begins by explaining the concept and importance of Software Testing, which I feel is an intricate part of Software Development itself.  As we’ve learned in class, we test our software to ensure the quality and integrity of our products. We want to be able to detect and fix any flaws in our products before they reach the consumer.

Udemy classifies testing techniques as a whole into two general categories: black-box and white-box. We’ve learned in class that we do not need access to the actual code to perform black-box testing of a product. In contrast, we ought to have access to the program’s internal structure and/or source code to perform testing techniques in the white-box category.

Many of the techniques we’ve discussed in class seem to fall within the black-box testing category, so I will focus primarily on that category. Udemy lists some techniques of black-box testing, three of which sound very familiar due to what we’ve done in class:

• Boundary value analysis: This is where we test the lower and upper limits of possible inputs. After finishing a class project and reading thoroughly about this technique, I feel that if our code is going to fail, there is a significant chance in finding these errors somewhere close to the minimum, nominal, maximum range.
• Decision table testing: Udemy describes this as evaluating conditions of our code within a table, where every decision correlates with a relation, predicate or variable. The blog cites this technique as “providing great confidence in the test cases.” I tend to agree with this statement because as we’ve learned in class, decision tables are good at analyzing complex logical relationships within our projects.
• Equivalence class partitioning: We use this technique to partition a complete set into subsets, and test each of these “equivalence classes.” Since we’re partitioning the sets, I believe this technique can be used as an efficient way of reducing the total number of needed tests as a whole.

Udemy concludes by explaining that a decision test design technique is the best way to obtain absolute logical coverage. I would like to learn more about this topic; perhaps we will be discussing it in class soon. The blog also emphasizes that we ought to use boundary value analysis and equivalence partitioning to cover a wide range of inputs.

After reading Udemy’s blog, I am convinced that all of the summarized techniques are used everyday in Software Development as a whole. Thus I am confident I will be using many (if not all) of these techniques in my professional career.

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

The Singleton pattern is a great topic choice for me this week. I sought to find a blog to strengthen my understanding of the Singleton pattern. But at the same time, I hoped it would offer insight as to what “Singleton related” questions may be asked in future job interviews. It turns out that such a blog does indeed exist, covering both of these inquiries!

Core Java Interview Questions: The Singleton Design Pattern by Sam

Sam begins by explaining the fundamentals behind design patterns. For nearly all programming languages across the board, design patterns are the conceptual structure and layout of our code, which establish themselves over time for being “tested and well-proven.” Not only are design patterns consistently brought up during job interviews, they are an intricate part of both object-oriented programming, and software development in general. This is important to me because I am always looking for ways to further my programming experience, for both myself and my future career.

So what is a prime example of a “conceptually tested and well-proven” design structure? According to Sam, knowledge of the Singleton design pattern is one of the primary requisites that employers tend to look for when interviewing potential candidates.

Most importantly, the job interviewer is likely to ensure whether or not the candidate knows what a Singleton is, and when/why we would want to use it. We can apply the Singleton pattern when we want to limit the creation of an object to a single instance. For an example of why this may be useful, Sam explains that it can make logical sense for the developer to have “a single go-to place in your application to get data on something.” I believe another reason why the Singleton pattern is useful is that it seems to make the layout of our code look elegant in a neatly structured way. I also feel that if we can limit the creation of needless objects, especially in large projects, this can free up a lot of memory that would otherwise be wasted.

Sam also notes that job interviewers may go a step further and ask the candidate how we create a Singleton pattern, perhaps in Java for example. Objects are created using constructors. Since the goal of a Singleton is to eliminate this ability, this can be achieved by creating a private constructor for the Singleton class. We can then provide a getInstance() method to make the Singleton object available.

I strongly suggest checking out Sam’s blog regarding the Singleton design pattern. I gave a basic summary on the subject, but Sam goes into further details regarding how to instantiate a Singleton pattern, as well as the strengths and weakness of this particular design. My main takeaways from this blog are the concise explanations and insights regarding the Singleton design pattern. Since it seems to be widely considered during interviews, hopefully my further solidified knowledge regarding this topic (due to Sam’s blog) will help me land a good job in the future!

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