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.

This is roughly what Tailbone does: https://github.com/dataarts/tailbone

If you had just posted the comment without "Sorry, but" at the beginning it would have been a great additional insight rather than disparaging to the OP :)

The Million Dollar Homepage is a website conceived in 2005 by Alex Tew, a student from Wiltshire, England, to raise money for his university education. The home page consists of a million pixels arranged in a 1000 × 1000 pixel grid; the image-based links on it were sold for US$1 per pixel in 10 × 10 blocks. The purchasers of these pixel blocks provided tiny images to be displayed on them, a URL to which the images were linked, and a slogan to be displayed when hovering a cursor over the link. The aim of the website was to sell all of the pixels in the image, thus generating a million dollars for the creator.

https://en.wikipedia.org/wiki/The_Million_Dollar_Homepage

The sheer "internet"-ness of the idea at the time was brilliant. It also seems like the kind of thing you can only really pull off once. And it was funny watching it slowly fill up, discovering what kind of businesses turned out to spend on something like this, what colours they attempted to choose to stand out, and how the result was a chaotic mess with everyone fighting for attention. Subtle commentary and somewhat prophetic of the current situation with ads...

This reminds me of the classic Million Dollar Homepage from way back when: http://www.milliondollarhomepage.com/

Highway1 (http://highway1.io) is doing a great job of helping startups figure out how to get their manufacturing strategy set up. The advice and insight the two companies I worked with in their most recent cohort (Spinn Coffee and Game of Drones) received was absolutely essential to getting off the ground, so I'm expecting to see more of this kind of incubator/accelerator in the future.

Funnily enough there are actually multiple Slack-like chat app projects underway in the Meteor community. I guess building a chat app is the new building a todo list app?

Yesterday at Meteor's main meetup Devshop this was presented: http://spacetalkapp.com/ and the speaker mentioned that there's a big community effort underway to keep improving it.

Let's see which one wins the race :)

Latency compensation/optimistic UIs is one of the first things that clued me into why Meteor is so great back in 2012 when I watched the original screencast: https://www.youtube.com/watch?v=fsi0aJ9yr2o

The reason is actually a common theme throughout Meteor: boilerplate code, and somewhat relatedly "devops" type code, are taken care of by the platform so you get to focus on building your app.

It's such a big focus of Meteor's design compared to every other platform, and it's what's kept me coming back for three years.

In fact, it's surprising that so few other platforms have picked up on the fact that eradicating boilerplate is a feature, and they should compete on it. Maybe with more posts like this, they'll be inspired to head in that direction!

For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?

If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation", where changes users make are instantly reflected in the UI and synced to the server in the background. This is a central feature of Meteor. More here: https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw

It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.

It's actually very easy to go from prototype to production; you just remove some convenience packages (autopublish and insecure), set up your security rules, do some basic performance tuning (eg. don't publish entire documents if you only need 3 fields, which is a standard practice for any app) and that's about it. Of course the definition of "production" varies per project, but after shipping over 20 Meteor apps since 2012 these are the most common things I tend to do.

Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?

You can express most of these in code. Yes, in relational databases you can express constraints in the database. But then you're having a NoSQL vs SQL debate, which is sort of out of scope of this discussion.

For the longest time, it was only supporting Java and Python SDKs.

You are describing Google App Engine circa 2010. I recommend taking another critical look at what Google has available because it's quite competitive these days :)

Meteor should publish more videos like this explaining the fundamentals. I feel like a lot of people miss the thinking behind the platform and end up comparing Meteor to other libraries and frameworks they already know, such as Ember, Angular or React, when Meteor is actually something completely different.

For instance, if you visit the "projects" page on the Meteor website (https://www.meteor.com/projects), you're faced with the following introductory paragraph:

The Meteor Project is a little bit like the Apache Foundation or the Free Software Foundation in that it is an umbrella organization that stewards the development of a set of open source projects. This page has information on each of the subprojects currently being sponsored by the Meteor Project.

It would be interesting to hear more about their philosophy on simultaneously building an organisation like this and designing a software platform.

Sorry you had a bad experience with the developer.

However, there is no such thing as the "Meteor marketing team". Meteor doesn't employ any marketing people (yet). Anyone talking enthusiastically about Meteor is just genuinely excited about it.

I'm curious to hear specific examples of esoteric concepts that you had a tough time with. In my experience, Meteor is the opposite of esoteric and actually very easy to work with, even as application complexity increases. If you can outline your issues, maybe we can try to address them. Thanks!

It accomplishes many things that other frameworks don't, the most important of which are ease of use and dramatic productivity gains. I recommend reading meteor.com/about for a high level overview and then diving into the description of projects at meteor.com/projects to understand how the various components of Meteor function. The original screencast at meteor.com/screencast is also a very useful introduction, and if you want to spend about half an hour building an app to get the basics down, meteor.com/try will do just that.

Using phantomjs to index your site has not caused any problems for most of us building apps in production for the past two years. From an engineering standpoint there are better alternatives such as server-side rendering (btw, there is a Meteor package that does this: https://github.com/meteorhacks/meteor-ssr), so outside of performance considerations this isn't a super big deal. A lot of Meteor apps also aren't Google-facing but instead apps that you use after log in, where Meteor's advantages have the biggest effect on one's productivity.

Meteor works in every evergreen browser and quite a few older ones. It will fall back to polling if there is no support for websockets and the Blaze view library works in IE8+.

I recommend just trying it out. It takes no time to install and get your first app started (<1 min) and you will immediately start to see the benefits. Come tell us more about your situation at forums.meteor.com and maybe we can help!

If you're in the Bay Area but not in SF, we also have the South Bay meetup (that I run): http://www.meetup.com/Meteor-South-Bay/