The pocket guide to debugging
jvns.ca
jvns.ca
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)
Keep it up, and many thanks!
The customs situation is a pain though, I wish I had a better solution.
I think it is okay since paywalled articles reach HN front page too. Also, if you had submitted this yourself as a Show HN, the guide (https://news.ycombinator.com/showhn.html) says "For books, a sample chapter is ok." - and https://wizardzines.com/zines/debugging-guide/ does have samples
Love your work. Always fascinates me to see how people approach simplifying something complicated. These remind me of a feeling I also get when I'm reading Scott McCloud: comics are vastly underrated for educational content.
I have been following your blogs and zines for years now. Keep up the good work and vibes. Peace.
(the way it works is that I add 1 copy to give away for every 1 copy sold, but it's a manual process)
It is not like everyone is obligated to follow freeware/freemium/patronage business model.
You are being too humble :) Great work deserves attention and payment.
I just ordered the 12 pack of physical print version zines + PDFs :D
https://wizardzines.com/zines/all-the-zines/
It includes the pocket guide to debugging zine, and 11 other zines!
Just bought the 12 pdf pack to show to my 7-yo girl that what I do sometimes is "fun" (and a refresher for some of the topics for myself).
Thanks!
She is an author that I love to support.
In every app I do I abstract time and scheduling/threading away, to be able to run any domain logic in a deterministic and as fast as possible way (i.e. the clock jumps to next event/treatment time instead of having to wait for it).
It's such a bliss for testing and debugging (can run hours in seconds, turn on all logs safely, rule out threading issues by reproducing with a single thread, etc.), it's a shame it's not a built-in feature in most (any?) languages or their core libraries clock/scheduling APIs.
I work mostly in Java, and started to do it in C/Ada, but anything Turing-complete should be fine.
>Any recommended reading about this topic/approach?
I learnt it implementing HLA norm for distributed simulations (https://en.wikipedia.org/wiki/High_Level_Architecture), but most of HLA is about distributed work synchronization, if you stay local you just need to retain the idea of advancing the time discretely from software, instead of having it flow uncontrollably with hardware ticks.
Here is a previous comment I made on the same topic: https://news.ycombinator.com/item?id=22390113 You can find links to code in my (other) comment in the linked InfoQ article. In particular you can try out clocks/schedulers provided by jolikit's SchedulingHelper class, with various kinds of SchedulingType: HARD (time = f(system_time)), SOFT_HARD_BASED (virtual time trying to keep up/down with a HARD master clock), and SOFT_AFAP (virtual time jumping instantly between works).
I've done all of those steps on that action list, and have thoroughly enjoyed the time I spent debugging (not really).
So many fond memories spending weeks on a bug only to change one line of code. Joy.
- "reread the error message" (please remember to do it, do it again, ...and again)
- "take a night break" (It's wonderful how a night of good sleep can solve your bugs)
Anyways, as a self-taught junior developer, I'm always looking for ways to become a better programmer, so thank you for this :)
https://wizardzines.com/zines/debugging-guide/samples/2-tiny...
You can institutionalize this practice at your org in some ways. At my org we have:
* strawman apps for our cloud systems and our windows services to practice deployments and startup/shutdown behavior without having to wait to compile full apps
* alwaysfails and alwayspasses tests in our test projects for confirming how test frameworks behave and our test reporting/logging function
* to some extent, health check pages on apps can hold limited tests https://www.thoughtworks.com/radar/techniques/health-check-p...
Maybe the zine encourages that, haven't read it yet, but looking forward to digging in based on recognizing this strategy.