(C-x means ctrl+x, M-x means alt+x)
The default prefix is C-b. If you (or your muscle memory) prefer C-a, you need to add this to ~/.tmux.conf:
| #!/bin/bash | |
| # | |
| # Prepends a date string in front of the Maven output. | |
| # A workaround for http://jira.codehaus.org/browse/MNG-519 "Timestamps on messages" | |
| [ -z "${AWK}" ] && AWK="$(which gawk 2>/dev/null)" || AWK="$(which awk 2>/dev/null)" || { echo "Error: Could not find AWK tool."; exit 1; } | |
| "${AWK}" 'BEGIN { print strftime("%Y-%m-%d %H:%M:%S"); }' 2>&1 > /dev/null || { echo "Error: your AWK version does not support strftime() function." && exit 1; } | |
| mvn "${@}" 2>&1 |"${AWK}" '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }' | |
| # see comp.unix.shell FAQ: (http://cfajohnson.com/shell/cus-faq-2.html) |
| #!/usr/bin/env python | |
| """Simple HTTP Server With Upload. | |
| This module builds on BaseHTTPServer by implementing the standard GET | |
| and HEAD requests in a fairly straightforward manner. | |
| """ |
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
The PayPal platform is a collection of reusable services that encapsulate well-defined business capabilities. Developers are encouraged to access these capabilities through Application Programming Interfaces (APIs) that enable consistent design patterns and principles. This facilitates a great developer experience and the ability to quickly compose complex business processes by combining multiple, complementary capabilities as building blocks.
PayPal APIs follow the [RESTful][0] architectural style as much as possible. To support our objectives, we have developed a set of rules, standards, and conventions that apply to the design of RESTful APIs. These have been used to help design and maintain hundreds of APIs and have evolved over several years to meet the needs of a wide variety of use cases.
We are sharing these guidelines to help propagate good API design practices in general. We have pulled extensively from the broader community and believe that it is importan
This document lists various useful patterns for API design. We encourage API developers to consider the following patterns as a guide while designing APIs for services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The words "REST" and "RESTful" MUST be written as presented here, representing the acronym as all upper-case letters. This is also true of "JSON," "XML," and other acronyms.