Sorry if I was ambiguous before. When I said "log format", I was referring to the message part of the log line. Standardized timestamp, line in the source code that emitted the log line, and level are the bare minimum for all logging.
Keeping the message part of the log line's format in sync with some external store is deviously difficult particularly when the interesting parts of the log are the dynamic portions that can take on multiple shapes.
Sure the relative difference between the fastest and slowest approach is 5x. But the absolute difference is still just 125.23 ns. For some perspective, 1 millisecond / 125.23 ns = ~7,985.
There certainly are cases where that slowdown matters. But for the vast, vast, VAST majority of applications, it is completely irrelevant.
As you correctly point out, everything you can do with metrics can be achieved via logs if you have enough compute and I/O. But that ignores the reality of what happens when you do indeed have too many logs to use something fancier like column store/inverted indices as you point out? I agree that in the vast majority of cases, it's likely fine to just take the approach of using logs and counting. But plenty of of developers (particularly here on HN) are in that overall small slice of the overall community that does have a genuine need for greater performance than is afforded by some form of optimized logging.
Likewise, traces are indeed (as you point out) functionally just correlating logs from multiple services which is akin to syntactic sugar. But again, that's precisely its value _at scale_: easing the burden of use. I've personally seen traces that reach across tens of services in an interconnected and cyclical graph of dependencies that would be hellish to query the logs for by hand.
Graphing metrics and doing transformations/comparisons is (much) faster. Yes, metrics do have to be defined first but in my experience that's a non-issue since the things you want to monitor are usually immediately obvious during development (e.g. request-response times, errors returned, new customers acquired, pages loaded, etc.).
With that being said, it's not a mutually exclusive situation. You can have both. However, some logs used for plotting metrics have near-zero debugging value (e.g. a log line that just includes the timestamp and the message "event x occurred"). Those kinds of logs should be fully converted over to metrics.
Some other logs however are genuinely useful (e.g. an exception occurred, the error count should be incremented, and this is the stack trace).
I think the author is asserting that trading away the hackability is worth the faster compile times because faster compiles lets you iterate faster and therefore increases hackability (i.e. put in minutes of effort once and get minutes of benefits per compile in the future).
> The benefits will include comprehensive outpatient and inpatient
medical care, long-term care, primary and preventive care, prescription
drugs, laboratory tests, rehabilitative, dental, vision, hearing, etc.
all benefits required by current state insurance law or provided by the
state public employee package, Family Health Plus, Child Health Plus,
Medicare, or Medicaid, and others added by the plan.
I'm struggling to understand what is not covered beyond that.
Keep in mind that a substantial portion of users now use ad blockers such that a lot of URLs used for analytics like this are blocked.
Consequently, you can't actually expect to capture 100% of these analytics events nor even expect the percentage captured to stay the same over time since the filter lists are very regularly updated and users enable/disable different ad blockers over time.
More broadly speaking, once you have sent a webpage to the user, you should not expect anything from the user's browser. They may or may not allow whatever arbitrary JS you have on the page. They may even intentionally give you bad data (e.g. hijack the payload to give you intentionally malformed data).
edit: even more broadly speaking, there's additional reasons why you can't expect to receive these kinds of callbacks: consider what happens if a user loses connectivity between loading the page and them navigating away (e.g. their phone loses service because they went into an elevator before navigating away)
One interesting thing is that First Class Parcels have noticeably faster delivery times than First Class Letters (as long as you both start and end in the continental US).
3. Practical questions; e.g. a question that more-or-less represents something you might actually encounter in your day to day job, for instance querying multiple APIs and joining the data together into a particular expected format
---
1 isn't bad due to its level of ease. 2 is awful since you mostly just need to grind many hours of Leetcode to be able to consistently solve those kinds of problems. 3 is enjoyable since the problems given might actually teach you something you'll use day-to-day.
> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
They have been moving to services, but all of their other services are distinctly mass consumer oriented; e.g. TV+, Music streaming, Fitness+ videos, Arcade, News+, iCloud photo backup, Card
I'm surprised Apple supports custom email domains to any extent. Apple is a consumer electronics company. Hosted email on custom domains is very distinctly not a typical consumer behavior.
Could you not argue the same thing for almost any code used by almost any piece of software closer to the metal?
e.g. someone manages to slip malicious code into Chrome/Chromium which eventually makes its way out to every Electron app/most browsers, or something gets injected into Windows/macOS/Linux, etc.
In NYC at least, electric supply charges are distinct line items from electric delivery charges. Consumers do have the option of choosing who supplies their electricity (e.g. namely if you want to buy your electricity from a green source). But the local monopoly is always entitled to charge you for the service of actually delivering said electricity to you.
Both charges fluctuate from month to month. When I still lived in Indiana, the local monopoly lumped together supply and delivery charges into a single line item which, interestingly enough, was significantly lower than what I pay for just delivery now.
The following prices are for roughly April.
NYC (ConEd) delivery charge is ~$18/month + ~$0.123/kWh. Supply is usually something like ~$0.115/kWh.
Indiana (Duke Energy) total cost (including both supply and delivery) was ~$9/month + ~$0.115/kWh.
Keeping the message part of the log line's format in sync with some external store is deviously difficult particularly when the interesting parts of the log are the dynamic portions that can take on multiple shapes.