FWIW, Brown University was doing research in this *Pad field (stylus-based input apps for domain specific notations) in the late 90s/2000s. I was a member of this group for a brief period of time. It's really exciting to see a resurgence in high quality pen computing with affordable, entry-level consumer hardware like the Surface 3.
What I'm finding from using and talking to beta users of DidSum (referenced in another comment on this post) is that the act of physically tracking a behavior has value in building habits and improving toward goals (or being extra aware of it, when you're not).
This is doubly true in a social setting where your friends/spouse/mom/coach can _see_ when you are or are not taking actions toward what you want to improve at.
I'm building a mobile app, called DidSum, that focuses on your #2 "Avoid Data Entry, but Make it Easy" (and putting an API around the data). It's almost ready for broader use.
I use DidSum to track running, blogging, eating healthy, sex, coffee consumption, and more.
DidSum allows you to define the actions you want to improve at. You can track publicly with friends and family and encourage/compare/compete with each other. You can also track privately (some actions I only track with my wife). It has basic analytics, which will get more powerful with time.
I suppose I am part of your Ph.D. 'attrition' statistic. It's less atrocious than you'd think.
I enrolled in Brown's Ph.D. CS computer program immediately after undergrad. In retrospect, I was too green to do proper due diligence to find the right fit with advisor and research area. The advisor relationship is extremely important. Within the first year I realized two things: 1) there was no way I'd be happy going deep with this particular research area and advisor for another 5-6 years, 2) I would complete my masters in the first year, fully paid for (with a research assistant "salary" on top) by being on the PhD track. I returned full-time to the company I co-founded while in undergrad after that first year.
No two PhD paths are the same, unlike with JD/MBA. Some folks come in and earn a master's along the way. Some come in with a master's. Some don't pass the (widely different depending on school) bars to advance to the Ph.D. candidate stage (I imagine there's a good bit of attrition here). Some don't find an advisor who can fund them. The requirement of contributing something novel to the body of research, no matter how long it takes, is a higher bar than completing coursework and projects. 6,7,8 years is a lot longer than 2-3.
Interestingly, some dev certificates/provisioning profiles I setup in the day prior to the outage do not appear to exist anymore. It seems as though they must have reverted back to some point earlier in the week.
Braintree isn't the only HTTPS API a developer will consume. Rather than bury the knowledge of HTTPS best practice in the black box of a library, why not exemplify it in language-specific examples of plain-old REST API documentation?
If the boilerplate for manually getting an SSL connection right in a given language is that obtuse, the "just use our library" pitch is even more compelling.
All this said, I have used Braintree's libraries and they are extremely well executed.
Not exposing REST API documentation externally (it surely exists internally, right?) just feels like a cop out.
(An argument I'm surprised was left out: it's easier for support staff to work with customers integrating with a good library than some home rolled REST client. I can imagine this to be true, but maybe a case of premature optimization if the majority of big API players expose and document their REST APIs anyway?)
Thanks for the heads up. Made a quick fix by taking out affix on the column. Tried to get this up pretty quickly with Bootstrap, need to spend some more time on it this weekend. Sorry for the annoyance.