Although I dedicated my previous post to introducing REST and RESTful API writing, I feel that it is important to briefly return to talking more about Docker, given how much I have come to using Docker containers for a significant part of my studies recently. In this blog, I have talked about containerization as a concept overall and not exclusive to Docker, as well as some of the things that can be done when using Docker. Namely, I discussed data management through use of volumes and mounts and container networking through port mapping. Such  features can be rather straightforward and easy to use individually and with enough practice during application development, however as development becomes more complex and demanding, having to repeatedly run commands to enable further functionality can be rather cumbersome for individual developers and overwhelming for the entire development team overall. This is not exclusive to Docker; certain utilities or commands used in development that are used especially frequently may overcomplicate the development process. Thus, often, a certain degree of automation or simplification is needed.

In my experience, I have used scriptwriting in order to speed up parts of my development process. In Docker, where it is possible to have to manage multi-container applications at once, having to manually define ports and volumes for each service individually can be extremely inconvenient for complex application development. Therefore, docker-compose YAML files  are often utilized to manage multiple services, volumes, and networks at once and in a more organized manner. Though a docker-compose file is not exactly a script file when it comes to defining container services, they can still help condense the entire process to create a service into one file. Moreover, to utilize a Docker container for application development, a docker-compose YAML file is not enough, as a Dockerfile is also needed in order to build the container’s image. However, for simplicity, I will only focus on the compose file.

Like I mentioned, a compose file is not necessarily a script file, not at least from my experience of writing script files. Despite this, there is a certain structure that needs to be followed when writing docker-compose files in order to ensure the proper functionality of the application. One resource that I found in my research regarding writing docker-compose files is an article named Introduction to Docker Compose posted on Baeldung.Com by Andrea Ligios. In this article, Ligios begins by briefly introducing the theory YAML configuration files and why using such a configuration file is preferable for development. Moreover, they proceed to illustrate the basic structure of a docker-compose file by highlighting the services, volumes, and networks to be used for the multi-container application, before they go into further detail on how to set up each of the previously mentioned sections and provide examples.

While it is important to understand how each part of a docker-compose configuration works individually, when it comes to larger-scale development and deployment, simplifying the process through use of docker-compose files can be extremely helpful.

Direct link to the resource referenced in the post: https://www.baeldung.com/ops/docker-compose

Recommended materials/resources reviewed related to :
1) https://www.tutorialspoint.com/docker/docker_compose.htm
2) https://docs.docker.com/compose/
3) https://dockerlabs.collabnix.com/beginners/difference-compose-dockerfile.html
4) https://phoenixnap.com/kb/docker-compose
5) https://runnable.com/docker/docker-compose-networking

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

This week will be continued talk on APIs and specifically I wanted to learn more about the structure of our API’s including on the differences between frontend and backend and any extra information on API’s that can be included. I have chosen a website that goes over what exactly these are and gives a good amount of information that could be useful later down in our careers.

In summary, frontend and backend are two very popular terms in web development. The term frontend is usually used for the part of the website that the user directly interacts with like the GUI’s. This is also called the “client side” of the application and use languages that should sound familiar to you such as HTML, CSS, and JavaScript with JavaScript being the most popular language of them all. This is because of several advantages such as flexibility, speed, and extended functionality although it does have some disadvantages in areas such as with debugging. Now if the frontend is what the user interacts with, the the backend should be everything that is kept out of sight from the user such as work with the databases, the scripting, and the API itself while making sure it can connect to the frontend. The languages used include python, PHP, and java all being widely used. The work on the frontend and backend has also become quite specialized over the years in which it is usual for one person to either work with just the frontend or just the backend and people who work on both are called full stack developers.

This resource has given me insight on the work we are doing with the API’s and with the work we are doing on the backend. The work that we are doing with the databases and the API’s is an entirely different area from the frontend that we haven’t even touched yet. The areas that have to be learned are numerous that require different sets of skills and talents to work in. It makes me wonder on whether we will get to work with the frontend in this class or in a future class. The I should prepare myself a bit more if one would want to become a full stack web developer seeing the needed skills in both ends. Although I haven’t done much work on any frontend material so I would have to wait to see on what the experience is like when working on the frontend on deciding if I should focus on one or another in the future.

Source:https://www.interviewbit.com/blog/difference-between-frontend-and-backend/

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

Resource Link: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#single-responsibility-principle

For this blog post, I wanted to delve into what the SOLID principles are and how they apply to object oriented programming. SOLID is an acronym for the 5 object oriented design principles. They are the single-responsibility principle, the open-closed principle, the Liskov substitution principle, the interface segregation principle, and the dependency inversion principle. The reason these principles are important, and why they’re important to use is that they help to maintain good coding practices and help to avoid code smells. This is essential in large projects, as code smells and bad design could increase development time, make refactoring harder, and make development harder for teams if other team members couldn’t understand the code.

The first principle of SOLID is the Single-Responsibility Principle. It states that a class should have only one reason to change, and that it should have only one job. This means that a class should only have code related to its function, and not extraneous code that should be elsewhere that’s unrelated to the class’s intended purpose. This helps to keep classes simple and easy to understand. If a class contained logic unrelated to its purpose, then it would make the intended purpose of the class confusing.

The second principle of SOLID is the Open-Closed Principle. It states that a class should be open for extension but closed for modification. This means that a class should be designed in such a way that if a modification to that class is needed, it can instead be extended by a different class, and then that class could be modified while maintain the functionality of the original class. The also helps the make each class have its own specific purpose. If instead of creating a new class, a single class was modified every time a modification was needed, then the class would get messy very fast, making it hard to read and hard to understand its functionality.

Next, the Liskov Substitution principle states that every subclass that extends another class should be substitutable for the parent class. This means that for example, if there was a shape class, and then a square class extended the shape class, then the square class should be able to be used in place of the shape class.

Then, the Interface Segregation Principle states that classes shouldn’t be forced to use an interface which has functionality that it has no use for. This means that if an interface has some functionality that doesn’t apply to everything, then a class shouldn’t use that interface if it won’t be using that functionality. Instead, interfaces should be very broad, making them applicable for many different purposes.

Finally, the Dependency Inversion Principle states that functionality should depend upon abstractions, not concrete methods. This means that if you have a class that must perform some functionality, and it shouldn’t depend on an exact implementation, then the class must be design in such a way that it applies to all implementations, based off abstractions.

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

This week I read a blog post that I thought really related to the class about agile software development. The blog is about the phases of the agile software development lifecycle. The blog starts off explaining Agile and why it is used. It is being used because of its flexible, iterative, and incremental character. The blog then goes into the phases, and some agile techniques and tools. The phases are requirements, design, development and coding, integration and testing, implementation and deployment, and finally review. Some of the tools and techniques are spiral SDLC, and waterfall SDLC. The blog then goes into the pros and cons of agile software development. A pro is that there are flexible working hours around the clock, and a con is that all communication takes place on the internet, so it might be harder to connect with fellow developers. The blog ends by summarizing the cycle of agile software development, and describing it as aiming to build and deliver flawless working software on a tight schedule.

I selected this blog post because software development is my dream job, and I thought it would be interesting to read about a possible way I might be working using the agile method. This blog has a great way of showing how agile software development works, and how useful it could be, and I think every CS major should read it since we have to take another class similar to the things in this blog with software process management.

 I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because of how deep it goes into explaining the cycles of agile software development . The blog gives a description for every phase, and explains what to do at every phase, what others are going to do while you are on that phase, and what tools to use when you are on the phase. Another reason I would recommend this blog is because a lot of jobs that we will be looking for in the future will be using the agile method, and if we are not good at using it, then we are at a disadvantage to be hired. The last reason I would recommend this blog is because it is focused on teamwork, and teamwork is important for every job, and not just computer science related jobs. Agile could be used anywhere. 

This blog taught me about all the phases, and that if they are all done correctly by a team of developers, they could really work productively as a cohesive unit. The material affected me heavily because it showed me what skills to learn, and what to expect if I want my future dream of software development to come true as many jobs might be using the agile method, so I must be prepared. Now that I know about the agile software development method, I will try to look for more different methods.

link: https://relevant.software/blog/agile-software-development-lifecycle-phases-explained/#Output

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

The Unified Modeling Language (UML) is a standard for diagramming the design of a computer program. UML class diagrams illustrate the classes and relationships of an object-oriented program. The five fundamental class relationships are dependency, aggregation, composition, inheritance, and realization. When my professor introduced UML, he provided instruction on inheritance and realization. Because an understanding of the five relationships is essential to reading and building UML class diagrams, the goal of this post is to familiarize myself with dependency, aggregation, and composition as well as their applications. To achieve the goal, I will be reflecting and adding to the blog, “Association vs. Dependency vs. Aggregation vs. Composition,” written by Niraj Bhatt, an enterprise architect at Advent eModal. In the post, Bhatt defines and applies the relationships.

Dependency is a relationship between two classes where one class uses the object of another class as a parameter of a method. One can represent it by drawing a dotted arrow from the user class to the class being used. Bhatt exemplifies the relationship in a program that simulates a turn-based game. The program acquires a Player class with a TakeTurn method that expects a Die object. Bhatt’s example is effective because, in many turn-based games, a player uses a die during his or her turn.

Aggregation is a relationship between two classes where one class owns the object of another class as an attribute. If an instance of the owner class ceases to exist, the object of the other class would still exist. One can represent it by drawing a line with a hollow diamond from the owner class to the class being owned. Because Bhatt exemplifies the relationship in an unfamiliar type of game, I will be providing another example. Another application of the relationship is in a course management system where the Course class owns Student objects. The application is effective because students will exist when courses do not.

Composition is a relationship between two classes where one class needs to have an object of another class as an attribute. If an instance of the former ceases to exist, the object of the latter class would cease to exist too. One can represent it by drawing a line with a filled diamond from the owner class to the class being owned. Because Bhatt exemplifies the relationship in an unfamiliar type of game, I will be providing another example. An application of the relationship is in an online shopping system where the Customer class has Order objects. The application is effective because orders would not exist without customers.

If I continue to pursue a career as a software engineer, my newfound understanding of class relationships will help me carry out my responsibilities. Many companies use UML to illustrate their software systems. I may need to apply the relationships to blueprint software or understand them in existing software to implement new features.

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

When writing code, it is always important to write as cleanly and efficiently as possible. Code can be sometimes confusing and hard to read to begin with, and writing poor code makes it much harder. We measure the quality of code using design smells. Design smells are different metrics such as rigidity and fragility which measure how poor a certain part of design is.

Yonatan Fedaeli writes in his article “Software Design Smells” that there are seven main design smells: rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity. These smells exist in all code to a certain extent, but some code has much less smells than others. The goal is to limit each of these smells as much as possible.

Rigidity is software’s inability to change. This makes it very difficult to add new features to a project. An easy way to fix this design smells is by designing each section of software independently of each other since the more interdependence a project has the more rigid it will be.

Fragility is a software’s tendency to break whenever a change is made. This is similar to rigidity, but different in that it is not difficult to make the change but difficult to make the change work. Any small change can totally break the entire project in a very fragile design.

Immobility is a project’s inability to reuse components. When a project is immobile, each piece of the project is so dependent on the rest that is almost impossible to use it in a different context. When writing a large project it is important to reuse code so that you are not wasting time writing the same thing multiple times.

Viscosity is how closely a project follows the original design goal. When a project is very viscous each new feature either preserves a complex design or does not follow the design goal. When a project’s environment is viscous it means that the project exists in a complex work environment. It may be difficult to build or test and you may spend extra time trying to get the project to run.

Needless complexity is when a project is more complex than it needs to be. Software is already complex to begin with, and it is important to write clear code so that people reading it do not need to spend extra time trying to figure out what it does.

Needless repetition is when code is repeated multiple times when it could be abstracted. This is similar to immobility in that code is not reused, but different since this smell focuses on abstraction and how code does not need to be rewritten many times.

Opacity is a project’s inability to be understood by the developer. This is similar to needless complexity in that an opaque project can be needlessly complex, but includes much more than that. Usually an opaque project has a poor initial design which is why it is difficult to understand.

When writing code it is important to write clean, efficient code. Keeping design smells in mind when coding will keep your projects clean and good quality.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.