> It also reveals that, whatever the people of Ireland have been told, their app is collecting centralised data on them.
The signup flow has a very obvious and well written opt-in for collection of anonymised data to help track how well the app is working, which was mentioned by the BBC article linked. I don't think people are being mislead.
I personally decided not to enable that, but did give the app my phone number to be shared in the event I'm a close contact.
> it has been in use, it is claimed to have resulted in 91 “close contact exposure alerts”, which is remarkably few.
That they know of, as those users either opted in to the anonymous tracking or (possibly) gave their phone number. It'd be useful to know how the install base per the usual Android/iOS stats compare with the anonymous tracking enablement, but those numbers haven't been shared as far as I'm aware.
Right now our overall case numbers are low enough (around 20 per day) that it's likely hard to tell how effective the app is. However our R is currently estimated at 1.1, so even a little help from the app could help keep us below 1.
I don't think there's any clear standard. There's many confusions about push vs pull that make the discussions hard to follow, as they often make apples to oranges comparisons. For example the push you're talking about in your comment is events, whereas a fair comparison for Prometheus would be with pushing metrics to Graphite. https://www.robustperception.io/which-kind-of-push-events-or... covers this in more detail.
Taking your example you could push without sending a packet on every event by instead accumulating a counter in memory, and pushing out the current total every N seconds to your preferred push-based monitoring system. You could even do this on top of a Prometheus client library, some of the official ones even as a demo allow pushing to Graphite with just two lines of code: https://github.com/prometheus/client_python#graphite
In my personal opinion, pull is overall better than push but only very slightly. Each have their own problems you'll hit as you scale, but those problems can be engineered around in both cases.
Seconding this. Out of all games in that general category Rimworld is scratching my DF itch, without me having to dig all the way back into full DF complexity.
At a previous company (30-40 employees) the main thing was having a blog setup somewhere that engineers could post to - clearly distinguished from the main product blog. Actually getting engineers to write up blog posts was a separate problem. Besides me there were only a handful, even when it was made clear that it could be about a very small topic. A few hundred words is plenty.
That works until there's ~only self-checkouts, then it gets slow again.
There's a knack to using them, and unless you have a generous number of them (I know of only two local stores that do), you end up getting stuck while the single staff member assigned to the self-checkouts assists customers having issues.
Plus it's not unusual for a significant number of them to be out of order, not accepting credit cards, only accepting credit cards, or just being generally temperamental.
At least for Prometheus the ones we tagged with hacktoberfest are ones we'd expect a new developer to have a good chance to be able to complete.
I don't think we should be disincentive people who attempt to instead tackle more thorny issues.