[I work for MongoDB] For your use case, I would consider just holding all of the data in MongoDB. With an appropriate data model, you'd be able to quickly retrieve the information you need for the initial page display as well as article details.
This isn't to say that there aren't use cases that might be better served by either database or a combination, but for your particular use, you may not be gaining enough to offset the added complexity of using two different databases.
Obv. I'm biased, but I would recommend using MongoDB :)
A plane heading to Japan from SFO would be carrying quite a bit of fuel. It's possible / likely that the takeoff weight would exceed the safe landing weight, requiring circling to burn off fuel or dumping fuel. If they have to get rid of fuel anyway, it might make sense to continue to another airport where they could get a replacement aircraft.
In addition to that, SFO is already down a runway which is causing some delays because planes need to go around the construction zones. An airplane with a potentially damaged landing gear can close all of the remaining runways due to the cross layout that SFO uses. LAX is laid out a little differently, so you aren't risking having the whole airport close for a while if something does go wrong.
When combined with the need to burn off some of the fuel, LAX seems like a sensible choice. You don't need to travel over any particularly tall terrain, LAX is large and should have sufficient runways for an airplane that might have trouble coming to a stop quickly. Since there was no issue with actual in-flight operation of the airplane, it's also not a 'land right the frak now' situation.
Is SFO a maintenance hub? That could be another variable, if the repair facilities in LAX are better.
And then there’s a potential bias against SFO, given they just let an airplane take off that HAD A WHEEL FALL OFF. Maybe they aren’t the best party to examine the plane just now.
> 6. North American outlets are rated for ~15A * 120V. So roughly 1800W. I can just use one outlet per psu whenever it's under 1800W, right? For simplicity let's also ignore whatever load is on that particular electrical circuit.
You're going to have a bad time with this assumption; typical non-kitchen household circuits in the U.S. are 15A for the circuit. Each outlet is usually limited to 15A, but the circuit breaker serving the entire circuit is almost certainly 15A as well; one outlet at maximum load will not leave capacity for another outlet on the same circuit to be simultaneously drawing maximum amperage.
Typical residential construction would have a 15A circuit for 1-2 rooms, often with a separate circuit for lighting. Some rooms, e.g. kitchens will have 20A circuits, and some houses may have been built with 20A circuits serving more outlets / rooms.
You probably shouldn’t be coming to HN for legal advice, which is what you need.
In any case, you’ll need to dissolve the Delaware Corp in Delaware and unregister(?) the California foreign Corp. registration. You almost certainly owe taxes to CA and taxes / fees to Delaware.
I strongly recommend talking to an attorney who specializes in corporate law, at least having a consultation to enumerate the steps necessary.
This doesn't sound unreasonable to me, especially as a solo developer. I think it's important to make sure your customers understand that they may not be able to download their installer in the future.
Perhaps sending an email reminder _n_ days before expiration of their one year free maintenance and reminding them of that (and perhaps offering an upsell to renew for an additional year of maintenance)
Outside of military / national security or if your agreement with your employer stipulates that you would give up your life before corporate secrets (and you are compensated accordingly) it's not reasonable to characterize cooperating at gunpoint as "cowardly"
I agree, I still think it's a reasonable word to include in the instructions though.
What you don't want is them holding back how much they co-operate with the red team in the drill because they think that's how they would act, or they'd like others to think that's how they would act. Even if it is how they would act, you'd presumably like to know that your security measures would still work even if someone else was in their positions. But also, it's pretty obvious that no-one (or very very few people) know how they'd really act in that sort of situation.
I thought (edit: And still think, but acknowledge that it is not yet a well thought out plan) putting that word in was a nice short form way of achieving that goal, though in a real drill you'd want to communicate a whole lot more about that than the 3 words I used. And probably also communicate that were this to happen in a non-drill form, that you don't expect them to resist.
Incidentally, it's hard for me to imagine that there are many organizations outside of the military / national security that include armed invasion of their offices in their threat model, though I suppose some multinational corporations might.
I can see the engineering appeal in this idea: testing beyond the expected operational envelope will tell you which parts of the process break first.
As for applicability, every now and then you hear a disturbing story of some office being raided by the police / anti-corruption force - this is not unrealistic if you're e.g. a news agency in a country whose government doesn't always respect the freedom of press.
Spending four paragraphs justifying how well a word communicates something when you could just replace it with the phrase “to simulate not brown-nosing (I would die for this job)”.
You know the saying "I didn't have time to write a short letter, so I wrote a long one instead" (Mark Twain, maybe). Ya, that's what I did, your version is just better.
> and yet the plane appears to have no mechanical backup instruments[?]
This is unlikely in a modern aircraft because mechanical instruments to back up e.g., the artificial horizon / attitude indicator or directional gyro (DG) / heading indicator are:
1) Mechanically complex - the attitude indicator and DG make use of gyroscopes which rotate at up to 24,000 RPM along with other mechanisms. They are typically powered by vacuum or electric motors which consume relatively more power (or require vacuum lines and a vacuum pump)
2) Expensive to maintain - see (1) - they need to be serviced somewhat regularly
(3) Heavier than their solid-state counterparts
(4) Have [dramatically] different failure modes - instead of a display going dark, a DG will slowly drift as the gyroscope precesses, giving erroneous values. Same with the artificial horizon. This can lead to catastrophic results under instrument meteorologicalconditions (IMC) where the pilots rely solely on instruments to maintain essential things such as heading and level flight.
(5) Because of (4) they require additional redundancy to ensure instruments can be cross-checked with one another. This compounds (2) and (3)
I think you are overstating the impracticality of mechanical standby instruments. Even glass cockpit GA aircraft typically came with fully mechanical backups until fairly recently---check out this SR22 cockpit as an example: https://commons.wikimedia.org/wiki/File:SR22TN_Perspective_C...
"Glass" standby instruments come with significant upside and not much downside, which is why they've been preferred in larger/more expensive aircraft for a while. There is nothing inherently more or less reliable about them, being fully isolated and redundant just as old-timey mechanical backups are, and they offer a much richer presentation (typically like a small PFD). However, new things are usually more expensive, which IIUC is why they were adopted first in larger, more expensive aircraft. They were considered a luxury in GA until fairly recently.
Plus the pilot stress of having to adjust to using dramatically different instruments when already in a difficult situation.
It's just not a workable idea in general. There are checklists for stuff like instrument failure which can probably recover from a software bug like this.
It's absolutely a workable idea. Standby instruments are typically a requirement for glass cockpit aircraft, and before electronic standby instruments came onto the scene mechanical instruments were used in the standby role in (AFAIK) all sectors of aviation.
"Fly the airplane" is the highest priority in any aviation emergency, and in many emergencies you will need backup instruments to do so. I don't mean to be mean, but tbh it is a little absurd to suggest that a e.g. a pilot who loses her PFD in IMC is better off running checklists than using backup instruments to establish control of the aircraft and situational awareness, and bailing out asap. Sure, it's stressful, but it's also something pilots need to (and do) train for.
Once the aircraft is under control, you can run your checklists, or if you have a co-pilot you may be able to work in parallel. Maybe you will be able to fix the issue, and maybe you won't, but backups give you a shot at landing safely either way.
I think backups for the electronic systems would not need the same level of redundancy as the primary systems (which presumably already have backups).
It's sort of like how you don't need RAID for your offsite backup disks, just some parity for bit-rot.
The mechanical instruments would be the (additional) redundancy. The additional weight/lines/service is indeed burdensome even without redundant mechanical systems.
> I think backups for the electronic systems would not need the same level of redundancy as the primary systems (which presumably already have backups).
If your backup is failing more often than your primary system then it's not much use as a backup.
Also, there ARE backups. There's fallback artificial horizon boxes that work independently of the rest of the system, for example.
That’d be frustrating, not just for this. I’d probably be looking into a solution like Tailscale to tunnel out. Or just develop a gnarled security rule list full of rich history. :)
This isn't to say that there aren't use cases that might be better served by either database or a combination, but for your particular use, you may not be gaining enough to offset the added complexity of using two different databases.
Obv. I'm biased, but I would recommend using MongoDB :)
Here's a reference for some design patterns to consider: https://www.mongodb.com/company/blog/building-with-patterns-...