nevir

Their seed round was in 2010—early investors are likely pretty interested in an exit

Apple makes the rules; and they're mostly concerned about digital marketplaces that _could_ operate purely via IAP

I don't think it's actually been advertised anywhere - welcome to a very small group of cool kids ;)

Consider larger services than a typical microservice.

For the same reason monoliths tend to split when the organization grows, it is often more manageable to have a small number of services per team (ideally 1, or less).

It's ok if a service owns more than one type of entity.

It's less good if a service owns more than one part of your businesses' domain, however

The 30% fee only applies to digital goods, not physical ones. It's part of why there's all the awkward hoops that the main amazon app goes through when you run into digital goods, but everything else is mostly sane

> p.s. Do you know how I would go about recommending someone add the ability to have green or amber text on the black background?

If you're on Android:

1. go to Settings -> Info -> About

2. Draw a lowercase h on the screen (anywhere), and you'll see a "special color mode enabled", and should get amber on black. another letter gives you green on black, but I forget which :( . There's a bunch of hidden color combinations there :)

I'm not sure that exists on iOS, though

---

For requesting it: help & feedback -> contact us -> give feedback is your best bet. I'm out of touch w/ the Kindle team, but at least several years ago many of the devs would obsessively read customer feedback (that wasn't deemed sensitive/PII)

Also: there were multiple ebook readers on the store at the time that were already selling books in-app. Several stopped development, others removed their in-app store.

I suspect we (Kindle) we're either the trigger for the in-app purchasing store, or really accelerated plans around it.

Yeah, it was supremely frustrating for us. The original store experience was fully native, and still a far better experience than what the app has today :(

Apple did the same thing to Kindle for iPhone back when it launched.

We submitted the original version to Apple with a fully functioning store built into it—and were then stuck in submission limbo. Two weeks later, Apple announces their intent to build in-app purchasing.

The kicker: Apple wanted a 30% cut of every book sold on the store …and at the same time, had negotiated with book publishers that the publishers MUST sell all books at a 30% margin on ALL stores if they want to sell their books via Apple's own ebook store.

Aka we couldn't sell books at an increased cost, even if we wanted to. We would have had to take a loss on every purchase.

In the end, we had to remove all of the store functionality from the app, and weren't even allowed to link people directly to the web store for purchasing (or even instructions for purchasing).

Why is that?

The implementation for promises is currently a pretty heavy performance hit:

https://docs.google.com/document/d/1y4lF-iQhhuSOgzlPIBbfCT4I...

The node and v8 teams are working to improve that, but the work hasn't all landed yet

Might be a conscious choice?

It's still a concern, but often forgotten.

I think they've done a pretty good job of codifying their values via the slides at the bottom of the first article:

https://www.slideshare.net/AmyCowpe/high-performance-behavio...

Yeah, I'd also add that it is a huge help in ramping up new devs when understanding your schema.

An alternative architecture (following the BFF idea):

* Non-GraphQL services (speaking REST, gRPC, whatever) * GraphQL gateways, owned by frontend teams/applications.

E.g. each frontend team/application owns its own schema owned by these teams. They can compose the backend services however they wish—and whatever is the most natural representation for their domain.

I would concur. The BFF pattern works really well with GraphQL.

I think 'One Graph' makes sense if that's how you model your data under the covers (e.g. Facebook's graph store)—but if you're in a service-laden world, it makes far less sense.

My God, the grammar of that title.

Google's promotion process biases very heavily towards "impact".

The problem is that maintaining existing projects generally isn't considered to be a demonstration of impact (or at least, it's a MUCH harder case to make). It's much easier to make the case that greenfield projects demonstrate impact.

Additionally, engineers have a good amount of power over what they get to work on: managers generally have to convince them to join a team. It's nice in concept, but lacks a steady influx of unwitting new engineers to help support all the not-so-sexy projects (like many other companies).

…so, you tend to see a pattern of engineers building a new thing, launching it, and then moving on to the next project. Leaving a trail of poorly supported projects in their wake.

At our company we've implicitly split the technical ladder at the principal level into "broad" principals (this article), and "deep" principal (expert at their field).

We're struggling to formally define it, though. How much pure IC work do we expect of broad roles? How much coordination/communication do we expect of deep roles?

Senior levels often have pretty wide bands, partially due to this. If you're moving to an organization that hires as senior, you'll almost certainly be able to negotiate your comp pretty far up

Though I am a principal that tracks very closely to what this article describes, I think eng organizations need both "broad" and "deep" principal technical roles.

E.g. at that level, the road forks three ways: deep principal ("pure" IC, & an expert in an area), manager, and broad principal (the hybrid force multiplier role).

The tricky part is making sure that the deep role doesn't devolve into promoting people purely on technical merits, and being blind to their cultural impact. Everyone at that level is a role model, for better or worse.

Apple only allows/signs one cert per company. And the process to get one requires an annoying amount of paperwork about your business

npm has eroded so much of my trust that I am hesitant to switch back to it any time soon. I've tried npm out every few months (since npm 3), and have consistently run into infuriating bugs or unexpected behaviors.

Much of it has been fixed over time, but the frequency and duration of these issues is concerning—and, I think, points to architectural deficiencies being the root of the problem. (And the project is so massive that it's understandably a really challenging thing to manage and triage)

For example:

* npm 5.0.0—5.7.0 didn't play nice with git-based dependencies (https://github.com/npm/npm/issues/17379)

* npm 5.0.0—5.4.1 edits package-lock.json unexpectedly (https://github.com/npm/npm/issues/17979)

* npm 5.0.0—5.4.? doesn't honor incompatible version differences in package.json compared to package-lock.json (https://github.com/npm/npm/issues/16866)

* Take a look at the issues labeled as [big-bug], and how long they've languished (mostly from the v3 era): https://github.com/npm/npm/issues?q=is%3Aissue+is%3Aopen+sor....

* and a bunch of others I can't remember off the top of my head; especially nondeterministic behavior in the v2 and v3 era.

They treat their employees relatively well - and for many people, that is more important than the company's external /social behavior

Typescript also supports type checking pure JS files, as well as type annotations via JSDoc comments, if you don't want to transpile.

If it helps set context, I got my perspective as a developer on the Polymer team

Web components work very well in isolation, and/or within a homogenous web component framework/library.

However, it is still pretty challenging to pass data throughout web components (in a way that allows you to build a complete application). HTML attributes are not great for data transfer (string serialization for everything). JS properties are a bit opaque (not represented by markup). And everyone ends up wanting some sort of property binding system, which may be unrealistic to standardize.

I think there will always be a place for some amount of framework/library support necessary for application builders.

GraphQL has no demands on your data model. You can do whatever you want behind the schema you provide to client apps

Isn't the other half of the statistic something like "the top 0.1% of U.S. taxpayers earned majority of income"?