Getting Better at Webstorm

Notes for myself:

  • Use the shortcut keys! 
    • Palua allows you to choose which applications to use the Function key vs Apple keys (Webstorm uses the function keys a lot) https://itunes.apple.com/us/app/palua/id431494195?mt=12
  • Install the shortcut reminder plug-in (displays shortcut alternatives whenever you use the mouse instead)
  • Use the terminal when possible inside webstorm
    • You can even create multiple tabs
  • Use Ctrl + Space a lot. You can use it to fuzzy find a relative path for a file reference. You can use it to find library attributes (might need to load it in first in the project).
  • Use Emmet abbreviations when you can. A few short ones, is better than one long one. Paraphrasing them!
    • http://docs.emmet.io/abbreviations/syntax/

Improving my workflow & productivity

  • Use source code analysis - Helps me focus on what areas to refactor and to pay attention to: https://github.com/es-analysis/plato
  • Better SCM CLI - SCM Breeze lets you use numbers: https://github.com/ndbroadbent/scm_breeze
  • Writing documentation - I think the key is to just a little bit of documentation here and there. constantly refactor it to keep it up to date.
  • Tmux / tmuxinator  - Use multiple terminal sessions in one window
  • Learn JetBrains shortcuts - Install the shortcut key plugin
  • Create shell scripts for dev install - Automates a tedious task
  • Email-jitsu - Focus on only reading the important emails... the inbox!
  • Store everything in a wiki - when it comes to project knowledge
  • Learn Regex
  • Append alias like crazy to .gitconfig and .zshrc - echo "alias list='ls -cl --group-directories-first'" >> config.fish
  • Copy to clipboard - https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pbcopy.1.html
  • Hash tag bash commands - the hash is treated as a comment
  • End cat early - One small trick: when you cat a large file carelessly, press Ctrl+S to stop displaying immediately. Then press Ctrl+C to stop the cat process.

ESLint

ESLint is a powerful Javascript linter that is more extensible than the more widely used JSLint and JSHint linters.

There's so many rules, and with very brief rule names - I found myself constantly needing to look up the definitions so I've created a boilerplate .eslintrc files that helps you get started with ESLint quickly. I have all the rules turned off so you can pick the ones to use. If you turn them all on, you're likely to be inundated with errors!

Generic ESLintrc sheet:

My personal ESLintrc sheet:


Open Source Licenses

There are many different types of licenses that open source projects use, so in this post I will cover the most common ones with the distinction of which ones you should be wary of using if you are interested in developing proprietary software using the open source project.

Licenses that you can not safely use for proprietary software:

  • GNU GPL
  • GNU LGPL
    • Some ambiguity of when you have to share your proprietary code. The wikipedia article discusses the distinction of statically vs dynamically linking the open source code: http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

Permissive licenses that you can safely use for proprietary software:

  • MIT license - Very short license with few restrictions http://en.wikipedia.org/wiki/MIT_License
  • Apache - http://en.wikipedia.org/wiki/Apache_License
  • BSD - https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html
  • ISC (Internet Software Consortium) - http://en.wikipedia.org/wiki/ISC_license; Functionally the same as MIT / BSD

Hybrid:

  • Mozilla Public License - The one major exception I found to the two categories is the Mozilla Public License which requires you to open source code files that are under the MPL, however your proprietary code doesn't need to be open-sourced. It's an interesting compromise between GPL and the permissive licenses listed above, however I fear that it may actually be a logistical headache to comply with.

Design principles

One of the things that I've decided to start working on is recognizing what makes certain designs good so I can start making some good designs.

After reading the sample chapters of several design-related ebooks on Amazon, I decided to buy this book called The Non-Designer's Design Book (4th edition) because it had a no-nonsense approach to explaining good design, supplemented with numerous visual and colorful examples.

The four principles that Robin Williams introduces are:

  • Contrast - Make things obviously different. Don't use a slightly different font. Make the fonts dramatically different if they have different purposes.
  • Repetition - Use certain things repeatedly. It goes hand in hand with the previous principle. If things aren't highly contrasted, then they should basically be the exact same. Slight differences is what throws the reader off.
  • Alignment - Make sure things are where they're supposed to be. Align things horizontally and vertically so nothing looks like it's just floating mistakenly.
  • Proximity - Put related things together. And space out unrelated things. Robin makes a big deal out of spacing numbers, bullets, etc next to words closely together so readers are not confused which symbol goes with which text.