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.

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.

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.

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.

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.

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.

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.

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.

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.