モノラルログ

マツオ ( @matsuoshi / monaural.net ) のざっくりしたブログです

Obsidian みたいなことを VSCode 上で実現する拡張機能 "Foam"

markdownメモアプリの話。

以前はメモアプリとして Obsidian を使ってたんですが、このところは VSCode で似たようなことを実現できる拡張機能 Foam に落ち着いてきました。

foambubble.github.io

自分のやりたいことは大して多くないので、ちょちょっとした設定でまかなえているように思います。その設定メモなどを。

ノートを書く

まあ、markdown 書くだけなので。プレビュー表示とかも VSCode なら不便しないですし、拡張機能も使いたければ色々使える。 普段使ってる VSCode なので、ショートカットキーなど覚え直さなくていいのもありがたい。

ノート間のリンク

[[page-name]] でふつうにいける。cmd+click でリンク先に飛べる。markdownファイル名を変更したら、ノート内のリンクも追随してアップデートしてくれます。

デイリーノート

option + D でデイリーノートを作れます。

デイリーノートのフォルダやファイル名は settings.json で設定可。自分は

"foam.openDailyNote.directory": "daily",
"foam.openDailyNote.filenameFormat": "yyyy/mm/yyyy-mm-dd",

こんな感じにして、daily/ というフォルダの下にさらに 2024/01/ と 年/月 なフォルダ作って、その下に 2024-02-01.md みたいな日付のファイルを作るようにしています。

デイリーノートのテンプレートは .foam/templates/daily-note.md に置けばOK。

タグ

#tag でタグ付けできる。タグ一覧も Tag Explorer ペインで見れる。タグ名はスラッシュ区切りで階層化もできる。

画像の扱い

Paste Image という拡張機能を使っています。画像をクリップボードからエディタにペーストすると、画像ファイルを作ってそこへのリンクを markdown上に挿入してくれる。

marketplace.visualstudio.com

グラフ

Obsidian の特徴的なノート間リンクのグラフ表示ですが、Foam でも Foam: Show Graph でいけます。自分あんまり使ってないっすけど。

複数端末でのデータの同期

GitHub でやることにした。

スマホでノートを見るにはどうしようかなと思ったんですが、そういえば GitHubアプリがあった。GitHubアプリでリポジトリのファイル参照はふつうにできるのでいいかな。ファイルの更新も一応なんとかできるけど、スマホからがっつり編集したい機会ってほぼないので別に良し。雑に別アプリにメモとって、あとでPCで整理することが多いです。

なお GitDoc という拡張機能を使えば、一定時間単位に編集されたファイルを自動でコミットしてプッシュする、みたいな設定も可能です。バックグラウンドで勝手に GitHub に sync させることができます。その Git の使い方どうなの感はちょっとありますが。

marketplace.visualstudio.com

なんで Obsidian を使うのをやめたか

まあ大した理由ではないのですが

  • 単純に VSCode のほうが慣れているから (ショートカットキー等含め)
  • VSCode はだいたい起動させてるし、常駐アプリは少ないほうがいいかな
  • そこまで複雑な機能は使いこなせてなかったし
  • 複数端末でのデータ動機も、まあ git でなんとかなるかなと

いう感じです。

これで大体いけそう。いけるいける。

書籍「コーチングアジャイルチームス」と、「ネイティブワイヤリング」

書籍「コーチンアジャイルチームス」

を、買いました。読み始めています。

で、第1章に出てくる「ネイティブワイヤリング」という言葉が興味深かった。

native wiring --- この言葉ははじめて聞いたんだけど、著者がアジャイルコーチとして成功した人々を見てきて気がついた、共通点をまとめたものらしい。

ネイティブワイヤリング

10項目あって、ざっくり書くと

  1. 「場の雰囲気を感知する」力
  2. プロダクトよりも人を大切にする
    • そして人が素晴らしいプロダクトを生み出す
  3. 好奇心を育む
    • 知らないということに気づく
  4. 人々は基本的に良い人だと信じる
  5. 計画は破綻しうることを理解する
  6. 学びに貪欲である
  7. 卓越性を追求する価値を認める
    • 成長のための環境と目標があれば、どんな集団でも良いことができるようになると信じる
  8. 制度的な理由や原因について妥協せず、理不尽を徹底して排除しようとする
  9. 不安定性を不可欠なものと信じる
  10. 間違えるリスクを取る
    • 間違いを犯したときは、それを認め、次に進む

これはとても納得感のあるリストだった。これ満たしてると、かーなりアジャイルな人って感じがする。

書籍の方はまだ全然読み始めなので、引き続き読んでいきます。

スプレッドシートの正規表現でパターン修飾子、欲張りでないマッチを使いたい

Google スプレッドシートは、REGEXMATCH や REGEXEXTRACT といった関数で正規表現が使える。

こんな感じで

=REGEXEXTRACT("数字は 123 です。", "\d+")

ドキュメントこちら

support.google.com

ただ、この正規表現は RE2 という正規表現エンジンを使っているようで、普段自分が JavaScriptなどで使っている書き方とは異なるものがあった。のでメモ。

具体的には、パターン修飾子、single line や 欲張りでないマッチについて。

パターン修飾子の single line

正規表現のドット . が改行を含むかどうかの指定。

JavaScript だと

/a.*b/s

といった書き方になる。最後の /s パターン修飾子。これでドットは改行にマッチするようになる。

スプレッドシートの場合は

(?s)a.*b

と書く。正規表現の先頭に (?s) をつける。

パターン修飾子の欲張りでないマッチ

JavaScript だと

/a.*?b/

といった書き方。量指定子のあとに ? をつけることで、欲張りでないマッチになる。

スプレッドシートの場合は

(?U)a.*b

と書く。正規表現の先頭に (?U) をつける。ungreedy の U らしい。

その他

single line も欲張りでないマッチも有効にしたい場合は

(?sU)a.*b

とこんな感じ。

スプレッドシートで使える正規表現 RE2 のドキュメントは、ここを見ればよさそう

https://github.com/google/re2/blob/main/doc/syntax.txt

スクラム関連のチェックリスト いろいろ

アジャイルスクラム関連のチェックリストを調べていたので、いくつか並べます

Scrum Checklist by Henrik Kniberg

Henrik Kniberg氏 (書籍「リーン開発の現場」などの著者) によるチェックリスト。色んな国の言葉に翻訳されており、日本語版は川口恭伸さんが公開されています

最低限のチェック、として挙げられているのは以下の3つ

  • 定期的(4週間以内)に動作する、テスト済みのソフトウェアを提供している
  • ビジネスニーズに基づいたものを最優先して提供している
  • プロセスは継続的に改善している

スクラムチーム用セルフチェックリスト by ryuzeeさん

ごぞんじ ryuzee さんによるチェックリスト。

10カテゴリ x 10項目 = 全100項目ありますが、こちらのツイートによると

「毎スプリントレビューで完成の定義を満たすインクリメントを見せてフィードバックを貰っている」が50点くらいで、残りは全部0.5点でいいくらい。

とのことです。

Scrum Master Checklist by MJ

MJ こと Michael James氏によるチェックリスト。こちらも各国翻訳多数。

スクラムチーム向けではなく、スクラムマスターへの問いかけになっているのが特徴。

あなたのスクラムチームの成熟度は?

Ron Eringa さんによる、各ロールごとの成熟度の表、ryuzee さん翻訳。

www.ryuzee.com

roneringa.com

SCRUM MASTER THE BOOK 自己組織化したチーム

書籍 SCRUM MASTER THE BOOK に出てくる、自己組織化したチームのチェックリスト。

ここでは引用しませんが、P8 のエクササイズ参照。

所感

個人的には Henrik Knibergさんの最低限のチェックと、ryuzeeさんの配点50点な1項目は似たことを言っているなあと。そしてそれと一緒に思い出したのが書籍「ゾンビスクラム サバイバルガイド」に出てきた 4つの症状。

ゾンビスクラム サバイバルガイドの目次より引用

  • 症状1:ゾンビスクラムチームはステークホルダーのニーズを知らない
  • 症状2:ゾンビスクラムチームは速く出荷しない
  • 症状3:ゾンビスクラムチームは(継続的に)改善しない
  • 症状4:ゾンビスクラムチームは障害を克服するための自己組織化をしない
  • すべては繋がっている

……やはりそこからだなあ、と

Fearless Change パターンの最小基本パック

書籍 Fearless Change を久々にさらっと読み返している

この書籍では変化の 48のパターンを紹介しているけれど、最初の 第1部第3章「さて、どこから始めよう?」で出てくる全体に関わる 5つのパターンをあらためて

パターンの最小基本パック

  • エバンジェリスト(1) [Evangelist]: 新しいアイデアを組織に導入しはじめるなら、あなたの情熱を共有するため、できる限りのことをしよう。
  • 予備調査(4) [Test the Waters]: 新しい好機が訪れた際に、興味があるかどうか調べるために、本書のパターンを利用して結果を評価しよう。
  • ふりかえりの時間(5) [Time for Reflection]: 過去から学ぶために、うまくいっていることや改めるべきことを評価するための時間を、定期的に確保しよう。
  • 小さな成功(2) [Small Successes]: 組織変革の取り組みをすすめるなかで、待ち受ける困難や膨大な作業に押しつぶされないよう、ほんの小さな成功でも、きちんと祝おう。
  • ステップバイステップ(3) [Step by Step]: 目標に向かって一歩一歩進めていくことで、組織変革の膨大な作業へのイライラを和らげよう。

(テキストは Fearless Changeの48のパターンのチートシートより引用)

まずは 1. 情熱・熱意が最初にあって、続くのが調査とふりかえり、小さな成功とステップバイステップ

変化って時間やリソースや協力者、支援がない状態からのスタートがほとんどと思うけど、まずはこの基本パックからなのだなあとあらためて

続きも読み返そう