primigenus

Hopefully at some point in the future apartments/houses just come with privileged access entryways that you can manage, and delegate time-gated access to delivery services. That way the delivery person can just let themselves into your "airlock", put the package there, and leave without getting undue access to your private home and without it being a public space (like a porch) that requires a social contract to not be broken in order to remain secure.

Today's too early though, since IoT (eg. a connected doorlock) seems untrustworthy. What are some solutions that could be used to approximate it, I wonder?

> It's not that Tesla will or won't be successful, it's just that as it succeeds, it's changing the ecosystem around it.

I invested in Tesla because I wanted this to happen. For me, Tesla is not successful unless it changes the ecosystem around it. If, while doing that, it goes under as a car manufacturer, but in the end changed the ecosystem for the better, that's great! Sometimes a thing only exists in order to make itself redundant.

I doubt this will happen, though. Instead, I expect it to be like the iPhone vs Android: there will continue to be a premium electric car by the people who launched the first real contender, but other companies will outscale them and eventually provide really competitive products. That's also fine. (Note that Android was a newcomer as well....)

I really appreciated the insight by Poppy CEO Avni that pursuing your passion might lead you to think you know what you're doing and not be open to feedback, whereas pursuing a combination of curiosity and frustration is much healthier. Food for thought.

Hey malgorithms, this is great! I check the Keybase website every month or so for updates and discovered yesterday that there's a new logo, replacing the old thieving dog/ferret/raccoon with what appears to be a person's head with their hair in a bun holding a key. Can you give some background on the thinking behind this logo redesign? (Sorry it's not a question about chat, per say)

This is the first Nintendo platform from the "next generation" of developers at Nintendo that studied under Satoru Iwata and Shigeru Miyamoto. During the presentation, the heads of software development (Yoshiaki Koizumi and Shinya Takahashi) introduced the hardware, and the head of hardware development for Switch (Kouichi Kawamoto) introduced the launch title 1 2 Switch. Staples of such presentations like Miyamoto, Reggie Fils-Aimé and Eiji Aonuma were notably absent (though they did appear in a short video at the end of the presentation).

They didn't mention this at all, but I think it was a brilliant way to demonstrate that the next generation of Nintendo is as integrated and collaborative as ever, and let the games and the hardware speak for themselves. It also demonstrates the efficiency of the teams now that both the portable and home console teams are working together in one building at the new head office in Kyoto. A great subtle touch to an otherwise quite clear, explicit conference, and reminds me of how similar Nintendo and Apple are.

You seem to be confusing branding and product naming.

Pixel is a brand name for high-end reference-type devices designed and built by Google, such as the Chromebook Pixel, Pixel C, and Pixel phone.

Nexus is (was?) a brand name for low-cost reference-type devices designed and built in collaboration with hardware manufacturers, such as the Nexus 5, Nexus 7 and (odd) Nexus Q.

Android is a mobile operating system used on platforms such as phones, tablets, cars, and as of a few weeks ago, IoT devices.

Chrome is an overarching brand name for various web-centric things Google is doing: Chromium is the browser. Chrome OS is a version of Linux strictly limited to providing a web browser paradigm-based user experience for computers. Chromebooks are a class of low-cost laptops that use Chrome OS. Chrome_cast_ is a brand name for streaming content to unconnected devices such as TVs and speakers by way of microcomputing devices such as the Chromecast Ultra or Chromecast Audio (which all run a stripped down Chromium under the hood).

All things considered, for a company as large as Google, I don't think it's really all that hard to comprehend. I think it's pretty consistent, and they try to fit as much as they can into the above set of brands when they can. For instance, Android Things used to be called Brillo. It feels a lot simpler than how eg. Microsoft used to do naming up until a few years ago. Calling for "whomever is responsible" to be "let go" certainly feels hyperbolic.

Hey Harrison!

Wow, mind blown: the popup says "save selected tabs", which made me ask the question "what do you mean, selected tabs? I only have one tab at a time?", followed by experimentally shift/cmd-clicking tabs in the current window, and resulting in abovementioned mindblow.

This fixes everything broken about Google Glass. It's almost disturbing how much more on point this is:

Of _course_ they're sunglasses.

Of _course_ it's focused completely on video.

Of _course_ it's marketed as being about sharing your memories as you lived them.

Of _course_ you can only record 10 second videos at a time.

Of _course_ snaps automatically sync to the app.

Of _course_ they're designed to appeal to young fashionable people.

Of _course_ the charge lasts all day

This is one of those things where once you see it it's just obvious this is what it was supposed to be all along.

This is a pretty nice demo of the process of turning a basic page into a "design" (in the sense that applying positioning, spacing, contrast, and things like typography is visual design - I might call it layout instead).

However, if you run Chrome's Accessibility Audit (https://chrome.google.com/webstore/detail/accessibility-deve...) on this page, you get warnings about low contrast for 100+ elements and a link to https://github.com/GoogleChrome/accessibility-developer-tool....

So although you claim black text is harsh on the eyes and gray is more comfortable, it in fact is not - it just makes it harder to read. The very first time you load the page and see black Times New Roman on a white background is actually a better user experience for a larger number of people, purely from the point of view of legibility.

Try having someone with less than stellar eyesight look at this page. Or someone who's trying to read it on a smartphone outside in sunlight or with the brightness of their screen set at less than maximum. Design isn't about what looks nice, it's about what works well - pages that a portion of your audience cannot read don't work well.

This looks similar to how Meteor's ReactiveVar package, and lower-level Tracker library, works: https://docs.meteor.com/api/reactive-var.html

It's certainly helped make building real-time user interfaces that update when the data changes significantly easier in my opinion, because you're able to express your intent in code more closely to what you mean rather than having to write all the connecting reactive boilerplate yourself.

The server-side network model he describes here is the same architecture Meteor is designed with (see this page: https://www.meteor.com/why-meteor/features). With Meteor, you get client side prediction and latency compensation (they call it "optimistic UI" now) for free. I've always been impressed they decided to build that, because I sure never would have myself. In fact the Meteor team has always said you need this kind of architecture in order to build true real-time applications. But I haven't seen other web-oriented platforms take a similar approach. Did the Meteor team just know something no one else has picked up on (despite it apparently being common practice in the games industry)? What gives?

Has it won? Where can I go and write `react-stack create my-new-project` and get a guaranteed working integration of the various elements that make up the stack, including a working server environment, pre-installed and configured database, and all of the other inbetweens that come with Meteor (such as DDP, livequery, Tracker, Blaze, ReactiveVar, etc)?

The "React" stack has certainly been an up and coming potential competitor for Meteor, but until Facebook or someone else actually shows signs of preparing the kind of integrated development experience that Meteor ships with out of the box, I don't think it's really similar. So that's what they're doing: tying together the best of the Javascript ecosystem, which happens to currently include a couple of projects by Facebook, into one cohesive whole that "just works".

To be "The Javascript App Platform", as displayed prominently on the Meteor homepage. If you build an app with Javascript, MDG want you to build it with Meteor. In order for you to do that you need to trust that you can use the tools you want to, and derive benefits from the fact that the stack is designed to work as a single platform. So if GraphQL is where it's at, it makes sense to design a place for it in Meteor.

Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: https://twitter.com/Rahul/status/673992512768507905). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two groups with disparate sets of opinions on where Meteor should go from here collide.

As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.

Meteor was a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.

The issue in the forum thread you're linking to was not caused by Meteor but by the OP canceling a deploy halfway through the process: https://forums.meteor.com/t/first-visit-loads-are-ridiculous...

It allows you to skip having to specify npm dependencies in package.js.

Have you taken a look at Meteor iOS? https://github.com/martijnwalraven/meteor-ios -- made by the person who currently leads mobile work at MDG.