tuxracer

> A big enough tax on fast food could probably cover it

Exactly this kind of statement is what worries some about universal healthcare. I highly support single payer, universal healthcare. But statements like this undermine the cause by feeding fuel to the idea universal healthcare will inherently lead to more government intrusion into your personal decisions.

If for some reason in the future you lose access to the devices you have already logged into Keybase with then you'll permanently lose access to that account with absolutely no way to recover any of the files, messages, etc... it contains. It may be unlikely you'd lose access to multiple devices at once but seems risky to even continue using that account without the paper key. Luckily you can generate a new one from the app.

It is a joke but a stupid one that harms adoption of the product. It's conceivable the author could decide say, eating meat isn't "nice" and sue an organization using it that packages meat products for consumption. A judge may find it unenforceable but having to potentially get tied up in a legal battle in the first place already makes it unpalatable to many organizations. See one of the replies here about a similarly juvenile clause where organizations got written permission to use a product "for evil". Not sure a few giggles is worth harming the adoption of technology many people have worked hard to deliver.

2 billion dollars and 8 years hasn't even gone into such an effort though. The complete rewrite which serves as the codebase for the xbox, iOS, etc.. version is where the majority of that time, money, and effort has been spent. The mobile and console markets were apparently seen as as a much more lucrative use of time and effort vs optimizing the legacy desktop-only Java version which the author himself agrees was poorly written.

The students are customers. It's a business. If these customers will continue to get themselves into tens of thousands of dollars in debt to pay for something of sometimes questionable value then let them block or have whatever speeches they want.

Of course on principle this is a disgusting form a censorship that could come to bite them on the ass if it continues to be culturally accepted. They seem to forget that things like interracial marriage, or people of color even being allowed onto these schools were once unpopular ideas.

If they continue to create a culture of violence and intimidation against anyone who dares utter unpopular ideas in their vicinity they'll snuff out any hope of future social revolutions from happening. But this seems to be what they want. It's in some ways an ultra-orthodox, conservative, perversion of left wing ideals.

Then oauth based attacks like this come along and your password (however strong it may be) and two-factor auth are bypassed completely... It's interesting Apple can scale personally vetting apps for the app store but Google apparently can't be bothered to do the same for apps that could actually ruin businesses and lives with the data they could scoop up

Is there a reason a lot of these cryptocurrencies have suddenly started to skyrocket all at once?

It's an interesting question though. I didn't read anything further into it (such as "oh you're saying it will solve ALL engineering problems EVER conceived by all of humankind?!!")

It's just a question, and an interesting one at that. Given they were already prepared to (and did) spend so much time rewriting why not kill two birds with one stone and get cross platform on top of it? There very well may be good reasons to have not used react native. It would be insightful to know what those were or even (to a lesser degree) to speculate.

const users = await getUsers();

const tweets = await getTweets(users);

console.log(tweets);

Is async code really harder to read?

Blindly shooting it down like it wouldn't solve engineering problems is just the other side of the same coin. You haven't really provided any constructive info why it wouldn't be a good fit here.

Taking it even further https://www.youtube.com/watch?v=ERB1TJBn32c#t=1m45s

There might not be a 1:1 relationship between the increase in price and decrease in demand but raise prices high enough and you limit who can possibly even afford it.

Agreed that's a much better analogy. In this case the "retailer" already maintains such records. The government isn't even asking for the list of all purchases by all individuals, just the name of who purchased a particular item.

Sure in the course of getting the answer to that question the retailer may sift through the records of all purchases, but this is data they already have.

This is hardly something to be outraged about. Title implies something much different.

The government is not getting access to (nor asking for) all queries. The government is getting access to information identifying who searched for a term. Google's query may include all search terms but Google obviously already has that data anyways.

This is equivalent to asking FedEx who in a given city was shipped something from a specific address. Sure when FedEx does a search it may technically search over all shipments from any address, but the government isn't getting access to that information. Hardly equivalent to door-to-door searches of every house.

This title is so inaccurate it should be changed. Asking who in a city searched for a term is not the same as asking for a whole city's Google searches.

If you migrate to HTTP2 or move to a host that already supports it then cutting down on "round trips" is an obsolete concern altogether.

> This will not work for iOS. Why develop something which excludes a big chunk of the cake?

By that logic nobody should even create native Android apps today. You're saying that if Android apps could run on even more platforms it would somehow stop being worth it to create them because iOS is excluded? Makes absolutely zero sense.

Android has had face unlock built in for some time. A naive way it mitigates the "unlock with photo" vulnerability is an option requiring you to blink. Not as robust as 3d, heat sensitive cameras but it's at least not a trivial as showing a photo to beat it.

The impressive amount of processing power available on many smartphones today certainly contributes to this being a practical unlock method.

That's very true Google has never been as disciplined when it comes to design guidelines. But aside from purity to specific guidelines there is a lot of data that show hamburger menus are death for discoverability of whatever is tucked away in them. Google has been slowly moving away from that direction for years first with the removal of the hardware menu button. As far as tabs go, having tabs, and on the bottom, is tremendously helpful especially on larger screen devices. All things Apple has likely known all along and hence their original design guidelines that Google seems to be adopting more and more of over time.

FYI Tab Bars are now recommended by Google for Android as well http://www.androidauthority.com/bottom-navigation-material-d... There is a lot of data that shows hamburger menus create big discoverability issues and Google highly discourages uses them now.

So if anything the general layout of an iOS app would meet the latest Android Design Guidelines quite well. There may be certain "iOSy" things left like very blurry backgrounds but overall there's little reason to have a different UI layout across platforms at this point.

> The part I'm still concerned about is UI performance - it's still miles off native.

Many times needlessly low expectations of both developers and managers are the blame for this. Yes, there are certain elaborate UI effects that are genuinely difficult to do well on web. But when there's a full second lag after pressing a button, or a menu slides into view at 3fps, the platform is not the problem.

A native app that has incredibly choppy, laggy UI for simple interactions wouldn't make it past many engineering managers or PMs. But when there's needlessly a full second lag after pressing a button on a web app everyone shrugs, inaccurately blames it on the web platform (instead of piss poor engineering), and it's out to production furthering the stereotype that web apps are inherently jank.

As a web development community we need to stop this cycle. Web engineers need to stop building, and engineering managers need to stop approving, web apps with needlessly janky, laggy UI for even rudimentary interactions.

Cool project! Quick suggestion: Ditch the "Update preview" button and immediately update the preview after you make new choices.

Standard practice in the world of Android phones. To add even more salt to that wound the OS was probably a couple years out of date when you bought it as well.

If you password protect the archive you should be good

Yeah but the checkout button on the insecure cart page could be changed so that it instead points to http://www.apple-payment.com/... or any random malicious "checkout" page which then steals your CC. They've compromised the security of credit card details users will at some point enter by doing this. It's insane if that isn't a priority.

Google Fi support is extremely friendly and often almost zero hold time. The actual substance of the support however is very much lacking. Google Fi sent me somebody else's SIM card with my Pixel. It turns out Google Fi pairs a SIM to a specific Google account. So when I booted my Pixel for the first time the email field was pre-populated with someone else's email address (but not the password luckily) and I got a "B010" error trying to activate. This is a very specific error code which I later found out means that I was sent the wrong SIM card (or trying to activate someone else's SIM card). But they didn't have this properly documented so they spent a long time on the phone with me factory resetting it, clearing data for certain system apps, booting in safe mode, etc... before escalating the issue and saying someone will get back to me later. A week later they contact me and say I was sent the wrong SIM and send me a new one. It was a terribly frustrating introduction to using their service. Also seems a needlessly frustrating experience if their support documentation and call back times were better.

There's no proper API to ask to prompt to homescreen. The only thing you can do (android chrome only) is enable the prompt to be shown at some point in the future. Google takes over from there and decides when and if users will be prompted, and the exact UI and copy of that prompt.

For sites that have enabled this, you'll be prompted once you visit a site a number of times over a short enough period of time.

This is a staggering limitation unique to PWAs. Any Product Manager I've ever worked with wants to experiment with different copy, UI, timing, etc... So the PWA add to homescreen prompt limitations makes it a complete non-starter.

In lieu of a proper API for PWA add to homescreen I'm then asked to put up prompts that send users to native app stores.

Those things are all possible in the latest versions of every major browser. Web standards have come a long way!

Nope. USB-C and traditional headphone jack only.

> Being able to use off-the-shelf braided USB-C cables is going to be awesome

Sadly there are a shocking number of USB chargers/cables which will physically fit into a USB-C port but are not to spec, therefore prone to damage or destroy the device. A Google engineer has been testing these and listing "approved" ones here http://www.bensonapproved.com/