nevir

Go to the shady ones :-/

The headline is also, probably in reality: "A small subset of Google wants...'

Many of them don't have the options that you do.

In a lot of cases, I see variations of this when there was not enough up front thought put into the design (before writing code).

Slight tangent, but a good way to tackle that is to outline what you want to do (sketch the API you're going to fill in, etc), and run that by a reviewer

10 year support contract is certainly a good chunk of that

> they just want to be recognized for having suggested the problem

In a business setting, I find that this case is often more of the variety of "they are suggesting the problem, and are implying/expecting someone else to solve it" (where someone _may_ be you)

It helps to ask "what is most likely to change about the code I am testing?" when writing unit tests. Try to avoid testing those things, and instead focus on testing the code's behavior (quack)

Tabs for indentation, spaces for alignment

I remember hearing that Google's main critique with yubikeys is that the newer keys' firmware is no longer open source (and thus, no longer independently verifiable). And that was, apparently, a primary motivation for breaking away from Yubico.

I wonder if its firmware will be open source? The marketing page makes no mention of that

> the cost of keeping them must be at least 50 million per year.

There's a high likelihood that at least some of their work will be of value to the company—or, if everything pans out, they get a fancy new platform. The real motivation is probably somewhere in the middle (retention, product development).

This is a solid bet to make, especially when you are effectively not worried about the cost (thanks, ads!).

A lot of Google is heavily research focused like this: let engineers (mostly) freely explore complicated problem spaces. If it's a product—awesome!—see if there's market fit, and then grow it. If not, no problem; see where it, or parts thereof, can be applied elsewhere within Google.

Source: I worked there.

They can't be removed from disk, but can be fully disabled

As someone that worked at Amazon a long time ago—back when AWS was just getting started—can confirm (historically). Publicly there were a myriad of AWS services; internally all we could use was S3 (for many years), if we were lucky. AWS being born of Amazon's "spare capacity" is an urban legend.

Nowadays, I hear it's quite different, and much of AWS is more rapidly dogfooded.

Or for publishing all packages

The challenge here is that you cannot just go with signed commits—it would also need to authenticate a specific user/org, repository, etc. (Anyone can sign a commit)

Similarly, however that whitelist of identities is specified becomes another vector, without a lot of PKI

HTML is purely declarative.

Each HTML document describes what it wants to have rendered, but does not describe how it should be rendered.

Yeah, sorry, Perl is probably a bad example (I was really thinking of Mason, and even then it's a bad example). Pulled that from the list!

This argument is less about specific technologies, and more about patterns and practices.

For example: web UI started as declarative (HTML -> PHP), and then transitioned towards more imperative (jQuery, Backbone, Angular), and is now moving back towards declarative (React, Polymer)

The military is going to deploy deep learning on their drones, with or without Google's help.

I'd rather have more people working on the problem than fewer. More scrutiny should, at least, improve the work and reduce errors in the models (and, hopefully, that leads to fewer casualties)

¯\_(ツ)_/¯

and iPhone X navigation is eerily similar to WebOS' cards paradigm. Everyone copies everyone.

npm has eroded so much of my trust that I am hesitant to switch back to it (from yarn) 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. 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: 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.

---

Btw, I'm not trying to tear down npm contributors here; people have put in a monumental amount of work into the project, and the node ecosystem wouldn't be where it is without npm.

Also see https://github.com/othiym23/node-continuation-local-storage

When the primary thing you're evaluated for is "impact", it's a wonder that Googlers bother to maintain any existing products at all.

(Plenty do out of love for the product/customers/etc, but man it's soul crushing to not be recognized for it)

On the flip side, JG is an awesome hire for any company

WebAssembly is not a silver bullet, and is intended for lower level code than I think you expect.

There's little to no interop with the front-end world as we know it (aka the DOM), and any briding to it is still quite expensive. You'd have to re-implement lua's garbage collector in wasm, etc.

wasm is great for high performance data crunching—aka why it's so attractive for 3d engines, games, and the like.

It's less great for developing front end apps; unless you feel like building much of a browser within it.

---

It _will_ get to that point, but we've got a while before interop is a realistic thing

Re: sibling comment - they moved to a single lidar on the roof with their new vehicles. It has a ~3 meter blindspot around the car

They're also a category where security is inherently a user-visible feature of their products (and as such, it _should_ be easier to justify security engineers)

Right, but that legacy isn't a great reason to hate on what Dart is now

dart2js is a very small sliver of what Dart is.

The inherent danger in rewriting dependencies always seems to be greatly underestimated, though. Especially when this is your first time tackling the problem space in earnest.

* Getting the solution 80% of the way there is often pretty fast (which ends up deceiving everyone depending on it "it's almost done!")

* You are nearly guaranteed to encounter a bunch of bugs that were already solved in the original dependency.

* Due to the previous points, there's a big chance that your initial design had a few fatal flaws, and requires significant refactoring to address (making the project take longer, and if not careful making it much harder to understand & maintain)

Rewriting dependencies can definitely be worth it from a code ownership/maintenance point of view; but more often than not, you'll end up creating a cycle where the new version of the dependency is just as obtuse as the previous—and once you leave, the same problem all over again.

If a dependency is well documented, has a clear architecture, and follows consistent coding practices, it will stand the test of time (including loss of authors/maintainers). Most people/companies aren't willing to put the time/effort into that level of polish.