path: root/2025/captions/emacsconf-2025-bookclub-tapas--bookclub-tapas--maddie-sullivan--main.vtt

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!