jvns

From the other side, I’ve fairly often written blog posts that I don’t put much effort into and have no intention of reaching the front page of HN, only to see 12 hours later that somebody submitted it and it’s on the front page.

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.

I pay for a tool to convert HTML/CSS into PDFs https://www.princexml.com/ and it seems to work well. I don't have the best idea of how it compares to the various free options though.

I tried to grep the code for `api.` to get a sense for all the vendors this codebase is using, and which you'd need to have relationships with to run the code. Here's what I found:

payments:

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

tax stuff:

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

for iOS app (?):

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

AI stuff:

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

other:

  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"?)

Deleted this post because I don't think a random screenshot from my email is a good source for people to refer to. A better source might be the bitly terms of service: https://bitly.com/pages/terms-of-service (1.4 Destination Preview)

Yes! Katie and I made it into a zine because I was such a huge fan of her work on https://ohshitgit.com/. (you'll notice she's a coauthor of the zine)

That's a great idea, thanks.

That book (Ed Mastery, https://mwl.io/nonfiction/tools#ed) is an April fool's joke, but it's a real book and I thought it was actually really good. I've still basically never used ed but it was fun to learn about and it helped me understand vim's history a little bit.

fixed, thanks!

fixed, thanks!

Like I said in the blog post, I'd love suggestions for other things I've missed that happen when you run "hello world", _especially_ if there's a way to use a Linux spy tool to trace what exactly is happening.

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.

Hello! I wrote this post and I have a couple of things to say about this "DNS is not actually hard" take. It took me many years to feel totally comfortable debugging DNS problems, and I wrote this post to explain why I think it was hard for me.

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.

note: it was available before, the only change is that now it's in a github repository instead of a zip file that you download from the website

A DNS resolver is both a client and a server -- for example Google's 8.8.8.8 (which this is a toy version of) is a server (you can query it with `dig @8.8.8.8 example.com`), but also a client of the various authoritative DNS servers that it fetches and caches records from.

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".

thanks, I'll take a look

There's this by Andreas Zeller: https://www.debuggingbook.org/, it's an interactive free book with implementations of a bunch of different debugging tools in Python

Awesome! My mom is from Trinidad so I always love hearing from folks from there :)

The initial 1000 copies ran out, but I just added a few hundred extra so it should work now.

Unfortunately I've done a bunch of research into this and I've never been able to find a print-on-demand service that prints the zines in a way that I was happy with. Print on demand is easier for regular books, but the booklet format is a bit weird.

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

As the author, I don't think this really makes sense on the front page of HN since you have to pay to read the zine.

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)

I'd never heard of this, thank you! I was hoping for people to provide more examples of things that have gotten easier in this thread but I'm happy to see one or two at least :)

Restarted the server and it should be back up for now :). Here's the culprit:

> 2021/12/15 18:39:10 http: Accept error: accept tcp [::]:8080: accept4: too many open files; retrying in 1s

should be fixed now, sorry about that!

Google Keep lets you make checklists and it's easy to uncheck everything on the list. I use it to make "leaving the house" lists etc.

I also implemented a vaguely Hey-inspired system in Fastmail a year ago and it's been good.

One tweak that's really helped me: when I filter things to "The Feed", I also use the filter to snooze them until 6pm, so I only get mailing list emails once at a day.

there's a site called focusmate that helps you find accountability buddies (https://focusmate.com). it's really helped me.

Author here. I wrote a post about the design of this game on my blog: https://jvns.ca/blog/2021/04/16/notes-on-debugging-puzzles/

One thing I find a bit strange about this (as a Gumroad user) is that Gumroad employees don't seem to be granted @gumroad.com email addresses -- when I've needed to email their engineering staff or marketing staff I often get replies from someone's personal email address.

The fact that employees are using their personal email address to do Gumroad business makes me feel a bit uncertain about how securely my information / my customers' information is being stored.

in case you haven't seen it: No Starch Press published a box set of all my free zines called "Your Linux Toolbox". I have some links to places you can get that here: https://jvns.ca/blog/2019/10/21/print-collection-of-my-first...