With our discussions in class about typescript and java script for use with Web-apps, I believe it is important to discuss the difference between web-apps and native apps and how our knowledge of them can help us decide which one is more preferable. I choose this article by Lifewire because it provides a great compare and contrast of web-apps and native apps.

There has been an ongoing debate over what type of app is better – Web Apps or Native apps. Firstly, I think it is important to distinguish the two. Typically, a native app is an app that is used local on a device. These apps are usually downloaded and installed on the device. For example, the camera app on an android phone or Microsoft word on a desktop computer. While native apps are usually local on a device, Web Apps are apps that are not installed locally on a device.

Let’s take for instance a locally installed app. That app can access almost all of the devices features (if permissions are granted). Snapchat, for example, is an instant messaging app using a smart-device’s internal camera. That is a native app using another native app. A web app only has access to a limited number of the device’s native features. This may seem like a bad thing, however, there are greater benefits to web-apps than you may think

The great thing about native apps is that since they operate specifically on software designed for a particular device, it can be greatly optimized and catered towards that device, thus enhancing the users experience. At the same time, this means whenever a native app needs to be updated, the device needs to keep downloading updates and bug fixes. With a web app, all updates are handled on the back-end, therefore no native changes or downloads need to be made.

Both web-apps and native apps are used everyday, and arguably, they can both be used hand in hand. Web apps can be developed for native apps and native apps can be developed for web apps. Paypal has a web-app in browser, however they also have a native app that can be downloaded and updated. I think as technology progresses, we will see more web-apps as cloud computing seems to be the future. Knowing this, I personally think that web-apps will continue to evolve because they require no user action to update and they do not need to be designed for a specific system, therefore making

Source: (https://www.lifewire.com/native-apps-vs-web-apps-2373133)

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.

For this week’s blog I chose the article titled “Alpha Testing vs Beta Testing.” I chose this article because it covers two types of testing I haven’t read too much about. I also like the comparison type so I can see different situations why I might choose one over the other.

To start, alpha testing is a type of acceptance testing. It’s used to identify all the possible issues in a product before it gets released to users. The idea of this type of testing is to simulate real users by using blackbox and whitebox methods. The article mentions this type of testing is usually done by internal employees in a lab type environment. The overall goal is perform tasks that the typical user will be doing frequently. This testing is done near the end of the software development cycle but before beta testing if beta testing is being done.

Beta Testing is another form of acceptance testing done by real users in a real environment. It’s mainly used to gather feedback and limit product risks before the product gets released to anyone and not just a small testing group. This would be the last type of testing before a final product gets shipped to customers.

While beta testing and alpha testing share some similarities there are some key differences. The first being that in beta testing reliability, security, and robustness are checked which is not true for alpha testing. Another difference is how issues are addressed. For alpha testing it’s not uncommon to make code changes before an official release. With beta testing code changes will usually be planned for future versions after the product is released.  Lastly, with beta testing you are getting feedback from real users and this will usually be a more accurate analysis of how a product will perform over alpha testing.

For larger product firms, a product release will usually incorporate both alpha and beta testing. Below is a typical flow chart of the process.

To clarify, the pre alpha phase would be a prototype where not all features have been completed and the software has not been officially published. The release candidate phase is when any bug fixes are small feedback based changes have been made.

In conclusion, this article was really great comparing alpha and beta testing. It goes into more details with some advantages and disadvantages of the two as well as some entry and exit criteria however this goes beyond the scope of this blog. After reading about these two types of testing I would definitely want to include both in a product release strategy however I would choose beta testing if I could only choose one. I think real user feedback in a real time and natural environment is most valuable before releasing. At the same time it would be easy to argue that terrible feedback in a beta testing cycle could be prevented with prior alpha testing.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

For this week’s blog I chose an article on the pipe and filter architecture appropriately titled “Pipe-And-Filter.” I chose this article after googling what some of the most common software architectures are and learning that pipe and filter was commonly implemented. This article seemed like a good length with straightforward information and diagrams to help with understanding the material so that is what I chose it.

To begin, this architecture consists of any number of components referred to as filters due to the fact that they filter data before passing it through connectors called pipes to other components. All of the filters work at the same time and this is usually implemented in simpler sequences although is not limited to that.

Above is a simple diagram to show how the architecture flows. It’s important to know that filters can transform the input data from any number of pipes. The pipes pass data between filters however it is unidirectional implemented by a buffer until the downstream filter can process it. The pump is where the data originates such as a text file or I/O device. Lastly the sink is the end target of the transformed data such as a file, database, or output to a screen.

One good example of this architecture would be a Unix program. One program’s output can piped into another program’s input.

Above is a more complex diagram to show how pipe and filter can start to become complex. Different sources or pumps can interconnect data into their respective streams. An application that uses this architecture will typically link all the components together and then spawn a thread for each filter to run in.

One interesting functionality of this pattern is a recursive filter technique. This is implemented by having a filter inside of another filter.

One common issue with this type of architecture concerns what kind of data types are allowed in a certain pipe. If only one type is allowed, filters need to parse for this which can slow an application down. You may also limit yourself to what pipes can connect to which filters.

After reading this article I have a good idea of pipe and filters main concepts. One thing I wished the article had discussed more in detail would be specific implementations of this architecture. I can’t directly see how I would need to use these concepts in any of the coding I’ve done so far. I can see a general use for this model for an application that takes in a lot of raw data and needs to output it in a useful format for making business decisions. In summary this was a well written article but I need to do some further reading on implementation examples.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

https://8thlight.com/blog/georgina-mcfadyen/2017/01/19/common-code-smells.html

This blog describes some of the most common code smells. A code smell is “a surface indication that usually corresponds to a deeper problem in the system.” Being able to catch code smells early will make it easier to refactor into code that is more extendable, readable, and supportable.

Long Methods

Having long methods makes your code harder to maintain and debug. It will also be more difficult to read as you have to keep a lot of complex logic in mind while reading a long method. Ideally, a method should not have more than one responsibility.

Refuse Bequest

Inheritance is not always the best model to use. If inherited methods go unused or are overridden to do nothing, it could be a sign of this code smell. Inheritance should only be used when a class needs to reuse code from its superclass.

Data Clumps

If multiple methods take the same type of parameters, it’s a sign that those parameters are probably related. The parameters can be combined together in a class to keep them together, which will help keep the code organized.

For example, instead of having a method with three parameters:

class DatabaseCredentials{
 ...
   public String getHost(){
     return host;
   }
   public int getPort(){
     return port;
   }
   public String getUsername(){
     return username;
   }
}
...
connect(DatabaseCredentials databaseCredentials);

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Over the past couple of weeks in our Software Quality Assurance and Testing course, we’ve been working on writing code using Test-Driven-Development as well as coming up with JUnit test cases based on code that was already written. Over this time, I’ve come to notice that naming conventions for test cases can prove to be a little challenging in some situations. This is especially the case when writing tests in a Behavior-Driven-Development (BDD) manor. BDD, I feel, has kind of become the norm when it comes to naming conventions for JUnit tests and what this means is that tests are written specifically to test certain expected behaviors of methods/classes and are named as such. To clarify this, let me give an example using the code we were working on in class; imagine you write a test case that is going to test our readToGraduate() method in our Student class. While you will most likely have multiple test cases for this method, since there are multiple factors to consider when determining if a student is ready to graduate, one of your JUnit tests might test to make sure the method returns false when the student’s LASC and major requirements are complete, and they have obtained enough credits but their GPA is less than 2.0. A possible name for this test, following the BDD practice of naming, might be:

As you can see this is kind of a mouth-full. Even though this describes the behavior we should expect with the given input, the readability of this code is pretty lousy. That’s why I decided to do some research on different naming conventions for naming JUnit test cases for this week’s blog post.

I found a blog post titled, Getting JUnit Test Names Right, written by Frank Appel, a software engineering professional, in which he addresses the same problem I have just described. Essentially what Frank suggests in his blog post is that we keep naming simple, which may mean making our test names less descriptive, and use good naming conventions for methods and variables inside the test case to enhance readability. He explains that test names can be made simple through our test’s name only describing state information. Hence the test case I described earlier may look something like this:

Although the name of this test may apply to multiple tests with different inputs we could address this by simply adding a number at the end of the name for different input values being tested.  Frank, addresses this issue as well in his explanation. He says that although this naming convention may lead to names that could apply to a variety of tests, using good naming conventions inside your test method will clear up some of the vagueness. Also, as Frank points out, since the JUnit reporting view provides pretty descriptive messages when a test fails, this will also help clear up some of the ambiguity.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Flyweight

The blog I chose to talk about this week goes into detail about the flyweight design pattern using its applications and implementations. When the blog starts talking about the applications of the design pattern, it begins with the situations of when you should use this design pattern. It explains that flyweight is centered around memory and sharing which may not be an issue for today’s computers, but it still is prevalent within mobile phones. When there is a need to create many objects, that needs memory power to execute but this design pattern focuses on efficiently optimizing that memory sharing which helps boost performance. The application of this design is shown in the blog when it talks about the large number of objects being used by the system and how flyweight will group certain objects together to reuse code to make the entire problem less repetitive. The blog then goes on to talk about the intrinsic and extrinsic states which is explained through the types of data values the objects can hold. It explains how a concrete object may hold an intrinsic state as a value which allows that value to have certain properties. These properties can be extrinsic and be modified as needed.

I chose this article because as I read more about this flyweight design pattern, I realized it also had the possibility for factory implementation as well due to the efficiency with mass object creation. This really interested me since we just went over factories and I wanted some more experience in understanding how factories can be used in other patterns. Though it would just be used to test this design pattern, I thought it was good exposure to how they worked, and it worked well with explaining how flyweight worked. The content was easy to explain with the examples used that had written out code and UML diagrams. The blog used these resources together with JDK to produce an output based off a test class that emphasized the main points of the applications and implementations. They helped cement the idea of factories and code sharing between different objects very well and used similar concepts to those discussed in class. This would affect my future practice by allowing a new view on code reuse which is an important concept. This pattern taught me more about code efficiency using factories and different pattern concepts as well as the idea of objects having different modifiable properties.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.