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.

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.

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.

Licensing may seem like an obscure legal detail, but it plays a critical role in scientific software development. In “The Whys and Hows of Licensing Scientific Code”, Jake VanderPlas breaks down why picking the right license is key to sharing and advancing research.

Summary of the Article

VanderPlas emphasizes three key takeaways:

Always license your code. Without a license, code is effectively closed, limiting its reuse. If you don’t, it’s basically off-limits for anyone else to use.

Use a GPL-compatible license.This makes it easier for your code to work with other open-source projects.

Prefer permissive licenses like BSD or MIT. These licenses lower barriers for collaboration, they are the most flexible and let people from both academia and industry collaborate freely.

Licensing is crucial for scientific reproducibility and collaboration. Even if you post your code publicly, without a license, it’s still “all rights reserved,” meaning others can’t legally use it. VanderPlas recommends permissive licenses because they encourage more people to adopt and improve the code. On the other hand, copyleft licenses (like GPL) keep the code open but might scare off companies from getting involved.

Personal Reflection

While reading this article, I found VanderPlas’s insights particularly relevant and important. I appreciate how licensing can help bridge the gap between innovation and real-world impact. The idea of using BSD or MIT licenses makes sense because they’re simple and open the door for more people to get involved.

This also made me think about how intentional we have to be with our work. Just like we carefully document research methods, licensing makes it clear how others can use and improve our code and/or tools. It’s a good reminder that open science isn’t just about sharing, it’s about having solid guidelines that make collaboration easier and that push science forward.

Citation

VanderPlas, J. (2014, March 10). The Whys and Hows of Licensing Scientific Code. Pythonic Perambulations.

Link of the article: https://www.astrobetter.com/blog/2014/03/10/the-whys-and-hows-of-licensing-scientific-code/

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

Week-13: 12/2/2024

This week in class we worked on merge conflicts and how to resolve them. I had to do an activity that had to do with solving a merge conflict. This experience was not as frustrating as I thought it was going to be. While doing the activity, Professor Wurst highlighted how important it is to understand version control systems like Git and to develop effective strategies for resolving conflicts collaboratively.

On this week’s blog hunt, I came across a helpful blog post by Sid Puri titled “Git Merge Conflicts,” which provided a clear explanation of what merge conflicts are, why they occur, and how to resolve them using Git tools. It broke down the process into manageable steps and even offered advice on how to prevent these conflicts from happening in the first place.

One of the key takeaways for me was understanding the root cause of merge conflicts: multiple developers making changes to the same file at the same time. Because Git can’t automatically figure out which changes to keep, it flags these conflicts and requires manual intervention. The post explained how to use Git’s notification system to identify conflicts and then how to manually merge code using conflict markers – those weird symbols like <<<<<<<, =======, and >>>>>>> that used to make my head spin.

The post also emphasized the importance of communication in preventing merge conflicts. This really resonated with me because our team conflict stemmed from two of us accidentally modifying the same section of code. If we had just communicated about our tasks beforehand, we could have avoided the whole issue. Moving forward, I’m definitely going to advocate for more frequent team check-ins and a more organized approach to task allocation.

What I really appreciated about the blog post was its practical approach to conflict resolution. It explained how to use built-in Git tools like git status and git diff to navigate conflicts with confidence. Mastering these tools will definitely save me time and frustration in future projects. Plus, learning how to handle and resolve conflicts collaboratively is a transferable skill that will be valuable in any team setting, not just software development.

Overall, this blog post was a great resource that directly complemented our coursework on team-based software development. It reinforced the idea that understanding and resolving merge conflicts isn’t just a technical skill; it’s an essential component of effective teamwork in software engineering. I feel much more prepared to tackle these challenges in the future and to contribute more effectively to my team projects.

Blog link: https://medium.com/version-control-system/git-merge-conflicts-4a18073dcc96

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