What is a Dev Container?

A Dev Container, or development container, encapsulates a complete development environment accessible through Secure Shell (SSH) in your preferred Integrated Development Environment (IDE). It overcomes workflow impediments such as low performance and limited bandwidth by providing an isolated environment with standardized configuration stored in a .devcontainer.json file. This JSON file, structured with Comments (jsonc) metadata, allows customization for specific needs, such as adding tools or extensions.

Why Use it?

Addressing Setup Configuration Issues: Maintaining and managing local environments involves the use of various tools and configurations, leading to a cumbersome process. Standardizing this process with a unified approach can significantly save time and streamline setup configurations.

Standardizing Build Instructions of the Project: Documenting dependency upgrades and changes can be challenging. Utilizing code rather than extensive documentation simplifies the process, enabling anyone to ship without being hindered by the “it works on my machine” dilemma.

Ensuring Isolation of Development Environments: Developers often work on multiple projects simultaneously, each with its own complexities. Isolating environments prevents conflicts with other software on the host system, creating a clean, controlled space for development tasks.

Enabling Consistency Across Development Teams: Achieving portability across diverse teams is complicated by varying technologies and configurations. Implementing a standardized development environment ensures uniform configurations among team members, minimizing inconsistencies from individual machine differences.

Simplifying Onboarding and Training Processes: Quickly launching environments in isolation facilitates learning new languages or frameworks. This approach is particularly beneficial for onboarding and training processes, keeping machines clean and allowing for smooth presentations and workshops, where everyone can follow along without interruptions caused by missing tools or confusion mid-step.

Dev Containers in Real World Enviroment

1. Standardized Development Environments:
   • Dev Containers provide a standardized and reproducible development environment, ensuring that all team members work with the same configuration. This minimizes the “it works on my machine” issue and streamlines collaboration.
2. Setup Configuration Management:
   • Addressing setup configuration issues is simplified with Dev Containers. They help in managing dependencies, tools, and configurations uniformly, reducing the time and effort required for setting up development environments.
3. Version Control Integration:
   • Dev Container configurations are often stored in version control systems (e.g., Git), ensuring that the development environment is versioned along with the code. This enhances collaboration and makes it easier for team members to switch between branches or versions seamlessly.

Personal Experience

Dev Containers are something I have recently just learned about, and I feel like the need for them is understated. The overall idea behind such a tool is to create a simple and consistent environment for a team to work in. Anytime I work on a project, I stress the need for one as it eliminates many common problems teams face in the early stages of development. I also believe that when I start my professional journey, I will find these containers to be more standardized within the teams I work with.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

After reflecting on the previous blog that I had written about coding, I pondered about what would happen if I were to work with software, and I immediately wanted to consider something about a software’s own making. For this blog, I decided to focus on Software Framework, which many programmers and organizations make great use of in the workforce. I took great interest in an article written by Tiago Monteiro, fittingly titled “What is a Software Framework?” It starts by giving the reader a simple concept where a man uses an axe to cut trees and then cuts wood to use for his fireplace for his family. When the chainsaw was introduced into this analogy, it related really well to programming, where you either start with fresh new code or make use of an existing framework done by another user to build your program. Reading more into the article, I found that there were advantages and disadvantages to using a software framework. While a framework is how anyone would start to form their own software, nobody has much freedom to alter the framework, limiting the use of a software framework to the functionality it was designed for.

I chose this article for my blog, because I believe that this article might help me in understanding a bit more about Software Engineering. Although the author of this article is a high-end Computer Engineer, his article could still give me an idea of what I should visualize when I start to learn more about designing software. A software has to have a framework to maintain functionality so it does not become inept, just as a computer will stop working if one of its most important parts either burns out like a wildfire or starts to malfunction upon reaching the end of its half-life.

My biggest takeaway from this article is that there are lots of software frameworks with many functionalities that are made useful in different manners.  Just as we try to create the framework to integrate smart machines into our appliances and everyday tools, we try to do the same with creating framework in our software as well.  We give life to our software the same way we try to create new computers, by giving it a spark of new and innovative programs for the greatest user and technological experience.

Reference: https://www.freecodecamp.org/news/what-is-a-software-framework/

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

We’ve covered a great many design principles during the course of this semester in Software Construction, some of which I’ve even covered in these blog posts (law of demeter comes to mind). For the end of the semester, I wanted to have a little review on some of the principles that I don’t recall all too much.

Starting off with one that isn’t too complicated, I wanted to briefly refresh on the YAGNI (or You Ain’t Gonna Need It) principle. According to a blog post by Tatum Hunter of Built-In, the practice entails only building features when needed. I found this post fairly insightful in the way it goes over how customers might want a large-scale feature now, so you may have to talk them down to a more realistic goal to avoid adding functionality that won’t be necessary, or to say no.

The principle of “striving for loosely coupled designs between objects that interact” is essentially implementing the observer design pattern. I believe I went over this in a previous blog post, but I did find another post by Harold Serrano that provides a brief summary as well. Serrano states that the principle means that objects should be able to interact with each other, but shouldn’t know much about each other.

For the principle of “encapsulating what varies,” a simple blog post from Alex Kondov explains what this means and why we do it. Essentially, we want to encapsulate the parts of the code that we write which are prone to change so that we don’t have to change a whole block of code for something that should be a one line fix. This makes our code adaptable and leads to cleaner code.

Inversion of control is used for abstraction simplicity. Kent C. Dodds explains that we want our abstraction to have less responsibility, while the user has more. He uses an example of a filter method that uses inversion of control, and one that doesn’t. The difference is that when the control is passed into the method rather than handled in the method, there is a lot less going on within the method, which increases simplicity. I found this really interesting because I was thinking about doing this for our GuestInfoBackend homework, before I kind of lost interest because I’m not too well-versed with Javascript, and I didn’t have much time to do it, hah. Needless to say, it’s a really interesting tool in my opinion and I find it very practicable.

This semester, we’ve gone over a great many ways to ensure proper software design, and these practices and skills are a great way to streamline your thought process. I think the important thing, as I’ve said before, is to not treat these as concrete rules, but to consider them in higher priority before writing code. Sometimes, you can’t get the perfect solution that fits all the proper software design principles, and that’s okay. It’s a matter of making sure the code is solid, pun intended.

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

Design Patterns

A design pattern is a general solution that can be used to solve commonly occurring problems in software design. A design pattern cannot be put directly into code, rather it is a template of how to solve a problem that can be used various situations.

Design patterns are helpful as they speed up the development process by providing proven examples to be used as a reference for common problems. When designing software, small subtle issues can build up leading to major problems that can only be seen during implementation. Using design patterns can help prevent these subtle issues from occurring which reduces the likelihood of major issues occurring.

Because design patterns are tested, proven, and commonly used, patterns also allows for better communication among developers by using well known and understood names for software interactions.

Types of Design Patterns

Creational

Creational design patterns cover class instantiation. These patterns can be further divided into two classifications, class-creation and object-creational patterns. Class creation uses inheritance in the instantiation process, while object creation uses delegation to create objects. Some creational design patterns are:

• Singleton
  • A class where only a single instance can exist
• Factory Method
  • Creates an instance of several derived classes
• Object Pool
  • Avoids expensive acquisition and release of resources by recycling objects that are no longer in use

Structural

Structural design patterns are about class and object composition. Like creational patterns, structural patterns can also be broken down into class creation and structural object patterns. Class creation patterns use inheritance to compose interfaces, while object patterns define ways to compose objects to obtain new functionality. Some structural patterns are:

• Adapter
  • Matches interfaces of different classes
• Private Class Data
  • Restricts accessor/mutator method access
• Decorator
  • Adds responsibility to objects dynamically

Behavior

Behavior design patterns are about how objects communicate with each other. Some examples of behavior design patterns are:

• Null Object
  • Used to act as a default value of an object
• Chain of Responsibility
  • A way of passing a request between a chain of objects
• State
  • Alter an object’s behavior when its state changes

Conclusion

This article was chosen because it clearly described what design patterns are, what they are used for, and gave examples of the different types of design patterns. As stated before, not only does the usage of design patterns help with preventing major issues, they also allow for better communication among developers which is essential to a team’s success which is why I chose to write about design patterns. As I continue to design software, effectively using design patterns will become more and more prevalent, so learning about them now will only be beneficial.

Resources:

https://sourcemaking.com/design_patterns

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

In this blog, I will go over the code “smells” pertaining to the Javascript language. For this topic, I picked a specific blog post called “Javascript Code Smells: 7 to Watch out For” written by .NET software developer Carlos Schults. It delves into this topic with lots of general details that explain some bad coding practice that can lead to your code having many problems. One of the main points that the blog emphasized was that long code alone was not a bad thing rather, the difficulty of reading lines of code that became too complex to handle makes these coding “smells” important to look back on when writing code.

The reason why I picked this topic is because I have had trouble with Javascript that I had never experienced before with other programming languages such as Java or C. One of the biggest factors that made it harder to understanding Javascript was its different and more difficult use of syntax. One of the coding “smells” the blog goes over was the difference in using the equality operand in Javascript compared to Java. Since I have been more involved with other programming languages such as Java than Javascript, learning the different coding structures of Javascript was going to take a while for me to grasp, especially since coding software such as OpenAPI uses Javascript to define its data and endpoints.

My main takeaway after reading this blog was that I should continue to further explore Javascript, while also maintaining the knowledge that I currently have when it comes to organizing the code I write. Reading this article about Javascript coding “smells” was very reassuring since I may have to find a similar reference to keep my coding consistent even after learning Javascript and not let it worsen with more and more complex functions for future coding. Having already had lots of experience with other programming languages in the past, I can use what I have learned from this blog and make better use of Javascript moving forward. 

Reference: https://www.testim.io/blog/javascript-code-smells/

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