動じないために。
（他の人が決めた型にはまってしまいがちなところを）他ならぬ自分に合った形にする、ということ。
自分仕様でない状態の例
アウトライナー（Dynalist）と仲良くなった
しかし誰かが作ってくれたアプリケーションを使うとなれば、自分が欲しいかどうかとは関係なく、一般的に必要とされることが多いらしい機能が、一般的に使いやすいとされるらしい形で実装されたものを使うことになる。そうなると、一般的に有効らしい使い方をとりあえずしてみるということになりがちである。
この形のアウトライナーを使うとすれば、ふつうどう使うもので、何が有効とされているのか、それをまずチェックしてみてその中から自分に合うものを選んでいこう、というのが当たり前の流れになる。
Backlinks
他の「生き方・心がけ」カテゴリの語句
アウトライナーでどんどん書いていってアウトラインを作ったとする。その内容が自分の中でホットな間はそれで困らないのだが、少し時間が経ってから見返すと、全体のメリハリが一目でわからなくなり内容の認識に手間取ることがある。
HeadingやColor、太字や斜体などを駆使してアウトラインの見た目をリッチにするという手もあるが、あんまりごてごてとやってもかえって把握しづらいし、ノードの操作が硬直的になるからノードの役割がはっきり決まっている場合以外はその手は使いにくい。
CSSの上書きによる全体のスタイルの調整で解決することはできないだろうか。
内容が一目でわからないというのは、単純に言えば「どこからどこまでがどういう一塊かわからない」ということだ。DynalistやWorkflowyのようなプロセス型アウトライナーは全てのノードが同じ見た目をして同じように扱えるのが良いところだが、それゆえに文字とインデントしかヒントがないということになり全体がのっぺり見えることがある。
このことに対して二つの道を考えた。
まずひとつは子項目を含めてノードを枠で囲ってしまうこと。そうすればその枠内が親子関係上一塊であることが一応明確になる。ちょっと設定が雑だがイメージとしては以下のような感じ（サンプルの文言が不自然だがこれは一番最後の例のために用意したもの）。
もうひとつ考えたことは、「メリハリがわからない」という状態を視線誘導で解消するみたいなものだ。具体的には、各ノードの本文を文字列のサイズ依存で枠で囲み、行というより粒状の見た目にしてみる。
.Node-renderedContent {
outline: solid 1px #bbb;
width: fit-content;
padding-right: 6px;
padding-left: 2px;
max-width: 100%;
border-radius: 3px;
}
実際、何ヶ月か前に書いてそのままになっていたアウトラインが読みにくく感じて手を加えるのを億劫に思っていたが、このようにスタイルを変えたら随分認識が楽になって作業が進んだ。
しばらく続けるとまた何か思うところが出てくるかも知れないが、とりあえずはこのまま使ってみようかと思う。
最近、Dynalistでノードのリンクを活用するようになった。
Dynalistでは全てのノードにURLが存在し、別のノードにそのURLを貼るとノード間で紐づけられバックリンクも表示してくれる。貼り方はURLだけでもいいしMarkdown形式でもいい。URLのみ貼った場合は自動的にリンク先のノードの本文が表示されるようになっている。
また、行頭または半角スペースの後でダブルブラケットを入力するとリンクのサジェストが表示される。文字を打っていくと候補が絞られていく。範囲はアーカイブしていない全ファイルで、編集中のファイル内のノードが優先されるが他のファイルのノードも候補に並ぶ。 候補のノードがどこに存在するものかというのは、パンくずリストも一緒に表示されるので判別できる。
なお、サジェストの絞り込みに反映されるのは本文部分のみで、ノート欄の内容は候補のピックアップに関係しない。
サジェストとバックリンク表示機能があるわけなので、Dynalistをネットワーク型のツールとして扱うことも機能的には可能である。しかしながら、推測するにノードリンクを多用している人はそういないような気がしている。なぜなら、普通に使っていたらノードのリンクをあちこち張り巡らしたくなるような使い方にはおそらくならないからだ。
今Dynalistを使っている人は実際にダブルブラケットと何か文字を入力してみてほしい。そうでない人もちょっと想像しただけでわかると思うが、存在している全てのノードが対象になってしまうとなると、サジェストはおそろしく雑然としたものになるだろう。ノードごとに粒度はばらばらだし、そもそもアウトライナーというのは文脈の可視化やコントロールのためのエディタ、つまり文脈エディタとでも言うべきものであり、周辺のノードがわからなければそのノードの意味は見えてこない場合が多い。
ノードのリンクを貼りたい、つまり「あのノード」と指し示したいと思うようなノードというのはそう多くはない。自分の中でそういう重さのノードかもっと軽いノードかというイメージを持っていても、ツールの側はそれを察してくれはしないので、気を使わなければサジェスト候補は各々の文脈でしか意味を持たない細かいノードで埋め尽くされ、まともに機能しない。
じゃあどうするか。気を使って利用すればいいのである。ノードリンクを活用することを前提としたアウトラインづくりを考えてみる。
まずは普通に自由に書いていく。例えばこんなアウトラインができたとしよう。（例は昔Scrapboxに書いた内容を一部変えたもの。）
ノードリンクのサジェストがどうなってほしいかを念頭にこのように整理する癖をつけると、アウトラインの各ノードはそれ単体で明瞭な意味を示した、謂わばアトミックなものになる。そうすると結局今まで何を考えてどんな結論を出したのかもわかりやすい。ノードひとつひとつが財産になっていく。
考えた結果はちゃんとまとめよう、という心がけを持とうとしても、どういう状態になっていればOKなのかがはっきりしていなければ努め続けるのは難しい。しかし「サジェストに出てきた時に納得できる粒度」という尺度があれば、それを満たしていればまとめは完了したと言えるし、そうなっていないものにはもやもやと不快感を覚えるのでもうちょっとどうにかしようと思うことができる。心がけの力ではなく、収まりの悪さへの苛立ちによって整理を進めていくわけである。
なお、冒頭に書いたようにサジェストの範囲はアーカイブしていないファイルに限られる。アウトライナーを使って扱いたい全ての内容についてこのような整理を目指す必要は全くなく、ノードリンクを使いたい領域以外はアーカイブしてしまえばいい。アーカイブ設定は全体検索にも影響が出ることには注意が必要だが、個人的には全体を横断して検索したいことはほとんどないのでアーカイブ設定で支障を感じたことはない。設定のオンオフは簡単なので必要が生じたら解除すればいいだろう。
リンクの貼り方にはURLそのままとMarkdown形式とがあると最初に書いた。URLだけを貼った場合には、リンク先の内容を変更した場合にそれが常に表示に反映されるという利点がある。そして同じ文面をあちこちに書くことにならないので、検索やサジェストのノイズにもならない。
となれば、Markdown形式は表示を意図的に変更したい場合に使えばよいと言える。リンク元が何十字かの文になっていたとしても、それを数文字で示して文中に組み込むということもできる。その都度エイリアスを生み出せるようなものだ。
ネットワーク型ツールではリンク元のタイトルそのままでしか扱えないことも多く、その場合文中に馴染ませるためにタイトル付けに工夫が必要になったりするが、その都度適当に言い表せばいいとなればタイトル付けに悩むこともない。アウトラインの各ノードにタイトルは不要である。
ただしこの場合、どのノードを指してその表現にしているのかが自分でわからなくなることもある。リンクをクリックすれば確認できるが、いちいち飛ばなくてもわかったほうが便利ではある。この課題について、私はChrome拡張機能を作りスクリプトを走らせてマウスオーバーでリンク元の本文とパンくずリストを表示できるようにしているのだが、その話は別の機会にするかもしれない（しないかもしれない）。
ノードリンクは便利な機能だが、ひとつ問題を挙げるならば、デフォルトの状態だとノードリンクはちょっと見づらいということがある。
.node-inline-item:not(.node-inline-image) {
display: inline;
border: unset;
background-color: unset;
color: #384d98;
font-size: inherit !important;
text-overflow: unset !important;
white-space: normal !important;
text-decoration: underline dotted;
&:before {
display: none;
}
}
こうすると本文中に混ざっていても違和感はない。既出の概念についてはリンクになっていた方が嬉しいという感覚も生まれ、一層リンクを活用したくなる。
CSS書き換えはDynalist自体に備わっている機能ではなく裏技的なものである。Webブラウザでしか実行できないという難点もあるが、見た目を変えるだけで使用感が劇的に向上するということはよくあるので、ツールの機能をフル活用するために試してみる価値はある。（書き方を細かく解説するのはちょっと手間がかかりすぎるので割愛する。）
最後に。重大な注意点として、ノードを別のファイルにMove to...で移動してしまうとそこでリンクが切れるということがある。ファイル一覧にドラッグして移動した場合には更新されるようだが、ありとあらゆるパターンを試して確認してはいない。動かし方によってリンクの追跡がされたりされなかったりということになるので、ファイルの構成に迷っている間はあまり多用しない方がよいかもしれない。
Dynalistはアウトライナーだが、私にとってはデータベースである。アウトライナーとして使えるデータベース、くらいの言い方をしてもいいかもしれない。
もちろん普通にWebブラウザやスマホアプリで操作する分にはただの（と言うのもおかしいが）アウトライナーである。Dynalistがデータベースであるというのは、アウトラインの形をトップダウンできちっと整備してデータベースとして使うというような意味ではない。発想としてはむしろ全く逆である。
DynalistはAPIを提供しており、プログラムを通じて自分のデータを参照したり編集したりすることができる。あるファイルのノード情報を取得する場合、そのファイルに含まれるノードがフラットな配列として取り出される。以下の型のオブジェクトがひとつの容れ物にわっと入っている状態である。
{
id: string,
content: string, // 本文
note: string, // ノート欄
checked?: boolean,
checkbox?: boolean,
color?: number, // 0~6
heading?: number, // 0~3
created: number,
modified: number,
collapsed?: boolean,
children: string[], // idの配列
}
アウトライン構造はchildrenプロパティに子ノードのidが列挙されることで表現されている。なのでこのidに一致するデータを探せばそれが子ノードだと分かる。しかしデータ自体はアウトライン構造にはなっていないわけである。ルート直下のノードも10層インデントしているノードもデータ上は隣に並ぶ。
つまり、そのノードがどこにあろうが関係なく扱えるということになる。例えば色を赤に設定したものに何らかの意味付けをするとしたら、それぞれてんでばらばらな深さに存在していてもcolorプロパティによって同じ種類のデータとしてまとめて取り出せる。色なり見出しなりノート欄なりを使ってそのノードの種類を自分で定義すれば、ノードの種類を示すためにアウトライン構造を使う必要はなくなる。
アプリケーション上のビューでは全てのノードがアウトライン構造のどこかに位置づけられる必要があっても、それぞれのノードのデータはアウトライン構造とは無関係に活用することが可能なわけである。
このことにより私の中でDynalistの使用感は大きく変化した。APIが使えなかった頃は分類的な視点でアウトライン構造を用いていたが、そのように形式的なアウトラインを作る必要がないとなれば、完全に「気分」で自由にノードを配置できる。これとこれが近い方が便利だ、その方が気分が良い、そういう理由で配置することに違和感を覚えなくなった。
もちろんカオスな方が良いということではない。自分が納得する基準で適切に配置させられるのがアウトライナーを使う理由なのだから、自分なりに整えていくことにはなる。そこに自分の気持ちとは無関係な形式的構造を混入させずに済むというのがAPI活用のポイントである。
ここまでの話だと「データベース」感は薄い気がするので、データベースとしての活用の話をもう少し具体的にする必要があるだろう。単に特定の条件で一度にピックアップできるというだけなら検索機能を使えば済んでしまう。
このサイトの記事はDynalistに書いてAPIを通じてサイト用のデータを生成している、という話は既に何度か書いている。それはつまり、Dynalistのひとつのファイルが記事のデータベースになっているということだ。
特定の書式（例えば色が赤でノート欄に日時が書いてあるなど）に従って書いているノードをタイトル行、その子項目を本文と解釈することで、それをひとまとまりの記事データとみなす。
インターネットを使っていると、日々数多のページにアクセスすることになる。有用なものがあればリンクを保存しておきたいと思う。便利なツールのURL、興味深い記事のURL、誰かのサイトのURL、後でチェックしたいもののURL、等々、さまざまな種類や状態の情報を保存しておくことになる。
全てをブラウザのブックマークに入れるとごちゃつきに耐えられなくなるのだが、これらを如何にもなデータベースで管理するとなると、保存の気軽さや頻度の多さとデータベースというものの仰々しさが大抵見合わない。とても手入れはしていられないし、テーブル形式のぴしっとした感じの割にそれほど見やすいわけでもなかったりする。
とりあえずDynalistにファイルをひとつ作り、そこに全部突っ込んでしまうことにした。最初は「検索すればいい」というつもりでDynalistを選んだのだが、ある時「ほかにビューワを作ってDynalistをデータベースとして使えばいいのではないか」と思いついた。作ったブックマークのビューワがこれ。（画像の内容はもちろんごく一部。）
ここまではDynalist上で書き込んだ情報を取得・解釈して活用することについて記してきた。しかしDynalist APIでできることは情報の取得だけではない。データの編集も可能である。
不可逆的な操作になるのであまり軽率に試していいものではないが、APIを使えばファイルやフォルダ、ノードの作成・編集・削除ができる。Dynalistを開いていなくてもDynalistのデータにアクセスして弄れるのだ。
例えば、あるファイルの中のノードについて一括で置換したい何かがあるという時に、普通はひとつひとつ手作業でやるしかない気がするが、APIを使えばプログラムで処理できる。ルールを前もってきっちり決めなくても後で軌道修正できることになり、大規模な何かをやるにしてもあまり構えずにやれるようになる。
あるいは、何かのページを見ていてリンクを保存したいとなった時に、自作のChrome拡張機能にDynalist APIを使った処理を実装しておけば右クリックメニューから直接Dynalistの特定の場所に送信するみたいなこともできる。私はブックマーク、記事の本文、Twitter（X）のポスト、YouTubeの情報などをそれぞれ然るべき場所に送れるようにしている。
こうするといよいよDynalistがデータベースらしくなってくる。Dynalist上での操作より外から操作する方が多いファイルというのもあり得るし、アウトラインの形で見たい時だけDynalistを開くという使い方も考えられる。アウトラインの表示を自分で作るのは割と面倒くさいので、データのアウトライン化を簡単に実現してくれる手段としてDynalistを利用するわけである。
このようにしばしばアウトライナーとしての在り方から逸脱した使い方をしているが、もちろんDynalistのファイルおよびノードを全てデータベースとみなして使っているというわけではない。普通のアウトライナーとしてアウトラインを考えることにも使っているし、その方が当たり前に多い。しかしそれらはいつでもデータベースとして解釈して活用することが可能である。
Dynalistの見出し、色、ノート欄は最初の頃はさっぱり上手く使えなかった。検索での絞り込みにそれらを使うことはできるが、結局のところ当時の自分にとっては見た目の問題でしかなかったからだ。何色をどういう意味で使うかに必然性はないし、6色もあるが6色しかないということも活用を難しくしている。
しかしながら、プログラムでの判定にそれらを活用できるとなると、急にそれらが便利なものに変身した。全てをノードの本文部分に書かなくてはならないとなれば、私自身には必要のない機械用のデータが場所を取って見ていて嫌になってくる。なのでメタデータを付与できる手段がほかに色々あるのはとてもありがたいことなのだ。
今となっては色設定とノート欄は必要不可欠である。色付けに必然性が生まれたことによって使うタイミングに迷うことはなくなり、また「使いこなせてない」という気分もなくなった。
アウトライナーは全ての情報をアウトライン上に位置づける。その特徴は私たちの理解を助けてくれる一方で、情報が位置に縛られるという欠点にもなる。しかしDynalistには別の切り口で情報を扱う手立てがあり、工夫次第でデータを如何ようにも活用することができる。
その意味で、私はDynalistを単なるアウトライナーではなく「アウトライン型データベース」だなと思って使っている。
プログラミングを始めた頃はアウトラインの位置を基準にしたブックマークビューワを作っていたが、手入れが面倒になってしまった。 ↩︎
うちあわせCastを拝聴していて、B6サイズがちょうどいいのに汎用的なバインダーがないんだよね、というようなお話があった。
私もB6は絶妙なサイズだと思う。普段A5を使っているけれど本当に手に馴染むのはB6だし、今使っているバイブルサイズのシステム手帳は外側のサイズがちょうどB6なのでなんとなく触っていて好ましい。（以前にも書いたことがある→「システム手帳×A6紙」というプチ革命）
中身がB6紙のバインダーとなると、外側はA5紙くらいのサイズになるだろうか。A5バインダーの横幅の広さと比べればそれでもかなり細身に感じられる気はする。
B6のリフィルとかバインダーって確かに見たことないよなあ……と考えていてふと思いついた。A5バインダーを切っちゃえばいいのではないか？
あまり立派なのは勿体ないし加工も難しいのでやめておくとして、百均に売っているようなややペラっとしたバインダーならカットしようと思えばできる。というか、かなり前の話だが『「超」整理法』に感化されて「超」整理手帳の真似事をしようとして、Z式バインダーを切って使っていたことがある。A4を四つ折りにしたのがちょうどぴったりになるように上も横も切り落としてしまったのだ（留め具で挟むための幅があるので実際の幅は三つ折りに近い）。その試み自体はまあお遊びのようなもので実用的というわけではなかったが、面白いことをやってみた感はあった。
話を戻そう。A5バインダーを流用してみるとして、B6紙に自分で穴を開ける場合、上下の端は微妙なことになる。まず中央揃えで穴を開けた場合（綴じ具側の方に注目）。
個人的には今現在用途が見つからないのと、リフィルの類の扱いには慎重になっていることもあって実践の予定はないけれども、いざとなればやれなくもないなという気づきは少し頭を柔軟にしてくれた気がする。
ここのところずっと使っていなかったObsidianを久々に使うことにした。
前に整えたCSSは今と趣味が合わなくなってしまったのでデフォルト状態で始めることにしたのだが、そのままだとなんとなく「気楽に書けない」感じがした。
なんでだろうとしばらく考えていてひとつ気がついたのは、左右の余白が大き過ぎると「読むもの」という感覚になってしまうということだ。普段使っているテキストエディタなどは当然上下左右に大きな余白はない。
あとは見出しの文字サイズ。メモとしては見出しというのはアウトラインを示すに過ぎず、視覚的にそんなに「見出しです！！！！！」みたいな主張はしてこなくていい。異なるレベルの見出しの文字サイズが近すぎると階層が分からなくなるというのはあるので、大きさの差を縮める代わりに色で区別することにする。
そういったことを反映したスタイルを整えてみた。
Denoを使って、指定したディレクトリ内に存在するプレーンテキストのファイル（txt,md,js,css,html,...）とMicrosoftWordのファイル（docx）を自作ツールにまとめて取り込むスクリプトを作った。
昨日、短文投稿サービスを彷徨うという記事を投稿した。その中で、Twitterには「自分の内面を自分で引き出す」という効用を感じているが、しかしそれはTwitterでなければならないものではないかもしれない、ということを考えた。
「自分の内面を自分で引き出す」ということをTwitterでやっていた理由は以下のとおり。
これは人に見せない日記でやっても良いはずで、実際日記によって同様の効果を得ている人はきっとたくさんいるのだが、私自身は100%自分のために何かをするということが苦手なので、「書くからには読んだ人が意味をきちんと理解できるようにしよう」という少しの利他性を動力にして文章を綴っている。長文にするとなると文章全体の組み立てを考えなくてはならないが（つまり利他性の発揮にエネルギーを費やしすぎる）、Twitterならとりあえず140字単位で意味が通じれば良いので文章化しやすい。
そしてこれをやる場はTwitterでない方がいいかもしれない理由は以下のとおり。
（自分の内面を引き出すための）自分の発信が生んでいるのはまた自分の発信であり、他者の受信・発信を通して自分の受信が豊かになっていくというサイクルを作り出していないのだ。
ではどこでやるべきかという話だが、昨日投稿した時点では解決策というのは全然見出せていなかった。しかしその後別な目的で探していたものによって図らずもスッキリ解決してしまった。
ずばり「掲示板」である。そして解決方法とは言うなれば「ひとり掲示板」だ。
なぜ掲示板を探していたかというのはまた改めて書こうと思っているので割愛するけれども、ともかくあれこれ無料掲示板サービスを見ていて、zawazawaというサービスに行き着いた。調べてみるまで存在を知らなかったのだが、WIKIWIKI運営が提供している「掲示板形式のWIKI」とのことだ。見た感じWikiだという印象は薄いが各スレッド（＝「トピック」）の最初にMarkdownで記述を作れるので、確かにWikiなのかもと思う。記述部分を充実させればWikiらしいWikiにもなるし、そこはあっさりでコメント欄が目立つようにすれば掲示板らしい掲示板になる、という感じだろう。基本的にはWIKIWIKIの補助的な位置づけだろうかと思う。
そしてzawazawaは権限の付与を細かく設定できる。URLを知っている人だけがアクセスでき、かつ自分だけが編集できるようにすれば、ひとり掲示板の完成である。じゃじゃーん。
機能もさることながら、見た目が明るくすっきりしていて綺麗なのが良い。使いたいという感じがする。zawazawaに慣れている人が見たら変に思われるかもしれないが、私自身は昨日初めて見たサービスなので違和感はない（違和感を持ちようがないというか）。
で、これは「のらてつの雑記帳」という板（＝「グループ」）の中に複数のトピックが存在していて、トピックを開けば私の書き込み（＝「コメント」）がずらっと並ぶ状態になっている。トピックはこのページの下の方、または右の「最新トピック」の欄からアクセスできる。
どんどん下方向に書き込むことになるのでTwitterとは向きが逆だが、書き込む感覚としては似たような感じで書いていける。zawazawaはアイコンが丁度いいサイズで表示されるのもTwitter感があって良い。コメントはツリー表示とタイムライン表示を切り替えられるというのも便利。なおMarkdownが使えるので結構いろいろなことができる。GitHub Issuesと同じような感じ。データはCSVでエクスポートできるようなので、もし飽きてしまっても安心。
これを勝手にTwitter的なものとして使うとして、タイムラインをトピック単位で分けられるというのが非常に便利に感じる。全てを細かく分類する必要はないが、明らかに継続的に語っている特定のテーマがあるならそれは分けられた方が望ましい。前々からTwitterにそういう機能があったら良いのにと思っていたが、まあ追加はされないだろうなと諦めてきたことだ。コミュニティ機能は「テーマごとのタイムラインに人が集まる」機能だが（それはそれで良いのだが）、私が求めていたのは「人それぞれにタイムラインを複数持てる」機能だった。
ちなみに各トピックページをRSSリーダーに読み込んでもらうとコメント単位でフィードを取得できる模様。ただ、最初の百数十字分のみで書式も反映されないので、長く書いていたりMarkdownをフル活用していたりするコメントはRSSリーダーだけだと不十分という感じ。
この掲示板にせっせと一人で書き込んでいく。読む人もいるかもしれないと思いつつ、自分自身が必要とすることを書く。誰かに読まれてもいいように最低限文章を整えておこうという気持ちを動力にして、未来の自分が助かるようにきちんと言葉にしておくということだ。
他の誰かとの間に何かの反応を起こしたいならTwitterなりMastodonなり他のSNSなりを使うとして、自分がどんどん書いていければそれでいいものはここに書く。書きやすさを理由にして100%自分のためのものもTwitterやMastodonに流していたりしたわけだが、正直他の人が各々リアルタイムに読みたいと思っているタイムラインにそういうのを流し込んでしまうことに気が引けるところがあったので（仮に読みたいと思ってくれている人がいたとしても）、書きやすさはそのままに気後れする要素を除いたこの場所はとてもやりやすい。
この場所を拠点にしていると、他の人の発信はリアルタイムでは目に入らない。気が向いたらTwitterやMastodonやRSSリーダーを見に行って、溜まっていた分を流し読んで気が済んだらここに戻ってくる。まだ昨日の今日なのでそういうスタイルで固まるかどうかはわからないが、このままこのひとり掲示板を続けるならそういう形で落ち着きそうな感じがする。
現時点では色々と良いことがありそうな感触だが、使っていくうちに弱点を見つけたりもするかもしれない。とりあえずしばらく続けてみようかと思う。
ここのところ、未だかつてなくScrapboxを盛んに使っている。といっても非公開の個人プロジェクトの話だが、きっかけがあって劇的に使いやすくなった。
これまでずっとページのタイトルの付け方に納得がいっていなかった。全然Scrapboxが悪いとかではなく（そりゃそう）、自分がうまくやれないでいただけの話である。
特にうまくできなかったのが、Web記事などの中の文章をScrapboxに保管しようと思った時のページタイトルである。記事のタイトルにすべきか、引用した文章そのものにするか、内容の要旨にするか。記事タイトルは必ずしも保存したい内容に沿っているとは限らないし、文章そのものというのもその文章が名言的なものでなければあまり有効でない。一時期は「～～は……である（要旨）」みたいな書き方をしたりしていたが、なんだか全然しっくりこない。
単に「～～は……である」だけでいいのでは、というのはもちろんあり得ることなのだが、自分が思いついた発想と誰かの言葉から得たものとを区別したいという気持ちがある。なので何かしらのルールでタイトルを書き分けたかったのだが、その目的に於いては記号や絵文字を付けると見た目に煩わしく感じてしまう。どうしたものか。
なかなか答えが出ないままでいたのだが、先日、ふとあることを閃いた。ページタイトルをスレタイみたいにすればいいのではないか？
スレタイと言っても色々あるが、イメージしているのはニコニコ動画でもよく見る隅付き括弧で挟むタイプのものだ。匿名掲示板はそんなに見に行ったことはないのだが、本題に対してサブタイトルが二つに分かれて左右についている形式を最初に見た時にはなんだかとても面白く感じたのを覚えている。以下スレタイと言ったらこの形のことを指しているということにする（この形式に何か名称があるのかわからなかったため）。
Scrapboxのページタイトルとしては、例えばこんな感じのページを作るようになった。いずれも実際に作ってあるページである。
パターンはいくつかある。整理すれば「【感想】～【出典・対象等】」「【分類】～【状態】」の形が多いだろう。如何にもスレタイっぽくなる場合もあるが、別に如何にもなスレタイっぽくしたいわけではないので、ただ日付を入れたり絵文字や顔文字を入れたりすることもある。例に挙げたのはいずれも両端に隅付き括弧をつけているパターンだが、頭の方だけつけているページもある。
で、この場合、【名文】とか【なるほど】というような言葉を頭につけたものは明らかに自分以外の誰かの発信が元だとわかる。逆に【💡Scrapbox】は「💡」で閃きを示しており、自分が思いついたことだとわかる。自分発のものと他人発のものの区別がしたいということはこれでクリアである。
前々から、頭の方に隅付き括弧で種別を添えることはあった。例えば「【JavaScript】指定した要素の位置までスクロールする方法」という感じ。しかしスレタイのイメージは浮かんでいなかったので、感想をそこに書いてしまうという発想はなかった。
この形式の良いところは、なんといっても情報量が増えることだ。一文に領域が三つでき、それぞれメインとサブ①、サブ②であることが明らかである。且つ、隅付き括弧同士は繋がっている可能性があるが、真ん中の内容部分とは少し断絶があるという独特のニュアンスを持っている。そしてメインが何であるかは明確でありながら、両脇も強調している感があるのが面白い。
例えば「【名文】真にカルチベートされた人間になれ【太宰治】」というタイトルについて考えてみる。この一文が示しているのは「『真にカルチベートされた人間になれ』というメッセージを含む太宰治の名文」であることがほぼ明らかである。「太宰治の名文」という要素が、【名文】【太宰治】に分割されている（【太宰治】～【名文】の順でもいい）。ちなみに、「太宰治のこと」ではなく「太宰治が書いたもの」であることを明示したいという理由で【名文】を敢えてつけている。
これが「【太宰治の名文】真にカルチベートされた人間になれ」とか「真にカルチベートされた人間になれ【太宰治の名文】」とかいう形だと、サブの部分が重たくなり、なんだかバランスが悪い。一方、むしろ情報を足して「【太宰治の名文】真にカルチベートされた人間になれ【正義と微笑】」とするとまた見やすさを取り戻す。天秤のように左右に重さが乗っていればサブ部分がある程度長くても違和感がない。
とはいえ短く済むならその方がスッキリする。作品名を入れたら必然的に「書いたもの」の話なので「の名文」はカットしてもいいだろう。比較しやすいように列挙してみよう。
ブログで紹介するみたいなことなら一番目より五番目の方が相応しく思える。ただ、自分の個人的なメモとしては、どの作品で書かれたものかより「太宰治がこんな名文を残している」という感慨の方が重要なので、一番目の方が適当なのである。
また、「真にカルチベートされた人間になれ」というのは実際に『正義と微笑』の中にある表現そのままだが、この部分が多少要約的になっていてもよい。例えば「【名文】学問は人格をカルチベートする【太宰治】」でもいい。これは私の中にある「スレタイには要旨が書かれているものだ」という前提の助けを借りている。そのまま引用しているかもしれないし、適宜縮めて要約しているかもしれないが、ともかくそのような内容で太宰治が残した名文がある、という意味合いのタイトルになっている。わざわざ「（要旨）」と断らなくても気にならなくなった。
個人的な感覚の話だが（それは全面そうではあるが）、絵文字が単体で文にくっついた状態というのが私は好きでないようだ。例えば、「【💡Scrapbox】ページタイトルはスレタイ方式にする【実践】」というタイトルを例に挙げたが、前は「💡Scrapboxのページタイトルはスレタイ方式にする」と書いていた。これがなんだかとても気に入らない。しかし絵文字が持つニュアンス自体は好きなので、絵文字を使えたらいいという気持ちはある。絵文字の情報量を優先して、ずっと気に入らなさを我慢していた。
ところが、「【💡】Scrapboxのページタイトルはスレタイ方式にする」と書いたところ、不思議と気に入らなさがなくなった。多分、絵文字部分が本体の一部のようであったのが、隅付き括弧で本体から明確に分離されたというのがその理由だろう。
最終的に、左の隅付き括弧に分類を示す言葉と合わせて入れることにした。【Scrapbox】だけなら「Scrapboxに関する一般的な知見や仕様」のニュアンスがあり、【💡Scrapbox】なら「Scrapboxを利用するにあたっての自分のアイデア」という意味になり、他には【💭Scrapbox】なら「Scrapboxの使い方として今考えていること」という意味がある。なお【💡】だけなら生活に関わる閃きなどになる。
このスレタイ風タイトルは、名詞・フレーズのページとそうでないページを区別する役割も担っている（後者のみをスレタイ風にしている）。このページはWiki的に使いたいページで、こっちはスレッド的な使い方のページだ、というのがひと目でわかる。私にとってこれは結構重要なことだ。
両端に隅付き括弧を配置する形式を好ましく感じるかどうかは多分人それぞれだろうし、そもそもページタイトルにそんなに細かくニュアンスを込めたいかというのも個々人でバラバラだろうと思うが、私の場合は自分の微妙な要求に答えてくれる形式をこれに見出して怒涛のようにページを作るようになった。スレタイのあの形を前から面白いと思っていたので、やっていて楽しい。Scrapboxライフは劇的に豊かになった。
いよいよ具体的に作ったツールの話がメインになります。
今回は少し前の記事（前日譚②～JavaScriptを書けると何が嬉しいの？～（NTA-DIY：前日譚②～JavaScriptを書けると何が嬉しいの？～））で触れたブックマーク管理ツールの話です。
管理と言っても、まだツール上でデータを編集するわけではありません。とりあえずCSVファイルにデータを用意しておいて、それを使っていい感じの見た目を作ろう、というものです。ツールというよりはビューワと言った方が表現としては合っているかもしれません。
実際に作ったもの（のコードを今の書き方で綺麗にしたもの）をサンプルとして見れるようにしてみました。
tag,title,url,favicon,description
SNS,Twitter（@Foam_Crab）,https://twitter.com/Foam_Crab,,
Writing,Noratetsu Lab,https://noratetsu.blogspot.com/,,メインのブログ
Scrapbox,Noratetsu's Room（のらてつ研究所）,https://scrapbox.io/noratetsu/,https://gyazo.com/8e76071e5281e7396c84c83d32554939/thumb/1000,
必須なのは「tag」「title」「url」です。どこに配置するかを「tag」で決めています。どのtagがどのカラムになるかはJavaScriptのコード内で指定しています。
「favicon」はアイコンとして表示したい画像のURLです。省略すればデフォルトのfaviconを「http://www.google.com/s2/favicons?domain=${url}」で取得して表示します。
「description」はそのページについてのメモです。どういうサイトだったか、何でログインするんだったか、といった情報を必要に応じて書いておきます。Webブラウザのブックマークは基本的にメモ欄がありませんが、メモできると「なんだったっけ」と考えるロスが減ります。
なぜこのようなツールを作ったかというと、個人的にWebブラウザのブックマーク機能のあのリスト形式が好きじゃないからです。具体的にどこがどう嫌かというのはズバッと言語化できないのですが（明確な理由があるものではないのだと思います）、嫌だという気持ちははっきりしていて、そのせいでブックマークをうまく使えない状態が長きにわたり続いていました。
フォルダ整理という形式がうまくいかなさの原因かなと思ったこともありましたが、多分問題はそこではなく、どういう見た目をしているかなのだと思います。早い話が、楽しいか楽しくないかの問題です。
ブックマーク機能を提供するサービスや拡張機能というのも世の中には色々ありますが、そういうのを試してみると、機能が大仰過ぎて面倒な気持ちがまさってしまいました。簡単さの面ではブラウザのブックマーク程度で良いのです。サッと見れるのが大事です。
ではどういうビューなら自分が納得するかと考えてみても、それは自明のことではなく、考え出すのにはそれなりに苦労しました。最終的に冒頭で貼ったサンプルのようになったのですが、多分自分以外の人には中途半端なデザインに見えるだろうと思います。私自身、理屈で考えていたらもっと違う形にしようとしたのではないかと思います。ですが、これでいいのです。イケてるかどうかは知りませんが、「認識するのが楽」なのがこの形なのです。
このブックマーク管理ツールはJavaScriptのありがたみを理解する上で大きな一歩となりました。そして当時「JavaScriptでできたら嬉しいこと」として唯一具体的に思い描けていたのがこの「CSVを元にHTML要素を作る」という処理です。
最初、このツール（というかビューワ）は内容を全部HTMLにベタ打ちして作っていました。一応ブックマークレットを使い、登録したいページで実行すれば必要なタグを全部つけた状態で一発コピーできるようにしていましたが、ただ貼り付けるのは簡単でも、並べ替えなどの操作は非常に面倒でした。そこで「データはデータで作って、自動でHTML化したい」という願望が生まれ、「そういうのこそJavaScriptってやつでできるんじゃあないのか」となったのです。
願望としてあったのはそれだけだったので、これを実現した時点でゴールに到達してしまったようなものでした。ノートテイキングアプリを自分で作ってしまう、なんてことはこの時点ではそれほど考えていなかったと思います。そこまでできると思っていなかったからです。何しろ何をどうしたらアプリケーションの体を成すのかわからなかったのです。
ですが、このビューワを作ったことにより、JavaScriptとはつまり何ができるものなのかということをイメージできるようになりました。これができるってことはじゃああれもできるんじゃないか、とアイデアが浮かぶようになり、それができたらじゃあこれ、これができたらじゃああれ、と飛び石を渡っているうちに可能性がどんどん広がっていったわけです。
コードの説明も書こうかと思いましたが、独学の我流でありオーソドックスな書き方になっているのかわからないのと、毎度言及していると大変過ぎて更新が捗らなくなることから、コードの詳細については説明を省略します。（質問を受けたら答えます）
コードは右クリック→「ページのソースを表示」を選択すると読めます。
ツールの挙動としては当時（つまり勉強開始二十日目くらい）から変えていませんが、コーディングは結構違っています。当時のコードを今見ると、知っているメソッド・書き方だけで頑張って作っているなと思いますが、工夫の積み重ねとは裏腹に、読むにあたっては何がなんだかわからないので、そのまま公開しない方が良いだろうと判断しました。
なおブックマークの管理のために別途CSVを編集するというのはあまり自然な流れではないので、半年くらい後に違うやり方に変えました。具体的には……とここで書こうかと思いましたが、それはいずれ記事にするのでお楽しみにということにします。
ところで、公開したサンプルは単にツールの様子を見せるために作ったものですが、個人サイトの一コンテンツとして置いておいてもいいかもと思いました。よく使う便利ツールのリンクなどを充実させると面白いかもしれないですね。
昨年の一月末からJavaScriptを勉強し始め、今日でちょうど丸一年になる。私の人生に於けるプログラミング元年だった。
スタート時は一年の間に「何か動くもの」を作れたらいいという気でいたが、実際に一年経ってみると「自分にとって理想的なツール」に迫るところまで来れた。一年間の集大成として今使っている自作デジタルノートツールについて書くことにする。
先日の記事（雑なメモは雑に書かれなければならない）にもスクリーンショットを一枚貼ったけれども、機能のごく一部の部分だけなので、ちゃんと記事にしておこうと思う。
と言っても、言葉で説明するのは到底無理なレベルであれこれ細かい挙動を搭載しているので、処理がどうなっているかより主にどの位置にどんな情報があるのかというレイアウトの話になる。
全体像を先に示しておくと、以下の五つのビューモードを持つツールになっている。
左にとりあえず書く場所としてのアウトラインがある（「Input Outline」というタイトルのデータがあり、それを指定してアウトラインデータを表示させている形）。中央上部にはデイリーアウトラインの領域があり、日毎に作られるページのアウトラインデータを表示している（直近十日分）。中央下部はカテゴリデータに「Hot」と記述してあるページのアウトラインデータを並べている。
それぞれタイトルをクリックすればページの詳細画面が開く。また各行がフォーカスされる度に右上のメタデータ欄にページの情報が一部取得される。本文を確認することもできる。
右には全ページのアウトラインデータの中で特定の属性を設定されたノードを取得して表示する欄がある。アウトラインは各行に予め設定した任意の属性を選択して付与することができ、そのデータから抽出している。
細かい機能は他に色々あるが割愛するとして、この画面構成によって今現在把握しておきたいことを一覧できるように試みているというのがアウトラインモードの特徴である。
データベースモードというのはつまり全データを管理する場所ということで、ページビュー、カードビュー、テーブルビューの三つの画面がある。
ページビュー
また、右カラムにある「データベース化」のチェックとその下の「Option Key」の部分によって、後述のテーブルビューにデータベースとして表示することができる。詳しくはテーブルビューの項で。
更にクイズ機能もあって、各ページに一問一答を設定でき、全ページのクイズをまとめて表示して解くこともできたりするが、それは本格的におまけである。（おまけだが割と重要。）
カードビュー
テーブルビュー
お試し
今回のツールのサンプルはHyperDatabaseにあるリンクで試せるようにした。
注意書き
既知の設定ミス（後から気がついた）
ちなみに、前に貼ったスクリーンショット内では「Hyper Outliner」ということにしていたが、アウトライナーの範疇は大きく逸脱しているので仮称として「HyperDatabase」ということにした（HyperText的な意味なので空白はなくした）。まあ名前はなんでもよくて、私自身はコードネーム的に「hyper」と呼んでいる。
色々な機能を搭載しているのだが、これらは今までばらばらにツールとして作っていたようなもので、今回それを統合した形だ。それぞれ思いついた時にはその機能を中心機能にしたツールを頑張って作るということしかできなかったが、今回はそれらを適切に組み合わせてデザインするというところまで行き着いた。
今現在、デジタルノートツールはScrapboxとDynalistとこのHyperDatabaseの三つを使っている。なおHyperDatabaseにはScrapboxのjsonデータを一発で取り込むことができ、Dynalistのopmlデータもやろうと思えば取り込む機能を作ることができるので、ツールを使い分けてはいるが最終的な可能性としてデータは統合された気分で使っている。
頑張ってツールを作っていても所詮は素人なので、いつどのタイミングで想定外のことが起こるかわからないし（最近はそんなには起こらないが稀に「あっ」となる）、ちゃんとしたプログラマーが作ったちゃんとしたツールはやはり使い続ける必要を感じている。バグが発生した時にその場で対処する余裕があるタイミングならいいのだが、「さっとメモしたい」みたいな時にバグと直面すると非常に困る。なので、ScrapboxやDynalistはHyperDatabaseとゆるく連携したツールとして現役だ。HyperDatabaseが本部でScrapboxとDynalistが支部みたいなものかもしれない。支部の方が現場としては優秀である。
このブログを本格的に始めた時の連載（アウトライナーの使い方ド下手問題～まとめ～）の最初で「情報管理の『系』を作り上げていく」ということを書いた。プログラミングと一年間格闘して、その姿が見えてきたかもしれない。
のらてつ Noratetsu