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.
> 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
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.
> 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?
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.
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.
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.
[core dev] If you like to think about your application starting with its API, I think you'll really like learning more about DDP [1], the websocket JSON-based protocol that Meteor clients and servers speak. This is one of my favorite parts of the stack.
Rich clients built against a REST API tend to need some sort of client-side cache so that clients can avoid repeated RTTs back to the server for data, and thus some sort of websocket-based invalidation system so that the server can push fresh data into that cache in real time. That's doable, but a total bummer for interoperability and shared tooling. Since the implementation of those things is usually custom to each app, it's rare to see one real-time app connected to another the way we can bolt server-based REST apps together. And there's no `curl` for this kind of endpoint.
DDP is actually quite simple. The spec is just a couple pages of markdown. It lets servers publish changing data sets to the client and it implements once-and-only-once remote procedure invocation. It runs over a websocket or over SockJS. Eventually we'll also define a binary TCP/TLS mapping for use between servers.
When you write `Meteor.publish` in a Meteor server, you're defining a real-time DDP endpoint, like a streaming version of GET. The server makes the common cases easy -- publishing a realtime MongoDB query to a client is a one-line function in Meteor -- but you also have access to the low-level DDP messages if you want to do something more advanced like publishing the output of a GPS sensor or a stock ticker.
There aren't any special bindings between Meteor clients and servers, just the standard DDP messages that go back and forth. So you can implement either side of the wire using something else. And there are some third-party implementations of both the client and server in the field now. You can write a Meteor front-end against a Java DDP backend. You can connect a native iPhone app to a Meteor backend. Or you can have two Meteor server processes, one subscribed to the other. (There's been discussion of all these cases on the mailing lists. We use server-to-server DDP heavily in Galaxy, the hosting product we're working on.)
The Meteor core team uses Hackpad for almost all our internal text -- technical design documents, checklists and procedures, note taking, drafting emails and website content, and documenting much of what we do and how we do it. I find the spare UX just about perfect for getting ideas down.
We've also experimented with using public hackpads for some core framework design discussions once or twice. It feels like a promising option. I hope we can try more of this.
the suggestion was “orthocode”.