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.
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.
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.
In her post A Gentle Introduction to Version Control, Julie Meloni gives a very easy to ready walk through of version control. Version control is all about maintaining the versions and revisions of your work as you are developing it. With good documentation, you can bring back old code you previously removed, or look at issues you had in your program in the past to see if that might be relevant to current issues. There are a lot of benefits to maintaining good version control.
Version control can also be useful in a classroom setting. I can recall multiple assignments this year where we used multiple commits with different labels for different assignment levels. In this way, the instructor could look at code from an earlier part of the assignment even when it had to be modified for a later part of the assignment.
Good version control also leaves you with backups if you want to revert to an earlier version of your program. Say you accidentally release an update with a major bug that slips through, you can quickly revert to an earlier version so you can fix whatever issues there are. You can use branches when you want to split off development into different directions and move the changes to main part of your program once you are satisfied, and you can use version control to help avoid any situations where there are conflicting commits.
I agree with Julie when she points out that version control has use in most business and private settings. Really, keeping good documentation of revisions of all documents can help organize your projects and keep them easily modified and reverted. For instance, if you are keeping a financial spreadsheet, but want to save it every month so you can track the differences over time, it is essential to use good version control to keep track of the revisions to the document. Or if you make modifications to a contract, but want to maintain copies of the older versions for legal reasons. Really, good version control is just part of good organization and allowing yourself to work with all the tools at your disposal. You work hard, there is no reason to throw it away.
The post Are Patterns like Mummies? by Michael Stal discusses the patterns from the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, otherwise known as the Gang of Four. This is the book containing the design patterns that we have been studying in class. He discusses how when the book first came out how groundbreaking it was for the software engineering community. Michael also discusses how after the Gang of Four book came out, there wasn’t anything that came after it that had quite as much impact. Michael questions whether more patterns exist, and whether they’ve been documented, or if the book contains most if not all of the worthwhile software design patterns.
The Gang of Four design patterns are basically ways to organize and structure your code in a certain way that solves certain issues you would run into and has certain advantages that can lend themselves to whatever you are doing. The author’s break down the design patterns into three different categories, which are:
Creational patterns deal with the creation of objects, structural patterns are executed through inheritance and interfaces, and behavioral patterns concern themselves with the communication between objects. There are several design patterns within each of these categories.
It is interesting to think about if the patterns covered within this book are the only design patterns (or at least the strongest) within software design. This means every large-scale program is ultimately composed of many components using only the design patterns contained within this book. Is there even a need to define more software design patterns, or can any given program or implementation issue be solved with the patterns found within the Gang of Four book?
I agree with Michael’s closing thoughts about design patterns, I think using them correctly and consistently leads to much more functional code and encourages best practices among software engineers. Whether or not there are more design patterns to uncover, or if we have reached our limit, the patterns we are aware of are still important to use to make communication between software engineers easier.
In the post Grouping Components by Use Case, Robert Annet discusses a strategy he uses when making context diagrams. After determining the use cases of his program, the components involved in each of the seven use cases are divided into groups within the diagram with different colored barriers. Structurizr, the web application Annet used for his diagrams, allowed him to filter the diagrams by the use cases. This makes observing which components are involved even easier visually.
The benefits of using this strategy of dividing your context diagrams into use cases is clear if you are working with a program that is complex enough to warrant it. A complex program in this case being one with a lot of different components which all are involved in several different interactions. If you have to make changes to a certain interaction withing your program, you can look at the components involved in the use cases and identify what you have to change to make the desired effect. Since your program has a lot of different and interlaced interactions and components, using these use cases and filtering your diagram into smaller parts makes it easier to understand the interactions and whats happening with the involved components without being overwhelmed by a ton of different components that don’t have any involvement. In my opinion, it is much clearer when you only have to see two or three components when you want to change an interaction in the program.
Using this strategy can also help you find other issues or reliances in your program. For instance, you may find that most or all of your use cases use the same component. Since this component is so integral to the interactions in your program, it is likely not one you are going to want to change much. This strategy also can help you find components that are not being used in your program, and thus may be unnecessary or you may need to reassess your use cases.
Overall, I thought Robert Annet’s idea of dividing programs into different use cases is very interesting and obviously useful as a concept, so I’m sure I’ll use in the future. Whenever you are dealing with a large enough system, you should consider looking at the diagram from this angle to see if you can identify any problems or vulnerabilities.
The State Behavioral Design Pattern is one of the GoF Design Patterns. In his series on the Gang of Four design patterns, John Thompson wrote an article on the State Pattern, which he defines as “an important pattern that allows an object to change its behavior when it’s[sic] internal state changes.”
He opens the article by providing an example of a Vending Machine program that will need the State Pattern to be applied to it. One thing I like about the way he writes his examples is how he uses variable names to make it very readable. He could have just had the states as the integers themselves, but his simple and clever use of variable names has given me ideas of how to make my programs more readable in the future.
In order to transform his Vending Machine program from a “monolithic class” into a more adaptable program, John shows us how to implement the State Pattern. He separates each of the four states of the vending machine into their own classes. They each implement an interface that defines the behaviors of the vending machine. These state classes each detail how they handle the behavior in that state. Finally, the vending machine itself which handles the inventory of the vending machine and has methods a lot of methods to handle changing the state of the machine.
Due to designing the code with this pattern, you can add a new state by creating a new concrete class and modifying the vending machine class to handle it. However the currently written states are closed to modification as well, following Open Closed principle. When you compare the example before and after the State Pattern was applied, it becomes apparent why it is so beneficial to use this pattern when it’s appropriate: it makes your code more open to modification and more easily-understood. You don’t have to spend as much time reading and understanding code under the State Design Pattern, and so it helps make your program easy to maintain, especially when multiple people might be going back to the code later. Having more classes isn’t necessarily a bad thing.
In this week’s blog post I decided to share an informative post by Henri Idrovo on dev.to detailing the implementation and usage of the factory design pattern, specifically the “Factory Method.” Henri starts the blog by introducing the problem the factory design pattern is aiming to solve: using the ‘new’ keyword creates dependencies on concrete classes within our program. When many new objects are being created, this tends to get out of hand. Henri introduced the dependency inversion principle, stating “Depend upon abstractions. Do not depend on concrete classes.”
To show how to implement and improve your code using the factory design pattern, an example is introduced that involves a Pizza Store that has to create different types of pizzas. Without the design pattern in place, every type of pizza you would want to make would require another if-statement, so clearly something needs to be fixed. In order to use the factory pattern, we need to separate what is likely to change from what is not, and put what will change in a class of their own.
In Henri’s example everything that is common to pizza creation is placed in an abstract creator class, and the specifics are placed in concrete creator classes that extend the abstract class. Similarly, the different kinds of Pizza are each given their own concrete product class that extends the abstract Pizza class.
The factory method seemed hard to understand at first, but after going through the examples given in the blog it became clear to me, and the advantages of using the factory method are clear. By relying on abstractions instead of concrete classes, you are removing dependencies within your code and making it much more open for modification. Whereas prior to applying the method, the handling of creation of pizza objects was handled within the PizzaStore class itself, it is now handled within concrete sub-classes that can also handle different categories of pizzas. Also, personally it is easier to read the code of the PizzaStore class after applying the factory method, and it is much more clean in the abstraction. I can see the factory method being useful in any situation where you have to deal with the creation of a lot of categorically related but different objects.
Hello! My name is Nicholas Coutu. I am a senior attending Worcester State University. I major in Computer Science with a concentration in Software Development and am also attempting a minor in Mathematics. I intend to use this blog to record my opinions on various articles related to my classes throughout my final year, and have further plans to use this blog for my professional career to document my work-related activities.