Hey. I am a student at WSU taking CS 348. This is a test post to introduce the blog and make sure it appears on the CS@Worcester blog.
From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.
Hello again, it’s like we’ve met before. Once more, my name is Oanh Nguyen. At this point and time, a student at the university of Worcester State. I major in computer science and minor in business administration. Nothing much changed. However, I would to point out that I’m also taking ‘Software Process Management’ on top of my other class. Many further blog will be related to this class. Which will be tagged accordingly.
I won’t take up your time any more than this. It’s nice to meet you all again, those reading this. Thank you.
From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.
This is my blog for CS-348 Ben Gelineau
From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.
This is my blog, A Bostonians Blog. I couldn’t think of a better name than this but this blog is my personal space to share insights, experiences, and discoveries as I progress through my coursework, particularly focusing on Computer science at Worcester State University.
From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.
I’m Joanna P. and I’ll be using this blog to talk about my journey though learning computer science.
From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.
Hello World, my name is Santiago Donadio and this is my first blog post.
I am currently taking CS348 – Software Process Management with Professor Wurst.
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.
Introduction
As we conclude Sprint 2, it’s essential to take stock of our journey, examining both our successes and the challenges we’ve encountered along the way. This sprint, our primary focus was on scaling up productivity and initiating the UI development process. Despite its longer duration compared to the previous sprint, Sprint 2 felt back-heavy due to delays in commencing frontend work until we obtained access to the new template.
Challenges Faced and Lessons Learned
Both sprints presented us with unique challenges, contributing to our team’s growth and development. One significant challenge in Sprint 2 was the unexpected complexity encountered while coding a UI component. Initially deemed a simple task, unforeseen changes in the source code necessitated extensive adjustments, resulting in delays and frustration. However, this challenge provided valuable lessons in flexibility and adaptability. By grappling with the intricacies of the component and adapting to evolving requirements, we honed our problem-solving skills and gained a deeper understanding of UI development.
Another challenge stemmed from the weight of certain child issues, which had a more substantial impact on our workflow than initially anticipated. This highlighted the importance of thorough planning and assessment when breaking down tasks and allocating resources. Moving forward, we recognize the need for a more nuanced approach to issue prioritization to ensure each task receives the appropriate attention and resources.
Team Dynamics and Communication
Effective communication emerged as a cornerstone of our approach throughout both sprints. We found that tackling problems collectively as a group significantly eased the resolution process. Whether through online discussions or face-to-face meetings, open dialogue and transparent communication channels were maintained, ensuring alignment and informed decision-making. We intend to prioritize effective communication, proactive problem-solving, and meticulous planning in future endeavors.
Strategies for Improvement
Team Improvement
Personal Improvement
Moving Forward
As we look ahead, we are committed to leveraging the lessons learned from Sprint 2 to inform our approach in subsequent iterations. Documenting challenges, solutions, and key takeaways in a “lessons learned” repository will serve as a valuable resource for future sprints, enabling us to anticipate and mitigate potential obstacles more effectively. With a shared commitment to continuous improvement and a supportive team environment, we are confident in our ability to overcome challenges and achieve our goals collectively.
From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.
As we start the Spring 24 Semester we turn a new page and focus on new courses and topics which will be closely followed during the upcoming months.
Before I go deeper into what we are focusing on this semester, let me remind everyone of you who continues to read my blog entries of who I am.
My Name is Anairdo Duri or Ano if it’s easier for any of you. I am a Junior Computer Science student at Worcester State University hoping to graduate next year.
Now that we got that out of the way let’s continue.
The main focus of my blog entries this semester will be focusing on Software Quality Assurance & Testing. I will be looking into various topics related to Software Testing which will include Test cases and evaluation, levels of testing, unit testing, system testing, test automation, code reviews, and so on.
Software Quality Assurance (SQA) and testing are crucial components of the software development life cycle, aimed at ensuring the delivery of high-quality software products. SQA is a systematic and comprehensive process that ensures the development and maintenance of software meet established quality standards and customer requirements.
Testing is the process of executing a software application or system with the intent of finding defects and ensuring that it behaves as expected. Its main objectives are to identify defects and ensure they are fixed before software release, to verify that the software meets specified requirements, and to ensure the software functions correctly in different scenarios.
My goal this semester is to obtain a greater understanding of these two important concepts in the large spectrum of computer science concepts as I already know that it will be useful in my desired career as a computer scientist.
Let’s hope that this semester is as successful as the past ones have been and as always,
Ano out.
https://www.simplilearn.com/software-quality-assurance-article
https://www.ibm.com/topics/software-testing
From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.
When I was first introduced to the concept of an API, a shortened abbreviation of Application Programming Interface, I never thought of it being used far outside the scope of Computer Science. However, as I revisited some software that I used in the past and observed the current software I worked with recently, I was more than surprised by the fact that an API is universally used across the Internet. For this blog, I explored a blog called “10 Most Popular Frameworks For Building RESTful APIs” written by Developer Advocate at Moesif, Preet Kaur. In this blog, the author explained that when deciding on the API framework to use, you needed to choose one that uses a programming language that you are familiar with, but you can also use in spite of its shortcomings. Further down the blog, she gave some examples of popular API frameworks that are used by many developers; one of those frameworks that was mentioned was Express JS, a framework I am familiar with.
One of the biggest contributing factors that brought me to use this article for this blog is not only the different frameworks that Kaur had given examples of, but also where you can find and learn about them. Reading this blog got me hooked on the many different types of API frameworks that I could look at to familiarize myself with each that may give me a better understanding of the specifics of REST API for my drive toward a career in Software Engineering. Even if the frameworks in question were written in programming languages that I am not as efficient in programming in, I still believe that this blog has helped me in understanding the overall meaning of building an API for use in creating applications and beyond.
My biggest takeaway from this blog is that the API framework you use to build an application, software or other kind of design is not only dependent on your skill at programming or engineering, but also what your goal is with using the framework you choose for your creation. While this blog was more general than the previous ones I read through, I still stand with a vision that the API framework that I use will only be as helpful as the skills I use to develop and engineer my path to a greater goal in creating the perfect software.
From the blog CS@Worcester – Elias' Blog by Elias Boone and used with permission of the author. All other rights reserved by the author.
Introduction
The blog, “A Short Guide to Open Source Licenses,”by David Skaife, helps us understand the often confusing world of open source licenses. Let’s break down the key points to make sense of why these licenses matter in the world of computer software.
Understanding Open Source Licenses
Open-source licenses are like rules for sharing computer code. They tell us how we can use, share, and change the source code. These rules help protect the original creators and make it easier for others to use the code without asking for permission each time.
Clearing up Myths: Public Repositories and Licensing
Skaife talks about a common misunderstanding of just putting code on a public platform, like GitHub, doesn’t automatically make it open source. Without a clear set of rules (license) with the code, it’s still protected by copyright, and others can’t freely use or change it. So, it’s crucial to attach a license if you want others to use your code.
Making Sense of Licenses
Skaife acknowledges that there are many licenses, but he suggests focusing on a few popular ones. He also mentions the Open Source Initiative (OSI), which approves licenses, making it easier for us to choose from reliable options.
License Types: Strict vs. Flexible
There are two main types of licenses – strict (copyleft) and flexible. Strict licenses say that if you change the code, your new version must also follow the same rules. Flexible licenses are more relaxed, letting people use, change, and share the code more freely.
Exploring Five Common Licenses
There are five common licenses we might choose from:
conclusion
Skaife’s guide helps us navigate open source licenses, making it easier to understand the rules for sharing and using computer code. With this knowledge, anyone working with open source software can feel more confident contributing, using, or creating, fostering a collaborative and innovative community. For those wanting more information, Skaife suggests checking out resources like the Open Source Initiative’s licenses pages and GitHub’s “choosealicence.com.”
reference
From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.