mark242

How many users wound up losing data because of that bug? In comparison, how many houses were lost to fire today?

The odds of you losing your hard drive and flash drive in a house fire are significantly higher than the odds of you losing data on S3.

"Hopefully a JavaScript-free Web can still happen."

The phone you're reading this post on has nearly as many CPU cycles available to run code as the web server that generated the html. Why on earth would you not want to distribute the overall application load.

This is a great start. Now let's integrate caniuse into every single MDN page.

The easiest thing to do on AWS is just fire off a CloudWatch event. When your Lambda function gets updated, or even on a set schedule, you can invoke your function with whatever arguments you need. Presumably you could cook in a method that warmed everything up, and call that method.

What's the exchange rate between Steem and Flooz? Can I finally use my Flooz credits?

The sizzle library that jQuery uses takes advantage of querySelectorAll.

https://github.com/jquery/jquery/blob/2d4f53416e5f74fa98e0c1...

...only with a ton of wrapper code around it in order to support IE9 and below. If you don't have to support ancient browsers, there's no reason you can't write QSA code.

var nodes = document.querySelectorAll("li"); for(var i=0; i<nodes.length; i++) { nodes[i].classList.add("foo"); }

Yes it's slightly more code. It's also going to run a hell of a lot faster on, eg, a mobile device.

I don't understand the pricing model. 800 new connections per hour, for $0.006? Isn't that extremely expensive? 80,000 connections for $0.60 in an hour is $432 per month for not a whole lot of traffic.

edit: Okay, it's 800 new connections per second, per the ELB pricing page, under "LCU details". The cost for 80k connections in an hour is effectively constrained by the bandwidth, eg if there's very low bandwidth it's $0.006/hour or $4.32/month.

Nope, sorry. You might be interested in Mike's solo album -- https://itunes.apple.com/us/album/fellow-prisoners/id5013550

Mike got the name from the poem.

There's a difference-- point-to-point encryption is what you're talking about. Anytime a message is transferred, it's done via TLS, but you can't be guaranteed that at any one point the message is kept encrypted. You can have this today -- just about any MTA has a configuration to only allow TLS connections, and then you can set up an IMAP server to only allow encrypted connections.

End-to-end encryption is the system whereby the moment the message leaves the sender's hands (phone, desktop, whatever) it's encrypted until it gets into the receiver's hands. This is your OpenPGP/etc. You could think of that as "Signal for email". This is apparently not what Magma is doing.

Here's the relevant line from Github:

https://github.com/lavabit/magma/blob/develop/src/providers/...

You can see that Magma is writing the email message to a file and instructing ClamAV to scan the file. This is actually worse than writing to a clamd socket, since (imho) it would be easier for someone to monitor a directory in a filesystem on a compromised Magma server.

Compare this to how SpamAssassin communicates with ClamAV-- it streams to either the port or socket:

https://wiki.apache.org/spamassassin/ClamAVPlugin

And let's be perfectly clear, EV certs are basically a moneygrab by CAs trying to provide some kind of value-add. It used to be that ecommerce sites would have to get an EV cert, now with Chrome desktop showing "Secure" in the address bar, the visual representation of an EV cert isn't nearly as important.

The ClamAV dependency concerns me; messages can only be passed to clamd via a plaintext stream. This seems to be at odds with the end-to-end encryption.

Dismissing CouchDB because it only supports pre-sharding is extremely shortsighted. It takes very little time to replicate from one db with 2 shards to another db with 3 shards, even on N nodes. Copying the *.couch files is the absolute wrong way to manage this especially in a production environment when those files will be constantly changing.

It is far, far easier to add nodes to a Cloudant/Couch2 cluster, set up realtime replication from db1 -> db2, then once the replication has caught up, at your leisure you switch your database connection in your app.

For a large ecom site hosted primarily in the US, for our European customers it cut TTFB almost in half.

> Electric cars are still affordable only to the affluent.

I just now ran a Carfax report and found no fewer than 7 electric Ford Focus cars within 50 miles of my zipcode for less than $15k used. Two of them are less than $10k. Not sure what "affluent" means to you.

The reason I don't like the internal-int-external-UUID strategy is that all of your queries now require an extra join. It's no longer "select microblog.* where userid = ?" now it's "select microblog.*,user.id from microblog,user where microblog.userid = user.id and user.uuid = ?".

This may be practical from a storage standpoint but string-based indexes on an SSD are pretty damned efficient.

Volume is a percentage, and a very analog control. The idea that you would have to have a round knob to twist on a computer screen is ridiculous, almost like some imaginary need for a specific shutter button to press to take a photo on a phone (just touch the screen!).

It's a one-dimensional value, make it a one-dimensional control. Slider. Done.

In reality my function would rarely exist in the Scala world since having a weakly-typed return like that is cringeworthy to say the least. But it's better to see this in action with Scala options.

  val myOptionalVar: Option[String] = functionThatReturnsOption()

  myOptionalVar match {
    case Some(str) if str.length > 10 => System.out.println("This is a long string.")
    case Some(str) => System.out.println("This is a short string.")
    case None => System.out.println("This code would be fifteen lines of null checking in Java.")
  }

I mean, reading this article is basically a giant advertisement for Scala and its powerful pattern matching.

  functionThatReturnsAnyVal match {
    case i: Int if i > 2 => System.out.println("Greater than 2")
    case i: Int => System.out.println("Less than or equal to 2")
    case s: String => System.out.println("Hello, " + s)
    case _ =>
  }

So let me get this straight. You need to go through all this code in 2017:

https://github.com/verekia/js-stack-from-scratch/blob/master...

...in order to replicate dispatchEvent and addEventListener?

This will be huge for getting Scala running on AWS Lambda. The cold-start times for JVM apps is just ridiculous and makes Lambda/API gateway essentially unusable for anything written on the JVM.

Sun tried that, back in the day. Maybe you heard about Java applets, maybe you didn't. They were the slowest thing about the web, insecure even with a sandbox, and just an overall pain. Short of having a jvm always running on your machine, the performance of Android-via-Chrome will completely turn people off the Android ecosystem.

If this is possible with RDS, that's huge. It's extremely frustrating to deal with spikes of transitory data into RDS and have to have the RDS disk space be sized to the maximum amount of space always-- it's a huge cost waste.

It's okay, since cookies is a Map[String, String] so running the get returns an Option[String].

If the author is concerned, the way to express this to be more expressive could be something like this:

    val uidOpt: Option[Long] = request.cookies.get("uid") map {
        case Some(uidStr) if uidStr.toLong > 0 => Some(uidStr.toLong)
        case _ => None
    }

> Is this properly null checking if required?

Yes, because if you're typing the word null in your Scala code you're doing something wrong. Any Java library that might return null should always be wrapped in an Option, so that you're dealing with Some or None, and you never get an NPE.

    Option(myJavaLibraryFactoryMethodUsers()).flatMap(_.sortBy(- _.age).headOption)

...will get you an Option[User] of the oldest user. People who have written Scala for more than six months can immediately recognize what this line of code does, and it eliminates around 20 lines of equivalent Java (or Go?) code. This kind of thing rarely needs to be refactored.

To play devil's advocate, steps 1, 2, 4, 5, and 6 are all fairly standard behavior for a Mac app that is installed "for all users on this system".

https://developer.apple.com/library/content/samplecode/SMJob...

Step 2 and 7 are fairly standard behavior for an application that is meant to be running at all times, eg a persistent chat app. Even something like GPG installs files into /Library/LaunchAgents. The location of the directories in question shouldn't set off a warning flag about whether an app is "shady" or not.

They last. I have a 2-year-old electric Ford Focus and have noticed nearly zero battery degradation; the range has been consistent since day 1. Recycling the batteries is undoubtably less of an impact than even the recycling of engine oil from an ICE car over the same timespan.

Fold is incredibly important. You should learn it. https://en.wikipedia.org/wiki/Fold_(higher-order_function)

In Scala, the debate between using fold on an Option or using map and getOrElse is almost as old as the language. The method signature for this is:

  def fold[B](ifEmpty: => B)(f: (A) => B): B

That is to say, fold always returns type B, and takes two arguments. The first takes a function returning type B if the option is "empty" (None) and the second takes a function that is called with the contents of the Some. As you can see, it's syntactic sugar for map and getOrElse.

  def map[B](f: (A) => B): B

  def getOrElse[B](f: => B): B