wsargent

> To put that another way, you might not know at the time whether your function is going to be invoked from a high-throughput loop.

> Is there a nice solution to this problem?

There's two ways to do it from within the logging framework. The first way is that you can suppress duplicate messages with a filter, like the DuplicateMessageFilter [1]. It wouldn't be that hard to add a filter that looked for the message template, and could suppress based on other properties on the LoggingEvent, such as the request ID or the overall similarity of the event.

The second thing you can do is add a budget for your logger, which will only allow it to log a certain period in a window. This is something you can do with budget evaluators [2].

Depending on the layer you put over SLF4J, you can also add conditional logging [3], which puts the logic at the application layer. Under this model, you'd have a counter or circuit breaker in the condition that would short-circuit the logging.

[1] http://logback.qos.ch/manual/filters.html#DuplicateMessageFi...

[2] https://tersesystems.github.io/terse-logback/guide/budget/

[3] https://tersesystems.github.io/blindsight/usage/conditional....

Started using this yesterday, with the X410 X11 install.

The nicest thing has to be running IntelliJ from X11 and have it see the linux filesystem.

I can run a Yubikey with weasel-pageant and get GPG signing and SSH keychain access to github through it -- it pops up a Windows PIN entry dialog box and then works fine thereafter. You can use wslutilities (wslusc) to set up windows shortcuts to your Linux applications. I use ConEmu as my shell and it's fine.

There is a problem with HiDPI screens. I've worked around this by increasing the font size in IntelliJ, but VS Code shows up as teensy tiny.

The worst part has to be the documentation. The docs for "pengwin-setup" is basically a bunch of screenshots on their blog.

So you assume he worked this through from first principles and is thinking critically and has checked his sources... because he works (well, worked) at Google?

I can tell you that the norm among engineers, even at Google, is to receive lore and anecdotes from people slightly more educated as if it were gospel, and to repeat it uncritically until someone else more charismatic comes along. This happens so often that someone wrote a book called [The Leprechauns of Software Engineering](https://leanpub.com/leprechauns) about the unsourced commmon knowledge that engineers will blindly repeat without thinking about it.

Also, the larger problem with debunking is that it just doesn't work all that well. It's like arguing with an antivaxxer -- they may ask for logical discussion but it has no effect. Ultimately, what convinces them is social pressure or a sudden intrusion of reality i.e. their child gets sick, they have a female friend who encounters discrimination etc.

> I'm not going to read two books just to figure out some google guy's 10 page memo - call me lazy but perhaps nobody is going to read two books just for that purpose.

Well, if it's any consolation, I wouldn't read it for that either. The blog posts and memos do accumulate, though, and at some point it's worth it just to have the sources to refer back to.

I don't know that there's a debunking of the thesis, because there's nothing very original in there -- it's repeats and retreads of other things that have been debunked over and over, so it all merges into a mashed up mess of points and rebuttals like a badly maintained wiki.

There are a couple of books which I can recommend that talk about why you see so few women in computing (as opposed to biology, math, etc) and also why you see so few black men and women:

    * Unlocking the Clubhouse: http://a.co/8oXDROX
    * Stuck in the Shallow End: http://a.co/9HXgvKW

These are not only well written, but they're also well researched and well thought out. They're worth reading on their own merits, but you may find them a useful debunking to the memo.

Fair enough -- I was actually thinking of

https://github.com/wsargent/docker-cheat-sheet/blame/master/...

but that's a fair counterexample.

You can use an agent to disable the security manager disabling. :-)

https://tersesystems.com/2016/01/19/redefining-java-dot-lang...

Check the blame log. That section's all me.

I put together a list of security tips:

https://github.com/wsargent/docker-cheat-sheet#security-tips

Probably the biggest one is to use Virtualbox or another virtual machine so that Docker isn't your only line of defence.

Hi, I'm on the Play team. We've got a number of Play maintained example projects that show how you can configure different projects:

https://playframework.com/download#examples

Should save you some time if you're looking to get started with JPA, different libraries, etc.

Also, this doesn't really get at the strengths of Play as a reactive application. For example, here's a talk where I discuss using Reactive Streams with Play to stream video through Play. It's about two years old now:

https://www.youtube.com/watch?v=zUB7GJMe_WY

Thanks!

I really like jhalterman's failsafe library. Exponential backoff, jitter, circuit breaker support, etc.

https://github.com/jhalterman/failsafe

Hi, I'm on the Play team. We've got a number of projects showing compile time injection:

Java compile time DI:

https://github.com/playframework/play-java-compile-di-exampl...

Java compile time DI using Dagger 2:

https://github.com/playframework/play-java-dagger2-example

Scala compile time DI:

https://github.com/playframework/play-scala-compile-di-examp...

Scala compile time DI with Macwire:

https://github.com/playframework/play-scala-macwire-di-examp...

Thanks!

The Artima book by Odersky is the bible, and so you need that one.

For reference, I like http://naildrivin5.com/scalatour although it's 2.8 rather than the current 2.12.

For style guide, I'd go with Li Hiayo's blog, notably the Strategic Style series: http://www.lihaoyi.com/post/StrategicScalaStylePracticalType...

Akka, Play and Lagom are part of the Lightbend Reactive Platform -- everything's async from the ground up, built on the JVM and Scala.

The authors put together the Reactive Manifesto: https://www.lightbend.com/blog/reactive-manifesto-20

The easiest way to use thread pools in Scala is to use an ExecutionContext. Akka will let you define an ExecutionContext from a configuration file using a wrapper called a Dispatcher -- you can ramp up the parallelism-max setting for more cores. Then you do actorSystem.dispatchers.lookup("my-dispatcher") and pass it to all the actor based code that you are using.

You can use a work pulling set of actors to handle computation after that, or use Akka Streams to provide backpressure, to avoid the OOM problem.

https://rnduja.github.io/2016/03/25/a_first_look_to_akka_str... is also pretty good.

You should check out Daniel Somerfield's talk at OWASP, "Turtles All the Way Down: Storing Secrets in the Cloud and the Data Center"

https://youtu.be/OUSvv2maMYI

You're thinking of mjpt777.

There's two problems with the lookahead approach:

1) It only applies to the code you write. Libraries can still use insecure object serialization under the hood i.e. you can't apply this to an built in app server running JMX.

2) It doesn't account for pathological objects, i.e. a billion laughs attack: https://gist.github.com/coekie/a27cc406fc9f3dc7a70d

More details here: https://tersesystems.com/2015/11/08/closing-the-open-door-of...

Jasypt is unfortunately prone to inventing its own crypto. This in itself leads me not to trust it.

http://security.stackexchange.com/a/65240/6714

Thank you fsargent. You are a scholar and a gentleman.

So much great code being checked in.

Try the Mechanic's Library, off Market St near the Crocker Galleria.

It's MD5 with a salt.

"Since the hashed password is never exposed outside of our data center, we don’t think that the differences between MD5 and SHA-1 are relevant. I.e. the risks for MD5 are about producing two inputs that match the same output. In the case of a purely back-end MD5 hash, any hypothetical attacker doesn’t have access to either the output (the MD5 hash) or the original input (the user’s password and our salt), so there really isn’t any productive attack based on MD5 vulnerabilities.

Of course, if someone has your original password and our salt, they might be able to come up with a SECOND synthetic password that hashes to the same value. (Since we constrain password characters that we accept, that might not be possible, but let’s assume it is…) The attacker could theoretically use this second password to access your account. But that same attacker could just use your original password, so I don’t see a real-world attack that would be improved with SHA1.

(Before Evernote, I spent five years building high-end cryptographic systems for government customers [e.g. http://www.isto.org/ose-site/file-fix/Public/corestreet-secu..., so I get to make use of my old crypto knowledge from time to time…)"

http://blog.evernote.com/tech/2011/05/17/architectural-diges...