lrascao

dash_id=xxxx
api_key=xxx
app_key=xxx

# 1. export
curl -X GET "https://app.datadoghq.com/api/v1/dash/${dash_id}?api_key=${api_key}&application_key=${app_key}" > dash.json

# 2. edit dash.json
move "graphs", "title", "description" up one level in the json hierarchy, from being beneath "dash" to being at the same level

rbf

# You can inspect the release by `tag` before to get the URL of the first asset.
# API_DOC: https://developer.github.com/v3/repos/releases/#get-a-release-by-tag-name
# The you can download the release asset file (not the API object) by including the header 'Accept: application/octet-stream'
# NOTE: When downloading the binary file, don't forget to specify the name of the downloaded file (with -o <filename>).
#       Otherwise the binary will be streamed into the terminal, doing weird unexpected things.
# API_DOC: https://developer.github.com/v3/repos/releases/#get-a-single-release-asset
#
# Everything put together gives that script:
GITHUB_OWNER=twbs
GITHUB_REPO=bootstrap

mikepea

Pull Request Etiquette

Why do we use a Pull Request workflow?

PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.

Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories

Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.