Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.

Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

• static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
• relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
• absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
• fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.

Source: http://blog.teamtreehouse.com/css-positioning

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.

Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

• static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
• relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
• absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
• fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.

Source: http://blog.teamtreehouse.com/css-positioning

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

In the second lesson of Shay Howe’s HTML and CSS tutorial, he begins going in more depth about HTML by showing which HTML elements are best used to display different types of content, how they’re visually displayed on a web page, as well as what different elements mean semantically.

Throughout the tutorial, Howe describes several different HTML elements and explains what their purpose is. He also displays a live demo of his examples which is very useful in understanding exactly what each element looks like visually. The list of elements that he describes and their purposes are as follows:

• <div>: division – a block-level element that is commonly used to identify large groupings of content; helps to build a web page’s layout and design.
• <span> – an inline-level element commonly used to identify smaller groupings of text within a block-level element.
• <h1-h6>: heading – block-level elements with six different levels. These help to quickly break up content and establish hierarchy.
• <p>: paragraph – blocks of text visually separated from adjacent blocks (i.e. vertical blank space, first-line indentation, etc.)
• <b>: bold – stylistically offsets text.
• <strong> – places a strong importance on text by bolding it.
• <i>: italicize – conveys text in an alternative voice or tone by slanting it.
• <em>: emphasis – places a stressed emphasis on text.

HTML5 introduced new structurally based elements in order to give meaning to the organization of our pages and improve structural semantics:

• <header> – used to identify the top of a page, article, section, etc.
• <nav>: navigation – identifies a section of major navigational links on a page.
• <article> – used to identify a section of independent, self-contained content that may be independently distributed or reused.
• <section> – used to identify a thematic grouping of content, usually includes a heading.
• <aside> – holds content that is related to the main content around it, but not central to the flow of it.
• <footer> – identifies the closing or end of a page, article, section, etc.

Howe emphasizes the importance of understanding the semantic difference of elements. For example, even though the elements <strong> and <b> both create the same bold text effect, they’re semantically different. The <strong> element is used to give strong importance to text while the <b> element simply stylistically offsets text.

The reason I’m writing about this topic because it’s very relevant to our final project. Prior to reading this I hadn’t even considered the semantics of elements. Also it’s useful to understand how to use each element. In the future I’ll be able to use what I learned to better organize pages and improve its structural semantics. I’ll also be able to apply this to my final project, so this lesson has been very useful to me.

Source: https://learn.shayhowe.com/html-css/getting-to-know-html/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

In the second lesson of Shay Howe’s HTML and CSS tutorial, he begins going in more depth about HTML by showing which HTML elements are best used to display different types of content, how they’re visually displayed on a web page, as well as what different elements mean semantically.

Throughout the tutorial, Howe describes several different HTML elements and explains what their purpose is. He also displays a live demo of his examples which is very useful in understanding exactly what each element looks like visually. The list of elements that he describes and their purposes are as follows:

• <div>: division – a block-level element that is commonly used to identify large groupings of content; helps to build a web page’s layout and design.
• <span> – an inline-level element commonly used to identify smaller groupings of text within a block-level element.
• <h1-h6>: heading – block-level elements with six different levels. These help to quickly break up content and establish hierarchy.
• <p>: paragraph – blocks of text visually separated from adjacent blocks (i.e. vertical blank space, first-line indentation, etc.)
• <b>: bold – stylistically offsets text.
• <strong> – places a strong importance on text by bolding it.
• <i>: italicize – conveys text in an alternative voice or tone by slanting it.
• <em>: emphasis – places a stressed emphasis on text.

HTML5 introduced new structurally based elements in order to give meaning to the organization of our pages and improve structural semantics:

• <header> – used to identify the top of a page, article, section, etc.
• <nav>: navigation – identifies a section of major navigational links on a page.
• <article> – used to identify a section of independent, self-contained content that may be independently distributed or reused.
• <section> – used to identify a thematic grouping of content, usually includes a heading.
• <aside> – holds content that is related to the main content around it, but not central to the flow of it.
• <footer> – identifies the closing or end of a page, article, section, etc.

Howe emphasizes the importance of understanding the semantic difference of elements. For example, even though the elements <strong> and <b> both create the same bold text effect, they’re semantically different. The <strong> element is used to give strong importance to text while the <b> element simply stylistically offsets text.

The reason I’m writing about this topic because it’s very relevant to our final project. Prior to reading this I hadn’t even considered the semantics of elements. Also it’s useful to understand how to use each element. In the future I’ll be able to use what I learned to better organize pages and improve its structural semantics. I’ll also be able to apply this to my final project, so this lesson has been very useful to me.

Source: https://learn.shayhowe.com/html-css/getting-to-know-html/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

1. Consistency
2. Productivity
3. Maintainability
4. Modularity
5. Catch Errors Early

There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

1. Consistency
2. Productivity
3. Maintainability
4. Modularity
5. Catch Errors Early

There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

In the blog post Common TypeScript Error Messages, Sarah Higley provides examples of several common error messages in TypeScript and details how to fix them. The potential issues demonstrated are as follows:

• Type fails to narrow
• Flexibly typing objects
• Third-party libraries and ambient type declarations
• Conflicting function overloads
• <any> or as any

One of the more simple errors occurs when trying to assign a number to a unique type:

• Type ‘number’ is not assignable to type ‘Answer’.

In order to avoid this error, you must simply explicitly type it when its created

const answer: Answer = 42;

or cast it when it’s used.

const result: Answer = answer as Answer;

One of the more complicated errors and potentially more time-consuming to figure out involves a missing declaration file when using third-party libraries, from which not all will necessarily be written in TypeScript. The error looks something like this:

• Could not find a declaration file for module ‘moduleName’. ‘/path/to/moduleName/lib/api.js’ implicitly has an ‘any’ type.

This can be solved by finding the library you want to use and install it.

She also describes how the overuse of <any> could end up causing errors and that while type casting is powerful because it forces the compiler to interpret the value as the provided type, it’s dangerous because you will no longer see type errors when you missed something.

The reason I chose this particular resource because we’re going to be using TypeScript for our final project so it’ll be useful to know common TypeScript error messages and some of their potential solutions as it’s likely we’re going to be running into these errors in the near future.

As I haven’t done much programming at all in TypeScript yet, I wasn’t able to use this blog to solve any issues that I was running into. But if I were to run into any of these errors in the future, I would be able to save a lot of time compared to if it was my first time encountering the problem. Also, I learned how to cast variables, how to use index signatures and the pros and cons of using them (greater flexibility at the cost of reduced control), how to install third-party JavaScript libraries, how to avoid conflicting function overloads, and to avoid using <any> or “as any” for everything, because even though it could turn out fine there’s a high likelihood that something will end up breaking.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

In the blog post Common TypeScript Error Messages, Sarah Higley provides examples of several common error messages in TypeScript and details how to fix them. The potential issues demonstrated are as follows:

• Type fails to narrow
• Flexibly typing objects
• Third-party libraries and ambient type declarations
• Conflicting function overloads
• <any> or as any

One of the more simple errors occurs when trying to assign a number to a unique type:

• Type ‘number’ is not assignable to type ‘Answer’.

In order to avoid this error, you must simply explicitly type it when its created

const answer: Answer = 42;

or cast it when it’s used.

const result: Answer = answer as Answer;

One of the more complicated errors and potentially more time-consuming to figure out involves a missing declaration file when using third-party libraries, from which not all will necessarily be written in TypeScript. The error looks something like this:

• Could not find a declaration file for module ‘moduleName’. ‘/path/to/moduleName/lib/api.js’ implicitly has an ‘any’ type.

This can be solved by finding the library you want to use and install it.

She also describes how the overuse of <any> could end up causing errors and that while type casting is powerful because it forces the compiler to interpret the value as the provided type, it’s dangerous because you will no longer see type errors when you missed something.

The reason I chose this particular resource because we’re going to be using TypeScript for our final project so it’ll be useful to know common TypeScript error messages and some of their potential solutions as it’s likely we’re going to be running into these errors in the near future.

As I haven’t done much programming at all in TypeScript yet, I wasn’t able to use this blog to solve any issues that I was running into. But if I were to run into any of these errors in the future, I would be able to save a lot of time compared to if it was my first time encountering the problem. Also, I learned how to cast variables, how to use index signatures and the pros and cons of using them (greater flexibility at the cost of reduced control), how to install third-party JavaScript libraries, how to avoid conflicting function overloads, and to avoid using <any> or “as any” for everything, because even though it could turn out fine there’s a high likelihood that something will end up breaking.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

• Using one class which activates and deactivates different responses with flags
• Using inheritance
• Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.

Source: https://blog.codefx.org/design/patterns/decorator-pattern-saved-my-day/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

• Using one class which activates and deactivates different responses with flags
• Using inheritance
• Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.

Source: https://blog.codefx.org/design/patterns/decorator-pattern-saved-my-day/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.