gist:1406238

Originally:
https://gist.github.com/7565976a89d5da1511ce

Hi Donald (and Martin),

Thanks for pinging me; it's nice to know Typesafe is keeping tabs on this, and I
appreciate the tone. This is a Yegge-long response, but given that you and
Martin are the two people best-situated to do anything about this, I'd rather
err on the side of giving you too much to think about. I realize I'm being very
critical of something in which you've invested a great deal (both financially

machisuji

import play.api.libs.json._

implicit object userToJson extends Writes[User] {
  def writes(user: User): JsonValue = JsonObject(Seq(
    "possiblyTotallyUnrelatedFieldName" -> JsString(user.name)
    //, ...
  ))
}

telent

App configuration in environment variables: for and against

For (some of these as per the 12 factor principles) 

1) they are are easy to change between deploys without changing any code

2) unlike config files, there is little chance of them being checked
into the code repo accidentally

3) unlike custom config files, or other config mechanisms such as Java

delitescere

See https://github.com/delitescere/docker-zulu and https://github.com/delitescere/docker-lein

joyrexus

Nice answer on stackoverflow to the question of when to use one or the other content-types for POSTing data, viz. application/x-www-form-urlencoded and multipart/form-data.

“The moral of the story is, if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded.”

---

Matt Bridges' answer in full:

The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the server. Depending on the type and amount of data being transmitted, one of the methods will be more efficient than the other. To understand why, you have to look at what each is doing

headius

Algorithm

1. A secret byte you want to read is stored at inaccessible memory location priv_mem.
2. The sender triggers an access exception by attempting to read priv_mem.
3. Due to CPU optimization (out-of-order execution), the load of secret from priv_mem and the use of its value in (4) and (5) below may execute before the exception is triggered.
4. Calculate an offset into a known array probe by multiplying secret by the width of a cache line (or whatever block size the CPU typically fetches, like a 4096-byte page). This guarantees each of those 256 possible offsets will cache separately.
5. Load probe[offset], which causes the CPU to cache exactly one chunk of of our array, populating one cache line.
6. The exception finally triggers, clearing the modified registers...but cached data is not excised.
7. Iterate over all 256 offsets into probe to find out which one loads fast. You've determined the value of secret.