-> 인박스 제로 - 나우
PARA CODE ORG-ROAM and Zettelkasten for BASB
PARA
[2023-10-11 Wed 15:46]
https://tasshin.com/blog/implementing-a-second-brain-in-emacs-and-org-mode/
P.A.R.A.는 간단하고 일관된 정리 시스템을 제공합니다. 프로젝트, 영역, 리소스, 아카이브의 약자입니다:
- 프로젝트: 특정 결과 및 마감일에 연결된 관련 작업 그룹
- 영역: 지속적인 활동 영역(마감일 없음)으로, 충족해야 할 기준이 있습니다.
예를 들어, '수리 업체 호출'은 작업이고, '차고 문 교체'는 관련 프로젝트이며, '집' 또는 '주택 유지보수'는 해당 주택을 계속 소유하고 거주하기 위해 일정 기준이 필요하므로 영역에 해당합니다.
-
리소스: 특정 프로젝트나 영역과 관련이 없지만 '이맥', '생산성' 또는 '보드 게임'과 같이 회원님이 관심을 가질 만한 자료입니다.
-
보관함: 비활성 프로젝트, 영역 또는 리소스입니다. 예를 들어 작년에 완료한 집
유지보수 프로젝트, 오래된 직업, 예전에는 했지만 더 이상 적극적으로 관심을 갖지 않는 취미 등이 있습니다.
프로젝트와 영역을 명확하게 정의합니다. 그런 다음, 그 프로젝트와 영역을 받은편지함과 저장 공간에 복제합니다. Tiago 는 작업 관리자와 노트 작성 프로그램 사이에 프로젝트와 영역이 일관되고 완벽하게 동기화되도록 할 것을 권장합니다.
필요에 따라 문서 폴더나 클라우드 스토리지 서비스와 같은 다른 받은 편지함에 파일을 복제할 수 있습니다. 새 파일을 다운로드하거나, 새 작업을 기록하거나, 새 웹 페이지를 저장할 때마다 해당 파일이 어디로 이동해야 하는지 이미 알고 있습니다.
실행 가능한 자료라면 작업 관리자의 해당 프로젝트나 영역에, 그렇지 않은 자료라면 파일 시스템이나 노트 작성 프로그램의 관련 프로젝트, 영역, 리소스, 아카이브에 저장할 수 있습니다.
미친 소리처럼 들리겠지만, 이 시스템을 구현해 보니 예전 방식이 미친 소리처럼 느껴집니다. 많은 Emac 사용자는 설정에 가장 중요한 각 파일의 기능과 이유를 설명하는 메모를 추가합니다. 이 방법을 사용하면 이러한 정보가 불필요합니다.
이와 관련된 또 다른 요점이 있습니다. 대부분의 조직 모드 사용자에게는 실행 가능한 정보가 실행 불가능한 정보에 매우 가깝습니다.
실행 가능한 정보를 확인하고 싶은 경우, 원본 파일의 작업 옆에 노트가 있더라도 안건 보기를 사용하면 매우 쉽게 확인할 수 있기 때문입니다.
쉽게 사용할 수 있는 시스템을 만들어야 합니다.
왜 이 쓰는가? 아주 중요한 지점에 봉착했다. 정말 중요하다. 나는 제텔카스텐을 추구한다. 이게 나의 지향점이다. 글이 다 어디에 갔는가?
일단 로그시크 수준의 연결망을 제공해야 한다. 내가 이맥스에 정착한 이후 오그롬으로 그 정도를 만나본 경험이 있던가? 이게 굉장한 문제다.
그리고 계획은 존재한다. 프로젝트라는 이름이다. GTD 일 필요가 없다. 이건 맞지도 않는다. 차라리 제로스나 TSHU 의 스타일을 가져가야 한다.
이건 명백한 것 같다.
그래서 안타까우면서도 어쩔수 없는 부분이다. 설정은 뻔하고 해야 할 일도 뻔하다. 차라리 내 워크플로우에 녹여내는게 좋을 것 같다.
하기 전에 무엇을 어떻게 할 것인가는 명확해야 한다.
그리고 이와 별개로 오그롬이 제대로 동작하는지, 버퍼는 보이는지 이 부분도 해결 봐야 한다.
어젠다와 별개 시스템으로 바라보는 것이다. 오그롬은 오그롬 대로 바로 서야 한다.
태그와 카테고리
[2023-05-20 Sat 18:52] 어젠다와 고리를 연결하는 방법 어젠다 인박스에 뭐가 있는가? 지저분한게 너무 많다.
블록 어젠다
[2023-05-18 Thu 04:53] 어젠다를 조금 더 블록 어젠다 처럼 사용해 보면 어떨까? 이건 이전에 프롯이 했던 것과 유사하다.
어젠다를 열면 저널에서 블록 어젠다를 만들어 주는 것이다. 그래서 해당 블록에 무엇을 했는지를 기록하면 된다. 그리고 그게 클록 테이블로 리포트 될 수 있으니까. 블록 들이 어떻게 운영되고 있는지 알 수 있다. 해당 블록 저널은 클락인의 대상은 아니다. 클락 인은 리파일에서 하는 것이다. 사실 블록 어젠다는 저널에 만들 필요도 없긴 하다.
다이어리에 잡아주면 된다. 보이는 것만 그러하고 저널에 있으면 적으면 되는데.
아. indistractable 에서 말하는 딴짓 본짓 그 맥락이다. 아무튼 조금 더 맞출 필요는 있다. 다만.
명확히 달려야 할 때는 그냥 하는가? 아닌 것 같다. 그럼에도 계획이 있어야 예측이 가능하고 성취가 가능하고
그리고 나의 역량이 파악이 된다.
이 부분은 앞으로 중요할 것 같다. 내가 나의 능력을 파악하는 개념이다.나에게 하루는 몇개의 블록이 있으며. 그 블록을 어디에 쓸 것인지. 대략 알고 있어야 하고. 그래야 코치와도 소통이 가능하고. 매니저도 알 수 있다.
도메인 - 서브 도메인 연결 그리고 제텔카스텐 구성
[2023-05-18 Thu 09:31]
호스팅 케이알 도메인에 메인 깃허브 블로그를 연결하고, 서브 도메인을 활용해서 note.junghanacs.com 도 만들어 보자.
아침에 고민한 바, 제텔카스텐 스타일로 전체 시스템을 구성한다.
여기 있네. 제텔카스텐 프로세스이다. 여기에 조금 맞게 생각을 해서 구성을 했다. https://zettelkasten.de/posts/every-step-value-creation/
핵심은 다시 쓰기, 연결 하기, 버리기랄까? 복잡하게 생각하고 구성하면 제텔을 시도 조차 못한다. 일단 단순한 시스템으로 시작해서 확장해야 한다. 수작업을 하고 나중에 자동화를 하면 된다.
일단 베이스는 book 테마로 갈 것이다. 다국어 지원하고 책 처럼 구성하기에 좋다. 다만 짧게 쓰는 노트들을 계속 올리기에는 지저분할 것 같다. 그리고 구성을 나누고 싶은 것도 있다.
제텔카스텐 프로세스에 입각해서 바라보면.... 잠시 로그시크를 다시 세팅하고 왔다. 같은 맥락에서 활용해야 하니까.
CODE, PARA 기법과 제텔카스텐
[2023-05-18 Thu 12:57] PARA 는 정리 방법론이다. CODE 의 개념의 일부분이다.
- PARA 기법으로 자료를 분류 저장해야 된다. 그냥 저널로 때려 박으면 찾을 수가 없다.
- 어젠다에 워크 플로우가 다 들어가 있다. 그것만 이용해서 관리하고 그것만 보고 진행하고 글로 기록하면 된다. 사실 노트 쓰기 방법론은 중요하지 않다. 다만 창조의 과정으로 융합이 되도록 워크플로우를 설계할 필요가 있다.
- 이러한 관점에서 TSHU 의 닷파일을 보면 딱 그게 구현되어 있는 듯하다.
- 나는 여기에 제텔카스텐의 맥락을 가져가려고 한다.
- 잠시만 PARA 기법을 보니 정말 간단하다. 이것 자체는 분류하는 것일 뿐이다. 내가 지금 분류가 안된 링크 할일 들이 얼마나 많은가? 사실 이것 부터 정리를 해야 다음이 의미가 있을 것이다. 그리고 Org-roam, Denote 와 관련이 없다. 자료를 수집하는 방법이다. 오히려 CODE 는 편집툴과 관련이 있을 것 같다. 제텔과도 별개다. 제텔은 내가 무엇을 쓰고 있는가에 관계가 있다. 사실 지금 이렇게 쓰는 것도 다 하나의 글에 반영이 되었어야 한다. 전체적으로 중구 난방인 것이다. 완전 간단하게 시스템을 가져가야 한다. 내가 뭘 하려는가?
- PARA 를 적용하고 있다. 잠시만 자료 수집을 어떻게 해야 되는지 정말 난해하다. 근데 자료 수집이라는게 맥락이 맞는 말인가? 목표에 따라서 하는 일인데 자료는 그전에 이미 갖춰진 상태이고.
- 예를 들어, basb-code 가 있다면 이건 basb 관련 페이지에 넣고 넣고 한줄로 이건 뭐다라고 써 놓으면 되잖아. 그러면 이해하는데 문제가 없지?!
- Denote 로 복잡한 개념을 연결하려면? 연결? 연결 대상과 어떻게? 태그 시스템이 사전에 정의가 되어 있다면 간단하게 하는게 더 쉽다. 로그시크에서 경험한 바 중구 난방이 되어 버리는데. 이게 통제를 해야 하는가? 통제는 태그로 하는게 맞을텐데.
- 이렇게 =저널=에 쓰고 있는게 바로 문제였다. 롬이야 롬으로 상상해봐. 이게 답이야.
org-capture-templates
[2023-05-18 Thu 17:42] 무엇을 어디까지 해줘야 하는가? TODO 엔트리 만들어 주는 건 의미가 없는 것 같다.
(setq org-capture-templates
'(("n" "Notes" entry
(file "~/org/inbox.org") "* %^{Description} %^g\n Added: %U\n%?")
("m" "Meeting notes" entry
(file "~/org/meetings.org") "* TODO %^{Title} %t\n- %?")
("t" "TODO" entry
(file "~/org/inbox.org") "* TODO %^{Title}")
("e" "Event" entry
(file "~/org/calendar.org") "* %^{Is it a todo?||TODO |NEXT }%^{Title}\n%^t\n%?")
("w" "Work TODO" entry
(file "~/org/work.org") "* TODO %^{Title}")))Wai Hon's Blog and Emacs => #디노트
[2023-10-05 Thu 14:17] 여기서 디노트 활용법 확인
[2023-05-18 Thu 13:01] 미니멀 한 구성에 감탄했다. Emacs Config - Wai Hon's Blog 여기에서 따라가고 검토해야 할 부분은 다음과 같다. 일단 코드를 싹 밀어 넣고 생각해야 겠다. 다음은 없다. org attach, breadcump, org-drill, cnfont 등 파악할 부분이 많다. 훌륭하다. pandoc template 도 알아둬야 할 것 같다. (tshu)