Lights Camera Action – Model View Controller

https://www.leepoint.net/GUI/structure/40mvc.html

 

A lot of the focus on the end of the year is around the Model View Controller pattern. Our projects have been based on it as well so it is something that we put a lot of focus on. While studying for exams I like to find relations in things that help me to remember them. I thought that the Model View Controller reminded me of a movie production. All the little pieces fitting into their spots so that the whole thing works flawlessly.

MVC, Model View Controller is like the director hierarchy of a coding project. View is similar to the camera being used in a film. It doesn’t know about the controller except for providing methods for the user to use the information. View is used to display all the information that the user needs to see. Basically a more front end version of the code. Where the controller is like the director. When the cameras are rolling the director commands what to do next. Similar to the controller which activates when the view model has a user. It also contains all the relative information to control the operation and make everything run smoothly. Finally Model which is like the set, and actors of a movie. Overall the model contains all the information that is needed for the production or program. Inside of the model is the constructor and the methods needed to be called upon. The article listed also explains the structure in simple terms: “The idea is to separate the user interface (the Presentation in the previous example) into a View (creates the display, calling the Model as necessary to get information), and Controller (responds to user requests, interacting with both the View and Controller as necessary).”

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

ngIf, Else, Then

In this weeks blog I will be taking a look at Agular’s NgIf, Else, and Then directives and the different syntaxes that can be used to better deal with conditionals and asynchronous objects. The ngIf directive when placed on a component will hide or show the details of that component or element based on the expression that you pass it to be evaluated. If the expression is evaluated to true, Angular will add  your DOM nodes and mount or remount your components. Another reason to use ngIf is the availability to invoke relevant lifecycle hooks such as ngOnInit and ngOnDestroy. The most standard use of ngIf is to provide a “true or false” type expression based on an evaluation. A common example of the standard use of ngIf would include:

@Component( {

Selector: ‘app’

Template:

Welcome back!

This basic use of ngIf check to see if the user is logged in and if so, Welcome back is displayed.

The next form that can be used is *ngIf and Else. The else statement makes it easy to provide a strategy that Angular can follow if the first *ngIf expression fails or is invalid.

<div *ngIf = “isLoggedIn; else loggedOut”

Welcome back!

</div>

<ng-template #loggedOut>

Please Login

</ng-template>

Here *ngIf is used to see if the user is logged in else it used the local reference of #loggedOut to tell the user to login.

 

One of the final variations of the ngIf directed is *ngIf, Then and Else. Using then alongside ngIf moves out ignition *ngIf template outside the element we’re binding it to. This allows use to dynamically change the template reference to then, swapping ng template as we go.

 

<ng-container>

*ngIf= “isLoggedIn; then loggedIn; else loggedOut”>

</ng-container>

 

In conclusion, ngIf is a versatile directive that can have many use cases apart from the code above and is a great way of providing If, Else, Then statements to your Angular application.

 

https://toddmotto.com/angular-ngif-else-then

From the blog CS@Worcester – Jarrett&#039;s Computer Science Blog by stonecsblog and used with permission of the author. All other rights reserved by the author.

Testing with Dummys

Today I will be talking about testing software! More particularly, testing by using dummys! So what exactly is a dummy and why do we use it in testing. Dummys are objects that are created for the purpose of testing but are actually never used. Think about it like a mannequin. The mannequin displays the clothes as how they would look on a human, but the mannequin is not actually a functional human, and does not actually use the clothes. Its only job is to make sure the clothes look (or function for the sake of testing) correctly. According to this blog by Tom Winter, “How our test data generator makes fake data look real”,  our test generator makes fake data look real for the purpose of testing our code. Why would we ever want to test fake data? The easy answer is this: sometimes we do not have all the data or all the code finished, and we want to test our code without having to play the waiting game. Sometimes it is even impossible to test our own code without dummys because we do not have access to the actually data. So we use these dummy objects to play the role of the real data (which we do not actually have access to, remember?) in order to test our code to ensure it functions properly.

Testing with dummy objects is something we have been doing in my software program at school, and I happen to find it very useful in the sense that I do not actually need the data to make sure my code works. Not only does this help pick up testing efficiency,  but it cuts down on the overall wait-time between developers and getting their product out. On the flipside of things, if another developer was waiting for me to finish my code before testing, they could use a dummy to test their code instead of rushing me to finish, which could possibly lead to me making mistakes and end up slowing down the entire development process. I enjoy being able to test right away, and using dummys can help with this. I hope to continue using dummy testing in the future, as it is an easy and very effective method of testing!

Here’s the link: https://medium.freecodecamp.org/how-our-test-data-generator-makes-fake-data-look-real-ace01c5bde4a

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.

It’s Alive! Mutation Testing

http://pitest.org/

Mutation testing is something that we learned the last day of classes. In a short and simple definitions mutations are seeded into your code and then tests are run on that mutated code. If the mutated code fails the tests you have then a mutation is killed, and if the mutated code passes then the mutation lived. From here you can gage what kind of quality your code is, and how well it responds to mutations. The higher percentage mutations killed the better overall quality is you code. However what are mutations exactly? Mutations are automatically modified versions of your code that make changes with the intention of making your code fail. The code that is changed is then called a mutation. The reason that you would use mutation based testing is to make sure your tests are capable of finding faults. Traditional test coverage measures only what code is executed by your test. Mutations are particularly useful in testing tests with no assertions, and partially tested code. Partially tested code being only testing certain branches of code and not all of the branches. A leading brand name and common mutation test suite is PIT what puts PIT ahead of the competition is its fast, easy to use system that is actively developed and supported. Pits UI is not complex and shows an easy to read file of mutations.

photo

Mutation testing is a fun gimmick of a name, and also a useful tool for testing the validity of your code. Expanding beyond just expected to results but to unexpected results.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

To be a Front-End Developer

Having just finished our final web application project presentations this past week, I believe this article was extremely necessary. In this final project, we were able to explore the methods to make a (mostly) functional web application, from the back-end to the front-end. We learned how hard both ends can be, but I found that the two are completely different from each other in importance. The back-end is how information from the web application will be stored to the local server. Meanwhile, the front-end is how the web application looks and is seen by it’s users. As Ronald Mendez describes in his blog post, “Owning the Role of the Front-End Developer”, it can be a very difficult time when you control the development of the front-end.

The front-end is important to all developers of a product. It is important to the sales team, the marketing team and the entire web development team. However, the front-end work is usually done at the very end of the development period. This can leave many front-end developers to feel left out of the development process and practically useless to their teammates during most of the development. Mendez found himself feeling this way many times in his career of working as a front-end developer until he learned how to speak up and keep his team motivated as they worked on different web application projects.

It’s fair to say that the modern developer can’t simply hide behind a keyboard and expect the rest of the team to handle all of the important decisions that define our workflow. Our role requires us to go beyond code, share our ideas, and fight hard to improve the processes we’re involved in.

— Ronald Mendez

I found this article to be incredibly applicable considering all of the work we had just finished on our own projects. We did both the back and front-end developments ourselves, but I can see how the front-end development can become tossed to the side when the core of the work is in the back-end and making sure the website actually functions the way it is supposed to. All in all, I believe Ronald’s advice is important to those seeking roles as web developers specifically.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

To All Software Engineers

As we end the semester, I thought it would be interesting to see what other software developers have been able to take away from their experiences in the field. The advice I found came from the blog post “The One Thing Every Software Engineer Should Know“, written by software developer Jeff Atwood.

In this blog post, Atwood shares advice from his personal experiences in the software engineering field and sheds light for those of us just getting started in the world of technology. He specifically highlights the advice of a former software engineer for both Google and Amazon, Steve Yegge, who says:

If there was one thing I could teach every engineer, it would be how to market.

This is something that some of us may have never thought of before, but it’s becoming more and more important as we continue to advance in technology. It is also the reason that many Computer Science majors insist on receiving an MBA (Master’s in Business) following undergrad. We may be the best software developer or engineer, but what does that mean to people who are not in the tech world? Sure, they know that we are able to program and fix almost anything, but how does that help them? How does the code we produce help them?

To answer this question, we as the new technological work force must add marketing to our skill set. Having the ability to market your own personal skill that has helped you to create and develop a product is amazing. With this skill, we are then able to show more companies that we are valuable as both software and sales engineers and capable of understanding what our software actually means beyond the coding aspect.

I found this article incredibly interesting considering how it attempts to bridge the gap between technical and non technical fields. Most buyers who are looking to buy software for their companies don’t know what certain specifications of the products mean. Being able to market your product to them in a way that they will understand makes you a better software engineer and sales engineer.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Journey into Mutation Testing

As I take another step towards Software Quality Assurance Testing. The blog I will talk about is “Mutation Testing: Watching the Watchmen” by Jasper Sprengers.

This blog is about an automated (unit) tests more commonly known as a mutation testing framework. This is a testing tool that purposely insert small changes that would cause a change to the the original code in order to verify your code against the intentional bugs that are created through this mutation testing framework. This testing framework is used in order to test and improve your code in a fun way. The writer also tries to stress the importance of unit testing and how integration testing is just as important if not more. Testing is important because it helps provide quality to your code. In order to be able to test your code you must understand it and what it is meant to do. It also covers “How to make sure our test are any good?”, that would be good code coverage and making sure test suite are testing a wide range of code that assure that most of your code is tested and that test are checked.  Using mutation testing is a pretty good way to make sure you have successfully written good test. Since mutation testing purposely changes your program test to cause it to fail. When test successfully fail then that means that a ‘mutant’ was successfully killed. If test pass then that means that a ‘mutant’ survive which means a mutant was not successfully killed making your test a not so good one after all. According to the writer a “useful mutation testing framework for Java is pitest.org“. In summation of what is talked in the blog using mutation testing framework would make you test your code more seriously without using shortcut.

I found this blog to be very interesting and useful. I like that it stresses the importance of having good test suites to insure quality and how it mention that using mutation testing framework will help insure that you have good test suites. I found the link to a mutation testing framework very useful.  I do not disagree with much of this blog. In fact I find it interesting enough to recommend others to read it. The title of the blog above provides a link to the blog, I suggest you check it out. Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

 

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Security Breaches and User Information

User data that is stored on websites is very important to keep secured. Although there are some technicalities when signing up for websites that allow you to upload pictures, movies, or other media, you should always take certain precautions when uploading anything to online. Security breaches are no surprise and with massive social media websites such as Facebook, Twitter, or Tumblr, there are bound to be hackers trying to break in the back end to rob and dump data. Unfortunately, breaches like this aren’t too uncommon. Just recently, Facebook was hit with an enormous security breach. About 6.8 million users’ data have been exposed. With a company as large as Facebook, you would think that their security and software back-ends would be able to block attacks, however this is obviously not the case. So what exactly happened? A bug slipped through in the API, an overlook by the software QA team at Facebook.

Facebook released a statement saying that their Photo API had a very vulnerable bug that let app developers access the photos of over 6 million users. The worst part of it was, the bug wasn’t noticed until 12 days after it had occurred. Not only were the users of Facebook affected, but app developers that utilized Facebook’s Photo API also suffered the consequences of this too. Reportedly, there were over 1500 applications that utilized this API.

What can we learn from this? Software testing is not exclusive to how code or programs run, but it also applies to security. There are teams that are dedicated to only testing for security and backdoors in programming for this reason – so the end user can be confident in their products. One small error in the quality of Facebook’s Photo API caused a major breach with a ton of collateral damage. Over 700 app developers and over 6 million Facebook users were affected by this. Interestingly enough, this isn’t Facebook’s only massive data breach in recent times and their end users are definitely not happy about it. Repeated vulnerabilities like are not good and are detrimental to a software’s future in quality and security. Making sure that you have protocols in place that check for these is very important to avoid these types of situations.

 

Article: https://fossbytes.com/facebook-hit-by-another-security-breach-6-8-million-users-photos-leaked/

From the blog CS@Worcester – Amir Adelinia&#039;s Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Procedural and Object Oriented Programming

I am writing in response to the blog post at https://www.codementor.io/learn-programming/comparing-programming-paradigms-procedural-programming-vs-object-oriented-programming titled “Comparing Programming Paradigms: Procedural Programming vs Object-Oriented Programming”.

Object oriented programming seems to be the focus of all that is ever taught in a computer science course after the basics of syntax and control structures are covered, which are the basis for procedural programming. The shift into object oriented programming seems to mostly be for the sake of establishing proper design principles such as encapsulation and normalization to reduce redundancy, but these are not mutually exclusive features of the object oriented programming paradigm; it is still entirely feasible to write procedural code that is still “good” code.

The blog post does not directly define what procedural programming is about, but it alludes to the writing of straightforward code that makes use of variables, scope, functions and control loops. Then comes the brief anecdote of writing thousand-line long programs that start to become difficult to maintain, and how the object oriented programming paradigm is the solution. Object oriented design is definitely helpful for improving the scalability of a large program by introducing better organizational practices to the code structure, but the principles of encapsulation and modularity can be applied directly to the poorly maintained program anyway without changing paradigms. This is not to say that object oriented programming is bad or unnecessary, but the point is that procedural programming is not bad and does not need object oriented programming to “fix” it. Procedural code happens to be the most common poorly written code because it is most commonly used by beginners, who learn about better coding practices once introduced to object oriented programming.

Some of the faults with object oriented programming are described in the blog post, adding that it is not the best idea to avoid the use of procedural programming for the sake of adopting the exclusive use of object oriented programming. Modularity regarding class extensions and modification of a class can make things difficult in languages that focus on object oriented programming, where overriding a method or re-implementing a class may have adverse effects on subclasses. It is ultimately decided that multi-paradigm programming is a good choice, where the benefits of procedural and object oriented programming can be combined.

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

Positive and Negative Testing

I am writing in response to the blog post at https://www.guru99.com/positive-vs-negative-testing.html titled “Positive Vs Negative testing”.

Positive and negative testing have some features in common with the details of boundary value testing that we covered in class. Robust boundary value testing, in particular, tests values not only on the boundaries but also inside and outside of the boundaries. Testing input values that are inside the boundaries is called positive testing, and testing input values that are outside of the boundaries is called negative testing.

The blog post confirms as much. Positive testing is about providing valid inputs and testing that the application behaves as expected. Negative testing is about providing invalid inputs and testing that the application does not do anything that it is not expected to do. Boundary value analysis and equivalence partitioning are listed as techniques for positive and negative testing. Testing input data that is chosen within the boundary qualifies as positive testing, and testing input data that is chosen outside the boundary is negative testing. Equivalence class partitioning has partitions that are also valid or invalid based on whether they are inside the boundary. Testing valid partitions is positive testing, and testing invalid inputs is negative testing.

“Positive testing” and “negative testing” are separate types of testing by themselves, but it does not necessarily make sense to only use one of them; they do not provide a complete analysis of the program’s behavior. Positive testing will yield no conclusions about the behavior of the program given invalid inputs, and negative testing does not verify that the program behaves as it is supposed to when it is given valid inputs. Boundary value testing and equivalence class testing are specific methods that use positive and negative testing, and the process of testing inputs directly falls under black box testing, which does not make the distinction between whether an input is categorized as valid or not, only whether the program behaves correctly. Doing both positive testing and negative testing will provide sufficient information about the behavior of the program to be confident about whether the program is going to behave correctly.

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