Unicode-encode vim.org text for rethinkdb-v1.13

Summary:
After updating RethinkDB to 1.13 and then running the vim.org scraper, we were
getting this error for every vim.org plugin we scraped:

```
Error scraping vim-fanfou (vimorg_id=4972) from vim.org
Traceback (most recent call last):
  File "/Users/david/code/vim-awesome/tools/scrape/vimorg.py", line 68, in scrape_scripts
    db.plugins.add_scraped_data(plugin)
  File "/Users/david/code/vim-awesome/db/plugins.py", line 500, in add_scraped_data
    insert(updated_plugin, upsert=True)
  File "/Users/david/code/vim-awesome/db/plugins.py", line 176, in insert
    r_conn())
  File "/Users/david/.virtualenv/vim-awesome/lib/python2.7/site-packages/rethinkdb/ast.py", line 75, in run
    return c._start(self, **global_optargs)
  File "/Users/david/.virtualenv/vim-awesome/lib/python2.7/site-packages/rethinkdb/net.py", line 213, in _start
    return self._send_query(query, global_optargs)
  File "/Users/david/.virtualenv/vim-awesome/lib/python2.7/site-packages/rethinkdb/net.py", line 305, in _send_query
    query_str = query.serialize().encode('utf-8')
  File "/Users/david/.virtualenv/vim-awesome/lib/python2.7/site-packages/rethinkdb/net.py", line 36, in serialize
    return json.dumps(res, ensure_ascii=False, allow_nan=False)
  File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py", line 250, in dumps
    sort_keys=sort_keys, **kw).encode(obj)
  File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/encoder.py", line 210, in encode
    return ''.join(chunks)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 35: ordinal not in range(128)
```

Test Plan:
Ran `PYTHONPATH=. python tool/scrape/scrape.py -s vim.org 1000`, and verified
the above error is no longer raised for all the plugins we scraped.

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D209
Add a crontab that runs the data pipeline daily

Summary:
So each day starting 10 pm PST, we scrape vim.org plugins, then
github.com/vim-scripts plugins, then recently-updated dotfiles github repos,
then we aggregate all known GitHub plugin repos, then we scrape 3600
non-vim-scripts plugin GitHub repos plugin repos.

Test Plan: Each command was run on the server and the output of ~/logs/cron/*.log examined.

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D210
Add a cronjob to dump DB daily

Summary:
We can then setup Tarsnap to backup these dumps elsewhere. These dumps are
currently only about 15 MB zipped.

Test Plan:
Ran `( cd $HOME/dumps && rethinkdb dump )` in $HOME on the server. Ensured dump
was found in the right folder.

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D211
use 4-space indents for python in .editorconfig
Highlight the current tag in the sidebar based on the query
Merge pull request #44 from JGulbronson/master

Added highlighting for the currently selected tag
Tweak selected tag color a bit

... so that hovering over a selected tag doesn't change it.
Add script to fix plugins with vim.org ID duplicates

Summary:
If you look at vimawesome.com/?p=3 right now, you will see many duplicated
"taglist.vim" plugins.

A long time ago, when we scraped a github repo whose homepage was a vim.org
plugin, we would assume that was the definitive github repo associated with
that vim.org plugin and set that repo's vim.org ID. But it turns out, of
course, that there are many different github repos that all set their homepage
to the same vim.org plugin. This led to multiple plugins with the same vim.org
ID in our DB, which violates an invariant assumed throughout the codebase that
vim.org ID is unique in the plugins table.

This was fixed the night before launching, but I forgot/didn't have time to update the data,
and so the data was in an inconsistent state.

With the invariant violated, scraping the same set of sources no longer
guaranteed idempotence, and so each new scrape would accumulate new duplicates.
Basically, when the scraper tries to match a source that has a vim.org ID and
it sees multiple existing plugins with the same vim.org ID, it doesn't know
which one to match to, so it inserts a new row instead of attempting a match.
This led to the proliferation of duplicates you see now.

So this script removes the extra accumulated plugins, and also fixes duplicate
vim.org IDs by only allowing the plugin with the most users to keep its vim.org
ID.

Test Plan:
Locally. Before fix, ran
`PYTHONPATH=. python tools/scrape/scrape.py -s vim.org`, and saw that a bunch of new plugins were inserted when they should
have been associated. Ran
`PYTHONPATH=. python tool/scrape/scrape.py -s github-vim-scripts`,
and saw new plugins were inserted when they should've been associated.

After fix, ran the two commands above again, and ensured no new plugins were
inserted. Also ensured there were no duplicated vim.org IDs

Also did a dry run of the script and looked at script output. For the first
6 plugins or so, manually verified the script made the right decisions in which
plugins to delete, which to keep, and which to assign the vim.org ID.

Ran the script twice to ensure the second time it outputted nothing (meaning it successfully de-duped). Also ran the script after re-scraping to verify there were no new dupes introduced.

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D212
Tags input: re-scoped padding definition

Fixes #32.
Merge pull request #48 from julen/issue/32

Tags input: removed unnecessary padding
Show plugin name in document title
Merge pull request #47 from JGulbronson/master

Show plugin name in document title
Add a script to easily view new submitted plugins

Summary: That is, submitted plugins that we don't already know about and are non-empty.

Test Plan:
- imported the `submitted_plugins` table from prod
- ran `PYTHONPATH=. python tools/clean_submitted_plugins.py`
- saw the output looked reasonable

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D213
Set Python IO encoding to utf-8 in crontab

Summary:
Otherwise, when we output non-ascii characters and try to pipe that somewhere,
Python does not know which encoding to use, defaults to ascii, and raises a
UnicodeEncodeError.

This fixes errors that look like this in vim:~/logs/cron/github-plugins.log:

```
Scraping plugins from github.com...
Traceback (most recent call last):
  File "/home/vim/vim-awesome/tools/scrape/scrape.py", line 54, in <module>
    scrape_fn(args.number)
  File "/home/vim/vim-awesome/tools/scrape/scrape.py", line 9, in scrape_github_plugins
    github.scrape_plugin_repos(num)
  File "/home/vim/vim-awesome/tools/scrape/github.py", line 243, in scrape_plugin_repos
    print "    scraping %s/%s ..." % (repo_owner, repo_name),
UnicodeEncodeError: 'ascii' codec can't encode characters in position 23-24: ordinal not in range(128)
```

Also disables Python output buffering so that logs are actually comprehensible
and sequential.

Test Plan:
- added the following cronjob to output every minute on the server:
  `python -c 'import sys; print sys.stdout.encoding; print u"\u0411\n"' >> $HOME/testcron.log 2>&1`
- saw that we were getting the same error as we saw in our other cron logs:
  ```
  None
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  UnicodeEncodeError: 'ascii' codec can't encode character u'\u0411' in position 0: ordinal not in range(128)
  ```
- Added "PYTHONIOENCODING=utf-8" to the crontab
- Saw that we were correctly outputting to testcron.log:
  ```
  utf-8
  Б
  ```

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D214
Actually install new crontab on every deploy

Test Plan: fingers crossed

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D215
Copy acknowledgements to README.md from about page

Summary: Just nice to mention React and RethinkDB in our README

Test Plan: *fingers crossed*

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D216
mv {clean,review}_submitted_plugins.py

Summary:
Next revision will add a bunch of stuff to this script so that it can actually
be used to interactively review and add plugins instead of just outputting
which submissions need to be reviewied. This just makes the next diff cleaner.

Test Plan: *fingers crossed* (extracted from tested revision, up next)

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D218
Interactively review and add submissions

Summary:
This changes the old script that just displays user submissions that can be
added, and displays a prompt asking whether a submission should be added. If
yes, will insert, else, will record it was rejected (and skip it in future
runs).

This just inserts a row into our table of known plugin github repos, which will
be used when we run the github scraper. A future revision will use the saved
`from_submission` field to auto-populate category and tags.

Test Plan:
- ran `make review_submissions` locally
- responded "y" a bunch of times
- ctrl-c'ed the script
- re-ran. saw that the "yes" submissions were not displayed again and added to
  the count of "known github plugins" and reduced the count of "new plugins".
  Also ran some DB queries to see that new rows were inserted into
  the `plugin_github_repos` table.
- responded "n" a bunch of times
- saw the rejected plugins count go up, new plugins count go down accordingly
- also ran a DB query filering on `rejected: true` to verify

Reviewers: xymostech, spicyj

Reviewed By: spicyj

Differential Revision: http://phabricator.benalpert.com/D217
Replaced relative URL with absolute URL
Reduce gunicorn works from 12 to 5

... since we downsized server from 8G Linode with 6 cores to a 2G Linode with
2 cores.

Test Plan:
*fingers crossed*

Auditors: spicyj, xymostech