Since I use different
computers from home, class, and work, after learning from class about docker
and setting up the same environment for all the devices, I thought it was time
to look into docker more. The article is about what is docker, why it became
popular and comparing it with other tools. That is why I choose this article
because “Docker overview” by Marsdev gives comprehensive introduction about docker,
comparing to virtual machine, use cases and advantage over other tools over the
internet. It clearly explains these things easily and detailed make it ideal
choice to learn how docker works and its benefits.

    The article covers essential components of Docker including
Docker Engine, Images, Dockerfiles, Docker Hub, Volumes, Compose, and Desktop
and how they work. For example, Docker Engine serves as the backbone of the
platform, enabling the creation and management of containers, while Docker
Compose allows developers to manage multiple interconnected containers with
ease. Not only that, but it also compares other tools that have similar functions
like Jenkins, Kubernetes. Not only that this article summarizes how container are
“given resources that no other process can access and cannot access any
resources that have not been specifically allotted to them”. In the end, Docker
is a powerful tool that makes development processes faster and build, test and publish
apps faster and efficiently than before.

Reading this article
and idea of ‘container’ showed why docker became a powerful tool for environmental
consistency. Also, I learned that I could have the same development environment
in different devices and applications now after installing docker, I don’t have
to constantly upgrade and downgrade versions of angular, node.js and different
things between different computers, applications. It was a pain going back and
forth and just a single program solves that mess I had. This program gave me a
clear roadmap for implementing containerization in my own work.  This article decreased the time I had to use
for development workflow compared to before. Not only that, but I am also
trying to use different dockers extension mentioned in the blog and others in
the marketplace for future use. Extensions like Disk usage help me double check
resource usage during development too. In the end, docker will save me time
during development and expand my base as a programmer as it decrease level of
errors between different versions of my program and the time to find those
errors.

Link to article – https://www.marsdevs.com/blogs/what-is-docker-why-is-it-getting-popular

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

    Since I use different
computers from home, class, and work, after learning from class about docker
and setting up the same environment for all the devices, I thought it was time
to look into docker more. The article is about what is docker, why it became
popular and comparing it with other tools. That is why I choose this article
because “Docker overview” by Marsdev gives comprehensive introduction about docker,
comparing to virtual machine, use cases and advantage over other tools over the
internet. It clearly explains these things easily and detailed make it ideal
choice to learn how docker works and its benefits.

    The article covers essential components of Docker including
Docker Engine, Images, Dockerfiles, Docker Hub, Volumes, Compose, and Desktop
and how they work. For example, Docker Engine serves as the backbone of the
platform, enabling the creation and management of containers, while Docker
Compose allows developers to manage multiple interconnected containers with
ease. Not only that, but it also compares other tools that have similar functions
like Jenkins, Kubernetes. Not only that this article summarizes how container are
“given resources that no other process can access and cannot access any
resources that have not been specifically allotted to them”. In the end, Docker
is a powerful tool that makes development processes faster and build, test and publish
apps faster and efficiently than before.

Reading this article
and idea of ‘container’ showed why docker became a powerful tool for environmental
consistency. Also, I learned that I could have the same development environment
in different devices and applications now after installing docker, I don’t have
to constantly upgrade and downgrade versions of angular, node.js and different
things between different computers, applications. It was a pain going back and
forth and just a single program solves that mess I had. This program gave me a
clear roadmap for implementing containerization in my own work.  This article decreased the time I had to use
for development workflow compared to before. Not only that, but I am also
trying to use different dockers extension mentioned in the blog and others in
the marketplace for future use. Extensions like Disk usage help me double check
resource usage during development too. In the end, docker will save me time
during development and expand my base as a programmer as it decrease level of
errors between different versions of my program and the time to find those
errors.

Link to article – https://www.marsdevs.com/blogs/what-is-docker-why-is-it-getting-popular

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

As I wrap up my last blog for the semester, I find myself still contemplating the career path I’ll take after completing my computer science degree. With so many options available in tech, one question that often occupies my thoughts is whether to pursue a role in DevOps or traditional software engineering.

Both fields are integral to the software development lifecycle, yet they have distinct focuses. Software engineering is primarily about designing, building, and maintaining software systems, while DevOps combines development and operations, emphasizing automation, collaboration, and the seamless delivery of software.

To better understand these roles, I explored the article Developer vs. DevOps engineer similarities and differences from TechTarget. This resource provides a clear breakdown of the responsibilities, skills, and career trajectories associated with both paths.

 Why I Chose This Resource

I selected this article because it connects concepts from CS 343; Software Design Principles . It also highlights the distinct mindsets and tools used in these roles, making it easier to relate the information to my interests and career goals.

What I Learned

1. Core Responsibilities: Software engineers focus on writing, testing, and debugging code, while DevOps engineers prioritize streamlining the software delivery process through automation and operational stability.

2. Skill Overlap: Both roles require proficiency in programming languages and version control systems, but DevOps engineers also need expertise in infrastructure-as-code (IaC) tools like Ansible and Terraform.

3. Collaboration: DevOps engineers work closely with both development and operations teams, emphasizing teamwork, whereas software engineers may work more independently or in smaller coding teams.

One point that resonated with me was how DevOps integrates continuous feedback loops into the development process, improving software quality and delivery speed.

Personal Reflection

Reading this article clarified the complementary nature of these fields. I’ve always enjoyed problem-solving and creating efficient solutions, which aligns with the goals of both software engineering and DevOps. However, DevOps’s focus on automation and system-level thinking piqued my curiosity, especially since I’ve been exploring tools like GitHub Actions in my personal projects.

This resource also reinforced the idea that adaptability is crucial in tech. Whether I choose software engineering or DevOps, learning skills from both domains will make me a more versatile professional. For example, I plan to experiment with IaC tools and practice creating CI/CD pipelines in my future projects.

Final Thoughts

Choosing between DevOps and software engineering is not just about job titles it’s about aligning your strengths and interests with industry needs. This exploration has helped me better understand what excites me about each field, and I feel more confident about preparing for either path.

For anyone considering a similar career decision, I highly recommend the TechTarget article. It’s a great resource for breaking down complex topics and understanding how different roles fit into the broader tech ecosystem.

Resouces:

https://www.gsdcouncil.org/blogs/devops-engineer-vs-software-engineer

https://www.techtarget.com/searchsoftwarequality/tip/Developer-vs-DevOps-engineer-similarities-and-differences

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

Since we’re diving deeper into web development, understanding how the frontend and backend work together is a must. It might sound like a techy tug-of-war, but it’s actually a smooth partnership—thanks to APIs (Application Programming Interfaces). Here’s how the magic happens, dumbing down.

The Frontend: The Face of Your App

The frontend is what users see and interact with. It’s all about the visuals and user experience. Imagine buttons, forms, and animations—that’s the frontend at work. Developers usually use HTML, CSS, and JavaScript frameworks like React or Angular to build this.

But here’s the kicker: the frontend is mostly clueless. It can show pretty pages, but it needs help to fetch or save data. That’s where the backend steps in.

The Backend: The Brain of Your App

The backend is like the brain. It’s where the logic, data processing, and database interaction happen. Built with tools like Node.js, Python, or Java, the backend handles all the “boring” stuff the user doesn’t see, like authenticating a login or storing a comment.

The frontend and backend don’t just shout at each other directly—they use an API to chat.

The API: Their Translator

The API is the middleman that helps the frontend and backend understand each other. Think of it as a menu at a restaurant(you would know if you read my previous entries). The frontend (the customer) picks something from the menu and places an order. The backend (the kitchen) cooks it up and sends it back. The API defines the rules of this exchange, so everyone’s on the same page.

Here’s how this plays out in real life:

1. Frontend Sends a Request: The user clicks a button to log in. The frontend sends an HTTP request (usually via POST) with the user’s credentials to the backend API at something like /api/login.
2. Backend Does Its Thing: The backend gets the request, checks if the credentials are valid, and prepares a response—like a token if the login is successful.
3. Backend Responds: The backend sends the token (or an error message) back to the frontend in JSON format.
4. Frontend Updates the UI: If the login worked, the frontend can now display the user’s dashboard. If not, it’ll show an error message like, “Try again, champ.”

Why This Connection Matters

APIs keep the frontend and backend loosely connected, so they can evolve separately. For example, you can upgrade your UI (frontend) without messing with your database logic (backend). Plus, APIs make your app’s backend reusable, other apps can connect to it too.

TL;DR

The frontend is the face, the backend is the brain, and the API is their translator. Together, they create the seamless apps we use daily. So next time you log in, search, or post, know that there’s a whole tech orchestra working behind the scenes. And now, you kind of know how it plays its tune!

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

This week, I will be talking about gatekeeping, specifically how it applies to the computer science community. First and foremost, we should define what exactly it is. Gatekeeping is the act of controlling or restricting access to something, such as information, or the participation in something, such as a group or community. In our example of gatekeeping, it will look at how people who are affiliated with the computer science community sometimes engage in this gatekeeping behavior, trying to control or restrict access to information and people’s participation in the community overall.

In the podcast, Chuck mentions, ‘There are quite a few people out there who are like, “you can’t make content on [whatever applicable subject], or you can’t do this, unless you’ve been doing it for like, 20 years,” even if they have been doing it for 20 years.’ This points out a glaring hypocrisy that is clear in this argument: the people that are gatekeeping others from participating in the community are often much like the very people they are trying to keep out. This is a problem, because by gatekeeping others and discrediting their ideas, you are losing out on potential present benefits, plus any long term ones that person likely would have contributed if allowed to participate. This also makes it harder for people who are actively trying to solve problems or work on projects, because gatekeeping shapes the community to look more like a zero-sum game, where the pool of ideas and influence is stagnant and does not contribute to any significant growth–in stark contrast to a positive-sum game, where said pool would be consistently growing with more and more people contributing their ideas and influence to the community.

Back to the podcast, the guest, David Bombal mentions, ‘There have been some discussions online about, “Who knows what they are supposed to know?” And I think that at the end of the day, everyone is a noob in something. It doesn’t matter what you do.’ This is another important point that highlights the inherent bias in gatekeeping against newbies and greenhorns who are at the beginning of their journey and have a strong potential to be dissuaded from the field entirely if they were to be on the receiving end of gatekeeping. However, this also carries the same potential to be a detriment to CS veterans. David continues, “I remember being the grandpa, learning NT4, and just as I got to know it, it changed.” This specifically applies to the computer science field, where new discoveries, changes, and updates are the norm, and one must always be learning to stay in the loop.

In conclusion, gatekeeping is a harmful social problem that continues to negatively impact the computer science community, and quashes a lot of potential for growth. It is important to recognize this, so you can stop it when you see it, and prevent yourself from contributing further to the problem.

https://www.youtube.com/watch?v=tWAkJw3_l2s

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

When I started studying computer science, I was unsure of what I wanted to do. As I learned, software development felt right for me, but that also asks another question, front end or back end? Initially, the front end seemed right for me, not for any particular reason other than working on the website felt better. However, after learning about both the back end and the front end, I am unsure now. 

In this blog post, Lane Wagner talks about their experience with front end development. They say that growing up, they wanted to be good at drawing, so that carried over into their computer science career. When they were working with front end things, they noticed that they focused their time on tweaking CSS, code for formatting the website, and it would always look bad anyways. They then decided that they wanted to become a back end developer instead, and talked about some other factors that affected their decision. These factors ranged from a number of things, such as pay and language preference, but the one that stuck out to me the most was feedback. They say that as a back end developer, you build code that is used by everyone, code like REST APIs, CLIs, and databases. This allows you to get feedback back from them in a way that is more constructive than if it was front end code, like UI. This lets you learn and improve.

After reading Wagner’s post, and reflecting on what I learned in class, I would also probably swing towards back end development too. The reason why I thought front end development would be better for me was because I am more artistic in a way. I also have a communication minor, so it would be a good way to combine the two. However, after learning both back end and front end, back end seems better to work with. The front end felt very convoluted to me, while the back end felt more seamless and streamlined. Maybe that was due to the fact that we spent more time learning the back end and playing around with it than the front end. Regardless, I would still love to learn more about both. I am still young, so learning both and maybe even working with both would help me choose which would be a better fit for me. But for now, back end development may be the better fit.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

RESTful APIs are a common and standard structure used to develop software applications. Lately in class we have been delving into how these APIs work using Thea’s Pantry as an example. I found this blog that gives a concise and easy to understand explanation of REST works. He gives a brief overview of what REST stands for and then explains its purpose. It used to make data transfer between client and server easier and more encapsulated. One of the points that was interesting to me and made a connection to what we learned in class about coding principles. The principle of encapsulation and keeping things as independent as possible. Trying to keep the server and client as independent as possible to make scalability and maintenance more efficient. The REST API serves as an interface between client servers that serves to communicate for them so they don’t have to.

It then goes into more detail about resources and URLs and return formats. It was also interesting to me that return formats could be more than JSON, the example they used was XML. You just have to specify, but I don’t know a reason why you wouldn’t use JSON. The Reason I chose this blog is because it is a simple explanation of what REST API is. For me personally, APIs can be kind of hard to understand, but this blog explains in a way that makes it easy to understand. The picture was a big help. Other than that I don’t really have anything to say. 

https://medium.com/@MakeComputerScienceGreatAgain/understanding-rest-api-a-comprehensive-guide-52fc10f6c9ed

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Hi class,

For this blog post I decided to choose the topic software testing. Software testing is one of the topics that we went over this course and furthermore, I hope you can have some good takeaways about how software testing is implemented out in the real world.

Before going into the summary, let me provide you with the resource that I am getting this information from. https://www.youtube.com/watch?v=PqCVDGhvEFs&t=1988s This is the link to the podcast I listened to called “Beyond Coding.” Here the host Patrick Akil, a software engineer looking to gain and share interest in coding, sits down with QA, quality assurance, engineer Augustine Uzokwe to discuss what a QA engineer does in software engineering. (I really do enjoy listening to podcasts so that’s why I have chosen a podcast format for my source.)

Patrick begins the podcast off by asking Augustine what is QA, quality assurance. Augustine replies it varies depending on the work and/or field the said QA is in, but in terms of this interview he will do this in perspective to software engineering. 

Augustine then goes onto talking about QA in software engineering. He goes on to state that yes, there is a lot of unit testing, but it is more so adapting, quick thinking, and team collaboration. He takes the approach of using broad practices such as pragmatic and being flexible. Furthermore, he goes on to state that if there’s two teams, Team A and Team B, what might work for Team A, might not work for Team B. 

He stresses this is totally okay, and acknowledges that this happens, but as a QA engineer you must find a solution fairly quickly. Not only quickly, but also find a smart solution. When a unit testing doesn’t have the correct output/run, he then goes on to state that rather than going back trying to fix everything then performing an end to end unit test, there’s a smarter approach that is better and in the long run will be quicker.

This approach is team collaboration. In the instance above, he would call all participating engineers in the code and simply talk and review the code with them. From here each engineer would have an assigned part to work on, then they would dispersed to work on their said assignment. In this time of working, Augustine stresses the QA engineer needs to take the lead and create an environment of openness amongst the fellow engineers. If one engineer has a question, they shouldn’t go searching for it online for three hours, but rather ask a fellow peer. 

Once a developer has their assignment done, it should be unit tested separately (if applicable). This is very beneficial because all the bugs can be found in that moment, then developed, rather than with an end to end test. In this time, Augustine would be spreading his knowledge of QA to the engineer so that way the engineer will slowly learn how to conduct and what to look for while on their own doing a software testing. 

Augustine states in today’s world of engineering how fast it is out there, but it is more so about “removing the waste” and improving as you go with unit tests/peer testing. Not only is this the case, but he also states that team maturity is very important and key. Furthermore, if a lot of engineers come together it doesn’t necessarily mean a quicker delivery. Engineers need to have a process in place and need to know how to properly test software, of which is where the QA engineer comes in to ensure quality over speed. 

My personal comments about this is that I like the way Augustine thinks a lot; quality over speed. Furthermore, throughout the podcast he says “win the time.” Before listening to this podcast, if I heard that statement in regards to programming I would’ve thought to write out the program as quickly as possible and then test at the end when I am “done” programming. Although after listening to the podcast, I would now think let me talk with my team, write out a plan to implement the code, code, ask questions, and unit test the code along the way. Overall, this was a very interesting listen and very insightful that could be useful to programmers of all levels; or even people wanting to implement a better structure of working on a team project.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

Estimation is a huge part of software development. It exists in many aspects of our work. The area where it is most important is estimation of development time. Many software methodologies are reliant on breaking down work into smaller parts and creating workflows. Like the famous Sprint from Agile. A common theme among all of these is estimating the time it will take to complete these tasks. And on a larger scale, how long it will take to finish a feature or product.

In this blog by Yaakov Ellis, discusses the importance of estimation. Moreover, the skills needed to make a good estimate. He first discusses the usefulness of estimation. How good estimates increase efficiency and reduce crunch time. One of the most important points of the article is the prerequisites needed to make good estimates. Such things like good and detailed specifications and understanding functionality. A point that stuck out to me is that he says that the people who do the work should do the estimates. Seems like something obvious but needed to be brought up nonetheless. There were many other points like not giving in to outside pressure to give an estimate that was unrealistic.

I chose this blog because a lot of what we talked about in class was teams deciding how much time to spend on certain things. Not only sprint lengths, but every part of Agile. Estimating the length of the project to even just a simple bug fix could take. I think it is a skill that is often overlooked. As someone who is bad at giving estimates and gives in to pressure to please people. I think that is something I will think about when making these decisions more. Some last points that I liked was the idea that you should estimate the public so everyone on the team can see them. I think that would decrease the risk of bad deadlines that force crunch on developers. 

Citation

https://stackoverflow.blog/2019/10/23/why-devs-should-like-estimates/ 

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.