mark242

  var txt = await read();
  // This code is blocked until read() completes.
  console.log(txt);

If you wind up writing the word "await" in your codebase more than once, you're doing it wrong. You will quickly see how futures/promises wind up taking over all of your code. This is a very good thing. You shouldn't need to block, ever.

Sincerely,

Scala coders

Amazon Cloudfront: $59770 per month

Google Cloud CDN: $50000 per month

Fastly: $144200 per month

etc etc. If they can't get together $12000 per month for Cloudflare, they sure as hell don't have a viable business model.

No. No. No. No. No. No. This should NEVER be an option. You should not allow data to pass unencrypted over the wire, period.

Every single performance issue that you're talking about can be seen in native apps; check Twitter, for example, or Facebook. There is a definite lag there caused by the network sync being front-and-center. That's unavoidable, but for an app like Vesper where you're not looking at a huge data transfer, running the sync in the background is absolutely viable.

There isn't anything that Vesper is doing that can't be done on the web. You could even write Vesper as a single-page app, and use a ServiceWorker with Firebase or PouchDB or whatever to run the sync. The infrastructure to do all this is very, very easy to do on the web.

This is not rocket science-- this is how far the web has come in a very short time. The UI could absolutely be the same as the iOS native app and while you might have a bit of scrolling hesitation on the interface, it would be perfectly accessible.

Suddenly you're on every mobile device, Android, iOS, iPad, desktop, whatever. The absolute hardest and most time-consuming endeavor would be to get the Stripe account set up for the one-time "in-app" payment to get sync working.

John and Brent and Dave made a fine app in 2012, but I would certainly hope that the next Vesper starts out life as a web app.

What you are doing is effectively recreating the VRFY command that nearly every major mail hosting service has removed for privacy and abuse reasons. You are opening yourself up to a huge liability, since spammers will quickly use stolen credit cards to crosscheck their lists against your API.

This will cause you to have processing issues from Stripe. This will cause you to have a huge backlash from hosting providers as you desperately try to make sure that your cached address is still valid. (Let's fire off 1000 calls to some random Postfix server, WCGW?) This will cause you to produce false results for domains that run catch-all addresses but don't advertise mailboxes. This will cause you to unwittingly become an effective tool in a spammer's repertoire.

Look, sticking a cache in front of the RCPT TO command is all well and good, but that functionality should be up to the owner of the mail server that you're bombarding, and not up to some third party. You are putting the onus of "hey, just contact us if you don't want us to hit your mail server" on every single mail server admin. This is not okay. SMTP servers aren't nearly as robust, and cannot handle a quickly-spiraling-out-of-control web service hitting them.

Things like:

* Native Lucene search, which you had to build as a weird add-on for Couch. Now it's full-featured out of the box.

* Geospatial queries, also a weird add-on which only kind of worked in Couch, is also cooked in and is pretty strong now.

* True node clustering and data sharding; Couch has always had really really easy replication between nodes, and getting master-master replication is essentially creating a document on each node. However, you had to store your entire data set on every node, which would grow out of control in a hurry.

* A better auto-compactor. Couch 1.6 does fairly well but it's still a weird cron-based thing that can still fail horribly. The auto-compactor in Cloudant/Couch 2.0 is pretty solid and you don't have to worry about massive spikes in disk space consumption.

Nope. Let's say you have a rest endpoint that accepts a Pokemon id to add to your collection. If you cryptographically sign a cookie that says "I am this user id" you can assume the request to add the Pokemon to your collection is valid. There's other business logic to perform, sure, but "I am this user" is taken care of for you.

What Google is proposing is the ability to save a long-term cookie that says "I am this user" and a short-term cookie that says "I'm signed in". The requests periodically say "am I still signed in/am I still this user" and the server can periodically (eg not every request) look that up in cache/database.

This is where the short/long-term cookie comes into play, and is actually a neat idea to take care of the "how do I periodically check that the user hasn't logged out/changed their password/invalidated their sessions/etc" problem that the cryptographically-signed cookie brings up.

The funny thing is that writing nonblocking code doesn't have to be as hard as it is, you just have to get into the mindset. It's easy to say "well, I have to have the result coming back from my JDBC/REST/etc call before I know what to do with it" and that's not the case at all, especially when you're working in a strongly-typed environment.

If you are working with any sort of confidential data, be it personal information, or payment info, or whatever, a determined attacker with access to executing Javascript on your page is going to cause a world of problems, the least of which is gaining access to localStorage. A much more concise example is adding a simple eventlistener on keypress, and just logging that data to a third party.

localStorage is ready for widespread use, imo, you just need to know what and when to use it; using localStorage as initial cached state on application startup is extremely useful.

Come on.

<em>This is my italic text.</em>

Connections are very very cheap to maintain, and very very expensive to build up and break down. Even in environments with load balancers, stateful firewalls, etc., it is much easier to keep a socket open than it is to create a new one.

If you're doing any kind of realtime data, websockets are the way to go. It is way, way easier to do stream processing and deal with backpressure than it is to have a gigantic number of clients doing http polling.

When Cloudflare mentions that websockets haven't had a gigantic uptake, I don't wonder if it's because Amazon's ELB doesn't support them and people don't want to roll their own haproxy solution.

Holy hell, what a telling statement that is. I get not unit testing for 1 == 1, but come on, unit and integration tests for, say, user login should be difficult, not fast. There are some test suites that actually do need to be perfect, unless Instagram thinks that eg OWASP isn't "decent coverage".

Don't run production code on a nano.

Don't run production code on a nano.

I don't care what language you're using, if you find yourself saying "well, I could run on a nano" just stop.

Is this really still a complaint in 2016? Your phone has that much RAM.

Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.

https://www.ibm.com/smarterplanet/us/en/ibmwatson/developerc...