Not a coincidence. Adonit manufactures the Ink & Slide for Adobe, and apart from some cosmetic differences, and an additional button, the JTPP has all the same functionality as the Ink.
Definitely, that is what we hope developers will start using it for. We expose the accelerometer data in the SDK, so developers can get access to the data. We also use the relative pen position to the iPad to sort out some offset issues to make sure the line appears to be coming from the tip itself.
The touch pressure for paper is done with a new touch Radius property. The radius property on touches was available as a private API, but only made available publicly in iOS 8.
The Ink and Adonit touch pixel point, which are basically the same (We manufacture the Ink and Slide for adobe) use a pressure sensitive tip in the pen itself, and communicate that pressure over Bluetooth. This gives you a much higher resolution on the pressure, with the trade off of the BT stack latency.
Ditto on the above lists. Similar to inter-app communication issue is some way to meaningfully work with documents and data outside of application silos, either to share documents between apps, or to get documents onto and off the device.
We recently launched a simple website monitoring app for the iPhone where we ping sites from our servers, and send push notifications when we detect something is wrong (a poor man's pagerduty or pingdom where you do everything from your phone and can subscribe using IAP).
Probably the biggest lesson we've learned from collecting data on latency and timeouts from our backend is that there are a LOT of very poor hosts out there. Trying to strike a balance between intermittent failures, and actual "Your site is down, you need to do something" is pretty difficult, unless you are willing to simply wait long enough. We'll regularly see timeouts from places like Tumblr and Github Pages--they never go down, but things can get spotty. We can also tell when certain hosting providers are doing their weekly backups (or something - just guessing) because things will just go to pot at the same time every weekend for about an hour.
I can second the S3/CloudFront recommendation. Pretty rock solid (modulo downtime in specific regions).
If it is related to manufacturing, then absolutely. My neighbor works for a Honda supplier, and one day had to drop everything and fly from Indiana to a plant in Brazil with a replacement for some part of the assembly line. It is surprising how quickly a supply chain disruption can ripple through the entire manufacturing line. These organizations track things in hours and minutes.
I've seen the current software patent debacle compared to a nuclear standoff. Reading this article made me think of another analogy: Gangs. How long until independent developers will need to either join the Bloods or the Crips in order to fall under the umbrella of their protection? Unless you are a paid-up member of the Apple or Google development programs, you are a potential victim of random drive-by-lawsuits. Even if you are a member you may get shot at, but the gang will retaliate on your behalf.
If they are truly blade servers, then they were possibly sharing the same chassis, power supply and backplane. Could the FBI have pulled just the blades in question? Possibly. But I can very easily imagine the entire blade chassis being viewed as a monolithic component that they would want to be able to perform whatever forensic analysis they are planning. They could also have pulled whatever blades they were not after, and left them, but until you replace the chassis, you are dead in the water.
My comment would be that the author is conflating growth in users and page views to revenue growth. While the two are very highly correlated, they are not the same thing. How Facebook monetizes its users and page views doesn't have to be a 1:1 relationship. The question should be how Facebook will derive ever more revenue from each user over time. Slowing user growth is certainly an easy proxy to use in lieu of real revenue numbers, but it is a gross oversimplification.
Scale Computing has a couple position open for C/C++ developers. Preference would be for working on site but we are open to people working remote (I work remote myself). More info at http://www.scalecomputing.com/careers/
Consider how destructive this kind of attitude is toward the programming profession. By trivializing any project, a programmer is by extension making it seem like programming is easier, and cheaper, than it really is. What starts out as an ego-pumping "hey, I'm smarter than THAT person." turns into a devaluation of the work we all do, all to fulfill some desire for acceptance among non-technical peers. You wouldn't pick the brain surgeon that told you he could get the job done in a fraction of the time his colleagues could muster.
I'm starting to wonder in how many ways I can screw up a 10 question survey. Thanks for the feedback. I had 5 other people proofread the survey and you are the only one to catch that.