It’s more effective to explain our ideas using external tools
Annotations: 0,732 SHA-256 78e7922c246e6a5a102024deb0796a31
&AI: 363,9 373,9 383,8 392,6 399,11 411 413,319
@Zsolt: 11,61 107,4 115,247 372 382 391 398 410 412
…
Annotations: 0,732 SHA-256 78e7922c246e6a5a102024deb0796a31
&AI: 363,9 373,9 383,8 392,6 399,11 411 413,319
@Zsolt: 11,61 107,4 115,247 372 382 391 398 410 412
…
Annotations: 0,1598 SHA-256 09fab30cb0cefcbc56a846db0fee07ab
…
Claude AI now can control a computer, but it is in a really early phase. It can be useful for UI scripting or automated testing.
My problem is that my #Zettelkasten is a #Jekyll project and it doesn’t contain my notes in a nicely formatted folder name. If I want to index it, I have to rename it somehow.
It also seems to be possible to rename a group by
- only temporarily locking in Finder,
- renaming in DEVONthink,
- unlocking in Finder.
This solution works perfectly. We can just lock the folder in Finder, rename it in #DEVONthink, then unlock it. Now the folder name and the path will be different.
Notes about the programmer’s notebook concept:
Independent Writer, Speaker, and Broadcaster - Merlin Mann:
Merlin Mann is an independent writer, speaker, and broadcaster based in San Francisco.
{Git Bisect is a powerful debugging tool that helps you pinpoint the exact commit that introduced a bug in your project. This feature is a great example of how Git can be much more than just a version control system, offering valuable debugging capabilities as well!}
Git bisect is a tool to find a commit that causes a bug.
{First, you need to inform Git of a commit where the code is working correctly \(the "good" commit\) and another commit where the bug is present \(the "bad" commit\).}
First, we have to set a good commit and a bad commit. These will be the start and end points of a binary search.
{Git then selects a commit that lies halfway between the two points you provided and prompts you to confirm whether the bug is present in that commit.}
Git then finds a commit halfway through, and we have to test if the commit works.
{This iterative process continues as Git narrows down the range of commits until it pinpoints the exact commit that introduced the bug.}
Then, repeat the process, which means, after a while, it will find the buggy commit halfway somewhere.
So, it uses binary search to find the commit causing the bug.
{\$ git bisect start \$ git bisect bad \# Current version is "bad" \$ git bisect good \<good-commit-hash\> \# Commit that is known to be "good" \# Git then checks out a commit for you to test and you mark it as "good" or "bad" \$ git bisect good \# or git bisect bad, depending on your conclusion \# Repeat until Git identifies the problematic commit \$ git bisect reset \# to end the bisect session}
Here’s how we can start a git bisect session.
{allows Git to remember how you've resolved a merge conflict so that it can automatically resolve it the same way if it encounters the same conflict again.}
Git Rerere is a way to tell Git to remember the merge conflict I already solved and reuse it again.
{This is particularly useful when working with long-lived topic branches, as you may encounter the same conflicts repeatedly.}
There are long-living branches that always need to resolve the same conflict, so this can help in those cases.
{git config --global rerere.enabled true}
How to enable Rerere.
{Once enabled, Git will automatically record how you resolve conflicts and reuse these resolutions in future conflicts.}
I wonder if this will cause problems because I feel it makes me trust blindly in Git for conflict resolution.
“Finding information on the front end” means using the project view in #OmniFocus to fetch our project support data. Assets are linked to actions and projects, so instead of browsing the file system using Finder, we start from the project and jump to related assets.
Starting from the project view allows us to use the OmniFocus quick-open to find projects and navigate to related information instead of general categories where we have to drill down multiple levels to find folders or files.
We should have a published section in the project plan. Or we can link to published assets using Hookmark. This is how we can prove that the project is actually producing output.
The published abstraction can be a physical thing that we made:
This note is the possible continuation of 2.8.4 Szabályok a digitális végtermékek előállítására.
Starting out in 2001 as both a writing tutor and high school substitute teacher, for the past twenty years Bob has been teaching and mentoring everywhere from public schools to punk warehouses to living rooms to online Zoom rooms and colleges. These days, he teaches courses on zettelkasten, PKM, social media, and spirituality. He is a former Building a Second Brain mentor, was the managing editor of _Parabola_ magazine between 2005–2010, has been blogging since 2003, and publishing zines on and off since the early 90s. He is the author of five books:
- A System for Writing: How and Unconventional Approach to Note-Making Can Help You Capture Ideas, Think Wildly, and Write Constantly
- Sitting with Spirits: Exploring the Unseen World In the Margins of Christianity
- The House of I Am Mirrors: And Other Poems
- Acupressure For Beginners
- The Power of Stretching
You can stay up to date on his comings and goings by finding him online or by signing up for his weekly email “The High Pony: ‘Really Good’ Insights from a Modest Perch.” For everything else » bobdoto.computer
It doesn’t matter how a project is organized; #Hookmark should contain all the related assets and links to the project. The organization of these assets doesn’t matter: we should dump everything in one folder per project and not care how we will use that information in the front end 2.8.2.4.4.
So, a file system just sits in the background, supporting our more important project-related interface, which we can use to interact with the information.
{Folders are like servers. They're the places where all your information is stored. Files, working docs, notes, PDFs, resources, images, every digital thing you've collected is stored somewhere, be it in a vault or on a hard drive. In folders, this information is typically stacked alphabetically or in numerical order. The only real way to organize the contents of a folder according to what best suits you is to rename, number, or https://writing.bobdoto.computer/how-i-use-clogs-to-organize-my-writing-files/ Page 3 of 7}
Folders are there to organize information. I like this idea that the file system is a backend of my projects.
2.8.2.4.5 The file system is a backend for our projects
{If folders are servers, then CLOGs are user interfaces. A CLOG is the means by which I engage with my writing files so I don't have to engage with what's stored in my folders. Kind of like email.}
The CLOG is like an OmniFocus project. Linking resources to a project from folders.
I wonder if I need separate ideation folders. Would be just one TaskPaper document enough (Interstitial Journal).
What does he mean by kind of like email?
{Whenever you open Gmail, you're engaging with Google's UI. This UI allows you to curate what you'd like to see. When you're in Gmail, you're engaging with a representation of the information stored on the server. You're engaging with whatever you've allowed to pass through your pre-defined filters. When you delete an email, it disappears from your UI, but not necessarily from the server. CLOGs function in the same way.}
He explains email here.
So a folder is a backend, the project is the frontend of our system.
2.8.2.4.4 The project view is the frontend of our file system
{Underneath "PUBLISHED" I list all the places I published my piece and how it did on each platform.}
Having a published section for plans is actually helpful to see outputs of a project. So technically this should managed in TaskPaper. I don’t think I need the ideation database like I think. It should be one folder called Project Support, and that’s it. Maybe organize it by area, but otherwise the folder of a project is just a backend. How I use that information in my Interstitial Journal is what’s interesting.
I want to have a way to click from OmniFocus and filter everything related to a project in TaskPaper.
I have to use the OmniFocus ID.
2024-10-05_21-08 The published section for plans is helpful to see the outputs of a project
I found this workflow about how we can use an integration branch as a base for stacked branches.
Stacked branches with vanilla Git
Instead start the work by creating a feature-integration branch, which will contain all the changes you are working on together. Later, when you better understand the specific changes you are making, you can re-order the commits with git rebase -i to group commits together that you want to slice off as their own reviewable and mergeable branches.
We don’t know the hierarchy first of our work, so we can create an integration branch to mess around with ideas. The good thing is that this doesn’t need to be pushed. I can start working on the branch without too much structure and then organize my work later.
Naming these would be something like this: TICKET-ID/integration
This would be the source branch for the stacked branches so that Tower will show it as the first item in the branch tree in the sidebar.
Just like in typical programming, the commits are in no particular order. As so frequently happens, you only wrap your head around the overall change you want to make after you’ve touched a bunch of different pieces.
What does he mean by “commits are in no particular order”? Maybe I should ask ChatGPT… Here’s what it generated about this:
In a typical programming session, you might start working on one thing, then realize another part of the system needs to be changed, and by the time you’re done, the commits reflect this non-linear process. Only afterward do you gain a clearer understanding of the full scope of the changes you’ve made.
This mirrors the messy, real-world workflow where things evolve organically as you work, rather than being neatly planned out in advance.
This essentially means that we organize our commits after we create a mess. It could be avoided, though, with frequent committing and then squashing related ones later. This would force a commit review workflow on me, which can be helpful in Finding a session wrap-up process so I can wrap up my work more efficiently.
Then we have to somehow create the branches to point at the associated commits. Remember the rule though: never switch off your integration branch. So how are we going to create these branches?
We branch off from commits. Then, these branches are pushed and sent for code review. It is still important that a PR has the proper base, so we have to maintain some form of connection between them.
Or, it can be solved by pushing the integration branch too, and setting that as a base, but then we lose the nice local, private sandbox.
The beauty of this method is that you are still on the
feature-integration
branch, ready to keep adding new work, whilefeature-a
can go up for review.
In theory, this sounds good, but what about keeping stuff current?
I have to review these use cases first in Tower. I don’t care about the command line git
for now.
Follow-up on 2024-08-14_23-33
I’m not sure if this is a good idea, but maybe I should hide the front page of my Zettelkasten? It would give me a way to discover random ideas.
On the other hand, I’m trying to make it more journal-like, so this idea would not help with that.
I’m introducing a new “Thought” tag, which will be used as entry points for the current threads I’m thinking about and developing.
The idea is to have an initial post tagged with “Thought” and follow-up notes are linked to that as a new reply. Over time, I’ll end up with a conclusion that can be developed into one or more permanent notes (2.6.9.5.1 and 2.6.11).
This is a remixed version of the #Folgezettel and 2.6.4 A strukturált jegyzetek a Zettelkasten belépőpontjai.
Follow-up on 2024-09-06_23-25
I want to find more ideas about using blogs as an external mind. Digital gardening is one way of doing this. 2.6.10
But I’m more interested in the commonplace book, where ideas are just thrown into a journal and, over time, developed into more refined ideas. I don’t care about nurturing the same post over the years.
My problem with that idea 2.6.10 is that I don’t know what the end result will look like. Instead of working on something for a long time, we should focus on outputting more posts and refining each new one better than the previous one.
These are my highlights from reading The Memex Method—Pluralistic: Daily links from Cory Doctorow.
The blog as an annotated browser-history
Is blogging like adding annotations to browser history? If you mainly blog about things you found online, sure…
Every day, I load my giant folder of tabs; zip through my giant collection of RSS feeds; and answer my social telephones – primarily emails and Twitter mentions – and I open each promising fragment in its own tab to read and think about.
If the fragment seems significant, I’ll blog it: I’ll set out the context for why I think this seems important and then describe what it adds to the picture.
So, his primary source is his web browsing. That’s fine.
My primary blogging sources also include my ideas. Maybe that’s why having a Zettelkasten is important at the end. Perhaps I should also keep a tab open for my ideas? I love the idea of fragments being opened in tabs. This is a nice metaphor since macOS tabs exist in the UI everywhere, so they provide a simple UI for fragments of information in apps that are made for browsing and managing information.
In the (my) blogging method, the writer blogs about everything that seems interesting, until a subject gels out of all of those disparate, short pieces.
So, blogging on its own can be a Zettelkasten-like way of emerging ideas as we develop them. Why do I need my Zettelkasten, then? Maybe my blog is my Zettelkasten. I think a Zettelkasten can help thread ideas together in an outline format, forcing ideas to emerge.
Blogging isn’t just a way to organize your research – it’s a way to do research for a book or essay or story or speech you don’t even know you want to write yet. It’s a way to discover what your future books and essays and stories and speeches will be about.
Blogging is a way of discovery, so blogging about something should be like date-ordered public thinking. Tags are subjects of interest. Maybe I should have more specific tags, like “Mac app renaissance.”
To conclude, my Zettelkasten is one of the backbones of my blog, along with journaling and browsing the web.
Follow-up on 2024-09-01_12-48
Looks like having the comma after the wikilink in follow-up notes will break the backlinks feature (relevant code).
For now, I’m going to use the following format:
Follow-up on wikilink
Follow-up on 2024-08-14_23-33
I forgot that I have a “Follow-up” button on my Zettelkasten website. This can be used for quickly writing a follow-up note about something I already started. Basically yet another way to create threads.
Then, I could save these threads by opening them on the website one-by-one and saving the stacked note URL.
Annotations: 0,2418 SHA-256 d9a43a5035e7c0495ed8243d5096fd4f
@: 77,23 101,43 145,199 347,323 673,1268 1991,427
@Zsolt: 50,10 76 100 144 344,3 670,3 1955,3 1989,2
…
Follow-up on 2024-08-14_23-41 Using Drafts to write notes
Sadly linking in #Drafts doesn’t work like that. If I want to use my follow-up script in #Drafts, then I have to assign a timestamp as the title then it can be used as a link.
h1
element.
Actually I should start my #Zettelkasten notes in #Drafts. When I have multiple ideas, it is easier to capture them in that app.
I can also pre-link these notes together in Drafts in the same as I can in iA Writer, so when I export them, the links should still work.
I’m thinking about giving up the general idea of the #Zettelkasten. I don’t have time to create permanent notes (or whatever we call them) and then link them together if I don’t use any of these notes in a writing project. And I don’t have any writing projects.
Instead, I want to focus more on using my #Zettelkasten as a journal-like medium where I can think freely in public and don’t have restrictions on how I format notes or link them.
This change means I would have more random thoughts like this, and if something is a returning thought, then maybe I’ll convert it into a more refined idea that can be stored in my outline.
On the other hand, if I read about an interesting topic, I would still use this page to store classic Zettelkasten notes (2.6.11).
Managing folgezettels means that I should have a general idea about why I’m collecting notes about a topic. Since a #Folgezettel is a thread, it should have some form of outcome. I can grab them as-is and finalize them into a blogpost or a project, or some form of plan.
When I see a #Folgezettel emerging, I could pick a bunch of notes and paste their content into #Gibberish. This way, I can create the first draft using a chat-like UI and get a feel for the final post.
Source: Making my file archive portable in a different way – Decoding
I concluded that each of these tools has its place.
I have a bunch of apps where I can manage information, and I should cut them back and figure out which one I’m using for what.
Here’s an initial list of my current use case of them.
Follow-up: 2024-02-21_00-19-conclusion-on-my-journaltype-apps
I’m a designer and front–end developer. I enjoy crafting quality macOS applications on the side. I’m also passionate about industrial design, typography, architecture, and art.
He makes an app called Finbar, which I use for searching my menubar from the keyboard.
Planning out my time with iCal calendars and groups, and being able to click back and forth between that planning view and David Allen’s “hard landscape,” is very appealing. I’d forgotten your earlier post on this topic, but I’ll be returning to it for ideas.
The printed calendar I carry with me doesn’t have the kind of detail yours does, but it does have the advantage of giving me four months of schedule in my back pocket. Do you print your calendars to any special size—e.g., for pasting into a Moleskine—or just to letter-sized?
The daily agenda for a trip sounds like a great idea for many (salesmen, in particular), but my trips are almost always focused on a single project. I’m more likely to be juggling appointments on the days I am in front of my computer.
Thanks for mentioning iCal. I have ditched eveything else and find that iCal has everything I need for GTD.
It’s a calendar, to-do (to-do’s can be sorted by calendar, too, by the way) list, tickler file (just put “See File under “file name” in the notes field) and, well, everything else that GTD requires.
Here’s the reason I forced iCal to work for me: I don’t carry a PDA, just a sony ericsson phone, and everything that is in iCal, including tasks and alarms, are synced with my phone quickly via iSync. I even have a script to open iSync, sync them, them quit iSync, all by hitting Shift-F8. So I just tap the hotkey when I get to my mac and leave it, and all my stuff is current all the time and very portable, always in my pocket.
Another great thing, it doesn’t just import from iCal to the phone, it syncs them, so when I’m out and I need to add a task, I can do it shorthand on the phone and it will sync to a calendar called “Inbox” in iCal when I sync up.
I would love to use fother fun GTD software, but alas, I don’t need to. If you carry a syncable phone with you everywhere, I highly recommend tweaking iCal to work as your GTD system.
Did I mention there’s tons of little apps and even widgets that let you see your iCal stuff at a glance without bringing up iCal? Very nice.
#TBD…
I was think about switching from #Things to #TaskPaper. Task-management is the last piece where I still don’t use plain text, albeit using Markdown in Things notes (see 2023-12-09_12-09 Things to-do journaling template).
TMTask
table includes projects, headers, and to-dos.hook
files linking back to projects as way to have a fake Spotlight index.
Knowing that the database is fairly easy to understand, I’m a bit more confident that I can export my to-dos out of Things. I can even use the SQLite database directly as an archival format too.
The non-existence of end-to-end encryption is still bugs me though.
I’m an experienced software engineer living in Magdeburg, Germany. Available for projects that match (
Swift()
/[Objective C]
).
Programmers complain about distractions all the time. But when we journal and document our actions, we can drop them in the moment and pick them up later from where we left off. It’s like bookmarks for our lives (see next actions 2.7).
We will also have a history of our actions in the journal, which can be used as a reference when we have to go back in time.
Automations should be exported into Git repositories. They have to be installed since most automation tool expects a script, a shortcut, or a macro to be imported into a library, or installed in a special place, but we can still export and assemble files from our tools into a repositories.
Keeping these repositories up-to-date can be a burden, since we have to manually export files. But it’s still beneficial to keep these under version control, since sync problems can happen, so we can go back to a previous version more easily.
Annotations: 0,659 SHA-256 cd1cb7e9d11f6799878e0f3997725c4d
&AI: 367,39 413,92 521,7 547
@Zsolt
When committing atomic changes of a “thing”, it has to have the following items included:
If the commit includes these, we can directly commit it into the main
branch.
However, this wouldn’t work in a team setting since it requires too much discipline from other people. Also committing directly to the main
branch can be dangerous.
PR commits don’t need to be that strict.
Merge commits on the other hand needs to be in a specific format.
issue number
This is my standard notes template for journaling about a #Things to-do in its notes.
# 2023-12-09_12-07
Notes about what happened with the to-do…
# 2023-12-09_12-09
Yet more notes about what happened with the to-do…
Source: Hook: getting out of the Dock - Discussion & Help - Hookmark Forum
To display the icon on the Dock:
defaults write com.cogsciapps.hook background.app.mode 0
To revert it to be a background only app:
defaults write com.cogsciapps.hook background.app.mode 0
I’m going to keep my interstitial journal separate from my Zettelkasten. My journal doesn’t need Git and all the bells and whistles of my Zettelkasten. I just want to have a simple place to quickly draft ideas.
Some notes may move over to my Zettelkasten, which I can automate, but it’s very private, so I don’t want to accidentally publish something.