FWIW - The Nest lock in question doesn't rely on an active internet connection to work. If it can't connect, it can still be unlocked using the sets of PINs you can setup for individual users (including setting start/end times and time of day that the codes are active). There's even a set of 9V battery terminals at the bottom in case you forget to change the batteries that power the lock.
This does mean you need to setup a code in advance of people showing up, but it's an under 30 second setup that I've found simpler than unlocking once someone shows up. The cameras dropping offline are a hot mess though, since those have no local storage option.
(my opinions, not my employer's standard disclosure) Lob team has been great to work with - they've accommodated a lot of tweaks we've needed (custom paper, much higher levels of verification). They're good at API backwards compatibility, but they are pretty active on the development front, so it's worth keeping an eye on what changes are coming through on the SDK.
We work out of a mono-repo and use pants (https://pantsbuild.github.io/) for python/jvm/js packaging to deploy on mesos (https://mesos.apache.org/). Pants gives us (effectively) the same development workflow as in production and let's us treat any application (we have ~500 at this point) as just a command line executable (for things with weird lib dependencies, we do statically compiled wheels for each architecture - CentOS and OS X in our case - on our own pypi mirror). We've got a few kinks to still workout for local development of web projects (mostly related to JS/CSS) but for things that don't touch the frontend it's pretty beautiful.
Even the standalone optical HRMs (e.g., Scosche RHYTHM+) aren't good enough to do HRV[1] even though their accuracy compares favorably with the chest strap models[2]
EC2 <-> S3 yes (this should be easy as S3 has ssl support out of the box). The bigger issue is stuff like redis (which purposefully doesn't support encryption) which means you either need to be careful not to put PHI in redis (e.g., use object IDs rather than the object themselves, don't cache things that might have PHI) or use something like stunnel (which doesn't play lovely with redis), ipsec, or use GCE.
I'd recommend encrypting from the boot volume up and not just your EBS volumes. Otherwise you have to worry about things like PHI in logs, core dumps, etc. being put onto unencrypted storage.
We have a home grown solution for this. We use pants (https://pantsbuild.github.io/) for our Python builds and phabricator for code reviews. Pants gives us a dependency graph so from which files get touched in a given diff, we can feed that back into pants to get the targets to build and the test suites to run. It's not as granular as running individual tests in a suite for small changes, but it definitely helps cut most runs down to just a small percentage of all the tests. The ability to pants to build test suites in isolation is also pretty key since it means we can run a whole bunch of suites in parallel so in many cases the total test run time can be just the time of the longest individual suite.
As others have mentioned, kicking off full runs on a regular basis is important to make sure there aren't weird cases that break and aren't caught in this approach.
FWIW - even inside a VPC on AWS traffic isn't encrypted by default so if you're dealing with PHI traffic between servers also needs to be encrypted. Many databases support this out of the box, but if you're using something like redis you either need to use ipsec or stunnel. Google's Compute Engine platform does support encrypted network traffic so that' s nice plus (we're multi-cloud so we're currently using stunnel and moving to ipsec).
Lock out the root AWS keys as much as you can (ours requires a MFA token that's stored in a safe) and only use IAM users with restricted permissions for day to day operations.
Everything should have an audit trail, preferable with all the logs shipped off the servers to a centralized store (that way if a server is compromised the attacker can't also edit/delete the logs)
Script all your boxes through config management so that you can handle updates/security patches in a uniform manner and quickly.
Restrict who has access to root/DB in production. When you grant access keep an audit trail of why they have access and revoke it if it's no longer necessary. Have a good development environment setup so people don't develop the habit of developing against production.
Pentest + bug bounties are good. Once you get to a certain point you'll probably also need to have a general security/HIPAA audit as well.
We didn't move away (never were using GitHub), but we've done our CI hooks from inside arc (the command line client for phabricator) and it's worked pretty well (it means you need to be able to reach both phabricator and our CI server, but since phabricator is self-hosted that's not really a problem). A little manual, but pretty straightforward to get setup.
Overall, we greatly prefer phabricator's review tools (batch email notifications) + general git workflow (linear history on master) so haven't really looked into GitHub enterprise.
Some of the plugins (which is a big part of choosing IDEA over the sub-products) aren't backwards compatible (I had issues with the golang plugin in 12, but it's fine in the community edition of 13). Right now I've got PyCharm 3.4 (work license), IDEA 12UE (personal license), IDEA 13CE, and Android Studio on my machine to support the various languages I'm using on somewhat regular basis (90+% of my time is spent in python, which is why I don't just use the python plugin for IDEA - the plugins are nice, but the context menus get crazy one you have more than one active at a time)
We use git-crypt (https://github.com/AGWA/git-crypt) in our ansible repo for credentials. Credentials are stored as variable YAML files so anyone can work with them in templates, but only our deploy box and SRE team can encrypt/decrypt the credential files themselves. Generally works pretty well, but you do need to remember to run credential deploys on new boxes. Eventually we'll probably move to a HSM (hardware security module) for the actual storage, but those are pricey (especially since you need two of them).
Mixed bag. The code review part is much better than stash and significantly better than crucible. Namely, diff of diffs makes reviewing changes based on comments infinitely easier (especially on large reviews). We installed phabricator just for the code review piece initially. Repo browsing is about on par with stash, but it doesn't seem to experience the horrific slow downs that our stash server does. We don't use the tasks because a number of non engineering roles also use JIRA and the tasks functions in phabricator don't have nearly the depth of security and workflow options we need.
Mixed bag. The code review part is much better than stash and significantly better than crucible. Namely, diff of diffs makes reviewing changes based on comments infinitely easier (especially on large reviews). We installed phabricator just for the code review piece initially. Repo browsing is about on par with stash, but it doesn't seem to experience the horrific slow downs that our stash server does. We don't use the tasks because a number of non engineering roles also use JIRA and the tasks functions in phabricator don't have nearly the depth of security and workflow options we need.
Kinesis Freestyle 2 http://www.kinesis-ergo.com/shop/freestyle2-for-mac/ with the VIP tent accessory and a trackball between the spilt (raised up so it's at the same level as the edges of the keyboard. Being able to keep my hands straight and minimizing movement to move my cursor is great (I keep a apple wireless keyboard around for if other people need to use my computer)
FYI: 4147 2011 1111 1111 triggers the special Chase Sapphire layout (number is on the back of the card, front just has your name + the Chase Sapphire (Preferred)).
I actually find the lack of any label on the CVV field a bit confusing, but maybe that's just me.
The first result for mobile is organic as far as I can tell (it just happens to be a google property when looking for Italian Restaurants in Tribeca). Try switching the query for mexican restaurant and just a few blocks to the west in SoHo (hi Aaron) a menupages result is first. Also, on the mobile front, I believe the quick results are from places and not Zagat, since with the same mexican restaurants query there are a number of places with just ratings and not "Zagat" ratings (you can see this in the blog's screenshot for Olive Garden as well).
I actually don't mind this on mobile (but I also generally use something else for finding restaurants) since the majority of restaurant websites are basically impossible to navigate on mobile and all I really need to know is 1) where are they 2) what's their phone number. How organic that database is, I'm not sure, but it doesn't seem to be showing specifically paid placements.
Having swam in the Hudson (NYC Triathlon) and kayaked extensively in the East River (including a trip up the Gowanus Canal - never again), the water quality in the main parts of the river is actually quite good these days. The biggest thing to keep in mind is that most of NYC runs the gutters through the sewage system, so when there is heavy rainfall, the combined output overwhelms the capacity of the system and they release untreated sewage into the rivers. There's a lot of community involvement in tracking water quality in the rivers and you can get real measurements at a fairly regular basis: http://www.nycwatertrail.org/water_quality.html I'd be far more worried about being an unsupported swimmer. Even in a kayak, the danger of boats is quite real and swimmers are even less visible (and slower) than kayakers.
Vine started out as a small (3 person) startup that Twitter acquired just before their launch. Could they, post acquisition, have gotten the android version out quicker, maybe, but it's unlikely that they could have built the backend, an ios, and an android app with the amount of polish the ios app had at launch and launched at the same time with just the 3 people they had prior to the acquisition.
I recently switched from using a racing bike for my day to day commuting to a much chunkier Dutch bike that seems to be in line with the Citi bikes and the difference in commute times is fairly negligible (Cobble Hill to SoHo took me about 15-18 minutes on my road bike and now takes about 18-22). The added ~5 minutes is worth not be drenched in sweat by the end of my ride and having some real cargo capacity on my bike.
This does mean you need to setup a code in advance of people showing up, but it's an under 30 second setup that I've found simpler than unlocking once someone shows up. The cameras dropping offline are a hot mess though, since those have no local storage option.