I used Google Sites a long time ago and I'm a bit surprised it still exists (with Google killing products all the time). How is it with revision history, etc. Is it easy to download the contents in a reasonable format? One advantage of GitHub/GitLab is that you have all your archive in source control all the time.
Are you interested in working on a text editor? If so, I have an idea I plan on implementing myself for fun: a clone of HeyNote with some added functionality. HeyNote is a simple buffer that consists of blocks. It's useful when you just want to note a simple block of text (an SQL query, log output, test data) but you are not interested in structuring it. What HeyNote lacks is the ability to add title and tags to blocks. It's not an alternative to other note taking applications. It is just a buffer with unrelated blocks in it.
That's explained at the end (Revisions). Fowler is probably looking for a general term that can be used to describe this specific way of debugging. Since he is aware of git bisect (and I'm sure he knows about hg bisect) there must be a reason he is not preferring "bisect debugging," for example.
Edit: The term diff has a clear link with version control. bisect is not that obvious. It may be ambiguous/vague in debugging context. I would still call it "bisect debugging."
Watching Brandolini is fun. He always have fun slides to look at and a humorous way to express his ideas. This talk is no exception. There are two things I would like to highlight:
- Brandolini thinks using Lo-Fi tools (like sticky notes, pen and paper) is superior to digital alternatives because when using them you focus is modelling instead of tidying the diagram. He says: "Digital tools are changing your brain priorities. I enter a session to model, and I find myself aligning rectangles and making arrows clear."
- Following the domain expert wherever they go is not necessarily a good idea. In many cases, the domain expert will push for a quick fix in the system instead of aligning the code base with the business and that will not be beneficial in the long run.
The book was published in 2010. And for a 13 year old book it certainly feels old. This is a compilation of short articles written by several people. And they generally do a good job of articulating their thoughts, but I cannot say it's full of gems, or anything. There is obviously some good advice. After all they are all experienced people with a good understanding of the field. But there are also sentences like "Do not only measure test coverage, but automatically check the results, too. Again, break the build if test coverage is too low." or "Have a regular code review day each week. Spend a couple of hours in a review meeting." So... I think it makes good light reading. You can read a single of these 97 "things" in a couple of minutes. But I wouldn't keep my hopes very high.
BTW: The book is available in GitHub: https://github.com/97-things/97-things-every-programmer-should-know
Please consider posting language specific questions to language specific communities in the future. For example, !c_lang@programming.dev
Thanks for the explanation. If it works, don't fix it :)