Category Archives: ai

A License to Develop Software

I read a blog titled “Software License Management” by Samantha Rohn of Whatfix. It dives into the complexities of software licensing, explaining the different types of licenses and their implications. Since I’ve been learning about open-source projects and legal considerations in software development, this blog felt like an essential read. I picked this blog because software licensing is a topic that many developers, including myself, often overlook or misunderstand. In my coursework, we’ve briefly touched on the importance of licenses, but I never fully grasped the differences between them or their real-world applications. As I start working on team projects and open-source contributions, understanding how to navigate licensing is crucial to avoiding legal issues and contributing responsibly to the developer community.

The blog provides an overview of software licensing, emphasizing why it’s critical for both developers and organizations. It categorizes licenses into two main types:

  • Permissive Licenses: These allow more flexibility. Developers can modify, distribute, and use the software with minimal restrictions, often without the need to release their modifications.
  • Copyleft Licenses: These require derivative works to retain the original license terms. For example, modifications to a product under a copyleft license must also be distributed with the same license attached.

The post also introduces the concept of software license management, highlighting the need for organizations to track, organize, and comply with licenses to avoid legal and financial risks. It concludes with best practices for effective license management, such as inventorying all software assets and ensuring compliance with usage terms.

This blog was an eye-opener for me. One thing that stood out was the explanation of copyleft licensing. Before reading this, I didn’t realize how restrictive some licenses could be in terms of sharing modifications. For instance, if I modify software with a copyleft license, I’d have to release my work under the same license, which might limit its use in proprietary projects. This insight made me rethink how I approach licensing for my own projects.

I also found the section on license management practices especially relevant. As developers, we tend to focus solely on the technical aspects of coding and ignore legal considerations. However, knowing how to choose and manage licenses is equally important, especially as I start collaborating on larger projects.

This blog gave me a clearer understanding of how to responsibly use and share code. Moving forward, I’ll make sure to read and understand the terms of any license attached to the libraries and frameworks I use. Additionally, when I create software, I’ll carefully select a license that aligns with my goals, whether for open-source contribution or proprietary use. If you’re new to software licensing or want to understand how to manage licenses effectively, I recommend reading thisblog. It’s a straightforward guide to a topic every developer should know.

Resource:

https://whatfix.com/blog/software-license-management/#:~:text=For%20the%20most%20part%2C%20copyleft%20licensing%20is,with%20the%20source%20product’s%20copyleft%20license%20attached.

Software License Management: An Enterprise Guide

Software License Management: An Enterprise Guide

Software License Management: An Enterprise Guide

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Connecting “Copyrights in AI” to Copyright and Licensing Homework

In the rapidly advancing world of artificial intelligence (AI), the intersection of technology and law has become increasingly complex. One of the most pressing legal issues is how copyright laws apply to AI-generated content. This is exactly what the article, “Copyrights in AI: Legal Overview” from HackerNoon offers, the author discusses the implications of copyright laws in the context of AI, focusing on whether AI can be considered an author of creative works, and how this impacts the rights of those who use AI to create content.

The article provides a clear overview of the current state of copyright law as it pertains to AI. Traditionally, copyright laws have protected works created by human authors, but with the rise of AI-generated content, it led me to ask: “can an AI be considered an author in its own right, or does the copyright belong to the human who programmed the AI, or the user who directed its output?” I learned that, under current law, AI cannot be considered an author in its own right, and the copyright typically belongs to the human creator or the user of the AI. This reflects a fundamental principle that we explore in our class, especially when considering software licenses. For example, when choosing a license for a software project, it is essential to understand the ownership of contributions and the rights of the contributors.

I selected this resource because the legal implications of AI are an area of particular interest to me, especially as AI continues to grow in influence and application across various industries. In one of my other classes, Computing Ethics, we talked about the ethical responsibilities and legal dilemmas surrounding the use of AI. The context being medical fields or business, how would the use of AI affect the users using it. This article connects those themes by highlighting the legal aspects of AI usage and authorship, which I had not fully considered before. It helped me understand that as AI technology becomes more sophisticated, the law may need to adapt to address new challenges.

By exploring “Copyrights in AI: Legal Overview” and reflecting on the licensing aspects discussed in my homework, I have gained a deeper understanding of how AI-related legal issues intersect with software licensing. In our Copyright and Licensing Homework, we focus on understanding different licensing models and the implications they have on the use and distribution of software so understanding who owns the rights to AI-generated works is critical to deciding how those works can be shared, modified, or distributed.

I expect to apply this knowledge when working with software projects, ensuring that the terms and conditions of any AI tools or systems used are clearly defined. As AI continues to grow in capabilities and its integration into software development increases, I believe this knowledge will be essential to navigating the complex legal landscape.

Link to the resource: HackerNoon article: Copyrights in AI: Legal Overview

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

Workflow for a Developer


This week, I came across an post titled “Improving Developer Workflow” on Vercel’s blog, and it caught my attention because I’ve been trying to figure out how developers stay productive while coding. The article dives into different ways to make workflows more efficient, focusing on tools and practices that help developers ship better code faster. Since I’m new to computer science and still figuring out how to work effectively, this post felt super relevant to my learning journey.

The post highlights key aspects of improving developer workflows. It starts by discussing the importance of having fast feedback loops, meaning developers should quickly see the results of their code changes. This post introduces tools like Vercel’s platform, which makes it easy to preview, test, and deploy changes almost instantly. Another focus is on collaboration, emphasizing how tools like GitHub help teams share work and review code seamlessly. It wraps up by stressing the value of automation, like setting up CI/CD pipelines, to reduce repetitive tasks and ensure consistent quality in the codebase.

I chose this post because workflow optimization feels like an essential skill for any developer, even beginners. Sometimes I get stuck on repetitive tasks or wait too long to test my code changes, which can be frustrating. This post seemed like a good way to learn how experienced developers streamline their processes. Also, tools like GitHub and CI/CD were mentioned in class, so I wanted to understand them better.

The main thing I learned is how fast feedback loops can save a lot of time and frustration. For example, using tools like Vercel lets developers instantly preview their changes in a live environment, so they don’t have to guess if their code works. I also learned how CI/CD pipelines automate testing and deployment, which not only saves time but also reduces the risk of errors. I realized that these tools make a developer’s life easier, but they also require some setup and understanding, which I’m excited to learn more about. Another cool takeaway was how much collaboration matters in a developer’s workflow. I’ve used GitHub for simple projects, but the blog post made me realize how powerful it can be when teams use it for pull requests, code reviews, and tracking changes.

This blog post made me want to improve my own workflow by setting up faster feedback systems, even for small projects. I also plan to explore tools like GitHub Actions to try basic automation for testing. In the future, I hope to use these techniques to work more effectively on team projects and avoid common frustrations like repetitive tasks.

Resource:

https://vercel.com/blog/improving-developer-workflow

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

AI Is Not A Software Engineer

In this blog, the author discusses how much the times have changed for new CS graduates. Reminiscing about how little they knew and how easily they got a job. Then talks about how much more prerequisite knowledge is needed to even sniff a job. The topic of the article is how now more than ever it is easier to get code that works. Thanks to AI, code is now more plentiful than it ever was before. However, all code is not good code. This leads to them discussing how despite how much code there is these days. Having people capable of understanding and able to build software are still very necessary. 

Although AI can now code for us, the coding wasn’t the hard part in the first place. The hard part was building software, and making good software. It’s easy to throw a bunch of code snippets together that accomplish something. But it is something entirely different to build specialized software that fills certain functions and meets certain criteria. AI cannot replace people, even though it may take away some jobs. At its heart, AI cannot build unique software. Teams of capable developers are still needed. The nature of how people code is changing. It’s becoming more important to be able to harness AI, but still oversee and build functional software.

I chose this article because I think it relates to team building. Like the article said, you need people who can understand code, not so much write it. Writing code is easier than ever, but finding people who understand how to build software is harder than ever. When using these tools it’s important not to rely on them too much. Discerning who can actually code these days is probably one of the most important skills for employers these days.  I think it’s important for me and everyone to keep in mind that AI is a tool. Tools dont make up for lack of knowledge. Tools are used best by people who know how to use them and maximize their use. One tool can’t solve every single problem. At the end of the day, knowledge is the most important part of being a software developer. 

Citations

https://stackoverflow.blog/2024/06/10/generative-ai-is-not-going-to-build-your-engineering-team-for-you/

By Charity Majors

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

How AI Tools Separate Us From Information

It is no secret that ChatGPT has blown up recently. It is not just used by CS people, but everyone from all walks of life. It has become a common tool used to help people with a wide range of problems. Offering a quick way to get answers without needing to look for answers by yourself. However, these AI tools are not just a catch all solution for every problem. In this blog from Stack Overflow called “Knowledge-as-a-service: The Future of Community Business Models” discusses how these recent developments have affected how we access information.

In just the last twenty years alone, the way of searching for knowledge has changed. Going from books, to search engines, and cloud technology allowing for farther reach. In recent times we have seen the rise of AI tools that help guide us to the answers we seek. These AI tools however, create a separation between knowledge and the people who make it. AI does the searching and synthesizing for us. Although convenient, it raises the question if that is the best way for people to learn.

Some common concerns held by people are that ChatGPT offers answers. It often does provide context as to why solutions work. What works for one dev environment might not work in another. AI is also reliant on humans for new consumption knowledge. If humans are not creating new knowledge, AI cannot create new information. The credibility of these tools often comes under scrutiny as well. Many developers mention how much variance there is to answers. Although these are certainly draw-backs, developers are learning that community created content is more needed than ever.

I choose this topic because I believe that most students use ChatGPT or some other tool to help us. I myself use it often to help with pretty much every single class I take. But I definitely rely on it the most for CS. I ask how something works or what is the best course of action. I think it is a common concern for many employers cause many don’t know how to actually code. Many people just copy and paste without learning. I am guilty of this myself. But I have been working on trying to actually understand every bit of code. And learning of where and when to apply these code snippets I use. I believe it is still very important to learn from sources outside of chatGPT. Like from classes or other websites composed of trustworthy data. It’s good to learn how to do things yourself without relying on outside sources.

Citations

https://stackoverflow.blog/2024/09/30/knowledge-as-a-service-the-future-of-community-business-models/

By Ryan Polk and Ellen Bradenberger

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Software Maintenance

Source: https://www.geeksforgeeks.org/software-engineering-software-maintenance/

This article is titled “Software Maintenance – Software Engineering.” Software maintenance “refers to the process of modifying and updating a software system after it has been delivered to the customer.” There are many different aspects involved in this including: fixing bugs, adding new features, and keeping up with new hardware and software requirements. Maintenance is very important for ensuring that software is able to last long. This process can be expensive and complex, so these factors must be taken into account during the planning of a software development project. The important tasks in regard to software maintenance are: bug fixing, enhancements, performance optimization, porting and migration, re-engineering, and documentation. Summarizing these tasks, it is important to find and fix errors quickly, add new features/improve existing ones, improve the performance of the software, adapt the software to run on different hardware, improve the design, and maintain accurate documentation of all of these processes. There are quite a few different types of software maintenance, but they can be categorized into proactive and reactive types. “Proactive maintenance involves taking preventive measures to avoid problems from occurring, while reactive maintenance involves addressing problems that have already occurred.” Maintenance can be done by stakeholders, the development team, a third-party, and they can be both planned or unplanned. Planned maintenance can be described as regular maintenance (bug fixes) while unplanned maintenance can be described as reactive maintenance that occurs when something unexpected happens. Maintenance can fall into these different categories: corrective maintenance, adaptive maintenance,  perfective maintenance, and preventive maintenance. Corrective refers to fixing bugs and enhancing performance of the system. Adaptive refers to modifications being made when a customer needs the software to run on a different system. Perfective refers to the adaption of the software when a customer has a demand. Lastly, preventive maintenance refers to modifications that focus on the prevention of future issues with the software. Software maintenance is important but there are some things to consider: the cost, complexity, possibility of new bugs, users not updating the software, compatibility, technical debt, and end-of-life (where maintenance isn’t possible anymore or cost-effective).

I chose this article because I found it in the syllabus and thought the topic to be interesting. We are always learning about the development of software, but the idea of maintaining it over the long term isn’t as heavily considered. A large part of the work of a software development team is to obviously develop software but it is also important to learn about how it can maintain a sense of longevity free from error and customer complaints. I will keep the information I learned from this article in mind in future projects and when I’m working with a team to ensure that I’m developing software all the while keeping maintenance in mind. If it is considered during the development process, the maintenance process will be much easier.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Anti-Patterns

Source: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/

This article is titled “Anti-patterns You Should Avoid in Your Code.” It specifically mentions six of them, being: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object. An anti-pattern, in regards to software development, is an example of how not to solve a problem in a codebase. They are not a positive thing, they are examples of practices to avoid in the development process. Anti-patterns lead to technical debt, code that you have to eventually come back to and properly fix later. Spaghetti Code is the most common, it is code that doesn’t have much structure. It is called Spaghetti Code because everything is difficult to follow, files are located in random places, and when visualized in a diagram, it appears to be a jumbled mess, much like spaghetti. Golden Hammer references a scenario where you follow a certain process that doesn’t necessarily align perfectly with the project but still works well enough. This may not seem like a large issue, but is obviously not the best practice to follow because it’ll cause performance issues in the long run. You should always use a process that is the best fit for your project, even if you need to teach yourself or learn something new. Boat Anchor is when developers leave code in the codebase that isn’t actively being used in the hopes of it being needed later and thus not requiring much effort to implement when it is eventually needed. The main problem with this is when it comes to maintaining the code. It leads to the question of what code in the codebase is unused and what is being actively used. Trying to fix a bug in the system on code that isn’t even being used is a time waster. Dead code is code that doesn’t look like it’s really doing anything, but it is being called from many different places. This leads to problems when trying to modify the code because no one is unsure what is actually dead. Proliferation of Code is about objects that have the purpose of invoking a more important object, meaning it doesn’t really do anything on its own. The action of invoking the more important object should be set to the calling object. Lastly, the God Object is an example of an object that does too much. Objects should only be responsible for doing one thing, referencing the Single Responsibility principle in SOLID. 

I chose this particular source because I appreciated the way examples were clearly given along with the 6 examples of anti-patterns, and upon reviewing the syllabus the topic “anti-patterns” seemed interesting. When you’re learning computer science a lot of the time you’re learning about things that you should do and not about things that you shouldn’t do. I really enjoyed reading about these 6 examples of common mistakes that developers make in industry. It’s important to both recognize good and bad practices to ensure that your projects are properly optimized. I can definitely see myself referencing anti-patterns when designing code in the future so my code can easily be maintained. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

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

Considering this week we only had one day of class it’s good to reinforce the ideas we learned to spread out in separate classes. I was in a search this week for an article that went into depth about software technical reviews. Software technical reviews are very important; understanding the fundamentals is a key component in the field. 

The main function of a software technical review is to examine a document either in a group or alone and find errors or any defects inside the code. This is done to verify various documents to find if they reach specifications, system design, test plans, and test cases. An important thing to consider is this is a step to make sure the client gets clarity of the project and stays informed on how it’s going. In addition, finalize any changes to reach the requirements before being released to the market. This allows for improved productivity, makes the testing process cost-effective, fewer defects to be found outside the team, and reduces the time it will take to create a technically sound document. The main three types of software reviews include software peer review, software management review, and software audit reviews. The process of software review is simple if you are informed of the implementations taking place. First is the entry evaluation which is just a standard checklist to know the basis for the review. Without a checklist, you will be pulling on strings to find what is wrong with the code or what it’s missing. Then comes Management preparation ensures that your review will have all the required resources like staff, time, and materials. Next is review planning where you create an objective that comes from the team. You then move on to preparation where the reviewers are held responsible for doing their specific task. Lastly, examination and exit evaluation where the group meets up and is discussed to make the team on the same page and verify any discoveries.

Reading this article allowed me to see other steps that are taken to do a software technical review. If we as a team were able to create an objective of what to search for inside the code last week it would have been more goal-oriented instead of randomly searching for faults in the code. As a team, it would have been great to have a more organized group so then when we come together we have an understanding of what we should all find. I would like to see how it would work trying to explain to someone who doesn’t code what has been done and show them that their money is being placed in the right place. Other than that this is a great way to reduce time and be in unison with your team.   

https://medium.com/@vyashj09/software-technical-reviews-in-software-testing-what-is-software-technical-review-321462039f4f#:~:text=A%20software%20technical%20review%20is,an%20object%20in%20the%20software.

View at Medium.com

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Black Box vs White Box Testing

In the ever changing and dynamic field that is Software development, understanding the nuances of different testing methodologies is crucial for ensuring quality and reliability. I would like to say that I stumbled upon the blog “Black vs White vs Grey Box Testing” on Shakebugs.com however, the truth is I was still a little confused after our last class and needed further clarification not only on the difference of the two testing methods but just what they do and when they are used. And well this article did just that it resonated with what we were learning and sparked several insights that I believe will impact future practices.

The article navigates through the concept of black, white and grey box testing (I did not even know grey was a thing.) Black box testing, as it explains, is an approach where the tester assesses the functionality without knowledge of the internal workings of the application. White box testing, on the other hand, requires a deep understanding of the code, as tester need to verify the internal processes and pathways. Grey box emerges as a hybrid approach, combining elements of both black and white box testing. It allows testers to apply their partial knowledge of the internal structures while examining the software’s external functionality.

As I mentioned before I chose this resource because it matched the topics we were discussing in class and further helped develop my understanding of the practical applications of the different testing methodologies. The clear and concise explanations paired with practical examples and visuals, provide a framework to differentiate and appreciate the unique attributes and applications

Reading this article was more delightful than I initially anticipated as when I saw a 13 minute read time I almost closed the tab however, I am glad I did not. I learned that while black box testing is excellent for validating user requirements and functionalities, white box testing is indispensable for internal code optimization and security assessments. Grey box testing , with its balanced approach, offers a valuable perspective for comprehensive testing.

Going forward, I intend to integrate these insights into my approach to software testing. In future projects, I will not only consider the functional requirements but also the internal code structure and security aspects when deciding on a testing strategy.

The blog post is a must-read for anyone in the field of software development testing. It offers clear and practical understanding of the different methods, guiding how to apply them effectively. You can read the full article here . This resource not only enhanced my understanding but has also equipped me with practical knowledge I am eager to apply in the future.

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.