A lot of this article seems to be conflating two things:
1. The ability for the code to process the error and recover from it
2. The ability to sensibly log, trace, and later for a human to understand the error after the fact
The later of these is best handled by using a tracing library systematically throughout your code to spit out open telemetr and “logging” the error within your local span. You can then debug the problem with a tool like honeycomb which’ll give you a much clearer idea of what’s going on. Having tracing in place will also help you debug in cases where you don’t have errors but your system is running slowly, doing something unexpected, etc.
This greatly reduces the problem domain you have to solve in actual error handling to just having the computer recover when something is recoverable. And in these situations it turns out that most recoverable errors are best expressed as “non-errors” once they migrate any distance from the origin of the error (e.g. the record not found turns into a standard “user not known” status return value - it’s no longer an error, but an expected behavior of the system!) So for these “short lived” errors that are either handled locally or bubbled up all the way to the top and never handled, I’ve found that Go’s native basic error framework is fine.
I don't think there's a way to check for sure but I'd say that's pretty likely. There are billions of android devices, and Linux servers, while popular, are probably less common just because servers are less common than consumer devices in general. But maybe I'm wrong!
Fowler's Law on Unicode: There's always another bug, you just haven't found it yet.
Dr Drang's script counts the number of _characters_ not the number of _glyphs_. This matters because there's more than one way to represent é: Either just as unicode character \x{e9} ("NFC") or as a combination of "e" and the combining character that adds the accent ("NFD")
For example for "léon" this prints out "l3n" for me.
Before I put down cash I have basic questions, like “how do I type a square bracket?” and “how do I type a backtick?”
The on-screen keyboard is pretty good, but makes coding and typing markdown hard. Will this solve this?
Also, this seems to be missing cursor keys. How do I move back and forward precisely? If the onscreen keyboard is hidden, I can’t even long press on space to move the cursor.
That’s actually one of the main reasons I like Obsidian - that I can easily use vscode with it. Obsidian’s backend is just markdown files on the file system which you’re free to edit with another editor at the same time as you have Obsidian open (it’ll notice file system changes and update any open documents near instantly). I even have a plugin setup that when I hit a keyboard shortcut it executes the necessary vscode command line tool to open whatever I’m viewing in obsidian in vscode.
I'd like to apologize on behalf of MaxMind for breaking your CI build. Let me assure you as a fellow programmer, I know how frustrating that can be! As you saw we've tried to reach out to the larger open source projects using GeoLite2 in advance, but we've not had time to give as much notice as we would like.
The CCPA was finalized in October, and it contains a number of ambiguities, particularly as it relates to our products. To arrive at our current interpretation, it has taken many weeks of working with privacy lawyers, following discussions in the privacy community, and observing actions other companies have taken. We're sorry for the timing, appreciating the frustration it causes, and wish we could have provided more notice.
With regard to the regular updating of the database automatically, I recommend you take a look at our own tool for automatically downloading the latest database: GeoIP Update https://dev.maxmind.com/geoip/geoipupdate/
We apologize for not providing more notice. The CCPA was finalized in October, and it contains a number of ambiguities, particularly as it relates to our products. To arrive at our current interpretation, it has taken many weeks of working with privacy lawyers, following discussions in the privacy community, and observing actions other companies have taken. We're sorry for the timing, appreciating the frustration it causes, and wish we could have provided more notice.
Will it be possible for malicious users to inflate the size of the database dramatically by submitting thousands/millions of Do Not Sell IPs?
Also, what’s the procedure a user needs to go through before adding an IP to the Do Not Sell list? How do you determine the users authority to make a change? I didn’t see any info on the notice itself. Hopefully you require the user to show extended “ownership” of the IP over the course of a month or more, lest users on dynamic IPs and temporary AWS/GCP/etc IPs are submitted for removal.
The problem with charging a fine is that by providing a mechanism for penance it reduces the pressure for those people who are prepared to pay fines to actually return the books on time.
The more affluent therefore work under different rules than the less well off, and can be "justified" in keeping books longer than they otherwise should. This probably explains why in the article they found a reduction in late returns when they abolished the fines.
It sure seems to me that wealthy people would be smart enough with their money to never pay a fine for a late library book. Unless they really are the type of wealthy people that always pay more for convenience, but then, why would those types be slumming around the library? They'd surely just buy books on Amazon.
Libraries can sometimes be much better for book discovery than the web.
You can pick up books and skim through as much as you want on the spot. You can go to a shelf and see many of an author’s books next to each-other, or see many books about the same topic.
My Grandmother loved the physical paper mail I used to send to her back home in the UK from https://www.pc2paper.co.uk/
She commented once that it took almost no time for the letter to get from the US to her. That's because, of course, I just uploaded the PDF for printing in the UK.
1. The ability for the code to process the error and recover from it 2. The ability to sensibly log, trace, and later for a human to understand the error after the fact
The later of these is best handled by using a tracing library systematically throughout your code to spit out open telemetr and “logging” the error within your local span. You can then debug the problem with a tool like honeycomb which’ll give you a much clearer idea of what’s going on. Having tracing in place will also help you debug in cases where you don’t have errors but your system is running slowly, doing something unexpected, etc.
This greatly reduces the problem domain you have to solve in actual error handling to just having the computer recover when something is recoverable. And in these situations it turns out that most recoverable errors are best expressed as “non-errors” once they migrate any distance from the origin of the error (e.g. the record not found turns into a standard “user not known” status return value - it’s no longer an error, but an expected behavior of the system!) So for these “short lived” errors that are either handled locally or bubbled up all the way to the top and never handled, I’ve found that Go’s native basic error framework is fine.
reply