andrewjshults
Joined 16 years ago
Karma
263
Submissions
145
Member since
Sep 12
Recent submissions
Comment · 7 years ago
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.
Comment · 10 years ago
(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.
Comment · 10 years ago
Longer blog post here: http://dna.hioscar.com/2015/10/14/scaling-deployments-at-osc...
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.
Comment · 11 years ago
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]
[1] http://www.dcrainmaker.com/2014/05/scosche-antbluetooth-opti... about 10% down the page [2] http://www.dcrainmaker.com/2014/05/scosche-antbluetooth-opti...
Comment · 11 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
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.
Comment · 12 years ago
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)
Comment · 12 years ago
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).
Comment · 12 years ago
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.
Comment · 12 years ago
If you haven't signed up for their beta program, I'd recommend it. At least on the android side the app is much nicer than the one in the app store.
Comment · 12 years ago
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)
Comment · 13 years ago
A bit further down the page, they cite Zapier
"Over a representative time period, Zapier polled for changes 30 million times but only took action on 460,000 of those polls (1.5% efficient)."
{username}@gmail.com