For my second blog post, I will explore Software Licensing. I chose this topic because we have learned in class about the different types of licensing and what you can or can’t do with specific ones. There are multiple options to choose from when selecting a license for a program or software, and these differences can sometimes be confusing. I decided to dive deeper into this topic and found a blog titled “Understanding Software Licensing” by Fernando Galano.

The blog is divided into five sections: What is a software license? How does it work? Why does it matter? What are the types of software licenses? How do you find the perfect license for your software? The blog does a good job highlighting the importance of a license and the complexities of the legalities that come with terms and conditions. As we learned in class, a license is a type of legal contract between the creator(s) and the users interacting with the software. This interaction for the users can include the installation, modification, copying, or distribution of the software. It’s ultimately up to the creator(s) to select the license they want, which then defines what rights the users possess with the software.

In our class discussions about software licenses in model two, we discuss the different types of licenses and which is the best. The blog also does a good job explaining the differences between them while giving examples of companies that use certain licenses. Some examples of licenses for software are copyleft, public domain, permissive, and open source. Each of these licenses has its benefits and limitations, and it is up to the creator to line up the values they want their software to use. For example, a public domain has no restrictions on how the software can be used, but in comparison, a copyleft license forces derived work to have the same conditions.

The blog ends by explaining why licenses even matter and how to choose which best describes your situation. It explains that licenses have benefits for the user and the creator and these benefits help both parties understand the terms and conditions for its use while avoiding confusion. The author highlights the benefits for the user as an aid to managing tools and resources, clarifying how you can use them, and preventing unnecessary costs for tools the user may not need. The benefits for the creator include preventing unauthorized copying and distribution, limiting liability, and giving the creator control over the usage of their product. What I wish the blog talked about is the similar topic of copyright. We learned about this important topic in part one of software licenses by answering questions like, “You have a new idea for a program, can you copyright that idea?” or “You created a new program based on that idea, is that software copyright-able?”.

This blog did a great job explaining how licenses protect the user and creator while going in-depth on the different types to choose from.

Source: https://www.bairesdev.com/blog/understanding-software-licensing/

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

Brygar’s principle of Simplicity resonates with Abstraction, as both focus on reducing complexity and emphasizing essential features. For example, an abstract Shape class might define a method draw(), but the specific implementation (how a circle or square is drawn) is handled in the subclasses Circle and Square. This simplifies the user interface by exposing only the necessary functionality.

Consistency aligns with Encapsulation, which involves bundling data and the methods that operate on it into a single unit and controlling access to the object’s internal state. For example, a Student class might have private fields like name and age. These fields are accessed or modified only through controlled public methods like getName() or setName(), ensuring that the class remains consistent in its behavior.

Modularity is closely related to Polymorphism, which enables objects of different classes to be treated as objects of a common superclass. By treating different objects as instances of the same class or interface, we can add new types without modifying existing code. For example, the Shape interface could allow the addition of new shapes (like Rectangle or Triangle) without altering the code for existing shapes.

Finally, Reusability directly connects with Inheritance, as inheritance allows one class to inherit properties and behaviors from another, making it easier to reuse and extend code. For instance, a Bird class could serve as a parent for Parrot and Eagle classes, where the child classes inherit common attributes like wingspan and methods like fly().

This blog post helped me understand how these design principles connect to each other. The assignment’s focus on defining the OOD principles and understanding their importance has deepened my appreciation for Abstraction and Encapsulation as tools for simplifying and protecting code. I now feel more confident in applying these principles to make my software designs both flexible and maintainable.

This blog post made me understand how it all connects. I now have a clearer understanding of how to approach system design in a more structured and efficient way. By focusing on Reusability and Simplicity, I’ll be able to write code that is easier to maintain and scale over time.

Link to the Resource:
Four Design Principles by Ivan Brygar

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

Hello everyone

For this week’s blog topic, I will talk about clean code. This was one of my favorite topics that we have discussed in class so far.  Even before, I knew that writing good code is important, but I was unsure on how clean code was written. So far I had an idea, from doing exercises, solving problems and writing my own projects either for school or for fun. I thought my code was good enough that it would pass Uncle Bob’s test of clean code, but after reviewing again through his perspective it definitely does not pass as it needs a lot of improvement. Clean code is extremely significant as also stated by the author of the blog, writing code may take up 10% of a programmer’s time while reading and understanding code occupies the remaining 90%. In the blog, the author mentioned how this is even more accurate as in an open-source project like his, where external contributions can be done. The code needs to be clean enough, so the contributors can easily understand and spent most of their time writing code to add to the project. If the code was written poorly, it would make the experience of the contributor a nightmare as he would spend double of his time just reading and understanding, which would leave barely any time to add any new features. If the project goes to be used by multiple users, bugs would eventually pop up and fixing them in a timely manner when the code is a mess it would be very annoying. Even adding new features, it would be extremely time-consuming as you have to do twice the work if the code was written good. This is one of the reasons why I chose this blog from the rest.  The author emphasizes the real problems that come with writing bad code and how much it will cost you time wise to maintain your project up and running. 

Later on the blog, the author points out the importance of functions and formatting. These are two simple things that anyone can learn and apply it to any of their work. 

Some key points that I wrote down for myself were that functions should be kept small and compact. The principle states that small functions increases clarity and reduces clutter. It makes it easy on the eye as it scrolls through the code, knowing what the function does and where it is used in an instance. The second point he mentioned was both vertical and horizontal formatting. He compared it to the Newspaper Metaphor, which it suggested that code should present key information at the top. It is also important to create vertical spaces between different functions which allows separations, and creating a format which is followed throughout the rest of the project. 

Horizontal formatting focuses more on maintaining manageable line lengths. We don’t want the lines of code to be too long, and they should be viewing compatible for every screen size. It is not recommended and always avoided scrolling horizontally in your code as it can become annoying over time and time-consuming. This code in a way was a reflection of my journey towards Clean Code. I had similar mistakes that I did in that past not knowing how to write clean code, but after reading more about it now I am capable of writing clean code. This is a valuable skill that my future self will thank me for mastering!

https://medium.com/codex/reading-clean-code-week-2-643641e4dc28

From the blog CS@Worcester – Site Title by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

The article “What to Expect From Agile” by Julian Birkinshaw talks about how agile management, which started in software development, is now being used in other industries. It uses ING Bank in the Netherlands as an example to show how agile principles can change a whole organization. ING started its transformation in 2015 to deal with problems like too much bureaucracy and separate departments that didn’t work well together.

Summary

Agile is a method that focuses on being flexible, working together, and improving things little by little. ING decided to use it to make their operations more efficient, inspired by companies like Spotify and Google. They made big changes, like reorganizing their teams into smaller groups called “squads” that handle tasks from start to finish and larger groups called “tribes” that focus on similar goals.

Here are the key things ING learned during this change:

1. Shifting Power: Managers gave up some control to allow teams closer to customers to make decisions. This led to a big culture shift, and some senior managers left because they didn’t fit this new way of working.
2. Keeping Stakeholders Involved: ING worked with regulators and other important groups to show that agile could work while still keeping important rules in place.
3. Focusing on Customers: Teams were organized based on what customers needed and could adapt their focus as those needs changed.
4. Balancing Freedom and Structure: ING used quarterly business reviews to set goals and stay on track while letting teams decide how to get things done.
5. Helping Employees Grow: Agile gave employees more opportunities to learn new skills and take on exciting challenges.

The results were positive: employees felt more engaged, customers were happier, and the bank saved money.

Reflection

What stands out to me the most is how agile balances giving teams freedom while still making sure they’re working toward the company’s goals. It’s not easy to find that balance, especially for industries like banking, where following rules is really important. It also impressed me how ING’s leaders had to let go of control and trust their teams to make decisions. That takes a lot of courage!

As a computer science and business administration student, I see how this case connects both of my fields. Agile started as a software development idea, but it’s now shaping how businesses are managed. If I were in a workplace like this, I’d like having the freedom agile offers, but I’d also want clear support systems to stay on track and make sure we’re meeting goals.

Citation

Birkinshaw, Julian. “What to Expect From Agile.” MIT Sloan Management Review, December 11, 2017.

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

This week, I read the informative post “How to Write Clean Code” from the freeCodeCamp blog. A thorough review of best practices for creating clear, manageable, and effective code was provided in the article. As I work to improve my software development abilities, this website has been really helpful in helping me better grasp clean code concepts. I selected this article because it immediately aligns with the course objectives, which prioritize process-oriented thinking and strong programming methods. Professional software development requires clean code, and becoming proficient in it supports the larger goal of becoming a skilled developer who can contribute successfully to group projects !! The article introduces the concept of clean code, which is described as code that is simple, transparent, and free of excessive detail. It covers specific activities, such as assigning descriptive and informative names to variables, functions, and classes. Creating functions that serve a specific, distinct purpose. Combining repeated logic for easy maintenance. Writing self-explanatory code and reserving comments for complex logic or critical context will help you avoid using unneeded ones. Use rigorous unit tests to ensure that the code works as intended. As a brief aside, the author emphasizes the need of developing these techniques into routines and incorporating them into daily coding operations. I realized after reading this post how frequently I ignore little but important details of code quality. For example, I have been guilty of using vague variable names like temp or data when my code would be easier to comprehend with more descriptive names. I found that developing large, multi-task functions makes debugging a headache, thus the remark about writing tiny, single-purpose functions caught my attention. I was able to relate clean code techniques to more general course ideas thanks to this resource. The concept of removing duplication, for instance, is closely related to software design concepts like DRY (Don’t Repeat Yourself), which we have covered in class. Similar to this, the emphasis on meaningful names is in line with our goal of communicating clearly, both when writing code and when recording procedures. In the future, I plan to apply what I’ve learned by revising my code to ensure that functions are clear and effective. Using descriptive terminology to improve text readability. Unit testing should be prioritized in order to identify and resolve issues early in the development cycle. These changes should make it easier for me to stick to my own responsibilities and contribute more consistently to group projects. My experience with clean coding will also be useful in real-world scenarios where teamwork requires efficiency and clarity. This article served as a helpful reminder of how crucial clean coding techniques are to meeting industry standards for software development. As I progress through this course, I’ll make an effort to incorporate these ideas into my workflow so that the code I write is not just useful but also readable and manageable.

Cocca, G. (2024, September 11). How to write Clean Code – Tips and Best Practices (Full Handbook). freeCodeCamp.org. https://www.freecodecamp.org/news/how-to-write-clean-code/

From the blog CS@Worcester – Just A Girl in STEM by Joy Kimani and used with permission of the author. All other rights reserved by the author.

Hello, this is my second topic-based blog and today I will be talking about something I learnt about in depth over several days in my Software Process Management class. This was a very interesting topic and I learned a lot of things about code that I had previously not known about. Some of the things that I was taught in my earlier days of coding were proven to not be the best way to go about making organized, clear code. One example of this is that I was originally taught to make comments after most lines of code, just to make sure everyone reading the code will understand it. However, it turns out this was just a beginner step to help myself learn. In reality, clean code should be easy to read and understand, making many comments obsolete.

Now I will talk about some examples of obsolete comments. One of these are redundant comments. These are comments that are unnecessary. An example of this would be: z = x + y (sets z to the sum of x and y). As you can see, the code speaks for itself, and this comment is completely obsolete. Another comment type that is unnecessary would be misleading comments. These comments are usually created when someone forgets about a comment after updating the code. This leads to the wrong comment being on a block of code that doesn’t even do what that comment states!

The blog I researched for this post is linked here: Writing Clean Code: Tips and Best Practices – DEV Community

Unsurprisingly, this blog shared many of the same values that I learnt about in class. It gave me an overview of the material I had gotten an in-depth understanding of, with many additional helpful tips and tricks. This blog mentioned using meaningful names for your classes, functions, methods, and variables. This ensures that someone else who is reading your code can easily understand EXACTLY what everything is used for. Ex) “bananas VS. bananasInBasket”

Another thing that this blog shared with what I learnt about is to make sure functions and methods are small and limited to a specific number of lines. You don’t want an entire code that may be repeated inside one method. Instead, create a function that you can call inside the method to keep the code clean.

The website also mentioned good practices for making comments, and to make sure you refactor your code a lot over time!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Hello Debug Ducker here, and today this piece will be a bit different. I want to share my opinions and others about on a somewhat controversial figure in the coding community. Robert Cecil Martin also known as Uncle Bob is a well-known software engineer. He is known for many things such as the subject to today’s topic, “Clean Code” a book written by him that discusses and shares what clean code is. it offers advice on how to structure and write code for it to be “clean”.

From my experience from reading excerpts from the book and trying some of his advice on an old project of mine, I have found that it has made the code a lot more readable. However there is some advice that I don’t agree with. To paraphrase, Uncle Bob mentions that a function should avoid having more than one argument or have none at all. He saw that the more arguments, the less clear it is. I understand what he means but personality I feel this may not apply to all cases when writing code, especially if you need multiple arguments to achieve something, so the advice is situational. It made me curious to do a bit of research myself on what others may think of his advice, and I found an article that shares similar sentiments about the advice given by Uncle Bob.

The blog is from a username qntm, who is a novelist but also a programmer. The blog entry is called “It’s probably time to stop recommending Clean Code”, and as the name may suggest, is an opinionated piece on the book of the same name by Uncle Bob. The blog entry had critiques about the book, such as the advice from Uncle Bob that said functions should only be about 3–4 lines. The user qntm found this bizarre, and frankly, I did too as I find this very restrictive for making functions.

That is just one of the many examples from the blog entry, and I would advise you to check the blog yourself to read the full thing. I’ll provide a link below and perhaps search for his other entries as well. I wanted to show you this because the definition of clean code perhaps can’t be defined by one person. Though I have found some of Uncle Bob advice to be helpful, I don’t think all of it should be taken as gospel. Apply his teachings where it may help and perhaps consider finding other ideas of clean code elsewhere because Robert is just one man who wanted to share some advice, I am sure others have different ideas that may help you as well.

Here is the blog entry by qntm about the subject for those curious

It’s probably time to stop recommending Clean Code. Things Of Interest @ Things Of Interest. (2020, November 28). https://qntm.org/clean

Martin, R. C. (2016). Clean code Robert C. Martin. Addison-Wesley Professional.

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Intro

Have you ever forked a respository without looking at its software license? It’s easy for developers to unintentionally violate licenses, especially if they aren’t informed about what they are, leading to potential legal troubles. This blog post by Fernando Galano breaks down the complexities of software licensing, providing clarity on a topic that is often overlooked, but is vital for anyone involved in software development.

Summary of Source

The blog post explores the concept of software licensing, covering its purpose, types, and implications.

1. What is a Software License?: An explanation of how licenses define the terms under which software can be used, modified, and distributed.
2. Types of Licenses: An overview of open-source and proprietary licenses, including popular ones like the GNU General Public License (GPL), MIT License, and Apache License. It also explains what a copyleft license is as well as what a permissive license is.
3. Why Licensing Matters: A discussion of how licensing affects collaboration, compliance, and intellectual property rights. It describes the benefits of licensing from the standpoint of both developers and users.
4. Best Practices for Choosing and Using Licenses: Practical tips for selecting appropriate licenses for projects and understanding license compatibility.

The blog is an introductory resource for open-source software usage and distribution. It doesn’t go into excruciating detail, with pages upon pages of technical terms, but it does cover the basics and anyone interested in furthering their knowledge on software licenses should explore more sources.

Why I Chose This Blog

I chose this blog because it addresses a topic that is often overlooked in technical coursework but is integral to professional software development. As I aspire to work as a software developer, understanding licensing will help me avoid legal complications and help my work be protected. The blog’s concise explanations and practical examples make it an ideal resource for building foundational knowledge in this area.

Reflection of Source

The blog post provided a clear and structured overview of software licensing, breaking down confusing legal jargon into digestible information. One aspect that particularly stood out to me was the explanation of the differences between permissive and copyleft licenses. For instance, I now understand how the MIT License offers flexibility by allowing modification and redistribution with minimal restrictions, while the GPL ensures that derivative works remain open-source. Reading about software licenses makes me realize how easy it is to unintentionally violate licensing terms due to a lack of awareness. Before learning about licenses I had never even considered that I might be violating the original creators intentions when deriving their work. This blog has made me more vigilant about understanding and respecting licensing terms, ensuring that my future projects remain legally sound.

Future Application

As I move forward in my career, the knowledge gained about licenses will shape how I approach software usage and distribution. When contributing to open-source projects, I will carefully evaluate license terms to make sure it aligns with my goals. Also, while working professionally, I’ll advocate for the proper review of licensing agreements to prevent legal risks. This understanding also allows me to choose the right license when publishing my own work, depending on the terms I would like others to follow. By adhering to licensing norms, I aim to contribute to a more ethical and collaborative development environment.

Citation

Understanding Software Licensing by Fernando Galano https://www.bairesdev.com/blog/understanding-software-licensing/.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.