hueyp
Joined 14 years ago
Joined 14 years ago
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:
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())
Or is the previous map required?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).
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.