This blog is just a setup for CS@Worcester, CS-443
From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.
CS484 Week-1
The Libre Food Pantry project and Thea’s Food Pantry at Worcester State University both represent impactful initiatives addressing food insecurity, each in their unique way.
1. The Libre Food Pantry Initiative: This initiative brilliantly merges technology and social welfare. By focusing on developing free and open-source software specifically for local food pantries, the Libre Food Pantry is a stellar example of how technology can be leveraged for social good. This initiative stands out for its innovative approach, where software development directly contributes to enhancing the efficiency and effectiveness of food pantries. Additionally, the project’s commitment to inclusivity, diversity, and a healthy community ethos, as reflected in its values and code of conduct, marks it as a progressive endeavor in both the tech and social service sectors.
2. Thea’s Food Pantry at Worcester State University: Named in honor of alumna and Holocaust survivor Thea Aschkenase, this campus-based service is a testament to community solidarity and support. It addresses the critical issue of student food insecurity, offering food and essentials to students, staff, and faculty in need. Operating from the Student Center, Thea’s Food Pantry provides confidential assistance, ensuring that members of the university community can focus on their academic and professional pursuits without the burden of food scarcity. The pantry’s operation, supported by student volunteers from various clubs and departments, including the SNAP practicum and the Urban Studies Club, is a wonderful example of campus community engagement and support.
Both initiatives, through their respective approaches, demonstrate the power of community-driven efforts in addressing fundamental human needs. The Libre Food Pantry’s focus on technology as a tool for social good, and Thea’s Food Pantry’s direct support to the university community, each highlight the importance of tailored solutions to societal challenges.
From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.
Software Architecture Patterns (Token Blog)
While I do not have a great understanding of Software Architecture as much as I do with programming the Backend of that same software, I still take into appreciation the looks of its design. When I took sight of “The top 5 software architecture patterns: How to make the right choice” written by Freelance writer Peter Wayner, one of the things that was eye-catching was how the Software Architecture Patterns were described throughout this blog. While the Microservices Architecture was one of the only architectures that I had familiarized myself with while reading through the different architectures, I had been more interested in the endless vacuum of strengths that the Space-based architecture had when seeing the benefits that it poses. The article had given a very understanding of all the Software Architectures by showing their strengths and their weaknesses, making it easier to see where their limits are foreseen.
I chose this article since I searched far and wide for a topic that I least understood, but still would be inspired to follow through reading about it for fulfillment. The article does a really great job at grabbing the reader, as the most complex part about trying to understand a Software Architecture is when you are trying not to break your own code with a Software Architecture that poses a great risk in causing your program to crash unexpectedly. For the simplicity of the reader, Wayner had given either a telling example or a visualization that would help the reader have a simple explanation of what the structure is designed to do for your program as its structure.
The biggest takeaway I had after reading this article was that I was still able to learn that each architecture shapes your program in a way to help better understand what to do with your program next. However, Software Architecture is still only the beginning of what you need to do to fully design your software. A software may still need changes that an architecture alone cannot fix, but what an architecture should do is help you see the full picture of your own work that you have done. A Software Architecture is only a frame in the end, but the program you create would be best suited for an environment that is needed to put it on full display.
https://techbeacon.com/app-dev-testing/top-5-software-architecture-patterns-how-make-right-choice
From the blog CS@Worcester – Elias' Blog by Elias Boone and used with permission of the author. All other rights reserved by the author.
REST API (Token blog)
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.
Architecting for Agility
Hey everyone, it’s Andi and I presented an article on decoupled software architectures. Essentially, decoupled architecture aims to break down monolithic applications into modular, isolated components that can operate and evolve independently. I wanted to talk about this concept because decoupling enables more agile, resilient systems that can better adapt to changing customer needs and scale more consistently clean . Article written by Arunkumar Ganapathy, a solutions architect focusing on the design and development of software systems with over 17 years of hands-on experience and is highly skilled in Java, Node JS, and AWS technical stack. So to start off, what is decoupled architecture? It’s a system design approach that tries to cancel as many dependencies between application components by enabling them to operate autonomously. This provides advantages like independent scalability, avoiding regression issues typical of tight architectures. As organizations move toward rapid digital transformation, a separate architecture of focused, isolated services becomes critical for adaptability and resilience. With users all over with interfaces and microservice designs, building modular applications where components can be maintained and updated independently is essential to handle change. By allowing developers to construct and use discrete, self-contained services, architecture transforms how modern agile software is envisioned and created.
Decoupled software architecture presents an important pattern shift that computer science students should understand as they prepare to design and build the systems of the future. More modular system designs will be critical as applications scale up to handle massive data and traffic volumes driven by AI, IoT, and cloud adoption. Understanding loose coupling principles provides valuable insight into creating codebases that avoid failures and unintended side effects when changes are introduced. Exposure to concepts like event streaming and publish-subscribe architectures gives examples of techniques students may employ in decoupled designs. As tightly integrated monoliths become very hard to define, transitioning to more flexible and advanced microservices-based ways will be a reality for many computer science graduates. Getting early experience reasoning through decoupled architectures as students will pay profits in building adaptable and maintainable production systems down the road. The skills used to remove complex processes into cooperative but small components have broad applicability across software domains and will serve CS students well as the landscape continues to move in this direction.
As a student exploring different architectural patterns for connecting user-facing experiences to back-end logic, this article on decoupled architectures opened my eyes to the immense benefits of modular system design. I gained new knowledge into concepts like architectures that enable present / faster responsiveness by finding changes across isolated services. The examples of decoupled architectures powering complex platforms like Uber showed real use cases I could relate to from a front-end perspective.
Seeing how divided application components can evolve discreetly, avoiding regression issues affecting legacy systems, showed me a different perspective on the importance of loose coupling and principles in sustainable software development. My biggest takeaway was understanding how standardized APIs serve as a stronghold facilitating coordination between discrete front-end and back-end elements – while still allowing for independent scaling, troubleshooting and innovation.
As I progress to construct my own full-stack applications, I will apply learnings around planning sturdy interfaces between autonomous services and handling new versions when dependencies change. The reflection overall shows the specific learnings around technical concepts and design principles as well as expected impacts on the student’s future architectural thinking and implementation priorities. It includes both big takeaways as well as practical development relevant to front-end and back-end coherence in decoupled systems.
December 20, 2023
andicuni
cs-343, CS@Worcester
cs-343, CS@Worcester
https://www.computer.org/publications/tech-news/community-voices/decoupled-architecture
From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.
Building Trust in Open Source Software
Hey Everybody! I chose the article “Boosting faith in the authenticity of open source software” to talk about how it affects present day software and how we can build off it. The article starts off presenting, Speranza is a new system that allows users to verify the authenticity of open source software packages while preserving the identity of developers. It builds on an existing signing system called Sigstore but uses a novel “identity co-commitments” cryptographic technique to prove a trusted developer signed the software without revealing their identity. This approach addresses vulnerabilities in the software supply chain by ensuring the origin of downloaded packages while improving usability and privacy compared to traditional signing keys. The article shows how Speranza enables trust in open source software through automatic verification of authenticity from maintainers.
Speranza presents an interesting case study for computer science students because it sits at the field of cryptography, real-world security issues, core computer science challenges, and the open source ecosystem so ubiquitous in the field. Specifically, the novel “identity co-commitments” technique aims to address the practical threat of vulnerabilities being introduced into software supply chains, whether through some type of malice. In order to take care of the identity, it aligns with both usability and privacy goals in computer science. The cryptographic research here goes as far as verifying authenticity, speaking also to the broader challenge of establishing trust between producers and consumers of open source software. Comments highlight the potential for Speranza’s automated integrity checks to transform that trust relationship. For CS students deeply embedded in open source as users and future contributors, understanding the latest developments working to up security and privacy could deeply inform both perspectives. More broadly, this research borders computer science trade-offs around security, privacy, and useability that come across domains.
As a student learning about building both front-end and back-end software systems, I found this article on the Speranza software authentication project a good addition to know about. I relied heavily on open source code in assignments, often importing libraries without much thought into their integrity. This resource impressed upon me that you can never fully trust third party code, even from regular or normal open source developers. Without an assurance like Speranza’s cryptographic identity commitments, any component in my software supply chain could be compromised.
I now understand the privacy-preservation behind Speranza’s design. By avoiding revealing developer identities in the authentication process, the system overcomes adoption barriers and aligns motives between creators and users of open source work. The commitment to privacy likely occurs from an open source mindset resisting that overcome.
Reading about Speranza’s novel technical approach using zero-knowledge proofs was clarifying as well from a software architecture perspective. Thinking through how I may include third party open source functionality in future applications, I need to consider adding checks on the integrity and origin of imported code. Though Speranza itself deals with authentication before download, it inspired me to reflect on similar proofs-of-authenticity within a completed software project. If I can confirm signed identities of any imported dependencies, it would make me more confident my project doesn’t have vulnerabilities introduced through my software supply chain. I still have much more to learn, but Speranza made me realize the trustworthy software development I had never considered.
December 20, 2023
andicuni
https://techxplore.com/news/2023-12-boosting-faith-authenticity-source-software.html
From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.
A Quick Guide to Open Source Licenses
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:
- MIT License: Simple and flexible, allowing changes with few conditions.
- Apache License 2.0: Similar to MIT but a bit more complicated, addressing specific issues like trademark rights.
- GNU General Public License (GPL) v2.0 and v3.0: Strict licenses, ensuring all changes follow the same rules, with v3.0 adding more details.
- GNU Lesser General Public License (LGPL) v2.1 and v3.0: Less strict than GPL, allowing some exceptions for linking.
- Berkeley Software Distribution (BSD) 2-clause and 3-clause variants: Flexible licenses, similar to MIT, with the 3-clause version having extra rules about using contributors’ names.
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.
CS-343 Wrap Up
APIs, or Application Programming Intеrfacеs, sеrvе as softwarе intеrmеdiariеs facilitating communication bеtwееn divеrsе applications or dеvicеs. Thеy arе vital for intеraction with wеb browsеrs, mobilе dеvicеs, and third-party softwarе. APIs opеratе through protocols, primarily ovеr thе intеrnеt using HTTP, and arе likеnеd to a mеdiator facilitating communication bеtwееn a usеr and a backеnd systеm.
REST APIs, a usеr-friеndly stylе of API architеcturе, usе HTTP mеthods likе GET, PUT, POST, and DELETE. REST API Managеmеnt involvеs four kеy componеnts: API Dеsign, API Gatеway, API Storе/Dеvеlopеr Portal, and API Analytics/Dashboard.
Thе principlеs of writing clеan codе еmphasizе using commеnts judiciously, brеaking down mеthods into focusеd units, incorporating unit tеsting, and еliminating codе duplication. Clеan codе еnhancеs rеadability, еfficiеncy, scalability, and rеducеs thе likеlihood of introducing bugs.
Documеntation is crucial for codе maintеnancе and collaboration, еncompassing low-lеvеl or inlinе documеntation, high-lеvеl documеntation, and walkthrough documеntation. Convеrsеly, anti-pattеrns likе Spaghеtti Codе, Goldеn Hammеr, and Boat Anchor hindеr codе maintainability and dеvеlopmеnt.
Dеv Containеrs, or dеvеlopmеnt containеrs, offеr a complеtе and isolatеd dеvеlopmеnt еnvironmеnt accеssеd through SSH in prеfеrrеd IDEs. Thеy addrеss sеtup configuration issuеs, standardizе projеct build instructions, еnsurе isolation of dеvеlopmеnt еnvironmеnts, еnablе consistеncy across tеams, and simplify onboarding and training procеssеs. Thеir adoption is bеnеficial for rapid dеvеlopmеnt, prototyping, and addrеssing challеngеs associatеd with divеrsе local еnvironmеnts.
This is just a quick summary of what I have been through in CS-343. It was a very impactful semester that taught me many new things. I believe what I enjoyed the most was working collaboratively in teams. I find myself always working better in a structured group and retaining information much better. Towards the end of the semester, when we started to work with APIs, specifically the backend/frontend, I noticed a big usage of JavaScript. The homeworks became a little more challenging because of this, and I am going to use my break to get a crash course in JS. I also am working on a personal project where I will soon be implementing a frontend GUI, so the timing works out great.
I also cannot wait for the capstone class next semester as the whole idea behind the class just sounds perfect. I am a very hands-on guy, so getting to finally work on an actual project for a semester with a team and implementing what we learned will be a learning experience. Also, a great way to practice for internships and job opportunities for the future.
Sources:
https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/
https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/
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.
Software License Managment
Earlier in the semester, we discussed licenses and copyright in regards to our code and documentation. I’ve wanted to write a post on licenses, but finding a post that did more than describe the definitions and uses of licenses was difficult. Luckily, I have found a blog that describes software license management, the best practices, and some drawbacks when managing licenses. From those sections, I want to highlight the parts that felt the most important. The blog is called, “Seven Best Practices for Managing Software Licenses” by Ibrahim Ogunbiyi, a data scientist and IT support specialist.
The post starts off with defining software license management as the process of controlling, tracking, auditing, and managing the use of software in an organization. They highlight the importance of using SLM in many ways, but the one that stood out to me was to ensure the software is secure and has no malicious code. If there is no liability in the rights listed by the license or the lack of one, I can imagine how it would be important to sift through each one to ensure the code is safe to use. Another one that felt important was keeping track of software due dates. Having your team or company rely on access to software only to have it pulled from you could be expensive and time wasting. If you fail to stop after your access is revoked, you could be held liable and sued.
The potential setbacks of SLM were the cost, complexity, and compliance risk. In an organization or large company dealing with a myriad of different license types and potentially using them in combination with each other, I can see how those issues could come up.
The best practices discussed in the post that I found most important were documentation and training. Any issues that arise when dealing with license issues would be incredibly hard to fix if you cannot find relevant information. Keep track of everything, within reason. I have worked in a company that had one person in our location who was fully trained to use the company’s software. She was berated with questions about how it worked without every employee getting a full understanding of the system. She was the linchpin. After she left, so many things fell through the cracks and I can only imagine how detrimental that could be when dealing with licenses. Making sure everyone is on the same page with a full understanding of how licenses work will save companies a lot of time and money.
After reading this post, I felt like this would be especially helpful for people starting their own company. Understanding the complexities and importance of software development can only help in the future. Although I do not feel like I will be making decisions on implementing a software management system anytime soon, I will still keep what I learned in mind when dealing with licenses.
The blog post: https://www.wrangle.io/post/seven-best-practices-for-managing-software-licenses
From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.
Inclusive Language
Recently our class discussed inclusive language and delved into tools that are able to root out non-inclusive language. I tried to find an article or blog that gives a set of examples to watch out for. I found a blog post that gives guidelines, examples of non-inclusive language, and provides examples of how companies are adapting to make their language more inclusive. The blog post is called, “Inclusive Language in Technology” by Barathy Rangarajan, DreamWorks Animation.
The blog post starts with giving a definition of inclusive language. It highlights the difficulty in changing language across repositories and identifying what is seen as non-inclusive language. Before diving into those offensive terms, they give four guidelines when writing code or documentation. These guidelines were: avoid using terms that have social history, avoid using idioms and jargons, write inclusive examples, and if you’re unsure, ask. I personally liked the inclusion of idioms and jargon being something to watch out for and how important it is to ask if you are unsure. Usually, idioms and jargon are just ingrained in the language we use based on where we are. Being aware of that when writing code or documentation for people who may not understand felt important. Understanding that these terms can be tricky to identify as non-inclusive, it’s important to ask those who might know more.
The post then gives a set of terms deemed non-inclusive, organized by different categories. These categories were, socially charged, gendered, ableist, ageist, and violent language. I won’t get into detail about each, but I recommend you take a look to familiarize yourself with the terms and alternatives. There were some terms I was not aware of.
The final portion of the article is the how companies have made changes to be more inclusive. They described how Autodesk, DreamWorks, and Sony pictures are addressing non-inclusive language. Some involve hiring based off race and gender, promoting resource groups, and setting a baseline initiative to produce inclusive code in the future and update older code. In one of my previous posts, I talked about setting ground rules that the team can agree on when conducting ourselves during development and discussions. I feel this is also relevant when it comes to inclusive language.
The blog post shed some light on the best practices and popular terms used when addressing inclusive language. In the future I will strive to be self-aware about how I write, ask question when I don’t know, and use what I’ve learned in day-to-day interactions along with writing code.
Link to the blog: https://www.aswf.io/blog/inclusive-language/
From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.