enginous

I'm pretty unclear about how the experience they showcase in the video would work on iOS. Maybe Android has APIs for this, but on iOS it looks like RCS just supports green-bubble messages, links and files/multimedia. But in the demo they show multi-choice cards, carousels, cards with buttons, and reply auto-suggestions.

Also, someone correct me if I'm wrong, but it also looks like this needs to be agent-initiated, ie. you can't add a "Text us" button that will take you to this experience. (But you could capture a phone number, and text them _iff_ they have RCS available and enabled.)

Overall, seems questionable whether this is worth integrating if the experience is so fractured across platforms and many people might not even have RCS. The concept of a platform for rich messaging across platforms sounds good though.

This pattern of the virtual DOM has some parallels with functional programming. At first look, using functional programming it looks like you're sacrificing the performance that you gain from mutations -- which to some extent is true. But when you look deeper, you'll find that the data structures for functional programming languages have been adapted to work in a very performant way with functional programming patterns.

In the same way, when you look closer at the virtual DOM model, you'll find that you can optimize the usage very well. For example, when you use React with immutable data structures (e.g., Immutable JS), deep equality comparisons can be done very quickly to reduce renders to the minimum subtree required, and to issue the renders for a given change in a batch operation.

With React, you often end up with even faster code than using manual DOM manipulations. Of course, your performance will vary depending on how you implement your code. Depending on which model you're using, and how you program, you may end up with a faster or slower product with either methodology.

But at the end of the day, the performance gain from running code using state mutations just doesn't seem worth the effort of having a significantly harder time reasoning about the code, and having to deal with the challenges of scaling a project where the complexity grows much faster with each line of logic.

And my feeling is that due to the time invested in managing a more complex project that deals with mutations, the "performance per engineering hour" gained for projects using a virtual DOM is more favorable for many projects.

So, it seems that the change for production apps is that you can now somehow commit to a monthly price for dynos and get a discount.

  1X – $25/month compared to $36.5/month (by the hour).
  2X – $50/month compared to $73/month (by the hour).
  PX – $500/month compared to $584/month (by the hour).

I'm also interested in what has changed. The dyno-hour prices of $0.05, $0.10, $0.80 for 1X, 2X and PX, respectively, seem the same as before.

I think the stuff React is doing is impressively simple and non-magical. Although I haven't used React yet, I wouldn't be surprised if these ideas make for code that's relatively easy to reuse and reason about.

The format of the post is also quite nice; a few short points with illustrations and a clear takeaway.

Also, his idea of increasing taxes will mean that even if his statement were true ("[if] people only bought half as much, they would be just as healthy"), a flat increase in drug tax would at best make this effect true on average.

Due to higher taxation, low-income individuals would have even less access to medicine than today. Keeping people away from drugs with prohibitive taxation means starving entire demographics of this component of health care.

So sure, people who have the funds to take excessive amounts of medicine may be "just as healthy." Others would be considerably worse off.

Encrypting anything with your Google Accounts password doesn't really make you invulnerable against Google. They can get your clear text Google Accounts password from you any time they want by just reading the password you enter on any of their clients.

What key are you going to encrypt these passwords with?

If you were to encrypt passwords in the cloud with a key that's stored on the device, you can't unlock the passwords on a different device (or the same device after flashing), which is the whole point of backing it up in the cloud.

If you were to encrypt them with the user's Google Accounts password, the device would need to ask for that password on every startup or store the GA password on the device at all times (the latter option is a far greater evil than the current "situation"). As long as Google is ever given the clear text password (i.e., before hashing), this would be open to interception by Google -- or infiltrators thereof.

If the GA password were to be used to authenticate in a way where Google doesn't get access to the clear text password (through digest-like authentication), a user wouldn't be able to access the backups after resetting her password. However, this method is not reliable if you don't trust Google (or its infiltrators), because Google provides the clients that would do the hashing before sending the password, so they could obtain the clear text password (by skipping the hash step, or by sending it through side channel) on any client they control such as HTTP login pages or mobile apps provided by Google.

Like all things security, it's a trade-off between security and convenience.

Again I run into the issue that Google doesn't seem to release their iPhone apps internationally. I'm in Europe (Iceland, specifically) and I can't download the Google Search or Google Authenticator apps because they're not available in our App Store.

Does this happen to people in any other European countries?

OP was clarifying the meaning of pirate in the present context, not the origin of the term or how it is used in some other contexts. The meaning you're suggesting is very explicitly not the idea behind the Icelandic Pirate Party.

At one point, they publicly rejected any affiliation with The Pirate Bay and said that they did not condone copyright violations.

They did however use the opportunity to encourage people to learn about openly licensed content, mentioning Paulo Coelho as an example, and suggesting that people consume free content no less than they do paid content. However advisable or realistic that actually is, it's not supporting illegal downloads.