Formatting, typos - talk 21-35

1 files changed, 38 insertions, 29 deletions

diff --git a/2020/info/24.md b/2020/info/24.md
index 256e7f42..70ec13fd 100644
--- a/2020/info/24.md
+++ b/2020/info/24.md
@@ -28,49 +28,58 @@ dirty code that makes this wonderful functionality work.
 
 <!-- from the pad --->
 
--   Actual start and end time (EST): Start 2020-11-29T10.34.52; End: 2020-11-29T10.55.39
-
+- Actual start and end time (EST): Start: 2020-11-29T10.34.52; End:
+  2020-11-29T10.55.39
 
 # Questions
 
-
 ## Q3: How large of a codebase could this be used to analyze? Are there known limits in size?
-
-Nope, so far I could create a microservice picture at work that has a few million of lines. I did not do stress test, but I am confident that (at least the hotspots analysis) does not break.
-
+Nope, so far I could create a microservice picture at work that has a
+few million of lines. I did not do stress test, but I am confident
+that (at least the hotspots analysis) does not break.
 
 ## Q2: Have you uploaded this file somewhere (or plan to do so)? This seems very useful so I would love to have these code snippets.
+It's totally my plan to make this accessible to everyone: we need more
+code quality for our feature (software is everywhere)! The plan was a
+series of blog and learn how to publish in MELPA later.
 
-It's totally my plan to make this accessible to everyone: we need more code quality for our feature (software is everywhere)! The plan was a series of blog and learn how to publish in MELPA later.
-
-That's great, make sure to announce it somewhere so we know when it comes out :D. Or maybe link the git repo that you are using for this.
-
+That's great, make sure to announce it somewhere so we know when it
+comes out :D. Or maybe link the Git repo that you are using for this.
 
 ## Q1: What is used to measure the complexity of a LISP file, from your point of view? The nesting level per chance?
+Indentation is good enough to apply in general. Even Lisp gets
+formatted in a standard way. Probably you can come up with a more
+specific and precise way, but indentation is a really rough metrics to
+give you a general idea. So take with a pinch of salt, but exploit to
+find weird things.
 
-indentation is good enough to apply in general. Even  lisp gets formatted in a standard way. Probably you can come up with a  more specific and precise way, but indentation is a really rough metrics to give you a general idea. So take with a pinch of salt, but exploit to find weird things.
-
-OK, thanks for the response.
-
+- OK, thanks for the response.
 
 ## How did you summon, resize and dismiss that window so seamlessly?
--   org-roam and C-x0
-    -   How did you resize it from 2/3 to 1/3 of the frame?
-        -   golden-ratio-mode from golden-ratio
+org-roam and C-x 0
 
+- How did you resize it from 2/3 to 1/3 of the frame?
+  - golden-ratio-mode from golden-ratio.
 
 ## Have you considered doing this analysis by function instead than by file?
--   I did not have chance yet to integrate that, but the theory is described in Adam's 2nd book: Software Design -Rays
-
+I did not have chance yet to integrate that, but the theory is
+described in Adam's 2nd book: Software Design -Rays
 
 # Notes
--  Book by Adam Tornhill "Your Code as a Crime Scene": <https://www.adamtornhillem.com/articles/crimescene/codeascrimescene.htm>
--  <https://github.com/adamtornhill/code-maat>
--  Beautiful circles diagram.
--  especially for big projects with many collaborators the codebase may become less transparent
--  hotspots: files that have had many changes based on git history; likely sources of bugs
--  Complexities of a file are measured in terms of the indentation, at least in the case of Java.
--  "If a lot of lines are deleted, that's usually a good sign. If a lot of lines are added, it's a sign of technological debt"
--  another beautiful diagram (big circle with files on periphery, linked together with curved lines) showing associations between changes in files: when this file gets changed, it usually means that this other file is also changed
--  <https://ag91.github.io/blog/>
-
+- Book by Adam Tornhill "Your Code as a Crime Scene":
+  <https://www.adamtornhillem.com/articles/crimescene/codeascrimescene.htm>.
+- <https://github.com/adamtornhill/code-maat>.
+- Beautiful circles diagram.
+- Especially for big projects with many collaborators the codebase may
+  become less transparent
+- hotspots: files that have had many changes based on git history;
+  likely sources of bugs.
+- Complexities of a file are measured in terms of the indentation, at
+  least in the case of Java.
+- "If a lot of lines are deleted, that's usually a good sign. If a lot
+  of lines are added, it's a sign of technological debt".
+- Another beautiful diagram (big circle with files on periphery,
+  linked together with curved lines) showing associations between
+  changes in files: when this file gets changed, it usually means that
+  this other file is also changed.
+- <https://ag91.github.io/blog/>.