Keller Apps' Blog

appengine features

2010-03-18T10:26:00.000-07:00

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

2010-03-18T10:16:00.000-07:00

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

2010-02-16T20:58:00.000-08:00

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

2010-02-07T13:54:00.000-08:00

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