Category Archives: Week 4

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

On the subject of using Simple Factories…

This week, I am going to discuss the function and design of a Simple Factory pattern in Object Oriented Programming. At a very high level, this allows a programmer to centralize and encapsulate instance creation functionality into one class, as opposed to having many different classes (or your main class) depend on a large number of different classes. In my opinion, this is particularly useful when designing code that uses the strategy design pattern, as there will be objects for every concrete strategy, and many dependencies will be created. It is much easier (in at least those instances) to encapsulate all of those dependencies and creations into one class, a factory, and have that factory be dependent on all of the classes instead.

These principles are highlighted well in this blog, which provides a use case to demonstrate the usefulness of a factory. In this post, the example used is an implementation of a creature factory (admittedly less cool than a duck factory). Before implementing a simple factory, the main class is responsible to create and instantiate different creatures, and they can be created from anywhere in the code. This works, but is poorly designed, as we have discussed in class. Any time you want to make a change to the way a creature functions, for example, you might have to go edit the code in a ton of different places, and your UML diagram might just look atrocious. To address these design flaws, we can introduce the Simple Factory pattern, which centralizes creature creation logic into one dedicated class. This factory handles the instantiation of various creature types, simplifying our main class instead of scattering creation logic throughout the code. Whenever we need a creature, we call a method on the factory, which returns an instance of the requested object.

The blog example creates a CreatureFactory class with a method create(CreatureType type), which accepts the desired creature type. Inside this method, we use a conditional statement to return the appropriate creature object based on the input. For example, if we get WEREWOLF we instantiate a Werewolf object. If we want to add a new creature type, like Phoenix, we just create a new class for it and update the factory method. There’s no need to search through the entire codebase for instances where creatures are instantiated.

I admittedly don’t do a lot of object oriented programming, but the principle of using a factory makes perfect sense to me, and is something that I do and will continue to do going forward. Centralization of creation looks clean, performs clean, and makes sense. I didn’t really get into this, but it also may be extremely useful for OOP languages that do not have automatic memory management like Java does. You could also centralize the destruction of objects, possibly allowing for efficient tracking and memory allocation/deallocation.

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

On the subject of Licensing your Code…

This week, I am going to discuss the importance of licensing your code – something that I did not know was important until this week. The blog post I will be referencing can be found here. I chose it because it provides both a simple explanation of the importance of licensing and it explicitly describes the fallacy that causes most developers (myself included) to not license their code. The blog also references some of the same specific licenses we discussed in class, which (along with some research) indicated to me that there is a small set of very popular licenses that can serve a variety of purposes and target a variety of different intents and audiences.

After reading this blog post, reading others, looking at different open source projects on GitHub, and having discussions in class, the conclusion I’ve come to is this: the top reason people don’t license their code is because they don’t understand that licensing actually gives people more rights, not less. Many (again, my prior self included) likely think that if you just code something and throw it onto GitHub, that anybody can use it as open-source. This is not the case; that is actually incredibly restrictive, because you own the copyright to that work, and nobody can use that code without running into some legal barriers. Whether those barriers will ever be realized is another question, but not including a license may be enough to deter people from expanding on your work. A well-chosen license clearly communicates how others can use, modify, and distribute your work. This not only protects the rights of the original creator, but also allows others to expand on the work without the constant worry of stepping on legal toes. Licensing is better thought of as a way to invite others to engage with your code, rather than a barrier that restricts access.

The MIT License, to give an example, is concise and straightforward, allowing users to do almost anything with the code, as long as they include the original license and copyright notice. This simplicity has made it a favorite in the open-source community, encouraging collaboration and making it easier for developers to share their projects without too many legal constraints.

Understanding code licensing not only protects your work but also leads to a more collaborative and innovative development environment. Whether you want to encourage broad usage with an MIT license or ensure that your project remains open-source with a GPL, the right license can significantly impact how your code is shared and utilized. Moving forward, I plan to include licenses in any open source code I write. Though I never thought it was important before, I’ve learned now that it actually is critical if I want my code to actually be usable by others.

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

Diagrams and Code

The blog post I’ve chosen is all about PlantUML diagrams and how they can be used in ways to help your coding. The author writes about why diagrams can be useful for seeing things visually in a text heavy environment like coding is. There are many advantages to representing code in a diagram. Making the program abstract and only focusing on the process of how each thing should work with the others helps to focus on concepts rather than the implementation and actual workings of the code. There are also many types of diagrams, such as sequence diagrams that show what events take place over time, a use case diagram that shows what different levels of users are able to do, class diagrams that detail different objects’ construction, activity diagrams that can show workflow, and others. PlantUML is able to be used in many different ways for many different scenarios. There are sometimes problems that PlantUML cannot solve in the most elegant way, as the author describes, but there are alternatives and some problems that PlantUML was not designed to solve.

I think this blog was helpful to read through and see just how versatile PlantUML diagrams can be after learning about how to make them in class. Another benefit to diagrams that the blog didn’t go over, but we did in class was being able to find potential problems in the code before you even type anything which can save a lot of time. I think that using UML diagrams more often can help me with coding as having a diagram that gives me a top-down view would be helpful to look at instead of scrolling through a wall of text to find what I need to do next or how I can improve my code. I sometimes find that I can overcomplicate some sections of my code and having a written out simplified plan to look back at will help me code with more focus and also help with encapsulation which I don’t do as often as I should.

After reading this blog I will be more aware of what situations could be helped with a PlantUML diagram and make one to keep me focused on the structure and entire scope of the program. There are also ways to use diagrams in order to show processes that I haven’t used yet or have talked about in other classes which could be a good tool to use in the future to explain and show complex abstract processes.

PlantUML Diagrams – Matt Hayes

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

UML Diagrams: Use-Case, Activity, and Deployment

Link to blog: https://developer.ibm.com/articles/an-introduction-to-uml/

To start off the new semester and new course, we’ve been learning, discussing, and practicing with UML diagrams, or Unified Modeling Language diagrams. These diagrams are great ways for software developers and companies to visualize the structure of programs, large or small. There are many different types of diagrams, and we’ve mainly covered Class Diagrams and Sequence diagrams. 

Although I am unsure about the popularity and usage of UML diagrams in professional environments, I believe they can be beneficial to the organization and cleanliness of a team’s code, for it is to be written after it has already been structured and designed. The article I chose today is one by Donald Bell on IBM, and it discusses a few types of UML diagrams with some background information on each.

Bell introduces a new topic to the audience as well as anyone should: with some background information. He states the creation of UML was to model computer applications and ensure that anyone who understands UML diagrams can efficiently, accurately, and productively contribute to the project. 

The first UML diagram covered is the Use-Case diagram. Such diagrams are utilized to help readers understand the interaction between the program and its users. There can be many Use-Case diagrams for one program, but they are more so used to highlight the essentials. Bell describes how to create this type of diagram so that it is easy to understand.

The second UML diagram covered is the Activity Diagram, which shows “the procedural flow of control between two or more class objects while processing an activity” (Bell). Bell believes the best-case scenario for this type of diagram is for more business-oriented visualizations, such as how a company wants to operate at a higher level. These types of diagrams are not as technical as other diagrams which makes it easier to understand for non-programmers (Bell).

The last UML diagram Bell covers is the Deployment Diagram, which shows the physical representation of a software system. This would mean user computers, databases, websites, etc.

I selected this article because it covers a few UML diagrams that we haven’t discussed in class, and it is important for software developers to have some UML proficiency.  This would be a beneficial skill to have at a new job, so you might understand the codebase faster. IBM is also a very credible company in the software industry which is why I chose an article from their website.

The content of the resource was presented in an understandable way for someone with a little bit of software knowledge. I enjoyed learning about the background of UML and its creation, along with the three types of UML diagrams that were listed and described. I hope to use such knowledge at a new job that may use UML diagrams so I could provide more productivity in a shorter time rather than taking too much time trying to understand the codebase.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches Individual Apprenticeship Pattern

This week I continued to read about Individual Apprenticeship Patterns for CS448 – Capstone and focused on the “Stay in the Trenches” pattern. This pattern emphasizes the importance of gaining continuous hands-on, practical experience in the craftsman’s chosen field(s) at all levels, even as they may advance within a company. It can be common as software developers move up to transition to more managerial roles focusing on handling teams and deadlines rather than hands-on coding.

However, doing so will inevitably and quickly result in deterioration of the craftsman’s coding skills. Instead of getting too caught up in theoretical knowledge or managerial roles early (or at any point) in a developer’s career, developers should ‘stay in the trenches’ and continue working on practical/coding problems to keep developing and advancing skills and expertise. By immersing ourselves in the actual work, we’ll learn from the day to day experiences and continue to grow in ways that upper level managers often cannot. 

Often, I’ve heard of upper level software managers spending most of their time on coordination, time/schedule management and strategy/design planning – from a craftsman’s standpoint, only code project strategy and design planning are particularly applicable. While it surely is far more abstract and long-term or larger in scale, developers who are working hands-on with code are still managing and accomplishing tasks and exercising their code strategy and design skills. So when considering that hands-on coders will also further several other skills related to their craft, these managerial roles seem like a clear downgrade in terms of job quality and day to day activities even if it comes with a pay increase.

This brings up the final major point of this pattern, which really stuck out to me – identifying other avenues and ways for craftsmen to advance within their company/career and be rewarded for high-quality performance. Some practical examples could include a simple pay increase, more involvement in internal strategy meetings/decisions, job-title shift/improvement, etc. There’s no clear or definite answer here, but individuals in this position are probably in good standing as the company is looking to reward them, and they should communicate and work with company management to find incentives and reward mechanisms that align with the goals of both parties. If not however, this pattern stresses the importance of staying on the craftsman’s path and considering advancement positions at other companies that are more flexible.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.