appengine features

Currently an appengine entity is a bigtable/datastore row containing the serialized entity encoded by google's protocol buffers. Every property is indexed whether or not it will ever be queried. An entity reference is inter-row which means entities are heavyweight.

Existing options for representing a Contact:
1a) Contact entity w/ ListProperty's: addresses, emails, etc.
1b) Contact entity w/ address1, address2, address3, email1, email2, email3, etc. properties.
2a) Contact entity w/ addresses property listing keys of Address entities. This is a workaround because lists of ReferenceProperty is unsupported.

I think it would be useful to have lightweight entities which can be embedded in the classic entities. This would enable more options for Contact:
2b) Contact entity w/ addresses property listing NestedReferenceProperty referencing Address nested entities.
2c) Contact entity containing Address nested entities--query by ancestor.

Protocol buffers support nesting & repeating but not arbitrary graphs. Therefore, an implementation based on protocol buffers would restrict expressiveness or face that challenge.

Possible API additions:

• constructor: new Model(nest=parent)

• property type: NestedReferenceProperty; supported in lists.

• custom index support.

It would speed entity update & reduce space if properties could be excluded from indexing.

entity extraction & NLP APIs

A wikipedia article on entity extraction. A useful survey of actual use of APIs.

opencalais is from Reuters.
$2,000 / (100K queries * 30days) = .066 cents per query
One must prepay $24K for the year. The daily cap is 100K queries & 20/sec.
Tried the firefox addon. For the ag2.0 agenda, nba.yahoo.com, & IGN.com, the results are poor.

gate is from U of Sheffield. It is more focused on NLP or language engineering.

usability testing tool

http://www.loop11.com/home/
looks useful based on the demo. Sometimes product managers & interaction designers cling too strongly to their ideas. A tool like this could help bring objectivity to the change order process.

billing systems in the cloud

We've been surveying billing systems in the cloud. Due to limited time, we're restricting our study to aria, monexa, chargify, & recurly.

cost

• #customers: chargify, recurly. Both cap at ~$30K/yr after one reaches ~15K customers. Equivalent to $30K / 2% = $1.5M in revenue at a 2% split.
• %revenue: recurly (3-2%), aria (2%), monexa (1.9%). aria charges a setup fee & monthly minimum.

In other words, chargify charges #customers, aria & monexa charge %revenue, & recurly offers choice.

Features they all offer:

• dunning
• PCI compliant payment & self-service pages (recurly: alpha; chargify: designing; monexa: prefers not to host but provides php app)
• account management portal including revenue & volume reports
• API including notification for real-time sync (chargify: json & xml, recurly: xml, aria: soap & xml/wddx)
• recurring billing
• ad hoc billing (chargify: 2wks)
• usage-based billing (recurly/chargify: soon)
• salesforce.com sync (monexa: soon, aria: now, chargify: long term, recurly: unknown)

aria/monexa require their professional services to configure while recurly/chargify is self-service.

Features which aria/monexa offer but chargify/recurly lack:

• localization of UI
• quickbooks sync
• netsuite sync
• reseller support (monexa doesn't pay splits--need to check on aria)

chargify is working on the following:

• multiple gateways: authorize.net only
• gateway-independent cardholder profiles (beta uses authorize.net profiles)

but lacks:

• foreign currency

Features none of the vendors have:

• historical event feed to overlay on charts