Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Original Blog:https://blog.logrocket.com/solid-open-closed-principle/

For this post, I’ve decided to write about the application of the open-closed principle in programming, and how new features can be added to an existing piece of code without altering existing code. I’ll also be writing about the pitfalls of incorrectly using the Open-Closed principle in circumstances where it isn’t necessary or is excessive.

The Open-Closed principle is a principle in the SOLID foundation of principles, which is an acronym for the its tenants:

S – Single Responsibility

O – Open – Closed principle

L- Liskov Substitution Principle

I – Interference Segregation Principle

D – Dependency Inversion Principle

In the blog, “SOLID series: The Open – Closed Principle”, the author defines the open closed principle as dictating that a program be open for the addition of modules, classes and functions without changes to existing code being made. This can be done, among other methods, through the use of interfaces, which outlines which methods a class must implement without modifying the methods or class themselves, and abstract classes, which provide blueprints for future subclasses. By designing you program around the idea of shared methods within classes and inheritance, you ensure that bugs involving the code within those methods are few and far between. However, criticisms of OCP arise when the abstraction that results from repeated inheritance becomes cumbersome.

In the blog, the author states that many developers feel that the definition of the open-closed principle itself implies inheritance, leading some specific examples of improperly used OCP. The first one the author mentions is “Over engineered-abstractions”. This occurs when the amount of abstractions in a program is unnecessary, which could cause the program to become more complex than it needed to be. This can cause the codebase to become increasingly harder to understand to contributors, leading to possible bugs in the future of the program’s development. Another problem outlined by the author is the “interface explosion” problem. This happens when interfaces are overused in a codebase. The author mentions how the .net ecosystem suffers from this due to it’s reliance on dependency injection. When this is a problem, the codebase can become cluttered and dense.

In summary, the author explained the definition of the open-closed principle, then gave criticisms about the principle based on the environment in which they would be implemented, with inheritance and abstraction sometimes resulting in increase complexity and codebase clutter when implemented in environments that don’t necessarily need them. A thought I had about the material covered in the blog is how the use of the factory design pattern could help in cases of an “interface explosion”, since it would reduce dependencies required by the client for the code to function, and would reduce the amount of locations that would needed to be edited to add a new object of a certain type.

From the blog My first blog by Michael and used with permission of the author. All other rights reserved by the author.