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 Andrew Lam 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 Andrew Lam 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 Andrew Lam 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 Andrew Lam 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 Andrew Lam 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 Andrew Lam 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 Andrew Lam and used with permission of the author. All other rights reserved by the author.

In my previous entries, I have been taking topics (such as REST APIs, coding smells, and so on) and merely providing general applications of the subject. This is not to say that the posts are simply summaries; rather, they provide a little bit of coverage on a lot of ideas within the subject. This time, I’m going to something a little different – I want to cover a specific issue involving REST API calls. This issue involves the return messages from the calls, specifically the “200” success message vs. the “404” failure message.

To summarize, a “200” return message is essentially an “OK” message. It means that, when trying to access data, that data can be found to some degree (even if its value is zero). For example, even when trying to access an empty list, it will return a “200” despite having no items within the list. In contrast, a “404” error is commonplace on the internet, to the point where even those who aren’t tech-savvy at least understand the general idea – it means that requested data cannot be found. in short, it doesn’t exist (at least not to the server).

A good way of discerning the difference between these two is to take a shelf of soup cans. If we have an empty shelf, then we will get a “200” message – the shelf exists, but there are no soup cans on it. Meanwhile, a “404” would mean that we cannot get any soup because the shelf does NOT exist.

The blog associated with this reading is short, sweet and to-the-point; it briefly explains the “200” and “404” messages, alongside some other return messages (and even some images of cats!) I chose this reading due to its brief, yet informative nature – these topics are not difficult, and don’t require too much explaining. The cats also make for a humorous touch, allowing the learning process to be more “fun” and “easy going”.

While a smaller detail, this distinction between “zero” and “null” is not to be taken lightly. I plan on using this knowledge in future practice, as it will reinforce good coding practices; it is not enough to say “we have no soup” and be done with the problem. We need to know exactly WHY we don’t have any soup, otherwise this faulty coding can lead to smells and other issues down the road. It is always important to not only understand what the result of a program is, but also how it gets that result. We also need to ask ourselves if this result is obtained “properly” – meaning that it is done in a way that works smoothly with the res of the program.

Link: https://blog.short.io/status-codes/

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

https://www.altexsoft.com/blog/front-end-development-technologies-concepts/

The frontend of an api or web system is the visual representation/interface that is seen and used by visitors, customers, etc. You interact with the frontend through your browser so frontend development is very important for any online website or service. When creating the frontend of a system the developers use HTML, CSS and Javascript which are the same tools used to make web apps. Frontends are very different from backends as the user does not see the backend or really necessarily interact with it. The backend is what happens on/in what it is developed for. Backends govern the functions and any operation that takes place within the system.

Backends are developed using different languages based on the developer or customers preferences. The backend also consists of the web server and storage of the system which it supports. But even though the backend contains what makes the site/app function, the front end is still just as important as it is what is presented directly to the users. Through mainly html front ends bring the actual user experience into play and help to dictate the functionality of a website even though the frontend is not directly involved in the execution of the functions.

I chose this article as it was very helpful when it comes to understanding what exactly a front end is and why it is important when developing something such as an app or website as it truly is the entire user experience. The user experience overall can make or break an app or any other type of programming which requires a front end and therefore the front end development process is very important.

I feel as though an article like this would be helpful not only to myself but to my peers as it thoroughly explains what a front end is as well as what a backend is. This helps fully differentiate the two so that there is no confusion in the development stages of either. Both frontends and backends are similar but also drastically different in how they are developed and the purpose they serve. This article helps to differentiate the two and helps the reader gain an understanding of what is included in each in order to develop an effective system that thrives for both the developers of the system and the users of the system. I would recommend this article to anyone questioning the difference between frontend and backend as well as anyone wondering how to develop an effective api in general.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

While I was seeking an internship, I had run into a great friend who currently works as a software developer. He mentioned this method which is called CI/CD and told me that this is a great way to develop, deploy and maintain software that developers should know about. Following his world, I’ve done research about this topic and found what he said was entirely true. For developers who want to learn more about the software development process, this blog is for you. This blog is going to focus on what is CI/CD and what it does to the software development life cycle.

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. There are three main concepts developed to CI/CD are continuous integration, continuous delivery, and continuous deployment. CI/CD is a perfect solution along with Docker to solve the problem that new code can cause for development and operation teams. CI/CD introduces automation and continuous monitoring throughout the life cycle of apps, from integration and testing phases to delivery and deployment. This practice is referred to as “CI/CD pipeline” and is supported by development and operation teams working together in a responsive way to have the best approach.

CI/CD is also a software engineering practice where members of a team integrate their work with increasing frequency. To do so, teams strive to integrate at least daily and even hourly, approaching integration that happens continuously. CI emphasizes automation tools that help build and test, finally ultimately focusing on achieving a software-defined life cycle. CI is successful, build and integration effort drops, and teams can detect errors as quickly as practical. CD is to be packaging and deployment what CI is built and tested. A team can build, configure, and package software as well as rewrite its deployment to fit with its budget at any given time. As result, customers have more opportunities to experience and provide feedback on changes.

Continuous integration helps developers merge their code changes back to a shared branch, more frequently- sometimes even daily. Once the changes are merged, those changes are validated by automatically building the application and running through many levels of testing to ensure changes have not broken the app. CI makes it easier to fix bugs as quickly and often as possible.

While in continuous delivery, every stage-from the merger of code continuously changes to the delivery of production-ready builds-involves test automation and code release automation. The goal is to have a code-base that is always ready for deployment to a production environment.

Those things above are some benefits of CI/CD and personally, I found it very interesting to me as a future software developer. I think this method would help developers to maintain the best of their system as well as the foundation of security.

Source:

https://www.redhat.com/en/topics/devops/what-is-ci-cd

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