TR overview comments

Author: hjwp

chapter_23_debugging_prod.asciidoc

@@ -18,6 +18,41 @@ Oh yes, waiting to be logged in. And why was that?
 Ah yes, we had just built a way of pre-authenticating a user.
 Let's see how that works against our staging server and Docker.
 
+////
+
+CSANAD: 
+Later in the chapter, where we are deploying to the staging environment, I got
+stuck: test_my_lists failed by telling me it could not find #id_logout. Since
+the test ran fine just previously against the local docker, and the deployment
+is a .tar archive, and there may not be sqlite3 client installed by default, it
+may not be very straightforward to investigate if the reader believes there is
+a discrepancy between their local docker deployment and the staging.
+
+This got me thinking: maybe we could add a few hints for what to do in case the
+reader believes there is a bug on staging: trying to reproduce it on the local
+docker environment and manually checking sqlite (e.g. by doing SELECT * FROM
+account_token; or SELECT * FROM account_users;...), add logging.info() or
+logging.debug() so that it shows up in the logs, etc). I think it would fit the
+scope of the chapter, as it's titled Debugging And Testing Production Issues.
+
+SEBASTIAN:
+It's worth reiterating the testing strategy in the real world. The chapter is
+called "Debugging And Testing Production Issues" yet it focuses on running
+tests against another non-production environment. It uses methods which I find
+a bit controversial because they don't treat the staging environment as a black
+box.
+
+
+DAVID:
+Nice one. I particularly liked the discussion of when to choose not to test
+something, in this case email.
+
+I do think we should talk a little more about security here - readers should
+adopt a security mindset when doing things like this and make sure they think
+things through.
+
+////
+
 
 
 === The Proof Is in the Pudding: Using Docker to Catch Final Bugs

chapter_24_outside_in.asciidoc

@@ -13,6 +13,27 @@ So let me know what you think of the chapter, via [email protected]
 *******************************************************************************
 
 
+////
+
+
+SEBASTIAN
+This chapter is not the easiest one to read and follow.
+I suggested adding some diagrams to visualize layers that we are crossing while doing outside-in TDD.
+I would consider removing a part about @property or at least discourage readers from doing DB calls inside it.
+
+
+DAVID
+I really like the outside-in focus of this chapter.
+
+Something occurred to me about the implementation that I don't mention in the
+comments (not specifically related to this chapter). We are using the email in
+the URL, but email addresses aren't guaranteed to be valid URL components - we
+should probably urlencode them, right?
+
+
+////
+
+
 ((("Test-Driven Development (TDD)", "outside-in technique", id="TTDoutside22")))
 In this chapter I'd like to talk about a technique called Outside-In TDD.
 It's pretty much what we've been doing all along.

chapter_25_CI.asciidoc

@@ -12,6 +12,40 @@ Let me know how you get on :)
 
 *******************************************************************************
 
+////
+SEBASTIAN
+A crucial chapter.
+I miss some introduction to what CI actually is and what is its role in today's
+modern development. Like some sales pitch why readers should care if they are
+strangers to the concept. Some mentions of team work in a contemporary working
+environment would be great 👌
+
+What I noticed is that somewhere in the middle pace changes from quickly
+getting up to speed with Gitlab CI to tedious debugging.
+
+I think it might use a refreshing perspective AFTER the debugging part to zoom
+out, sum up what was done, how this could've been avoided and how it works in a
+modern working environment. Being able to run all or as many tests as possible
+locally is great, but normally (my experience, so might be biased) ppl build
+things from the start to make sure that CI will pass.
+
+DAVID
+Well worth including this chapter!
+
+Quite a bit of tweaking needed but it's a good one.
+
+I think we should be mentioning LLMs more as a debugging tool these days.
+
+In one comment I mention that setting up a project looks different if you're signing up for a free trial, here's a screenshot:
+Side question, not specifically relevant to this chapter, but the requirements pinning seems a bit off to me - I only had Django in my requirements file, also the versions in the Dockerfile are defined separately. Possibly this has been addressed since I reviewed earlier chapters.
+Another few things maybe worth mentioning for additional context:
+
+    Precommit hooks - maybe don't need to get into them here, but they do address some of the things that CI also addresses.
+    Perhaps worth talking about how CI really comes into its own when working in teams, especially with open source. At the moment this is oriented around solo projects.
+    Could mention linting too!
+
+////
+
 
 ((("Continuous Integration (CI)", id="CI24")))
 ((("Continuous Integration (CI)", "benefits of")))

chapter_26_page_pattern.asciidoc

@@ -11,6 +11,17 @@ Still, it's a fun chapter, give it a go,
 and let me know how you enjoy it!
 
 *******************************************************************************
+////
+DAVID
+
+
+The format of this chapter works really well!
+
+I wonder if there is a way of introducing some of this earlier in the book in
+two or three places, maybe in smaller ways. They could commit beforehand and
+then try to solve certain problems on their own, then undoing their work
+afterwards and replacing it with how you did it.
+////
 
 // DAVID: What proportion of readers will know the meaning of the word 'copacetic'?
 
@@ -22,6 +33,8 @@ and they're positively prehistoric now.
 Regardless, let's say lists are often better shared.
 We should allow our users to collaborate on their lists with other users.
 
+// HARRY: restore Irregardless here somehow?
+
 Along the way we'll improve our FTs
 by starting to implement something called the Page object pattern.