rmaccloy
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.
I'm sure they incrementally rolled this out so it's possible you are in a cohort that got this change earlier.
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.)
It's definitely a pretty dry read in parts, but battle through it.
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)
I'd be interested to hear about your implementation if you can share (email is HN username at gmail.com)
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.
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.)
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.
Separately, I think it's great if you can have all of your employees involved in the support and outreach process, but that's a cultural thing and thus a bit harder than changing a mail header.
I've done this manually a few times, but with foresight attaching signal handlers that open up a port or dump stack (a la `jstack`) is usually less finicky.
If you have a cage, it's the datacenter (peering, power, environment, physical security.)
Do you need to care about these things? Probably not. (But maybe you do, and you happen to care less about price, or database write latency/throughput/predictability, or...) Pick whatever set of tradeoffs works for you.
It may be somewhat easier at a company that's dealt with the process before, but most valley startups will have access to experienced immigration attorneys.
For schema changes, there are a bunch of approaches. Just a few:
* Treat (non-purely additive) schema changes as a special case and take extra care deploying them. (This sounds like a cop-out, but it might be the right effort tradeoff for many startups.)
* Write forwards and reverse migrations for each change, and avoid data-losing schema changes.
* Implement all (or all non-purely additive) schema changes by shadowing data operations onto a new version of the schema (asynchronously migrate all previous data onto the new schema in some back-end process.) Write tests to verify the migration/shadowed data is correct. Switch data reads to be on the new schema. Eventually delete the old schema in a subsequent deploy after an appropriate stabilization/verification period.
I find #3 to be the most general, but there's plenty of overhead (computational, storage and man-hour) that may not be appropriate for your case.
Server affinity + staged rollouts are another approach, but for long timeframes (e.g. A/B UX tests, feature prototypes) I'd think you'd want to go with flagging anyway from a codebase management point of view.
Some things do take more effort to make dynamically flaggable than it would take cost to delay integration, to be fair. Judgement call.
Google and Facebook both have a consumer-facing presence so you think of them as being more accountable, but they're both advertising businesses, no doubt.
cfengine has been around longer, but seems to have negative adoption since puppet became well-known. I know a few people who swear by it, though.
FWIW, at my current startup I use Chef to manage a mid-sized collection of servers (app, load balancers, DBs/replicas, task processors) where the app is written mostly in Python, and it took a ton of pain out of scaling up to deal with a very large paying customer two nights ago.
Puppet has better documentation, but learning either is a bit of a trial and error process I think. You might find Blueprint (https://github.com/devstructure/blueprint) useful to bootstrap (the authors are around in the HN community, I think.)
From Scott Walker's blog: http://walkercorporatelaw.com/startup-issues/ask-the-attorne... http://venturebeat.com/2010/03/01/ask-the-attorney-what-the-...
Recent Emacs have git support in VC; I tend to just use that since I tend to do anything other than committing (rebasing, switching branches, merging, pushing, etc.) in a terminal.
I use this constantly in deploy, etc, scripts so I can run my compile + rsync + deploy command in a terminal, background it, and go work on something else until the process finishes. I'd say it's generally useful for anything that takes longer than 10 seconds but less than an hour (after an hour you tend to forget what's going on; might as well just email yourself.)
Festival (http://www.cstr.ed.ac.uk/projects/festival/) is something similar for *NIX users.
I think it's quite dangerous to assume such provisions aren't going to make it past whatever partisan wrangling goes on; I doubt either the dems or the GOP are going to give much of a damn about the startup ecosystem unless a lot of noise gets made about it.
http://www.avc.com/a_vc/2010/03/startups-get-hit-by-shrapnel...
http://www.huffingtonpost.com/robert-e-litan/proposed-protec...
I'm surprised this hasn't been brought up more on HN. I'm not against bank reform, but these provisions seem clearly detrimental to prospective founders without providing any actual protections to people who need them. Correct me if I'm wrong...
Neither are useful for the Digg usecase. Edit: That is to say, they're optimized for large datasets, low concurrency, medium latency, medium-to-high consistency and medium-to-low availability.
Same for MySQL, modulo (possibly) the Drizzle project.
Oracle has a lot of different irons in the fire, but "cheap scaling" isn't one of them. (If you've got the money to burn... TimesTen?)
That's not a knock on any of the above, it's just a different use case.