WEBVTT captioned by sachac NOTE Introduction 00:00:00.620 --> 00:00:04.159 Alright! Hi everyone! Happy EmacsConf! 00:00:04.160 --> 00:00:07.079 I´m so excited to be here. 00:00:07.080 --> 00:00:07.959 It's surreal to be part 00:00:07.960 --> 00:00:09.439 of the conference itself, 00:00:09.440 --> 00:00:11.239 in addition to being a viewer. 00:00:11.240 --> 00:00:13.879 EmacsConf is like Christmas to me, 00:00:13.880 --> 00:00:18.159 and I'm so excited when it comes around every year. 00:00:18.160 --> 00:00:21.119 Today, my talk is on a programming methodology 00:00:21.120 --> 00:00:23.999 that I've created, discovered, stumbled upon. 00:00:24.000 --> 00:00:26.439 I call it "Bookclub Tapas." 00:00:26.440 --> 00:00:27.759 Before we get into that, 00:00:27.760 --> 00:00:29.679 let me introduce myself. NOTE Hi, I'm Maddie! 00:00:29.680 --> 00:00:32.119 My name is Maddie Sullivan, 00:00:32.120 --> 00:00:34.239 and my pronouns are she/her. 00:00:34.240 --> 00:00:36.719 I go by the handle ElephantErgonomics, 00:00:36.720 --> 00:00:41.119 which is shortened down to ElephantErgo in the IRC. 00:00:41.120 --> 00:00:43.079 You can reach out to me after the talk 00:00:43.080 --> 00:00:44.959 for questions, comments, 00:00:44.960 --> 00:00:47.759 or just to say hello by reaching out 00:00:47.760 --> 00:00:56.959 to hello@ElephantErgonomics.com. 00:00:56.960 --> 00:01:00.039 So this software development strategy I found, 00:01:00.040 --> 00:01:03.839 it's inspired by literate programming and Agile. NOTE Bookclub Tapas 00:01:03.840 --> 00:01:07.439 So what exactly is Bookclub Tapas? 00:01:07.440 --> 00:01:09.439 Bookclub Tapas is a conversation 00:01:09.440 --> 00:01:11.719 that you have with yourself. 00:01:11.720 --> 00:01:13.479 It's a log and a ledger, 00:01:13.480 --> 00:01:16.519 of your intentions, hopes, dreams, 00:01:16.520 --> 00:01:17.119 and what you've learned 00:01:17.120 --> 00:01:19.719 over the course of development. 00:01:19.720 --> 00:01:22.799 Bookclub Tapas is an oracle 00:01:22.800 --> 00:01:24.199 you can consult 00:01:24.200 --> 00:01:26.933 about the state of, and the strategies behind, 00:01:26.934 --> 00:01:29.559 your development process. 00:01:29.560 --> 00:01:33.479 Bookclub Tapas is also a peer programming partner 00:01:33.480 --> 00:01:37.119 that helps you decide how to best put forward your efforts 00:01:37.120 --> 00:01:38.439 and how to best pull together 00:01:38.440 --> 00:01:40.399 what you're working on. 00:01:40.400 --> 00:01:42.719 Bookclub Tapas will also help you to understand 00:01:42.720 --> 00:01:45.239 how to tailor scope to your needs, 00:01:45.240 --> 00:01:46.759 and how to have the best parts 00:01:46.760 --> 00:01:49.399 of your program shine through clearly. 00:01:49.400 --> 00:01:52.159 Bookclub Tapas consists of two parts: 00:01:52.160 --> 00:01:54.159 Bookclub and Tapas, 00:01:54.160 --> 00:02:00.519 but what does that mean exactly, though? NOTE Bookclub 00:02:00.520 --> 00:02:04.719 Bookclub is a reverse literate development strategy. 00:02:04.720 --> 00:02:07.479 Bookclub is a time for you to write, 00:02:07.480 --> 00:02:08.959 and then read and reflect. 00:02:08.960 --> 00:02:10.719 It's like a Bookclub, 00:02:10.720 --> 00:02:12.559 but it's for your program. 00:02:12.560 --> 00:02:15.239 Instead of inserting narration into your code 00:02:15.240 --> 00:02:17.799 to narrativize what you are accomplishing, 00:02:17.800 --> 00:02:20.759 you are instead inserting snippets of code 00:02:20.760 --> 00:02:23.799 into your narrative to make it come alive. 00:02:23.800 --> 00:02:27.999 So, what are we narrativizing, exactly? 00:02:28.000 --> 00:02:30.439 What sort of story are we telling? 00:02:30.440 --> 00:02:34.319 Bookclub is the story of you, your program, 00:02:34.320 --> 00:02:36.559 and how your efforts are allowing your program 00:02:36.560 --> 00:02:40.299 to come into the world. NOTE Too many hats, too many roles 00:02:40.300 --> 00:02:42.479 Software developers naturally have to wear 00:02:42.480 --> 00:02:43.679 a lot of different hats, 00:02:43.680 --> 00:02:46.479 and take on a lot of different roles. 00:02:46.480 --> 00:02:48.159 We apply ourselves into a lot 00:02:48.160 --> 00:02:50.079 of different contexts. 00:02:50.080 --> 00:02:53.067 We do research, interface architecture design, 00:02:53.068 --> 00:02:55.519 mathematics, philosophy. 00:02:55.520 --> 00:02:57.679 We take in the world around us 00:02:57.680 --> 00:03:00.359 and then build abstractions to model it. 00:03:00.360 --> 00:03:01.799 We translate the abstract 00:03:01.800 --> 00:03:03.079 into the concrete, 00:03:03.080 --> 00:03:04.667 and then when we're trying to teach software 00:03:04.668 --> 00:03:05.999 how to be "smart," 00:03:06.000 --> 00:03:07.239 we translate the concrete 00:03:07.240 --> 00:03:09.639 back into the abstract. 00:03:09.640 --> 00:03:11.500 I can't help but feel like so much of 00:03:11.501 --> 00:03:13.759 what makes software development difficult 00:03:13.760 --> 00:03:14.919 is just trying to remember 00:03:14.920 --> 00:03:16.679 and keep track of everything. 00:03:16.680 --> 00:03:17.959 We have to try and remember 00:03:17.960 --> 00:03:21.259 so many different implementation details. 00:03:21.260 --> 00:03:24.159 We have to remember how our own code works, 00:03:24.160 --> 00:03:26.679 how the API of our dependencies work, 00:03:26.680 --> 00:03:29.479 how relevant real-world constraints behave, 00:03:29.480 --> 00:03:31.319 what the standards lay out, 00:03:31.320 --> 00:03:34.159 and how our data structures are laid out. 00:03:34.160 --> 00:03:35.079 When we're debugging, 00:03:35.080 --> 00:03:37.519 we simultaneously have to remember 00:03:37.520 --> 00:03:40.239 how our program is currently behaving, 00:03:40.240 --> 00:03:42.679 as well as how the program ought to behave 00:03:42.680 --> 00:03:43.719 in order to get a chance 00:03:43.720 --> 00:03:46.039 to reconcile that gap. 00:03:46.040 --> 00:03:47.999 It's honestly all way too much. 00:03:48.000 --> 00:03:50.239 We need a ledger of what we're actually doing 00:03:50.240 --> 00:03:55.799 in order to stay sane. NOTE Narrativiation 00:03:55.800 --> 00:03:57.333 I think a really effective way to 00:03:57.334 --> 00:03:59.599 make sense of things that are complex and important 00:03:59.600 --> 00:04:01.039 is to narrativize them, 00:04:01.040 --> 00:04:02.839 to turn them into stories. 00:04:02.840 --> 00:04:06.039 This is a strategy that humans have been using for a long time. 00:04:06.040 --> 00:04:08.559 Mnemonic devices, metaphors, 00:04:08.560 --> 00:04:09.759 and drawing parallels 00:04:09.760 --> 00:04:12.199 are all different ways of doing just this. 00:04:12.200 --> 00:04:14.799 Telling stories helps us to understand 00:04:14.800 --> 00:04:16.359 things that are big and complex 00:04:16.360 --> 00:04:19.119 by grounding them in our own experience 00:04:19.120 --> 00:04:23.979 and making it fit into our scale. 00:04:23.980 --> 00:04:25.799 So because the way that everyone 00:04:25.800 --> 00:04:26.919 naturally tells stories 00:04:26.920 --> 00:04:28.239 is going to be a little different, 00:04:28.240 --> 00:04:30.067 because the details that strike us 00:04:30.068 --> 00:04:32.119 as important and worth focusing on 00:04:32.120 --> 00:04:34.239 are going to be different for different people, 00:04:34.240 --> 00:04:35.639 I'm not going to say 00:04:35.640 --> 00:04:36.799 that there are hard and fast rules 00:04:36.800 --> 00:04:39.359 about how Bookclub "should work," 00:04:39.360 --> 00:04:41.133 because how it "should work" 00:04:41.134 --> 00:04:43.919 is however it best fits your needs. 00:04:43.920 --> 00:04:45.879 Different people and different projects 00:04:45.880 --> 00:04:47.559 have different backgrounds and mindsets. 00:04:47.560 --> 00:04:49.633 And I don't think it's my place to say 00:04:49.634 --> 00:04:51.879 what strategy is correct as a universal law. 00:04:51.880 --> 00:04:54.719 You know, because Bookclub Tapas is, after all, 00:04:54.720 --> 00:04:57.099 just something I've sort of stumbled into. 00:04:57.100 --> 00:05:00.039 Bookclub is intrinsically ad-hoc. 00:05:00.040 --> 00:05:02.159 My providing a prescription of strategy 00:05:02.160 --> 00:05:04.839 is basically going to begin and end with the idea 00:05:04.840 --> 00:05:07.519 that you write a reverse-literate document 00:05:07.520 --> 00:05:08.799 that illustrates how you've gone 00:05:08.800 --> 00:05:11.919 about writing your program. 00:05:11.920 --> 00:05:14.519 All of that being said, 00:05:14.520 --> 00:05:16.319 I'm going to talk about 00:05:16.320 --> 00:05:18.439 how I've laid out my book club files 00:05:18.440 --> 00:05:20.399 and why I think this is a solid place 00:05:20.400 --> 00:05:24.779 from which to get started. NOTE My starter kit - My stock, off the shelf suggestions 00:05:24.780 --> 00:05:27.839 So my stock off-the-shelf suggestions 00:05:27.840 --> 00:05:29.079 for just getting started 00:05:29.080 --> 00:05:32.960 is to have sections for: our overarching goal, 00:05:32.961 --> 00:05:35.059 our development goals, 00:05:35.060 --> 00:05:40.699 a place for scratch work, a test suite, research, 00:05:40.700 --> 00:05:42.467 and then finally sections for variables, 00:05:42.468 --> 00:05:47.659 functions, and macros. NOTE Now what? 00:05:47.660 --> 00:05:49.999 So we have our starter kit sections. 00:05:50.000 --> 00:05:51.959 How do we go about using them? 00:05:51.960 --> 00:05:53.639 How do we get started? 00:05:53.640 --> 00:05:55.319 Well, we write them, you know, 00:05:55.320 --> 00:05:56.439 out in our org document, 00:05:56.440 --> 00:05:58.979 but then what do we do? NOTE Our overarching goal 00:05:58.980 --> 00:06:01.599 We start by writing what we know. 00:06:01.600 --> 00:06:04.219 We have a spark, a vision. 00:06:04.220 --> 00:06:05.839 We had the beginning of an idea 00:06:05.840 --> 00:06:08.079 of what we wanted our program to do. 00:06:08.080 --> 00:06:09.839 Alternatively, maybe we had 00:06:09.840 --> 00:06:10.879 a client lay our goals out. 00:06:10.880 --> 00:06:13.299 Either way, we have some idea 00:06:13.300 --> 00:06:15.439 of how we want our program to be shaped. 00:06:15.440 --> 00:06:18.339 Let's start by writing that down. 00:06:18.340 --> 00:06:19.439 What are we trying to do? 00:06:19.440 --> 00:06:23.459 What is our goal? NOTE Our development focuses 00:06:23.460 --> 00:06:26.279 After that, we're probably wondering to ourselves, 00:06:26.280 --> 00:06:27.759 "Okay, we have our goal, 00:06:27.760 --> 00:06:30.079 but how do we get there?" 00:06:30.080 --> 00:06:31.359 That's when we start writing 00:06:31.360 --> 00:06:33.359 our development focuses. 00:06:33.360 --> 00:06:35.159 If we have bursts of intuition 00:06:35.160 --> 00:06:36.919 about what functions to write, 00:06:36.920 --> 00:06:39.799 questions that we want to answer through research, 00:06:39.800 --> 00:06:43.339 we start enumerating those every time they hit us. 00:06:43.340 --> 00:06:44.559 Our goal is to write them 00:06:44.560 --> 00:06:46.199 all down in a checklist 00:06:46.200 --> 00:06:48.159 in order to turn them from daydreams 00:06:48.160 --> 00:06:50.479 into courses of action. 00:06:50.480 --> 00:06:52.439 If we aren't having development focuses 00:06:52.440 --> 00:06:54.799 hit us right away, that's okay. 00:06:54.800 --> 00:06:57.279 If we just stare at the goal for long enough, 00:06:57.280 --> 00:06:58.319 I think it's inevitable 00:06:58.320 --> 00:06:59.559 that the muse will speak, 00:06:59.560 --> 00:07:00.879 and we'll get a clear lead 00:07:00.880 --> 00:07:05.119 on a path forward. NOTE The rest of the headings 00:07:05.120 --> 00:07:07.219 So now what? 00:07:07.220 --> 00:07:09.899 Now that we have our development focuses, 00:07:09.900 --> 00:07:11.759 we want to go ahead and create 00:07:11.760 --> 00:07:13.439 the rest of the headings for ourselves 00:07:13.440 --> 00:07:15.539 so we can act upon them. 00:07:15.540 --> 00:07:17.239 We go ahead and write the rest 00:07:17.240 --> 00:07:19.419 of the file's structure ad-hoc 00:07:19.420 --> 00:07:22.339 in a way that will serve our needs for now. 00:07:22.340 --> 00:07:24.079 If it's not fitting us well later on, 00:07:24.080 --> 00:07:25.279 we can just go ahead and change it. 00:07:25.280 --> 00:07:26.239 There's no pressure. 00:07:26.240 --> 00:07:27.719 That's the beauty of having this 00:07:27.720 --> 00:07:30.099 all be in a plain Org document. 00:07:30.100 --> 00:07:32.079 If we're doing something consistently, 00:07:32.080 --> 00:07:35.059 we probably want to have a heading for it. 00:07:35.060 --> 00:07:36.439 We'll go ahead and create homes 00:07:36.440 --> 00:07:38.919 for our variables, our functions, our macros. 00:07:38.920 --> 00:07:41.479 We'll want to create a spot for scratch work 00:07:41.480 --> 00:07:43.319 to sort of like stretch our legs 00:07:43.320 --> 00:07:45.399 and lament in a stream-of-consciousness 00:07:45.400 --> 00:07:47.079 sort of format about how 00:07:47.080 --> 00:07:50.159 a particular piece of design ought to work. 00:07:50.160 --> 00:07:52.359 Basically, any time we wear a different "hat" 00:07:52.360 --> 00:07:55.079 or we take on a different "role" as a developer, 00:07:55.080 --> 00:07:58.839 it's worth considering creating a category for it. 00:07:58.840 --> 00:08:00.719 The best way for us to figure out 00:08:00.720 --> 00:08:01.839 what headings to fill in, 00:08:01.840 --> 00:08:03.359 and how to fill them in, 00:08:03.360 --> 00:08:07.919 is to just go ahead and act upon our development goals. 00:08:07.920 --> 00:08:09.959 If we have a question we want to answer, 00:08:09.960 --> 00:08:12.519 we'll want to create a Research heading 00:08:12.520 --> 00:08:14.759 so we can go ahead and have a spot 00:08:14.760 --> 00:08:17.419 for scratch-work for reasoning things out. 00:08:17.420 --> 00:08:18.919 If we want to write the first draft 00:08:18.920 --> 00:08:20.679 of a function we want, 00:08:20.680 --> 00:08:22.799 We'll want to create a heading for functions 00:08:22.800 --> 00:08:37.979 and then a sub-heading for that function in particular. NOTE Conversationality 00:08:37.980 --> 00:08:40.419 So now that we've filled in our sections, 00:08:40.420 --> 00:08:42.379 what do we do now? 00:08:42.380 --> 00:08:43.679 Our idea for a program 00:08:43.680 --> 00:08:44.879 has been turned into a story, 00:08:44.880 --> 00:08:47.619 but what does that actually get us? 00:08:47.620 --> 00:08:50.839 To me, a lot of what's exciting about Bookclub 00:08:50.840 --> 00:08:52.919 is that novelization goes in 00:08:52.920 --> 00:08:56.059 and a peer programming partner comes out. 00:08:56.060 --> 00:08:58.359 As we loop through reviewing our document, 00:08:58.360 --> 00:08:59.799 as we scan it up and down, 00:08:59.800 --> 00:09:02.000 we're able to engage in conversationality 00:09:02.001 --> 00:09:04.999 with our past self because of how verbose 00:09:05.000 --> 00:09:06.499 we've been in our notes. 00:09:06.500 --> 00:09:08.439 We can ask our past self questions, 00:09:08.440 --> 00:09:09.879 and get back answers. 00:09:09.880 --> 00:09:11.979 We've turned our past self 00:09:11.980 --> 00:09:14.579 into a peer programming partner. 00:09:14.580 --> 00:09:16.359 If we're wondering what to do next, 00:09:16.360 --> 00:09:18.319 we can check our Development Focuses. 00:09:18.320 --> 00:09:20.759 If we're wondering how something works, 00:09:20.760 --> 00:09:22.199 we can read documentation 00:09:22.200 --> 00:09:24.719 embedded in our function drafts, 00:09:24.720 --> 00:09:26.919 or we can read the outcomes of tests 00:09:26.920 --> 00:09:28.659 that we've performed in our research. 00:09:28.660 --> 00:09:33.019 We can ask ourselves questions and get answers. 00:09:33.020 --> 00:09:34.439 Some of what's most exciting 00:09:34.440 --> 00:09:35.919 about peer programming to me 00:09:35.920 --> 00:09:38.079 is having fresh perspective 00:09:38.080 --> 00:09:41.079 and alternate context. 00:09:41.080 --> 00:09:42.679 We have a fresh set of eyes 00:09:42.680 --> 00:09:44.439 on the program that aren't our own, 00:09:44.440 --> 00:09:47.479 and with that set of eyes 00:09:47.480 --> 00:09:50.199 comes someone else to share the burden 00:09:50.200 --> 00:09:52.539 of trying to remember everything. 00:09:52.540 --> 00:09:54.839 With Bookclub, instead of having 00:09:54.840 --> 00:09:57.559 a peer programmer that exists in physical space, 00:09:57.560 --> 00:10:00.719 we have one that's, to get all sci-fi for a moment, 00:10:00.720 --> 00:10:03.039 reaching forward towards us 00:10:03.040 --> 00:10:04.999 from backward in time. 00:10:05.000 --> 00:10:06.799 We're asynchronously working 00:10:06.800 --> 00:10:08.119 with our past selves 00:10:08.120 --> 00:10:10.439 as an equal-role collaborative 00:10:10.440 --> 00:10:12.879 partner in development. 00:10:12.880 --> 00:10:15.039 We have their perspective, 00:10:15.040 --> 00:10:17.799 their fresh memories of the code as it was written, 00:10:17.800 --> 00:10:20.959 and their focus on what was worth worrying about 00:10:20.960 --> 00:10:22.319 at a different point in time. 00:10:22.320 --> 00:10:24.959 We can ask them questions and get answers. 00:10:24.960 --> 00:10:26.319 We can ask them questions like, 00:10:26.320 --> 00:10:28.199 well, "What do I do now?" 00:10:28.200 --> 00:10:30.419 "How does this data structure work?" 00:10:30.420 --> 00:10:33.679 "What types does this third-party library take?" 00:10:33.680 --> 00:10:35.119 By asking these questions, 00:10:35.120 --> 00:10:36.319 I can even stay fresh 00:10:36.320 --> 00:10:37.479 on development progress 00:10:37.480 --> 00:10:40.099 that I last touched months ago. 00:10:40.100 --> 00:10:42.799 It's really easy to duplicate work, 00:10:42.800 --> 00:10:44.719 forget how things work, 00:10:44.720 --> 00:10:46.159 lose track of priorities. 00:10:46.160 --> 00:10:48.279 Bookclub helps keep us focused, 00:10:48.280 --> 00:10:49.839 it keeps us accountable, 00:10:49.840 --> 00:10:55.479 it even keeps us company. NOTE Ad-hoc means lesricsf tion 00:10:55.480 --> 00:10:58.359 One of the most immediately useful things about Bookclub, 00:10:58.360 --> 00:11:00.867 in my opinion, is that we immediately have 00:11:00.868 --> 00:11:02.359 a list of actionable items. 00:11:02.360 --> 00:11:04.319 Every time I have a little pain point, 00:11:04.320 --> 00:11:06.639 I go ahead and write it down, 00:11:06.640 --> 00:11:09.079 and I write down all of the things 00:11:09.080 --> 00:11:11.579 that would be nice to have done someday. 00:11:11.580 --> 00:11:13.199 So you might be wondering, 00:11:13.200 --> 00:11:14.679 and it's fair to wonder this, 00:11:14.680 --> 00:11:17.479 isn't this effectively just the GitHub issue model? 00:11:17.480 --> 00:11:19.279 We're listing out bug requests, 00:11:19.280 --> 00:11:21.239 issue requests, feature requests. 00:11:21.240 --> 00:11:22.519 It's not exactly a new idea, 00:11:22.520 --> 00:11:24.559 and it's pretty intuitive. 00:11:24.560 --> 00:11:26.719 I think the important consideration here 00:11:26.720 --> 00:11:29.999 is that having really formalized apparatus 00:11:30.000 --> 00:11:31.639 for entering in our thoughts 00:11:31.640 --> 00:11:34.419 can be an unnecessary source of friction. 00:11:34.420 --> 00:11:36.359 Bug listings don't tend to be 00:11:36.360 --> 00:11:37.839 a great fit for daydreaming 00:11:37.840 --> 00:11:40.939 or verbose considerations of philosophy. 00:11:40.940 --> 00:11:42.919 Bug listings tend to be reserved 00:11:42.920 --> 00:11:45.119 for catastrophes. 00:11:45.120 --> 00:11:47.279 I feel like a lot of the tooling 00:11:47.280 --> 00:11:48.199 that we currently use 00:11:48.200 --> 00:11:51.279 really struggles with creating ergonomics 00:11:51.280 --> 00:11:54.879 that make taking frictionless notes difficult. 00:11:54.880 --> 00:11:57.159 We have systems where all the disparate 00:11:57.160 --> 00:11:59.079 parts of what we're working on 00:11:59.080 --> 00:12:02.499 feel really far away from each other. 00:12:02.500 --> 00:12:04.039 We're pushed away from engaging 00:12:04.040 --> 00:12:05.959 in conversations with ourselves 00:12:05.960 --> 00:12:07.919 as a result of how disparate 00:12:07.920 --> 00:12:09.159 all of our tooling feels, 00:12:09.160 --> 00:12:10.959 how the process of working with it 00:12:10.960 --> 00:12:12.899 is incongruent. 00:12:12.900 --> 00:12:15.599 My hope is that we can instead 00:12:15.600 --> 00:12:16.999 engage with a process 00:12:17.000 --> 00:12:18.359 that makes it really trivial 00:12:18.360 --> 00:12:20.199 to write impulsive journaling 00:12:20.200 --> 00:12:21.979 about what we're doing. 00:12:21.980 --> 00:12:23.839 So much of design is ultimately 00:12:23.840 --> 00:12:25.559 just daydreaming. 00:12:25.560 --> 00:12:27.279 Good ideas tend to strike us hard, 00:12:27.280 --> 00:12:29.779 in a momentary flash of inspiration, 00:12:29.780 --> 00:12:32.599 and then they fade just as quickly. 00:12:32.600 --> 00:12:35.239 Anyone who's had an idea all at once 00:12:35.240 --> 00:12:36.579 in the middle of the night 00:12:36.580 --> 00:12:38.159 knows that they're going to have to choose 00:12:38.160 --> 00:12:40.619 between either committing to writing it down 00:12:40.620 --> 00:12:41.959 or accept that by morning 00:12:41.960 --> 00:12:44.259 they'll have lost it. 00:12:44.260 --> 00:12:45.359 If we're not writing 00:12:45.360 --> 00:12:46.759 what strikes us as important 00:12:46.760 --> 00:12:48.639 at the same moment that it's happening, 00:12:48.640 --> 00:12:50.379 we're going to lose it. 00:12:50.380 --> 00:12:52.639 It's not realistic to expect ourselves 00:12:52.640 --> 00:12:54.519 to hold onto our ideas forever 00:12:54.520 --> 00:12:56.359 with the same precision 00:12:56.360 --> 00:13:01.919 as when we were first inspired. NOTE Gratis documentation 00:13:01.920 --> 00:13:11.319 Okay. I'm gonna call you out real quick. 00:13:11.320 --> 00:13:13.759 If I ask all of you "Who wants to read 00:13:13.760 --> 00:13:15.959 really excellent documentation?" 00:13:15.960 --> 00:13:17.079 I imagine that everyone here 00:13:17.080 --> 00:13:18.379 is raising their hand. 00:13:18.380 --> 00:13:20.759 We want code to make sense 00:13:20.760 --> 00:13:21.959 and we want to know what 00:13:21.960 --> 00:13:24.239 the original developer had in mind. 00:13:24.240 --> 00:13:26.399 Even the original developer themselves 00:13:26.400 --> 00:13:28.579 would want this just for their own sake. 00:13:28.580 --> 00:13:30.999 I know that for me, I can even feel 00:13:31.000 --> 00:13:32.319 things becoming less fresh 00:13:32.320 --> 00:13:33.759 just after a couple months away 00:13:33.760 --> 00:13:35.539 from my codebase. 00:13:35.540 --> 00:13:38.619 And that was me from a couple months ago. 00:13:38.620 --> 00:13:42.359 They're not around anymore. 00:13:42.360 --> 00:13:45.359 Now, here's the rough part. 00:13:45.360 --> 00:13:48.579 Here's what I'm really gonna call you all out. 00:13:48.580 --> 00:13:51.599 "Who wants to write really excellent documentation?" 00:13:51.600 --> 00:13:53.719 Now, I don't know what's happening on your end, 00:13:53.720 --> 00:13:55.559 but I'm imagining crickets, 00:13:55.560 --> 00:13:57.039 silence, tumbleweeds 00:13:57.040 --> 00:13:59.139 blowing through to the horizon. 00:13:59.140 --> 00:14:00.999 It's a tough ask. 00:14:01.000 --> 00:14:03.559 It's not generally all that rewarding. 00:14:03.560 --> 00:14:06.299 If you're writing docs from scratch, 00:14:06.300 --> 00:14:07.999 a lot of it involves relearning 00:14:08.000 --> 00:14:10.679 the intentions behind crusty old code. 00:14:10.680 --> 00:14:13.359 For me, it hurts to not spend that same time 00:14:13.360 --> 00:14:16.119 implementing bug fixes and new features. 00:14:16.120 --> 00:14:17.599 It just doesn't feel like 00:14:17.600 --> 00:14:19.619 a great use of my time. 00:14:19.620 --> 00:14:22.279 Even if it's strictly for my own codebase 00:14:22.280 --> 00:14:25.039 for my own use, it's hard to sit down and do it 00:14:25.040 --> 00:14:28.779 even when I know how much I would benefit from it. 00:14:28.780 --> 00:14:31.359 My thinking is that when you write rough, 00:14:31.360 --> 00:14:34.039 piecewise daydreaming as you go, 00:14:34.040 --> 00:14:36.039 it's so much easier to not only 00:14:36.040 --> 00:14:38.759 begin writing documentation early in your process, 00:14:38.760 --> 00:14:42.839 but also to stay consistent about not slouching into 00:14:42.840 --> 00:14:48.439 an accumulation of a backlog. NOTE Keeping the thread of your intention 00:14:48.440 --> 00:14:51.319 So not only does writing documentation early 00:14:51.320 --> 00:14:54.599 make us more likely to keep that habit going, 00:14:54.600 --> 00:14:56.399 but it also makes the documentation 00:14:56.400 --> 00:14:59.499 we do write way more robust. 00:14:59.500 --> 00:15:01.239 When fiction meets reality 00:15:01.240 --> 00:15:04.119 and we start writing out code 00:15:04.120 --> 00:15:06.119 that is constrained by the real world 00:15:06.120 --> 00:15:08.859 and not just our imagination, 00:15:08.860 --> 00:15:11.759 we learn that things we assumed about our design 00:15:11.760 --> 00:15:14.839 aren't going to work out in practice. 00:15:14.840 --> 00:15:16.879 Because of this, we can enter 00:15:16.880 --> 00:15:18.559 into a sort of situation 00:15:18.560 --> 00:15:21.139 akin to boiling a frog in a pot of water. 00:15:21.140 --> 00:15:23.079 Frogs don't notice that they're being boiled 00:15:23.080 --> 00:15:26.919 if the water is only heated gradually enough. 00:15:26.920 --> 00:15:31.099 We decide to adjust our design only a little bit 00:15:31.100 --> 00:15:33.919 without changing the documentation right away. 00:15:33.920 --> 00:15:34.999 Doing that once is fine, 00:15:35.000 --> 00:15:36.559 but I don't believe for a second 00:15:36.560 --> 00:15:38.559 that we're only going to do it once. 00:15:38.560 --> 00:15:39.919 We can find ourselves surprised 00:15:39.920 --> 00:15:41.659 that as time goes on, 00:15:41.660 --> 00:15:43.919 our code looks nothing like our spec, 00:15:43.920 --> 00:15:45.879 and we lose the thread of what our code 00:15:45.880 --> 00:15:48.699 was supposed to do in the first place. 00:15:48.700 --> 00:15:52.979 When we stake our intentions clearly and early, 00:15:52.980 --> 00:15:54.979 you ground yourself in them. 00:15:54.980 --> 00:15:58.439 You reduce the risk of straying from them. 00:15:58.440 --> 00:15:59.879 You have clear reference 00:15:59.880 --> 00:16:01.919 for what you want your code to do, 00:16:01.920 --> 00:16:03.319 and you reduce the risk 00:16:03.320 --> 00:16:05.919 of having its purpose shift over time. 00:16:05.920 --> 00:16:07.399 When we take turns alternating 00:16:07.400 --> 00:16:09.239 between writing code and documentation 00:16:09.240 --> 00:16:11.199 rather than acting, you know, 00:16:11.200 --> 00:16:14.319 as having it all as one step, 00:16:14.320 --> 00:16:16.479 we risk taking turns just moving 00:16:16.480 --> 00:16:21.499 our goalpost back and forth. NOTE Bookclub is becoming too much 00:16:21.500 --> 00:16:24.239 So we've seen how our Bookclub files get us 00:16:24.240 --> 00:16:25.839 all sorts of amazing features 00:16:25.840 --> 00:16:27.619 and practical benefits. 00:16:27.620 --> 00:16:29.599 But we might be starting to notice a pattern 00:16:29.600 --> 00:16:31.839 as we continue to engage in conversation 00:16:31.840 --> 00:16:33.839 and work with our document 00:16:33.840 --> 00:16:35.919 and watch it grow in size. 00:16:35.920 --> 00:16:38.819 We originally created our Bookclub file 00:16:38.820 --> 00:16:40.700 with the hope to reduce 00:16:40.701 --> 00:16:42.119 what we would need to keep track of 00:16:42.120 --> 00:16:44.879 and to reduce our level of overwhelm. 00:16:44.880 --> 00:16:48.919 We might find that as our Bookclub file grows, 00:16:48.920 --> 00:16:51.159 we're encountering more detail 00:16:51.160 --> 00:16:53.319 than we can practically parse, manage, 00:16:53.320 --> 00:16:55.759 and decipher intention from. 00:16:55.760 --> 00:16:57.719 It can be easy to enter into a situation 00:16:57.720 --> 00:16:59.839 where we're drowning in the breadth of our notes, 00:16:59.840 --> 00:17:03.399 and in doing so we've recreated the same problem 00:17:03.400 --> 00:17:05.419 we originally set out to solve. 00:17:05.420 --> 00:17:08.759 Writing out every single detail helps us a lot 00:17:08.760 --> 00:17:11.079 to make sense of things at first, 00:17:11.080 --> 00:17:13.519 but then after a while, we can encounter 00:17:13.520 --> 00:17:15.879 a signal-to-noise problem 00:17:15.880 --> 00:17:19.399 when we try to make meaning from too many details. 00:17:19.400 --> 00:17:25.239 This is where tapas come in. NOTE Introducing Tapas 00:17:25.240 --> 00:17:29.199 So tapas in Spanish cuisine are appetizers. 00:17:29.200 --> 00:17:31.559 What's notable about tapas 00:17:31.560 --> 00:17:33.839 is that you can bring a bunch of them together 00:17:33.840 --> 00:17:35.299 to make a full meal. 00:17:35.300 --> 00:17:38.379 In the context of Bookclub Tapas, 00:17:38.380 --> 00:17:40.339 they serve a similar role. 00:17:40.340 --> 00:17:42.719 The idea is that we write flavorful libraries 00:17:42.720 --> 00:17:45.419 that together form a full program. 00:17:45.420 --> 00:17:47.059 We have a full program, 00:17:47.060 --> 00:17:49.839 but it's made from discrete modules. 00:17:49.840 --> 00:17:52.719 The idea behind tapas is that instead of creating 00:17:52.720 --> 00:17:55.859 one perfect, "solves everything" codebase, 00:17:55.860 --> 00:17:57.319 we want to create a whole bunch 00:17:57.320 --> 00:17:59.079 of separate libraries 00:17:59.080 --> 00:18:02.919 that themselves nail a specific subdomain. 00:18:02.920 --> 00:18:04.119 And once these libraries 00:18:04.120 --> 00:18:05.179 are all brought together, 00:18:05.180 --> 00:18:08.019 they form the whole that we're seeking. 00:18:08.020 --> 00:18:10.079 Once our Bookclub file becomes big enough 00:18:10.080 --> 00:18:12.239 such that we feel like our scope can be split 00:18:12.240 --> 00:18:14.239 into multiple libraries, 00:18:14.240 --> 00:18:16.079 that's when we want to take the opportunity 00:18:16.080 --> 00:18:22.839 to split our program up into parts, into Tapas. NOTE What are Tapas, what are Tapas not? 00:18:22.840 --> 00:18:25.159 So, maybe one of the best ways 00:18:25.160 --> 00:18:27.039 to understand what makes a good Tapa 00:18:27.040 --> 00:18:30.599 is to first examine what does not make a good Tapa. 00:18:30.600 --> 00:18:32.159 The single most important thing 00:18:32.160 --> 00:18:33.559 to understand about Tapas 00:18:33.560 --> 00:18:37.139 is that they themselves are substantial. 00:18:37.140 --> 00:18:38.879 There's a lot of back and forth 00:18:38.880 --> 00:18:40.679 on the idea of micro-libraries, 00:18:40.680 --> 00:18:42.879 their merits, their dangers, 00:18:42.880 --> 00:18:45.419 and when and where they kind of work best. 00:18:45.420 --> 00:18:46.359 I think the distinction 00:18:46.360 --> 00:18:47.599 that I would like to draw 00:18:47.600 --> 00:18:50.719 is that I think that tapas belong in the larger end 00:18:50.720 --> 00:18:53.759 of scale and complexity for microlibraries 00:18:53.760 --> 00:18:56.159 rather than the smaller end. 00:18:56.160 --> 00:18:58.079 I think particularly small helpers 00:18:58.080 --> 00:19:00.299 like NPM's is-odd 00:19:00.300 --> 00:19:01.919 are a good example of something 00:19:01.920 --> 00:19:05.479 I think does not constitute a good Tapa. 00:19:05.480 --> 00:19:08.799 Meanwhile, I think Python's Requests library 00:19:08.800 --> 00:19:11.799 is a really good example of a Tapa. 00:19:11.800 --> 00:19:15.319 I believe Requests only does HTTP connections, 00:19:15.320 --> 00:19:18.319 but I feel like that's not so simple and straightforward 00:19:18.320 --> 00:19:20.239 that you can just go ahead and implement it 00:19:20.240 --> 00:19:23.199 on your own real quick. 00:19:23.200 --> 00:19:24.639 A real danger of creating 00:19:24.640 --> 00:19:27.219 helper libraries that are too small 00:19:27.220 --> 00:19:31.159 is that we don't remove abstraction 00:19:31.160 --> 00:19:33.319 nearly as much as we postpone it. 00:19:33.320 --> 00:19:35.819 If our libraries are small, 00:19:35.820 --> 00:19:38.899 but the glue code that binds them is large, 00:19:38.900 --> 00:19:40.079 we haven't done anything 00:19:40.080 --> 00:19:41.519 to reduce complexity 00:19:41.520 --> 00:19:44.179 or employ abstraction in a meaningful way. 00:19:44.180 --> 00:19:47.479 If all of the complexity exists in our glue code, 00:19:47.480 --> 00:19:49.799 we've simply replaced our functions 00:19:49.800 --> 00:19:52.519 with libraries of the same size and purpose. 00:19:52.520 --> 00:19:54.559 Our codebase is still monolithic 00:19:54.560 --> 00:19:58.039 instead of having meaningfully divided scope. 00:19:58.040 --> 00:19:59.559 I think that a good Tapa 00:19:59.560 --> 00:20:01.479 ought to feel like augmentations 00:20:01.480 --> 00:20:03.979 or extensions to the standard library. 00:20:03.980 --> 00:20:05.199 You know, maybe something kind of 00:20:05.200 --> 00:20:08.379 akin to Scheme's SRFI system. 00:20:08.380 --> 00:20:10.599 I think that the goal of good Tapas 00:20:10.600 --> 00:20:13.919 is not to solve a particular problem, 00:20:13.920 --> 00:20:18.519 but instead to solve a particular class of problem. 00:20:18.520 --> 00:20:20.159 The goal of a well-written Tapa 00:20:20.160 --> 00:20:22.999 is to solve needing to do hard work in general 00:20:23.000 --> 00:20:25.559 rather than solving what can only really be 00:20:25.560 --> 00:20:26.679 an individual need 00:20:26.680 --> 00:20:28.439 of an individual program. 00:20:28.440 --> 00:20:30.359 I feel like Tapas are most helpful 00:20:30.360 --> 00:20:32.119 when we instead seek to solve 00:20:32.120 --> 00:20:35.319 a larger overarching problem 00:20:35.320 --> 00:20:39.439 that intersects with the problem space of our code base. 00:20:39.440 --> 00:20:42.239 When we have a handful of Tapas 00:20:42.240 --> 00:20:46.179 that are roughly the same size and scale, 00:20:46.180 --> 00:20:48.119 the glue code that marries them 00:20:48.120 --> 00:20:52.179 is also roughly the same size and scale. 00:20:52.180 --> 00:20:55.639 As a heuristic, I try to aim for any function 00:20:55.640 --> 00:20:57.839 being approximately 3 calls in length, 00:20:57.840 --> 00:21:00.839 and then any Tapa being between 6 00:21:00.840 --> 00:21:06.399 and 12 functions in length. 00:21:06.400 --> 00:21:08.039 The number of Tapas themselves 00:21:08.040 --> 00:21:09.639 can be as many or as few as you need, 00:21:09.640 --> 00:21:12.879 but then your Tapas can split into 00:21:12.880 --> 00:21:16.459 their own separate Tapas as needed. 00:21:16.460 --> 00:21:18.799 My hope is that the collection of our Tapas, 00:21:18.800 --> 00:21:20.599 especially as we create 00:21:20.600 --> 00:21:22.319 dependency chains among them, 00:21:22.320 --> 00:21:25.039 is that each next Tapa is a trivial case 00:21:25.040 --> 00:21:27.099 of the one prerequisite to it. 00:21:27.100 --> 00:21:28.879 Every Tapa is a meaningful, 00:21:28.880 --> 00:21:31.059 human-readable abstraction 00:21:31.060 --> 00:21:33.439 that enables us to feel confident about our tooling 00:21:33.440 --> 00:21:35.639 without drowning in detail. 00:21:35.640 --> 00:21:38.499 The whole stack can be understood by humans, 00:21:38.500 --> 00:21:40.159 but we only have to focus on 00:21:40.160 --> 00:21:41.879 any one piece of it at a time, 00:21:41.880 --> 00:21:47.419 rather than focusing on the entire stack all at once. 00:21:47.420 --> 00:21:48.879 We can practically achieve 00:21:48.880 --> 00:21:51.259 a huge final product, 00:21:51.260 --> 00:21:52.759 but each individual step 00:21:52.760 --> 00:21:54.279 in working towards that goal 00:21:54.280 --> 00:21:56.039 is still at a human scale. 00:21:56.040 --> 00:22:02.179 One thing I want to make sure to point out, 00:22:02.180 --> 00:22:03.279 one thing I want to make sure 00:22:03.280 --> 00:22:05.179 to point out explicitly, real quick, 00:22:05.180 --> 00:22:06.279 is that having access 00:22:06.280 --> 00:22:07.839 to a hygienic macro system, 00:22:07.840 --> 00:22:10.259 like the ones that we have in Lisps, 00:22:10.260 --> 00:22:11.999 makes for an amazing experience 00:22:12.000 --> 00:22:13.319 for creating Tapas. 00:22:13.320 --> 00:22:15.279 The types of abstractions that we can do 00:22:15.280 --> 00:22:17.039 by modifying syntax at compile time 00:22:17.040 --> 00:22:18.439 makes for incredibly intuitive 00:22:18.440 --> 00:22:25.179 and ergonomic tooling. NOTE Tapas are maybe best illustrated by example 00:22:25.180 --> 00:22:27.279 So we've talked quite a bit about 00:22:27.280 --> 00:22:28.919 what I think makes a Tapa good, 00:22:28.920 --> 00:22:30.759 but I think maybe the best way 00:22:30.760 --> 00:22:32.679 to understand the concept 00:22:32.680 --> 00:22:35.599 is to have a look at the whole workflow in practice. 00:22:35.600 --> 00:22:37.479 I've been working on this, currently 00:22:37.480 --> 00:22:40.219 unnamed, Elisp program recently. 00:22:40.220 --> 00:22:42.959 It's a validator for the filetags lines 00:22:42.960 --> 00:22:45.819 of my Org Mode files. 00:22:45.820 --> 00:22:49.299 So I have Org Mode files 00:22:49.300 --> 00:22:50.999 under my Documents directory, 00:22:51.000 --> 00:22:53.633 organized in this hierarchical way, 00:22:53.634 --> 00:22:57.039 and the nested directories have meaningful names. 00:22:57.040 --> 00:23:00.300 I want the headers of my Org files to be tagged 00:23:00.301 --> 00:23:01.800 in accordance with the sequence 00:23:01.801 --> 00:23:04.199 of the names of the directories. 00:23:04.200 --> 00:23:06.167 I do this by having the file-tags line 00:23:06.168 --> 00:23:06.999 at the top of the file 00:23:07.000 --> 00:23:09.519 just list the path segments in order. 00:23:09.520 --> 00:23:12.199 If I have an Org file in the directory 00:23:12.200 --> 00:23:16.559 "~/Documents/foo/bar", 00:23:16.560 --> 00:23:20.799 the file-tags line has the tags "foo" and "bar". 00:23:20.800 --> 00:23:23.139 This is totally fine to do by hand, 00:23:23.140 --> 00:23:24.919 but I want a program 00:23:24.920 --> 00:23:27.119 that recursively searches through my directories 00:23:27.120 --> 00:23:29.799 to validate that the tags are correct 00:23:29.800 --> 00:23:33.459 because it's easy to drop something. 00:23:33.460 --> 00:23:36.039 This scale of problem is actually kind of perfect 00:23:36.040 --> 00:23:39.959 for demonstrating how Bookclub Tapas work in action. 00:23:39.960 --> 00:23:40.759 We have a problem 00:23:40.760 --> 00:23:42.639 that's mostly rather simple, 00:23:42.640 --> 00:23:44.359 but it has a lot of moving pieces. 00:23:44.360 --> 00:23:47.799 We want to iterate over directories recursively, 00:23:47.800 --> 00:23:49.559 we want to do string manipulation, 00:23:49.560 --> 00:23:50.879 we want to parse buffers, 00:23:50.880 --> 00:23:52.899 and we want to edit buffers. 00:23:52.900 --> 00:23:55.359 All of these tasks are simple enough on their own, 00:23:55.360 --> 00:23:56.679 but it's deceptively easy 00:23:56.680 --> 00:23:58.399 to start tripping over ourselves 00:23:58.400 --> 00:23:59.959 when we feel like it's necessary 00:23:59.960 --> 00:24:03.019 to do all of these different things in one step. 00:24:03.020 --> 00:24:05.399 So there are a ton of great string 00:24:05.400 --> 00:24:06.959 manipulation tools for Emacs, 00:24:06.960 --> 00:24:08.079 so that's checked off, 00:24:08.080 --> 00:24:10.939 that's done, taken care of. 00:24:10.940 --> 00:24:12.119 I'm still kind of daydreaming 00:24:12.120 --> 00:24:14.399 about writing a wrapper around 00:24:14.400 --> 00:24:16.039 some of the Emacs standard libraries 00:24:16.040 --> 00:24:16.999 for directory traversal, 00:24:17.000 --> 00:24:20.179 just to make it a little bit nicer to work with. 00:24:20.180 --> 00:24:20.799 But the big thing 00:24:20.800 --> 00:24:22.519 that really struck me as odd 00:24:22.520 --> 00:24:25.479 is that there doesn't seem to be a great tooling 00:24:25.480 --> 00:24:28.239 for destructuring Emacs buffers 00:24:28.240 --> 00:24:29.399 beyond just chaining together 00:24:29.400 --> 00:24:31.379 a bunch of editor commands. 00:24:31.380 --> 00:24:33.959 Emacs is so buffer-oriented, 00:24:33.960 --> 00:24:36.439 I feel like it really deserves a good library 00:24:36.440 --> 00:24:38.719 for programmatic buffer destructuring. 00:24:38.720 --> 00:24:40.559 I looked around for a bit, 00:24:40.560 --> 00:24:42.799 but I couldn't really find anything. 00:24:42.800 --> 00:24:44.759 So at the end of the day, 00:24:44.760 --> 00:24:47.279 I could definitely just grit my teeth 00:24:47.280 --> 00:24:50.919 and put my head down and just use tools 00:24:50.920 --> 00:24:54.359 that feel cumbersome to work with if I wanted to. 00:24:54.360 --> 00:24:55.199 I could write something 00:24:55.200 --> 00:24:56.039 that's "good enough" 00:24:56.040 --> 00:24:57.759 just for the purpose of my package 00:24:57.760 --> 00:25:00.279 and then hide it deep inside the code base. 00:25:00.280 --> 00:25:03.819 I could absolutely do that. 00:25:03.820 --> 00:25:07.919 But I can't help but think about how 00:25:07.920 --> 00:25:11.099 after I properly write the tooling I'm missing, 00:25:11.100 --> 00:25:13.159 I'm really going to be thanking myself 00:25:13.160 --> 00:25:15.879 in terms of reduced implementational complexity, 00:25:15.880 --> 00:25:19.039 reduced bug hunting, real reusability, 00:25:19.040 --> 00:25:22.199 and ultimately really just a deep sense of pride 00:25:22.200 --> 00:25:23.719 in knowing that I took the time 00:25:23.720 --> 00:25:27.319 to do something in a way that feels "right." 00:25:27.320 --> 00:25:28.799 This right here is the perfect time 00:25:28.800 --> 00:25:30.239 to split off Tapas. 00:25:30.240 --> 00:25:32.119 Any time that we find ourselves 00:25:32.120 --> 00:25:34.319 reaching for a fictional dependency, 00:25:34.320 --> 00:25:35.439 wishing that someone had written 00:25:35.440 --> 00:25:37.679 a library like this... 00:25:37.680 --> 00:25:39.119 We can take that opportunity 00:25:39.120 --> 00:25:42.019 to remember that we are "someone." 00:25:42.020 --> 00:25:44.319 We can write that library ourselves, 00:25:44.320 --> 00:25:46.679 and we deserve to write that library 00:25:46.680 --> 00:25:52.339 because we deserve to get to use it. NOTE Introducing Squint 00:25:52.340 --> 00:25:55.279 So I'm going to briefly show 00:25:55.280 --> 00:25:56.899 a Bookclub buffer 00:25:56.900 --> 00:25:59.259 for a program called Squint. 00:25:59.260 --> 00:26:00.879 It's the buffer destructure 00:26:00.880 --> 00:26:03.199 that I've been talking about, and it's real. 00:26:03.200 --> 00:26:04.519 It's a wrapper around 00:26:04.520 --> 00:26:05.999 Emacs's narrowing functionality 00:26:06.000 --> 00:26:08.739 and regular expression search. 00:26:08.740 --> 00:26:11.799 It's not totally done, 00:26:11.800 --> 00:26:15.279 and will likely see some breaking changes, 00:26:15.280 --> 00:26:16.759 but I really like where it is. 00:26:16.760 --> 00:26:18.679 I'll be posting it in its current state 00:26:18.680 --> 00:26:22.399 on some of the big source repository sites 00:26:22.400 --> 00:26:23.279 relatively soon. 00:26:23.280 --> 00:26:24.719 I think it has a good feature, 00:26:24.720 --> 00:26:26.519 which is really quite exciting. 00:26:26.520 --> 00:26:28.999 And it'll likely probably get split off 00:26:29.000 --> 00:26:29.799 into its own Tapas. 00:26:29.800 --> 00:26:32.239 We'll see. No matter what, 00:26:32.240 --> 00:26:34.319 I do recommend being on the lookout for it, 00:26:34.320 --> 00:26:35.599 because I think it'll be 00:26:35.600 --> 00:26:37.479 a really excellent demonstration 00:26:37.480 --> 00:26:39.679 of some of the solid ideas 00:26:39.680 --> 00:26:43.899 behind how to get rolling with Bookclub Tapas. 00:26:43.900 --> 00:26:46.639 So I have my background section 00:26:46.640 --> 00:26:49.039 where I'm basically just sort of laying out, 00:26:49.040 --> 00:26:53.239 you know, what the objective is for the program. 00:26:53.240 --> 00:26:55.119 I have my vision where I'm doing 00:26:55.120 --> 00:26:58.019 some daydreaming about, you know, 00:26:58.020 --> 00:26:59.639 how this all ought to work. 00:26:59.640 --> 00:27:00.919 I date stamped this. 00:27:00.920 --> 00:27:02.919 As you can see, it's from a while ago, 00:27:02.920 --> 00:27:05.599 but I still have the full context of, you know, 00:27:05.600 --> 00:27:08.159 all the things that I've done working on this. 00:27:08.160 --> 00:27:12.319 I listed out a bunch of ideas 00:27:12.320 --> 00:27:15.479 for different forms for functions macros. 00:27:15.480 --> 00:27:21.839 I did different pieces of research. 00:27:21.840 --> 00:27:23.199 Yeah, I was trying to figure out 00:27:23.200 --> 00:27:24.679 for the width restriction macro, 00:27:24.680 --> 00:27:26.599 what types does it take? 00:27:26.600 --> 00:27:28.479 And I did a whole bunch of tests 00:27:28.480 --> 00:27:31.279 to try and ultimately figure it out. 00:27:31.280 --> 00:27:35.719 Because it claims in the documentation, 00:27:35.720 --> 00:27:37.399 I believe, that it will just take 00:27:37.400 --> 00:27:39.439 any type for labels. 00:27:39.440 --> 00:27:43.959 But in my testing, that's not 00:27:43.960 --> 00:27:44.879 ultimately what I found. 00:27:44.880 --> 00:27:46.519 The results of my tests 00:27:46.520 --> 00:27:50.119 is that symbols, numbers, they work. 00:27:50.120 --> 00:27:51.319 Strings do not. 00:27:51.320 --> 00:27:52.919 I'm not sure why that is. 00:27:52.920 --> 00:27:54.439 But for my purposes, 00:27:54.440 --> 00:27:58.159 this is what I need to know. 00:27:58.160 --> 00:28:00.359 I have my development focuses here. 00:28:00.360 --> 00:28:03.879 So I have my assorted goals 00:28:03.880 --> 00:28:05.119 for different directions 00:28:05.120 --> 00:28:08.059 I want to take the program. 00:28:08.060 --> 00:28:13.339 And then lastly, I have my functions, my macros. 00:28:13.340 --> 00:28:14.439 And this right here 00:28:14.440 --> 00:28:18.079 is the titular macro. 00:28:18.080 --> 00:28:20.499 This is ultimately the big meat 00:28:20.500 --> 00:28:24.859 of the program. 00:28:24.860 --> 00:28:28.219 And it's all contained happily organized 00:28:28.220 --> 00:28:30.359 inside my Bookclub file. 00:28:30.360 --> 00:28:31.199 I'm quite happy with it. 00:28:31.200 --> 00:28:36.099 I think it looks really nice. NOTE What else does Bookclub Tapas do? 00:28:36.100 --> 00:28:40.759 So what else does Bookclub tapas do? 00:28:40.760 --> 00:28:44.519 I don't know. It probably does a lot of stuff. 00:28:44.520 --> 00:28:46.439 It does all sorts of stuff 00:28:46.440 --> 00:28:47.439 that I don't know about yet, 00:28:47.440 --> 00:28:48.879 but this is where you come in. 00:28:48.880 --> 00:28:51.439 I'm really excited to see what people do 00:28:51.440 --> 00:28:52.879 when they take these ideas 00:28:52.880 --> 00:28:54.019 and run with them. 00:28:54.020 --> 00:28:56.819 And if you have something really cool you're doing with it, 00:28:56.820 --> 00:28:59.239 please email me and come talk to me about it. 00:28:59.240 --> 00:29:00.599 I'd love to hear about it. 00:29:00.600 --> 00:29:08.159 Again, my email is hello@ElephantErgonomics.com. NOTE Let's work together 00:29:08.160 --> 00:29:10.839 So last, before we wrap up, 00:29:10.840 --> 00:29:12.599 I want to go ahead and give 00:29:12.600 --> 00:29:14.199 a quick plug for my services. 00:29:14.200 --> 00:29:17.019 I am an independent software engineer 00:29:17.020 --> 00:29:20.079 that has an emphasis in backend design 00:29:20.080 --> 00:29:21.599 and general automation. 00:29:21.600 --> 00:29:23.919 In particular, I have an emphasis 00:29:23.920 --> 00:29:26.839 in that really cool new generative AI thing 00:29:26.840 --> 00:29:28.559 that everyone's been talking about recently. 00:29:28.560 --> 00:29:30.679 If you have a headache, 00:29:30.680 --> 00:29:33.239 you have some sort of pain point 00:29:33.240 --> 00:29:34.799 for your small or large business, 00:29:34.800 --> 00:29:36.767 you wish you could just wiggle your nose 00:29:36.768 --> 00:29:38.999 and have disappear, come talk to me. 00:29:39.000 --> 00:29:41.599 I'll make it disappear. I love doing that. 00:29:41.600 --> 00:29:46.979 Reach out to me at hello@ElephantErgonomics.com. 00:29:46.980 --> 00:29:48.319 If you think that Bookclub Tapas 00:29:48.320 --> 00:29:51.039 would be a great fit for your team and your project, 00:29:51.040 --> 00:29:53.039 I'd love to hop on and help you 00:29:53.040 --> 00:29:55.119 get the ball rolling quickly. 00:29:55.120 --> 00:29:59.819 Go ahead and email me at hello@ElephantErgonomics.com. 00:29:59.820 --> 00:30:01.639 Lastly, if you're a member 00:30:01.640 --> 00:30:03.799 of the larger Lisp community 00:30:03.800 --> 00:30:06.859 and you want to fund independent software development 00:30:06.860 --> 00:30:08.319 for things that really excite you, 00:30:08.320 --> 00:30:09.639 for passion projects 00:30:09.640 --> 00:30:11.439 that make our ecosystem richer, 00:30:11.440 --> 00:30:17.079 I'd love to look into accepting independent funding 00:30:17.080 --> 00:30:20.419 so I can commit more hours 00:30:20.420 --> 00:30:22.679 toward making that happen. 00:30:22.680 --> 00:30:24.599 Some of the projects that I want to work on 00:30:24.600 --> 00:30:28.679 are a Python Foreign Function Interface for Guile Scheme, 00:30:28.680 --> 00:30:31.959 a framework for rapidly creating simulation games 00:30:31.960 --> 00:30:33.878 that feels just as simple 00:30:33.879 --> 00:30:36.239 as writing Emacs configurations, 00:30:36.240 --> 00:30:37.719 I want to work on getting 00:30:37.720 --> 00:30:41.459 a full graphical web browser inside of Emacs, 00:30:41.460 --> 00:30:43.359 and I want to finish programs like Squint. 00:30:43.360 --> 00:30:44.879 These are just some of the projects 00:30:44.880 --> 00:30:46.019 I want to work on, 00:30:46.020 --> 00:30:48.239 but I need funding to do so. 00:30:48.240 --> 00:30:49.559 If you want to see these things happen, 00:30:49.560 --> 00:30:53.799 send me an email at hello@ElephantErgonomics.com 00:30:53.800 --> 00:30:55.559 with both your intention 00:30:55.560 --> 00:30:57.359 to pledge a monthly contribution 00:30:57.360 --> 00:30:59.399 as well as clarification, 00:30:59.400 --> 00:31:02.079 a sort of vote on which project 00:31:02.080 --> 00:31:03.519 you would like to see me prioritize. 00:31:03.520 --> 00:31:06.679 I would love to have folks reach out 00:31:06.680 --> 00:31:07.519 for any of these reasons. 00:31:07.520 --> 00:31:12.199 I would just love to talk to you. 00:31:12.200 --> 00:31:14.619 Thank you so much for watching! 00:31:14.620 --> 00:31:16.519 I really hope that the talk was interesting, 00:31:16.520 --> 00:31:18.639 and I'm really excited to see 00:31:18.640 --> 00:31:19.719 your thoughts and questions 00:31:19.720 --> 00:31:21.959 right now in the Q&A! 00:31:21.960 --> 00:31:25.800 Thank you so much for watching. Bye!