steverice

"RefCountingStorage write content helper" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5b33ea53
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:957)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:917)
	at java.lang.Thread.run(Thread.java:680)

steverice

"repositories": [
		{
			"type": "composer",
			"url": "http://packages.firegento.com"
		},
		{
			"type": "package",
			"package": {
				"name": "connect20/lib_google_checkout",
				"version": "1.5.0.0",

steverice

.
├── [2907877]  composer.json
├── [2937290]  composer.lock
├── [2316418]  magento
│   ├── [2890782]  LICENSE.html
│   ├── [2890783]  LICENSE.txt
│   ├── [2890784]  LICENSE_AFL.txt
│   ├── [2890785]  RELEASE_NOTES.txt
│   ├── [2890786]  api.php
│   ├── [2880927]  app

steverice

/**
 * Example: incoming property name (e.g. from PHP) has square brackets, e.g. names[0][1]
 * var property = names[0][1];
 * var value = {
 * 	names: [
 * 		['some', 'data', 'here']
 * 	]
 * }
 * result: value == 'some'
 * 

steverice

1. Set up PR fetch aliases to make pulling PRs easy: https://gist.github.com/gnarf/5406589
2. Set up RubyMine as external diff viewer in SourceTree: http://www.jetbrains.com/ruby/webhelp/running-rubymine-as-a-diff-or-merge-command-line-tool.html and http://stackoverflow.com/questions/14774053/intellij-diff-tool-in-sourcetree (bin path for me is /Applications/RubyMine.app/Contents/MacOS/rubymine)
3. Bookmark a temp repo that you use to grab PRs in SourceTree
4. ???
5. PROFIT!

steverice

API v2 Vision 👓

This document outlines the vision and scope for v2 of the API.

Ordered lists represent prioritized order. We recannot accomplish everything at once, and thus everything needs to be prioritized sooner or later. I choose sooner.

This document does not attempt to present a comprehensive record of all the changes that will be made, as those will be captured by stories in JIRA. Instead, it establishes the goals, principles, and patterns that we'll use to make the decisions about what needs to change.

It is a living document and will evolve as we discover new edge cases and outliers that weren't previously considered.

steverice

---
title: PagerDuty Developer
layout: main
---
<ul class="breadcrumb">
  <li>
    <a href="/documentation/rest/">REST API</a>
  </li>
  <li style="list-style: none">
    <span class="divider">/</span>

steverice

The API Approval Process

When do I need approval for an API change?

Approval is needed before shipping any change used by one or more wild clients or releasing the API for general availability. In other words, the API must be contracted.

If you are working on a prototype API, you may ship your code at will, but you acknowledge the following tradeoffs:

• you are responsible to make any and all code changes to satisfy the final approved proposal before general availability
  • in other words, there will be additional churn
• you have communicated to any clients of the prototype API that their integration may break at any time

steverice

PagerDuty API v2 is Now in Beta!

PagerDuty is thrilled to announce that the new version of our popular PagerDuty REST API is now available for everyone to use in beta!

We've been working hard on this version of the API for a while and are excited about the improvements in speed, consistency, and ease of use that API v2 delivers.

If you're a PagerDuty customer, you've already been using API v2 for a while every time you use our web application. In our own experience, we've found it easier to work with and build new functionality using API v2 than ever before.

What's new?

steverice

Hello,

Thanks for your continued interest and use of the PagerDuty API.

We're writing to let you know that as of November 4th, 2015, we will be discontinuing the ability to authenticate against the API using HTTP Basic Authentication (PagerDuty username and password), which has been deprecated since mid-2014.

We are doing this to improve security of PagerDuty accounts by limiting the spread of PagerDuty user passwords, which are difficult to audit and revoke should they become compromised.

Additionally, the need to authenticate a user via HTTP Basic Authentication imposes a performance penalty on every API request due to the robust hashing techniques we use to store and validate user passwords. This is done by design to make brute forcing passwords computationally infeasbile.