debergalis

[founder here]

the suggestion was “orthocode”.

Thanks, looking into it. I agree and I hope we're able fix this. We're moving all of the Apollo docs to the same system. It's built on Gatsby, which uses GraphQL under the hood.

Agree. And congrats on the round.

[author here]

> So assuming what we did wasn't good, what is a way you might make this work? Do you have a single code base like we did and just be more disciplined? Do you have a project whose job is to stitch together other schemas and pull in submodules? A monorepo for the entire company? Do you actually limit what the idea of the company is at some point to limit what the scope is that this should cover?

I think these are great questions. One approach that looks promising is the idea of modular schemas that can be stitched together into a larger graph. Quite a few large organizations are doing this now. I recommend watching a recent talk by Martijn Walraven for more on this idea: https://www.youtube.com/watch?v=OFT9bSv3aYA

[author here]

Yup, we see this pattern a lot. You get the benefits of fewer bytes on the wire, typed APIs, elimination of data fetching code, etc.

But it leaves a lot on the table. The bigger wins come when new features can draw from all your data (in unanticipated combinations) without new API or services development, when you can make new data available for every team's use just by plugging it into the central graph, and when you have a birds-eye view of exactly how all your data is being used so you know where to make further investments.

[Apollo cofounder here — we are indeed the same team that built Meteor.]

Yup, all three are customers.

> I am thinking a major reason for the longevity of the Cessna training line is more to do with cost for budget conscious training schools, rather than being a better aircraft that any other trainer.

Yeah, budget and familiarity. I doubt Cessna is selling many 172s to anything other than flight schools.

Cirrus just certified the SF-50 Vision, a new single-engine VLJ.

Cessna doesn't call it this, but the Mustang is pretty close to VLJ sizes. (Not many being made though, as their M2 pretty much took over that space of the market.) The Embraer Phenom 100 is similar. Both have been reasonably successful.

Yes, the lead raises the effective octane, preventing detonation. The other tool for preventing detonation is running extremely rich fuel/air ratios, the typical setup for the airplane at full takeoff power.

You target an appropriately rich mixture at sea level when tuning the carb or adjusting fuel flow for injected engines. The pilot manually leans the mixture as the aircraft climbs to maintain a reasonable fuel/air ratio.

Owners sometimes call that mixture lever the money lever because it governs fuel flow, aka "dollars spent per minute".

Engine manufacturers typically specify a TBO -- Time Before Overhaul, which is the number of hours in service an engine can run before it needs to be torn down, inspected, and overhauled according to the manufacturer's procedure.

For the most part, commercial operators must adhere to these recommended times, but aircraft operated under FAR Part 91 (roughly, those that aren't used for commercial transportation) aren't required to follow the TBO recommendation. You can run it as long as you want.

In practice, most operators do follow those guidelines. I've never heard of any engine doing much more than 2x the TBO before requiring major overhaul. And you'll often need various repairs to cylinders and engine accessories along the way.

Interestingly, manufacturers also specify calendar time limits on TBO, but private operators commonly ignore these. Lots of airplanes only fly 25 hours or so a year.

Aircraft piston engine efficiency is actually quite similar (measured in brake specific fuel consumption) to modern auto engines. The Lycoming O-320 in a Cessna 172 burns 280 g/kWh. Modern auto engines like the EcoBoost burn not much less -- ~250 g/kWh. See https://en.wikipedia.org/wiki/Brake_specific_fuel_consumptio....

Moreover, aircraft engines like the O-320 can run for hours at continuous max power output. Good luck doing that with a car engine.

Car engines absolutely demolish aircraft engines on emissions, though. They have O2 sensors, computer-controlled ignition systems, and catalytic converters, whereas aircraft piston engines have fixed ignition timing and burn extremely rich of peak (meaning massive emissions) at takeoff power. And on top of that, while little engines like the O-320 can burn ethanol-free autogas, the big piston engines like a Continental IO-550 require leaded fuel, adding another pollutant to the mix.

Would you mind sharing what metrics and analysis are the most important for your GraphQL API? (Or what you would find most valuable if you could get it?) What tools do you use today?

[I work on Optics.]

This is a most unfortunate framing. Politics is not toxic. It is the means by which our society discusses and makes big decisions. Perhaps s/Detox/Vacation/ could have worked?

Certain types of political discussion most certainly can be toxic. I'd support any effort to keep HN free of that. I'd also respect a choice to keep HN completely free of politics if you chose to go in that direction, though I'd rather see a more positive attempt to get the HN community more engaged with the serious political issues of our time.

[i work at meteor]

Meteor's hot code push on mobile is more sophisticated than this. When you deploy a new version of a Meteor app, clients fetch and save the new client JavaScript bundle along with its static assets. Future launches of the installed app immediately run new code (even offline) without first requiring a round trip to a server.

[i work at meteor]

After we announced 0.9.2 and hot code push for mobile apps, many of our users wanted to be sure it was kosher. It's easy to get confused about this because the App Store review guidelines suggest that downloading code isn't okay. And many Meteor developers don't have a deep background in the iOS ecosystem. The cool part about 0.9.2 is you can build mobile apps with just your basic Meteor/JS/HTML5 knowledge.

Apple's formal developer agreement is both controlling and clarifying, and since it's a bit harder to find we thought it would be good to point Meteor developers at the key part.

One important difference between Meteor's front-end and Angular is how we track data dependencies and changes. As it happens we've been working on a Meteor manual and just published the first chapter on Deps, our 1kb library for doing this.

https://meteor.hackpad.com/Understanding-Deps-aAXG6T9lkf6