In this week’s class, we delved into some intriguing topics that shed light on the dynamic world of project management and software development. So, let’s recap the highlights of our recent discussions.

New Project Initiation:

We kicked things off by exploring the essential steps in new project initiation. It all begins with reading product descriptions and commencing a basic requirements analysis. This initial phase sets the tone for the entire project, as it helps us understand what we’re about to embark on. Clarity at this stage is paramount.

Then, we moved on to the technical side of things by creating a new project on GitLab. We ensured that all the required files were in place and established a board structure tailored to support Scrum development. This pivotal step lays the foundation for collaborative, agile work and efficient progress tracking.

One concept that stood out this week was the “Definition of Done.” Understanding and defining what constitutes a complete task is vital to maintaining project integrity and ensuring that everyone is on the same page regarding project expectations.

Copyright and Licensing:

The second part of our class dived into the complex yet critical world of copyright and licensing. It’s not just about legalese; it’s about safeguarding your work and respecting the intellectual property of others.

We explored Free & Open Source Software Licensing, digging into the details of when a work becomes copyrighted and who owns that copyright. This knowledge is essential in avoiding potential legal pitfalls.

We also examined what you can and cannot do with unlicensed software. Knowing the boundaries here is crucial in preventing unintentional violations.

Licensing became a central theme in our discussions, as we explained its role and its significance in the realm of open-source software. We even delved into specific licenses like the GNU General Public License, Mozilla Public License, Eclipse Public License, and MOT License, each with its unique implications and considerations.

Lastly, we explored the importance of identifying the license of published software. It’s essential to be aware of the rules and limitations when using or contributing to open-source projects.

In summary, this week was an exciting journey through the early stages of project initiation, all the way to the intricate world of copyright and licensing. These insights will undoubtedly prove invaluable as we continue our education and venture into the realms of project management and software development. Stay tuned for more exciting insights in the coming weeks!

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog is “Understanding Software Licensing”. This blog discusses what a software license is, how it works, why it matters, a few types of software licenses, and how to decide the best type of license for your software. In class, we discussed the topics that were brought up in this blog so I decided to do a deeper dive into software licenses to refresh my mind on the information that we reviewed and possibly gain a better understanding of it. 

The author tackles the topic in an organized manner that makes each part easy to follow. In the section about why software licenses matter, the author outlines clear advantages from different standpoints. For example, he states that from a developer standpoint, they offer benefits like “preventing users from performing actions like copying and distributing your software, if the license prohibits it, limiting your own liability, spelling out your own rights as a developer, and allowing you to control the usage of your product”. He then outlines the benefits from a user’s standpoint; he mentions that it helps you manage your tools and resources,  prevents you from paying for tools that aren’t necessary for your business, and clarifies how the provider can use your private information. The choice to clearly outline the advantages from each standpoint aids in the reader’s understanding of the importance of licensing software.

The sections on the types of licenses were beneficial. The public domain license is a simple license to understand. The section that defines a copyleft license is an open-source license meaning that deviation of the code must have the same terms. Defining the GNU license as a weak copyleft license helped to simplify what it was. His explanation of a permissive license was helpful as well. He defined each type of license with a short, simple statement at the beginning and then went on to further explain them.

The other part of the article that I found to be very helpful is the section about how to figure out what the best type of license is for your software. Because software licensing is new to me, I was struggling to pick which license I should use for a project. The author mentions that you should “consider the different models, thinking about the purpose behind your code and what you want users to be able — and not be able — to do with it”. It can be very challenging to outline the true purpose of your code clearly. It was very helpful that the author clearly defined the types of licenses in simple terms and then gave simple advice on how to pick which one to use. I enjoyed reading this blog and will use the knowledge for my future projects.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

API, or application programming interface, is a set of specifications that allow applications to interact with one another. They enable transfer of information and is treated as an intermediary level let companies open their application data to external third-party developers as well as internal departments within the company. An example of how APIs work is third-party payment processing. For instance, when making a payment online and being given an option to “Pay with PayPal”, the connection made between the third-party payment system and the website where the payment is being made is reliant on APIs. When selecting the option, an API calls to retrieve information or request. After processing the request from the application to the web server, the API makes a call to the external program/web server. In this situation, it would be the third-party payment system. The external system then sends the requested information back through the API to transfer to the initial requesting web server.

REST is a set of design principles and stands for “representational state transfer” architectural style. Sometimes referred to as RESTful APIs, they were first defined in 2000 by Dr. Roy Fielding and provides more flexibility and freedom for developers. They can support many different data formats and are required to follow the 6 principles, also known as architectural constraints. The six principles are the following: uniform interface, client-server decoupling, statelessness, cacheability, layered system architecture, and code on demand (optional).

Uniform interface means that all API requests from the same resource should have identical formats to ensure that a piece of data belongs to only one uniform resource identifier (URI). The resource should not be too large while still containing the information the client needs. Client and server applications must be completely independent of each other in REST API design. The client application only needs to know the URI of the requested resource and cannot interact with the server in any other ways. Statelessness means that each request needs to include all the information necessary for processing it, which means REST APIs do not require any server-side sessions. Resources should be cacheable on the client or server side and the server responses should contain the needed information about whether caching is allowed for the delivered resource. The purpose of this is to improve performance on the client side while also increasing scalability on the server side. REST APIs have different layers to them that calls and responses go through. To note, do not always assume the client and server applications connect directly to each other. These APIs need to be designed so that neither the client nor the server can tell whether it communicates with an intermediary or end application. In certain cases, responses can contain executable code when they usually send static resources. In the case that an executable code is added (such as Java applets), the code should only run on-demand.

What is a REST API? | IBM

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

As a computer science student, my recent deep dive into REST filters and queries has been an exciting journey, and I’m eager to share my newfound knowledge on my blog. This educational adventure has been made all the more engaging by drawing inspiration from a renowned source, “The Web Developer’s Guide to REST APIs,” an authoritative guide known for its in-depth insights. By harnessing the capabilities of REST filters and queries, I can adeptly extract, manipulate, and interpret data from various real-world APIs, offering invaluable insights for my web development endeavors.

The power of REST filters and queries becomes abundantly clear when applied to an API or database. These tools empower me to refine, categorize, sort, and arrange data with utmost precision. A simple yet potent filter allows me to isolate a specific subset of data, such as products falling within the “Beverages” category, using a query like: /products?filter=category eq 'Beverages'. This not only trims down the dataset returned but also permits a laser focus on the data that is most pertinent to my objectives. Furthermore, I can apply the $orderby parameter to arrange the results in ascending or descending order, perhaps alphabetically or by price, for a comprehensive understanding of the data landscape. This degree of command over data proves instrumental, especially when dealing with voluminous datasets in real-world applications.

REST queries, in addition to their filtering and sorting prowess, offer the capability to conduct intricate data operations. Consider, for instance, the need to identify the top 5 customers who have placed the highest number of orders. By adroitly combining the $filter and $orderby parameters, I can craft a query like: /customers?$filter=orderCount gt 0&$orderby=orderCount desc&$top=5. This flexible and nuanced data manipulation capacity is a linchpin in my decision-making process as a developer and is a skill set crucial for me to master. Consequently, anticipate an insightful journey as I delve deeper into the realms of REST filters and queries, leveraging the wisdom from “The Web Developer’s Guide to REST APIs,” to enhance my data manipulation expertise.

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

Overview

In order to be able to use someone else’s software for your own software project, you must attain a software license. This license establishes the rights and limitations that you have when using the product owner’s software. Software licenses are attained by licensing agreements, where you sign a contract with the owner of the software to use the patented technology.In that contract contain the rights, responsibilities, and limitations you have as a user. I think if you develop some sort of software, it is crucial that you and your team are recognized as the owners of it, and that outside users don’t use it however they feel like. There are many types of software licenses that have different terms and conditions. An article that I read by Ben Lutkevich went more into depth of what a software license and agreement will usually look like, as well as the different types.

Attaining a License

You are about to sign the licensing agreement to officially be able to use someone else’s software. Here’s what to expect. On it will be basic information about both sides. Your name, your address, contact information, as well as the lending party’s. It will contain when the agreement officially goes into effect, and you are able to use the software. It will contain the duration of how long you are able to use the software. It will include how much you have to pay for the software, how many users are eligible. It will give a disclaimer of warranties, as well as maintenance, upgrades and support. Most importantly, it will include the permissions and limitations on distributing the software, user rights of copying and modifying the software. These licensing agreements may differ depending on the type of software license.

Types of Software Licenses

The most common software licenses you find are Proprietary and FOSS. A proprietary software license is commonly referred to as closed-source. Proprietary licenses do not allow users to freely alter the software. Whereas FOSS (Free and Open-Source Software) is the opposite, where the customer is allowed to use the source code and alter the software. FOSS is commonly referred to as open-source. This is the type of license that we will be using in class. Two other licenses that are familiar are Permissive and Copyleft. Permissive software licenses establish some requirements for distribution or modification of the software, and Copyleft notes that licensed code may be distributed or modified as part of a software application or project if all code involved is distributed under the same license. New products containing old code with a copyleft license have the same restrictions as the old code’s license.

Conclusion

If planning to create a software product, it is a smart idea to establish copyright for it, so you are credited for the work you put in. And if you are using someone else’s product for your own product or project, it is the smart decision to attain a licensing agreement, avoiding any potential lawsuits.

Article URL

https://www.techtarget.com/searchcio/definition/software-license#:~:text=A%20software%20license%20is%20a,the%20software%20without%20violating%20copyrights.

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

Refactoring is the process of restructuring a code without changing or adding to its functionality and external behavior. There are a lot of ways to go about refactoring but it mostly goes towards applying standard basic actions. These changes in the existing code save the software’s functionality and behavior since the changes are so tiny, they are less likely to cause any errors. So, what is the point of refactoring? Well, refactoring is to turn any messy confusing code into a clean understandable one instead. When a code is messy it means that the code is hard to understand and maintain, when it’s time to add a required functionality it causes a lot of problems with the code because it’s confusing already. With a clean code, it’s easier to make any changes and improve on any problems. Also with a clean code anybody who ever works with the code is able to understand the code and can appreciate how organized it is. When a messy code isn’t cleaned up it can affect any feature developments because developers have to take more time to understand the code and track the code so that they can make any changes themselves.

Knowing when to refactor is important and there are different times to refactor your code. Like refactoring, while you’re reviewing the code, reviewing the code before it goes live is the best time to refactor and make any changes you can before pushing it through. You can also schedule certain parts of your day to refactor your code instead of doing it all at once. By cleaning your code you are able to catch any bugs before they create any problems in your code. The main thing about refactoring your code is that cleaning up a dirty code can reduce technical debt. Clean code is easier to read and if anybody else besides the developer works on that code they are also able to easily understand that code as well as maintain and add features to it. The less complicated the code is, it can lead to improved source-code maintenance. With a clean code, the design can be used as a tool for any other developers it can become the basis of a code elsewhere. This is why I believe that refactoring is important because changing just the smallest piece of code can lead to a better functional approach to programming. It helps developers get a better understanding of the code as well as making better design decisions.

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