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.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by and used with permission of the author. All other rights reserved by the author.

Hello, blog (mood-status: relax and focus), writing this blog after coming home from a work trip and finishing it the last week of classes, studying on exams, and submitting assignments. But anyway, on writing about this week-13. I am writing this as my final blog for the year 2021. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Framework.

A framework is a platform that provides a foundation for developing software applications. It uses shared resources (libraries, image files, and reference documents) puts them together in one package. The resources can modify that package to suit the project’s specific needs. With a framework, the developer can add or replace features to give new functionality to the application. A working program that Framework can selectively modify by adding code.

What are the different types of frameworks?

The programming languages that many frameworks available from each use to solve different problems that come up in software development for Many industries can use it.

Back-End Web Frameworks

Back-end web frameworks are the multiple used programming frameworks. Web frameworks help developers in making web applications and active websites. These frameworks completely changed how web development is done, speeding up the entire software development process by automating everyday tasks for web developers, like providing database access, session management, and page templates. Instead of building websites using HTML, JavaScript, and CSS, back-end frameworks use programming languages to interact with a database to generate content. The work is hosted on a server, consequently the back-end portion.

Front-End Frameworks

Back-end frameworks are loaded on a server and executed in a user’s browser. It allows web developers to design what the users see on the website, manage requests, define file structures, and style its components. As Framework, It gives web developers a base to develop while controlling the final output. 

Why should you use a framework?

Frameworks help reduce time wasted in developing software. It provides a general working system that the user set for a specific application by extending the code. All the lower-level details have been added already. Frameworks allow the developer to save more time to write code specific to the project, not dealing with the Framework’s workaday, redundant functions. Also, It made the code clean and easily adjustable by following the coding convention of the Framework. Finally, frameworks help develop the project quickly, reducing programming time and costs.

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

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing.

There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components work together and show the relationships between those components. Behavioral UML diagrams on the other hand, show how a system would behave from the objects interacting with each other in it. In this class I am currently taking at Worcester State University, we look at the design and structure of programs through structural UML diagrams. We went through different versions of a “DuckSimulator” and its UML diagrams to see how the program can be improved. When given a difficult concept to add to the DuckSimulator, we were able to come up with a solution through the UML diagram because we could visually see how adding interface classes would affect the DuckSimulator.

The DuckSimulator structural UML diagram we used was a class diagram intended to be written in Java. UML diagrams are very commonly used to represent software that is based on object orientated programming because they can easily show the different classes with their attributes and behaviors as well as the relationships between each class. Class diagrams are split into three vertical sections. The section at the top is the name of the class, the section in the middle are the attributes, and the section at the bottom are the methods. Types of variables and return types of methods are indicated after the name and a colon (id : int). Typically the attributes in the middle section of each class are private variables indicated by a minus sign (-) before the name. Classes can be linked together with many different arrows to show relationships between them. UML diagrams are very powerful at representing a program written with a object orientated language.

https://creately.com/blog/diagrams/uml-diagram-types-examples/
 

From the blog Comfy Blog by and used with permission of the author. All other rights reserved by the author.

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

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

Hello blog (mood-status: feeling Good), writing this blog after thanksgiving dinner and eating well like pretty good with a plate of food alongside hanging the family. But anyway, on writing about this week-11. To be truthful here, I writing this because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large Companies’ applications that execute core business applications and keep a company going can more than some code modules. It can structure in a way that enables:

• scalability
• security 
• robust execution under stressful conditions. 

Their structure is that maintenance programmers can find and fix a bug that shows up after moving on to other projects. These programs can design to work perfectly in many areas, and business functionality is not the only one. A well-designed architecture benefits any program, and not only the largest ones as singled out. It mentioned large applications first because the structure deals with complexity, so the benefits of the network compound as the application size grows large. 

Another use of a structure that enables code reuse was design time. Ultimately, companies build up models of parts, each unit representing an implementation stored in code modules. At coding time, the developer can as promptly import the code module into the application. When another application needs the same functionality, the designer can quickly import its module from the library.

The C4 model

The C4 model made by Simon Brown designates on UML and the 4+1 architectural view model. It breaks down software into smaller units for modeling. Like the quick methodology, the C4 model requires fast, efficient sharing and constant updates of software architecture in software development.

The C4 model (shown as a map). The Maps can build on a different scale. By changing scales, like for example; The town map with streets and buildings. Having the C4 model changes the level of a diagram to describe software architecture. Using the abstraction-first approach, C4 conducts modeling top-down from system context to lower levels.

• Person (Element) – users or roles of a software system
• Software system (topmost level in abstractions) – the value of existing systems or systems under development and the interaction between those systems
• Container (Element) – the internals of software systems, usually applications or solutions for data storage. A different concept to containers in Docker. It mainly refers to software that is single deployed.
• Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
• Relations – dependencies or data flow between abstraction elements.

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by and used with permission of the author. All other rights reserved by the author.

Hello, week-9. I want to post a blog to quickly review the API topic to learn more about REST calls. I got confused; I researched about it. It has the Understanding And Using REST APIs.

What is a REST API

API (Application Programming Interface) – A set of rules allows programs to support any other. The developer creates the API on the server and enables the client to speak to it. 

The REST (Representational State Transfer) determines how the API. It is a set of rules that developers follow when they create their API. One of the rules states that one should get data (called a resource) when linking to a specific URL. Each URL made a request, while the data sent back to is called a response.

The Anatomy Of A Request #

It’s important to know that a request with four points:

• The endpoint
• The method
• The headers
• The data (or body)
  

The endpoint – URL that requests for (root-endpoint/?). The root-endpoint is the starting point of the API that is ordering.

The path determines the resource request. For example, it is like an automatic answering machine. That asks to press 1 for service, press 2 for another service, 3 for yet another service, and so on.

The Method

The method is the type of request sent to the server:

• GET – Request to get a resource from a server. It will perform a `GET` request; the server looks for the requested data and sends it back.
• POST – Request to create a new resource on a server. It performs a `POST` request, the server creates a new entry in the database and tells whether the creation is successful.
• PUT & PATCH – Requests to update a resource on a server. If performing a `PUT` or `PATCH` request, the server updates an entry in the database and tells whether the update is successful.
• DELETE – Request to delete a resource from a server. If performing a `DELETE` request, the server deletes an entry in the database and tells whether the deletion is successful.

These methods provide meaning for the request made. Perform steps: Create, Read, Update and Delete (CRUD).

The HEAD: it used to provide information to both the client and server. It has many purposes, such as authentication and giving information about the body content. It can find a list of valid headers on MDN’s HTTP Headers Reference.

The Data – contains information sent to the server. It only used POST, PUT, PATCH, or DELETE requests.

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

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by and used with permission of the author. All other rights reserved by the author.

Hello, I want to write this blog after looking over some class activities again and seeing any questions to review, but something caught my attention. I read the word “microservices” in some class-work exercises; I got interested and looked it up again. I found two links that helped me understand What are microservices? And examples from Amazon company.

What are microservices? 

Microservices (microservice architecture) – is an architectural method that structures an application as a collection of services that are

• Highly maintainable and testable
• Loosely linked 
• Individually deployable
• Organized around business capabilities
• Owned by a small team

The microservice architecture makes applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features to reduce complex applications. It even allows an organization to evolve its technology stack.

The pattern language guide 

The microservice architecture isn’t perfect; It has several problems. Moreover, when using this architecture, many issues must address.

The microservice architecture pattern language is a set of patterns for applying the microservice architecture. It has two goals:

• The pattern language allows whether microservices are a good place for application.
• The pattern language allows the microservice architecture favorably.

Characteristics of Microservices

• Autonomous – Each element set in a microservices architecture can be developed, deployed, operated, and scaled without affecting the functioning of other benefits. Services don’t need to share any code or implementation with other services. Any connection between individual components happens through APIs. 
• Specialized – Each service is designed for a collection of capabilities and focuses on solving a specific problem. 

Benefits of Microservices

• Agility – promote an organization of small and independent teams that take ownership of their services. Groups work in a small and well-understood context and are allowed to work independently and fast. It helps to shorten construction cycle times. It benefits significantly from the throughput of the organization.
• Flexible Scaling – Each service is to be independently scaled to meet the demand for its support application. It enables teams to support requirements, precisely measure the cost of a feature, and manage availability if a service experiences a spike in demand.
• Easy Deployment – Enable continuous combination and delivery, helps try out new ideas, and rolls back if something doesn’t work. The low cost of failure enables experimentation to update code and stimulates time-to-market for new features.
• Technological Freedom – It doesn’t follow a “one size fits all” plan. Teams have chosen the best tool to solve specific problems.
• Reusable Code – Dividing software into small modules, which enables teams to use functions for multiple purposes.
• Resilience – Service independence increases an application’s stand to failure. With microservices, applications handle complete service failure by discrediting functionality and not crashing the entire application.

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