hueyp

That said, in the defence of romans, they were also open to learning and integrating others ideas into their own. Scipio africanus absolutely learned from hannibal, and was able to layer aggressiveness, deception, and delay into his strategy. Every metaphor is imperfect, and cannae is absolutely an example of being blind / stubborn, but my quibble with the OP would be that romans didn't _really_ change their aggressive identity in the long term, and that identify continued to serve them well for 100's of years after hannibal.

I don't know which, but I think one of the `RANGE_DELETE` vs `NODE_DELETE` said it could take a list of ids but only one of them could -- it was something like this at least ... maybe path vs key? I don't remember how it was documented -- this is what I had in mind when I said wrong.

I didn't submit PR's btw -- I suck at open source :).

Exactly. Same thing with public records -- having a public record could very well mean you have a higher default rate but what is important is LC punishes it more than they should so its a value investment.

We invest via a model (not filters) and the whole idea behind the model isn't to find what criteria makes someone less likely to default in absolute terms, but what makes one D2 loan less likely to default than another D2 loan.

A nice talk / use case given here:

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

For example of I have a 'make_user_preferred' event, I just transact the database and then add any metadata I need to the Datomic transaction.

Datomic is Event Sourcing if you create a realized version of your database on every event. It is just smart about it and keeps diffs.

As far as the render method being big, the premise React is built on is that the virtual DOM is much faster than the real DOM. Test as necessary for your own comfort / use cases. I personally trust the testimonials of people smarter than me that aren't the React team also feel this is true and are making real changes to their products based on that. I also trust my own experiences that the DOM is slow :)

Could the java equivalent be?

  articles.stream().flatMap(article -> article.getTags().stream())

Section: "Zero or more times ... gauranteed"

"When considering the behavior of the underlying message transport, it is best to remember what is promised. Each message is guaranteed to be delivered zero or more times! That is a guarantee you can count on. There is a lovely probability spike showing that most messages are delivered one time.

If you don’t assume that the underlying transport may drop or repeat messages, then you will have latent bugs in your application. More interesting is the question of how much help the plumbing layered on top of the transport can give you. If the communicating applications run on top of plumbing that shares common abstractions for messaging, some help may exist. In most environments, the app must cope with this issue by itself."

At least once, at most once, etc are just probability distributions. All you can count on is zero or more times.

But yes, your database stores the status of a message. At this point you could drop every single message on your queue and have enough information to resend them. Each message could have its own resend (SLA) semantics.

Amazon Simple Workflows is an implementation of this pattern: http://aws.amazon.com/swf/. I've never used SWF but the docs are great food for thought.

[edit]

Also might be of interest to watch Rich Hickey's 'Language of the System'. (https://www.youtube.com/watch?v=ROor6_NGIWU&feature=kp -- there are a few versions of this talk, not sure if this is the exact viewing I saw). The talk is not really about queues, but he tries to break things up a bit. You need a data store, you need a queue, etc. As soon as a queue tries to have durable messages it is becoming a database and has all of the problems a database has to deal with. Instead you could keep data storage being solved by the data storage provider and let queues focus on passing messages.

This raises the issue of how to deal with dropped messages, but that can be solved without durable queues (like that paper describes / SWF / etc).

'Hey Underscore, You're Doing It Wrong' -- http://www.youtube.com/watch?v=m3svKOdZijA

It is much better than the title would suggest :)

This is probably my favorite part of the game -- watching pro level players react perfectly to even the slightest tell.

http://m.flickr.com/photos/maisonbisson/15521786/lightbox/

That road heading northeast past sedan crater leads to Area 51.

http://jsfiddle.net/uXbn6/378/

Very interested in this. The trivial Go examples seem much more channel as side effect.

While I still need to wrap my head around the differences (and thanks for the explanation) one quick take away is how much easier it would be to write the higher order operations with core.async channels versus observables.

For multiple value channels my head keeps going to wanting to have map, filter, etc with the channels and I'm thinking I'm missing something because that would just be creating Rx / Observables.

I have ido and find-file-in-project installed but neither of them seem to include directories in the fuzzy search. So if I search 'custcore' it won't match 'customer/core.clj'. If I instead search 'core' it is too broad of a term. I really need very little out of an editor, but this is one of those things.

Can you point out where in the docs you got this impression? So far for pedastal services (the backend stuff) all I can see is a replacement for ring and middleware. Once it leaves your handler it is back to whatever you were doing in clojure already.

Or am I missing something? Serious question. I've read the docs, but they are pretty light so far. I haven't looked at the sample code yet.

This is in comparison to reading an OO library in a language I'm much more familiar with but where inheritance / mixins mean you have to dig through many files (often not obvious which ones) to understand a piece of code.