WebStorm Shortcuts

Before I started using WebStorm for my TypeScript project, I mainly used Microsoft Visual Studio or Eclipse. Sometimes you really take for granted being able to quickly perform certain actions using shortcuts for a specific IDE. While I could have continued to use Visual Studio for TypeScript, I figured it would be best to work with WebStorm given that my professor was using it. If I ran into a Visual Studio specific problem, he wouldn’t be able to help me, so to save any potential headache I decided against using it.

Of course, it’s not like WebStorm doesn’t have its own shortcuts. In fact, I found myself instinctively using shortcuts from Visual Studio that also ended up working in WebStorm, such as the comment shortcut (Ctrl+/). Knowing these shortcuts will likely save me time in the future, so I set out to find a list of useful WebStorm shortcuts.

10 WebStorm Shortcuts You Need to Know

In the JetBrains blog 10 WebStorm Shortcuts You Need to Know, Ekaterina Prigara shares a list of the essential shortcuts that everyone should try:

  • Search everywhere: Shift+Shift
  • Navigate to declaration: Ctrl+B or Ctrl+Click
  • Code completion with replace: Tab
  • Show intention actions: Alt+Enter
  • Extend selection: Ctrl+W
  • Run: Alt+Shift+F10
  • Expand Live template: Tab
  • Multiple cursors: Alt+Click
  • New Scratch file: Ctrl+Alt+Shift+Insert
  • Refactor: Alt+Control+Shift+T

Under each command she provided an explanation of the shortcut as well as a very useful visual of the command in action. She also provides a useful resource containing a list of all the WebStorm shortcuts for OS X, Windows, and Linux located here.

I hadn’t known about the majority of these commands. The “Code completion with replace” command is particularly useful because I recall auto-completing code while trying to replace a variable and ending up with both the new and original variables. “Multiple cursors” is one of the more interesting commands in my opinion. Being able to type the same code in multiple places at once, while pretty situational, would have been able to save me a lot of time, particularly on the HTML of some of my components. Also, Scratch files are a great idea that I had no idea even existed. Being able to create code samples or make notes directly in the IDE without affecting the rest of the project is a godsend. Not only that, but the Scratch files are saved in WebStorm if I need them later.

These commands, as well as the commands found on WebStorm’s key map reference card, are probably going to save me a lot of valuable time in the future, so it’s important to learn them as early as possible when using a new IDE.

Source: https://blog.jetbrains.com/webstorm/2015/06/10-webstorm-shortcuts-you-need-to-know/


Positioning in CSS

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?

Oh no! What happened?


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 course CS248 is positioned 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.

The course CS248 is positioned relative to the schedule, its parent element.

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

HTML Elements and Semantics

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/

Benefits of Using Angular and TypeScript

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/


Common TypeScript Error Messages

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.


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/

Flaky Tests

Flaky tests are tests that could pass or fail for the same code. This is a problem because the failure of a flaky test doesn’t always indicate a problem with the code, but you can’t just ignore the test because you could be ignoring a bug.

In the the blog post “Where do our flaky tests come from?”, Jeff Listfield, a Senior Software Engineer at Google, talks about the the potential causes of flaky tests and what can be done to avoid creating flaky tests. He demonstrates the correlation between the objective size of the test (binary size, memory usage) and the likelihood for it to be flaky. He also shows a correlation between certain tools and a higher rate of flaky tests, however, the reason for this is because larger tests are more commonly written using those tools. The tools themselves only contribute a small amount to the likelihood of a flaky test being created. When writing tests you should think about what code that you are testing and what a minimal test would look like in order to minimize the likelihood of creating a flaky test.

I chose this topic because effective use of test cases is very important in software development because it allows you to make sure that you’ve addressed and tested all of the product requirements, allows future testers to run your test cases when needed, and also makes it possible to build automated scripts to run as many tests as possible. By writing your test cases out, you also won’t need to constantly repeat the process and remember what values you’re testing every time as they’ll already contain all necessary variables, allowing you to maintain consistency in your tests.

This blog post in particular was interesting because it uses data gathered from real tests used in Google’s continuous integration system to show a cause of flaky tests and how to avoid them. Before reading this blog I didn’t realize how important writing test cases really was, but seeing just how many automated tests that Google used (4.2 million!) which lead to me doing more research on their importance. It also reminded me that the best solution is usually the simplest, in that you should remember to keep your test cases as simple as possible to avoid creating a flaky test and giving you a headache in the future trying to figure out what’s wrong.

Source: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html