https://www.dossier-andreas.net/software_architecture/pipe_and_filter.html

The Pipe-And-Filter architecture is conceptually very simple. It essentially consists of breaking down one operation into a sequence of smaller operations, in which the input of each is the output of the previous. These operations are called “filters” and the connectors linking them are called “pipes”. Sometimes the terms “pump” and “sink” are used to refer to the initial input and final output, respectively. I think making up those last two terms is a little excessive, but overall I like the metaphor – it makes me think of an actual physical machine, which is similar to how I prefer to think about computing in general.

The most well-known example of this pattern is seen in Unix and Unix-like operating systems, which are also the most obvious example of this pattern’s utility. There is no need for any program to have word counting functionality, because its output can be piped into wc, a program that only does that. Similar functionality for pattern matching is provided by grep. With this ecosystem of programs in place, a skilled user of a Unix shell has a great deal of functionality available to them through composing these programs in different ways, as opposed to creating new programs from scratch that do slightly different things than what the programs on their machine already do. Another common example is compilers, which also function in a similar way in order to streamline and simplify the process of translating between languages. The OpenGL rendering pipeline has similar motivations, only for processing graphics instead of programs.

One drawback of a pipe-and-filter system is that it has the potential to draw too much overhead. Being able to pipe something into wc rather than counting words yourself is a more flexible solution, but it does involve running a separate program. At small scales (i.e. most use cases) this isn’t an issue, but if your data is large enough you may need to abandon this system.

Before looking into this, I wasn’t really aware of the pipe-and-filter architecture as a distinct pattern. I was aware of how the Unix ecosystem worked, but I thought the practice of piping together small programs in sophisticated ways was just a quirk of that operating system. I didn’t connect the dots that it was also the same basic concept being used in graphics pipelines, even though I was aware of them. I also have always regarded compilers as a little magical, and seeing that their workflow can be decomposed like this makes them seem a little more approachable.

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

My experience with HTML programming outside of classwork pretty much begins and ends with making forum posts look fancy in 2012 messaging boards, and I have even less experience designing frontends with HTML. I wanted to use this blog post to learn more about how to build frontends. Matias Lorenzo’s “Frontend Architecture and Best Practices for Consuming APIs” seemed like a very good start.

Lorenzo notes that issues begin to arise when designing a frontend because that frontend is often dependent on a backend API. This means that whenever the backend or the API undergoes a change, the frontend must also be changed. Lorenzo describes some other issues one might encounter when integrating an API into their frontend. APIs may use lengthy key names that necessitate mass replacement. APIs might structure data in a way that is difficult to fully utilize, or they might include too much data.

Lorenzo proposes a frontend architecture that would further isolate the frontend from the backends it depends on so that it is more stable when the backend changes and is titled model-controller-serializer. Below is a diagram of how this architecture fetches information, in this example it is fetching products for a storefront, from an API:

Controllers in this architecture are the point of contact between the rest of the app and the API. This portion of the app should be able to create any relevant request. Information comes in through the controller, is deserialized by the serializer, then is passed to the model to create instances of that information.

Serializers in this architecture decipher information coming in from the API. If an API includes information that is not relevant to the app, the serializer can remove this information. The serializer can also change the type of a field (eg. from a string to a boolean). Similarly, if the API uses long or clunky names for fields, the serializer can alter the name of the field before passing it along.

Models in this architecture are representations of information from the API that can be read by the app. These store information as an object in Javascript (or whatever language is being used in the app) so that it is easy to access and understand.

I chose this source because I wanted a more in-depth look at frontends. I know what a frontend does, but I would be at a loss for how to design one. This frontend architecture Lorenzo describes seems really useful to help keep the frontend and backend seperate, and I will be keeping this reference in mind for future projects.

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

Christian Shadis

As I transition into the final semester of my undergraduate degree, I plan to learn Javascript. In my Software Construction, Design, and Architecture class, we briefly explored and edited some frontend code in Node.js and Vue.js. Using my prior knowledge in Java, I was able to understand how most of the code was functioning. As Javascript continues to rise in popularity, it would be a valuable language to add to my skillset. One of the fundamental aspects of learning Javascript, or so it seems, is to understand the Document Object Model (DOM). Having used his book HTML & CSS: Design and Build Web Sites to supplement my knowledge in web design, I decided to consult the fifth chapter of Jon Duckett’s Javascript and JQuery: Interactive Front-End Web Development to learn more about the DOM.

Duckett first specifies the DOM as a set of rules, separate from the HTML and CSS of the website, which “specifies how browsers should create a model of an HTML page and how JavaScript can access and update the contents of a web page while it is in the browser window” (Duckett 184). In other words, the DOM acts analogously to an API in that it facilitates or enables real-time communication between JavaScript code and the HTML page. Duckett proceeds to describe the DOM tree, the benefits of caching DOM queries, and how to traverse the DOM tree. He also described how to access, update, add, and delete HTML content from the page using the DOM. The chapter included a bit of bonus information such as cross-site scripting attack prevention and how to view the DOM in each of the major web browsers.

Reading this chapter was useful in contextualizing how the different parts of a webpage interact with each other. In addition to learning the fundamentals of the DOM, I also gained experience reading JavaScript code, which is a great way to learn how a language works. What stood out to me most about the material was the parallels between the DOM nodes and the LinkedList data structure. Having coded an implementation of the data structure in a previous course, it was intuitive to see how traversal of the DOM tree worked.

I plan to continue to learn JavaScript, and plan to read the remainder of the book. Web design is becoming more ubiquitous by the day, and thus a more valuable tool for developers to have. I would highly recommend this book and others by Jon Duckett to developers – the design is pleasing, he provides sample code, and offers excellent simplistic explanations.

Duckett, J. (2014). Document Object Model. In JavaScript & JQuery: Interactive Front-end web development (pp. 183–242). essay, John Wiley & Sons.

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

Rest API are a common method for integrating applications in their services to provide more reliability and to be flexible where possible. I chose to use stackoverflow.blog as my blog because they are filled with information in regards to many programming languages, AI, databases, especially Rest Api and etc. The blogs also discuss and provide certain authors that give explained details on the processes and focus on implementing, as well as common problems that may erupt with certain solutions that can lead an aid to a professional career in software development world. As this website have given me a clearer perspective while in my Software Construction architecture class along the way working on our Food pantry project.

As for Rest Api, they are a common web service used in today’s technology. Allowing the client (person making the request) to communicate with the servers (receiving the client requests) with is the Rest Api that is connected to a database. To keep in mind, when creating an API, we use always separate the client from the server to made to interact on one way because due to fact that clients can make requests but not responses, while server can make response but not requests. We use HTTP methods as an action for the client wants to make. GET Method allows the clients to request the information from the backend. POST Method is creating or listing the information. PUT Method is editing the information. DELETE Method allows the deletion of information.

JSON (JavaScript Object Notation) is a basic format to help the programmer to easily read write out code for the computer to understand and generate the output and cache the responses. API endpoints are the end of the communication, which utilizes the services or the response. For example, when making a request on the API rom the browser or an application, the response will then be received that reaching that point will be the endpoint. 

After learning about REST API in my CS-343 class and working along the course. I start to begin to gain more confidence and gain more insight on how the process works. And designing the API which gave me complications for the backend and frontend as well. Realizing even the slightest misspelled command or wrong path can leave you clueless on fixing the problem but understood why the situation erupted. This material could’ve been useful for my database course I have taken previously to implement the databases on the server to be integrated along with providing the appropriate security from the client side with restrictions, while the backend is able to store, modify if allowed. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Docker is a program used to package applications and their dependencies into bundles that can run on any computer. A running instance of the bundle is a container. Docker containers help developers build software by isolating applications, sandboxing projects, and guaranteeing running software. To have a docker container, one needs to write a Dockerfile, build it into an image, and run the image. When I was learning the process, my instructor explained the process and terms by using only an analogy. He compared them to the process of how source files became executables, and then running processes.  Because analogies only help understand concepts (not define them), the goal of this post is to define Dockerfiles, images, and containers as well as their relationships. To achieve the goal, I will be using information from the article, “Differences Between Docker Images and Containers,” written by Eugen Baeldong, an author who has written about software development extensively. His article differentiates Docker images from containers.

The Dockerfile is a text file that contains instructions on how to find, install, and configure an application and its dependencies. In the same way an embryo is a baby at the first stage of development, a Dockerfile is a container at the first stage of development. Some commands that can be used to create instructions are RUN and COPY. RUN is used to install a package or application and COPY is used to copy files and directories from one location to another. With the commands, instructions are created. The set of instructions tell a computer how to find and install the applications and its dependencies.

When a computer executes the instructions in a Dockerfile, an image is built. According to Baeldong, an image is a template for creating the environment one wants. In other words, it is a snapshot of a system one wants. Returning to the baby analogy, an image is a container at the second stage of development in the same way a fetus is a baby at the second stage of development.  I imagine an image as one’s desktop environment. The icons in the environment represent the application and its dependencies in a dormant state. The application is not running yet in the same way desktop applications do not run until one double-clicks their icons.

When a computer runs an image, a container is created. A container is an environment where an application and its dependencies are running. The application in the container is independent from the applications on the computer. In other words, the contents inside a container and one’s computer are unaffected by one another. I imagine it as a computer inside a computer; however, the second computer will not have a graphical interface because it is not necessary for an application to run.

https://www.baeldung.com/ops/docker-images-vs-containers

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.

Since we’ve been using JavaScript for the past several weeks in class and in homework, I thought it would be beneficial to help run through some elements of JavaScript I found weird or difficult at first. I’ve noticed some people have a harder time understanding JavaScript’s syntax or how its variables work, so I wanted to make this as a sort of reference.

Types

JavaScript contains primitive and non-primitive types. A variable can be declared with “var”, “let”, or “const”, more on const later. The main primitive types are¹:

• Boolean: true, false
• Null: null
• Undefined
• Number: 72, -174.21
• String: “Hello, ”, ‘world’

For an object type, objects are very loose and can for the most part be defined with relative ease. 

Let’s take a simple object, named “car”.

This object has three properties, wheels, year, and color. When declaring or assigning properties, the syntax shifts from the typical use of “var num =”, to “num: ”. These properties in an object are pairs: “wheels” and “4” are a pair, specifically a key-value pair as well as an object. This means that there is more than one way to access an object’s properties. 

The second one looks suspiciously similar to a map, specifically one in C++. Objects may be iterated through using a for-loop directly.

Functions

Functions may be defined in a few ways. If inside of an object, the function would be defined as:

Else, it may be defined as the following:

The bottom function declaration is known as arrow notation. A function with arrow notation is not bound to an inherited constructor or the keyword “this”, and its usage with scopes may be troublesome. Its parentheses may be dropped if there does not exist any parameters, such as “getProps => {}”².

JSDoc

JSDoc is a markup language used to comment JavaScript code, and is similar to JSDoc in many ways. JSDoc may be created by typing “/**”, then pressing enter upon this pop up:

JSDoc is, in my opinion, very useful in declaring classes, functions, objects, types, or declaring types. This is especially important with JavaScript, since types are handled dynamically.

JSDocs can use the following my pressing “@” inside of the comment, revealing a large list of descriptors, with users being able to make any and anytime³:

Upon creating a simple JSDoc annotation:

Hovering over the object “car” will read:

For our function getValue:

This is rendered as: 

Hopefully, this post can be helpful. JavaScript was odd for me when I first started, with these topics being some of the things that took me a while to get used to. The sources contain a wealth of information that I have and will continue to refer to and learn from, and hopefully they can help you too.

Links:

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures (Types)
2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions (Arrow Functions)
3. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html (JSDoc)

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.