Category Archives: CS-343

Apprenticeship Patterns – The White Belt

I think this is some of the best advice that the Apprenticeship Patterns have to offer. Stagnating in the learning process is an incredibly difficult problem to resolve, as learning is such a unique process to each individual person. I learn quite differently from my brother, while he and I learn wildly different from my father. With such a discrepancy even within a family, I think this is a very poignant point to address. From a personal standpoint, I’ve certainly experienced this phenomenon to an extensive degree. My ability to intake new information varies drastically based on how interesting I find the topic.

As the author mentions, “Dave’s not knowing stance helped him to collaborate with the family to find solutions as a team.” I find this to be invaluable advice; maybe I’m a little jaded, but I believe most people have no idea how much they don’t actually know. The capacity of people to not understand how uninformed they may be on certain topics genuinely shocks me sometimes. Even worse, this type of person often thinks other people are wrong when they are woefully uneducated on whatever the topic may be. Apologies for ranting about this for so long; it’s genuinely one of the most frustrating things I find about the modern era. I blame the internet honestly. 

I don’t want to claim I’m an expert on people, but this is something common I’ve frequently observed in various jobs or interactions. To step off my high horse for a minute, I generally tend to regard myself as an idiot in most situations – not even as a self-deprecation thing. I find that humility in knowledge is one of the most valuable traits that anyone can have, in literally every situation. Akin to “not wanting to be the smartest person in a room,” I think there is, without a doubt, ALWAYS something that can be gleaned from a dispute or conversation. After opening up my biases or assumptions in some ways, my opinions have been drastically changed in ways I could have never predicted. Even if one is an expert at something, I find it incredibly important to maintain this white belt mindset.    

I realize I’ve definitely deviated from the original point of the pattern, but because I’m so adamant about this type of subject I felt the need to rant a little bit. Thanks for coming to my Ted talk. 

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective Blog #3

This phase in our project is to put together all the pieces we have been implementing for weeks. It is the best part of our project because we have been working on something for months and finally we can see what it looks like after all. However, this realization would not come without many different adjustments to the program. Several pieces have played a role in the process, and all the teams have contributed to the final point. For my part, I have worked on more environment setups. For example, Learn how to use commitlint/conventional commits for the Application source codeEditcommitlintng: Issue worcester/cs/naturalization-interview-confidence-environment/General#13. is one of the resources that I have used to set up the files in a way in case it gets to push the files to the main branch and has a bad commit message it will fail the pipeline but if it gets to push to any branch other than main it won’t fail the pipeline but it will give you a warning. Since we were working on a collaboration that was essential to maintain a good environment for all. The syntax for the file code is commitconfig.sh echo “module.exports = {extends: [‘@commitlint/config-conventional’]}” > commitlint.config.js this will set the configuration. On top of commit messages, the Conventional Commits specification is a lightweight convention. It provides a simple set of rules for generating an explicit commit history, making it easier to build automated tools on top of it. Second, Learn how to add and remove VS Code Dependencies to a Docker imageEdit, Issue: worcester/cs/naturalization-interview-confidence-environment/demo-react#22. We wanted to know how to add or remove NPM dependencies in a Docker container used by React Native projects in this issue. Using VS Code to add dependencies:
Look in package.json for the extension ID and paste it alongside the required version. I have pulled the join working file from gitlab to run to test on the docker environment. After many tries, eventually, all dependencies were installed and the program worked properly.
In issue worcester/cs/naturalization-interview-confidence-environment/demo-react#45: Prompter Question pageEdit, in this issue I followed my opposition team member, which was assigned for that task. The goal for this issue was to create a page that will contain a list of questions that the prompter can choose from and read to the test taker. It should show all of the options in a card format. The full text of a card should be displayed on a new page once it has been selected. Find out what base image criteria isEdit issue: worcester/cs/naturalization-interview-confidence-environment/demo-react#52. As you can imagine, many people find it difficult to choose the right container base image. A base image is available for every major Linux distribution. For programming languages such as Python, Ruby, and Node.js, open-source projects provide their own base images. For services like MariaDB, Redis, Elastic, and MySQL, many open-source projects and vendors provide their own images. While programming languages and services aren’t technically base images, most people consider them to be so and factor them into their decision-making process when selecting standardized base images. This is why the container base image matters when we want to set the environment.

Overall, we had a better sprint due to modification from the previous ones. We have learned how to write issues properly. We had a more detailed plan for every issue. Communication, in general, became absolutely a cornerstone for our success. We have improved on planning. We have selected the topics based on the needs of the previous discussion. As we struggled in the past to break issues into small pieces, we were able to correct that and made a better reading board for everyone. I personally went over the issues on the board where if something is not cleared or detailed then I would ask questions related to that issue.
For the future we wish that we had time to make all the functionalities of the program work. Such as to be able to navigate in the app page by page. To be able to filter question by question from the main page without any difficulty. Finally, set all the functionalities on the app for user friendly. This project has been nothing but learning curve for all of us. Giving the fact that we did not have a blue print from previous example, we now leave a working project for the upcoming team that will be working to improve this application.

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.

Week 15 II: What Are REST APIs? HTTP API vs REST API

https://blog.devgenius.io/what-are-rest-apis-http-api-vs-rest-api-92c2fe2bb136

For this last blog post, I decided to pick this post on the same blog as the last one, blog.devgenius.io. Admittedly I am picking too many REST API blog posts but I thought this one was a good pick because I’ve never dove deep into why we use REST APIs and what they are as well as some other types of APIs. In this blog post titled “What are REST APIs? HTTP API vs REST API” by The Educative Team (which I assume is a team of authors) they go over HTTP APIs, REST APIs, when to use REST APIs, and what to learn next.

First, they go over what an HTTP API is. It’s an API that uses Hypertext Transfer Protocol as the communication protocol between the two systems. HTTP APIs expose endpoints as API gateways for HTTP requests to have access to a server.
They also go over common alternatives to the popular REST API: GraphQL API, Falcor API, and gRPC APIs. GraphQL APIs are the second most popular form of API and seeks to correct common problems with the REST API structure. It’s open-source and designed to hold data in a tree structure. Falcor API uses much of the REST API architecture with paths and references but automates much of the request structure. Lastly, gRPC APIs are a newer API based off RPC APIs. Almost all of the processing of gRPC APIs are done by the server in RPC architectures.

Next, they go over REST APIs. REST API stands for Representational State Transfer and is an architectural pattern for creating web services. REST APIs see widespread use by application developers due to how simply it communicates with other machines over complex operations. REST is a ruleset that defines best practices for sharing data between clients and the server. It then goes into architectural requirements to be considered a REST API: Client-server, Stateless, Cacheable, Uniform Interface, and Layered System.

Lastly, it goes into when to use REST APIs, when not to, and what to learn next. For when to use REST APIs, REST APIs are great for building general-purpose applications to be scalable in the future. As for when not to, REST is a helpful tool in your toolbelt and a good general rule to follow but it shouldn’t be your programming dogma. For what to learn next, you should learn other API types so you can recognize when a situation calls for a non-REST solution.

I thought this was a good blog post to dip my toes more into REST APIs and just APIs in general. When I was working on my homework, I didn’t really give much thought into the work but when looking into the concepts of the homework more, it’s actually interesting to learn about. I also chose this blog post because it went over other API types that I should learn about if I go into front end development and I thought that was a good takeaway from this post.

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

Software Development and Videogames

In our modern society videogames have become a

In our modern society videogames have become a ubiquitous piece software that many use as a form of entertainment. They are on everything from dedicated home consoles and PCs to handheld devices and most prominently, smartphones. Videogames as software can range from extremely simple text based games to complex 3 dimensional environments with intelligent AI systems controlling events throughout the game.

Game development can be a great exercise for any upcoming software engineer to practice their skills. A single person is capable of creating a game as was the case originally with the popular game Minecraft. Minecraft, as many may already know is a open world that is famous for its randomly generated terrain and complete freedom in destroying and building in the world around you. In this simple game there is AI controlling the in game monsters, physics that dictate how you jump, fall, and swim. A dataset of different types of blocks that make up the game, and a world generator that utilizes different rules to create a landscape that is random yet results in a world that is cohesive and believable.

In contrast to the random generation and world state tracking done in Minecraft, other games such as portal specialize in their ability to create believable physics as well as their signature reality bending portals. The game allows you to seamlessly move through portals and stand anywhere in between and also involves physics of items and liquids dropping and moving in a believable way. Physics is an important part of the game and can prove difficult in itself to design from a software perspective.

Aside from these however, games can be as simple as a 2 dimensional platformer that only needs to consider at a basic level the act of moving left or right and jumping, or even a turn based game that needs only consider strict choices that are given to the player to interact with the game world. Game development, just like any good software has a development cycle and will go through a development, alpha, beta, and release cycle where the software will take shape and become a finished product over time. As the game becomes more complex, bugs and other problems may arise that must be dealt with and code optimization and organization becomes important. It can involve multiple people and repository management as projects become more and more complex, too complex even for just one person to deal with. Often the gamification of a task can make it more enjoyable and rewarding to practice so why not apply this to software. If it interests you it can be a great way to practice your skills and even discover new practices that can help in other programs you create.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Understanding More About APIs

In the second half of the semester we began working with the API code for the Worcester State food pantry project. As I worked with the API code, I never really took the time to gain a deeper understanding of how APIs work and I wanted to explore that as I wrap up my final assignments. I found this video explaining the basics of Web APIs to be very helpful and fill in gaps I had in my understanding of the topic. 

API stands for application programming interface and web APIst provide mechanisms users can use and interact with where the workings of that mechanism are hidden to the user. The video gave a great example of a way to visualize how APIs work: when you enter an elevator you have a set of buttons that take you where you want to go, but you don’t see or know exactly how it does it. Web APIs are the medium between the client (user) and the server (the web servers). HTTP protocol (HyperText Transfer Protocol) is used to transfer data through the web. Every link on your web browser is in HTTP form with a path and parameters or query – for example, I am editing this in google docs and my browser is in the form of docs.google.com/document/d/encryption/edit. Servers offer responses in various different codes such as 200 (success), 400 (client error), or 500 (server error). The information that is sent over can be in two different formats: XML or JSON. They have different formats but the same function of transferring data. 

JSON is the standard for APIs because most programs are using javascript and it provides easy integration. Many modern APIs use the REST architecture (Representational State). REST APIs use an end point just like the HTTP path and the method, which defines what kind of action is being performed (GET, POST, DELETE). Headers contain information about the type of request and the body is the JSON object. API requests have four parts: The end point (the path), the method (which HTP call is being made), the header which contains additional information, and the body (the message or data that is being sent). 

This video did not mention YAML files and that was part of the API system I was still struggling to understand, and came across a great breakdown:

https://idratherbewriting.com/learnapidoc/pubapis_yaml.html

The food pantry API code is made up of many different YAML files. YAML is similar to mark up languages but it removes all the brackets and other syntax making it easier and faster to read. YAML and JSON are related, making the two easy to integrate. YAML file syntax uses indentation to denote different levels and each different level is an object with dashes indicating variables. JSON uses quotation marks and brackets whereas YAML uses dashes and semicolons.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

week-15

Hello, blog (mood-status: relax), writing this blog after coming home from work, finishing the exams, and submitting assignments. But anyway, on writing about this week-15. I am writing this as my “final” blog for the year 2021 for real. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Patterns & anti-patterns.

 

Patterns

Patterns are part of everyday language, but it’s essential to discuss algorithms to understand their importance in software engineering. An algorithm performs a daily task like sorting a list of items, storing data for efficient retrieval, or counting occurrences of an object within a data set.

 Algorithms are among the most used fundamental concepts in software engineering. It mainly highlights proofs of its solutions and its only code samples in obscure, ancient languages such as Algol or MIX Assembly. Despite much covered: singly- and double-linked lists, trees, garbage collection, etc. The details are hiding in problematic libraries, but the concepts are the same. These algorithms have remained reasonable solutions to common software engineering problems for more than five decades and are still going strong.

A “pattern” can be a general structure of an algorithm. In algorithm focus on a specific programming task, a pattern challenges beyond that domain and areas such as reducing defect rates, increasing code maintainability or allowing large teams to work more effectively together. Some standard practices include:

  • Factories
  • Pub/Sub
  • Public-key Cryptography
  • Agile

 

These are four common patterns in the industry; it ranges from highly technical to broader, more process-oriented points. Factories are very code-oriented, while pub/sub is more architectural. While public-key cryptography has general importance, libraries to support its operations are available for almost every programming language in everyday use, making it generally short of implementation.

At the other end of the expanse, “Agile” remains unavailable: a point and a tool among developers, project managers, and other stakeholders about precisely what it means and how it should be implemented. From Narrow or broad, technical or process-oriented, excellent working knowledge of these patterns is an essential component in a technologist’s toolbox.

 

What is an Anti-Pattern?

A “pattern” is a known-to-work solution to a common software engineering problem (anti-pattern). Anti-patterns do not incorporate the idea of failure to do the right thing, including options that seem right at face value but direct to trouble in the long run.

Note the reference to “a common response.” Anti-patterns are not a few mistakes; they are familiar and always followed with good choices. As with regular patterns, anti-patterns can be broad or very specific, and there may be hundreds to consider in the realms of programming languages and frameworks.

From the blog Andrew Lam’s little blog by and used with permission of the author. All other rights reserved by the author.

Week 15: Top 5 REST API Problems

https://blog.restcase.com/top-5-rest-api-design-problems/

For this week, I wanted to stay on topic of REST APIs because I was still working with REST APIs this week. Also, I just think REST APIs are a fun topic for me to learn about since it’s so foreign to me. Anyway, in the blog post by Guy Levin from a blog that focuses on “Architecture, Programming, Ideas and Thoughts about microservices, APIs, cloud technologies and more” linked above, he writes about the top 5 REST API design problems. The 5 problems consist of: Using body in GET requests, usage of wrong or lengthy names for parameters, defining own error code and error message, ignoring caching, and returning too much data and long response times.

To summarize the 5 problems,
Using body in GET requests: add parameters inside the body, instead of in a URL. Many servers might not even look at the body of the request when it comes to GET method.

Usage of wrong or lengthy names for parameters: Since the URI already should state what is the resource, like project, there is no need for a long name like project_id, but only id.

Defining own error code and error message: Don’t use the approach of returning a response code 200 when something went wrong, make use of standard HTTP error codes.

Ignoring caching: Try not to ignore caching and use it, caching is very useful and gives several advantages like saving network bandwidth since this the server does not return content body but relies on the browser for that.

Returning too much data and long response times: Nobody wants to call an API and get a response after 2 minutes. Start designing your REST APIs with support for pagination, sorting and filtering.

I thought the problems Levin listed were simple mistakes that he wrote about to emphasize that these are easily missed. These problems seem to come up often if he has to write about them. I picked this blog because I thought it would be more complex problems but I think the blog post was a good post to reinforce REST API fundamentals. Looking back at these problems, I don’t think I really encountered much of these problems when I was working with the backend of the pantry API. Other than caching, all of these problems I didn’t encounter which I thought was good since the pantry backend was my first encounter with REST API stuff so I was already exposed to good fundamentals.

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

Vue.js Breakdown

Traditional web applications function by having single pages that need to be refreshed when data has to be updated or submitted. You can likely recall using a website where each time a form was submitted or a link was clicked, you had to wait for the data to process and a few seconds later a new page appears. This process feels very cumbersome and discourages the use of the service.

Modern-day web applications are single-page, meaning data is dynamically added and removed from the HTML without the page needing to be redownloaded. To do this, a virtual dom is created through javascript and rendered as HTML to the page. When the virtual dom has a change, the actual dom is updated only in the area that is needed, without reloading everything. This change in design improves speed, reduces the amount of data to load, and improves user experience. Most services used online today are single-page applications and when they are not, it feels old and outdated.

There are three main web frameworks that are used to create single-page applications and these are React.js, Angular, and Vue.js. Of these frameworks, Vue has the fastest-growing developer userbase. A main benefit of Vue is that it is an easy-to-learn framework. In Vue, the virtual dom has a two-way data binding. To dynamically control the webpage, Vue uses user-created components that are linked together in a hierarchy. Each component is abstracted and allowed to have variables passed to it to make it display specific data. This feature allows custom HTML components to be reused, reducing repeated code and unmanageably long HTML files. A benefit to Vue components is that they can be easily unit tested, as only a small portion of the web application will be tested at a time.

In each component, it can contain state variables, which are like javascript variables that are tied to an element on the webpage. When a state variable is changed, its value is updated on the webpage. The process of watching a variable for a state change and updating the virtual dom then rendering the update to the webpage is called data-binding. This process happens nearly instantaneously and is what makes using Vue-built applications feel seamless and snappy.

I have used React.js in the past and I am familiar with the structure of combining html and javascript together. I am interested in learning more about Vue and what benefits this framework has to offer. Vue separates out the style, structure, and logic of each component which forces developers to keep their code cleaner than in React.


Source: https://www.altexsoft.com/blog/engineering/pros-and-cons-of-vue-js

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

Npm and Yarn

When looking at Node, I was confused on what type of software it is. It seemed like a framework to me. As I did some research I came across some articles and found that it is a common misconception that people think it is a framework or even a programming language. Node.js is a java runtime environment (JRE). It is typically used in backend development, but it also has pretty good use in the front end as well. 

Over the course of the semester we have been using node modules in our projects. In order to get one of these modules in a project we would need to use the npm install method. Npm stands for Node Package Manager. It contains hundreds of thousands of repositories that developers can use to inject dependencies into their applications. At the time I didn’t really understand what the npm was used for so I would just blindly install packages into my projects so I could get them working. 

During the last few projects we were working on in class we started using Yarn, another type of package manager. Once again not knowing exactly what Yarn was or why I needed it I blindly installed the resources I needed for my project, and got to work. At the time, I didn’t notice any subtle differences. The packages I installed were also put into my node modules and I was able to work on my projects as needed. So what was the difference?

Yarn was developed as a response to some of the shortcomings of npm in the past. Over time the developers of the two package managers have been copying each other’s homework in terms of staying relevant in the developer community. One of the glaring differences between the two is that when installing packages, yarn installs multiple packages at one time while npm installs packages sequentially. In the grand scheme of things, this saves some time when setting up your projects. Both package managers allow the node modules to have the same file structure although the file signatures differ. In yarn, the node modules are generated with yarn.lock and in npm the node modules are generated with package-lock.json. Yarn has made it so it is easy to convert from package-lock.json to yarn.lock files in case users wanted to make the switch from npm to yarn. Npm however doesn’t seem to have the same ease of access when migrating from yarn to npm.

In terms of which package manager is better will depend on the developer. It is important to take into consideration though, that yarn is the later package manager. It has gained as much traction as npm has in its entirety, but this could just be due to the increasing demand in package managers in the present day. 

Sources:

NPM vs. Yarn: Which Package Manager Should You Choose?

https://www.geeksforgeeks.org/difference-between-npm-and-yarn/

https://www.section.io/engineering-education/nodejs-frontend-backend/

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.

Design Smells

Before constructing a project, we must picture out an image out or possibly draw it out to get a better grasp. This way tends to make a smother software as writing our code. But overtime we must face challenges along the way, which regards to maintaining software and keeping it maintained and readable. I have found this website which is called https://flylib.com/books/en/4.444.1.47/1/. This website is a library is all types of information regarding a library of books in different areas such as SQL, programming languages, interfaces, etc. I believe this website can aid me and any other developer to get a wider insight on the information they desire to seek. 

Design smells are basically violations regarding poor designing and that can be spread among other parts of one’s code and/or project. Which is why we have types of code smells to determine on how to seek and resolve it before it becomes an issue. The design smells are divided into seven principals.

Rigidity design is where you make a small change in your code could make huge, unexpected changes in other areas of the software. Fragility design is almost like rigidity, but this is where is when you alter a change in your code and broken code starts to erupt in. this is a sneaky design smell because we do not realize it sometimes and it can potentially make it through the production phase. Immobility design is common due to the fact of parts that are deemed useful are also harder to separate as it can pose a risk. Viscosity designs are also common when deciding between a not good choice that is convenient other than a good one that is not convenient. Needless design comes in two forms which are needless complexity and needless repetition. Needless complexity is straight forward of making your code overly complicated than it needs to be that consists of redundancy. Needless repetition is composed of unnecessary repetition. For example, when we make copies of classes to do the same thing and adding more classes on top which result in a developer’s laziness. Lastly, we have opacity design where readability becomes harder to read and takes time to understand the code which waste time on a developer. 

After gathering information on design smells and seen examples of each type of design smell in my CS-343 class. I understand that it is crucial to refactor code where it can stay readable and keeping it maintained. When starting a project, we always want to make a visual image to make it easier to implement. Also applying the rules and avoiding design smell as much as we can but sometimes, we can miss them and are able to determine the type of smell and find a solution. 

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