Monthly Archives: December 2021

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 Andrew Lam 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.

Changing your Approach to Testing

I’ve always avoided familiarizing myself with the practice of testing, as the models and math required to really understand it seems to be quite daunting. On an episode of Coding and Cocktails by the name of Changing your Approach to Testing, Alan Richardson outlines a shift in how we should think about testing. The thing that immediately struck me was his outline of how testing in the industry is a tad lackluster – for the reasons that I avoided it in the first place. Apparently, people haven’t read up on past research and existing models to optimize their techniques of testing. Richardson references the difficulty of testing for beginners, and a disconnect between those that specialize in it versus those who are not as versed in the practice. I could sense a tinge of frustration from Richardson as he outlined a general lack of familiarity with the field, noting a soft disregard of math techniques like set theory, graph theory, probability theory, etc. He stressed the technical knowledge and deep analysis needed to effectively do the job, as well as the interpersonal communication techniques needed to address problems with colleagues. 

I found it particularly intriguing when Richardson referenced the need to effectively communicate with team members with the right language for that individual, especially in the case they don’t want your feedback. He noted that this could be seen as “people skills,” but further explained he actually studied psychology to better understand his interactions and optimize the team’s communicative efficiency. Quickly after however, Richardson pumps the brakes a bit to say one need not possess every good quality for being a tester – after all, what are teams for? As long as aspects like technical know-how, tenacity to finish and the ability to challenge people are represented in the team, members can work off others’ strengths while being valuable for their own. I must say this relieved a bit of my anxiety because of the huge pool of knowledge that must be drawn from, be it interpersonal or technical. 

Furthermore, he stressed the application of the tests, and how to go about asking the right questions when designing them. The example Richardson brings up is a basic question that should always be asked before any work is done – what is the goal of testing this specific product, and how should tests be implemented based on that goal? I believe he stressed this point because he asserted that a majority of the industry is relatively inflexible when adapting to different testing environments. As mentioned prior, this is most likely due to an unfamiliarity with the literature and research. 

As much as I enjoyed the perspective, and will definitely remember this episode for future reference and tips, it has only made me more terrified of testing. At least I know what I should be doing though, right?

Link – https://soundcloud.com/codingovercocktails/changing-your-approach-to-testing-with-alan-richardson

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

Exploring Fintech Innovations

For this post, I tuned in to the Code and Cocktails episode by the name Exploring Fintech Innovations. Amancio Bouza, API thought leader and chief product officer at Contovista AG, represents an area in tech known as fintech, or financial technology. This field describes how technology can improve and optimize delivery and use of financial services. The episode delves into the intricacies of modern banking, and describes how woefully behind banking is in the modern era. Some institutions are so large they disregard the need for things like API implementation entirely, thinking that they have a few years before it becomes essential. To combat this, consultants like Bouza educate banks on the future necessity of the technology. 

For example, upgrading certain models of data analysis could provide statistics on customer preferences and expectations. Thus, this information coupled with machine learning has the potential to tailor specific financial advice to a user at an individual level. This could theoretically be massively beneficial to a bank’s constituents, by educating them on specific pitfalls and nuances of their financial situation, hopefully pushing them to accrue more wealth once they understand the data. Once the understanding of some patterns and validity of different models are smoothed out with machine learning, it also greatly helps with risk management for both the individual and the bank itself. 

In addition, Bouza notes that in the next decade or so society will shift to a more decentralized payment model, with debit and credit cards being phased out for account-based financial transfers. This is an infrastructure many larger banks need to adapt to, as Bouza notes the autonomy granted by such a shift will be an inevitable draw for modern day consumers. He references a “lack of urgency” in these large institutions, whereas startups who are on the razor’s edge of success or failure will scramble to be ahead of the curve of general tech implementation to keep up with the market. In the classic capitalistic train of thought, they consider themselves too big to fail.       

I think it’s also important to mention that people like Bouza are far from wanting to totally restructure the system. He’s working to educate existing entities and give them the tools to prosper in the coming future – tools that will benefit both the institution and the consumers. By incorporating even a small portion of Bouza’s suggestions, people can take advantage of the autonomy given to them to invest in hyper personalized interests. Autonomous finances have the ability to make each consumer the most wealthy and frugal that they have the potential to be, which is a net win for everyone involved.

Link – https://soundcloud.com/codingovercocktails/exploring-fintech-innovations-and-trends-with-amancio-bouza

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

The State of APIs in 2021

I recently discovered a podcast by the name of Coding over Cocktails, and they’ve done some excellent interviews with professionals in the field that specialize in API design. Evidently, the infrastructure of APIs are poorly maintenanced in many cases, as the importance of the practice has not yet hit the general understanding of how important they will come to be in future design strata. Matthew Reinbold, the interviewee on the episode titled The State of the API in 2021, asserted that there are a few key ways to see the “articulated vision” for how APIs interact and benefit future implementations of software. 

Reinbold outlined the need to be able to articulate how technological modularity is a strategic boon to the industry. While at the moment API design is proverbially left on the cutting room floor, he stressed the growing importance of integrating the practice as a cornerstone of future project endeavors. Referencing the pandemic, he cites a slew of examples pertaining to the cultural shift in society and the changing needs of consumers. For example, if an API was properly implemented for a given company, they ended up being months ahead of other organizations who failed to recognize the importance of the practice. These cultural shifts like curbside pickup are now a staple in modern business practices, and are here to stay for good.

API implementation promotes independence for consumers and resiliency to change for businesses, but at the moment are a “it would be cool if we had that” type of implementation in most projects.

Reinbold goes on to say that work culture norms are the primary thing that has to change before executives see the potential gain from incorporating such software. Changes to management would undoubtedly be the primary driver, but Reinbold also stresses the agency that lower tier employees don’t think they have in the industry. He uses the comical and stereotypical image of a computer geek living in a basement, where all one has to do is “throw pizza and sugary drinks down the stairs and code comes out.” In reality however, Reinbold argues that younger workers or “new power” feel helpless in the face of their superiors, or “old power.” But the mantle of leading change, Reinbold states, is simply finding the correct skills and techniques to do things better, and to try and get one’s colleagues intrigued with the implementation. The dynamic between new and old power is irrelevant if genuinely good ideas and leadership are explored at all levels. 

Either way, it was fascinating to hear about something we studied in class as the next step in tangibly improving our technology and quality of life. 

Link – https://soundcloud.com/codingovercocktails/the-state-of-the-api-in-2021-with-matthew-reinbold

From the blog CS@worcester – Dummies that Code by howbrash 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.

The SOLID Principles

Throughout this semester, the most interesting topics to me are those relating to how to produce good code. While I like learning about and implementing API requests in either the frontend or backend, regulating code utilizing something like the SOLID principles is interesting to me because it can be applied in many different situations and programming languages. We discussed the SOLID principles earlier in the semester, and while I walked to discuss them on this blog, I never got a chance to.

The Single Responsibility Principle states that a class should only have one job. The below article uses the example of shapes, namely a square and a circle. The Square class has the length of a square, and the Circle class has the radius of a circle. Another class, AreaCalculator, contains the logic that deals solely with adding the area of the different shape objects.

The Open-Closed Principle states that “Objects or entities should be open for extension but closed for modification”. If a programmer would like to take an existing class and add functionality to it, the existing class should be developed in such a way as to allow easy inheritance, and the programmer should add his implementation in an inherited class. In the article’s example, the author adds an area() function in the shape classes to calculate each shape’s respective area, then changes the design to implement a shape interface, which is implemented by the shape classes. The AreaCalculator then checks the instances of Shape Interface, and calculates that way.

The Liskov Substitution Principle states that every child class should be substitutable for their parent class. This means that a child class acts in the same way as its parent class, in this case, providing similar functionality and returning in a similar format. The article uses the example of a class called VolumeCalculator, that inherits from AreaCalculator. Both VolumeCalculator and AreaCalculator must be consistent, such that its implementation is the same.

The Interface Segregation Principle states that a client should never be forced to implement an interface that it doesn’t use, or depend on methods they don’t use. Building on the author’s example, if we needed to calculate the volume of a sphere, a class shouldn’t manage both a circle and a sphere, but segregate them into two different classes.

The Dependency Inversion Principle states that “entities must depend on abstractions, not on concretions”. In the author’s example, one class connects to the database, whereas another class depends on the connection class, thus they cannot decouple. Instead, we should implement a class using an interface, which is the parent class of the connection class. Abstraction is now applicable in both high-level and low-level classes.

Going through this article has been informative. I would also like to practice implementation and classes in Java or C++ to gain a better understanding of these principles.

Link:

  1. https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

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.