I realize this sounds like a humblebrag but it is not a positive thing for me to have every single thing I write submitted to HN whether it’s relevant to a broad audience or not.

payments:

  https://api.paypal.com 
  https://api.stripe.com

  https://api.taxjar.com
  https://api.vatstack.com (EU VAT)
  https://apiservices.iras.gov.sg

  https://api.appstoreconnect.apple.com 
  https://api.storekit.itunes.apple

  https://api.iffy.com  (AI content moderation)
  https://api.helper.ai (AI support)
  https://api.openai.com

  https://api.easypost.com  (shipping labels?)
  https://api.sendgrid.com (email)
  https://api.pwnedpasswords.com (haveibeenpwned)
  https://api.worldbank.org (for purchasing power parity?)
  https://api.dropboxapi.com (for "upload from dropbox"?)

Comments URL: https://news.ycombinator.com/item?id=39301741

Points: 3

# Comments: 0

Considering adding a few things that are happening in the kernel and trying to use `bpftrace` to trace them, but I need to figure out how to use bpftrace/kprobes and hunt down the relevant kernel functions.

I also used to think that "no, actually, it's easy!" was an encouraging response to "this is hard to learn". And I kind of get it! I love DNS! I think it is surprisingly simple in many ways, and I've written about that a lot, for example in https://implement-dns.wizardzines.com which shows you how to implement a toy DNS resolver from scratch in some pretty simple Python code.

But over the years I've learned that "no, it's easy to learn!", instead of coming off as an encouraging comment ("you can do it!"), often gets received as "no, it's not hard, actually the problem is that you're dumb". Like, I've been confused about this for years, and you're telling me that, no, actually it's easy? Not that helpful!

So I've stopped telling people that, and instead I put a huge amount of work into trying to understand _why_ people find certain things hard and work to help remove some of those barriers.

I implemented this as a command line tool because that's much easier to do in a Jupyter notebook environment, but you can also pretty easily transform it into a UDP server running on localhost and query it with dig in the same way that you would with 8.8.8.8. That's one of the bonus exercises at the end (Exercise 7).

I might end up bringing "convert it into a server" into the main content though because it's pretty easy to do and I think it makes the whole thing seem more "real".

(the way it works is that I add 1 copy to give away for every 1 copy sold, but it's a manual process)

The customs situation is a pain though, I wish I had a better solution.

I am doing a giveaway for folks who can't afford the zine though -- if $12 is a lot of money for you but you think the debugging advice in there would be helpful, you can use code BUYONEGIVEONE at checkout to get the PDF version for free. (it'll ask you for a billing address but if you dislike sharing your address unnecessarily like I do, you can just put a fake address)