Category Archives: CS@Worcester

Deep Dive: UML Diagrams

This week I’m again back at my favorite site, GeeksForGeeks. For everything I learned about in class, there’s always something GeeksForGeeks can teach me. Unified Modelling Language (UML) is just how it sounds, a language for modelling a system. It is a multi-faceted tool and in class we learned about class and sequence diagrams. What I was happy to learn however is that these two examples of UML can be separated into two categories, Structural UML Diagrams and Behavioral UML Diagrams.

Quick note: I will be summarizing this article as someone who knows what UML class and sequence diagrams are. If you do not know what these are then I would read the article yourself to get to the same starting point.

The article starts with a brief summary of what UML is before hopping into the categories of diagrams and plethora of examples of each. First up is Structural Diagrams and they include the class diagrams most people have seen, composite structure diagrams that show more detail for the individual parts, object diagrams which model how instantiated class objects interact with one another in the system, and component diagrams show how the physical pieces of a system are laid out. They are followed by the deployment diagrams visualizing all the pieces of hardware with their corresponding piece of software components and to wrap this category up we have the package diagrams to show us dependencies and internal composition of, you guessed it, our packages.

Next up is the Behavioral Diagrams, categorically separated into state machine diagrams that models a classes change over time or results from an external stimulus, activity diagrams which are reminiscent of flow charts in their depiction of the various states of a system, and use case diagrams showing the requirements for a system to properly interact with the users (known as external agents). Next up is the good old sequence diagrams, followed by communication diagrams which show similar information to sequence diagrams but in a more ‘free form’. This leads into timing diagrams that are again, similar to sequence diagram except now they are showing the constraints on time and duration. And finally we see interaction overview diagrams which are just a high-level overview of the interaction within the system.

After these types of UML diagrams Geeks For Geeks has a refresher for the OOP principles in UML that then rolls into some of the tools used to make these diagrams as well as the steps to make them, best practices, use case for these diagrams, how they fit into the Agile development mentality, some of the common challenges in regards to making UML diagrams and finally some of their myriad of benefits.

Almost needless to say, I now have a bookmark to this article and will be giving some of the listed tools a spin once I have the time. I expect this knowledge to help me in mentally visualizing a system so I can better address any problems that arise.

Link:
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/#3-types-of-uml-diagrams

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

GitHub adds Copilot

Just this week, GitHub announced that they will be offering a free version of Microsoft’s Copilot. I came across an article that discusses this breakthrough. In this article, GitHub CEO Thomas Dohmke gives his direct input on the situation. He has always believed in offering free resources for developers and believed that Copilot should also be an available resource. He later goes on to explain that this is because He believes that people all across the world should have access to the same tools that allow them to become developers, as the $10 a month that you would have to pay for Copilot normally is relatively more expensive in other regions. While this is great news for developers around the world, it will be a fairly limited version of Copilot. In this free version, developers will be allowed 2,000 code completion suggestions per month. This includes suggestions that are not accepted by the user.

I found this article particularly interesting because we have been using GitHub and its many features in my CS 348 class this semester. We’ve mostly been using GitHub for creating repositories and creating pull requests for larger repos. It is incredibly convenient and makes version control much easier. However, this new feature adds a lot to the software. Not only can you store your work in a repo and add work to other repos, but you can also get AI assistance for what you are working on.

I believe this is an important breakthrough for developers globally. Dohmke’s idea of creating equal opportunity for developers worldwide is amazing to me. Not only is the future in technology, but we currently live in a world where technology is everything. There are great minds all over that may have never gotten the right opportunity. Perhaps this addition can help someone create a life changing software. Outside of speculation, though, this will help thousands of developers, as GitHub now has over 350 million users. While it is a limited version of the product, it is a big step taken by GitHub. It is nice to know that I am getting into a field that people are willing to offer help and services for the betterment of the industry. As someone who is still young and learning new things daily, I hope to be able to take advantage of this. I believe it will help me, along with many others, to write good code while still learning.

URL: https://techcrunch.com/2024/12/18/github-launches-a-free-version-of-its-copilot/

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

What is Git?

A Beginner’s Guide to Git and Version Control

Git is a useful tool for software developers, yet its many features can be intimidating or confusing to beginners. This GitHub blog post “What is Git? Our Beginner’s Guide to Version Control” offers a clearer, more concise explanation of Git, its purpose, and what its practical applications are. This blog post is an excellent resource for anyone early on in their journey through software development, as the knowledge will be useful for years to come. I myself still needed some more practice with git commands, and benefited from reading the post.

Summary of the GitHub Post

The post explains important concepts such as what repositories, branches, commits, and merges are, and emphasizes how Git helps developers collaborate effectively on projects while maintaining a complete history of those changes.

The author discusses and defines many crucial Git commands like git init, git clone, git add, and git commit, breaking them down into much simpler, more easily understandable terms. Lastly, the post also discusses the importance of version control systems like Git and GitHub in preventing data loss, enhancing collaboration, and improving code quality overall.

Why I Chose This Post

I chose this post because Git is a critical tool in software development and is directly related to our current course material. As someone with limited experience with Git and GitHub, I often had to practice extra with its terminology and commands. Understanding Git is vital for success in our coursework, and future careers in software development, where collaborative coding is a big deal and a common occurrence.

Reflection

One takeaway from this post and course for me was the significance of version control in teamwork. The post reinforced the idea that Git is not just a tool for managing personal projects in the way that I have experience using it, but also a way to collaborate more effectively with others on software projects.

Upon learning all this about Git and GitHub, I planned to apply what I’d learned by setting up repositories for all my future projects, creating meaningful commit messages, and leveraging GitHub to store and maintain my history of works. Through that, I’ve been able to build up my own portfolio and showcase my works to others.

Conclusion

This blog post serves as an excellent starting point for anyone looking to begin learning Git, and to understand its role and uses in version control. Its practical approach and clear explanations make it accessible to complete beginners, while laying down the foundation for much more advanced concepts later on down the line. As I continue my journey in software development, I’m confident that the skills I’ve gained from this resource will be invaluable, and I do continue to use Git and GitHub very frequently.

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

Computer Programming and My Future

Hello Debug Ducker here, and this one is going to be a lot less focus. As I near the end of my college fall semester, I come to realize that I am nearing completion of college, and will hopefully come out with a bachelors degree in Computer Science. With this in mind I did some reflecting about my choice in the field and how have my classes helped me.

For this semester, I did a CS course called Software Construction, Design and Architecture. To best describe it, its like applying the fundamentals of computer science, while understanding new techniques to build better software . I remember at the beginning we review some CS concepts such as Polymorphism, Abstraction Inheritance, and Encapsulation, and when studying it I was surprise to see I was still familiar with the subjects. Even funny that I recently applied for an internship with a company that had me do a test involving those subjects It made me feel more confident with my abilities. Also with the way the class was setup I was a lot more engage with the subjects.

I also learn some new things that involve CS such as UML class diagrams that basically meant to outline the program class structure. Here is an example that I did for class assignment

This was meant for some appointment application, I just did a diagram of it. I can see this being helpful in the field to help people understand what exactly going on with classes if they are new to a project.

I also learn about API work and I am not exactly clear on how it all works but I say I understood a little. I relearn the HTTP methods during that time, which I needed cause it has been a while since I had experience with them. Funny, that one of the HTTP method names is just GET, which just gets you information from a database. Anyway I hope to return trying API so I can get a better grasp on it.

That is a review on the class work but about my efforts. I say I did quite well despite some difficulties. Some unexpected hurdles came but I was able to jump over them to the other side and learn some new skill as a result. Though time waits for nobody and I may have missed some things but hopefully that could be mended.

Now that I am typing these I would like to use to blog for other purposes in the future but we’ll see. Have a nice a holiday and thank you for your time.

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Software Licenses

Hello everyone

For my last blog for the semester, the topic would be about Software Licenses and their importance in the computer science field. This was one of the most underrated things I learnt during the semester, so that’s why I wanna talk about it. Even though now it seems obvious, it never crossed my mind that I should always put a license on my project. This blog makes an amazing explanation on why you should always put a license on your work and also which one to choose from.

The blog begins by explaining the different types of software licenses, starting with:        Permissive Licenses – which impose minimal restrictions on what you can do like modification and distribution of it. Some of the most popular permissive licenses are the MIT and the Apache license. They are highly popular because they typically only require attribution, which is that you have to give credit to the original author.                                            Then the blog talks about:                                                                           Copyleft Licenses – anyone could modify and distribute the code, but they had to share their changes with the community under the same license. Some of the most popular Copyleft Licenses are the GNU Lesser General Public License (LGPL), which allow linking to open-source libraries with limited obligations but impose stricter requirements if the library is modified. There is also the GNU General Public License (GPL). They are a bit more restrictive, requiring that any derivative works be distributed under the same license and with access to the source code.                                                               

At the end of the blog, it addresses unlicensed code. Emphasizing that code without a clear license is not automatically free to use and may lead to copyright infringement. If the code does not have a license then it is considered to be under the default  copyright laws. This means that only the original author has the right to use, distribute or modify it. If someone was to happen to use it even if it is publicly available, it raises legal issues.          This blog to me was incredibly helpful and useful as it not only explained the various types of software licenses but also gave examples of them. It showed and highlighted the types of works and where would you wanna use these licenses and what works the best for you. One thing that I learnt while reading this blog was understanding what is an SBOM which stands for Software Bill of Materials. It is a detailed list of all the components in the code and their respective licenses. It is important to understand what licenses works the best for you so you can get the most out of it. The computer science field is an amazing work space that everyone can work together to build each other up and licenses help us do just that!

https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

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

The Singleton & Desing’s Patterns

12/19/2024

At the start of the semester, we were introduced to Design patterns. These techniques include anything from completely restarting a project to erasing redundancy such as repetition of code. Our biggest focus was to use overrides ONLY where needed and it was our job to figure that out because there were certain methods that did need to be overridden.

We worked on a Duck Simulator that has methods for each duck itself, but some ducks needed functions to be overridden were as some didn’t need them for example a decoy duck does not fly. Whereas a mallard duck does therefore there is no need to override a function for that decoy duck. This design pattern is very easy to overuse specially for people not introduced to these types of problems.

The interesting part of this homework was also using the previously covered topic of UML diagrams. This homework though was more about reading and understanding but the main point was to transfer it to Java code. This was a nice intertwining moment because it makes it easier in the future to understand not just the UML but also the design patterns taught.

We created two different interfaces for the Duck Simulator which one was a Quack() and the other was Fly(). These made it so we as the developer do not have to keep overriding. Hence, we end up with a bit more files, but it saves us the trouble in the future if we needed to edit let’s say the decoy duck to fly. Now we are able to go into one file and edit without having affected any other files. Which in larger systems can become a big issue because now the developer has to go into every single file that uses said method which waste time and can be missed if multiple people are working on it at the same time.

We also learned about the singleton method which just retrieves a single instance of an object and if it is not there then it creates it does not use multiple of the same object. There is one down side I read about in the source and it was about unit testing. The source talks about many unit testing frameworks that rely on inheritance when producing a mock object which is a problem because the singleton class is private, and static methods cannot be overridden. Overall, it is still applicable, and we used it in the intermediate part of the design patterns homework to learn how it worked better to always only have one instance of a method.

Source: Design Patterns in Java

From the blog CS@Worcester – Cinnamon Codes by CinnamonCodes and used with permission of the author. All other rights reserved by the author.

Management Pitfalls, How to Navigate Them

I recently read the article “Common SDLC Management Pitfalls (And How To Avoid Them)” published on Forbes.com. This insightful piece delves into prevalent challenges encountered during the Software Development Life Cycle (SDLC) and offers practical strategies to mitigate them.

I selected this article because, as someone striving to enhance my understanding of software process management, recognizing common pitfalls is crucial for effective project execution. The article’s focus on real-world issues and solutions provides valuable guidance for both current and future projects.

The article identifies several key pitfalls in SDLC management:

  • Unclear Requirements: It emphasizes that ambiguous or incomplete requirements can lead to project delays and cost overruns. The recommendation is to engage stakeholders early and ensure thorough documentation to establish a clear project scope.
  • Inadequate Communication: The piece highlights that poor communication among team members can result in misunderstandings and errors. Implementing regular meetings and utilizing collaborative tools are suggested to enhance information flow.
  • Lack of Proper Testing: The article points out that insufficient testing can cause defects to reach production, affecting product quality. It advocates for integrating comprehensive testing phases within the development process to identify and address issues early.

Reflecting on these insights, I recognize the importance of establishing clear requirements from the outset. In past projects, I’ve experienced setbacks due to vague objectives, leading to scope creep and resource strain. Moving forward, I plan to prioritize stakeholder engagement to define precise and attainable goals.

The emphasis on communication resonates with my experiences in team settings. I’ve observed that regular check-ins and transparent discussions significantly reduce misunderstandings and align team efforts. I intend to advocate for consistent communication channels in future collaborations to maintain project coherence.

The article’s focus on testing underscores a critical aspect of software development. Previously, I underestimated the value of early and thorough testing, which led to last-minute defect discoveries. I now understand that incorporating iterative testing phases can enhance product quality and reduce time-to-market.

In conclusion, this article has deepened my understanding of common SDLC pitfalls and reinforced the necessity of proactive management strategies. By applying these lessons—clarifying requirements, fostering open communication, and committing to rigorous testing—I aim to contribute to more efficient and successful software development projects in the future.

For those interested in exploring this topic further, I recommend reading the full article: Common SDLC Management Pitfalls (And How To Avoid Them).

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Smarter Ways to Gather Software Requirements

I recently read the article “Gathering Requirements for a Development Project in 2025” on Developer-Tech.com. The article talks about how collecting and understanding software requirements is changing, focusing on new technologies and ways of working to make the process better.

I picked this article because I want to improve how I manage software projects. Gathering requirements is such an important part of any project, and understanding future trends can help me stay ahead. The article gave clear examples of how requirement gathering is improving and what to expect in the coming years.

The article covered three key points:

  • Using Artificial Intelligence (AI): It explains how AI tools can make collecting and understanding requirements faster and more accurate. AI can analyze a lot of data quickly and help figure out what stakeholders (the people involved in the project) need.
  • Better Team Collaboration: The article emphasizes how important teamwork is. New communication tools are helping teams work together more easily, making sure everyone understands the project’s goals.
  • Agile Development Methods: It talks about Agile, a way of working that breaks projects into smaller steps. Agile lets teams adjust requirements as they go, so the final product meets user needs better.

This article made me think differently about how I collect and organize project requirements. The idea of using AI tools stood out to me because it would make the process quicker and catch mistakes I might miss. In the past, I’ve done everything manually, and it can take a lot of time.

The part about teamwork also hit home for me. I’ve worked on projects where poor communication caused delays and confusion. Using tools that help everyone stay connected and clear about the goals can make a big difference.

I also liked what the article said about Agile. I’ve worked on projects where requirements changed halfway through, and it was stressful. Agile makes it easier to handle those changes, which is something I plan to learn more about and use in future projects.

Overall, this article was a great introduction to how requirement gathering is improving. By using AI, working more closely with teams, and adopting Agile methods, I can do a better job on projects. If you’re interested, I recommend reading the full article: Gathering Requirements for a Development Project in 2025.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

A Serious Look at Playful Retros – Sjoerd Nijland

I’m writing this blogpost about Scrum, specifically about the Sprint Retrospective(although the author refers to it as a Scrum Retrospective) that takes place after a Sprint Review. This blogpost(possibly article?) caught my eye while I was browsing through some blogs, as it directly references something we’ve learned about in class, but from a different point of view. Does ‘fun’ and ‘silliness’ have a place in a professional setting like a Sprint Retrospective? My initial thought after reading this introductory question is that yes, a little playfulness is fine as a means to relieve tension and stress, so long as it doesn’t hinder productivity, and so long as everyone is comfortable with it. But while it’s fine in moderation, it’s by no means a necessity. If someone wants to maintain professionalism, then that’s completely fine too. But as someone who’s never actually worked on a development team, I was interested to hear an experienced person’s take on the subject.

In the referenced article, Sjoerd Nijland first addresses the common critiques of playfulness, where people call it unserious and unprofessional, and assume that it gets in the way of productivity. He counters by mentioning the benefits of playfulness based on neuroscience. Some of these include: Improving brain function, energy, and happiness, relieving stress, deepens connections and trust, and encourages creativity needed for problem-solving, amongst many other benefits. It’s something that everyone, even introverts, can benefit from. It’s a mindset. It provides psychological safety. It puts people in a comfort zone, leaving them open to new ideas and discussion. It keeps people trusting of one another, instead of checking and inspecting each other. And so he counters the common by saying that not only can it be beneficial in a professional environment, but that “Discouraging playfulness at work is profoundly UNprofessional”. When applied intentionally, it can be a great mechanism for helping your team deal with what would otherwise be a stressful environment.

I like the way he views playfulness, because he thinks of it in a different way than most people would. Playfulness isn’t slacking, it’s a tool, one that benefits team dynamic and productivity in the long run. Too much of it can be detrimental, and people shouldn’t be neglecting work for play, but ideally it should exist in some capacity. He references existing scrum environments and scrum professionals, and addresses how it’s helped in certain cases, and how some of the scrum critics aren’t viewing it the way they should. Playfulness and seriousness complement each other, and when used correctly, is a great tool for improving your team’s relations, stress levels, and ultimately, productivity. I’ve changed my mind playfulness being unnecessary. A little levity is important for the mind and body, and I’ll definitely keep that in mind when I’m in a professional environment.

Link: https://medium.com/serious-scrum/a-serious-look-at-playful-formats-in-retrospectives-73aed21aa083

From the blog CS@Worcester – Justin Lam’s Portfolio by CS@Worcester – Justin Lam’s Portfolio and used with permission of the author. All other rights reserved by the author.

Working as a Front end developer

Now that I have heard about people’s experiences working on the back end, I was curious about people’s experiences working on the front end. Reading personal experiences taught me a lot about working on the back end. You can learn a lot and avoid mistakes by seeing others take similar paths. Also, it can prepare you for problems that you may face in the future. Mistakes are inevitable but being able to adapt or being able to recognize it and fix it goes a long way. Working on projects especially those that have to do with coding errors is always a step away. You can try to get a step ahead on these problems by seeing other people work and implementing it on your stuff. That is why I found an article about working as a front-end developer. These articles are very engaging and always give me a new perspective.

This article is written by Selim Enes who has done freelance work in the past but is currently working as a developer. When he first started he was working on small things like CSS edits until he proved himself. One of his major projects was a blog project where he had to create the display of the UI. He was involved in all operations after 2 months. When he proved to the team that his code wouldn’t crash the project he gained access to the company’s main project. The company’s main project entailed a webinar application that used technologies like WebSocket. One thing that made him know he was going in the right direction was being able to develop features like push-to-talk by himself. There are some negatives to his work with his boss being very hasty on projects. He believes all tasks are urgent and make some work very stressful. Plus with the recent economic regression, he doesn’t believe he will be able to get a raise anytime soon. He has learned to have a full-stack blog project for himself and has an e-commerce project his about to start working on. He is working while also building his portfolio outside of work.

Reading this article was very insightful. It made sense that when you first start working for a company they won’t give you the keys to everything just yet. They ease you up into it until you have gained their trust. Working on his portfolio outside of work motivated me to do the same too. You can sometimes become complacent at your job because you have a living but you shouldn’t. You should always try to improve and hope to find better opportunities elsewhere

View at Medium.com
https://medium.com/@sellimenes/1-year-experience-as-a-junior-front-end-developer-39766fad5c34

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