Noratetsu Lab

　ずっと前にVBScriptというWindows用のプログラミング言語をちょっと齧ったことがありました。中高生向けにプログラミングの考え方を説いた本を手にとったことがあり、その中でこの言語の説明があったのが出会いのきっかけです。

　齧ったと言っても、一噛みで歯のほうが折れたという感じでプログラミングの勉強の履歴としてはカウントしていません。（VBAもちょっとだけやりましたが、必要に迫られる環境になかったので本当にちょっとだけです。）

　実現したいことでググって、コードを拝借して弄れそうなところを弄る、という感じでtxtファイルやxlsxファイルの編集はしたことがありました。
　先日Excelの話を書きましたが（NTA-DIY：前日譚③～Excelの拡張としてのデジタルDIY～）、「打ち込む」と「見て使う」のうち「入力する」方のUIを新たに作る試みだったと言えます。専用のアプリケーション以外からデータを弄ることができるということにはかなりの驚きがありました。コンピュータを使っている、という感触を覚えました。
　しかしこの言語について全然理解はしていないので、調べて出てくること以外の挙動は何も作れません。基礎をやらずに当てずっぽうにコピペしていても何も身につかないのです。そりゃそう。

　VBScriptをやっていてもう一つ驚いたのが、テキストエディタでコードを書いて、それをvbsという拡張子で保存し、そのファイルをダブルクリックすればそれだけでコードが走るということです。当時は本当に仰天しました。書いて、ダブルクリック。環境構築のための努力は何も要りません。このパソコンにはそういうものが最初から備わっているのか、と感嘆しました。自分はパソコンのことを何もわかっちゃいないのだと思ったことを覚えています。
　まあ、今でもコマンドプロンプトなんかはわからないに等しいです。辛うじてNode.jsとGitに関するコマンドは使えるようになりましたが、コマンドというものの可能性がどこまで広がっているのか見当もつきません。自分が勉強さえすれば何も新たに導入せずとも実現可能なこと、というのが実はたくさんあるわけですね。

　もう一度VBScriptを勉強し直してもいいかなとも思っています。VBScriptでは「画面」を作れないのでノートテイキングアプリをつくることは難しいですが、逆に画面が要らない自動処理などはわざわざ他の言語を使わなくてもいいわけです。（ちなみにWindowsはPythonもインストールが必要です。）
　多分、他の言語（特にJavaScriptやPythonなど）をやっていれば、VBScriptの習得には苦労しないだろうと思います。
　とはいえ開発が終了して久しい言語であり、今ならPowerShellの方を勉強するのがきっと現実的で、どうせならVBScriptだけでなくPowerShellも覚えられたらより良いだろうとは思います。今のところ、PowerShellについては全くなんにもわからない状態です。日頃普通に生活していてPowerShellというワードを見かけたことがほぼないので、あまり関心を向ける機会がなく、存在を一応認識していながらもノータッチでここまで来ています。

　ちなみにどうしてVBScriptをやめてしまったかというと、どこでどう勉強すればいいのかその時はわからなかったのと、コードが動くという面白さを感じる一方で「役に立つ」ものは作れなかったからです。VBScriptではGUIを作れないというのが、プログラミング思考の弱い当時の私には致命的にミスマッチでした。何が何でも習得しようという熱意が生まれなかったのです。
　

直近の2投稿に関連して。

先日の投稿で、アウトライナーは常に使っていながらこう使っていますという話はなかなか思い浮かばない、ということを書きましたが、tasuさんも「いざアウトライナーについて語ろうと思っても、言葉がでてきません」とお書きになっているのを見て勝手に親近感を抱きました。
そして倉下さんの以下の分析に確かにそうだと肯きました。

日常的に使っているツール、当たり前に使っているツールほどうまく言葉になりません。これは当然です。なにせ「当たり前に使っている」というのは、使う上で意識の起動が不要な状態になっている、ということであり、言語化には意識化が避けては通れないのですから。
それに比べると、新しいツール、使いはじめたばかりのツールはじゃんじゃん言葉が出てきます。大当たり中のパチンコみたいなものです。そこでは意識がやたらめったら働いているので、言葉になりまくりなのです。
新しいものへの感動ではなく、自分にとっては既にわかりきっていることの中にある、素朴な「良さ」を取り出してみるということ。焦点を当て直さなければならないという点で難しさはありますが、しかし考えてみるに、多分難しく考える必要はないのだろうと思いました。このことについて言葉にしようと思って、この投稿を書いています。

倉下さんも引用なさっている箇所ですが、tasuさんは冒頭でこう書いていらっしゃいます。

デイリーノート、指針、思いついたことを書く、……。手書きなどの特別な工程を除き、何かを始めるときはとりあえずアウトライナーに書いてみる、と言って良いと思います。
倉下さんのご感想も引用致します。
でもって、「デイリーノート」も「指針」も「思いついたことを書く」も具体的にどんな風に書いているのかが気になります。そういう「使い方」の話に私は興味津々なわけです。
私も全く同じ気持ちです。そして、そこについて「もっと詳しく知りたい」という気持ちもありますが、実のところ「デイリーノート、指針、思いついたことを書く」「何かを始めるとき」の部分だけで既に結構嬉しいです。具体的にどうなさっているかはわかりませんが、それにもかかわらず、そのようにしてアウトライナーを使っているのだという事実だけでなんだかわくわくします。
Tak.さんがnoteでの「アウトライナーライフ」という連載にて、実際に実践なさっていることをガンガン掲載していらっしゃいますが、それもやはり嬉しい感じがします。役に立つから、自分の生活にも取り込めるから、というより（それももちろんあるのですが）、シンプルに「誰かのその人なりのやり方を見れて嬉しい」という気持ちです。

他の場所で何度か書いていますが、私は「日経ビジネスアソシエ」という雑誌の手帳特集がとても好きでした。多分この雑誌についてはこの界隈（？）ならご存知の方が多かろうと思います。あとは他の媒体でほぼ日手帳やモレスキンなどの用例もあちこちで見ました。もうどれをどれで見たのかわからなくなってしまいましたが、本当に多彩な例を目にしました。カラフルで工夫している感満載のものもあれば、黒一色で剛毅木訥な力強さを感じるものもありました。みっちり詰め込むように書いているものもあれば、時々必要が生じた日に必要な分だけ書くというスカスカな手帳もありました。どの例も同じようにわくわくして見ました。
昨今デジタルツールの使い方について語るとなれば「あれをこうして、こっちであれして」という手順の説明をすることが多いように思われます。一方で雑誌の手帳特集が楽しかったのは、写真で実物を見れたことにあります。手順の説明もあればよりありがたくはありますが、正直あってもなくてもいいくらいでした。その例について「わかる」かどうかより、誰かがその人なりに工夫して生きているということを「垣間見た」だけで嬉しいからです。
（デジタルツールの場合は、スクリーンショットだけ見ても、手書きではないことでニュアンスが掴みにくい上に、レイアウト的に意味合いが自明でない場合も多く感じます。どうしても説明せざるを得ない面もあるでしょう。）
手帳以外にも、部屋の様子とか廃品利用とかそういうものを見ると大変わくわくします。あとは自分がわからないプログラミング言語でも「これをこうしているんですよ」というような語りを見かけるとわくわくします。内容がわかれば実際的に助かるということはありますが、たとえよくわからなくても「見れて嬉しい」という部分は変わらないようです。

工夫らしい工夫、方法らしい方法でなくとも、「これをこうしています」という事実だけで楽しく、そしてその楽しさは、手帳のように道具自体については普通に知っているというものだとより鮮やかに思えます。知的好奇心よりもっとメンタルな部分で嬉しく感じているような気もします。
アウトライナーも「普通に知っているもの」の範疇に入っていると言える気がします。多分、有効かどうか、真新しいかどうかなんてことは関係なく、「アウトライナーを使ってこうしています」というのを聞くと楽しくて嬉しいのだと思います。おにぎりの具は何が好きか、なんていうことで割と楽しい会話になったりするのと同じようなものかもしれません。

そういえば、前に富山さんが投稿なさっていたiTunesの応用の話に私は甚く興奮して、その後幾度か読み返してiTunesのUIに思いを馳せたりしたのを思い出しました。

• File Viewerに似せてPDFを管理した - by 富山孝裕@タカヒロト - トンネルChannel

発想自体に驚いたこともありますし、iTunesという個人的にかつて超がつくほど使い倒したツールについての工夫を知れたことが私には大変に嬉しかったのです。

今月のお題、「アウトライナーの使い方」に関する投稿です。

常に使っていると言っていいくらいアウトライナー（およびアウトライン機能）はいつも何かしら開いているのですが、その一方なんとなくで使っていて使い方に自覚的でないので、こう使っていますという話はなかなか思い浮かびません。
しかしちょうど最近始めたことがあって、そのことなら割合整理して語ることができそうなので、ちょっと書いてみることにします。どんなものかと言うと、ブログのアウトラインから本文まで全部Dynalistで書く、という試みです。

ブログやトンネルChannelの投稿のために記事を書く時、少し前までは自分で作ったノートテイキングアプリを使っていました。メモのリストがあり、メモそれぞれにアウトラインのデータと本文のデータがあって、メモをクリックするとアウトライナー部分とテキストエディタ部分が上下に並んだ形で表示されるものです。
似た形式でいくつかツールを作っていますが、例えばこういう感じです。

アウトライン＋本文というセットで扱うのは自分の中でとても画期的なことで、実際この形式はかなり役立ったのですが、ひとつ問題もありました。私が作ったこのタイプのツールでは、記事それぞれをカードのように扱っていて、記事の位置づけを整理できるようにはなっていません。
ひとつの記事で完結するとか、長くても三つ四つくらいで話が終わるものならそれでよかったのですが、しかし今年に入って私はちょっと大きなシリーズに挑むことにしました。挑むと言ってもただ自分のことを好きに書いているだけのことですが、プログラミングの勉強を始めてからの一年間の整理を試みています。自分の中で劇的な一年だったので、きちんと一通り整理しておきたいと思ったからです。
一年という期間の俯瞰が目的なので、記事それぞれの位置づけを考える必要があります。その場合に、ばらばらのカードのようなツールではとてもやりにくく思われて、せっかく作った自作ツールを離れてDynalistに戻ってきました。アウトラインと本文を別の場所で作るのは面倒だったので、本文もDynalistで書くことに。そして、記事の種類によって場所をわけるのも面倒なので、シリーズ以外の記事を書く場所もDynalistに移動しました。ブログを書くという活動全体をDynalistに引っ越したわけです。

Dynalistで本文まで書いてしまうというのは、実は前にもやったことがありました。しっくり来なかったというわけではないのですが、その時は短期間でやめています。書いていた記事が単発のものだったのでDynalistを使う必然性がそれほどなかったからです。
今回は、全体像の整理をするのにプロセス型アウトライナー以上に良い形態が思いつかないので、他の選択肢を考える気にはなっていません。今回のような大きなシリーズものや、あるいは本の執筆もきっとそうですが、必要な情報・内容を大きな括りから小さな括りへと階層になるように構成した時に、最小単位の「記事」が何層目になるのか事前にはわかりません。そういった場合に、フォーマットを予め決めておかなければならない形式や、層の数が限られるような形式はやりにくいと感じます。あるいは何層目かによって見た目が決まってしまうものも困ります。層を無限に作ることができ、どの層も同じ見た目をしているプロセス型アウトライナーは、その点で非常に自由です。

具体的にどうやっているかを書いていくことにします。
Dynalistは「ファイル」を作って作業することになります。私は投稿先ごとにファイルを作っています。「Noratetsu Lab」「トンネルChannel」といったファイルがあるということです。なお上述のシリーズについては、投稿先はNoratetsu Labですが、他の単発記事を書く作業とは別のラインが常時走っている状態なので「NTA-DIY」というファイルを別に作ってやっています（「Note-taking applicationのDIY」の略です）。
そして適宜階層を作ります。「NTA-DIY」では下の画像のように一段階階層があり、その下に記事の項目が並んでいる状態です。（CSSをあれこれ弄っているので、Dynalist本来の見た目とは違っています。）

特に階層を作る必要がなければ作りません。「トンネルChannel」はファイルの直下に記事が並んでいます。
各記事の項目は直下に「■」「◆」「🖋」という三つの項目を作っています。記号は別になんでもよいのですが、なんとなくでこれらを選択しています。

これらはそれぞれ「必要な情報」「文の組み立て」「本文」を表しています。

まず■の下に思いつくままに書き、流れが見えてきたら◆の下で構成し、🖋の下に本文を書く、というのが基本の流れです。わざわざ◆で整理する必要がなければ■と🖋だけになり、■も作らずに🖋だけで直に本文に取り掛かることもあります。
本文は段落ごとに項目を作っている状態です。項目というのを意識しているわけではなく、普通にテキストエディタに書くように書いているということです。

しかし項目になっていることの恩恵は受けています。例えば後で調べておかなければならない部分があれば、その部分の項目の下位に調べる必要がある旨書いておきます。調べて本文を整えたら畳んで見えなくします。あるいは没が発生した時、手前の箇所の下に没の部分をインデントし、折り畳んでしまいます。「使われなかった分岐」がそのまま残るわけです。
つまり各段落に対して好きなように情報を付与できるということです。これは大変便利です。

Dynalistで書くことにはこのような利点がありますが、ベストとは言えない部分もあります。まず字数カウントの機能がありません。そして複数のファイルまたは項目を開いて作業するということができません。
後者については可能なアウトライナーもあり、単にDynalistを選択しているからできないということなのですが、他のアウトライナーの存在を知りつつDynalistを気に入って使っているので目を瞑っています。
🖋の下に書いている時に◆の内容を見たいとなったらその都度スクロールして確認している状態で、言ってしまえば煩わしいのですが、その一方で本当に「常に並べておく」のが良いのかどうかはちょっとなんとも言えないと思い始めています。前はあれこれ同時に表示しても気になりませんでしたし、むしろ表示しておけるなら表示しておきたかったのですが、最近は本文を書いている時は本文以外の情報（特に計画の部分）はあまり見えない方が捗ることもあるように感じています。それは集中できるからというより、予め考えたルートに縛られてしまう度合いを下げられるからという理由です。「見えないほうが良い」とまでは思っていませんが、見えないことによって生産性が下がるわけではないな、という感じです。

こんなところです。
……と言って締めようと思ったのですが、「字数がカウントできない」という点について、この投稿を書き始めてから解決策を閃きました。Chrome拡張機能で字数カウントを実装してしまえばいいじゃん、ということです。思いついてすぐ作ってみたところ、これがとても良い感じです。

上から順に、フォーカスしている部分全体の文字数、編集中の行の文字数、「🖋」の下位項目の文字数です。これが右上あたりに常時表示されています。思いがけずデメリットを自己解決してしまいました。詳細はここでは割愛しますが、別途どこかに書くかもしれません。
こんなところです（今度こそ）。

　ここのところ、未だかつてなくScrapboxを盛んに使っている。といっても非公開の個人プロジェクトの話だが、きっかけがあって劇的に使いやすくなった。

　これまでずっとページのタイトルの付け方に納得がいっていなかった。全然Scrapboxが悪いとかではなく（そりゃそう）、自分がうまくやれないでいただけの話である。
　特にうまくできなかったのが、Web記事などの中の文章をScrapboxに保管しようと思った時のページタイトルである。記事のタイトルにすべきか、引用した文章そのものにするか、内容の要旨にするか。記事タイトルは必ずしも保存したい内容に沿っているとは限らないし、文章そのものというのもその文章が名言的なものでなければあまり有効でない。一時期は「～～は……である（要旨）」みたいな書き方をしたりしていたが、なんだか全然しっくりこない。
　単に「～～は……である」だけでいいのでは、というのはもちろんあり得ることなのだが、自分が思いついた発想と誰かの言葉から得たものとを区別したいという気持ちがある。なので何かしらのルールでタイトルを書き分けたかったのだが、その目的に於いては記号や絵文字を付けると見た目に煩わしく感じてしまう。どうしたものか。

　なかなか答えが出ないままでいたのだが、先日、ふとあることを閃いた。ページタイトルをスレタイみたいにすればいいのではないか？
　スレタイと言っても色々あるが、イメージしているのはニコニコ動画でもよく見る隅付き括弧で挟むタイプのものだ。匿名掲示板はそんなに見に行ったことはないのだが、本題に対してサブタイトルが二つに分かれて左右についている形式を最初に見た時にはなんだかとても面白く感じたのを覚えている。以下スレタイと言ったらこの形のことを指しているということにする（この形式に何か名称があるのかわからなかったため）。

　Scrapboxのページタイトルとしては、例えばこんな感じのページを作るようになった。いずれも実際に作ってあるページである。

• 【名文】真にカルチベートされた人間になれ【太宰治】
• 【なるほど】覚えたい英単語でショートストーリーを作らせる【ChatGPT】（→出典）
• 【💡Scrapbox】ページタイトルはスレタイ方式にする【実践】
• 【感想】RemNoteを使ってみた【惜しい】
• 【悩】ローカルサーバー方式でデータを保存すると一部文字化けする問題【解決🎉🎉🎉】
• 【2023/03/12】漠然と体調不良【翌日解消】

　パターンはいくつかある。整理すれば「【感想】～【出典・対象等】」「【分類】～【状態】」の形が多いだろう。如何にもスレタイっぽくなる場合もあるが、別に如何にもなスレタイっぽくしたいわけではないので、ただ日付を入れたり絵文字や顔文字を入れたりすることもある。例に挙げたのはいずれも両端に隅付き括弧をつけているパターンだが、頭の方だけつけているページもある。
　で、この場合、【名文】とか【なるほど】というような言葉を頭につけたものは明らかに自分以外の誰かの発信が元だとわかる。逆に【💡Scrapbox】は「💡」で閃きを示しており、自分が思いついたことだとわかる。自分発のものと他人発のものの区別がしたいということはこれでクリアである。
　前々から、頭の方に隅付き括弧で種別を添えることはあった。例えば「【JavaScript】指定した要素の位置までスクロールする方法」という感じ。しかしスレタイのイメージは浮かんでいなかったので、感想をそこに書いてしまうという発想はなかった。

　この形式の良いところは、なんといっても情報量が増えることだ。一文に領域が三つでき、それぞれメインとサブ①、サブ②であることが明らかである。且つ、隅付き括弧同士は繋がっている可能性があるが、真ん中の内容部分とは少し断絶があるという独特のニュアンスを持っている。そしてメインが何であるかは明確でありながら、両脇も強調している感があるのが面白い。
　例えば「【名文】真にカルチベートされた人間になれ【太宰治】」というタイトルについて考えてみる。この一文が示しているのは「『真にカルチベートされた人間になれ』というメッセージを含む太宰治の名文」であることがほぼ明らかである。「太宰治の名文」という要素が、【名文】【太宰治】に分割されている（【太宰治】～【名文】の順でもいい）。ちなみに、「太宰治のこと」ではなく「太宰治が書いたもの」であることを明示したいという理由で【名文】を敢えてつけている。
　これが「【太宰治の名文】真にカルチベートされた人間になれ」とか「真にカルチベートされた人間になれ【太宰治の名文】」とかいう形だと、サブの部分が重たくなり、なんだかバランスが悪い。一方、むしろ情報を足して「【太宰治の名文】真にカルチベートされた人間になれ【正義と微笑】」とするとまた見やすさを取り戻す。天秤のように左右に重さが乗っていればサブ部分がある程度長くても違和感がない。
　とはいえ短く済むならその方がスッキリする。作品名を入れたら必然的に「書いたもの」の話なので「の名文」はカットしてもいいだろう。比較しやすいように列挙してみよう。

• 【名文】真にカルチベートされた人間になれ【太宰治】
• 【太宰治の名文】真にカルチベートされた人間になれ
• 真にカルチベートされた人間になれ【太宰治の名文】
• 【太宰治の名文】真にカルチベートされた人間になれ【正義と微笑】
• 【太宰治】真にカルチベートされた人間になれ【正義と微笑】

　ブログで紹介するみたいなことなら一番目より五番目の方が相応しく思える。ただ、自分の個人的なメモとしては、どの作品で書かれたものかより「太宰治がこんな名文を残している」という感慨の方が重要なので、一番目の方が適当なのである。
　また、「真にカルチベートされた人間になれ」というのは実際に『正義と微笑』の中にある表現そのままだが、この部分が多少要約的になっていてもよい。例えば「【名文】学問は人格をカルチベートする【太宰治】」でもいい。これは私の中にある「スレタイには要旨が書かれているものだ」という前提の助けを借りている。そのまま引用しているかもしれないし、適宜縮めて要約しているかもしれないが、ともかくそのような内容で太宰治が残した名文がある、という意味合いのタイトルになっている。わざわざ「（要旨）」と断らなくても気にならなくなった。

　個人的な感覚の話だが（それは全面そうではあるが）、絵文字が単体で文にくっついた状態というのが私は好きでないようだ。例えば、「【💡Scrapbox】ページタイトルはスレタイ方式にする【実践】」というタイトルを例に挙げたが、前は「💡Scrapboxのページタイトルはスレタイ方式にする」と書いていた。これがなんだかとても気に入らない。しかし絵文字が持つニュアンス自体は好きなので、絵文字を使えたらいいという気持ちはある。絵文字の情報量を優先して、ずっと気に入らなさを我慢していた。
　ところが、「【💡】Scrapboxのページタイトルはスレタイ方式にする」と書いたところ、不思議と気に入らなさがなくなった。多分、絵文字部分が本体の一部のようであったのが、隅付き括弧で本体から明確に分離されたというのがその理由だろう。
　最終的に、左の隅付き括弧に分類を示す言葉と合わせて入れることにした。【Scrapbox】だけなら「Scrapboxに関する一般的な知見や仕様」のニュアンスがあり、【💡Scrapbox】なら「Scrapboxを利用するにあたっての自分のアイデア」という意味になり、他には【💭Scrapbox】なら「Scrapboxの使い方として今考えていること」という意味がある。なお【💡】だけなら生活に関わる閃きなどになる。

　このスレタイ風タイトルは、名詞・フレーズのページとそうでないページを区別する役割も担っている（後者のみをスレタイ風にしている）。このページはWiki的に使いたいページで、こっちはスレッド的な使い方のページだ、というのがひと目でわかる。私にとってこれは結構重要なことだ。
　両端に隅付き括弧を配置する形式を好ましく感じるかどうかは多分人それぞれだろうし、そもそもページタイトルにそんなに細かくニュアンスを込めたいかというのも個々人でバラバラだろうと思うが、私の場合は自分の微妙な要求に答えてくれる形式をこれに見出して怒涛のようにページを作るようになった。スレタイのあの形を前から面白いと思っていたので、やっていて楽しい。Scrapboxライフは劇的に豊かになった。
　

　最初の一ヶ月について十本かけて書いてきました。（もう一本書くつもりでいたので締め的なことを書きませんでしたが、一ヶ月目については前回で終わりです。）
　一年も前のことですが、比較的解像度高く書けたのではないかと思います。もう少し細かく書きたい気持ちもありましたが、費やせるリソースはこれが限界と思いちょっと駆け足になりました。

　一年前のことを書けるのは、簡単ながら記録を残していたからです。何がわからなくて何に感動したのか、Scrapboxの個人プロジェクト（非公開）に書き込んでいました。
　こう書くとその都度きちんと整理していたかのようですが、実際には「○○って～～ってこと？」とか「なるほどね！！」とかいう感じの記述があるだけです。後々のために残そうとかいう意識はなく、何もしていなかったかのような気分になるのを防ぐために書いていったらそれなりの記録になった感じです。
　ページの粒度としては、「次のステージに進んだ」と感じたらページを改めていき、期間にして1ページあたり数日から一週間程度の記録になっています。実際のページ名を並べるとこんな感じです。

• TS/JS日誌vol.1 基本～配列・関数・オブジェクト
• TS/JS日誌vol.2 ブックマークレット実作
• TS/JS日誌vol.3 「TypeScriptで学ぶJavaScript入門」復習/ブックマークレット進化
• TS/JS日誌vol.4 ScrapboxのPageMenu作成
• TS/JS日誌vol.5 bookmarks.htmlの自動生成実装＆cards.html開発
• TS/JS日誌vol.6 card.htmlのlocalStorage化、メモアプリに進化
• TS/JS日誌vol.7 outline.html開発

　これらのページの中に、日付を書き、参照したURLと疑問や感想、作ったコードへのリンクを日付の下に箇条書きでずらっと並べていきます。実のところ八割がたURLの列挙で、日記的な記述はそんなにはありませんが、何に取り組んでいたかがわかりさえすればその時どうだったかはある程度思い出せます。また、いちいち細かく書いていないことによって、逆に「わざわざ書いた」部分の困り具合や感動具合、その他正直な心境が目立ちました。これは思わぬ収穫です。この一連に関してはズボラ日記で正解でした。
　見返すために書いたのではなく書くために書いていたものなので、今回このシリーズ記事を書くにあたって見直すまで、一年近くこれらのページを開くことはなかったように思います。たまたま記事を書こうと思ったので役に立つ日が来ました。
　Scrapboxでなければこうはできなかった、というようなものではなく、Obsidianでもアウトライナーでもtxtファイルでもなんでもいいのですが、Scrapboxは気軽に書ける雰囲気があり、他のことにも使っているのでScrapboxを選択しました。

　じゃあずっとこれを書いていたのかというと、実際は上記の七ページだけです。ちょうど一ヶ月分しか時系列に沿った日記はありません。JavaScriptの習得スピードが速くなるといちいちメモしていられず、また疑問点も比較的すぐ解決できるようになり、ノートを取る必要性が薄くなっていきました。書くために書いていたので、書く必要がなくなると途絶えてしまったわけです。
　代わりに、一ヶ月が過ぎた頃からはツール開発を始めていたので、書いたコードは頻繁にGitでコミットするようになりました。勉強したことは実際に動かすコードとして反映され、その記録がGitに全て残っています。コードを書き、また別に日誌を書く、となると二度手間になってしまいますが、Gitを使えばその時点の状態が記録されていくので、コードをこまめにコミットするだけで日誌を書いているのとおおよそ同じことになります。
　ただ、漫然とコミットしているとそのコミットが前回のコミットとの間でどう違うのかひと目ではわからず、資料として使いづらくなります。そこでコード内のコメントやコミットメッセージを工夫する必要がありますが、これがまた結構難しいです。いずれもその時点の文脈に基づいて書き残すことになりますが、後から難点になるのが、知識・スキルの状態の変化です。

　知識が乏しく経験が浅い時点で書いたメモは、その時の感覚で「こう書けばわかるはず」と思っているのですが、もっと先に進んでから戻ってくると何のことを言っているのかびっくりするほどわかりません。書き方自体が下手だったのも大きいと思いますが、能力不足で的確な表現ができないことによって、結局コードを細かく見ないと何がなんだかわからない記録になってしまいました。その時点ですごく頑張って記録をつけても、言葉にする労力があまり活きない可能性があるのです。
　このことを解決する術はわかりません。まあ、プログラミングを勉強し始めた最初期しか起こらないこととも思うので、「最初に学ぶ言語の学習記録はどんなに頑張っても読めるものにならない」と思った方がいいのかもしれません。Gitのコミットは如何にも「後から確認できるようにするための記録」然としているので、あまり意味をなさない記述が気になってしまいましたが、最初の一ヶ月にScrapboxに書いていたもののように、「見返すために書いたのではなく書くために書いた」と思って見れば十分な記録だと思えます。他の人に読んでもらうものではないので、何かしら残っていればそれでいいでしょう。
　その意味で、うまく記録を作る力がなくとも、「そのもの」を残しておけるGitというのは本当に素晴らしい仕組みです。見たままを撮れる写真ですら写真の撮り方の上手い下手が後々問題になりますが、Gitのコミットログはどこからでも見れる3Dモデルを全ての段階で残しておけるようなものです。威力を遺憾なく発揮できるのはプレーンテキストの記録に限られはしますが、今やっていることを言語化すること自体が困難な状況の中で「とりあえずそのまま残す」が可能というのは大変ありがたいことです。（うまくやれていないものを前にして素朴に喜んでいられるのは趣味の独学者の特権ですね。）

　そんな感じで、ScrapboxとGitに残した記録を元に、一年間の書き起こしに取り組んでいます。一ヶ月以上かけてやっと一ヶ月目が終わったところですが、二ヶ月目以降はもう少しサクサクいけると思います。
　

　簡易ブックマーク管理ツールを作ったことで、CSVファイルから自由にHTML要素を作る術を得ることができました。表のデータにレイアウトやデザインというものを結びつけることができるようになったわけです。
　最初はブックマークの整理のことしか考えていませんでしたが、それができるようになってみると、今度は得たものを応用して別の何かを作ってみたくなりました。

　この時自分の中に問題意識としてあったのは、せっかく書いたメモがそのまま埋もれて死んでしまっているということです。メモが死蔵される原因のひとつが「テキストの連続の中に混じってしまっている」ことにあり、見た目に存在感を持たせれば見返しやすくなるのではないか、と考えました。
　そこで作ったのが、メモをカード風にして並べていくツールです。（なお画像は後述のエディタ版です。）

　このレイアウトとコンセプトは、Scrapboxと、倉下忠憲さんのMindGardenの影響を受けています。
　この時期はとにかく乱数を使いたかったので（プログラミングやってる感があるので）、カードをランダムにピックアップする処理をツールのキモとして作りました。
　当初はブラウザ上でデータを編集して保存する術をまだ知らなかったので、このツールはビューワでしかありませんでした。CSVファイルに手動入力してデータを作り、このツールを通して見るという形です。

　やがてlocalStorageの使い方とJSONを覚えると、ビューワからエディタへとクラスチェンジしました。ノートのテイキングが可能になったわけです。ようやくNTA-DIY（ノートテイキングアプリケーションのDIY）に至ったということですが、この進歩は劇的です。
　localStorageという機能を知る前は、ノートテイキングアプリとして成り立たせるにはどうしたらいいのかいまいち想像できなかったので、こうすればいいのかという感動はかなり大きなものでした。
　localStorageなるものは初耳だという方に簡単に説明すると、localStorageというのはWebブラウザの保存領域にデータを文字列で保存する仕組みのことです。ブラウザではセキュリティの問題から直接ローカルファイルを編集することができませんが、ブラウザの中にならデータを置いておけるのです。ただしブラウザに依存するので他の端末からはアクセスできない上、容量には限りがあるので（ブラウザによって異なり、ドメインごとに5～10MB）、万事を解決するものではありません。その問題については後々他のやり方で打破することになります。

　さてツールとして成り立たせる術は得ましたが、いきなり実用性のあるツールを作れるはずはないことは解っていたので、実用的なツールを目指しはしながらも「実際役に立つかはさておき、この挙動が実現できるか試したい」というような発想でコーディングしていきました。
　そうして作ったものがCard Memoにあります。（スマホからもアクセスはできますがPC用です。）

目的と仕様

• 思いついたメモと誰かの言葉の引用を溜めることを目的としています。
• カードをクリックすると編集画面が表示されます。
• 各欄の編集履歴が全部保存されます。
• attribute欄に特定の文字列を入力するとカードの種類を設定できます。
  • 「！」：重要（文字色が変わる）
  • 「P」：ピックアップ（右側の列に表示される）
  • 「X」：トラッシュ（非表示にできるようになる）
  • その他色指定（マウスオーバーで有効な文字列を表示）
• カードの番号を指定して抽出する範囲を決められます。
• 指定した枚数をランダムにピックアップできます。

　自分用のため親切設計にはなっていませんが、データはお使いのブラウザのlocalStorageに保存されるので、実際に使用することができます。なお編集履歴の保存は「必要は多分ないけど思いついたのでやってみた」というタイプの機能です。
　CSSをそれなりに整えるとそれなりのものができている感じに見えるかもしれませんが、特に難しいことはしていません（何しろ始めて一ヶ月経っていない初学者です）。技術的にはごくごく初歩的な範囲だけで自分の希望にそれなりに沿うものができることがわかりました。これは驚くべき発見です。
　当初は「一年後には何か小さいアプリケーションを作れたらいいな」と思っていたわけですが、そこで思い描いていた「小さいアプリケーション」は開始一ヶ月弱でもう実装可能になってしまいました。最初の予想がちょっと頓珍漢だったとは思いますが、それだけプログラミングというのは高い壁に思えていたのです。
　もちろん「良いコード」は全然書けません。エラーが発生しないようにツールの使い方のほうを気をつけるということも多々ありました。重要なのは、「人間の目にはめちゃくちゃでもコンピュータが解釈できれば動く」ということです。力技が許されるならできることはたくさんある、ということをこのツールを作る中で知りました。そうなると、肝になるのはスキルより如何に思いつくかの方です。

　なおコードは一年前に書いたものそのままではなく、今現在のスキルで全面リファクタリングしたものです。ゼロから作り直したわけではないので、今作るとしたらそうはしないという処理がちらほら残っていますが、気力が尽きたのでこんなもんでいいだろということにしています。リファクタリングにあたり色々得たこともあるので、格闘した甲斐はありました。コーディングのアイデアがいろいろ生まれたのと、当時の工夫に価値を感じる部分をいくつか発見しました。
　例えばattribute欄に文字列で設定というのは、未熟な頃に編み出した「なるべくレベルの低い処理でどうにかしたい」という苦し紛れの策で、今見るととてもダサい感じがします。今ならチェックボックスやカラーピッカーなどを当たり前に設置します。
　でも自分しか使わないツールでUI上のそういう「わかりやすさ」が本当に必要なのか、と思えてきました。重要なカードだという設定をするにあたり、この形式なら「！」のたった一文字で済むところが、もしinput要素のデータを個別に扱って「"important": true」とかやったらデータの文字数が何倍にも増えることになるわけです。「重要な内容でピックアップ指定にもしていたけど不要になったのでトラッシュに設定した」というニュアンスが「！PX」だけで済んでしまうのは実に省スペースです。

　頑張って作ったこのツールを当時バリバリ使ったかというとそれほどでもないのですが、それなりに面白いツールを作っていたなと思います。
　当時は他のツールなどで作成したデータを加工して取り込むというようなことを考えなかったので、ツールを作ったらそのツールのデータというのはツール上でゼロから作っていくものでしたが、今なら過去の記述を整形してガッとインポートするみたいなこともやろうと思えばできるので、大量のメモが入った時の使用感が実際どんなもんかそのうち試してみてもいいかもしれないと思いました。
　

　スマホが身近になるよりも以前のことですが、その当時私は何かデータっぽいものを整理しようと思ったらExcelを使っていました。

　作ったファイルの多くは関数も必要としないもので、ただ「編集可能な表」が欲しかったのです。手書きの表では、後から行や列を追加したり入れ替えたりができませんから、そういう操作がいくらでも可能な表エディタとしてExcelを必要としていました。
　しかしExcelでの整理がうまくいっていたというわけではありません。続けさえすれば充実した「自分データベース」になるはずだとわかっていながら、続けるということが難しいのです。
　一言で言えば「飽きる」のですが、この「飽き」は「最善でない」という気分から生まれていました。データの形式としては問題ないのに、自分の手で打ち込み自分の目で見て使うツールとしては納得感がなかったのです。

　一方それ以外のツールを使うともっと不満に感じました。テキストの保存がメインのツールはデータとしての活用しにくさが気になりだし、逆にデータベースとして高機能であることが売りのサービスは、多機能すぎて面倒臭さのゲージがじりじりと高まっていきます。
　Excelに入力した状態のようにピシッとデータ化されていて、且つ自分に馴染むUIを備えている――そんなツールが現れることを願っていました。大変我儘な願いです。
　様々なアプリケーションを使ってきましたが、面白いと思うツールは数あれど、いずれも自分にぴたりとハマるものではありませんでした。「これこそ自分が求めていたものだ」と感じる人もいるだろうと思いながら、私自身がそうではないことを残念に思うことが続きました。

　Web技術を使ったノートテイキングアプリケーションの自作は、その不自由な心境を打ち破ってくれました。素人ですから技術的に実現可能なことに制限があるというのがネックですが、「必要かつ十分なデータ形式」「理想のUI」という二点を自力で模索する術を得たのは、自分の世界がちょっと変わるくらいの出来事です。
　プログラミングをする、あるいはアプリケーションを作る、ということを考えた時、実現したいと思うものは人それぞれ大きく異なるだろうと思います。私の場合は、JSONというデータ形式を使い、JavaScriptのDOMによってデータを自由に配置する、それがプログラミングへの関心の九割くらいを占めています。かつてExcelでやりたかったことを現実的なものにしたいという願望です。

　そしてデータベース的であってほしいところをデータベース的にする試みを重ねる中で、データベース的である必要のないものはそうでない形でよい、という素朴な納得を得ることにもなりました。「Excelみたいにピシッとした」という状態への憧れを解体し、無意味に自分を駆り立てて不満を生み出す根源を撃退したのだと言えるかもしれません。
　

　いよいよ具体的に作ったツールの話がメインになります。
　今回は少し前の記事（前日譚②～JavaScriptを書けると何が嬉しいの？～（NTA-DIY：前日譚②～JavaScriptを書けると何が嬉しいの？～））で触れたブックマーク管理ツールの話です。

　管理と言っても、まだツール上でデータを編集するわけではありません。とりあえずCSVファイルにデータを用意しておいて、それを使っていい感じの見た目を作ろう、というものです。ツールというよりはビューワと言った方が表現としては合っているかもしれません。
　実際に作ったもの（のコードを今の書き方で綺麗にしたもの）をサンプルとして見れるようにしてみました。

• Bookmark Viewer

　データのCSVはこちら。「tag」「title」「url」「favicon」「description」の5つの項目を設定しています。説明がわかりやすいように一部を取り出すとこんな感じ。

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を編集するというのはあまり自然な流れではないので、半年くらい後に違うやり方に変えました。具体的には……とここで書こうかと思いましたが、それはいずれ記事にするのでお楽しみにということにします。

　ところで、公開したサンプルは単にツールの様子を見せるために作ったものですが、個人サイトの一コンテンツとして置いておいてもいいかもと思いました。よく使う便利ツールのリンクなどを充実させると面白いかもしれないですね。