> 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.
We've a STV system in Ireland, I'm not sure you'd classify our independents as centrist (by the Irish definition of centrist - by the US definition almost all our politicians are far left).
Overall the system works quite well, and the proportion of representatives a party has in parliament roughly aligns with first preference votes.
> But as stated by others (about Ireland in their example), even companies that had their hq there asked for zip code at a time there was not any.
Post codes are not generally used in Ireland. The launch was not really successful and even An Post (the government-run postal service) doesn't use them.
Irish counties are fun, as the traditional 26 counties (in the Republic) don't align with the thirty-something administrative counties that now exist.
> I strongly disagree that metrics and logs are different toolsets, or that you would need both of them in order to properly observe your systems.
And from the link:
> Logging can be useful for some purposes. However, it’s rare that they’re the only tool for monitoring your code. And it’s even rarer that they’re the best tool.
Metrics are a tool that take a different approach to logs, once you get beyond small systems you need both. I talked about this earlier in the year: https://www.youtube.com/watch?v=hCBGyLRJ1qo
Prometheus is not intended as durable long term storage, it's fundamentally limited to the size of a machine. You should also design your monitoring be able to tolerate completely losing the data of a Prometheus.
Splunk is a event logging system, compared to Prometheus which is metrics based. You need both types of systems to be able to properly observe your systems, they're complementary.
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.