Front end and back end development get thrown around a lot, but I never really understood the difference. Therefore, I decided to do some research and figure out what front end development and back end development are, and what the difference between them is.

Let’s start with front end development. Front end development, also known client side development, deals with the user interface. The user interface, or UI for short, is what the user gets to see and interact with. Front end developers are responsible for designing and creating the user experience elements in a program. Front end developers may find themselves using technologies like Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript to implement features such as buttons, menus, pages, and so on. The goal of front end development is to create attractive, simple, and easy to follow interfaces for users. However, achieving this goal can get quite complicated due to a major challenge. This major challenge is the sheer amount of variance in devices. Not all devices are the same. There are devices that are big and small, fast and slow, and new and old. Guaranteeing a consistent experience across all devices and platforms is a very difficult task but is an essential one. This gets further complicated with the rapidly evolving technologies, standards, and practices.

Now, back end development, as you might have guessed is the complement of the front end development. If front end development deals with things that the user can’t see then back end development deals with things that a user cannot see. Back end development, also known as server side development, deals with servers that provide data on request, the applications which channel those requests, and the databases which organize the information. Back end developers might find themselves using databases such as IBM DB2, MySQL, and NoSQL as well as a bunch of programming languages and frameworks such as Java, Python, and C++. The goal of back end development is to design and create applications that can accurately locate and deliver data to the front end as smoothly as possible.

While developers usually just specialize in either front end development or back end development, sometimes employers need developers who are proficient on both ends. This is known as full stack development, and these highly specialized developers are known as full stack developers. Their job is to use their deep knowledge to suggest ways to make the development process more efficient.

https://www.conceptatech.com/blog/difference-front-end-back-end-development

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

In class, we’ve been using vue.js. Vue.js seems to have many similarities to React, so I thought it would be informative to briefly discuss how to implement React components. Vue.js seems to also use components, so I thought it would be helpful to explain a common concept that seems to exist between the two.

I open visual studio code, and open the terminal. To create a react app, I typed the following commands:

• npx create-react-app reactapp
• cd reactapp
• npm start

After React finished installing, I changed my App.js to this:

This component’s render() function will display the content on the webpage using JSX¹. There is currently nothing but an empty screen. Instead of writing everything inside a component, we should segregate the information into separate components, that would then be called in this central component.

For this example, we’ll create a webpage with four parts: a header, a navbar, a side pane, and a main pane. Each component will contain its own js file. Since we’re making a very simple web page, the header will be a simply designed bar. I created a blue bar in Paint, and I imported it using CSS. The header will contain a title, and compose the top of the web page.

Below the header should be the navigation bar. For the sake of example, the navbar here will just display the formatted text on it. The navbar would in practice function as a transition between web pages.

Next is the side pane. This side component on a website could function as a way to automate section traversal, as is done on a wikipedia page. If the main section has a title such as “Lorem Ipsum”, it would list “Lorem Ipsum” with the ability for a user to highlight and click on it. Like the navbar, we’ll only create a very simple display.

The final component is the main component. This component will be where we put our text. I created a title called “Lorem Ipsum”, with some body text.

We now need to add our components into our previous App.js file. The top will contain the header and the navbar, and the body will contain the side pane and the main pane.

Finally, we need to create the CSS. For my design, I am using this inside of the App.css file, which is then imported into App.js.

For our product, we get this (the bottom part was cut in the screenshot for space):

While it’s not winning any awards, it’s a draft of a simple website design. This illustrates how components work together, in a library like React, and I hope this helps with understanding vue.js too.

Link:

1. https://www.youtube.com/watch?v=w7ejDZ8SWv8 (For discussing how components and JSX work, so I could make this guide!)
2. https://reactjs.org/tutorial/tutorial.html (ditto)

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

In my previous post I linked an article I read about some basic things that I should know about JavaScript in my attempt to get more familiar with the programming language for my computer science course this semester. This post is a continuation of the last and necessary to getting me up to speed with JavaScript and how my course is using it. So far I have only programmed in languages like C, C++, Java and not a typescript based language. The languages I used were more object oriented and I came across this article below that caught my attention. That you shouldn’t use classes in JavaScript.

https://javascript.plainenglish.io/why-you-should-not-use-classes-in-javascript-ca960d13c625

Funnily enough the article starts off with a mention to Scheme, the first programming language I learned in a college education setting and a language I never touched again after that semester. It turns out according to the article that JavaScript itself was supposed to be based on Scheme. So, here’s hoping some of what I learned from Scheme will be beneficial down the line when I learn more about JavaScript.

One of the main issues described in the article relate to binding. That with JavaScript even referring to an object that was class defined requires the exact context in relation to it’s call. In his example it shows ‘this’ being used three times just inside the constructor method for creating the function. I haven’t really ever seen a class defined yet in JavaScript so all the humorous jokes about the language I have seen so far are starting to make a bit more sense (like an endless chain of this.myfunction.this.myclass etc etc).

Another Issue raised in the article is the fact that you apparently cannot create private variables in JavaScript. In the example shown it makes it pretty clear. I was honestly kind of shocked considering it is such a common thing used in every other language I have learned. This is definitely something I need to remember about JavaScript to avoid future errors if I ever have to create a class and intend to use encapsulation.

This article ends on the note that the author has a preference for factory functions, a topic I had only heard of and learned during this semester. While the list of reasons to not use a class are I feel minimally an issue it does help me understand that JavaScript is generally less focused on class based structures and more focused on just using objects to avoid some issues from JavaScript and issues from OOP in general.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

When my instructor introduced technical debt, he described it as poor design choices that delay the productivity of a development team. When I was learning about how unclean code can slow down the software development process, I asked myself, “Is unclean code technical debt?” To answer the question, I am going to explore and compare the meanings and consequences of unclean code and technical debt. I will be using chapter 1 of Clean Code, written by Robert C. Martin to support the discussion. Chapter 1 explores the meaning of clean code and its value.

Unclean code is code that cannot be read and enhanced by a developer other than the original developer. Some qualities of unclean code include uninformative names, redundant comments, and multi-purpose functions. Some reasons for unclean code may include making a deadline and having inadequate skills. Unclean code is consequential because it slows down the development process. When code becomes unclean, it becomes difficult to read. When it is difficult to read, it becomes to develop.  Martin reinforces the value of clean code by talking about how unclean code killed a company in the 80s: “As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was bad code that brought the company down.” In other words, bad code tempts bad code and as bad code piles up, the application eventually becomes unusable, unmaintainable, and not worth fixing.  Unclean code hampers the capacity of an application to be developed.

Technical debt is the time a developer needs to use to refactor the code of a piece of functionality from a previous release because the functionality was implemented hurriedly. In software development, developers may deliver an application faster by using a convenient course of action to implement a piece of functionality. When they tell themselves they are going to refactor the code and add even more functionalities in the next release, they are putting themselves in technical debt. The debt becomes consequential when it is never paid. If developers do not pay the debt by refactoring the code, it may be difficult to understand. The lack of understanding may tempt developers to pile on the mess with unclean code and unintuitive implementations. As the mess grows, the application may become unusable, unmaintainable, and not worth fixing. Technical debt hampers the capacity of an application to be developed.

While unclean code functions like technical debt, I do not think unclean code is technical debt. Unclean code describes code, whereas technical debt describes the extra time a developer needs to use to refactor code. I think the two concepts have a cause-and-effect relationship, where unclean code is the cause and technical debt is the effect. The loss of productive time from unclean code may sway teams to take shortcuts. Understanding unclean code as a cause of technical debt will encourage me to become more aware of the way I write my code.

Martin, Robert Cecil. “Chapter 1: Clean Code.” Clean Code, Apogeo, Milano, 2018, pp. 33–46.

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

Assume a software developer who has a Windows computer creates an application and sends it to a tester who has an Apple computer. Do you think the application would work on the tester’s computer? The application may not work because it may be runnable on only Windows computers. The developer should solve the potential problem by using virtual machines and containers, ways of packaging applications into self-sufficient units that can run on any computer. When I was learning how to use Docker, a program used to create and run containers, my instructor often compared it to a virtual machine. To make sense of the comparisons, the goal of this post is to define the relationship between virtual machines and containers. To achieve the goal, I will be using the information from Preethi Kasireddy’s article, ‘A Beginner-Friendly Introduction to Containers, VMs, and Docker” which differentiates virtual machines from containers by architecture.

A virtual machine is an emulation of a computer. It is run on physical computers, called host machines, using a hypervisor, a program that creates and runs virtual machines. A few commonly used hypervisors are VMware, Hyper-V, and VirtualBox. For every virtual machine, the hypervisor provides an operating system, application, and assortment of dependencies. When a virtual machine is running, it depends on its operating system to manage how the application uses a partition of the host system’s resources. Each virtual machine’s operating system then depends on the host machine’s operating system to manage how the host system’s resources are partitioned.

A container is an executable package with an application and the application’s dependencies. They run on physical computers called host machines, using a containerization application, a program that creates and runs containers. As of today, the most used containerization application is Docker. For every container, the containerization application provides an application and assortment of dependencies. Because every container does not have a separate operating system, one can think of it as a virtual machine without a separate operating system. When a container is running, it depends on the host machine’s operating system to manage how the host system’s resources are used.

When I think about the architectural differences between a virtual machine and a container, I think about a house and an apartment respectively. A house represents a virtual machine because each family has their own set of utilities in the same way each virtual machine has an independent operating system. An apartment represents a container because multiple families share the same set of utilities in the same way multiple containers share the host system’s operating system.

If I continue to pursue a career as a software engineer, my understanding of virtual machines and containers will help me decide how to deploy my applications. If I want my application to efficiently use operating system resources, I should consider deploying it with a container.  If I want to deploy a system, I should consider deploying it with a virtual machine.

https://www.freecodecamp.org/news/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b/

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing.

There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components work together and show the relationships between those components. Behavioral UML diagrams on the other hand, show how a system would behave from the objects interacting with each other in it. In this class I am currently taking at Worcester State University, we look at the design and structure of programs through structural UML diagrams. We went through different versions of a “DuckSimulator” and its UML diagrams to see how the program can be improved. When given a difficult concept to add to the DuckSimulator, we were able to come up with a solution through the UML diagram because we could visually see how adding interface classes would affect the DuckSimulator.

The DuckSimulator structural UML diagram we used was a class diagram intended to be written in Java. UML diagrams are very commonly used to represent software that is based on object orientated programming because they can easily show the different classes with their attributes and behaviors as well as the relationships between each class. Class diagrams are split into three vertical sections. The section at the top is the name of the class, the section in the middle are the attributes, and the section at the bottom are the methods. Types of variables and return types of methods are indicated after the name and a colon (id : int). Typically the attributes in the middle section of each class are private variables indicated by a minus sign (-) before the name. Classes can be linked together with many different arrows to show relationships between them. UML diagrams are very powerful at representing a program written with a object orientated language.

https://creately.com/blog/diagrams/uml-diagram-types-examples/
 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing.

There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components work together and show the relationships between those components. Behavioral UML diagrams on the other hand, show how a system would behave from the objects interacting with each other in it. In this class I am currently taking at Worcester State University, we look at the design and structure of programs through structural UML diagrams. We went through different versions of a “DuckSimulator” and its UML diagrams to see how the program can be improved. When given a difficult concept to add to the DuckSimulator, we were able to come up with a solution through the UML diagram because we could visually see how adding interface classes would affect the DuckSimulator.

The DuckSimulator structural UML diagram we used was a class diagram intended to be written in Java. UML diagrams are very commonly used to represent software that is based on object orientated programming because they can easily show the different classes with their attributes and behaviors as well as the relationships between each class. Class diagrams are split into three vertical sections. The section at the top is the name of the class, the section in the middle are the attributes, and the section at the bottom are the methods. Types of variables and return types of methods are indicated after the name and a colon (id : int). Typically the attributes in the middle section of each class are private variables indicated by a minus sign (-) before the name. Classes can be linked together with many different arrows to show relationships between them. UML diagrams are very powerful at representing a program written with a object orientated language.

https://creately.com/blog/diagrams/uml-diagram-types-examples/
 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing.

There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components work together and show the relationships between those components. Behavioral UML diagrams on the other hand, show how a system would behave from the objects interacting with each other in it. In this class I am currently taking at Worcester State University, we look at the design and structure of programs through structural UML diagrams. We went through different versions of a “DuckSimulator” and its UML diagrams to see how the program can be improved. When given a difficult concept to add to the DuckSimulator, we were able to come up with a solution through the UML diagram because we could visually see how adding interface classes would affect the DuckSimulator.

The DuckSimulator structural UML diagram we used was a class diagram intended to be written in Java. UML diagrams are very commonly used to represent software that is based on object orientated programming because they can easily show the different classes with their attributes and behaviors as well as the relationships between each class. Class diagrams are split into three vertical sections. The section at the top is the name of the class, the section in the middle are the attributes, and the section at the bottom are the methods. Types of variables and return types of methods are indicated after the name and a colon (id : int). Typically the attributes in the middle section of each class are private variables indicated by a minus sign (-) before the name. Classes can be linked together with many different arrows to show relationships between them. UML diagrams are very powerful at representing a program written with a object orientated language.

https://creately.com/blog/diagrams/uml-diagram-types-examples/
 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing.

There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components work together and show the relationships between those components. Behavioral UML diagrams on the other hand, show how a system would behave from the objects interacting with each other in it. In this class I am currently taking at Worcester State University, we look at the design and structure of programs through structural UML diagrams. We went through different versions of a “DuckSimulator” and its UML diagrams to see how the program can be improved. When given a difficult concept to add to the DuckSimulator, we were able to come up with a solution through the UML diagram because we could visually see how adding interface classes would affect the DuckSimulator.

The DuckSimulator structural UML diagram we used was a class diagram intended to be written in Java. UML diagrams are very commonly used to represent software that is based on object orientated programming because they can easily show the different classes with their attributes and behaviors as well as the relationships between each class. Class diagrams are split into three vertical sections. The section at the top is the name of the class, the section in the middle are the attributes, and the section at the bottom are the methods. Types of variables and return types of methods are indicated after the name and a colon (id : int). Typically the attributes in the middle section of each class are private variables indicated by a minus sign (-) before the name. Classes can be linked together with many different arrows to show relationships between them. UML diagrams are very powerful at representing a program written with a object orientated language.

https://creately.com/blog/diagrams/uml-diagram-types-examples/
 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.