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.

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.

Link to blog: https://dzone.com/articles/java-rest-api-frameworks-1

In class, we’ve been covering REST APIs and how to use certain call methods such as GET, POST, PUT, and DELETE. Before class, I had heard of REST APIs but never had any understanding of what they were, or how to interact with them. I figured I would dive deeper into other Java REST APIs. The article Java REST API Frameworks by Farith Jose Heras García lists some REST APIs along with their advantages and disadvantages.

García begins with a simple introduction to Java REST APIs and what they do, specifically how they enable communication between applications and other software, and make the passing of data easier. Each API on the list includes pros and cons, and then a CRUD (create, read, update, and delete) example using the API. 

First on the list is the wildly popular Spring Boot. According to García, some of the benefits of Spring Boot are that it is easy to use and set up, has a lot of built-in support, and has a large library of plugins and modules. The cons are that beginners might struggle to understand it, and it might be too much for smaller projects and better for larger projects instead.

Second on the list is Jersey. Jersey is simple, ideal for microservices, and also has a decent-sized library. However, García considers it slow and difficult to debug.

Third on the list is Play Framework. It’s lightweight and flexible, high performance, and also offers a library of plugins. It’s updated and designed for modern Java applications, as it works with Java 8 and Scala. Unfortunately, it has a tough learning curve and debugging can be a challenge.

The final on the list is Vert.x. It is lightweight, flexible, and has high-performance, and also supports JavaScript. The cons are that it is difficult to debug and might be hard to understand for a first-time user.

I selected this resource because it is an article that is a good reference for an updated list of Java REST APIs currently in use. It gets the point across for each item, whilst being a short enough read to be a good refresher for those unfamiliar with the information. It’s mainly beneficial for choosing which REST API to use with your project or application.

I found this to be a solid article for learning a little bit about Java REST APIs and how to choose them. For example, I did not know that Spring Boot is too heavy for smaller applications. The formatting was simple, and it’s pretty interesting to see the frameworks in action with the CRUD code examples García provided. Choosing the right REST API framework for your project’s needs is very important since many factors can go into such a decision (size, libraries, and easy learning curve). I hope to apply this to projects of my own and perhaps jobs where REST APIs are needed.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

As I become a more knowledgeable developer, I hear the term ‘software framework’ being used more frequently. In my research, I’ve seen an increased interest in frameworks such as Angular and React. To understand what these are, I must first define what is a software framework.

In the article What is a Framework? Software Frameworks Definition, written by Joel Olawanle, walks through a general definition of software frameworks, comments on how they may be applied, and how they differ. Olawanle defines a framework as such, “…is a structure that you can use to build software. It acts as a foundation so you don’t have to deal with creating unnecessary extra logic from scratch.”(Olawanle). Supposing a framework is implemented correctly, developers will save time allowing them to start the project earlier. Additionally, the foundation it provides will not be prone to human error. If the components of a framework are implemented from scratch, then there could be errors that would be much more difficult to fix further in development. Since frameworks can be modified, there is less of a reason to implement their functionality from scratch.

Olawanle expands his definition to other aspects of software development. Before reading this article, I understood that there were both frontend and backend frameworks, but I was surprised to learn that mobile applications and data sciences have their respective frameworks. While reading Olawanle’s article, I noticed a framework I used a few years ago, that being Bootstrap. This qualifies as a software framework as it gathers files needed for a functioning website (.html, . css, and .js) into one structure. This allows the developer to easily make their website without having to build this structure. Angular and React both are classified as Frontend frameworks. Both of these are used for creating interfaces for websites, but each has its unique components. React can use JavaScript to create HTML and CSS files, meanwhile Angular has dependency injection allowing it to more freely communicate with other applications. Each of these creates a specialized purpose for the framework. 

Depending on where a developer is working (front end, back end, etc), there will be a framework that can create a strong foundation for their code. Before selecting their framework, the developer must weigh the tradeoffs between the various frameworks and consider which would support their project principles the most. Using a framework in this scenario would save time and reduce any human error manually implementing these components introduce. In my experience with Theas’ Pantry, the backend does not use any framework listed within Olawanle’s article. After reviewing the documentation, it seems as if the back end would not support these listed frameworks as they are not directly language-compatible. This means more time and resources would be invested into implementing the framework, than potentially implementing components of such individually. Frameworks provide a strong starting point for development teams, depending on the design choices frameworks may be incompatible with certain projects.

Link to Article:

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

-AG

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.