nnja

# Setup Amazon EC2 CLI
export EC2_HOME=~/.ec2
export EC2_PRIVATE_KEY=`ls $EC2_HOME/pk-*.pem`
export EC2_CERT=`ls $EC2_HOME/cert-*.pem`
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/

# Path entry for AWS EC2 Command line tools
PATH=$PATH:$EC2_HOME/bin

# Path entry for AWS CLI Elastic Bean Command line tools

nnja

Installing GNU Screen on OS X in Homebrew

I want to edit in one tab, run what I edit in the other. Typical multi-view stuff. I've used Terminal.app for the last few years. Lately, however, after not long enough, Terminal gets laggy when I switch between tabs.

The stutter between edit and run is annoying, an unnacceptable. One of the major reason I've chosen to work with character based UI is because it is snappy. There shouldn't be a lag while a screen of UTF-8 is rendered in a monospace font.

The lag gets progressively longer, chipping at my productivity with irritation. The only solution is to kill all my Terminals, which essentially kills my flow. Terminal.app won't remember where I was for me. I have to initialize ever tab.

GNU Screen

nnja

nnja

(add-hook 'hack-local-variables-hook 'run-local-vars-mode-hook)
(defun run-local-vars-mode-hook ()
  "Run a hook for the major-mode after the local variables have been processed."
  (run-hooks (intern (concat (symbol-name major-mode) "-local-vars-hook"))))


(defun detect_buffer_venv (buffer-name)

  (let ((buffer-dir (file-name-directory buffer-name)))

nnja

# -*- mode: snippet -*-
# name: i
# key: i
# group : general
# --
import ipdb; ipdb.set_trace()

nnja

Keybase proof

I hereby claim:

• I am nnja on github.
• I am nnja (https://keybase.io/nnja) on keybase.
• I have a public key whose fingerprint is E80D A711 1E08 1568 81EC 1325 2DD8 28C5 1A3D D12D

To claim this, I am signing this object:

nnja

autoload -Uz vcs_info

zstyle ':vcs_info:*' stagedstr '%F{green}●'
zstyle ':vcs_info:*' unstagedstr '%F{yellow}●'
zstyle ':vcs_info:*' check-for-changes true
zstyle ':vcs_info:(sv[nk]|bzr):*' branchformat '%b%F{1}:%F{11}%r'
zstyle ':vcs_info:*' enable git svn
theme_precmd () {
    if [[ -z $(git ls-files --other --exclude-standard 2> /dev/null) ]] {
        zstyle ':vcs_info:*' formats '%c%u%B%F{green} '

nnja

When many different people are working on a project simultaneously, pull requests can go stale quickly. A "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. The most common reason why pull requests go stale is due to conflicts: if two pull requests both modify similar lines in the same file, and one pull request gets merged, the unmerged pull request will now have a conflict. Sometimes, a pull request can go stale without conflicts: perhaps changes in a different file in the codebase require corresponding changes in your pull request to conform to the new architecture, or perhaps the branch was created when someone had accidentally merged failing unit tests to the master branch. Regardless of the reason, if your pull request has gone stale, you will need to rebase your branch onto the latest version of the master branch before it can be merged.

What is a rebase?

nnja

https://raw.github.com/wiki/user/repo/page.md?login=login&token=token

nnja

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this: