rmaccloy's comments

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.

Yes, they expanded the context window, announced two days ago: https://github.blog/changelog/2023-08-28-github-copilot-augu...

I'm sure they incrementally rolled this out so it's possible you are in a cohort that got this change earlier.

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.)

Co-sign.

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 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.

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.

Even if the reply-to just dumps responses into a customer support queue, that's better than 90% of mass mail is doing.

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.

This page appears to be positively ancient, referencing FreeBSD 5 and Red Hat 8, and a bunch of the technical differences are incorrect now; the Linux kernel hasn't used stable/unstable versioning in forever and is entirely on git, every GNU/Linux distribution has easy binary package dependency resolution and retrieval, etc.

This actually exists, sort of: http://pyrasite.readthedocs.org/en/latest/index.html

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 single-rack network, now your single point of failure is the rack switch or PDU. (This is why e.g. HDFS has rack-aware mode.)

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.

In the bay area, given the current market, any reasonably funded startup would likely work with you, assuming you passed interviews, etc.

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.

Soft-delete (+ action logs) for data recovery. Also, code review and lots and lots of tests.

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.

They're not mutually exclusive: you want basic correctness/design review of course (my favored approach is now pre-integration code review + authoritative master/master-always-deployable), but a proper feature-flagging system will let you beta or A/B test potentially incorrect (in a code-correctness, performance, or UX sense) changes gradually in the real world. Binary (on/off for everybody) flags are more the exception than the rule.

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.

Facebook and Google both do their own targeting (obviously.) Google allows access to some data for 3rd-party firms via RTB. Neither pass on PII (or really any non-aggregate) data to advertisers, AFAIK, I'd be surprised if Specific did either.

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.

Puppet and Chef are pretty agnostic. You can use them to manage only your infrastructure (packages, user accounts, databases) and leave app deployment up to something like capistrano or fabric if you like (although at a certain level of app complexity it makes sense to integrate.)

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 my understanding, you're describing (edit: something like) Series FF (i.e. what Founders Fund issues) there-- the founder's institute stuff has certain additional voting rights attached in additional to liquidity provisions.

From Scott Walker's blog: http://walkercorporatelaw.com/startup-issues/ask-the-attorne... http://venturebeat.com/2010/03/01/ask-the-attorney-what-the-...