├── .editorconfig ├── Advanced-Git-Cheatsheet.md ├── Git-Flow.md ├── Google-Analytics-Referral-Spam.md ├── Heroku-Handson.md ├── Markdown-Cheatsheet.md ├── NPM-Install-on-windows.md ├── Node.js.md ├── README.md ├── dnsmasq.plist ├── principles-of-code-quality.md └── unix-screen-cheatsheet.md /.editorconfig: -------------------------------------------------------------------------------- 1 | # EditorConfig helps developers define and maintain consistent 2 | # coding styles between different editors and IDEs 3 | # editorconfig.org 4 | 5 | root = true 6 | 7 | [*] 8 | 9 | # Change these settings to your own preference 10 | indent_style = space 11 | indent_size = 2 12 | 13 | # We recommend you to keep these unchanged 14 | end_of_line = lf 15 | charset = utf-8 16 | trim_trailing_whitespace = true 17 | insert_final_newline = true 18 | 19 | [*.md] 20 | trim_trailing_whitespace = false 21 | indent_size = 4 22 | -------------------------------------------------------------------------------- /Advanced-Git-Cheatsheet.md: -------------------------------------------------------------------------------- 1 | # Advanced Git Cheatsheet 2 | 3 | ## Working with hub 4 | 5 | Install Github's command line utility [`hub`][hub]: 6 | 7 | #### On OSX: 8 | 9 | ```shell 10 | $ brew install hub 11 | ``` 12 | 13 | #### From source: 14 | 15 | ```shell 16 | $ git clone https://github.com/github/hub.git 17 | $ cd hub 18 | $ rake install prefix=/usr/local 19 | ``` 20 | 21 | ### Authorize hub 22 | 23 | You need to authorize hub with your Github account using an oAuth token, [follow the instructions illustrated in this comment to create the token and provide it to `hub`](https://github.com/github/hub/issues/491#issuecomment-35631300) 24 | 25 | ### Attaching Pull Requests to existing issues 26 | 27 | To attach a PR to an existing issue use the following command: 28 | 29 | #### When you work on a Fork 30 | 31 | ```shell 32 | $ hub pull-request -b USERNAME_OF_UPSTREAM_OWNER:UPSTREAM_BRANCH -h YOUR_USERNAME:YOUR_BRANCH URL_TO_ISSUE 33 | ``` 34 | 35 | #### When you work on the same repository 36 | 37 | ```shell 38 | hub pull-request -i 4 39 | ``` 40 | 41 | Where `-i 4` is the issue's id. 42 | 43 | Source: [Stackoverflow question](http://stackoverflow.com/questions/4528869/how-do-you-attach-a-new-pull-request-to-an-existing-issue-on-github). 44 | 45 | 46 | ## Remove folder from repo with history 47 | 48 | ```shell 49 | git filter-branch -f --tree-filter 'rm -rf folder/path' HEAD 50 | ``` 51 | 52 | [source blog post](http://dalibornasevic.com/posts/2-permanently-remove-files-and-folders-from-a-git-repository), [Stack Overflow](http://stackoverflow.com/questions/10067848/remove-folder-and-its-contents-from-git-githubs-history), [git-scm](http://git-scm.com/book/en/Git-Internals-Maintenance-and-Data-Recovery) 53 | 54 | ### Compact Git Repo 55 | 56 | After a `git filter-branch` you run the `git compact` command to remove empty directories from history. 57 | 58 | ```shell 59 | git gc --aggressive --prune=now 60 | ``` 61 | 62 | Source: [SO Question](http://stackoverflow.com/questions/2116778/reduce-git-repository-size). 63 | 64 | ## Move a folder to another repository with history 65 | 66 | ### From Source Repository 67 | 68 | ```shell 69 | git clone 70 | cd 71 | git remote rm origin 72 | git filter-branch --subdirectory-filter -- --all 73 | mkdir 74 | mv * 75 | git add . 76 | git commit 77 | ``` 78 | 79 | ### From Destination Repository 80 | 81 | ```shell 82 | git clone 83 | cd 84 | git remote add repo-A-branch 85 | git pull repo-A-branch master 86 | git remote rm repo-A-branch 87 | ``` 88 | 89 | [source blog post](http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/) 90 | 91 | ## Alternative and FASTER way to copy dir from repo to repo with history 92 | 93 | ```shell 94 | mkdir /tmp/mergepatchs 95 | cd ~/repo/org 96 | export reposrc=myfile.c #or mydir 97 | git format-patch -o /tmp/mergepatchs $(git log $reposrc|grep ^commit|tail -1|awk '{print $2}')^..HEAD $reposrc 98 | cd ~/repo/dest 99 | git am /tmp/mergepatchs/*.patch 100 | ``` 101 | [source](http://blog.neutrino.es/2012/git-copy-a-file-or-directory-from-another-repository-preserving-history/) 102 | 103 | 104 | [Github Flow]: http://scottchacon.com/2011/08/31/github-flow.html 105 | [hub]: http://hub.github.com/ 106 | -------------------------------------------------------------------------------- /Git-Flow.md: -------------------------------------------------------------------------------- 1 | # Git Flow 2 | 3 | ## General 4 | 5 | * For remote names use `origin` and `upstream` where it applies. 6 | 7 | ## Flow Overview 8 | 9 | Following the [Github Flow][] paradigm, in short: 10 | 11 | * Each developer creates a fork of the repository to their own account. 12 | * Names remotes: their own repository `origin` and the main repository `upstream`. 13 | * Creates a new branch out of `upstream/master` or target upstream branch. 14 | * Works on the branch doing [Atomic Commits](http://en.wikipedia.org/wiki/Atomic_commit). 15 | * Pushes to *origin* often. 16 | * When done performs a **Pull Request** to `upstream/master` or the target branch. 17 | * If an issue exists (like in most cases) then they are expected to attach the Pull Request onto that issue using [HUB][], [here's how to do it](Advanced-Git-Cheatsheet.md#working-with-hub). 18 | 19 | ### DO NOT 20 | 21 | * [DO NOT Squash your commits](http://thanpol.as/javascript/Dont-Squash-its-rude-and-a-lie/) 22 | 23 | ## Keeping up with master 24 | 25 | To keep up with the master of the original repo use `fetch`: 26 | 27 | ``` 28 | git fetch upstream 29 | ``` 30 | 31 | ### How to create the upstream remote 32 | 33 | The `upstream` remote refers to the repository that you want to send your Pull Request to. If you have write access on that repository then you don't need it. Otherwise you need to create it: 34 | 35 | ``` 36 | git remote add upstream [uri-of-repository] 37 | ``` 38 | 39 | ## Create a new fresh branch 40 | 41 | To create a new fresh branch from the original (upstream) master: 42 | 43 | ``` 44 | git checkout upstream/master -b new-local-branch 45 | ``` 46 | 47 | ## More Reading 48 | 49 | * [Github Flow][] 50 | * [Rolling back changes with revert](http://gitready.com/intermediate/2009/03/16/rolling-back-changes-with-revert.html) 51 | * [Gitmagic Git Complete Reference](http://www-cs-students.stanford.edu/~blynn/gitmagic/) 52 | 53 | [Github Flow]: http://scottchacon.com/2011/08/31/github-flow.html 54 | [HUB]: http://hub.github.com/ 55 | -------------------------------------------------------------------------------- /Google-Analytics-Referral-Spam.md: -------------------------------------------------------------------------------- 1 | How to tackle Google Analytics referral spam. 2 | 3 | 1. Go to the Admin page of your analytics. 4 | 1. On the 'View' tab on the right, click on 'View Settings'. 5 | 1. Find the "Bot Filtering" checkbox and check it, then save. 6 | 1. From the left sidebar go to the 'Filters' view. 7 | 1. Create new filters as illustrated bellow: 8 | 9 | ## Creating Filters 10 | 11 | All the filters we will create will be of **Type** "Custom" and **Field** "Campaign Source". We use the "Campaign Source" field because the "Referral" field will not do the job, it'll skew results and mixup bots with our general visitors. 12 | 13 | The "Filter Pattern" accepts up to 255 characters so we have to break out the filters in multiples: 14 | 15 | #### Referral Spam 1 16 | 17 | > .\*(trafficmonetizer|4webmasters|webmonetizer|dailyrank)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 18 | 19 | #### Referral Spam 2 20 | 21 | > .\*(success\\-seo|floating\\-share\\-buttons|social\\-buttons|simple\\-share\\-buttons|free\\-share\\-buttons|free\\-social\\-buttons|traffic2money|buttons\\-for\\-website)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 22 | 23 | #### Referral Spam 3 24 | 25 | > .\*(seo-platform|sexyali|get\\-free\\-social\\-traffic|qualitymarketzone|free\\-floating\\-buttons|bundlepost|chinese\\-amezon)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 26 | 27 | #### Referral Spam 4 28 | 29 | > .\*(event\\-tracking|Get\\-Free\\-Traffic\\-Now|videos\\-for\\-your\\-business|ranksonic|rankings\\-analytics|copyrightclaims)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 30 | 31 | #### Referral Spam 5 32 | 33 | > .\*(googlemare|quit\\-smoking|trafficgenius|2your.site|for\\-your|yeartwit|годом)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua|рф).\* 34 | 35 | #### Referral Spam 6 36 | 37 | > .\*(semalt|buttons\\-for\\-your\\-website|best\\-seo\\-solution|best\\-seo\\-offer|100dollars\\-seo|semaltmedia|video--production)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 38 | 39 | #### Referral Spam 7 40 | 41 | > .\*(blackhatworth|7makemoneyonline|ilovevitaly|priceg|prodvigator|resellerclub|savetubevideo|screentoolkit|kambasoft|socialseet|superiends|vodkoved|iskalko|luxup|myftpupload|websocial|ykecwqlixx)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 42 | 43 | #### Referral Spam 8 44 | 45 | > .\*(slftsdybbg|seoexperimenty|darodar|econom|edakgfvwql|adcash|adviceforum|hulfingtonpost|europages|gobongo|cenoval|cityadspix|cenokos|lomb|lumb|srecorder|see\\-your\\-website\\-here|76brighton)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 46 | 47 | #### Referral Spam 9 48 | 49 | > .\*(anticrawler|medispainstitute|offers\\.bycontext|sitevaluation|paparazzistudios|powitania|sharebutton|tasteidea|descargar\\-musica\\-gratis|torontoplumbinggroup|54\\.186\\.60\\.77|ekatalog)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 50 | 51 | #### Referral Spam 10 52 | 53 | > .\*(rankscanner|sharemyfile|justprofit|127\\.0\\.0\\.1|search\\-helper|dbutton|o00|wordpress\\-crew|fast\\-wordpress\\-start|top1\\-seo\\-service|uptimechecker|uptimebot)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 54 | 55 | #### Referral Spam Catchall 56 | 57 | This pattern was suggested by [Brian Clifton in this blog post](https://brianclifton.com/blog/2015/05/29/removing-referral-spam/). 58 | 59 | > offer|free\\-|share\\-|mercedes|buy|cheap|semalt|googlsucks|benz|sl500|hulfington|buttons| 60 | darodar|pistonheads|motor|money|blackhat|backlink|webrank|seo|phd| 61 | crawler|anonymous|\\d{3}.*forum|porn|webmaster|flipboard|fl\\.ru| 62 | mbca|ahrefs|game|^sex|^video 63 | 64 | #### Referral Spam 2016 65 | 66 | An update for 2016 67 | 68 | > .\*(website\\-analyzer|boost\\-my\\-site|traffic2cash|santasgift|o\\-o\\-8\\-o\\-o|snip)\\.(com|org|net|ml|tw|info|xyz|to|website|co|ru|ro|au|ua).\* 69 | 70 | 71 | ## More Reading 72 | 73 | * https://www.distilled.net/resources/quick-fix-for-referral-spam-in-google-analytics/ 74 | * http://www.optimizesmart.com/geek-guide-removing-referrer-spam-google-analytics/ 75 | -------------------------------------------------------------------------------- /Heroku-Handson.md: -------------------------------------------------------------------------------- 1 | # Heroku Node.js Hands On 2 | 3 | 4 | ## Get Setup with Heroku 5 | 6 | 1. [Signup](https://signup.heroku.com/signup/dc) for a Heroku account. 7 | 1. Install the [Heroku Toolbelt](https://toolbelt.heroku.com/) 8 | 1. Login using the CLI 9 | 10 | ```shell 11 | heroku login 12 | ``` 13 | 14 | ## Prepare a Node.js Project for Heroku 15 | 16 | ### Heroku and Random Listening Ports 17 | 18 | Due to the architecture or Heroku's Dynos the port number that the requests will be sent to is dynamically selected. Each new Dyno instance propagates the port number in the environment variable `PORT`, this is how to fetch it from within your Node.js Application: 19 | 20 | ```js 21 | var port = Number(process.env.PORT || 5000); 22 | ``` 23 | 24 | ### Create your Heroku application 25 | 26 | * Through the heroku manage panel (preferred) 27 | * From the command line: `heroku create` 28 | 29 | #### The Success modal 30 | 31 | ![The success view](http://than.pol.as/Vtph/Screen%20Shot%202014-06-04%20at%202.47.26%20PM.png) 32 | 33 | #### Get the git repository 34 | 35 | In our case `git@heroku.com:stub-test.git`, then: 36 | 37 | Add it as a remote to your current project: 38 | 39 | ```shell 40 | git remote add heroku git@heroku.com:stub-test.git 41 | ``` 42 | 43 | #### Setup Heroku boot 44 | 45 | In order for Heroku to know how it should boot up your application you need to create the `Procfile` at your project's root folder, here is a sample `Procfile`: 46 | 47 | ``` 48 | web: node . 49 | ``` 50 | 51 | #### First Deployment 52 | 53 | ...and every other deployment happens like that: 54 | 55 | ```shell 56 | git push heroku master 57 | ``` 58 | 59 | #### Power up your application 60 | 61 | This is required to kickstart your Heroku application, use only once. 62 | 63 | ```shell 64 | heroku ps:scale web=1 65 | ``` 66 | 67 | ## Installing Addons 68 | 69 | ### Redis To Go 70 | 71 | ```shell 72 | heroku addons:add redistogo 73 | ``` 74 | 75 | ### MongoLabs 76 | 77 | ```shell 78 | heroku addons:add mongolab 79 | ``` 80 | 81 | ## Tips & Tricks 82 | 83 | ### View logs 84 | 85 | ```shell 86 | heroku logs --tail 87 | ``` 88 | 89 | ### Setup Environment Variables 90 | 91 | ```shell 92 | heroku config:set NODE_ENV=heroku_staging 93 | ``` 94 | 95 | ### Export Sensitive Data to Heroku 96 | 97 | Check out [this Gist](https://gist.github.com/thanpolas/5bcb42e0ae1f34e6dc56) on how to export sensitive data (passwords, keys, tokens) to Heroku without having them tracked in your repository. 98 | 99 | 100 | ## Installing system-wide custom libraries 101 | 102 | If you want to install a system-wide custom library on the heroku platform you are pretty much screwed. But fear not, there is a way out. Heroku uses *Buildpacks* to setup your environment based on the language of your codebase. You can find all the [Heroku Buildpacks at their github organization](https://github.com/heroku/), they are opensource. 103 | 104 | With the help of the community, we are now able to mixin multiple buildpacks, this awesome feature is enabled by using the [heroku-buildpack-multi Buildpack](https://github.com/heroku/heroku-buildpack-multi), just declare that you wish to use the multi buildpack: 105 | 106 | ``` 107 | heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-multi.git 108 | ``` 109 | 110 | From then on, you need to define all the multiple buildpacks in the `.buildpacks` file: 111 | 112 | ``` 113 | $ cat .buildpacks 114 | https://github.com/heroku/heroku-buildpack-nodejs.git#0198c71daa8 115 | https://github.com/heroku/heroku-buildpack-ruby.git#v86 116 | ``` 117 | 118 | That way you can then search for your system-wide buildpack and include it in your `.buildpacks` file. For e.g. if you need the *Ffmpeg* library installed, search for a relevant buildpack on the web (or even better github) and just include it along with your system's offical Heroku buildpack: 119 | 120 | ``` 121 | $ cat .buildpacks 122 | https://github.com/HYPERHYPER/heroku-buildpack-ffmpeg.git 123 | https://github.com/heroku/heroku-buildpack-nodejs.git 124 | ``` 125 | 126 | Cha ching! 127 | 128 | ### Grunt build with Compass on Heroku 129 | 130 | The buildpack you need is [heroku-buildpack-nodejs-grunt-compass]( https://github.com/stephanmelzer/heroku-buildpack-nodejs-grunt-compass) by stephanmelzer. 131 | 132 | Buildpack git repo url: 133 | 134 | ``` 135 | https://github.com/stephanmelzer/heroku-buildpack-nodejs-grunt-compass.git 136 | ``` 137 | -------------------------------------------------------------------------------- /Markdown-Cheatsheet.md: -------------------------------------------------------------------------------- 1 | # Markdown CheatSheet 2 | 3 | This is intended as a quick reference and showcase. For more complete info, see [John Gruber's original spec](http://daringfireball.net/projects/markdown/) and the [Github-flavored Markdown info page](http://github.github.com/github-flavored-markdown/), this was forked from [Adam Pritchard's](https://github.com/adam-p/) [Markdown Here wiki page](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet). 4 | 5 | Note that there is also a [Cheatsheet specific to Markdown Here](./Markdown-Here-Cheatsheet) if that's what you're looking for. 6 | 7 | You can play around with Markdown on the [live demo page](http://www.markdown-here.com/livedemo.html). 8 | 9 | ## Table of Contents 10 | 11 | 1. [Creating Table of Contents](#tocs) 12 | 1. [Headers](#headers) 13 | 1. [Collapsible Sections](#collapse) 14 | 1. [Emphasis](#emphasis) 15 | 1. [Lists](#lists) 16 | 1. [Links](#links) 17 | 1. [Images](#images) 18 | 1. [Code and Syntax Highlighting](#code) 19 | 1. [Tables](#tables) 20 | 1. [Blockquotes](#blockquotes) 21 | 1. [Inline HTML](#html) 22 | 1. [Horizontal Rule](#hr) 23 | 1. [Line Breaks](#lines) 24 | 1. [Youtube videos](#videos) 25 | 26 | ## Creating Table of Contents 27 | 28 | ```no-highlight 29 | ## Table of Contents 30 | 31 | 1. [Creating Table of Contents](#tocs) 32 | 1. [Headers](#headers) 33 | 34 | ... 35 | 36 | ## Headers 37 | 38 | body 39 | 40 | **[⬆](#TOC)** 41 | ``` 42 | 43 | Lots going on here, as you notice we use the Anchor HTML element `a` for the header names, the `name` attribute is what we are going to use internally to create links inside the document. `` Once this is defined we can then create a link to point to that anchor using just the pount key like so: `[Go to TOCS](#tocs)`. 44 | 45 | ## Headers 46 | 47 | ```no-highlight 48 | # H1 49 | ## H2 50 | ### H3 51 | #### H4 52 | ##### H5 53 | ###### H6 54 | 55 | Alternatively, for H1 and H2, an underline-ish style: 56 | 57 | Alt-H1 58 | ====== 59 | 60 | Alt-H2 61 | ------ 62 | ``` 63 | 64 | # H1 65 | ## H2 66 | ### H3 67 | #### H4 68 | ##### H5 69 | ###### H6 70 | 71 | Alternatively, for H1 and H2, an underline-ish style: 72 | 73 | Alt-H1 74 | ====== 75 | 76 | Alt-H2 77 | ------ 78 | 79 | **[⬆](#TOC)** 80 | 81 | ## Collapsible Sections 82 | 83 |
84 | You can create collapsible sections [click me]. 85 | 86 |
87 | 88 | Hello 👋. 89 |
90 | 91 | Here is how: 92 | 93 | ```md 94 |
95 | You can create collapsible sections [click me]. 96 | 97 |
98 | 99 | Hello 👋. 100 |
101 | 102 | ``` 103 | 104 | **[⬆](#TOC)** 105 | 106 | ## Emphasis 107 | 108 | ```no-highlight 109 | Emphasis, aka italics, with *asterisks* or _underscores_. 110 | 111 | Strong emphasis, aka bold, with **asterisks** or __underscores__. 112 | 113 | Combined emphasis with **asterisks and _underscores_**. 114 | 115 | Strikethrough uses two tildes. ~~Scratch this.~~ 116 | ``` 117 | 118 | Emphasis, aka italics, with *asterisks* or _underscores_. 119 | 120 | Strong emphasis, aka bold, with **asterisks** or __underscores__. 121 | 122 | Combined emphasis with **asterisks and _underscores_**. 123 | 124 | Strikethrough uses two tildes. ~~Scratch this.~~ 125 | 126 | **[⬆](#TOC)** 127 | 128 | ## Lists 129 | 130 | (In this example, leading and trailing spaces are shown with with dots: ⋅) 131 | 132 | ```no-highlight 133 | 1. First ordered list item 134 | 2. Another item 135 | ⋅⋅* Unordered sub-list. 136 | 1. Actual numbers don't matter, just that it's a number 137 | ⋅⋅1. Ordered sub-list 138 | 4. And another item. 139 | 140 | ⋅⋅⋅You can have properly indented paragraphs within list items. Notice the blank line above, and the leading spaces (at least one, but we'll use three here to also align the raw Markdown). 141 | 142 | ⋅⋅⋅To have a line break without a paragraph, you will need to use two trailing spaces.⋅⋅ 143 | ⋅⋅⋅Note that this line is separate, but within the same paragraph.⋅⋅ 144 | ⋅⋅⋅(This is contrary to the typical GFM line break behaviour, where trailing spaces are not required.) 145 | 146 | * Unordered list can use asterisks 147 | - Or minuses 148 | + Or pluses 149 | ``` 150 | 151 | 1. First ordered list item 152 | 1. Another item 153 | * Unordered sub-list. 154 | 1. Actual numbers don't matter, just that it's a number 155 | 1. Ordered sub-list 156 | 1. And another item. 157 | 158 | You can have properly indented paragraphs within list items. Notice the blank line above, and the leading spaces (at least one, but we'll use three here to also align the raw Markdown). 159 | 160 | To have a line break without a paragraph, you will need to use two trailing spaces. 161 | Note that this line is separate, but within the same paragraph. 162 | (This is contrary to the typical GFM line break behaviour, where trailing spaces are not required.) 163 | 164 | * Unordered list can use asterisks 165 | - Or minuses 166 | + Or pluses 167 | 168 | **[⬆](#TOC)** 169 | 170 | ## Links 171 | 172 | There are two ways to create links. 173 | 174 | ```no-highlight 175 | [I'm an inline-style link](https://www.google.com) 176 | 177 | [I'm an inline-style link with title](https://www.google.com "Google's Homepage") 178 | 179 | [I'm a reference-style link][Arbitrary case-insensitive reference text] 180 | 181 | [I'm a relative reference to a repository file](../blob/master/LICENSE) 182 | 183 | [You can use numbers for reference-style link definitions][1] 184 | 185 | Or leave it empty and use the [link text itself] 186 | 187 | Some text to show that the reference links can follow later. 188 | 189 | [arbitrary case-insensitive reference text]: https://www.mozilla.org 190 | [1]: http://slashdot.org 191 | [link text itself]: http://www.reddit.com 192 | ``` 193 | 194 | [I'm an inline-style link](https://www.google.com) 195 | 196 | [I'm an inline-style link with title](https://www.google.com "Google's Homepage") 197 | 198 | [I'm a reference-style link][Arbitrary case-insensitive reference text] 199 | 200 | [I'm a relative reference to a repository file](../blob/master/LICENSE) 201 | 202 | [You can use numbers for reference-style link definitions][1] 203 | 204 | Or leave it empty and use the [link text itself] 205 | 206 | Some text to show that the reference links can follow later. 207 | 208 | [arbitrary case-insensitive reference text]: https://www.mozilla.org 209 | [1]: http://slashdot.org 210 | [link text itself]: http://www.reddit.com 211 | 212 | 213 | ## Images 214 | 215 | ```no-highlight 216 | Here's our logo (hover to see the title text): 217 | 218 | Inline-style: 219 | ![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 1") 220 | 221 | Reference-style: 222 | ![alt text][logo] 223 | 224 | [logo]: https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 2" 225 | ``` 226 | 227 | Here's our logo (hover to see the title text): 228 | 229 | Inline-style: 230 | ![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 1") 231 | 232 | Reference-style: 233 | ![alt text][logo] 234 | 235 | [logo]: https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 2" 236 | 237 | **[⬆](#TOC)** 238 | 239 | ## Code and Syntax Highlighting 240 | 241 | Code blocks are part of the Markdown spec, but syntax highlighting isn't. However, many renderers -- like Github's and *Markdown Here* -- support syntax highlighting. Which languages are supported and how those language names should be written will vary from renderer to renderer. *Markdown Here* supports highlighting for dozens of languages (and not-really-languages, like diffs and HTTP headers); to see the complete list, and how to write the language names, see the [highlight.js demo page](http://softwaremaniacs.org/media/soft/highlight/test.html). 242 | 243 | ```no-highlight 244 | Inline `code` has `back-ticks around` it. 245 | ``` 246 | 247 | Inline `code` has `back-ticks around` it. 248 | 249 | Blocks of code are either fenced by lines with three back-ticks ```, or are indented with four spaces. I recommend only using the fenced code blocks -- they're easier and only they support syntax highlighting. 250 | 251 | 
```javascript
252 | var s = "JavaScript syntax highlighting";
253 | alert(s);
254 | ```
255 | 
256 | ```python
257 | s = "Python syntax highlighting"
258 | print s
259 | ```
260 | 
261 | ```
262 | No language indicated, so no syntax highlighting.
263 | But let's throw in a <b>tag</b>.
264 | ```
265 |
266 | 267 | 268 | 269 | ```javascript 270 | var s = "JavaScript syntax highlighting"; 271 | alert(s); 272 | ``` 273 | 274 | ```python 275 | s = "Python syntax highlighting" 276 | print s 277 | ``` 278 | 279 | ``` 280 | No language indicated, so no syntax highlighting in Markdown Here (varies on Github). 281 | But let's throw in a tag. 282 | ``` 283 | 284 | **[⬆](#TOC)** 285 | 286 | ## Tables 287 | 288 | Tables aren't part of the core Markdown spec, but they are part of GFM and *Markdown Here* supports them. They are an easy way of adding tables to your email -- a task that would otherwise require copy-pasting from another application. 289 | 290 | ```no-highlight 291 | Colons can be used to align columns. 292 | 293 | | Tables | Are | Cool | 294 | | ------------- |:-------------:| -----:| 295 | | col 3 is | right-aligned | $1600 | 296 | | col 2 is | centered | $12 | 297 | | zebra stripes | are neat | $1 | 298 | 299 | The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown. 300 | 301 | Markdown | Less | Pretty 302 | --- | --- | --- 303 | *Still* | `renders` | **nicely** 304 | 1 | 2 | 3 305 | ``` 306 | 307 | Colons can be used to align columns. 308 | 309 | | Tables | Are | Cool | 310 | | ------------- |:-------------:| -----:| 311 | | col 3 is | right-aligned | $1600 | 312 | | col 2 is | centered | $12 | 313 | | zebra stripes | are neat | $1 | 314 | 315 | The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown. 316 | 317 | Markdown | Less | Pretty 318 | --- | --- | --- 319 | *Still* | `renders` | **nicely** 320 | 1 | 2 | 3 321 | 322 | **[⬆](#TOC)** 323 | 324 | ## Blockquotes 325 | 326 | ```no-highlight 327 | > Blockquotes are very handy in email to emulate reply text. 328 | > This line is part of the same quote. 329 | 330 | Quote break. 331 | 332 | > This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote. 333 | ``` 334 | 335 | > Blockquotes are very handy in email to emulate reply text. 336 | > This line is part of the same quote. 337 | 338 | Quote break. 339 | 340 | > This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote. 341 | 342 | **[⬆](#TOC)** 343 | 344 | ## Inline HTML 345 | 346 | You can also use raw HTML in your Markdown, and it'll mostly work pretty well. 347 | 348 | ```no-highlight 349 |
350 |
Definition list
351 |
Is something people use sometimes.
352 | 353 |
Markdown in HTML
354 |
Does *not* work **very** well. Use HTML tags.
355 |
356 | ``` 357 | 358 |
359 |
Definition list
360 |
Is something people use sometimes.
361 | 362 |
Markdown in HTML
363 |
Does *not* work **very** well. Use HTML tags.
364 |
365 | 366 | **[⬆](#TOC)** 367 | 368 | ## Horizontal Rule 369 | 370 | ``` 371 | Three or more... 372 | 373 | --- 374 | 375 | Hyphens 376 | 377 | *** 378 | 379 | Asterisks 380 | 381 | ___ 382 | 383 | Underscores 384 | ``` 385 | 386 | Three or more... 387 | 388 | --- 389 | 390 | Hyphens 391 | 392 | *** 393 | 394 | Asterisks 395 | 396 | ___ 397 | 398 | Underscores 399 | 400 | **[⬆](#TOC)** 401 | 402 | ## Line Breaks 403 | 404 | My basic recommendation for learning how line breaks work is to experiment and discover -- hit <Enter> once (i.e., insert one newline), then hit it twice (i.e., insert two newlines), see what happens. You'll soon learn to get what you want. "Markdown Toggle" is your friend. 405 | 406 | Here are some things to try out: 407 | 408 | ``` 409 | Here's a line for us to start with. 410 | 411 | This line is separated from the one above by two newlines, so it will be a *separate paragraph*. 412 | 413 | This line is also a separate paragraph, but... 414 | This line is only separated by a single newline, so it's a separate line in the *same paragraph*. 415 | ``` 416 | 417 | Here's a line for us to start with. 418 | 419 | This line is separated from the one above by two newlines, so it will be a *separate paragraph*. 420 | 421 | This line is also begins a separate paragraph, but... 422 | This line is only separated by a single newline, so it's a separate line in the *same paragraph*. 423 | 424 | (Technical note: *Markdown Here* uses GFM line breaks, so there's no need to use MD's two-space line breaks.) 425 | 426 | **[⬆](#TOC)** 427 | 428 | ## Youtube videos 429 | 430 | They can't be added directly but you can add an image with a link to the video like this: 431 | 432 | ```no-highlight 433 | IMAGE ALT TEXT HERE 436 | ``` 437 | 438 | Or, in pure Markdown, but losing the image sizing and border: 439 | 440 | ```no-highlight 441 | [![IMAGE ALT TEXT HERE](http://img.youtube.com/vi/YOUTUBE_VIDEO_ID_HERE/0.jpg)](http://www.youtube.com/watch?v=YOUTUBE_VIDEO_ID_HERE) 442 | ``` 443 | 444 | **[⬆](#TOC)** 445 | -------------------------------------------------------------------------------- /NPM-Install-on-windows.md: -------------------------------------------------------------------------------- 1 | 2 | This information was current as of May 6th 2016. 3 | 4 | ## Tips 5 | 6 | * On a virtualbox share your working folder so you can manage git and use your editor from osx. 7 | 8 | ## Install a node.js application on Windows 9 | 10 | 1. [Install node](https://nodejs.org/) 11 | 1. [Install git](https://git-scm.com/download/win) 12 | 1. [Install python](https://www.python.org/downloads/windows/) - [2.7.11 x86-64 MSI](https://www.python.org/ftp/python/2.7.11/python-2.7.11.amd64.msi) 13 | 1. Set PYTHON environment variable 14 | 1. Right click on "My Computer" and select "Properties" 15 | 1. Find and select "Advanced system settings" 16 | 1. Find and select "Environment Variables" 17 | 1. On the 'User variables' press the "New..." button 18 | 1. Variable Name: `PYTHON` Value: `C:\python27\python.exe` 19 | 1. Click "OK" all the way back. 20 | 1. Install Visual C++ Build Tools 2015 (link no longer exists) - [Complete solution here](https://github.com/nodejs/node-gyp/issues/629#issuecomment-153196245) 21 | * **Update 5/30/2016**: LOL, Microsoft decided to pull down the link to download the required runtime, hopefully I had a copy and uploaded on my personal store: http://than.pol.as/gJGq - hopefully I won't get sued by MS... 22 | * **IMPORTANT** Choose "Custom Install", and **select both Windows 8.1 and Windows 10 SDKs**. 23 | 1. Open CMD and type: `npm config set msvs_version 2015 --global` 24 | 25 | You are now ready to perform `npm install` on the project 26 | 27 | ### Troubleshooting 28 | 29 | 30 | > e:\app\node_modules\mdns\src\mdns.hpp(32): fatal error C1083: Cannot open include file: 'dns_sd.h': No such file or directory [E:\app\node_modules\mdns\build\dns_sd_bindings.vcxproj] 31 | 32 | To remedy this: 33 | 34 | 1. Download and install [Bonjour SDK for Windows](https://developer.apple.com/bonjour/). 35 | 2. Restart Windows 36 | 37 | [Source](https://github.com/agnat/node_mdns/issues/147#issuecomment-189191526) 38 | 39 | -------------------------------------------------------------------------------- /Node.js.md: -------------------------------------------------------------------------------- 1 | # Node.js Cheatsheet 2 | 3 | This is a collection of best practices, cheats and tips for doing safe sex with node.js, enjoy! 4 | 5 | ## Table of Contents 6 | 7 | 1. [Formatting](#formatting) 8 | 1. [Document Blocks](#docblocks) 9 | 1. [Module Dependencies](#modules) 10 | 1. [Module Format](#format) 11 | 12 | ## Formatting 13 | 14 | Thanks to recent developments in tooling, we no longer have to argue about formatting on node.js (or any javascript) project. The only thing you have to do is have the [prettier](https://prettier.io/) package installed on your editor. 15 | 16 | As, at this time (2021) the most popular editor is Visual Studio Code, to enable auto-formatting on save, you have to create the file `.vscode/settings.json` with the contents: 17 | 18 | ```json 19 | { 20 | "editor.formatOnSave": true, 21 | } 22 | ``` 23 | 24 | **[⬆](#TOC)** 25 | 26 | ## Document Blocks 27 | 28 | Every method, function, property should be documented with [JSDoc Tags][jsdoc]. 29 | 30 | ```js 31 | /** 32 | * Helper for default value of date types. 33 | * 34 | * @param {number} plusTime The time to add in miliseconds. 35 | * @return {number} The JS timestamp the future. 36 | */ 37 | exports.defaultDate = function(plusTime) { 38 | return Date.now() + plusTime; 39 | }; 40 | ``` 41 | 42 | **[⬆](#TOC)** 43 | 44 | ## Module Dependencies 45 | 46 | For the Node environment the following order of requiring modules is advised: 47 | 48 | 1. Require all core modules 49 | 1. Require all packages 50 | 1. Require all local modules 51 | 52 | Each separated by a new line and if possible order by lower to higher level in the stack. 53 | 54 | ```js 55 | // core modules 56 | const util = require('util'); 57 | 58 | // packages 59 | const __ = require('lodash'); // use double underscore for lodash 60 | const Promise = require('bluebird'); // lodash is lower in the stack than promises 61 | const express = require('express'); 62 | 63 | // local modules 64 | const userCtrl = require('./controllers/user.ctrl'); 65 | ``` 66 | 67 | > **Important**: All module dependencies must be declared on the top of the file, no exceptions. 68 | 69 | **[⬆](#TOC)** 70 | 71 | ## Module Format 72 | 73 | ### General Layout 74 | 75 | Each Node.js module should have the following structure: 76 | 77 | 1. Lines must not exceed 80 columns. Exceptions are markdown and markup files. 78 | 1. The `@fileoverview` tag at the top of the module, with a general description about what this module is about. 79 | 1. The module dependencies as described in [Module Dependencies](#modules). 80 | 1. Use only `exports.property` as a way of exporting. 81 | 1. Declare all static properties, functions, constants or enums right after the export statement. 82 | 1. Declare all public / exported methods 83 | 1. Declare all private methods 84 | 85 | Even *private* methods are defined on the exported object. 86 | 87 | ```js 88 | /** 89 | * @fileOverview The user Model. 90 | */ 91 | 92 | const util = require('util'); 93 | 94 | const __ = require('lodash'); 95 | const config = require('config'); 96 | const log = require('logg').getLogger('app.model.User'); 97 | 98 | const ModelMongo = require('./model-mongo'); 99 | const helpers = require('../util/helpers'); 100 | 101 | /** 102 | * The supported user roles. 103 | * 104 | * @enum {number} 105 | */ 106 | exports.Role = { 107 | API: 1, 108 | ADMIN: 2, 109 | }; 110 | 111 | /** 112 | * Pre-validation middleware. Set any default values. 113 | * 114 | * @param {function} next callback 115 | * @private 116 | */ 117 | exports._setDefaultValues = (next) => { 118 | next(); 119 | }; 120 | ``` 121 | **[⬆](#TOC)** 122 | 123 | [jsdoc]: https://jsdoc.app/ 124 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Practice 2 | 3 | A collection of best practices and cheat sheets. 4 | 5 | ## Best Practices 6 | 7 | * [Principles of Code Quality](principles-of-code-quality.md). 8 | * [Node.js](Node.js.md) 9 | 10 | 11 | ## Cheat Sheets 12 | 13 | * [Github Flow](Git-Flow.md) 14 | * [Advanced Git Cheatsheet](Advanced-Git-Cheatsheet.md) 15 | * [Markdown Cheatsheet](Markdown-Cheatsheet.md) 16 | * [Heroku Node.js Hands On](Heroku-Handson.md) 17 | * [Unix Screen Cheatsheet](unix-screen-cheatsheet.md) 18 | * [How to Setup stress-free SSL on OSX Dev Machine](https://gist.github.com/jed/6147872) 19 | * [A fixed for OSX Yosemite `dnsmasq.plist` file](dnsmasq.plist) 20 | 21 | -------------------------------------------------------------------------------- /dnsmasq.plist: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Label 6 | homebrew.mxcl.dnsmasq 7 | ProgramArguments 8 | 9 | /usr/local/opt/dnsmasq/sbin/dnsmasq 10 | --keep-in-foreground 11 | 12 | KeepAlive 13 | 14 | RunAtLoad 15 | 16 | 17 | -------------------------------------------------------------------------------- /principles-of-code-quality.md: -------------------------------------------------------------------------------- 1 | # Principles of Code Quality 2 | 3 | Tooling evolves, styling changes, languages come and go — but one thing remains constant: the pursuit of quality code and engineering excellence. 4 | 5 | ## Decision-Making Process and Code 6 | 7 | Every decision we make as engineers is a tradeoff. However, that does not mean that we have to compromise our engineering principles. Naturally, the particular constraints, environment, resources, and goals should be considered as determining factors in each case, but there are also underlying principles that should always be satisfied to achieve high quality code standards and engineering excellence. 8 | 9 | Decisions don't just happen at a massive scale, as in the case of choosing a particular architecture or technology. They happen at every instance of our work. Consider the smallest examples: Shoulda new line be left between code blocks? When to comment, and what type should be made? A line-break in your code here, or there instead? All of these micro-decisions express parts of the bigger picture that, overall, reflects your coding discipline,the quality of your code and your expertise with the applications that you work on. 10 | 11 | Let's go through these principles, and consider how and why they should all be factored into your decision-making process—no matter how big or small the decision is. 12 | 13 | ## Maintainability 14 | 15 | Maintainability helps engineers debug, update and extend existing code. The way to achieve maintainability is to write simple, explicit code. In other words, to ensure that you can fix or extend code when necessary, you should be able to run the debugger on a line-by-line basis or insert a console log statement in the code. 16 | 17 | For example, this is difficult to maintain code: 18 | 19 | ```js 20 | function foo (alpha) { 21 | if (alpha) return bar(); 22 | return null; 23 | } 24 | ``` 25 | 26 | There are 2 maintainability issues with the above snippet: 27 | 28 | 1. You are not able to extend what happens in the conditional unless you rewrite it. 29 | 2. You are not able to set a debug and examine the output of bar() before returning it. 30 | 31 | This is how the same function can be written to be more maintainable: 32 | 33 | ```js 34 | function foo (alpha) { 35 | if (alpha) { 36 | const res = bar(); 37 | return res; 38 | } 39 | return null; 40 | } 41 | ``` 42 | 43 | Yes, this is more extensive, has more characters and creates a variable. But none of those concerns are big enough to outweigh the value of maintainability. We are no longer writing software for 8bit machines with 8kb of RAM — it's gonna be OK! 44 | 45 | ## Readability 46 | 47 | Readability is the most important code quality factor. After all, we should remember that we are writing code for the humans who are reading it; whereas computers have no trouble executing readable or obfuscated code (it's basically all the same to them). 48 | 49 | When working in teams, readability consists in a uniform and homogeneous codebase. Multiple developers are expected to read and understand existing code, so leadership and every engineer should always give the highest priority to code homogeneity when authoring code. 50 | 51 | To achieve codebase uniformity and homogeneity, a certain set of rules must be agreed upon and honored by all authors. When this set of rules is applied properly, the whole codebase should look like it was authored by a single person. 52 | 53 | This is a hard to read example: 54 | 55 | ```js 56 | function a(a, i) { 57 | a.splice(0, i); 58 | a.splice(1); 59 | } 60 | ``` 61 | 62 | This is the same function in a more readable format: 63 | 64 | ```js 65 | /** 66 | * Will remove all items from the provided array except the one with the defined 67 | * index. 68 | * 69 | * @param {Array} ar An array. 70 | * @param {number} arIndex the index item to retain. 71 | * @return {void} Array is updated in place. 72 | */ 73 | helpers.arrayKeep = (ar, arIndex) => { 74 | ar.splice(0, arIndex); 75 | ar.splice(1); 76 | }; 77 | ``` 78 | 79 | Yep, documentation can make all the difference! Unlike machines that process code alone, our human brains can more efficiently understand code when it’s accompanied by helpful documentation. Larger and explicit argument names also help to understand the implementation faster. 80 | 81 | Readability is a concern in almost any coding decision-making: How many lines of code should a file have? (In my view, no more than 300, although others would be less generous). Regarding variable names: should they be short or long and explicit? (Long and explicit.) Ultimately, this isn't about writing an exhaustive list of rules. Rather, it's about developing a careful mindset that guides your decision-making and problem-solving. 82 | 83 | A rule of thumb: Anything that can save even milliseconds in the act of reading and understanding code, is a development in the right direction. 84 | 85 | ## Verification 86 | 87 | Your work needs to be verified. Code is complicated and, as we all know, full of errors and bugs. When you deliver your work, you should also provide evidence that what you've built actually works.The best way to do that is through automated testing. 88 | 89 | While testing and testable code is also a major part of maintainability, it is so important that it nonetheless deserves to be considered its own principle. Tested code gives more confidence to engineers. They can maintain a codebase and perform refactorings with the safety net of a complete test suite, which will prevent them from breaking existing functionality. 90 | 91 | Automated testing and verification is not something abstract. It has a concrete footing in computer science. At the very least, you should monitor your "test coverage". Simply search for test coverage tools and libraries for your particular stack, and make sure to integrate them into your pipeline. 92 | 93 | A fully automated build, test, and deployment pipeline is a requirement for any healthy codebase. It helps to solve questions regarding how the organization operates. It saves the entire team time and, of course, protects against broken code from entering into production. 94 | 95 | In addition to its science, there is also an art to testing, and it can only be developed through constant practice and application. I heed my favorite line on the subject: 96 | 97 | > Untested code is legacy code from the moment it is written. And no one wants to deal with legacy code. 98 | 99 | ## Scalability 100 | 101 | Scalability is about having processes, documentation, and operations that allow for rapid scalability of the codebase and the engineering team. This does involve code writing but also goes far beyond that. Regarding coding, the best practices for scalability have already been established by Eric Evans, in his book, [Domain Driven Design][ddd]. A good rule of thumb for operations is to make sure that your business units are sufficiently decoupled, and prepared to become a stand-alone micro-service at a moment's notice. 102 | 103 | The following typical directory structure illustrates this practically ... 104 | 105 | Do not do: 106 | 107 | ``` 108 | app/controllers/user.ctrl.js 109 | app/models/user.model.js 110 | app/views/user.view.js 111 | ``` 112 | 113 | Do: 114 | 115 | ``` 116 | app/users/user.ctrl.js 117 | app/users/user.model.js 118 | app/users/user.view.js 119 | ``` 120 | 121 | The other facets of scalability are documentation and process. Save everyone time by having onboarding documentation that explains, step by step, what a new engineer needs to do and install in order to be ready to contribute.. 122 | 123 | Processes and rituals that help collaboration, communication, and peer to peer learning, all improve the scalability of an organization. 124 | 125 | ## Conclusion 126 | 127 | As we get our footing in the programming industry, our minds swim with new ideas about what is possible, and with opinions on existing technologies. This phenomenon has been responsible for moving entire industries, for better or worse, but we should not let a desire for innovation get in the way of the best practices. 128 | 129 | Being a good programmer, and consistently producing quality code, is attainable. Yes, there is a science to computing, but there is also the practice of excellence in engineering. Excellence comes through discipline. To become a better programmer, you should strive to develop and hone that discipline throughout your professional career... 130 | 131 | Please, feel free to make your suggestions and share your ideas—this is an ever-living document/repo, where we all strive to get better. 132 | 133 | Thank you for your attention 🙏. 134 | 135 | [ddd]: https://www.goodreads.com/book/show/179133.Domain_Driven_Design 136 | -------------------------------------------------------------------------------- /unix-screen-cheatsheet.md: -------------------------------------------------------------------------------- 1 | # Unix Screen Cheatsheet 2 | 3 | ## Basic commands 4 | 5 | | Task | Command| 6 | | --- |:---| 7 | | Start a new screen session with session name | screen -S [name] | 8 | | List running sessions/screens | screen -ls | 9 | | attach to a running session | screen -x | 10 | | attach to session with name | screen -r [name] | 11 | 12 | ## Help 13 | 14 | ``` 15 | ^a ? 16 | ``` 17 | 18 | ## Multi user mode 19 | 20 | ``` 21 | ^a:multiuser on 22 | ``` 23 | 24 | ## Getting Out 25 | 26 | | Task | Command | 27 | | --- |:---| 28 | |detach | `^a d` | 29 | |detach and logout (quick exit) | `^a D D` | 30 | |exit screen | `^a : quit` or exit all of the programs in screen. | 31 | 32 | 33 | ## Window Management 34 | 35 | | Task | Command | 36 | | --- |:---| 37 | |create new window | `^a c`| 38 | |change to last-visited active window | `^a ^a` (commonly used to flip-flop between two windows)| 39 | |change to window by number | `^a ` (only for windows 0 to 9)| 40 | |change to window by number or name | `^a ' `| 41 | |change to next window in list | `^a n` or `^a `| 42 | |change to previous window in list | `^a p` or `^a `| 43 | |see window list | `^a "` (allows you to select a window to change to)| 44 | |show window bar | `^a w` (if you don't have window bar)| 45 | |kill current window | `^a k` (not recommended)| 46 | |kill all windows | `^a \` (not recommended)| 47 | | rename current window | `^a A`| 48 | 49 | ## Split Screen 50 | 51 | | Task | Command | 52 | | --- |:---| 53 | | split display horizontally | `^a S` | 54 | | split display vertically | `^a` or `^a V` (for the vanilla vertical screen patch) | 55 | | jump to next display region | `^a tab` | 56 | | remove current region | `^a X` | 57 | | remove all regions but the current one | `^a Q` | 58 | 59 | --------------------------------------------------------------------------------