Category Archives: CS-343

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

cs-343, CS@Worcester

cs-343, CS@Worcester

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.

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://medium.com/@krunalchauhan_/article-worth-reading-on-what-is-an-api-what-is-a-rest-api-and-deep-diving-into-rest-api-fea074dacaed

https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

https://www.atlassian.com/agile/project-management/scrum-values#:~:text=Scrum%20is%20a%20set%20of,solving%20and%20reducing%20project%20timelines.

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.

Dev Container Basics

What is a Dev Container?

A Dev Container, or development container, encapsulates a complete development environment accessible through Secure Shell (SSH) in your preferred Integrated Development Environment (IDE). It overcomes workflow impediments such as low performance and limited bandwidth by providing an isolated environment with standardized configuration stored in a .devcontainer.json file. This JSON file, structured with Comments (jsonc) metadata, allows customization for specific needs, such as adding tools or extensions.

Why Use it?

Addressing Setup Configuration Issues: Maintaining and managing local environments involves the use of various tools and configurations, leading to a cumbersome process. Standardizing this process with a unified approach can significantly save time and streamline setup configurations.

Standardizing Build Instructions of the Project: Documenting dependency upgrades and changes can be challenging. Utilizing code rather than extensive documentation simplifies the process, enabling anyone to ship without being hindered by the “it works on my machine” dilemma.

Ensuring Isolation of Development Environments: Developers often work on multiple projects simultaneously, each with its own complexities. Isolating environments prevents conflicts with other software on the host system, creating a clean, controlled space for development tasks.

Enabling Consistency Across Development Teams: Achieving portability across diverse teams is complicated by varying technologies and configurations. Implementing a standardized development environment ensures uniform configurations among team members, minimizing inconsistencies from individual machine differences.

Simplifying Onboarding and Training Processes: Quickly launching environments in isolation facilitates learning new languages or frameworks. This approach is particularly beneficial for onboarding and training processes, keeping machines clean and allowing for smooth presentations and workshops, where everyone can follow along without interruptions caused by missing tools or confusion mid-step.

Dev Containers in Real World Enviroment

  1. Standardized Development Environments:
    • Dev Containers provide a standardized and reproducible development environment, ensuring that all team members work with the same configuration. This minimizes the “it works on my machine” issue and streamlines collaboration.
  2. Setup Configuration Management:
    • Addressing setup configuration issues is simplified with Dev Containers. They help in managing dependencies, tools, and configurations uniformly, reducing the time and effort required for setting up development environments.
  3. Version Control Integration:
    • Dev Container configurations are often stored in version control systems (e.g., Git), ensuring that the development environment is versioned along with the code. This enhances collaboration and makes it easier for team members to switch between branches or versions seamlessly.

Personal Experience

Dev Containers are something I have recently just learned about, and I feel like the need for them is understated. The overall idea behind such a tool is to create a simple and consistent environment for a team to work in. Anytime I work on a project, I stress the need for one as it eliminates many common problems teams face in the early stages of development. I also believe that when I start my professional journey, I will find these containers to be more standardized within the teams I work with.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

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 Framework

After reflecting on the previous blog that I had written about coding, I pondered about what would happen if I were to work with software, and I immediately wanted to consider something about a software’s own making. For this blog, I decided to focus on Software Framework, which many programmers and organizations make great use of in the workforce. I took great interest in an article written by Tiago Monteiro, fittingly titled “What is a Software Framework?” It starts by giving the reader a simple concept where a man uses an axe to cut trees and then cuts wood to use for his fireplace for his family. When the chainsaw was introduced into this analogy, it related really well to programming, where you either start with fresh new code or make use of an existing framework done by another user to build your program. Reading more into the article, I found that there were advantages and disadvantages to using a software framework. While a framework is how anyone would start to form their own software, nobody has much freedom to alter the framework, limiting the use of a software framework to the functionality it was designed for.

I chose this article for my blog, because I believe that this article might help me in understanding a bit more about Software Engineering. Although the author of this article is a high-end Computer Engineer, his article could still give me an idea of what I should visualize when I start to learn more about designing software. A software has to have a framework to maintain functionality so it does not become inept, just as a computer will stop working if one of its most important parts either burns out like a wildfire or starts to malfunction upon reaching the end of its half-life.

My biggest takeaway from this article is that there are lots of software frameworks with many functionalities that are made useful in different manners.  Just as we try to create the framework to integrate smart machines into our appliances and everyday tools, we try to do the same with creating framework in our software as well.  We give life to our software the same way we try to create new computers, by giving it a spark of new and innovative programs for the greatest user and technological experience.

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

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

some design principles

We’ve covered a great many design principles during the course of this semester in Software Construction, some of which I’ve even covered in these blog posts (law of demeter comes to mind). For the end of the semester, I wanted to have a little review on some of the principles that I don’t recall all too much.

Starting off with one that isn’t too complicated, I wanted to briefly refresh on the YAGNI (or You Ain’t Gonna Need It) principle. According to a blog post by Tatum Hunter of Built-In, the practice entails only building features when needed. I found this post fairly insightful in the way it goes over how customers might want a large-scale feature now, so you may have to talk them down to a more realistic goal to avoid adding functionality that won’t be necessary, or to say no.

The principle of “striving for loosely coupled designs between objects that interact” is essentially implementing the observer design pattern. I believe I went over this in a previous blog post, but I did find another post by Harold Serrano that provides a brief summary as well. Serrano states that the principle means that objects should be able to interact with each other, but shouldn’t know much about each other.

For the principle of “encapsulating what varies,” a simple blog post from Alex Kondov explains what this means and why we do it. Essentially, we want to encapsulate the parts of the code that we write which are prone to change so that we don’t have to change a whole block of code for something that should be a one line fix. This makes our code adaptable and leads to cleaner code.

Inversion of control is used for abstraction simplicity. Kent C. Dodds explains that we want our abstraction to have less responsibility, while the user has more. He uses an example of a filter method that uses inversion of control, and one that doesn’t. The difference is that when the control is passed into the method rather than handled in the method, there is a lot less going on within the method, which increases simplicity. I found this really interesting because I was thinking about doing this for our GuestInfoBackend homework, before I kind of lost interest because I’m not too well-versed with Javascript, and I didn’t have much time to do it, hah. Needless to say, it’s a really interesting tool in my opinion and I find it very practicable.

This semester, we’ve gone over a great many ways to ensure proper software design, and these practices and skills are a great way to streamline your thought process. I think the important thing, as I’ve said before, is to not treat these as concrete rules, but to consider them in higher priority before writing code. Sometimes, you can’t get the perfect solution that fits all the proper software design principles, and that’s okay. It’s a matter of making sure the code is solid, pun intended.

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.

YAGNI

“You Aren’t Gonna Need It” is an agile design principle from ExtremePrograming that goes against building code for future features before they are needed. Martin Fowler states in his blog “YAGNI” (https://martinfowler.com/bliki/Yagni.html) how building these features early typically add more time than they save. Fowler breaks down the individual costs of these features and where they add up, along with how these costs vary between three different scenarios. The best scenario is that the presumptive code was still required and added to the project when it was needed. The next scenario is that the feature is scrapped from the project entirely. Arguably the worst scenario is that the feature is added, however, the code that was built in the past was built incorrectly and needs to be updated. These scenarios each have their different costs, but even with the best scenario it is likely time was still lost between deciding to build the feature and when it was finally needed. Assuming that time can be saved by adding a future feature early because it relates to something you are currently doing will only add more work when it comes to debugging, refactoring, and reading the code.

Costs of YANGI

  • Cost of Building – All effort and time programming, analyzing, and testing the feature.
  • Cost of Delay – The time spent on the presumptive feature could have been spent on a more relevant and required feature, creating a delay in the release and actually monetary and time based costs.
  • Cost of Carry – Adding unnecessary code to a project only makes it harder to read and understand, slowing down further production.
  • Cost of Repair – Assuming the feature is eventually added to the project, the way it was built in the past may not be right anymore and needs to be repaired or redone.
  • Cost of Removal – In the event that the feature is scrapped and removed from the project, the code will also need to be removed or will only continue the accumulation cost of carry.

What YAGNI Is VS What YAGNI Is Not

Following the principle of YAGNI means time spent building code should be spent building code that is relevant to the current state of the build. This does not mean that refactoring falls under YAGNI principles as it is time being spent making the software easier to modify.

Using YAGNI Moving Forward

As projects become larger and more complicated it is important to keep my code clean, organized, and on schedule. The best way to do this is to ensure features are added only when they are needed to not clutter the space with unused code.

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

Reflecting on the Core Pillars of Object-Oriented Programming: Insights from a Recent Exploration (Week-14)

In my recent exploration of Object-Oriented Programming (OOP), I came across an insightful blog post titled “Unraveling the Mysteries of Object-Oriented Programming: A Deep Dive into its Core Concepts.” This blog, written with clarity and depth, provided an in-depth look into the foundational elements of OOP – Abstraction, Encapsulation, Polymorphism, and Inheritance.

The original blog post broke down the complex principles of OOP into digestible segments, explaining each concept’s significance and application in software development. It began with Abstraction, describing it as a method for simplifying complex systems into essential characteristics. Encapsulation was then introduced as a means to protect data integrity by bundling data and methods within a class. Polymorphism was highlighted for its flexibility in allowing different classes to be treated under a common interface. Finally, Inheritance was discussed as a tool for building new classes from existing ones, promoting code reuse and efficiency.

Reflection on the Blog’s Content:

I found the original blog post remarkably enlightening. The way it articulated each concept with relevant examples made OOP’s sometimes abstract principles more tangible and relatable. Particularly, the explanation of Polymorphism and how it enhances flexibility in programming was an ‘aha’ moment for me. The post’s structured approach in dissecting each principle separately yet showing their interconnectedness provided a holistic understanding of OOP.

Application in Future Practices:

The insights gained from the blog will significantly impact my approach to software development. The understanding of Encapsulation will guide me in writing more secure and robust code, emphasizing the importance of data protection. Additionally, the concepts of Inheritance and Polymorphism will be instrumental in designing more versatile and maintainable code structures, enabling me to tackle complex programming challenges more effectively.

The blog’s detailed exploration of Abstraction has particularly equipped me with a strategic approach to problem-solving. By focusing on the essential elements of a problem, I can better manage complexity and enhance the clarity of my code.

Conclusion:

This reflection on the foundational concepts of OOP, as explained in the initial blog post, has been both educational and transformative. It has deepened my understanding of OOP’s core principles and their practical applications in real-world programming scenarios. As I continue my journey in software development, the insights from this blog will undoubtedly serve as a valuable guide in crafting efficient, robust, and maintainable software solutions.

Resource Reference:

“Unraveling the Mysteries of Object-Oriented Programming: A Deep Dive into its Core Concepts.” Blog post,. https://codedamn.com/news/javascript/oop-best-practices .

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.

Week 14 – Token #2 – CS-343

For this blog, I specifically wanted to look into how this class relates to the preferred field I want to go into, which is Game Design. I wanted to see what kind of languages would be used, what kind of design elements are implemented, and even in the case of frontend vs. backend, how online games employ servers.

However, it seems like I had a misunderstanding that these two positions were similar omewere, as I find many sources that say software design vs. game design are a completely different beast, which only made me more interested. I did some more research, and this lead me to end up reading this article below:

Software Engineer vs Game Developer – Which one is for you?

Specifically I noticed that software development has more rigidity when it comes to designing and delivering a product. Software engineers are usually employed to design a software to meet consumers demands, which usually entails specific features and options they’d want in the software you’re developing. Whereas with game design, you have a much more flexible development cycle, as theres a lot more creativity involved. You’re less focused on making sure specific features are available and more focused on delivering a product that is unique and interesting for consumers, and keeps them engaged.

Game developers also rarely work with programming languages when it comes to development of products. Game developers mainly use engines, which are interfaces that employ programming languages to create building blocks to build off of to create a video game. Software engineers mainly work with the code directly at almost all times, making sre each line is properly written. That’s not to say some game devs don’t work with code directly, some do, and many Triple A companies actually write their own engines using their own code, like in the case of Epic Games’ Unreal Engine, which is used to power their famous game Fortnite.

Something this article notes is that software developers may not need to worry about performance compared to game developers, and I can understand why they might say that. Games rel on having a fluid and enjoyable experience, and that is dependant on the performance of a game, making sure theres no glitches, bugs, or lag. However, I would argue that performance is still a factor within software design too, because what if a simple calculation process in a program takes multiple minutes? Consumers will still have an issue with that. While I do think it’s definitely a lot more important in game development, that’s not to say it’s not unimportant in software design.

And that’s all my blogs for this semester! I’ll be taking another of Professor Wursts classes next semester, so I’ll likely be writing again then. See all you readers come January!

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.

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

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.

Week 14: CS-343

Design Patterns

A design pattern is a general solution that can be used to solve commonly occurring problems in software design. A design pattern cannot be put directly into code, rather it is a template of how to solve a problem that can be used various situations.

Design patterns are helpful as they speed up the development process by providing proven examples to be used as a reference for common problems. When designing software, small subtle issues can build up leading to major problems that can only be seen during implementation. Using design patterns can help prevent these subtle issues from occurring which reduces the likelihood of major issues occurring.

Because design patterns are tested, proven, and commonly used, patterns also allows for better communication among developers by using well known and understood names for software interactions.

Types of Design Patterns

Creational

Creational design patterns cover class instantiation. These patterns can be further divided into two classifications, class-creation and object-creational patterns. Class creation uses inheritance in the instantiation process, while object creation uses delegation to create objects. Some creational design patterns are:

  • Singleton
    • A class where only a single instance can exist
  • Factory Method
    • Creates an instance of several derived classes
  • Object Pool
    • Avoids expensive acquisition and release of resources by recycling objects that are no longer in use

Structural

Structural design patterns are about class and object composition. Like creational patterns, structural patterns can also be broken down into class creation and structural object patterns. Class creation patterns use inheritance to compose interfaces, while object patterns define ways to compose objects to obtain new functionality. Some structural patterns are:

  • Adapter
    • Matches interfaces of different classes
  • Private Class Data
    • Restricts accessor/mutator method access
  • Decorator
    • Adds responsibility to objects dynamically

Behavior

Behavior design patterns are about how objects communicate with each other. Some examples of behavior design patterns are:

  • Null Object
    • Used to act as a default value of an object
  • Chain of Responsibility
    • A way of passing a request between a chain of objects
  • State
    • Alter an object’s behavior when its state changes

Conclusion

This article was chosen because it clearly described what design patterns are, what they are used for, and gave examples of the different types of design patterns. As stated before, not only does the usage of design patterns help with preventing major issues, they also allow for better communication among developers which is essential to a team’s success which is why I chose to write about design patterns. As I continue to design software, effectively using design patterns will become more and more prevalent, so learning about them now will only be beneficial.

Resources:

https://sourcemaking.com/design_patterns

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