It's honestly better than this on all fronts, since you can get ProRAW out of recent iPhones even in the default camera app and get RAW without DeepFusion out of different alternative camera apps.
I think I had to spend ~$1k to get my first DSLR with RAW support back in the 2000s. Adjusted for inflation, Halide + a recent iPhone feels like a pretty good deal.
FYI, the reason the pw change requirement went away is because NIST published an updated set of guidelines that explicitly disrecommend it: https://pages.nist.gov/800-63-FAQ/#q-b05
On the vendor / policy side, many/most of these questions trickle down from NIST or similar institutional guidance. The auditors pick up on that and on practices from comparable companies they've audited, which can be helpful when your industry is moving towards sanity and painful when there's a meme that makes no sense in your context.
(If you spend significant time dealing with customer compliance issues, I would definitely vote that it's worth being familiar with the relevant subset of NIST pubs.)
You can run a SOC2 compliance program earnestly or as a check-the-box exercise.
If you're running earnestly, I would argue that the hardest thing about a SOC2 is ensuring that you stick to your guns on approaches that work for you and not adding cruft that you don't care about. If you let the latter happen, you will invariably end up a box-checker, and being a box-checker eventually contaminates a robust engineering / security culture.
And it's hard to walk back more restrictive / cumbersome policies; if you delegate your SOC2 to a person who doesn't deeply care, they'll eventually agree to put ClamAV on all the hosts or something (to make the auditors go away) and then you're going to be stuck with that for a while.
(So you need to find someone who has enough business context and good judgement to run the process, which is super painful from an opportunity cost perspective at a startup, and hard to locate at all at a larger company.)
> If you're running earnestly, I would argue that the hardest thing about a SOC2 is ensuring that you stick to your guns on approaches that work for you and not adding cruft that you don't care about. If you let the latter happen, you will invariably end up a box-checker, and being a box-checker eventually contaminates a robust engineering / security culture.
That's spot on, not only for SOC2 but for many, if not most, relevant certifications. The most important part is "not adding cruft". Nothing sucks like being stuck in a ISO9xxx certified process because you over-specified your processes even though you'd get the "ISO9xxx-certified" label for 10% of what you did. Suddenly you cannot react with common sense anymore because doing so would violate contracts you made with exactly those big customers you got the certification for in first place.
> if you delegate your SOC2 to a person who doesn't deeply care, they'll eventually agree to put ClamAV on all the hosts
Bingo. Just spell out the consequence: you no longer can optimize your compute costs by switching to a managed Kubernetes, because there is no ClamAV there.
If you're an engineer and have trouble getting past project management methodologies that feel like bullshit (or conversely if you care a lot about them but have trouble convincing your team to) you must read "Principles of Product Development Flow".
It's definitely a pretty dry read in parts, but battle through it.
I'm certain all 37s employees have access to the production database anyway; they're still a fairly small company.
The only real additional risk here is running non-production code against live data; e.g. the risk of a feature branch sending extra email to customers. Given the nature of their products this is probably manageable, assuming they don't run batch jobs (via eg. resque)
We're about to open source a similar deal (redis-based "soft guarantee" mutexes) -- ours is written in Python and mostly used as a way to coordinate (very frequent) parallel task execution a la CountDownLatch, so 100% reliable exclusion in the face of failure isn't critical.
I'd be interested to hear about your implementation if you can share (email is HN username at gmail.com)
Everything old is new again. Email status is a check-in method as old as, well, email.
This works great if you have a reasonable number of people working largely on independent areas, or if your pace is slow enough to drive consensus through email.
If you need to reach team consensus regularly and quickly, e.g. on architectural or design decisions, synchronous standups are still better, even virtual ones over IRC or FaceTime or whatever. (If you hear people saying "wait, why/when did we do that?" a lot, you may be in this situation even if you'd rather not be.)
I'm not a standup (or capital-a Agile, bleh) zealot by any means, but if you've got more than two people working closely on an area, and you're going quickly, regular and delineated synchronous communication still beats email threads for efficiency.
Agreed. It depends a lot on the team and the project. Our team of six devs had stand-ups every 90 minutes all day every day for 9 months when were all touching the same app. It was appropriate and we got a lot done. When the nature of our work changed, we switched back to a daily stand-up.
I think a huge part of the appeal of Mailbox is it's less than a full-featured project management/GTD tool -- it basically prescribes a certain approach to managing your inbox (do, defer, archive.)
I was a GTD-ish person before Mailbox came along, so I had a system for handling these things, but I know a ton of people who either never made the effort or repeatedly tried and failed to get onto some GTD/task management system; often, I think, due to tyranny-of-choice type issues.
Post-Mailbox, I still manage my commitments in Things, but I manage my "accept queue" (if you will) via Mailbox-- "triage" is really an excellent way to put it. Sometimes the resolution is "I'm too tired to think about this, tell me about it again tomorrow"-- and that works a lot more seamlessly than Boomerang, hitmelater, etc, IMO.
(disclaimer: I have no financial interest in mailbox/orchestra, but I know-- and like-- the team and have given them small amounts of technical advice.)
One of the things I think people who haven't spent a significant amount of time living in dense cities miss is that you do very little "living" in your apartment.
I spend maybe two hours a day awake in my (reasonably large for SF) apartment during the week, tops. The rest of the time I'm at work or out in the city somewhere; I treat the local downstairs basically like my living room.
It's not a lifestyle for everyone, but I consider the entire city my living space and I don't think it's abysmal at all.
That's a good point, and you're probably right about folks who haven't lived in large cities like that. Everyone's experience is different, I guess I was just expressing my own personal experience against the article.
I think I had to spend ~$1k to get my first DSLR with RAW support back in the 2000s. Adjusted for inflation, Halide + a recent iPhone feels like a pretty good deal.