Category Archives: CS-343

SPA treatment. How’s the Vue over there?

With front-end development being one of the last topics we cover for this semester, I decided to take a deeper look into things that can be built using the frameworks we’ve utilized. Vue.js for example is a framework that can be used to develop a front-end application. One type of front-end application that many of us are very familiar with is a Single Page Application(SPA). An SPA is an application that displays all of its information, well, on a single page. It sounds like a lot but only the requested and necessary information is usually displayed on the page at one time. 

For example, most email service providers have been developed using SPA styled programming. If you’re like me, you have a ton of unread emails that you are just too lazy to go through and delete. All of these messages can span over the course of a few “pages”. As you click through the pages, you can see how quickly the response is while sifting through them. Although this design gives you the impression that you are navigating through many different pages, the browser is just updating the very same page that you navigated to.

While some of this implementation is back-end stuff, Vue can help make this possible with the use of components, that’s all it really is. Instead of having to use hundreds of unmaintainable lines of javascript to add functionality to an application, Vue makes it really simple and easy to maintain your code with Don’t Repeat Yourself (DRY) standards. It starts with a root component to get the Vue framework into your code. From there everything else is just a series of components to get everything working. 

Components come in two different flavors. Global components, as the name might suggest, are registered and usable everywhere within the application. Local components are only usable wherever they are registered. To register a component as global you would need to use the Vue.component method. Registering a component locally would require that you make it a part of the “props” of an element. Figuring out when to use a component globally or locally calls for careful consideration when making your application. 

There are other great front-end developing frameworks like React.js and Angular.js. Along with Vue, these three are very popular in terms of leading frameworks that developers like to use in the present day.

My sources I used for this post:

https://vuejs.org/v2/guide/components.html

Understand VueJS in 5 minutes

Global & Local Components

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

JavaScript Quirks

As time goes on and I have learned more about JavaScript and its use in the back-end and front-end. I have found many surprises about JavaScript compared to other programming languages. The more I interact with it, the deeper I get to know the language and the framework inside. This article is to point out some of the odds about JavaScript.
Semicolon (;)
Java requires a semicolon at the end of every single statement, in case we don’t put a semicolon at the end the compiler would give us errors. Unlike Java, JavaScript does not have a compiler hence if we, unfortunately, missed out on semicolon, there’s not going to be any warning, but it might result in breaking our code or it would simply refuse to work. That is because of JavaScript’s automatic semicolon insertion rule. The rule states that a valid program ends with a (;) if it does not end with a (;) then JavaScript will automatically insert a (;). Therefore, it will not ask us to insert a semicolon.
Strict Equality (===)
Java has two types of Equality; one is single equality (=) means it’s used for numbers and the other is double equality (==) which is used for String. Move on to JavaScript, it has 3 types of equality. Two are similar to Java but there is also another one, it’s called Strict Equality (===). The Strict Equality checks if the data types are the same and if it is not, it returns false. Complicated, isn’t it?
Let and Const
It would be best not to use “var” to declare variable because it is not block-scoped and allows for mutation. Being block-scoped means a variable does not pass its boundaries, unlike var that does not respect borders. Professional users advise newbies to use “let” or “const” to declare the variable. Usually, developers would use “let” unless they don’t want that variable to change then they would use “const”. On the other hand, Java gives users a variety of variable declarations such as int (Integer), String, double (2.9), or boolean (true or false). So, simple but not simple at all.
Fixing Errors
About fixing errors, since JavaScript does not have a compiler, therefore, it’s harder to fix errors unless we type something that is absolutely not making any sense. The only way to fix the error is to run the code on localhost and figure it out from there. However there’s a fix for that, it’s ESLint. This extension uses command lines to tell us where the problem lies but also could fix the errors if we run.
Now we have learned some JavaScript quirks and there are many more that we should spend more time to look. But JavaScript still dominates the market despite all things above and is one of the most popular languages in 2021 and undoubtedly 2022. So, deal with it.

https://rofiatolusanya.medium.com/javascript-quirks-84d2d8ac4f41

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

UML Diagrams – PlantUML

We learned PlantUML at beginning of the semester and even did an entire homework creating UML diagrams of a project. But the reason I am writing about UML diagrams right now is because as I was going through previous activities I realized, not only can UML diagrams be used for code built on OOP but also to create a simple and easy to read diagram of an microservices architecture.

As we all know we are going to be using microservices architecture to build Libre Food Pantry so I decided to look for a resource that can make using PlantUML simpler and easier to use and understand. I found a great blog by solutions architect Alex Sarafian. Below are the few features that I found very useful:

  • We can color code arrows for multiple flows flow of the diagram and add legend to specify what color represents which flow.

Format example:        A -> B #Blue : text

legend

    | Color | Flow |

    |<#Red>|  Flow 1 |

    |<#Blue>|  Flow 2 |

endlegend

We can color code arrows inside PlaceOrderService and ApproveOrderService for easier understanding of the services.

  • Autonumber feature will automatically add a number alongside the text of every event. Autonumber gives a linear sequence of events that are going to take place. For example, 1st UI placing the order to API, then 2nd from API to Database and so on.

Format example 1: numbers in front of event text

autonumber

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

Format example 2: Numbers are 2-digit padded and highlighted

autonumber “<B>[00]”

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

  • PlantUML limits the image width and height to 4096. Therefore, when image file is created over the limit of 4096, diagrams are cutoff completely taking away the advantage of efficient flow UML diagram. To fix this we can use command line parameters to increase the width and height limit of image. Another way is to use ‘skinparam dpi X’ parameter. However, the downside to using skinparam is that we must find the value for ‘X’ by experimenting to see when UML diagram fits the best.
  • We can display text relevant to an event below the arrow for a cleaner UML diagram. We a skin parameter to achieve this. For example:

skinparam responseMessageBelowArrow true

autonumber “<B>[00]”

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

  • PlantUML supports a lot of different colors. A neat trick is to use the ‘colors’ command to render a picture with all colors.

Sources: https://www.codit.eu/blog/plantuml-tips-and-tricks/?country_sel=be

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

REST API

We have been using REST API for most of the semester now but did not really read or have knowledge about it. We have been reading a lot of documentation of MongoDB – its operators, commands, methods, or collections. but nothing about REST even though we will be using REST API again in future semester i.e., for capstone when we are working on Libre food pantry. Therefore, I wanted to research REST and found a very interesting blog by Adam Duvander.

REST stands for REpresentational State Transfer. REST API’s are a form of web services used to run websites (like we have built Libre food pantry example), mobile applications and most enterprise integrations.

Important thing to know about REST is that it is not a standard, it is built over HTTP standard. The information can be in several formats: JSON, HTML, XLT, Python, PHP, or even plain text. JSON is the one we have been using and probably will be using because it is easy to read by both people and machines.

Developers used HTTP methods or HTTP verbs to define the requests being made. GET, PUT, POST, and DELETE are ones we have used so far. PATCH is another commonly used HTTP method to update a subset of existing data.

REST resource is data that is modified or accessed using HTTP methods. For example, when we worked on backend, we defined a path to access or modify data by using GET, PUT or POST methods. An example of a request would be:

POST /order/{id}/items

{id} would be an identifier to find order with that specific id value. Identifiers can be integers or hashes.

REST architecture is made of this resources and requests and requests are made using HTTP methods. REST architecture also states that information should not be stored after any request is executed, meaning every request is independent of the other. However, resources should be accessible and modifiable by the user. Therefore, interface between components is needed so that resources requested are identifiable and separate from representations sent to the user. The representation has information which can be then used by user to access and modify resources. REST architecture also needs cache for interactions between user and server and a system to handle different servers used to process requested information into hierarchies.

Built on these principles, REST is very versatile, able to work in a large variety of environments, with multiple data types making REST API’s faster and lightweight.

Sources: https://blog.stoplight.io/rest-api-standards-do-they-even-exist

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Getting Started with Axios

View at Medium.com

https://www.sitepoint.com/axios-beginner-guide/

This week I decided to write about Axios for JavaScript. We are using Axios on our front end. So I thought it could be helpful to read an article about Axios, and learn more about what Axios does and how it works.

Axios can be used on backend node.js applications. And used in JavaScript files/ frameworks like Vue, React, and Angular. One of the most common uses of Axios is making HTTP requests to send, receive, or save data. Data passed in post operations is conveniently sent in JSON format. Below is an example of an axios HTTP request method.

axios({
  method: 'post',
  url: '/login',
  data: {
    user: 'brunos',
    lastName: 'ilovenodejs'
  }
});

Axios also has a convenient way to receive responses. Axios returns a promise that is either a response or an error method. A response object is returned with a successful call, and the .then() function is called. The response object has data, which is the payload in JSON. The status in the form of an HTTP code. The status text, which is an HTTP message. Headers, returned by the server. The original request information. And the HTTP request in the XMLHTTPRequest object format.

If an Axios request returns an error, the promise will be rejected and an error object is returned. An error object includes: an error message, a response object, a request, and the original request. 

axios.get('/product/9')
  .then(response => console.log(response))
  .catch(error => console.log(error));

To better understand Axios, it is worth explaining what a JavaScript promise is, and why programmers use them. Promises are used to handle asynchronous functions in JavaScript. Promises may return a value or payload, or an error message. Each promise has a state. A promise can take three different states. fufilled, rejected, and pending. In the code below process will not execute until fetch executes. And handleErrors will not execute until save has executed. .catch will handle erros within process() and save().

fetch(url)
.then(process)
.then(save)
.catch(handleErrors)
;

Axios, and promises in general are important pieces of software development today. When using the microservice architecture. Sending and receiving data is an essential function of each service. And Axios and promsies help developers do just that. Axios and promises work asynchronously meaning that they can run different parts of the program simultaneously. This is another important concept because sometimes differrent parts of a web page load asynchronously. So an asynchronous method could render the first available piece of data.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Blog post 7 –DRY and YAGNI

DRY and YAGNI are two acronyms used to describe best practices when it comes to coding. DRY stands for “Don’t Repeat Yourself” while YAGNI stands for “You Ain’t Gonna Need It”. These two acronyms or best practices complement each other very well. They both aim to make code cleaner, simpler, and free of coding smells such as needless complexity and needless repetitions. These are coding smells that every developer should avoid. So, what do they actually mean?

DRY or “Don’t Repeat Yourself”, is a best practice revolving around repetition in code. When it comes to code, quality is always better than quantity. Why have hundreds of lines of code when you could have a dozen lines that do the same thing? Having duplicated code or duplicated logic is a waste. Not only will you waste time and effort, in the beginning, adding the unnecessary code, but you will also waste further time and effort maintaining and extending the code in the future. Repetition in code can be caused by a variety of reasons mostly from either poor programming habits, like copy and pasting code without really understanding how it works, or from a poor understanding of coding knowledge in general, but specifically, a poor understanding of encapsulation. Regardless of the cause, needless repetition should be avoided as much as possible and repetitive code should be eliminated by refactoring wherever possible.

YAGNI is an acronym that stands for “You Ain’t Gonna Need It”. YAGNI is a coding best practice that stems from the principles of Extreme Programming or XP. YAGNI revolves around the idea of avoiding the writing of unnecessary code that is based on foresight rather than need. Martin Fowler describes YAGNI as “a statement that some capability we presume our software needs in the future should not be built now because “you aren’t gonna need it”. In other words, software developers should always implement features when they need them and never when they just foresee the need for them. There are several reasons why YAGNI exists. One very good reason is that it maximizes the amount of unnecessary work that is left undone. This is excellent because it improves the productivity of software developers, and it maintains the simplicity of products. Simplicity is especially important because implementing new features is quite expensive. It takes a significant amount of time, money, and resources to add the features and to maintain them. Features that are not necessary can be very costly. To avoid wasting resources on unnecessary features, apply the YAGNI principle and don’t implement features unless you need them now.

https://deviq.com/principles/yagni

https://deviq.com/principles/dont-repeat-yourself

https://martinfowler.com/bliki/Yagni.html

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

GRASP (General Responsibility Assignment Software Patterns)

GRASP (General Responsibility Assignment Software Patterns) is a design pattern in object-oriented software development used to assign tasks to different code modules.
GRASP provides a way to solve organizational problems and provides a common way to speak about abstract concepts. The design pattern sets responsibilities for objects and classes in object-oriented program design.
GRASP with an object-oriented design identifies its problems and solutions together as patterns.

Patterns of GRASP

Creator
• Who creates an Object? Or who should create a new instance of some class?
• Creator is a GRASP Pattern which helps to determine which class should be responsible for creating a new instance of a class

Information Expert
• Information Expert is a principle used to determine where to delegate responsibilities such as methods, computed fields, and so on.
• Expert principle says that assign those responsibilities to object for which object has the information to fulfill that responsibility.

Low Coupling
• Low coupling is an evaluation pattern that directs how to allocate responsibilities for the following benefits:

lower dependency between the classes,

change in one class having a lower impact on other classes,

Great ability to reuse.

Controller
• Deals with how to transfer request from the UI layer objects to domain layer objects.
• A controller object is a non-user interface object responsible for receiving or handling a system event.
• We can make an object as Controller, if

Object represents the overall system (facade controller)

Object represent a use case, handling a sequence of operations

High Cohesion
• High cohesion is an evaluation pattern that seeks to keep objects focused, manageable and understandable.
• High cohesion is generally used in support of low coupling.
• Benefits
– Easy to understand and maintain
– Code reuse
– Low coupling

Indirection
• Indirection pattern supports low coupling and reuses potential between two elements by assigning the mediation role between them to an intermediate object.
• Benefits: Low coupling, e.g. Facade, Adapter, Obserever.

Polymorphism
• According to the polymorphism principle, responsibility for defining the variation of behaviors according to the type is assigned to the type for which this variation happens.
• Benefits: Handling new variations will become easy.

Protected Variations
• Protected variations pattern protects elements against the diversity of other elements (objects, systems, sub-systems) by wrapping the focus of instability with an interface and using polymorphism to create a variety of implementations for this interface.
• Provides flexibility and protection from variations.

Pure Fabrication
• Pure fabrication is a class that does not represent concepts in the problem domain, specifically designed to achieve low coupling, high cohesion, and possible reuse arising (when the solution presented by the information expert pattern does not work).
• Benefits:
 High cohesion,
 low coupling
 And can reuse this class.

REFERENCE

  1. http://www.kamilgrzybek.com/design/grasp-explained/
  2. https://home.cs.colorado.edu/~kena/classes/5448/f12/presentation-materials/rao.pdf

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

Architectural patterns

Architectural Patterns.

These architecture patterns are a reusable solution to a commonly occurring problem within the field of software design. Software architecture patterns are a description or template for the structural organization or scheme for how to solve a problem that can be used in many different situations.

  1. Layered pattern

This pattern can be used to structure programs that can be divided into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher layer.

Layers of a general information system:

  • Presentation layer 
  • Application layer 
  • Business logic layer
  • Data access layer 

Usage

  • General desktop applications.
  • E commerce web applications.

2. Client-server pattern

Consists of two parties; server and multiple clients. The server component will provide services to multiple client components. Clients request services from the server and the server provides relevant services to those clients.

Usage

  • Online applications such as email, document sharing and banking

4. Pipe-filter pattern

This can be used to structure systems which produce and process a stream of data. Each processing step is enclosed within a filter component. Data to be processed is passed through pipes.

Usage

  • Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis, and code generation.
  • Workflows in bioinformatics.

5. Broker pattern

It’s used to structure distributed systems with decoupled components. These components can interact with each other by remote service invocations.

Usage

6. Peer-to-peer pattern

In this pattern, individual components are known as peers. Peers may function both as a client, requesting services from other peers, and as a server, providing services to other peers.

Usage

7. Event-bus pattern

This pattern primarily deals with events and has 4 major components; event source, event listener, channel and event bus. Sources publish messages to particular channels on an event bus. Listeners subscribe to particular channels. Listeners are notified of messages that are published to a channel to which they have subscribed before.

Usage

  • Android development
  • Notification services

9. Blackboard pattern

This pattern is useful for problems for which no deterministic solution strategies are known. The blackboard pattern consists of 3 main components.

  • blackboard — a structured global memory containing objects from the solution space
  • knowledge source — specialized modules with their own representation
  • Control component — selects, configures and executes modules.

Usage

  • Speech recognition
  • Vehicle identification and tracking
  • Protein structure identification
  • Sonar signals interpretation.

10. Interpreter pattern

This pattern is used for designing a component that interprets programs written in a dedicated language. It mainly specifies how to evaluate lines of programs, known as sentences or expressions written in a particular language.

Usage

  • Database query languages such as SQL.
  • Languages used to describe communication protocols.

REFERENCE

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

codegrepper.com

I used to believe that this was a pro in my coding abilities but the further I go, the more I realize that is actually a con. When I first started coding in CS140, I realized that I have had a unique ability when it came to paying attention to detail. When I am absolutely lost or confused, I will hammer the nail all day. Meaning, I will read every single character in every line of code before I decide that I am completely lost. This is great, time and time again I have proven that no code is a match for me. I always seemed to outwork my failure. Before the deadline passed, I had made sure that I submitted something that makes sense and works.

Once I started working on our latest Javascript homeworks, I realized that this is not helpful to me. I have managed to get my codes to work. And I have managed to get them to do what I needed them to do. That being said, if you asked me to explain the code in plain english I would struggle to do so. That’s because I just spent hours and hours playing around with the code. Instead of researching basics and creating a great fundamental understanding for myself, I just went for it. I believe life would be alot easier if I had this fundamental understanding before I began coding rather than trying to grasp it during coding.

Codegrepper.com is something I found while researching these fundamentals. It seems that I have came across a gold mine. This link right here specifically helped me work on the get method within my javascript for the HTTP Get request.

https://www.codegrepper.com/code-examples/javascript/javascript+find+object+in+array+by+property+value

Immediately you have a code snippet of javascript which finds object in array by property value. And it begins to build up. It shows you how to find object by property. How to find ID in an array javascript. And so on. This website also has a search engine that allows you to search anything. It seems to be an incredible tool, especially when learning new languages. If you type “hello world”, it gives you the intro code snippets for any language you can think of. I will definitely take more use of codegrepper.com moving forward.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

GRASP

Resource Link: http://www.kamilgrzybek.com/design/grasp-explained/

For this blog post I wanted to explore the GRASP principles. GRASP is an acronym for 9 principles that apply to object oriented design in programming, and it stands for General Responsibility Assignment Software Patterns. The 9 principles are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Indirection, Polymorphism, Pure Fabrication, and Protected Variations.

First, the Information Expert principle states that an object should have all the functionality and logic that pertains to it. For example, if a class has a list of objects, then it should also have all the logic for functions that pertain to that list, such as adding items, removing items, etc.

 Next, the Creator principle states that an object should be created within the scope where it’s used. This means that if a certain class A relies on another class B to function, and B is unique to A, then B should be created within class A.

Next, the Controller principle states that the first object behind the front end UI layer should control the backend operations. This helps to separate the front end functionality from the backend functionality.

Next, the Low Coupling principle states that objects should be designed in such a way to where they can be isolated and reused without changing many other components. This helps to avoid rewriting code that could be useful in multiple places, instead making it generic so that it can fit into many different applications.

Next, the High Cohesion principle states that objects should only contain data and functionality that pertains to their function. This helps to avoid overloading a class with extraneous information and logic that isn’t necessary and should be abstracted or put into another class.

Next, the Indirection principle states that instead of directly coupling two objects, an intermediary object should be used between the two to handle the coupling. This helps to avoid a direct dependence relationship between two objects, instead having them both rely on an in between class that handles the relationship, so that change can be localized to that one class.

Next, the Polymorphism principle states that objects should be generalized so that they can handle support for different object types. For example, an animal class would have functions that pertain to all animals, and then subclasses could have functions that are more specific to certain kinds of animals.

Next, the Pure Fabrication principle states that shared functionality between classes should be placed within a separate class rather than in a class that it only roughly fits into. This helps to abstract functionality that could be repeated among many classes, instead putting it into a single shared class.

Finally, the Protected Variations principle states that systems that are likely to change should be protected as to not affected other systems. This helps to avoid breaking systems that other systems rely on, instead making sure that systems which other systems have a dependence on are protected and not susceptible to change.

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