- Download docker-compose.yml to dir named
sentry
- Change
SENTRY_SECRET_KEY
to random 32 char string - Run
docker-compose up -d
- Run
docker-compose exec sentry sentry upgrade
to setup database and create admin user - (Optional) Run
docker-compose exec sentry pip install sentry-slack
if you want slack plugin, it can be done later - Run
docker-compose restart sentry
- Sentry is now running on public port
9000
alias c='docker-compose' | |
alias cb='docker-compose build' | |
alias cup='docker-compose up' | |
alias cr='docker-compose run --service-ports --rm' | |
alias crl='docker-compose run --service-ports --rm local' | |
alias crd='docker-compose run --service-ports --rm develop' | |
alias crt='docker-compose run --rm test' | |
alias crp='docker-compose run --rm provision' | |
alias crci='docker-compose run --rm ci' | |
alias crwt='docker-compose run --rm watchtest' |
#!/bin/bash | |
pbpaste | pygmentize -O"style=tango, fontface=Menlo" -f rtf -l $1 | pbcopy |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
I like to manage dotfiles without having to mess with silly symlinks or having | |
to install/configure specific dotfile managament tools. So here's what I did: | |
$ cd ~ | |
$ git init . | |
$ echo '*' > .gitignore # ignore all files by default | |
$ echo '!.bashrc' >> .gitignore # ...and then tell git what files not to *not* ignore | |
$ # ...add other files you may want to track to *not* ignore | |
$ git add .bashrc # now actually add the files to git | |
$ git add .gitignore # add the .gitignore to git |
This entire guide is based on an old version of Homebrew/Node and no longer applies. It was only ever intended to fix a specific error message which has since been fixed. I've kept it here for historical purposes, but it should no longer be used. Homebrew maintainers have fixed things and the options mentioned don't exist and won't work.
I still believe it is better to manually install npm separately since having a generic package manager maintain another package manager is a bad idea, but the instructions below don't explain how to do that.
Installing node through Homebrew can cause problems with npm for globally installed packages. To fix it quickly, use the solution below. An explanation is also included at the end of this document.
#!/usr/bin/python | |
import ast, _ast, os | |
for root, dirs, files in os.walk('.'): | |
for name in files: | |
if name.endswith('.py'): | |
full = os.path.join(root, name) | |
t = ast.parse(open(full).read()) | |
for n in ast.walk(t): | |
if isinstance(n, _ast.Str) and not isinstance(n.s, unicode): |
/* | |
* I add this to html files generated with pandoc. | |
*/ | |
html { | |
font-size: 100%; | |
overflow-y: scroll; | |
-webkit-text-size-adjust: 100%; | |
-ms-text-size-adjust: 100%; | |
} |
This is just a few thoughts on the topic of writing technical guides. This was intended for Basho's engineering team, but this may apply to open source projects in general.
It's commonly preached that the first step in writing is to identify your audience; to whom are you writing? This is the most well known, most repeated, and most overlooked step of writing in general and technical writing in particular. Take this document, for example. My audience is technical people who need to communicate technical information, and not teenagers, so I shy away from images of pop icons and memes. I use jargon and words like "identify" rather than "peep this".