jabzd

We actually had it that way on accident in a few of our applications - we had a `#isTextable(e164)` function that would do a carrier lookup and voip carriers sometimes returned as landlines or as arbitrary values that didn't mean mobile. We eventually did some work to refine that function to be smarter and actually better represent if the number was textable. At least for us, it wasn't a conscious decision, it was a gate being aggressive in our SMS pipeline.

Yes, can confirm I am seeing the same behavior. Other members on my team in other regions are able to resolve addresses - seems to be hit or miss to a degree based on location.

This is exactly what we do as well and the approach works pretty well. We also tag the associated git repo with a build id and branch name so by looking at the git repo, you can tell if and when something has been built.

It was a preface to that list, as in "if you don't solve this one, don't bother reading the rest of the list." That makes it the most important thing...that's how I read it anyways.

I consider it "serverless" similar to how "stainless" steel only lessens, but isn't a full 100% guarantee. That makes me feel slightly better about the term, ha.

For what it is anecdotally worth, this has gotten better. It launched in Chicago at least a year ago and the first few orders my wife and I placed, I felt like I should have shopped myself for how many items weren't found and how much hand holding the shopper needed to replace items. We almost gave up on it, but with a baby in the house my wife kept with it and the replacement feedback loop has really gotten much better. Nowadays, out of a 25 item order, maybe 1 item is replaced and usually without a back-and-forth necessary (something reasonable is picked and you have the opportunity to reject it). Also, luckily, in the Chicago market most of the stores are "same-price-as-in-store" and the prices seem fairly reasonable where I mostly believe that.

I felt very similar. Especially thinking about it from a disaster recovery/re-bootstrapping perspective. That scared me into using docker swarm kit which is stupidly easy to bootstrap. Keep in mind that's not necessarily a like for like replacement but it was enough for my use case.

I've been keeping an eye out waiting to feel more comfortable to use and support a kube cluster on bare metal.

90% iOS app development, 10% familiarity.

We're a small shop so we have one team that does everything so one machine for all contexts is starting to be a pain. We did at least dust off some mac minis to do puppet (lots of virtual machines) work on those when possible to free up some RAM on our app dev machines.

Totally agreed on the value-add for those languages. We'll probably keep one license around for the times we drop into Java for Android which is fairly infrequent. Otherwise, we're a mix of JS (NodeJs/React/Appcelerator/etc), Ruby (via Puppet), HTML/CSS, PHP, Python, etc. IntelliJ was overkill in the first place but the one IDE to rule them all is just too compelling to not give it ago. Worked for 2 years, the product has just gotten too slow now.

My gut reaction is that IntelliJ's indexing isn't yet properly optimized for the small-file dependency-hell that JS dev has turned into.

The unfortunate thing was that we were willing to upgrade to the newest Macbooks if they had 32GB of RAM and hope that helped (in addition to some VM woes for working on infrastructure) - probably would have kept IntelliJ in play but the swapping and it using 33% of RAM on our machines made it an easy target to try to replace.

In comparison, VSCode is using 70MB RAM on my machine currently with 6 projects open.

I was at 600% CPU and 5GB of RAM with 3 project windows open, for IntelliJ Ultimate (we hop between a lot of languages so this is easiest). This was with most inspections turned off!

I've also moved to VSCode and haven't looked back. My whole team is currently evaluating VSCode. That is ~$600/mo in subscriptions to IntelliJ Ultimate if everyone decides to move to VSCode - which is looking likely.

In Chicago, some recruiters have started asking for 30%. I've refused to work with these companies but rates are definitely going up.

We are currently moving to using Docker swarmkit (from non-Docker environment). We thought about using tags to communicate environment but it felt like an anti-pattern given how tags work. What we ended up with is the following:

Per publishable branch (e.g. master to prod, dev to QA, shared integration that isn't ready for dev to secondary QA):

- Publish image to private docker registry with tag in the format of <branch>-latest (e.g. master-latest, dev-latest). Also add labels with git revision hash and CI build number to reconcile what is in the image both in CI and in git repo.

- Capture the digest of the published image and put in .txt file as an artifact from CI.

- Add a tag to the git repo with the build number, treated as version number in the form of v<build-number>-<branch> (e.g. v1-master).

- Maintain list of applications' docker image digests that should be running in each environment. We currently have this automatically determined by pulling the digest artifact from the passing-build digest. We do allow for manual overrides, however.

- We have a CI project that updates the docker swarm with these digests and other settings (replicas, mounts, environment variables). We wrote a small tool that does this similar to where stacks/dab files are going but with more functionality.

With the labels and published digests we can go from build to digest, digest to build, etc.

This is working really well so far and we aren't fighting the tools. We may separate the non-master registry later in life, and that's really easy given that docker treats the private registry hostname as part of the tag.

In one keynote I went from being excited about what was coming to feeling held hostage, yet ignored, in the Apple ecosystem due to iOS app development. 16gb of RAM is just too limiting for some workloads.

I may need to outfit my team with powerful linux desktops and low end macbooks for app development and remote/emergency work.

Pertaining to your edit, apologies for over-simplifying originally. You are absolutely correct that the Security Rule is very very vague. Many HIPAA audits barely reference the Security Rule and instead use stronger rule sets. Unfortunately, HIPAA is generally documentation of policies as opposed to true technical guidance and requirements. We're also an 8 year old SaaS company so many of our agreements pre-date the "cloud" catching up from a complicance perspective. At the speed of healthcare, I imagine it'll take another decade for the industry to realize that an AWS cloud is probably more secure than something a 10 person organization can cobble together.

Not so much HIPAA directly, but the business associate agreements that many customers make use of. In order to meet the requirements of many of the agreements we have in place, we have to own any and all hardware that PHI data lives on. They don't exactly accept redlines on those kinds of agreements.