2024.10.06.

Bruno Brito

Content Marketing Developer @ Tower

Bruno enjoys learning new things just as much as he enjoys teaching them. Thanks to his carefully crafted content, you won’t need to wrestle with hard topics. When he’s recharging, you will find him listening to electronic music while playing video games.

#Person

Beyond “Commit” and “Push”: 5 Advanced Git Features You Should Know


Page 2

{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.

Page 2

{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.

Page 2

{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.

Page 2

{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.

Page 3

{\$ 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.

Page 3

{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.

Page 3

{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.

Page 4

{git config --global rerere.enabled true}

How to enable Rerere.

Page 4

{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.

#Drafting #Literature

2024.10.05.

The project view is the frontend of our file system

“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.

The published section for plans is helpful to see the outputs of a project

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:

  • We can create a picture and a journal entry about the end-result
  • We have to have some form of external thing that we can point to at the end of a project

This note is the possible continuation of 2.8.4 Szabályok a digitális végtermékek előállítására.

#Drafting

Bob Doto

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:

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

#Person

The file system is a backend for our projects

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.

How I Use CLOGs to Organize My Writing Files


Page 3

{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

Page 4

{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?

Page 4

{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

Page 6

{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.

  • Plans
  • Journal entries

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

#Literature

2024.10.03.

Using an integration branch as a base for stacked branches

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.

  • So the question is, what should we use a base for a PR here?

The beauty of this method is that you are still on the feature-integrationbranch, ready to keep adding new work, while feature-a can go up for review.

In theory, this sounds good, but what about keeping stuff current?

  • Can I re-order branches in Tower so one commit gets into a branch automatically?
    • Or do I have to cherry-pick?
  • What about editing an existing commit where I do the coding?
    • I don’t see that as a convenient way to integrate commits
  • Will the Tower re-stacking workflow work in this case?

I have to review these use cases first in Tower. I don’t care about the command line git for now.

2024.09.07.

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.

What's my problem with digital gardening

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.

#DigitalGarden

2024.09.06.

Blogging is about annotating our mind

This method was first mentioned in 2024-08-18_08-52 Writing Inbox in iA Writer.


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.”

  • Maybe I should even add descriptions to tag pages.

To conclude, my Zettelkasten is one of the backbones of my blog, along with journaling and browsing the web.

#Zettelkasten #Blogging #Thought

2024.09.01.

Using follow-up notes

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.

Here’s an example for a stacked notes URL.

2024.08.19.

2024.08.18.

Writing Inbox in iA Writer

Inbox workflow from Ploum:

I simply have an “inbox” folder where there are drafts in gemtext format. They could linger there for months or years. Sometimes, they are published one hour after starting them. There’s no rule.

I’ve been greatly influenced by Cory Doctorow and his memex method. In my inbox, I keep a “today.gmi” file in which I write small reflections and links to interesting articles. When the file is bigger than 1000 words, I try to give it a direction, I reorder the nuggets and publish it without thinking too much about it.

As a consequence, my blog is a mix of focused posts that took a long time to write, focused posts that were written in a whim and posts containing random thoughts and links. I let you try to guess in which category is a given post.

I like the ideas of this post. Having an inbox where my posts are drafted, then publish them directly. I should have a better system for using iA Writer in my everyday blogging, not just longer posts and the Zettelkasten-type notes.


I basically have a Bike outline named “Decoding”, which is used as daily notes and I can publish things directly from there. iA Writer is more for post drafts, or general ideas. I should maybe use it to draft stuff there. If something emerges, then maybe create a project for it in my Writings folder.

So this is the order of my idea flow:

  1. Bike outline for short posts and ramblings
  2. Drafts for ideas when I’m away from the computer
    • Or I want to add a new idea to my threads in iA Writer
  3. Use iA Writer to write or nurture these draft posts
  4. Create a new Writings project if it needs longer form writing
  5. Publish the posts from iA Writer depending on the location

I should just have one place, which is the #Drafting tag to use it as a writing inbox.


I really like how Andy Matuschak 2024-08-19_16-24-andy-matuschak uses the writing inbox concept. It is a list of ideas which should be worked on, then formed into something final.

I should have some form of flow with any material which is enters my life somehow, I work on it, shape it, then I have a final artifact 2.8.4 which can be used as a product that I’m sharing with someone (or me).

So when I’m working on something, I should ask that how this will be finalized?

2024.08.14.

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.

  • iA Writer links to file names.
  • On the other hand, #Drafts links to note titles (which is the first line of the note).
  • When I export the note, the file name becomes the timestamp of the note, then the title is assigned if the first line is an h1 element.
    • Looks like my #Zettelkasten can’t parse wikilinks to titles which is weird, because I remember that I had that feature to be compatible with both ways of linking.

Zettelkasten refinements

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).

#Thought

2024.03.18.

Implentation plan – Making my file archive portable in a different way

Source: Making my file archive portable in a different way – Decoding

Tasks

  • My Sandisk drive is perfect for this, since it has a rubber enclosure
  • Test run
    • Setup ChronoSync to sync my file archive to an external drive
    • Connect my 1 TB external G-DRIVE and sync
    • Get the offsite backup drive home
      • My other Sandisk Drive
    • Connect a new external drive to my Mac mini
      • I’m switching from Sandisk drives to OWC enclosures for mobile backups, so I’ll have two drives available for use
  • Make a note on my packing list to bring the archive mirror drive when I’m away from home
  • Uninstall Tailscale and delete my account
    • This is tracked in a different OmniFocus project

2024.02.21.

Highlighting information in streams

  • Streams are information collections, where new information is getting pre-pended or appended.
    • 2.16 Appending information is way to keep a history of changes
  • Highlighting information in streams is the #GTD capture and #Journaling process.
    • #GTD capture is for highlighting an interesting thought in the stream of our thoughts
    • #Journaling is for highlighting a moment that we want to process or remember in the stream of our life.
  • Streams should not store any state about whether we have seen something or not. A stream is just a raw collection of data, usually sorted by time.

#Linking

Conclusion on my journal-type apps

I concluded that each of these tools has its place.

  • Decoding files #DigitalGarden
    • Raw Bike outlines to quickly edit and publish a post to my blog.
    • All the content in these files should be ready to be published. Private things can be tracked in the interstitial journal.
  • Interstitial Journal #Journaling #TaskPaper
    • A way to track information throughout the day.
    • Work on routines using checklists.
  • Day One
    • My private blog, where I can explain ideas and thoughts to myself without the fear of any public visibility.
  • Apple Journal #Journaling
    • The life bookmarking tool for my thoughts and photo stream.
    • My photos are a stream of captured moments and I can highlight important ones by adding them with a short description to Apple Journal.
  • Strflow
    • Strflow is great for short idea dumps when I’m thinking about something. Then these ideas can be moved to my system in OmniFocus/Bike.
    • I don’t have any use for Strflow currently, so I’ll remove it from my toolchain.
      • I keep the app installed because I have content inside it.

#Journaling

2024.02.18.

Consolidate my journals

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.

  1. Bike journal for logging information to my blog (or privately).
  2. TaskPaper journal, which is more of a running list of tasks for today, but can be used as a private journal.
  3. Day One which is an actual journal app, but kept private.
    • I recently re-installed Day One, because it is still the best and most native-looking private journal app I know on the Mac. I don’t trust their custom sync engine though.
  4. Strflow, for capturing ideas.
  5. #Zettelkasten, which can be also used as a journal.

Follow-up: 2024-02-21_00-19-conclusion-on-my-journaltype-apps

#Journaling

Using the Zettelkasten to advance R&D projects

  • I have these “look into” type #GTD projects which are about getting myself more familiar with something (which could be a tool, a programming language, a framework etc).
  • Previously I created OmniFocus projects with corresponding Bike outlines, so I can collect my notes in one place and then figure out what to do with this information later.
  • What I have in mind instead is to use my #Zettelkasten to manage these outlines.
    • The #OmniFocus project would be still present because I need to have a place to store #NextActions.
    • The #Zettelkasten would be the outline.
    • As I gather more information I would add more connections as a form of reading and permanent notes.
      • 2.6.5.1.3 Jegyzetek gyűjtése könyvolvasás közben
  • By using my #Zettelkasten like this I would have a history on how I learned a topic, and where should I pick up next time.
    • 2.6.5.7 A Zettelkastennel párhuzamosan több dolgot is írhatunk
    • The #Zettelkasten serves as a journal, because I keep the history of my learning path in the a timeline of timestamped notes which can be reviewed in later when I pick the topic again. #Journaling

2024.01.02.

2023.12.24.

2023.12.17.

Cool iCal tips from 43folders

https://web.archive.org/web/20060819234608/http://www.43folders.com/2006/06/29/ical-tips/#comment-8784

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.

https://web.archive.org/web/20060819234608/http://www.43folders.com/2006/06/29/ical-tips/#comment-8841

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.

2023.12.10.

Exploring the database format of Things

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).

  • Why I like Things
    • Nice UI
    • #Markdown support in notes
    • Really good #Shortcuts integration
    • iOS and iPadOS versions, which are at the same level of excellence
    • There is a link to everything
    • No attachments
      • People tend to dislike this. Having no attachments support forces me to have better attachment management in dedicated apps like DEVONthink
  • Why I don’t like Things
    • Uses a database
    • Sync is not end-to-end encrypted
    • No Spotlight integration
      • On the Mac, I periodically run a script which creates .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.

2023.12.09.

When we keep a journal we automatically keep bookmarks for ourselves

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.

#Journaling #NextActions

I can keep automation scripts in Git repositories

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.

Keeping an issue thread ensures we have background information about code changes

  • Timestamped documentation
    • #TBD…
  • A timeline of changes
    • As the idea develops, we can see a timeline of changes in the issue.
    • The timeline of changes is similar to how Zettelkasten threads work. The only difference is that we can’t have indentation with timelines.
  • An issue thread is like background information on what decisions we made about our code at a point of time.

Documentation should live in the same repo as the code

  • Documentation review should be part of the code review.
    • By forcing us to store the documentation in the same repository, we can keep it up-to-date with the code directly.
    • We can catch missing documentation updates in PRs while doing code reviews.
  • The documentation is versioned in a way in Git that ensures it aligns with the same version of the code, thus automatically synchronizing its history with older versions of the app.
  • Question: how we can migrate existing documentation from an external wiki into the repository?

#Linking

We don't need to create a PR if the commit is atomic

When committing atomic changes of a “thing”, it has to have the following items included:

  • Actual code changes
  • Tests/specs
  • Documentation
  • Reference to an issue number (or a link to an external issue tracking software)

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.

#Development #Linking

Things to-do journaling template

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…

#Journaling

Displaying Hookmark icon on the Dock

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
  • #BugsQuestions
    • The problem with the Dock mode is that the Hookmark app still kept active after copying the link.
    • It doesn’t switch back to the original app.
      • LaunchBar has a Dock mode, but it doesn’t steal the focus when it’s activated.

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.

#Journaling #TaskPaper #Zettelkasten

The Arc style tab and bookmark management

People seemingly like Arc because of its tab management. I think it can be replicated with Safari as well using tab groups.

Arc doesn’t even have bookmarks, but Safari does.

  1. A bookmark can live in the temporary tab space
  2. It can be moved into more specific tab groups
  3. From here it can be even bookmarked into my Inbox tab group
  4. I can organize the bookmark in my Safari bookmarks, or move it into other apps for long term storage.

I should manage my Pull Requests like this, since they are very important.

2023.12.08.

I can quickly search today’s notes by typing fdate into The Archive’s omni bar. Typinator will expand today’s date.

I also modified my Open Current Note in Zettelkasten shortcut to give me an option to open the note in The Archive too. I just figured out that it searches for the note and gives me backlinks.

#Shortcuts #Workflow #Journaling

Simon Willison

Simon Willison is the creator of Datasette, an open source tool for exploring and publishing data. He currently works full-time building open source tools for data journalism, built around Datasette and SQLite.

Prior to becoming an independent open source developer, Simon was an engineering director at Eventbrite. Simon joined Eventbrite through their acquisition of Lanyrd, a Y Combinator funded company he co-founded in 2010.

He is a co-creator of the Django Web Framework, and has been blogging about web development and programming since 2002 at simonwillison.net

#Person #Development #Web

Refactor Things journaling

  • Create a repository for the original shortcuts
    • automation-things-journal
  • Journal About Things To-Do
    • Save the Things URL of the selected item
    • Create a new Drafts document with the date, published, things_url, title attributes in the frontmatter
    • I could also create a new text file directly using iA Writer URL schemes, and the Shortcut
      • Get the Things URL
      • Format the frontmatter
        • title → name of the selected Things item
        • date → the current date
        • publishedfalse
        • things_url → URL of the selected Things item
      • Create the Markdown file with a timestamp and a slugged version of the selected Things item
  • Open Things To-Do Journal

#Journaling #Things

Refactor checklist journaling

Automation repository creation

I created the new repository for my first automation script. https://github.com/zsbenke/automation-taskpaper-checklists

It would serve as a demo.

  1. Include all files that are needed for the automation.
  2. Create a README.md file which describes what it does.
    • I could include the keyboard shortcut which triggers it.
  3. Record a demo.mov file
  4. Upload the demo.mov file to Vimeo with the name of the automation
    • Automation – Automation Name
  5. Link the demo.mov from Vimeo in the README.md

#Automation #Reference