This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” 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 figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

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

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” 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 figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

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

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” 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 figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

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

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” 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 figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

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

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” 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 figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

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

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” 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 figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

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

 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.

 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.

 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.

 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.