Category Archives: CS-343

Two-Factor Authentication

For my final blog post of the year, I wanted to select a more interesting topic. The article Two-Factor Authentication with Node.js by David Walsh covers two-factor authentication and shows how it works behind the scenes using JavaScript. He even includes examples of how to implement two-factor authentication using QR codes.

Two-factor authentication is a user-verification method used by many web applications and services today. When a user tries to log in, a verification code is sent to a previously specified external device or address, such as a phone number or email. This code usually expires after a set time. The user that requested the code then enters it in the application or program to verify themselves and gain access to their account. By splitting access to your account into multiple different forms, you greatly increase the security of your account. Nobody can log into your email, even if they know the password, if you have two-factor authentication that is being sent through SMS.

David Walsh explains how the system of two-factor authentication is divided up behind the scenes. The first step is to generate a secret unique key for the user to validate two-factor authentication codes in the future. Then, you must add the site to your authentication. Finally, this code must be provided by the user and then validated to confirm it matches what was expected. If not, the user can try again with a new key. Since most two-factor authentication services refresh the key every few seconds/minutes, it is not necessary to lock the user out if they get one wrong.

Two-factor authentication is an incredibly powerful and important new form of security that allows you to put an even tighter lock around your information. As a developer, it is important to consider allowing your users to use two-factor authentication for your application, especially if any sensitive data is stores or if access to your account leads to vulnerabilities in the system. It’s one of those things you don’t realize is so important and valuable until you get your account stolen and realize it could have been prevented.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Back to Front

In his post Back-end Development vs Front-end Development, Mikke Goes explains the differences between back-end and front-end development. He also goes into detail about the places where they intersect. Mikke also speaks briefly on combining both areas of development into what is known as full-stack development.

Back-end development concerns itself with the storage and manipulation of data. For example, when you log into your email, your browsers sends a request to the server to return all the information concerning your account, such as your settings and inbox. The mechanisms behind the storage and transferring of this information is the back-end. Back-end development concerns itself with the parts of a program you don’t usually see, but does a lot of work behind the scenes.

Front-end development finds its responsibilities mostly in the visual aspects of your program or application. All the buttons, text, and input fields on a web page are designed by front-end developers. This gives the users ways to interact with all the information stored in the back-end, creating an interface that bridges the gap between the client and the server. Both the functionality and appearance of web pages can fall under the duties of a front-end developer.

Full-stack development puts it all together. This is an understandably powerful position to operate in, as working on both the front- and back-end together ensures that they will be designed with each-other in mind and written properly and effectively. In CS-343 this semester, we have to work on a project where we are effectively full-stack developers. It is challenging to have to work on both at the same time, but I think working on one helps your understanding of what needs to go on the other end to tie everything together.

Front-end and back-end development are both important concepts. A web application isn’t going to exist without one or the other, and both are ultimately just as important to the end result as each-other. The differences are apparent, which is why it makes sense some people make a living doing one or the other. Ultimately, Mikee makes a good point that understanding both types is a boon to learning how to develop web applications.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Model-View-Controller

On his blog, Mikke Goes takes the time to explain the Model-View-Controller design pattern in his post What is the Model-View-Controller (MVC) Design Pattern?. He uses the analogy of an ice cream shop to describe the different functions of the components. The waiter is the view, the manager is the controller, and the person preparing the ice cream takes the role of the model. Together, when a customer makes an order, they each can perform their responsibilities and successfully handle the customer’s request.

The Model-View-Controller design pattern separates the components of your code into sections that divide logic from interface. Keeping the functionalities separate from each other will make your application easier to modify in the future without running into issues. Each of these different groups has a different responsibility when it comes to the application and how requests are handled.

The view consists of the parts of your application that your user will see and interact with. It is not very smart, only outputting the information given to it by the controller. The view helps users make sense of the logic behind your application and interface with it.

The model is the opposite, dealing with all the logic and data manipulation behind wheels of your application. The model responds to requests by processing any data in the necessary ways and giving it back to the controller in a form the view can understand.

The controller handles the communication and interaction of these two. When a request is put in through the view, the controller brings this to the model, and takes the model’s output back to the view to be displayed. It is a middleman that helps connect the two other layers of responsibility.

The Model-View-Controller design pattern seems like a pretty simple design pattern to comprehend. All of the components are divided by responsibility and the program is written with this in mind, making sure that only certain components handle tasks that are within their category. In terms of our projects, the front-end would amount to the view and the back end to the model, with the typescript file functioning as the model. It seems like the development of web applications would sort of naturally fall into this design pattern.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming

I am writing in response to the blog post at https://blog.codinghorror.com/your-code-oop-or-poo/ titled “Your Code: OOP or POO?”

Most of the code I have ever written has been founded in the imperative programming paradigm. I began pulling concepts from object oriented programming in the last few years to help organize large projects and keep the structure of things more adaptable. It is a useful way to develop a large framework, but relying on objects for absolutely everything seems like it would tend to cause a lot more problems than it would ever be meant to solve.

This blog post refers to “POO” as “Programming fOr Others”, as opposed to plain Object Oriented Programming (OOP). One of the purposes of object oriented programming, and one of the reasons it is such a dogmatically adhered-to convention, is that it makes it a lot easier for people who did not write the code to understand what it is doing and work with it themselves. The blog post discusses on the topic that object oriented programming can be over-used, and it is not the only solution to writing code that is readable and easy to be understood by others.

There was an excerpt about how there was a type of programmer who would only write five or ten lines of code, preceded by twenty lines of comments, and object oriented programming basically allows the two to be combined. Instead of concise code accompanied by an explanation, there is a large file filled with descriptive language embedded into the structure of the code itself.

Another excerpt mentioned the use of object oriented programming for trivial tasks. I do not think that it makes any sense to go through the effort of supporting scalability and maintainability for something that can be started and completed and discarded so easily without the extra work. A simple command line in an imperative programming language would be far more practical for basic tasks.

Part of the argument made is that a programmer should focus on the principles of object oriented programming, rather than the name. Encapsulation, simplicity, code re-use and maintainability are the main ideas, not just objects.

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

Using Swagger for API Documentation

As we are nearing the end of the semester and about to finish our projects, I’ve been thinking more about the documentation process for the different parts including the frontend and backend. With this in mind, today I found a great topic about documentation generation for REST APIs with a tool called Swagger. I’ve never heard of Swagger before today, but it is a useful framework that allows for testing, documentation, and other useful features for building APIs. This post shows a quick little tutorial of how to implement Swagger for documentation generation with a Spring Boot project that is very similar to my project and the example REST API order system we have been using. It is a relatively simple process that includes adding the necessary dependencies for Swagger and adding a controller class for it, then all you have to do is just add the necessary documentation statements for each controller and requests within the controllers. The end result is a very nice-looking HTML page that displays a well formatted layout which includes the documentation for your API backend with a graphical display for each request and all the information associated with the request such as body and return information. Now as I was reading this article and this new way of creating documentation, I was comparing it to the way we’ve been doing it so far with a simple table written in Markdown for all of our API endpoints. The output of doing it in Markdown was nice but writing it was a tedious task with the formatting of the table. I much prefer the simplicity that Swagger allows you when adding a new endpoint. I also like the final product that Swagger produces a lot more than the simple Markdown document. In the future if I am creating another Spring Boot project, I am going to try to use Swagger from the start for documentation instead of using a Markdown document with a table for a basic readme as it appears that using Swagger makes adding new endpoints much less tedious with formatting. I would also like to try to add this to my current project if there is enough time, and also see if it is possible to use it with Angular too.

Source: https://dzone.com/articles/swagger-generation-with-spring-boot

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

Parsing HTML and the Document Object Model

In A List Apart’s series “From URL to Interactive“, Blogger Travis Leithead describes in his article “Tags to DOM” how HTML documents are parsed and converted into the Document Object Model (DOM). Through the course of his post, Leithead explains encoding, pre-parsing, tokenization, and tree construction.

The first step to parsing an HTML document is encoding. This stage is where the parser must sort through each part of the input and sent from the server. Since all information computers handle is binary, it is the parsers responsibility to figure out how to interpret the binary stream into readable data.

After all the data has been encoded, the next stage is pre-parsing. During this step, the parser looks to gather specific resources that might be costly to access later. For example, the parser might select an image file from a URL tagged with a “src” attribute.

Next, the parser moves on to tokenization. This process is when all the markup is split up into discrete tokens that can be organized into a discernable hierarchy. The parser reads through the text document and decides which tokens to declare based on the HTML syntax.

Once all the document has been tokenized, each token is organized into what is called the Document Object Model, or DOM. The DOM is a standardized tree structure that defines the structure of the web page, organizing it into sections with a parent-child relationship. The root of the tree is the #document/<html> tag, and its children are <head> and <body>, the body may contain multiple children, and this organization contextualizes the data into a readable layout. The DOM also contains information about the state of its objects, so this allows for a degree of interaction that make complex programs.

I would highly recommend this article and this whole series to any budding developer such as myself, as understanding the entire process of how programs transform from code to an interactive website is integral knowledge. And the authors at A List Apart do a great job being both thorough and concise in their explanations. I definitely feel more knowledgeable after having read this article and found it valuable.

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

Deceiving a Deceiver

In my second blog post for the week (because I procrastinate any and every assignment), I am going to write about the topic of cyber-security today. I stumbled upon an article that was talking about this exact topic. The article is titled “Computer hackers could be thwarted by new ‘deception consistency method”. This title stood out to me because it may be a way to stop computer hackers almost entirely, so I decided to give it a read. The article turned out to be very short and to the point which is admirable, but it does make it a little harder to write about.

The abstract of this article leads of with “Can you deceive a deceiver?” and I absolutely love that phrase because it is like a PG-13 version of another phrase that I won’t mention here for the sake of professionalism. Anyways, the article mentions that the study by Assistant Professor of Computer Science Guanhua Yan and PhD student Zhan Shu at Birmingham University. They want to figure out a way to more effectively against malicious hackers. It was inspired by a data breach of Target in 2013, which cost them around 18.5 million dollars. They explain the concept of cyber deception is and I find it to be an interesting concept. To put it simply, it is putting the hackers in a fake environment to make them think they are in the system, but in reality, they are in some fake system. They mention that the problem with deception currently is that there are “bad lies” that make it blatantly obvious to hackers that they are in a fake environment.

The two decided to develop a deception consistency method, which they then tested on college students who recently completed a cybersecurity course, and the results were very positive. Most of the students were unable to recognize that they were in a fake environment, and that most of them just guessed. While this is a step in the right direction, the is not a “cure-all for things like what happened to Target and Equifax.”. They did say that they would continue to improve the effectiveness of the method to stop the more advanced attacks.

I thoroughly enjoyed this article because I do want to learn more about cyber security in the future. I find it interesting that hackers can be mislead like this, and still think they are in a system. I don’t really have too much prior knowledge on cyber security, but this has definitely raised my interest about the subject. I don’t disagree with any of the information. These two researchers did an excellent job on this study, and I encourage you to take a look at this article.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Top 5oftware Architecture

CS SERIES (13)When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.

If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.

The fives types discussed in the article are:

  • Layered (n-tier) architecture
  • Event-driven architecture
  • Microkernel architecture
  • Microservices architecture
  • Space-based architecture

The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.

Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.

Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.


Article: https://techbeacon.com/top-5-software-architecture-patterns-how-make-right-choice

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

Copy Pasta: Te AntiPattern

For this week’s blog post I will be taking a look at another antipattern, another very common AntiPattern that creates maintenance nightmares. It usually takes the form of several similar segments of code that are interspersed throughout the software project. Programmers who are learning how to develop software who are following the examples of more experienced developers usually fall prey to this unwillingly. They do this by modifying code that has worked for them before in a similar situation and they think by potentially customizing it to support new data types they can get by but this causes code duplication which may cause positive outcomes but long-term problems. Symptoms of this antipattern include the same software bug that reoccurs throughout the software despite local fixes, lines of code increasing but overall productivity not being affected. Essentially this antipattern re-uses code that you may or may not need adding to your lines of code without any actual assistance being provided from the length. The most common cause of this is a lack of abstraction among developers who are often accompanied by a poor understanding of inheritance, composition, and other development strategies. And is most likely to occur when people are unfamiliar with new technology or tools as a result, they take a working example of something and modify it, trying to adapt it to their specific needs. Some solutions to this involve white box reuse through the developers extending systems primarily though inheritance. On the other hand of this black box reuse has other advantages such as the object is used as-is, through a specified interface where the client is not allowed to alter how the object interface is implemented. In a way this antipattern is very similar to spaghetti code but spaghetti code is not structure for easy component reuse because of this Cut and Paste Programming is the only means available for reusing preexisting lines of code.

https://sourcemaking.com/antipatterns/cut-and-paste-programming

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

Why favor composition over inheritance?

In the early stage of software engineering, there was no such thing is composition or inheritance, it only exist in the context of object-oriented programming. When object-oriented programming was introduced, every one pretty much ignored it until user interface heavily based on it. One of the most popular object-oriented design principles is to favor composition over inheritance.  I have been asking people about the advantages of using composition over inheritance and the answers always suggest that it makes your code so much simpler and increase its flexibility. That is somewhat an acceptable answer, but I thought, to convince you, I would need more than just simpler and maintainability, so I found a this article that provide five reasons and I will summarize it.

Firstly, there are a lot of object-oriented programming languages out there, but let’s take Java for consideration, since a lot of developers (including the new one) know how to use it. With composition, when class A uses the functions of class B, it doesn’t inherit class B, but instead, it sees class B as a variable or an object. This is why it is called “composition”. It is suggested to use composition and that does not mean inheritance is completely useless. While inheritance is referred as IS-A relationship, composition suggests more of a HAS-A relationship. With IS-A relationship, an instance of the sub class to a function as a parameter, which accept instance of the super class, offer somewhat of the flexibility.

On the other hand, the fact that people prefer composition, especially in Java, is that most of the time it does not support multiple inheritance. To be clearer, sometimes you need to use multiple function, but you can only extend one of the two classes that offer these two functions, that would cause a lot of pain to go through. For example, if you want to read and write a file, you probably want to reference the two objects and call the function from there, while it is almost impossible to extend the read and write class at the same time to call their functions. Composition also offers more test-ability than inheritance. While you only need to create a Mock object that represent the composed class for testing, in order to test the sub class, you would need the super class to be available at the same time. Flexibility is the most important one to talk about. Although both allow developers to reuse code, inheritance is more likely to break encapsulation. Because sub class heavily depends on the super class, even a slightest change can alter or break the functionality of the sub class.

There are a lot more reasons to consider composition over inheritance and you probably will discover it by yourself on your way making your own program. However, it is important to keep in mind these reasons so that you would not make a mistake when you start developing.

From the blog #Khoa&#039;sCSBlog by and used with permission of the author. All other rights reserved by the author.