- Install Git
- Create a GitHub account
- Open Terminal
/Applications/Utilities/Terminal.app
import contextlib | |
import subprocess | |
# Unix, Windows and old Macintosh end-of-line | |
newlines = ['\n', '\r\n', '\r'] | |
def unbuffered(proc, stream='stdout'): | |
stream = getattr(proc, stream) | |
with contextlib.closing(stream): | |
while True: | |
out = [] |
Either copy the aliases from the .gitconfig
or run the commands in add-pr-alias.sh
Easily checkout local copies of pull requests from remotes:
git pr 4
- creates local branchpr/4
from the githubupstream
(if it exists) ororigin
remote and checks it outgit pr 4 someremote
- creates local branchpr/4
fromsomeremote
remote and checks it out
Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000
This re-styles your sublime text sidebar to be dark, it fits default Monokai theme.
Save the Default.sublime-theme file into packages/Theme - Default, make a backup of your original if you want to be able to go back easily.
Based on:
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
-
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the
secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection. -
Use production SSL certificates locally. This is annoying
As demonstrated by the tutorials on the website, RabbitMQ can be used for everything from queuing background work to building RPC systems. To use RabbitMQ effectively, it is important to understand the core concepts: queues, exchanges, bindings, and messages. The documentation on rabbitmq.com is excellent, so I won't go into much depth, but it's worth briefly mentioning the core ideas.
Exchanges are where messages are sent. Every time a message is pushed in to RabbitMQ, it goes through an exchange.
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
apply plugin: 'java' | |
apply plugin: 'war' | |
apply plugin: HelloPlugin | |
group = 'org.springframework.samples' | |
version = '1.0.0-SNAPSHOT' | |
description = "petclinic" | |
sourceCompatibility = 1.7 |
# Short of learning how to actually configure OSX, here's a hacky way to use | |
# GNU manpages for programs that are GNU ones, and fallback to OSX manpages otherwise | |
alias man='_() { echo $1; man -M $(brew --prefix)/opt/coreutils/libexec/gnuman $1 1>/dev/null 2>&1; if [ "$?" -eq 0 ]; then man -M $(brew --prefix)/opt/coreutils/libexec/gnuman $1; else man $1; fi }; _' |