のらてつの雑記帳 検索除外

「project」という機能もあるんだけどこれもまたなんというか、惜しい…というか…。
いつか改良されるのかもしれないし、しばらく様子を見ることにする。

面白いことを試みているアプリだなと思いつつ、アフォーダンス的にいま一歩なところがあり、これをガンガン使おうという気には今のところならない。
でも触ってみると勉強になるところがあるなと思う。

タイトルだけを小さい付箋のようにしてずらっと並べるビューがあって（Surfingビュー）、やっていることとしては単純な話だけどこれはとても良いと思う。
（後でスクリーンショット貼ります）

というか、それ以外のMarkdown書式は使えないかも？
入力補助がないだけでなく、自力で書いても反映されないようだ。

本文は、「数式」「太字」「斜体」「箇条書き」「リンク」のアイコンがあって、それらの操作についてはやりやすいようになっている。
それで十分かどうかは人によりそうだが、個人的には十分かなと思う。
リンクは既存のカードタイトルがサジェストされるので入力がとても楽。

最近VSCodeの拡張機能開発に勤しんでいるが、そのきっかけはこのアプリを見て「フロントマターを使って親子関係を設定し、拡張機能で行き来することはできないか」と思ったから。

各カードに「親」と「タグ」を設定でき、本文内でリンクも貼れる。
色々やれるのはかえって混乱を招く場合もあるが、「タグ」「リンク」の他に「親子」の概念があるのは「なるほど！」という気分になった。

アプリ紹介画面のスクリーンショットだと個人的にはフォントがなんとなく微妙に見えるけど、実際には普通にシステムフォントが使われるので気にならない。

なんか今日一日表示がめちゃくちゃなままだったなあ。

VSCode拡張機能は今のところ、

• 左サイドメニューにアイコン設置
• 左サイドパネルの表示
  • 任意のデータでツリー構造作成（Tree View）
    • 開いているmdファイルのフロントマターのデータをサイドパネルにツリー構造で表示
• 絞り込んだファイル群を選択肢としたクイックオープン構築
  • 選択でそのファイルを開く

あたりができるようになった。
そんなに難しくはないのだと思うけど、APIと格闘するということ自体がそんなに慣れていないことなのでなかなか時間がかかる。

メッセージの表示

右下にぴょこんと出るやつ。その際に選択を求めることも可能。
Notifications | Visual Studio Code Extension API
vscode-extension-samples/extension.ts at main · microsoft/vscode-extension-samples

Information

vscode.window.showInformationMessage('Hello World!');

Warning

vscode.window.showWarningMessage('Warning');

Error

vscode.window.showErrorMessage('Error');

ちょっと長く書こうとした時に、「今後ツリーにするかもしれないなら細かく切り分けた方がいい」と思ってなるべくアトミックにしようという気持ちが働く。その「ちょっと待てよ」という感じが自分で面白い。
Twitterでは「なるべく誤解ないように一度に書こう」とか「140字埋めるくらいで話の収まりが良い」とかいうことを考えて、字数が短い割に話が横断的になってしまうこともあった。

あと自作よりカスタマイズの方が難しくて、ScrapboxのUserScriptなりChromeなりVSCodeなりを自分で機能拡張できるようになったのは本当に大きい。
やっぱり、土台の頼りない完全自家製ツールで頑張るよりも、ちゃんとしたものを自分仕様に近づけられた方が安心感があるし有用だと思う。でもそれができるようになるにはツールを自作しまくって鍛錬を重ねることが必要だったと感じる。

まあ、実際に作ったアプリケーションがどれだけ活躍するかよりも、自作の試みを通してアプリケーションというものについてちゃんと考えたことで既存のアプリケーションの使い方が変わっていくことの方が重要だなと思う。

自作アプリケーション（デジタルノート系）を色々作ってきたけど、結局今ガッツリ使っているのは日記用に作ったものひとつだけ…。
前にブログに書いた、HyperDatabaseと名付けた自分的に高機能なアプリケーションは、自分の生活の状況によって使い勝手が変わってくるというのが自分でわかっていて、作った時はよかったけど今はちょっと違うかなという感じで休眠している。また使う時が来るだろうとは思う。

読んだ記事の感想とか引用とかをどこに書いたらいいのかって地味にスッキリできていなかったけど、ここでいいのでは！という感じ。
筆者に感想が届く可能性はガタッと落ちるけど、感想を届けたいと強く思ったらその時はTwitterに書けばいいかなと思う。

Twitterを使うにあたって「自分の発信を充実させなきゃ」とはあまり思わないのだが、これは自分のブログやサイトと同様に充実させていきたい感じがある。

実はこれは多くの人に共通するアウトライナーに対する誤解のひとつです。「誤解」が言い過ぎなら「アウトラインという言葉に引っ張られたイメージの偏り」とでも言えばいいでしょうか。「アウトライナーで操作するアウトライン」と「最終的な成果物のアウトライン」を混同しているわけです（むろん「間違い」ではありません）。

アウトライナーという言葉がやっぱり諸悪の根源なのでは…ｺﾞﾆｮｺﾞﾆｮ（アウトライナーという名前を好まない派のつぶやき）
意味と形式の両方を持ってしまう単語は常に両方を引き連れてしまうし、しかもカタカナ語となると「微妙な違いで言い分ける」みたいなことも起こらない。

正直「○○のアウトライン」「△△のアウトライン」という風に呼び分けてもあまり納得できないし、単に「アウトライン」と言われた時にどの意味の何を示しているのか自明でないので、「アウトライン」と呼び続ける限り日本人の混乱がなくなることはなさそう。しかし市民権を得うる日本語が思いつかないのでどうしたらいいかわからない。
せめて形式に「○○型表記」という名前が付けば半分はわかりやすくなるのにって前から思っていますがずっと考えていてもこれぞというのが思いつかない。

アウトライナーを自由に使うための○箇条！みたいで面白かったです。
ポイントそれぞれについてばらばらに「こう考えた方がいいよね」と思い至りはしますが、こういう風に踏まえるべきポイントがまとめられていると見通しが良くなる感じがします。

アウトライナーと仲良くなるためのいくつかのポイント｜Tak. (Word Piece)｜note

一時期GitHubのIssueをメモに使おうとしていたけど、GitHubを開くのがちょっと面倒くさくて続かなかった。
こっちなら続く感じがする。

トピックごとにRSSも取得できるようだが、長いと全文は表示されないな。

拠点をこの掲示板にすることで、情報の濁流を「見過ぎる」ということがなくなる。
本当にやりたいことは何なのかをゆっくり考えられる感じがする。

PCのWebブラウザから見た時にTwitterの表示がめっちゃ崩れることがあるのは一体どこがどうなっているんだろう。

どこの筋肉をどのように鍛えたいのかがわからなければ適切な筋トレメニューが組めないように、自分の知りたいが曖昧なままではそれ以降の知る行為も漠然としてしまいます。
だからまず、自分の「知りたい」を認めましょう。それは存在してもよいのだと受け入れ、それがどんな形をしているのかを見つめましょう。自分の知りたいを肯定するのです。

「自分は○○を知りたいと思っている人間でありたい」みたいな自己像があり、ずっとそれに縛られていたけれど、多分本当に自分が知りたいことは自分が思い描いていた「○○」とは全然違うんですよね。
博覧強記な人は素晴らしいと心から思っている。自分がそうであったらどんなにか素敵だろうと思っている。が、本当に博覧強記になりたいのかと言うと、多分どうでもいい。それが己の実像だということを認めるまでに結構かかっている。
自分が見つめるべきは、「博覧強記」的イメージの領域ではないのだと思う。持っている知識が絶対的に広くて多いことは大事だという思いは持ち続けながらも。
というか、どちらかというと自分のための「知りたい」を追究した先に、博覧強記の道が繋がっているのではないかとも思う。

「知をわたる」とは、さまざまな知を渡り歩くことです。知の散策、知の散歩。ときにそれはショートトリップであったり、長期旅行であったりもするでしょう。不遇にあって知の亡命を行うこともあるかもしれません。ともかくそれは移動することです。移動しながら、そこにある知を味わっていくことです。

知るためにあちこち渡り歩く、というのはメタファーとして珍しいものではないような気がするのに、どうしてか「そうか」と感じた。
「知りに行く」は既にあったイメージなのに、「知の移動」となると「知の！移動！そうか！」という気持ちになる。

Knowledge Walkersにようこそ | Knowledge Walkers

コマンドをコマンドパレットから呼び出せるようにする

package.jsonの編集

予めpackage.jsonにコマンドを書いておく必要がある。

{
  // 前後に色々ある

  "contributes": {
    "commands": [
      {
        "command": "hoge.foo",
        "title": "コマンド実行テスト"
      }
    ],

  // 前後に色々ある
}

extension.tsの記述

その上で、extension.tsのactivate関数の中に以下の形で記述。
なおregisterCommand関数とcommandオブジェクトは>> 2で作ったもの。こうするのが一般的というのではない。

export function activate(context: vscode.ExtensionContext) {
  context.subscriptions.push(registerCommand(command.foo));
}

例に普通書かれているのはこうとか↓

context.subscriptions.push(vscode.commands.registerCommand('hoge.foo', () => { console.log('コマンド実行'); }));

こう↓

const command = 'hoge.foo';
const commandHandler = () => { console.log('コマンド実行'); };
context.subscriptions.push(vscode.commands.registerCommand(command, commandHandler));

コマンド登録

（activate関数の中で実行する）
詳細→Commands | Visual Studio Code Extension API

基本形

// コマンド登録の基本形はこの形
vscode.commands.registerCommand('hoge.foo', () => { console.log('コマンド実行'); });

オブジェクトにまとめてみる

コマンドを沢山作るとなると一箇所で管理できたほうがいい気がする。
Tree Viewでコマンド登録することがあるので、コマンド名を直に打たないで変数にしておいたほうが把握しやすい。

const command = {
  foo: {
    name: 'hoge.foo',
    func() {
      console.log('コマンド実行');
    }
  },
}

vscode.commands.registerCommand(command.foo.name, command.foo.func);

ラッパーを作ってみる

処理を簡単にする関数を作る。

const registerCommand = (data: { name: string, func: () => void }) => vscode.commands.registerCommand(data.name, data.func);

registerCommand(command.foo);

extension.tsの最も基本的な構造

import * as vscode from 'vscode';

// アクティブ化時に実行（実行するものは全てこの中に書く）
export function activate(context: vscode.ExtensionContext) { }

// 無効化時に実行
export function deactivate() { }

VSCode拡張機能開発についての具体的なコードのメモなどはこっちに。
→VSCode拡張機能開発ノート

コードブロックを使えるし具体的なコードのメモも書けるな、と思ったけど、それなら言語やAPIごとにトピックを作った方がわかりやすいか。
どんなことをしたかという日記・日誌はここに書き、具体的なコードのメモ・ノートはそれぞれトピックを立てることにしよう。

コードブロックも使える。

const test = 'test';
console.log(test);

Twitterだと自分のツイートはあっさり流れて行き、アカウントのホームをただ遡っても蓄積を感じられない。
その点、ここは100%自分の投稿で、かつ色々工夫をすることができる。
逆に「流れてしまうからこそ言ってしまえる」みたいなものはここでは書けないが、そもそもそういうのはあんまり書かない方がいいだろう。

問題は書き込みがべらぼうに多くなった時の様子がどうなるかかな。
まあでも一番上や一番下にジャンプできるし、コメント検索機能もあるから困ることはないか。

「のらてつの茶の間」と称して作っていたページも、要するにこういうことがやりたかったような気もする。
茶の間は「テキトーに書きたい」という要求が「更新はPC限定で、GitHubを経由する」という形態とマッチしなかった。（技術不足でそれ以外の形式を作れない）

でもここはスマホから書き込める。今まさにスマホで書いていて、これはいいぞと思っているところ。

データのエクスポートもできるようだ。CSV形式。
これはありがたい。

Mastodonのアカウントを持っていて一応普段から呟いているが、これも「Twitterとは別の、もう一本のタイムライン」という気分で使っていた。それも、ほんとうの意味での「つぶやき」としてのタイムラインと見なしていた。
Twitterの方がぐらぐらなので、TwitterをすっかりやめてしまってMastodonに一本化するという可能性もあるのだが、そうするとまたタイムラインが一本になってしまう。

となると、「つぶやき」としてのタイムラインをここに複数本つくり、「よそ行き」としてのタイムラインをTwitterなりMastodonなりに一本作る、というのがスッキリして良いのではないか。

この「タイムラインを複数作りたい」というのは、Trickleというサービスが解決してくれるかに思われた。
いや、機能としては解決してくれている。が、SNS的性格が残り過ぎていること（リリース当初の様子ではそう感じた）と、アプリ内でしか書き込みにアクセスできないということがネックに感じた。

Markdownが使えるので修飾も自由。メモとしてもノートとしても使える。
後から編集することもできる。