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

Being computer science students, many of us including myself have never really written to much code before starting classes here. And since many of us were beginners at writing code and the practices that come with that, our code tended to be an affront to the eyes of anyone who was unfortunate enough to have to read it. As it turns out, many of the issues with our code actually have names, and are usually referred to under the umbrella term of Anti-Patterns. I found out about Anti-Patterns back when we were covering design smells in class, and while thinking of what I wanted to write for a blog entry this week I decided to go more in depth on some of the different types of anti-patterns out there. Many of which I have definitely been guilty of in the past. GeeksforGeeks has a great article covering what anti-patterns are and different types of them. There were plenty in that article, too many to go into in this post without making it too long, so I will go over the ones that I have done most frequently in the past (Although I almost certainly have done each one of the ones in that article at some point). First and foremost is spaghetti code, which is basically just a term that refers to messy code. Code that works, but is incredibly disorganized, difficult to read, and overall unmaintainable. I can confidently say that many of my first personal projects and class assignments suffered from this. My code would work, but god forbid you want to quickly add or remove a feature without needing to try to interpret what that code originally needed to do. Thankfully with time I have gotten better at organizing my code and making it much more readable and maintainable. Another Anti-Pattern that I have done plenty of times, and actually relates to a previous blog post I made, is the “Boat Anchor”. This is essentially useless code within your program. This can also be referred to as “Dead Code” Code that you wrote thinking it would be useful, but it ended up just taking space. This is actually the issue that YAGNI tries to address. There are still functions in many of my projects that I thought would have a purpose, but now they just take up space. I tend to do this less now, although I cant say I dont slip up every now and then.

https://www.geeksforgeeks.org/6-types-of-anti-patterns-to-avoid-in-software-development/

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

Front-end is the graphical user interface where users can interact with on their computers to communicate with the website’s database to view the information they need. To develop the front-end, developers use HTML, CSS, and JavaScript framework; and they also have to be aware of the constantly changing in the tools and techniques to create the front-end of a website.

HTML (HyperText Markup Language) is the most basic markup language (absolutely not a programming language), for documents designed to be displayed in a web browser. Learning HTML is the first step in front-end development. Come after HTML is CSS, stands for Cascading Style Sheet, and is used for formatting markup language, mostly for HTML. Finally, while HTML and CSS creates the structure of the website, JavaScript is what powers its interactivity. Furthermore, learning JavaScript is a never ending process since there are new frameworks coming every year. Let’s take a look at the popularity differences between these web frameworks, according to the Stack Overflow survey in 2019 and 2020 respectively:

We can see that jQuery is losing their numbers to React.js and Angular and React.js looks like they will get that first place this year, but the top three most popular frameworks are all JavaScript. Besides, as I said that there are new frameworks coming every year, it means that when a better framework shows up, front-end developers have to learn it in order not to be left behind. For now, in my opinion, React.js is what you should go for if you want to get a role in this field.

Besides the programming language skills, there are other tasks that front-end developers have to be aware of. From my experience, a method called fake API is really important. For instance, in the process of developing the graphical user interface, front-end developers have to test their work by calling the API from the back-end team to see how the data fit into their blocks. However, in case that back-end team falls behind or somehow is not able to provide the front-end team with the built API, fake API is one useful method to test the front-end. Another frustrating task that I’ve heard about is that the design has to be responsive which means that the website has to run properly on any device, from the smallest mobile device to the largest desktop.

In conclusion, above is what I know so far about the front-end. Also, I found outstanding guidance about the practice of front-end development from Frontend Masters including almost everything we’ll need regarding a front-end topic. Check it out if you want to learn something in the front-end.

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

I have worked before with Docker and Docker Compose, but I am a bit shaky when it comes to networking either of them. I know it is possible, and I know it is often a necessary step in deploying applications. However, I have never had luck trying to network containers together. I wanted to spend some time learning more about this.

Docker comes with several networking drivers: bridge, host, overlay, ipvlan, and macvlan. Bridge is the default networking driver used by Docker and is the most popular. Ranvir Singh’s article “Docker Compose Bridge Networking” outlines how to use that bridge networking driver to network containers together using either Docker or Docker Compose.

A network for Docker containers can be created using the following command:

$ docker network create -d bridge my-network

This creates a network called ‘my-network’ which uses the bridge driver. To add containers to this network, one would run commands similar to the following:

$ docker run -dit --name container1 --network my-network ubuntu:latest
$ docker run -dit --name container2 --network my-network ubuntu:latest

These commands would create ubuntu containers ‘container1’ and ‘container2’ respectively and would add them to the ‘my-network’ network. Singh advises that a network should be dedicated to a single application; this ensures that applications are secure and isolated from one another.

Networking with the bridge driver works slightly differently when using Docker Compose. By default, Docker Compose will create a network with the bridge driver and will deploy the services defined in the Compose file to that network. This network is named after the directory that the docker-compose.yml file is in. This setup does not require ports to be exposed in order for containers to talk to one another; one should be able to call the hostname to reach another container. Calling ‘docker-compose down’ removes and deletes the network created from the docker-compose.yml file.

Instead of using the default Docker Compose network, a network can be defined inside the docker-compose.yml file. This definition happens at the top level of the compose file, similar to how a service is defined. This way multiple networks can be defined and used by a single compose file.

I selected this source because it was something I was interested in. I thought networking was exclusive to Docker Compose, and I was not aware that you could create a network for Docker images to communicate over. This does not help my problem of not being able to get Docker Compose services to talk to each other, but it does help to clarify some information I had been missing. I will internalize the information in this article for future work, but I also want to keep looking into this topic.

Additional Source

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Christian Shadis

Over the past month, my Software Construction, Architecture, and Design course has shifted gears into a sort of crash-course for full-stack web development. Our initial focus was on the backend of web apps and specifically on APIs. In class I learned how to edit API endpoints for different HTTP methods such as GET, POST, and PUT. I understood how to code the API and I understood the difference between the different HTTP methods, but I still did not understand the very basics of what an API was beyond its acronym. For this blog post, I set out to learn the fundamental nature of APIs to supplement my technical understanding. While it is helpful to know how to code an API, the knowledge would likely be useless without an understanding of what an API is or when to use one.

An API (Application Programming Interface) is a technology developed as a solution for multiple applications needing to communicate despite their incompatibility. For example, a person running Google Chrome trying to view the available items on a store website requires their web browser and the store’s server to be able to communicate. This is unlikely to be possible without an API. The API allows Chrome to send a request for information to the server, and then allows the server to return the requested data (or an error message) in a particular format such as JSON. The API facilitated the exchange of information between a client application and an unrelated server. This example illustrates the necessity of APIs. Without them, communication among devices built differently would be impossible. Web browsing as we know it would not exist, nor would web-based phone applications.

In What is An API and How Does It Work?, Thomas Davis first describes the omnipresence of APIs in everyday life even for non-programmers, and contrasts that ubiquity with the fact that few people understand how an API works, let alone what it does. He describes the API as an intermediary between two parties that do not speak each other’s language, and provides everyday examples of situations in which one would desire two computers to communicate. Once he explained the base concept of an API, he described different types of APIs such as the REST API, the SOAP API, and the XML-RPC API, comparing and contrasting each.

Knowing how to code APIs is an important aspect of backend development, but I feel much more confident in my ability to code an API now that I more fully understand the concept. I expect to build backends for web applications in the future, so this knowledge should be helpful in my development career.

References:

https://towardsdatascience.com/what-is-an-api-and-how-does-it-work-1dccd7a8219e

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.