Category Archives: CS-348

A List of Open Source Software


Open-Source software has become a vital source of tools for the development community, as well as innovative software. Recently I have become interested in finding out just how many of the applications I use are open-source, while at the same time finding new open-source software. I want to expand the software I have at my selection. First, let us reestablish what open-source software means: software that can be modified, enhanced, or inspected by developers who are not the original creators. This is done by packaging the source code along with the software so that it can be edited by anyone who knows how to.  

To start off this extensive list, Mozilla Firefox is open source to my surprise. Firefox has its source code internally available within the browser itself and can be found by using the URL and has guidelines for contributors up on a separate website. Mozilla also has the source code for countless other projects up on GitHub, such as Gecko, the rendering engine for Firefox. Continuing down the list we got GIMP and Blender, two powerful tools for any aspiring artist out there. In recent days I actually downloaded Blender onto some of the computers at the school I work at. While I am not going introduce 3D modeling to my middle schoolers, there have been students who have shown an interest in the subject. I thought having Blender available to these students would foster interest and motivate these students to pursue more. It is for situations like these that I believe in the importance of open-source software and the need to have these tools available to all. GIMP has helped me out here and there in the past, and since it is the only image manipulation software that is free, I am also planning to implement it in my classroom. 

One of the most important pieces of open-source software is none other than the operating system Linux. So many pieces of technology are running on Linux, or some variation thereof. Android OS is based on Linux and is also open source, Chromebook OS is based off Linux, several routers are using Linux. From cars, TVs, to even super computers, Linux has been a reliable operating system for a massive amount of hardware. Even NASA has completely switched over to Linux as of 2013. I am partially convinced to convert to Linux after all the compelling evidence I found.  

Finally, I have already mentioned LibreOffice in a previous blogpost as well, but it bears mentioning here. Microsoft Office is such a ubiquitous piece of software it is almost impossible to work in any sector of society that does not make use of it. The downside is that it is expensive for many. This is where LibreOffice comes in and offers a free alternative that does not require making an account of some kind like Google’s services. It perfectly embodies the spirit of open-source software.

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

process models

With the final blog post of the semester for Software Process Management, I wanted to review the process models we went over (waterfall and agile approaches), and perhaps take a look at some more models that we didn’t go over in class.

The waterfall approach as we went over it in the semester essentially that everything is planned at the start of the development process. This means that the plan is rigid during the course of the process. With the agile approach, the plan is highly flexible and able to change during the course of the process. Each increment of development, usually a few weeks, is followed by a plan for the following few weeks, and the cycles continues, with each aspect of the plan being adjustable as needed.

The agile approach is great for large projects and very versatile, but what other process models are there? In a blog post written by Omar Elgabry, he lays out two models that sort of make up the agile process model (incremental and iterative), as well as two other models, the spiral model and the prototype model.

Both the incremental and iterative models are based on increments of development, but the increment is the difference between them and the agile model. With the incremental approach, a complete feature is completed with each increment. With the iterative model, each increment is a small portion of all features. Compare with agile, in which each increment is a small functional portion of each feature.

The prototyping process isn’t a whole process by itself, it’s rather a tool in the form of a process to test the feasibility of a project. It’s in the name, a prototype is quickly built according to a customer’s requirements, and is helpful when the resource cost of a full project isn’t clear. The customer is usually in the loop for the development of the prototype. Once this prototyping phase is complete, the development team can opt for another process model to move forward.

The spiral model is used for cases where there is high risk associated with the project, typically large projects. The model is rarely used, but is good for testing feasibility. Essentially, each loop in a visual spiral is a phase of the project, and each phase is made up of an objective setting phase, a risk analysis phase, a development phase, and a planning phase where it is determined if the development should continue into another phase.

While I appreciate the spiral model for it’s uniqueness, I can definitely see why most teams use the agile model. It’s essentially a direct improvement from the incremental and iterative models in terms of versatility, and if you need a prototype, you can still build one using that process. Still, it’s interesting to know that we are still trying to find more ways to streamline our development to be more efficient, and I’m sure someday even agile will be taken over by another model.

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.

Week 14 Blog

  This last blog post I decided to revisit an important topic in class: Agile Project Management. This topic initially piqued my interest due to my lack of prior knowledge about how crucial project management can affect the product of a project. The blog post I chose highlights the Agile Manifesto and the twelve key principles to Agile. In addition, the post discusses the benefits of having a project management, for example, structured project management plans remove the fear of making a bad decision when a problem arises. Agile in particular helps improve collaboration and productivity between parties, in turn, producing a better/more refined final product.

  You might ask yourself, “These benefits sound great, but you haven’t told us how to implement Agile”, luckily this blog post dives into various tools that make project management easier. The first tool, Workast, provides features that let you create tasks for the team, set due dates, assign tasks to certain people, and even host meetings through Slack. Similar to lists in GitLab, Workast allows team members to group tasks into lists and move them according to its completion status. This tool is a great way to visualize project progression and productivity. The second tool mentioned is Trello, similarly, Trello allows teams to create to-do tasks and post them on a timeline. Lastly, we have a program called ClickUp which allows users to select a scrum workflow style. Managing sprints, tracking sprint progress, and creating daily scrum boards are just some of the features ClickUp offers.

  One thing that is the most important is having a place to manage your sprints. Having easy access to information like total estimation of the sprint and spillover tasks are crucial to analyzing project progression. After researching the three tools that the blog mentions, I believe ClickUp gears more towards an agile/scrum workflow.

  After reading the blog post, I’m curious to learn about other types of project management techniques and guides. It is no doubt that Agile is an effective approach to optimize project production, however, the Agile methodology does come with its disadvantages: poor long-term planning, dependency on the customer, greater demand on development team. Because the Agile methodology is flexible with its timelines, it’s difficult to predict when a project will be finished. Agile also utilizes feedback from the customer to ensure a product is beneficial to a customer. Team members are expected to meet daily at the same time, putting pressure on developers to stick to one schedule despite a having a duties that are constantly changing.

  Blog Post:

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

AI Assistance in Coding

AI has a polarizing reputation in many practices such as art, music, and coding, and seeing as you can make copies of works based on recorded patterns in less than half the time, it is understandable why people can dislike it. I like AI, it can generate funny images, make trivial tasks instant, and provide more input for someone trying to improve in a field. In coding, AI is a worrying topic that has the potential to replace many humans in the industry. However, AI is only as good as its user, a user that isn’t knowledgeable in the the product they are trying to generate cannot be as good as someone good at the field. 

In “Three Types of AI-assisted Programmers” by Isaac Lyman, the post covers the three types of people who can use AI in programming. Those three are someone with no coding knowledge, a junior engineer, and a senior engineer. The author covers the pros and cons of each person using AI to code and expresses the opinion that AI is a great addition to a team’s work, if they are attentive enough to the code generated. The pros and cons of the junior and senior engineer is what I want to highlight since AI could very well be integrated in future developer teams. The author mentions that junior developers should stray away from using AI in their work, as it may become a crutch. Rather than using AI to fulfill work tasks, junior developers should use AI to provide insight and examples to improve their skill set. A senior engineer, already having the fundamental code skills and knowledge, should just leverage the speed that AI can provide into streamlining basic code. By saving time from the menial code, senior engineers can put more time into delivering better features.

I thought this blog post contained valuable insight into the use of AI in coding and future development teams. The exploration of pros and cons for each category offers a valuable roadmap for future developer teams, emphasizing the need for a balanced and strategic integration of AI into the coding workflow. As AI continues to improve, it becomes clear that the use of AI, particularly for junior developers as a learning aid and senior engineers for time optimization, holds the key to coordinating between human expertise and artificial intelligence in the evolving landscape of coding.


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

Writing Clean Code in Python

At Worcester State University, I have been learning about programming through the context of Java. However, there are many other programming languages aside from Java. Though they likely follow the same principles and patterns, there are also inevitable differences, or at least a different approach to these same principles or patterns in practice.

The article Best Practices to Write Clean Python Code written by vanigupta20024 goes over Python specific clean code practices. The author presents four main tips:

  1. Clean indentation
  2. Using virtual environments
  3. Modular code
  4. “Pythonic” code

Clean indentation was taught in class under the context of “horizontal openness” or “horizontal spacing”. This principle is necessary for all languages, but it is especially necessary for Python. Python does not use braces to specify code blocks. Instead, it relies solely on space and tab indentations. Because of this, not only is clean indentation required to readable code, it is required for executable code!

Using virtual environments is something specific to Python. It allows the programmer to create a separate and custom environment for their project where any installed libraries and packages are separated from those installed outside the environment. That way, dependencies can be easily shared and managed separately for each project. Instead of having someone install libraries one-by-one, it is much cleaner to have the person run a requirements.txt file to automatically install all the necessary libraries and packages to run the code in one execution.

Modular code is a tool in Python that helps programmers follow the DRY principle (Don’t Repeat Yourself). This makes code clean by allowing programmers to create something like a code library that can be imported and implemented into the Python program without having to have all the code in the repository. Even better, modules can be uploaded into the Python database to be accessed by anyone, meaning that instead of having to create the function themselves, programmers can simply import the function they need to use in their code, making the code less dense and neater.

“Pythonic” code refers to special Python shortcuts that can make code easier to read by simplifying a task that would normally take multiple lines of code. For example, when swapping values, a programmer might initially think to write code this way:

value_a = 5
value_b = 6
temp = 5

value_a = value_b
value_b = temp

However, that is a lot of lines simply for swapping two values with the addition of a third variable. Instead, there is Python shortcut for this that simplifies the process.

value_a = 5
value_b = 6

value_a, value_b = value_b, value_a

Clean code is definitely an aspect of programming that I want to become more adept with. Python is not a language taught at WSU, but it was the sole language I used in my internship and research projects which is why I decided to do research on tips and tricks for clean code through the context of Python programming.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Javascript Code “Smells”

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. 


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

Week 14 – Blog for both CS-343 AND CS-348

So for this blog, I wanted to find a topic that is applicable to both classes, so I wanted to look more into GitHub and the ways it functions compared to GitLab.

I duplicated by Secret Santa Generator repository from GitLab: and duplicated it in GitHub here:

To do this, I had to open up the local repo on my PC, create a new blank repository on GitHub, and run the following commands:

Once this was done, my repository was transferred over to GitHub successfully, without harming my GitLab repository in any way shape or form. Everything, including the history of the repository, was included with this transfer, which I think is really cool.

One difference I immediately noticed between GitHub and GitLab is that GitHub allows you to add a short description on the right-hand side of the repository, allowing a quick way to figure out what the program intends to do without having to look at the Obviously if you want more information, the is very important in that case.

Both sites have a really good planning structure, with GitLabs’ issue boards, and GitHub’s project tab, which is structured very similar, but I think GitHub’s might be better as it allows you to choose from a lot of different templates like Kanban, Team retrospectives, and bug tracking, which I think is really cool. You’re also able to customize it as you please, so you’re able to set up a scrum structure like we did in GitLab for many of our projects. However, after looking into it, if you want to utilize Scrum, it seems GitLab is definitely structured better with preset pillars that are made with Scrum in mind. However, it’s a toss up on which would be better to utilize in this case for project management, in my own humble opinion.

GitLab also has some advantages in the construction and development aspects of this comparison, as after looking into it, GitLab is able to automate releases and builds of code once they are ready to be done so, and GitHub doesn’t have this capability at all.

This seems extremely useful for a program that has set deadlines and not enough time to do these things during, say, a Sprint. It allows a lot more flexibility with the work being done in a repo and can allow a lot more efficiency and productivity. I will definitely look into this more later on when I start using this repo I cloned myself.

All in all, after looking things over, it seems like GitLab has a lot of additions that make it better over GitHub in all sorts of ways, and I’m surprised GitHub is used more than it. I should probably introduce my friend I’m working with on GitHub for his game engine for this if he ever develops a much bigger team, as many of the planning-oriented inclusions GitLab has would be extremely beneficial!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Goodbye, Clean Code

Before taking this class, I didn’t know of any guidelines for writing code. Clean code is a guideline with an objective to make code easier to understand, maintain, and read. By following its principles, a developer makes projects more likely to succeed in the long term. Learning this, I thought that I should try to implement this in all I code I make, and am still trying to make clean code practices common in my code. However, in a blog post: “Goodbye, Clean Code” by Dan Abramov, he says to “let clean code guide you, then let it go”. This was interesting, since wouldn’t having clean code all the time be nice to have for understanding the code you write? Dan during the time he recalls in the post thought so too.

In this post, Dan recalls a time when he was working on a project and checking his colleague’s code they had just turned in. The code had tons of repetitive code and math that would take a second to process. Bothered by this, he fixed it to look cleaner, removing the repetitiveness and making it so there could be changes in one spot rather than multiple methods. This resulted in a request that he reverts the changes he made from his boss, which he reluctantly agreed to do. Looking back at this event, the author says it took years to understand his boss was right. Calling clean code a phase of a coder’s life and explaining that chasing that guideline was forgetting about the human aspect of coding. Firstly, he changed his colleague’s code without discussion, which was a terrible decision when working in a team where they needed to collaborate. Secondly, he realized later that the changes he made would have impacted the project severely and added complications if he had kept them.

This blog post was not saying there was a problem with clean code itself, but how people treat clean code as an absolute guideline like the author did in the past. This post helped me understand chasing clean code is more of a detriment to yourself and others on your team and to not get too obsessed with it. Getting hung up on this aspect makes you lose sight of your project and team’s goals in mind. I think that people should keep writing clean code but not lose themselves to chasing a standard in a way that makes writing that code meaningless. While I haven’t experienced this, I can sort of understand it as how I was trying to implement these principles in my code after learning of them.


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

Cracking the Code for Clean and Reliable Open-Source Science: 10 Rules to Rule Them All

Hey Coders! Feeling lost in a maze of confusing code? Tired of code messes and bug hunts?

Today, let’s dive into the exciting world of open-source scientific software. If you’re like me and tired of dealing with confusing code and chasing bugs, don’t worry! The article “Ten simple rules on writing clean and reliable open-source scientific software” by Hunter-Zinck et al. (2023) is here to show us the way to clean, reliable, and easy-to-handle code that benefits everyone.

Why This Article Rocks

This article stood out because it tackles two key issues: making code user-friendly and emphasizing the importance of open-source software. Plus, it simplifies complex software development into 10 easy-to-follow rules.

The 10 Golden Rules

The article outlines 10 key principles for writing clean and reliable open-source scientific software. Here’s a quick rundown, with a dash of my own insights:

  1. Modularize: Break down your code into smaller, independent units. This makes it easier to understand, test, and maintain. Think of it like building with Legos – you can easily swap or add new pieces without affecting the whole structure.
  2. Document everything: Write clear and concise comments explaining your code. Imagine someone completely new to your project needs to understand it – would your comments guide them through the jungle?
  3. Use descriptive names: Don’t be cryptic! Choose variable and function names that accurately reflect their purpose. Think of them as road signs – they should tell you exactly where you’re going.
  4. Test relentlessly: Write unit tests to catch errors early and often. These are like little detectives, constantly scrutinizing your code for any suspicious activity.
  5. Version control is your friend: Use tools like Git to track changes and revert to previous versions if needed. It’s like having a magic rewind button for your code!
  6. Automate your tasks: Write scripts to automate repetitive tasks. This frees you up to focus on the bigger picture and avoid tedious manual work.
  7. Embrace continuous integration: Set up systems that automatically test and build your code when changes are made. This helps to identify problems early and prevent them from snowballing.
  8. Get feedback: Share your code with others and ask for their feedback. This can be like having a team of extra eyes, spotting errors and suggesting improvements you might miss.
  9. Contribute to the community: If you’re using existing open-source software, consider contributing back by fixing bugs or adding features. Remember, it’s a two-way street!
  10. Stay up-to-date: Keep your codebase and dependencies up-to-date with the latest versions to ensure compatibility and security. Think of it like keeping your operating system updated – it’s essential for smooth sailing.

Learning and Beyond

This article has been a game-changer, offering a clear roadmap for writing clean and reliable open-source scientific software. Looking forward, my plan is to further refine my skills in writing clean and reliable code and actively contribute to the open-source community.

P.S. For more detailed explanations and examples of each rule, check out the original article here.

From the blog CS@Worcester – Site Title by Iman Kondakciu and used with permission of the author. All other rights reserved by the author.

Navigating the Clean Code Conundrum: Striking a Balance for Optimal Performance

In the engaging podcast-style video, “Clean Code: Horrible Performance,” two seasoned developers share insights over 47 minutes on the delicate balance between clean coding and system performance.

The developers initially champion the virtues of clean code—emphasizing readability, maintainability, and collaborative benefits. However, the conversation takes an interesting turn as they delve into the paradox that clean code might lead to suboptimal performance.

Real-world examples illustrate scenarios where an excessive focus on code cleanliness can unintentionally hamper efficiency. The developers caution against over-optimization and stress the importance of a balanced approach.

Practical insights emerge as the duo offers strategies for identifying bottlenecks and optimizing critical code sections without sacrificing readability. They acknowledge the evolving nature of software development, where the pursuit of clean code intersects with the demand for high-performance systems.

In conclusion, “Clean Code: Horrible Performance” serves as a valuable guide for developers seeking to strike the right balance between clean coding principles and performance optimization. The developers’ experiences provide practical wisdom for navigating the complexities of modern software development without compromising code aesthetics or system efficiency.

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.