I'm working with the PayPal API right now (send your condolences) and all their documentation is in the form of CURL requests. Just finished converting it to python requests commands and now this gets posted.
I built this! It looks like there's a lot of excitement about generating Go code. If someone wants to send a pull request incorporating the Go generator, I'll happily accept it.
We use Riemann at Two Sigma to monitor/alert/heal our Mesos cluster [1], precisely because of above reasons to reject.
>- You must pick up Clojure to understand and configure Riemann (we're not a Clojure shop, so this is a non-trivial requirement)
>- Config file isn't a config file, it's an executed bit of Clojure code
This is actually great -- static files quickly become their own franken-languages, with code generating config files.
>- Riemann is not a replacement for an alerting mechanism, it's another signal for alerting mechanisms (though since it's Clojure and the configuration file is a Clojure script, you can absolutely hack it into becoming an alerting system)
>- Riemann is not a replacement for a trend graphing mechanism.
You probably don't want another alerting mechanism; you probably already have pagerduty or something else -- what you want is a rich way to create the alert.
> You probably don't want another alerting mechanism; you probably already have pagerduty or something else -- what you want is a rich way to create the alert
This is the heart of why we use Riemann. When we first started using it 2 years ago, we had thousands of different types of error emails per day (due to monitoring thousands of retail stores, all with their quirks). Because Riemann config is just code, we were able to build systems and abstractions on top of it for describing the various error types and their semantics. E.g If 500s are being returned from service A, only alert us if > 1% of those requests failed in the last 2 minutes. You can get these kinds of rules in something like Nagios, but if you want customization, you have to deal with plugins. Here, it's just code. If we don't like it, we change it. The result is that there's no excuse to setup gmail filters. You can ensure that all errors are actionable.
To load the framework (application) with the logic with the concern of deciding what resources it wants. The scheduler shouldn't care about what you get, just fairness. Two-tiered scheduling achieves this:
Mesos decides how many resources to offer each framework, while frameworks decide which resources to accept and which
computations to run on them.
I guess that makes sense if frameworks care about placement (which I generally don't) because otherwise they'd have to express placement constraints to Mesos.
I still can't find documentation about what fairness policies are actually implemented, though.
This sounds like the story Jessica Livingston mentioned at Startup School 2012 <http://news.ycombinator.com/item?id=4699862 >, if I remember correctly -- business in Texas got a term sheet, moved to California, investors pulled out when their user acquisition metric changed. Anyone have more color on this?
Poor example-- the Famine should be known as the Starvation. There was plenty of food to ration to the Irish, even on Irish land; the British instead shipped it home, or fed it to cattle and then shipped that home, and let the Irish starve instead.
Sorry to be late to the party-- xaa, could you explain a little more what you mean by
"Ultimately I believe the breakthroughs will come fastest if we can "close the feedback loop" by automating a lot of bench biology, and then have computers both generate and test hypotheses."
I don't know anything about bioinformatics, so I'm trying to see how this differs from vanilla automated model selection. I'm really interested, so please feel free to send me an email if you feel that's more appropriate.
