Noratetsu Lab

　一ヶ月以上前のことだが、新しい規格のアウトライナーを自分用に作ろうとしていた。結局没にしたが、最初はいいことを思いついたと思ったのでここに書いて供養する。

　メモを雑に書いたままゾンビ化させないために、「つぶやくように書けて、アウトライナーのように操作できて、平面配置で表示されて、自然にもう一人の自分と対話できるツール」を作ろうという話のツール紹介編。ここに至る経緯は前回の記事をご参照のこと。

• アウトライナー×つぶやき×平面配置①～経緯編～

　前回の最後にも貼ったが、まずメイン画面のスクリーンショットはこちら。

　なお撮影用に余計な情報が写らないようにしたため実際の画面とはレイアウトが若干違っている（実際よりちょっと窮屈な画面になっている）。
　コンセプトとしては「アウトライナー×Twitter×面」ということになるが、書き込んで操作する部分はアウトライナーである。なので名付けるとしたら○○アウトライナーということになるだろう。
　そして左右にちらっと映っているのが他のビューで、普段はこんな感じで中途半端に端っこが見えている状態で控えており、マウスオーバーするとアウトライナー部分に重なるようにスライドインするようになっている。それぞれのスクリーンショットはこんな感じ。


　動かしている様子は動画にしてTwitterに投稿したので、ご興味のある方はそちらもどうぞ。

• https://twitter.com/Foam_Crab/status/1587745920329732096

　機能ごとに詳細を書いておこうと思う。（例によってツールもコードも公開していないが、考え方や所感が誰かの何かの役に立つかもと思って書いている。）

アウトライナー

　アウトライナー部分は、フォーカス以外の一通りのアウトライン操作ができるようになっている。ほぼ普通のアウトライナーである。
　違っているのは、各ノードに個別のアイコンを設定できることと、編集時に文字数カウントが表示できることだ。

　アイコンはCtrl+←/→で簡単にくるくる変更できるのだが、挙動の仕組みとしては、全てのノードが何らかの種別を持ち、その種別に対応するアイコンが自動的に表示されているということを意味する。（HTML的にどうなっているかというと、li要素にカスタム属性を設定し（data-typeとした）、その値が「topic」とか「date」とか「A」とかいうふうに変更されていくということだ。）
　前回書いたように、アウトラインに行を追加した時にはデフォルトで「二つに分けた自分の一方」を示すアイコンが表示されるようにしてある。サンプルでは「自分A」ということにして赤丸の「A」のアイコンにしてある（実際は全然違うアイコンを使っているし、自分A自分Bという呼び方でもない）。
　こうすると、とりあえず自分Aとして考えたことを書くことになり、自分A以外に他の自分がいるはずであること、自分の中でも偏った視点でしかないかもしれないこと、をなんとなく意識する。（前回詳しく書いたが、そうなるように私自身が既に訓練されていたところがある。以下、「こういうことが起きる」として書いてあるのはあくまで私の中でのことである。）
　自分A以外に人がいるのに、自分Aにしかわからない独りよがりな書き方をすると他の存在が関われなくなるので、恰も他の誰かが見ているかのようにきちんと書こうという気持ちが働く。別にきちんとさせないで自分Bをいきなり登場させてもいいのだが、そうすると対話の体を成していないという気持ち悪さに私が耐えられなくなるのである。
　自分Aが書いたものに自分Bという別の視点をぶつけてみた時、それでも納得できるのか、ツッコミどころを見つけて「いやそれはおかしいでしょ」と自分で批判することになるのか、それはその時次第だが、とりあえず自分で穴を探すというチェックが働く。自分同士である以上どうしたって完璧なチェック機能にはならないが、それでも結構な頻度で「いや、ちょっと待てよ」が発生するし、「じゃあこういうのはどうか」と新たなアイデアを閃くことも多い。必然的に、思考はどんどん拡張していく。
　自分Aと自分Bというのはどう分けているのかというと、前回の繰り返しになるが、「合理的っぽい自分」と「本音っぽい自分」という二つの軸をイメージしたものになっている。なので自分Bから話がスタートすることもある。どちらも「っぽい」であって、そんなにはっきり分かれているわけではなく、よく考えるとこれ逆だったのではということもある。どっちがどうというより、二つの軸で考えるということが肝心である。

　字数カウントも大事な要素になっている。見た目としてはこういうことになる。

　意義は前回書いたので繰り返さないが、結構馬鹿にならない影響がある。必ず100字以上140字以下で書くぞ、というようなルールを設けているわけではないし、実際その字数に至っているのはせいぜい半分くらいではないかと思うが、目安があることで常に「まだ不完全だからもうちょっと考えられるなら考えよう」という意識を持つようになっている。
　また、字数カウントによる目安というのはきちんと文章化して書いていなければ意味を成さないので、ここでも「人が読める文章」を書こうというインセンティブが働いている。

　なお、各ノードはそれぞれ作成日時と編集日時が記録されており、そのことによって次に紹介するタイムライン機能が実現されている。

タイムライン

　右側からスライドインしてくるタイムライン画面は、見た目に明らかな通りTwitterのタイムラインを参考にしたものである。

　ここで直接編集はできないが、ダブルクリックすればアウトライナーの当該ノードがフォーカス状態になってすぐ編集に取り掛かれるので、編集と閲覧の行き来は簡単である。
　タイムライン機能を考えた最初の動機は、ツリー構造とは別に「考えた順」に並べたいという気持ちが前々からあったことだ。アウトライナーは内容を基準としてツリー状に形を成していて、いつでもどこにでも書き加えられて書き加えるほど成長していくのは良いのだが、その場所から離れてしまうと「さっき考えたあれ」に戻るのがまあまあ面倒である。データの構造としては内容が基準になっていて良いのだが、それはそれとして「最近追加または編集したノード」が時系列順に並んでほしい。そういうことから、アウトライナーのノードに日時を記録し、それを元に時系列に並べたビューを作ればいいという構想が浮かんだ。そこにTwitter風にしたら面白そうというアイデアが加わってこういう形になった。
　さて今まで自分が書いたメモをずらっと並べるということは幾度となく試みたのだが、どうにもしっくりきていないところがあり、その原因は何かしばらくわからなかったのだが、多分「絵がない」ということだったのだと思う。ツイート履歴ならずっと見ていられるのだが、それはおそらく本文の隣にアイコンがあるからである。自分自身の（あるいは特定のアカウントの）ツイートを追う限り、ただ同じアイコンがひたすら並んでいるのだからアイコンに情報は何ひとつ含まれていないのだが、しかしアイコンを取り払ってしまえばいいかというとそれはそうではない。ただただ文字が並んでいるのを見ていると、内容がどうであるかには関係なく正直うんざりしてくる。私の中ではそれは文が読みやすいか否か以前の問題なのだろうと思う。
　また、今は親ノードのIDに対して＠を付けてメンションを飛ばしている風の見た目にしているが、最初はそうしていなかった。メンション風にする前、タイムライン上の各書き込みはそれぞれ別の話題に対しての書き込みなのに、宛先を明示していないと続けて読もうとしてしまい、頭が混乱していた。そのことに気がついたのでこの形にしてみたのだが、そうすると、見ただけでどこ宛てかはわからなくとも、宛先を表示していれば「どこかの何かに宛てている」ということが前提となるので、文脈の混在が気にならなくなった。それは普段、Twitterのタイムラインで当たり前にやっている脳の処理であろう。

マップ

　左側の平面配置は、アウトライナー部分のアウトラインについて、日付ノードを除いたものをCSSでいい感じに整えたものだ。アウトライナーでの表示と見比べるとこんな感じ。


　各階層について、兄弟ノードは横方向、子ノードは縦方向に並んでいる。各ノードのサイズは文字数と横方向の個数に応じて適当に伸縮する。階層が深くなると背景色が濃くなる（なんとなくそうしている）。

　私が作ったものを他の人が今ぱっと見てわかりやすく思うかは微妙なところだと思うが、私にとっては自分で作ったアウトラインが変形しているので（つまり書いてある内容は既に一度頭に入っている）、ひと目で全体の構造がわかるというありがたみを感じている。平面上にみっちり敷き詰められた状態で、更に各項目について文字数が多すぎるものはスクロールするようにしているので（項目のブロックが縦長にならないようになっている）、画面にはかなりの情報量が入る。
　また、topicのノードについて背景色を変えているように、data-type属性の値（≒アイコンの種類）によってCSSを変えて見やすくすることもできる。例えば結論用のアイコンを作って背景色を赤系統にする、ということをしている。
　なお、これも各項目をダブルクリックすればアウトライナーのノードがフォーカスされるのですぐ編集に取り掛かることができる。

簡易検索

　現状、AND、OR、NOT検索はできないが、特定のキーワードを含むノードをピックアップすることはできるようにしてある。
　検索を実行すると、アウトライナー画面は該当するノードの背景色が黄色くハイライトされ、タイムライン画面は該当ノードだけ表示されるようにフィルタリングされる。タイムラインは他に期間指定とdata-type属性（≒アイコン）でフィルターできる。
　あと全データから「#」を付けた文字列を取得してオートコンプリートを設定しているので（検索欄をクリックしたり↓を押したりすれば候補が出る）、Twitterのようにハッシュタグを使うこともできる。
　必要が生じれば、AND、OR、NOT検索をはじめもっと細かい高度な検索も実装するかもしれないが、今のところは別にいいかなという感じでいる。

　細かいところまで色々書いたが、重要なのはCtrl+←/→という簡単な操作でノードの属性を変えられるようにしたことと、アウトライン構造を維持したままアウトライナー的でないビューを実現したことだ。自分Aと自分Bその他の切り替えに何クリックも必要だったら続かないだろうし、せっかくメモが捗っても書けば書くほどビューに難を感じてしまったらしょうがない。
　今までアウトライナー系のツールは色々と作っており、どれもその時点では自分の中で革新的だったのだが、今回が一番会心の出来という感じがする。データ構造や必要な操作としてはシンプルで、自力でやらなければならない処理はほとんどなく、それでいて今まで抱えていたもやもやを一度に晴らせるものになった気がしている。

　ちなみにこのツールの保存形式はOPMLなので、Dynalistなど他のアウトライナーにそのままインポートできる（ただしdata-type属性は消失する）。
　

この記事はこちらの記事へのレスポンスです。

• のらてつさんのツール作成日誌の感想 - by Go Fujita - トンネルChannel

ブログ記事にご感想をくださりありがとうございます。はじめの方では身に余る賛辞をいただき、大変恐縮しております。

自分なら違うデザインにする、とお書きになっている二点についてお返事を書こうと思い、コメントではなく記事の形で書くことにしました。
Goさんと私の感覚の分岐点になっているであろう点として挙げてくださっているのが、次の二点でした。（勝手に換言して書きますがお許しいただきたく）

• 凝っていて複雑ゆえに飽き性だと続かないかも
• ログは重視してないから要らないかも

実のところ、「私もそう思う！」という気持ちです。というか、私もそうなので、これまで使ってきた全てのツールが続いていなかったりします。似た複雑性のツールは数多ありますが、それらはその複雑性ゆえ継続は悉く挫折しました。なぜなら、ツールの複雑性がそのまま私にとって複雑だからです。
ところで、「違う考え」を提示していただいたことに対する返答の形なので、変に緊張を呼びそうだなと心配していますが、全然反論や弁明などではなく、Goさんのご意見を元に私自身の解像度を上げることを試みようと思っています。お返事と書きましたが、ほとんどただ自分語りをすることになりそうです。

突然ですが、私は極度の飽き性です。だいたい三週間または三ヶ月サイクルで「形式」に対して飽きてしまい、種々のデータがばらばらの形式であっちこっちにあります。
飽きる理由は多分いくつかあって、「理想の格好良さに沿うべく無理している」ということもありますし「傾けられるエネルギーに波がある」ということもあり、そもそも「ただ飽きて続けられない」ということもあります。経験上、「ただ飽きる」のは「自分以外の人間が作った事物」に対してより高確率で発生します。というか必ず発生しています。偏屈過ぎて、自分以外の存在の感性に合わせ続けていられないのです。
あとは、「より良いものを思いついてしまった」ということも大きな原因になります。そうなると現行のやり方は全く気に入らなくなってしまうからです。「モノ」には愛着もわきますが、私の場合「やり方」には全然そういう愛着・執着を抱くことができないのです。
あまりにも飽きっぽくて生活にある種の支障が出ているので、自分の「飽き」について随分詳しくなってしまいました。すぐ飽きる自分に悩まされているのが嫌で、「じゃあどうしたら飽きないんだよ」と問い続けている状態です。

飽き性である自分に対してできることを考えた時、「飽きないようにする」と「飽きても良いようにする」の二通りのアプローチがあるでしょう。
「飽きないようにする」にはどうしたらいいか？　具体的な方策は人それぞれの性質次第ですが、私の場合は上述したような理由があるので、

• 格好良くするための無理をしないようにする
• 熱意の多寡に影響されないようにする
• （人が作ったものは確定で飽きるので）自分で作る

の三点が対策になります。
一つ目を言い換えると、「無理をしないと格好良くならない仕組みは駄目」ということでもあります。これは特に汎用的なツールを使う時に発生します。紙のノートでもそうです。私は情報のレイアウトを超が付くほど重要視していますが、自分が望む見た目を作らんとして、記入するたび認知資源を使う必要があるのがまずいのです。なので、JavaScriptの力で自動で整えてもらうことにしました。
二つ目の達成には、やる気に満ち満ちている時でなくても維持できるような簡単さであることが必要です。私の記事を読んでくださった方は、多分ツールの見た目が複雑そうなのでここがネックになるとお感じになったのではないかと思いますが、むしろここを確実に解消するためのあの複雑さ（仮）なのでした。
あんまり具体的に書くとさすがに冗長なので割愛しますが、例えば「作成画面を開いてから必要項目をチェック」だと面倒くさくて絶対飽きるので「この項目をチェックした状態で作成画面を開く」というボタンを設置する、というようなことをしています。普通のタスク管理ツールは「作成画面を開いてから情報を編集」にならざるを得ないと思いますが、それだと私の場合100%飽きることを知っています。
なので、裏で動いている処理の複雑さや見た目の「なんか選択肢と記入欄が多い」という印象とは裏腹に、「私の動線」からすると逆にシンプルになっています。これは私が作って私が使っているからのことであり、それぞれがそれぞれの設計をしないと意味がないところだと思います。

ここまでは「飽きないようにする」ための対処法ですが、「飽きても良いようにする」ことも必要になります。自分以外の人が作ったツールには必ず飽きますが、じゃあ自分が作ったツールには飽きないかというとそうとは限りません。最初の方で書きましたが、「より良いものを思いついてしまった」が発生したらもうおしまいです。そしてそれはしばしば発生します。（思いつくこと自体は喜ばしいことです。）
何かのシステムでやっていて飽きた時に困るのは、そこまでの形式で作ったデータが他のツールにそのまま持ち越せないことです。しょうがないので新たに始めることになり、まあ結局はそんなに生活に支障はないのですが、気持ちとしてはかなりの不満を抱える羽目になっています。ツールを替えてしまえばそれまでのデータは参照しづらくなり、バックアップデータを残したとしても、それらはもはや「記録」ではなく「残骸」になっています。
やりようは技術次第で色々あるかと思いますが、私の場合は、JavaScriptで処理をしているのでJSONファイルが救世主になりました。今後も自分でツールを作ることが前提になってしまいますが（それは私の中では先述した通りもう前提なのですが）、見た目や編集の方法に飽きるとしても、必要なデータの種類はあまり変わらないことから、JSONファイルを使い回せばツールを替えてもデータを持ち越すことが可能です。
実際、（タスク管理ではないツールですが、）データはそのままにツールの設計を大きく変えて作り変えたものがあります。新旧ツールの間に一応互換性があるということです。やがて改良の末に旧ツールには戻せない形になることはありますが、大事なのは旧→新の移行なので、逆向きの可否は重要ではありません。（それも旧ツールを弄ればどうにでもなります。）

長くなりましたが、「飽き」についてはこのくらいで、次はログの話です。
一応ずっと何かしらの形でログを取っています。飽き性ゆえにログの形式はバラバラです。というか、どこにいつのログがあるのかももはや定かではありません。どこかにはあるはずですが、取り出してくるのは容易ではない状態です。とても不本意です。
そもそもログが必要かというと、正直なところ、情報としてはあんまり必要性は感じていません。よく自分の傾向を振り返るために記録を見返すというような話を聞きますが、私はそういうことはほとんどしません。あまりにもフォーマットというものに飽きるので飽きる周期はどのくらいかを知るために見返したことはありますが、多分、それだけです。そしてタスクの実行記録に至っては、全く役に立った記憶はありません。記録を活用していないのです。
でも、私はこれからもログを取ります。データがどこにいったのかさえもはや判らないにもかかわらず、これまでログを取っていたことは私には大きな意味があります。
以前、私は精神の健康を損なってほとんど何もできなくなったことがありました。虚無感、無力感、無能感に襲われてまあ大変だったのですが、それ以来、頭の中を「私は何もできていない」という認識が埋め尽くすようになりました。今もそうです。多分一生残る後遺症だと思っています。（回復する人もいると思いますが、私には恐らく死ぬまで残ります。）
仕事をする、何かを書く、というようなことをすれば、もちろん私がした何かが世界や誰かの中には残るのですが、それを自分自身が認識していられないと「私は何もできていない」ということが私の中では真実になってしまうので、「私はこの日これをした」という証明書を自分に発行するために毎日ログを残すのです。私の脳は私自身がしたポジティブなことを忘れたがっているようで、一目で把握できる形で書き留めないと容易く「なかったこと」になってしまいます。そのくせネガティブなことは絶対忘れてくれない残念な脳です。
証明書を発行してしまえばあとは安心してその証明書は放置です。ちゃんと生きている感を実感したい時だけ眺めています。

盛大な自分語りになってしまいました。個人的なこと過ぎて自分のブログにすら書く機会を見出だせていなかったことですが、えいやと書いてみました。
もしかすると他の人の目には私が如何にもシステマティックなものが好きそうに映っているのではという可能性を感じなくもないのですが、実情としては、多分全然そうじゃないのだと思います。システマティックに生きなくて済むシステムを作ろうとしているような気もしています。
　

　プログラミング経験がないところからJavaScriptの勉強をスタートしておよそ八ヶ月になります。
　まだわからないことはたくさんありますが、難題だったコールバックや非同期処理をある程度使えるようになったり、Node.jsを活用できるようになったり、他の言語（AutoHotkeyとか）を多少書けるようになったり、コマンドプロンプトでGitを利用できるようになったり、プログラミングやコマンド周りの壁をいくつか乗り越えたところで、ここまでの所感をまとめておきたいと思います。（経緯についてご質問のメッセージをいただいたこともあり）

　これまでに他の記事に書いたことと重複する部分もありますが、あまりわかりやすく書いてこなかったと思うので、書き直すことにも意味があるだろうと思って改めて書くことにします。

　プログラミングをほぼゼロから学ぶにあたり、障害になっていると感じたことが三つほどあります。

• 日本語じゃない
• 人間用の言語じゃない
• プログラミング的発想を普段そんなにしていない

この三点です。
　まず一つ目、「日本語ではない」ということ。英語が得意な方にはあまり共感されないかもしれませんが、プログラムを書くために用いる言葉が母語ではないために、「言葉に慣れていない」ということを「プログラミングが難しい」と混同する可能性が結構あると思います。出てくる単語出てくる単語、いちいちイメージが浮かばなくて「調べないと動きが想像すらできない」ということになるわけです。それはプログラミングの難しさとは全然関係ないことですが、プログラミングに挑戦しようとして直面することなので、プログラミングの壁として立ちはだかるように感じてしまうところがあります。
　二つ目の「人間用の言語でない」というのは、特に所謂文系人間にはつらいところかもしれません。自然言語を基準にして考えると、プログラミング用の表現というのは全然直感的ではありません。形式はもちろんのこと、括弧の種類やピリオド、カンマ、コロンなど、日常的に目にしていても用法について考える必要があまりない記号類にも、それぞれ固有の意味があり、それらを正しく使わなくてはなりません。更には、「等しい」「または」「かつ」などを示す際にも馴染みのない記法をあれこれ覚える必要があります。そのうち慣れますし慣れれば自然と使えるようにはなりますが、最初の最初は外国語をイチから勉強するがごとき苦労があるように思います。
　これら二点については、私の場合はプログラミングの勉強を始める前に数カ月間CSSの習得に取り組んでいたことで、少しハードルが下がったように思います。CSSというのは指令を出して何かを動かすものではないので、プログラミング的発想の足掛かりになったわけではありませんが、コンピュータ的な記述方法で書いてコンピュータに解ってもらう、ということの訓練になりました。後から振り返ってそうだったのだと思ったことですが、人工言語に馴染む一歩として大きな役割を果たしていたと思います。

　三つ目、「プログラミング的発想を普段していない」というのは、プログラミング教育を受けていないわれわれ世代には少々高い壁になっているかもしれません。「～～と書けば……という結果が得られる」ということをいくら覚えても、それをどう組み合わせて何をする必要があるのかがわからなければ（思いつかなければ）、ツールとして使えるものにはなっていかないのです。
　この点について「こうすれば良いですよ」と語れることは私にはないのですが、私が心がけたことは、再現したいものについて「実際に何がどうなることになるのだろう」ということを熟考することです。人間の感覚で考えると自分にとっての「意味」に引きずられがちですが、「情報」がどう「動いていく」必要があるのか、どうすればコンピュータが解釈し得るのか、それを「こうすれば情報はきちんと然るべきところに辿り着くぞ」という確信を得るまで考える。
　プログラミングをする人は当たり前にやっているであろうことですが、プログラミング未経験者としては少し負荷が高いことに思えます。でも、確信を得た時の「これでいけるはずだ！」という発見の喜びは他ではなかなか得難い知的感動だと思います。

　私自身が具体的に勉強をどうしていったか、ということもまとめておこうと思います。完全に独学でやった場合のことであり、これが良いということではありません。

• 初心者向けの解説サイトで基礎を覚える
• その時点でできそうなことを色々やる（おみくじとかじゃんけんとか、ごく単純なメモツールとか）
• やりたいことを実現できるらしいメソッドを検索して試す
• ツールとして使えるものを色々作ってみる
• その後で本を読む
• メソッドを全部解説しているサイトを「読む」

　勉強を始める前に解説本をちらっと見たのですが、手を動かしていない状態でいきなり読んでもわけがわからないという感じがしたので、初動で本を活用するのは諦めました。（読んでイメージできる人は本の方がサイトより体系的で俯瞰しやすいので役に立つと思います。）
　ということで、Web上に情報を提供してくれていることに感謝しながら、Web上で見てWeb上のオンラインエディタで書いて試す、ということを繰り返して勉強しました。解説サイトとエディタが一体になっている学習サービスも色々あるかと思いますが、私は記事の連載の形で書かれたものを見ながらTypeScript: プレイグラウンド - TypeScriptとJavascriptを探求するためのオンラインエディタで試しました。（なおTypeScriptの記法に沿っていないJavaScriptのコードはエラーが表示されることがしばしばありますが、実行すれば動きます。私は最初の最初TypeScriptから始めたのでこちらをよく利用しました。）
　六番目の「メソッドを全部解説しているサイトを『読む』」というのは、メソッドを調べる時に辿り着くサイト（特にJavaScript | MDN）を、検索して辿り着いた部分だけでなく、書かれているメソッド全部について一通り読んでいくということです。私もまだ途中ですが、だいぶ解るようになってから読むと「なんとそんな便利なメソッドが！」と感動できます。

　勉強する中で、自分の中でポイントになったことが三点あります。

• 慣れないものは慣れるまで繰り返す
• よくわからないものはとりあえずスルーする
• 仕組み上難しいことは最初から諦める

　声を大にして何度でも強調したいのが、「慣れるまで繰り返してから次に進むべし」ということです。初心者向け解説サイトはとてもわかりやすく書いてあるので、読むだけで「なるほど」と思うことができます。しかし、じゃあそのページを閉じて今見たものを再現できるかというと、これがなかなかそうはいきません。そうできないと実際にプログラムは書いていけないわけですが、「なるほど」感の割に全然そうできないのです。「alert("Hello World!");」に「この程度のこと理解できないはずがない」と思っても、最初の最初はそれだけのことが見ないでは再現できなかったりするわけです。
　特に私が繰り返したのは「条件分岐」と「forループ」です。JavaScriptでツールを作る時、素人がやりたい範囲でツールらしさを構築する上で必要なことというのはほとんど「条件分岐」と「forループ」でまかなえるように思います。一方、素人目には一見して仕組みが分かりづらいものでもあります。If分岐は難しくないですが、do...whileやswitch文はちょっと考えないと捉えにくいように思いますし、forループに至ってはforに続く括弧の中に初期化式・条件式・加算式とあって一読で意味を理解するのは困難だと思います。とりあえず定型文として覚えて使えるようにすることが大事です。

　次に「よくわからないものはスルーする」ということが私の中では重要でした。今しがた書いたforループの中身も、もちろん最初に理解してしまえればそれが一番良いのですが、とりあえずは「ループ処理ができる」ということさえ獲得できればそれ以上のことはよくわからなくていいとしました。
　他にはアロー関数やコールバックがスルー対象でした。今はもうある程度わかるようになりましたが、最初はなんのこっちゃでしたし、まあ使わなくてもツールは作れるわけです。使えるようになってみると確かに劇的に軽やかにはなるのですが、それで「できること」が劇的に増えたのかというと、それはそうでもありません。
　他にも、私がやりたいことをスパッとやってくれるメソッドが言語の中に既に存在しているのに、その存在に気づいていなかったり、説明を読んでも使い方が理解できなかったりして、わざわざ自分で関数を作っていたということがかなりたくさんあります。多分プログラミングの巧者にコードを見られたら馬鹿だなあと笑われるような記述が山程あったと思いますが、でもプログラムは動くのです。jsファイルの中身さえ見られなければそれっぽいツールができているわけです。
　私の目的は綺麗なコードを書くことではなく、自分がほしいツールを自分で作って動かすことです。コードがどれだけダサくて汚くても、動けば私の勝ちなのです。そしてコーディングがわかってきたら、後から書き直して整えていけばいいことだと思います。いずれにせよ金をもらってやっている職業プログラマーじゃないのですから、そんなに構える必要はないと思っています。

　最後の「仕組み上難しいことは最初から諦める」というのは、なぜ自分でツールを作るのかということに関わることでもあります。プロが作ったちゃんとしたツールを使えるなら、そっちの方が断然賢明な選択です。プログラミングは魔法のようですが、多少齧った程度では全てを解決してくれはしません。
　難しいことは難しいがゆえに今ここで例示して説明することもできないのですが、例えば一つだけ挙げると、クラウド連携は早々に諦めました。Web技術（HTML、CSS、JavaScript）によってWebブラウザをツール化する時、セキュリティの都合上ローカルファイルにアクセスできないので代わりにDropboxやGoogleドライブと連携するという手があるのですが、初心者には些かハードルが高いと感じました（Dropbox連携はちょっとやりましたが、ログイン状態を維持する処理で挫折しました）。
　ローカルファイルを扱えない＝データをブラウザの中の保存領域に置くしかないというのはファイルの取り回しとして大きな制限なので、クラウド連携についてはこうできたらいいなと早いうちから夢想することになると思いますが、日頃種々のデジタルツールで当たり前にやれていることである一方自力で実現するのは容易ではありません。（なお、Electronというフレームワークを習得すればローカルファイルを扱えるようになるので、そこまでいければクラウドにファイルを置くということが自動的に可能になります。）

　プログラミング言語を習得するにあたっての所感はこんなところですが、そもそもどうしてプログラミングをやりたいのかということはよく考える必要があるかもしれません。
　私の動機は以前書いたので細かくは繰り返しませんが（JavaScript日誌：一歩進んだら十回足踏みせよ）、具体的にやりたいことがあったのと、「プログラミングができない」という劣等感を解消したかったというのが大きい理由です。記事を今読み返して「そうだったか」と思いましたが、ツールづくりをするということはそんなに考えていませんでしたね。まずどこまでできるものなのか全く想像がついていなかったので、何も思い描けていなかったのです。
　具体的に作りたいものが先んじてあればモチベーションとして強力なのは確かです。しかし、漠然と「プログラミングができない自分」に不満があるというだけでもチャレンジする意味は大いにあると思います。ただ大事なのは、いつも楽しくやることだと思っています。
　私はこの八ヶ月間ずっと楽しくJavaScriptのコードを書いていました。説明を読んでもちんぷんかんぷんなことはたくさんあって、「説明がわからない自分」に多少もやもやすることはありましたが、でもまあ、その記述がわからなくても、できるようになったことがたくさんある喜びと比べればそんなのは些末なことです。理解が及ばないがゆえにへんてこな自作関数山盛りでごちゃごちゃやっているダサさ極まるコードでも、自分でアウトライナーを作れたことの方が私にとっては重要です。
　ちゃんとやろうと身構えて取り組んでしまったせいで変にコンプレックスを増加させてしまったら元も子もありませんから、気楽なゲーム感覚でやるのが良いと私は思います。（過去にそうして失敗したという経験談です。）

　なお、いつも自分の挑戦について「自作ツールを作っている」というふうに表現してきましたが、「ツール」という言葉に含まれ得る範囲の中ではごくごく一部のことしかやっていないので、今度から「自作デジタルノート」と書くことにします。メモアプリやアウトライナー、付箋ツール、単語帳などのような、文字情報を自分が理解・操作・処理しやすいように加工したりピックアップしたりする種のツールということです。
　「なぜ自分でツールを作るのか」という問いを先程ちらっと書きましたが、私にとっては「自分が求める形で情報を表示してくれるデジタルノートが世の中に存在しないから」ということがその理由です。デバイスを横断する連携の可否よりも、自分が見たい形で見たいものを表示してくれること、自分が書きたい形で書ける欄を生成してくれること、その二つが遥かに重要なのです。
　デジタルノートツールを作るというのは、ノートの内容を格納したデータベースと、その内容をHTML要素に然るべき形で配置したりHTML要素からデータベースに内容を保存したりするスクリプトを用意することで成り立っています。逆に言うと「それだけのこと」なので、見た目の自由自在感の割に、必要な技術はそんなに多くはありません。プログラムの動きを確認しやすいこともあり、初心者でも気軽に挑戦できることだと私個人としては思っています。
　

　JavaScriptの勉強を始めて半年が過ぎた（1/27スタート）。
　三ヶ月経過した時点で振り返り記事を書いたが、今回も同じようなまとめをしておきたいと思う。自分用のただの日記である。

• ツール製作日誌：三ヶ月で劇的ビフォーアフター①‡‡‡自作ツール紹介編
• ツール製作日誌：三ヶ月で劇的ビフォーアフター②‡‡‡生き方改革編

　まず前回からの三ヶ月で新たに作ったツール群をまとめてみる。

①Fusen2.html

　三ヶ月前の時点で作ってあったFusen.htmlの改良版。当初は付箋の種類ごとに作成ボタンを作って別の経路で付箋を作っていたが、今回は付箋は一種類のみになっている。記述内容で付箋の種類を判定し、自動で然るべきHTML要素が構築されるようになっている。
　そして付箋の中に付箋をドロップするとアウトライン構造になる。現状ではアウトライナーとしての手軽さがちょっと犠牲になっているところがあり一長一短だが、構造が煩雑だった前バージョンよりわかりやすくはなっている。
　また、付箋の規格を統一したことによりOPML出力がスムーズにできるようになった。

②ToDo Manager（名前は適当）

　前にツール製作日誌：タスク＆スケジュール把握ツールで紹介したタスク管理ツール。
　ちょっとしたことだが初めて試した挙動というのが色々あり、地味にレベルアップしたように思う。特にinput要素を多用しているのでそのあたりはかなり鍛えられた。

③Protean Outliner（カード式アウトライナー）

　ツール製作日誌：カード式アウトライナー①機能説明編で紹介したアウトライナー的ツール。
　どこかにゴールがある考え事をする場所。ブログ執筆を含め、今現在書き物の類は全てここで行っている。あれこれ機能を実装しており、もはや自分にしか理解できないであろうツールになっている。
　なお、最初は「カード式」のつもりで作ったのだが、結局のところ「ルーズリーフ式」であった、ということをつい先日書いた（ツール製作日誌：カード式アウトライナー③カードっていうかルーズリーフだった編）。

④Knowledge Manager（名前は適当）

　辞書的知識を書き足していく場がほしかったので作った。
　それぞれのカードには名前を複数つけることができ、一覧では名前が全て列挙されている。「メインの名前+エイリアス」ではなく、名前が複数可の状態。各カードのノート部分（アウトライナーになっている）で名前を[]で囲むとリンクになるのだが、複数あるどの名前でも構わないようにしている。
　各カード内で一問一答のクイズを作れるようになっており、クイズ一覧表示でそれらがカードとして表示される。マウスオーバーで答えが表示され、覚えた時はクリックで現在日時を記録できる。そこからの経過日時に応じてクイズ一覧で表示できるカードをフィルターできる。
　Ankiに担わせたかった役割を（Ankiの起動と管理が面倒くさかったので）自作ツールで実現した形。
　なおカード一覧でもクイズ一覧でも、マウスオーバーで内容を確認できる。

⑤Mameronbuner

　豆論文作成・管理ツール。（内容の性質上全てモザイクすることに）
　Protean Outlinerでやりたかったけどどうもやれなかったことを、より豆論文に特化した形を作り直して達成できるようにした。
　ポイントはタイトルが不要なこと。カード一覧で表示されているのは本文の冒頭3行で、タイトルとして表示したいなら最初の行をタイトルらしくすればいいようになっている。
　各カードに格言的なものを登録できるようにしており（複数可）、例えば「格言・仮説」を選択するとカード一覧より小さいカードでその一文をそれぞれ表示できるようになっている。コードの構造としては④のKnowledge Managerと大体同じ。マウスオーバーで内容確認が可能。カード間のリンクも可。

⑥ミニゲーム類
　コーディングの練習としてちょっとしたゲームを色々作った。特に参考にしたものはなく、いずれもゼロから自分で考えた。
ハイアンドローゲーム

　表示されたトランプに対して次の一枚が高いか低いかを当てるゲーム（Aが最も高い）。
　トランプ1組が尽きるまでやれるが途中でやめてもよく、いずれでもその時点での成功率を見ることができる。
　単純なゲームだが、やり始めるとやめ時がわからなくなり延々やってしまう。かっぱえびせん状態。

ポーカーゲーム

　配られた5枚から一度だけ任意の枚数交換可能で、できた役が良い役だと嬉しいねというゲーム。役を正しく判定するためにif分岐をあれこれ考える必要があり、良いトレーニングになったと思う。

スロットゲーム

　alertを使ってリールごとに結果を表示してスロットっぽい見た目にしているゲーム。柄の並びは某RPGのカジノのものを使っている。
　今のところただカチカチやって揃ったら楽しいというだけのものだが、倍率の設定はしてあるのでカジノっぽくしようと思えば一応できる。

神経衰弱ゲーム

　番号を指定し、その番号に振り分けられている記号を揃えるゲーム。多分HTML要素（DOM操作）を使えばそんなに苦労しなかったのを、わざわざダイアログ上でなんとかしようとしたので無駄に悪戦苦闘した。その分経験値はそれなりに得た。

ハエたたきゲーム

　上の画像のように動く四角をクリックできると消せるというゲーム。
　指定したミリ秒単位で、指定したいくつかの動きの中から乱数で決定して動き回るようになっている。直進：左折：右折：停止を2:1:1:1にしたら生き物っぽさが出た（後退しないようにした）。別途指定した時間単位で増殖させることもできる。
　マリオペイントで育った人間としては、ハエたたきと言えば手に汗握る思い出深きアクションゲームなのである。＼アッー！／

　自分でツールを作ることの意義などは三ヶ月前に書いており（ツール製作日誌：三ヶ月で劇的ビフォーアフター②‡‡‡生き方改革編）、そこから今までの間に気持ちとしての大きな変化はない。前回書いた通り、プログラミングはいいぞ、という感じである。
　一方、この三ヶ月で技術的には結構進歩したように思う。DOM操作（今まさに画面の中に存在しているようなHTML要素群の操作）で出来ることというのは無限にあるわけではないので、三ヶ月前と比べて「結果として実現できていること」はそんなに変わっていないのだが、コードをうまくまとめることができるようになったことで書くスピードが上がり自由度が増し、後から見て意味がわかりやすくメンテナンスしやすくなった。コツを掴んだという感じがする。
　特に「クラス」と「インスタンス」の概念を理解してカスタム要素(Custom Elements)を作れるようになったのが非常に大きい。例えばアウトライナー機能をいつでもどこでも一瞬で用意できるのである。最初は本当に苦労したのだが、今はもう作り放題だ。

　もうひとつ、Electronでローカルファイルを扱えるようになったのが大きな進歩だろう。Electronというのは、Web技術（HTML+CSS+JavaScript）を使ってデスクトップアプリケーションを作ることができるフレームワークのことである。
　Web技術によってGoogle Chromeなどのブラウザをツール化できるのはとても便利で、プログラミング初心者には大変嬉しいことなのだが、セキュリティ保全のためブラウザからローカルファイルを編集することはできないようになっている。ローカルファイルを読み込むことと、手動でデータをローカルファイルとしてダウンロードすることはできるのだが、ローカルファイルをデータベースにしてリアルタイムに処理するということはできないのだ。
　となればダウンロードを忘れたら終わりなのかというと、ブラウザにはlocalStorageという保存領域があり、各ドメインに対して最大10MB（ブラウザごとに異なる）用意されているので、そこに保存すれば消えることはない。普通に公開されているツールも、データ保存のための通信を行わないものはその機能によってユーザーのデータをブラウザ内に保存している。ただ、そのPCのそのブラウザの中だけにある状態なので、データの取り扱いとしてはいささか不便である。
　そこでElectronなのだが（デスクトップアプリケーションを作成するのでローカルファイルを扱えるようになっている）、ElectronはJavaScriptの形式で記述するものの、色々とコンピュータ的に考えなくてはならず、JavaScriptのDOM操作が直感的なことに喜んでいた身にはかなり辛い。数学で言うと平方根が出てきたとか微分積分が出てきたとか三角関数が出てきたとか、そんな感じの段差である。
　今でもよくわかっていないのだが、とりあえずローカルファイルを読み込めてローカルファイルに書き出せるようにはなったので、まあそれ以上わからなくても当分はいいかなという感じでいる。（なお三ヶ月前の記事でElectronについて既に触れていたのだが、当時一応書き出し自体はできたものの、ごく限られた条件の元でしか実現できていなかった。セキュリティのためにメインプロセスとレンダラープロセスというふうに分かれており、その横断を理解するのがちょっと難しくて面倒だったため三ヶ月放置していた。）

　ツールのデータベースとしてローカルファイルを使えるということは、そのファイルがオンラインストレージ（Dropboxなど）にあればどの端末からもいつでも参照できるということである。また、ローカルファイルの読み込みも簡単になったので、例えばLogseqやObsidianで使うmdファイルを読み込むこともできるようになった。早速、Logseqのmdファイルで未来の日付をリンクしている箇所をピックアップしてHTML上に出力するコードを書いてみたりした。
　つまり他のちゃんとしたツールとの間に橋が渡されたということであり、このことは自作ツールの可能性を大きく広げるものだと思う。できることはおそらく爆発的に増えたのだが、自分自身がそれに全然追いついていないので、この先はゆっくり練っていきたいと思う。
　

Go Fujitaさんのこちらの記事に、

• ぼくのノートツールは Smalltalk と Org - by Go Fujita - トンネルChannel

次のようにあるのを読んで、少し考えました。（言及いただきありがとうございます！）

そして、倉下さんやのらてつさんと同じことはとてもできないしやらないけど、ぼくだったら何ができるだろうか、と考えるようになりました。　

私が使えるのは、JavaScriptがある程度とPythonが僅かばかりという状態ですが、倉下さんがお使いになっているのもJavaScriptとPythonなので、私は初心者ながらも倉下さんのお話はおおよそイメージを掴むことができます。どの程度の難易度のコードなのか、というのが大体わかるのです。
一方Go Fujitaさんが日頃お話になっている言語やツール（例えばSmalltalkやEmacs）については全く触れていないので、Goさんのお話は私にはおそろしく難解に感じます。何も知らないので「難しそう」と反射的に下す判断が当たっている保証は一切無いわけですが（実際、おそらく多くが間違っているのですが）、「難しそう」という評価を覆す体験を自分が一向に積まないので、「難しそう」という印象はそのまま残り続けてしまっています。
倉下さんや私がやっていることは当人からすると他の人にとって「とてもできない」ようなことではなく、またGoさんがお話になっているSmalltalkなどについてもGoさんからするとそこまでハードルの高いものではないのではないかと推察しますが、扱える言語が違うだけでなんだかとても高くて厚い壁が立ちはだかっているかのような気分になってしまうように思います。まだどの言語も知らないプログラミング未経験者からすると尚の事でしょう。ある言語の特徴などを抽象的に語ると、その言語を知らない人からすると「全く何を言っているかわからない」ということになってしまうからです（小一時間勉強するだけですぐわかるようなことであったとしても）。

私が「こんな感じに自作ツールを作ったor改良した」「プログラミングを始めて○ヶ月でこのくらいだ」という話をするのは、「右も左もわからないド素人でもちょっと齧れば結構なことができるぞ」ということを伝えたいからです。
しかし一方で、「結構なことができる」を言いたいがために情報量を増やしてしまうと、まだその言語に挑んでいない人を逆に圧倒してしまう可能性があるとも感じています。すごいのはあくまでプログラミング言語なのですが、プログラミング言語を使う私がすごいかのように見えてしまう、という感じがします。他の人の語りに対して、私自身がそう感じています。（もちろん「プログラミングしている人」に個々のすごさというのがないわけではないでしょうが、プログラミング言語に対する「わからなさ」が「すごさ」の評価にどかっと上乗せされがち、という印象があります。）

伝える側として、これを解決するにはどうしたらいいのだろう、と時々考えます。しかしまだ答えは出ていません。
具体的なコードを公開するのはひとつの手かもしれませんが、しかし私個人の体験としては、先に「難しそう」を取っ払ってからでないとどんな簡単なコードも難解に見えて圧倒されてしまいます。「console.log("Hello World!"）;」でさえ、文字で見るとウッとなる可能性があるわけです。
私がJavaScriptの勉強を始められたのはいくつか具体的な動機があったからで（以前自分のブログ（JavaScript日誌：一歩進んだら十回足踏みせよ）で書きました）、誰かの導きの力というのはそれほど大きな意味を持ちませんでした（影響が全くなかったというわけではないにせよ）。そう考えると、誰かに「最初の一歩」を踏み出してもらうための後押しというのは、どう頑張ってもなかなか難しいのかもしれません。
ただ、例えばJavaScriptを勉強してみようという時に、「勉強するはいいけど最終的に何ができるんだろう」と思いながらやるよりは、「○○（※任意のツール名）の代わりになるようなツールを作れたりするらしい」というようなイメージがあった方がワクワク感は持てるような気はしています。Goさんは記事の中で「気取ることなく楽しそうに、サイトやウェブアプリ (?) をつくっているようすをみて、刺激を受けている人も多いと思います」と書いてくださっていますが、そのように「楽しいものだ」という印象をもたらすことができているとしたら、それは小さくない意義があるのではないかとも思います。

また、もしかすると個別のプログラミング言語の話や成果物の紹介よりも、「ツールというのはこれがああなってこうなってそうなるものということだ」的な、メカニズムの把握の仕方の方が「最初の一歩」の後押しとしては大事なのかもしれません。学校でプログラミング教育を受けていない私たちには、その部分にボコッと穴が空いている気がします。
例えばブラウザで動くメモツールを作るのだとすれば、まず「メモツールというのは、テキストエリアを用意し、そこに自分が打ち込んだテキストがどこかに保存され、起動時にそれを呼び出すことができるものだ」という認識が必要です。逆にそこまでくれば、「JavaScript テキストエリア」「JavaScript データ 保存」とかで検索するだけで大体どうにかなるのです。やりたいことがはっきりしてさえいれば、それが実現できるまで調べればいいので、投げ出さない限りそのうち正解に辿り着きます。

私はプログラミングそのものを人に教えられるほどプログラミングのことを知りませんが、日曜大工のように趣味として自分のためにプログラミングすることがもたらす豊かさへの感動を人一倍抱いていると思っています。（日曜大工的にプログラミングする人のことを「サンデープログラマー」と呼ぶようですね。）
どうしたらその感動を活かせるだろうか、ということを今後も考えていきたいと思います。

　前回の続き。JavaScriptを勉強して情報管理ツールをいくつか作ってみたというのを前提に、何を得たのかをまとめておこうと思う。

• ツール製作日誌：三ヶ月で劇的ビフォーアフター①‡‡‡自作ツール紹介編

　まずプログラミング周りの自分の到達段階はこんな感じ。

• （HTML、CSSは2021年中におおよそ習得）
• （SCSS、mermaid.jsを1月中に大体理解）
• JavaScriptのDOM操作をある程度理解
  • TypeScriptをちょっとやったけど結局直接JavaScriptで書いている
• Node.jsとElectronを少しやった（作ったツールを移植して動かせるようにはなった）
• Pythonの基本的な操作を学習

　ツールを作れたというのはつまりデータを扱うということができるようになったということだが、そのことによって世界が劇的に広がったように思う。プログラミングの勉強を始めてすぐは、何かが「動く」というだけでデータのセーブ・ロードはできないので、自力でコードを書けることのありがたみをなかなか感じられない。
　データの扱いは以下の順番で学習していった。

• ローカルファイルのCSVを読み込んでJSONにする（というコードを拝借して使う）ことに成功
• localStorageへのオブジェクトの保存・呼び出しを理解
• localStorageにHTMLをそのまま保存する手があるのを理解
• GitHub Pagesで公開状態にしたデータをfetchすることに成功
• Electronを使ってローカルファイルを読み書きすることに成功
• データの保存・読込時にHTMLとOPMLを行き来するやり方を習得
• Promiseで確実にデータの読み込みが完了してから次の処理をする構造を理解（サイズの大きいデータを扱えるようになった）

　つまり、「ブラウザにデータを保存できる」「ローカルファイルを直接読み書きするという手もある」「ネット上に公開されているファイルを読み込める」「独自ツールでもOPMLにして種々のアウトライナーと互換性を持たせられる」ということができる状態である。ここまでのことならそんなに高度な技術は必要なく実装できることがわかった。クラウドが扱えたらスマホでもアクセスできるのになあと思うのだが、まだそこまでのスキルは得ていない。
　しかし、ここまでできたならDropboxかGoogleドライブか何かしらの何かでいけるのではないかという気がしてくる。実際どうかはまだよくわからないが、「できるのかもしれない」と考えられるようになった。三ヶ月前はそういう可能性など僅かにもなかった。

　プログラミングを勉強し始めて、気持ちや考え方の面でかなりの変化があった。
　一言で言えば、生活がとても豊かになった。物的経済的には別に何も変わっていないが、想像力と創造力が飛躍的に高まったような感じがある。
　他のツールに対して不満を抱くことも減った。そもそも自作ツールのことばかり考えて他のツールのことはほとんど意識を向けてもいなかったということはあるが、何かに不足を感じても基本的に「その要素を足したツールはどうやったら実装できるかな」と考えるようになった。
　もちろんできることには限りがあるが、私がやりたいことというのは基本的に「テキストデータを良い感じに表示する」ということだけなので、必要なスキルは初歩的なものだけで済む。やろうと思えばどうにか実現できる。プログラミングの経験がない人の目にはもしかしたら何かすごいことをやっているように映ったりするかもしれないが、数学にたとえると、三角関数でも微分積分でも行列でもなく、四則演算とせいぜい平方根を使う程度のことをやっているようなものである。その組み合わせを工夫しているというだけだ。
　元々日曜大工的なことは好きで、特定の用途に合う容れ物や何かの位置を固定するものなど「あると便利だが名前をつけがたい何か」の類を色々作っていた。自分が得意なのはそういうアナログな工作であって、デジタルなものはちょっと苦手だなという意識がずっとあったのだが、今は日曜大工と同じ感覚でコードを書いている。家は建てられないが棚は作れる、という感じだ。

　ツール作りに取り組むにあたって、「痒いところは自分で掻く」を合言葉にしている。
　頑張れば作れると思えるようになったことにより、デジタルツールに対して自分が本当に求めていることは何かを細かく考えるようになった。思いつくのは空想ではなく実現可能性のあるアイデアである。以前ならただ「こうだったらいいなあ」と思うに留まるほかなかったが、今は「無いなら作ればいいじゃん」と思う。
　誰かがやってくれるのを待つしかなかった生活から、頑張れば自力でなんとかできる生活へとデジタルライフが転換したのである。何が何だかさっぱり分からなかった世界で主体性を手に入れたことは、精神的に劇的な変革をもたらしたと感じている。ますますデジタル化が進む中でも自分の生活をコントロールしていられるかもしれないという希望がある。
　だからみんなもやろう、と簡単に勧められるわけではないが、しかし未経験者が思っているほどプログラミングは遠い世界のものではないというのは確かである。
　「alert("Hello World!");」の一行から人生は変わるかもしれない。
　

　JavaScriptの勉強を始めておよそ三ヶ月になる（1/27スタート）。この間に自分のデジタルライフは大きく変わっていった。

　まずHTML+CSS+JavaScriptの三要素を習得したことによって、ある程度実用的な情報管理ツールを作れるようになった。
　現時点で形を成しているツール・サイトが六つある。それらについて書いていくが、ツール名が「～.html」となっているのは「名無し」と同じ意味。

①Bookmarks.html（ブラウザ上）

　ブラウザのブックマーク機能にどうもしっくり来ておらず、どうしてもリスト状でない形のブックマーク管理ツールが欲しかった。既存のブックマーク管理サービスは多機能過ぎ、しかも見た目もぴたりと好みにはまらないので、自分で作るほかなかった。
　この見た目と機能はHTML+CSSだけで作れるのでJavaScriptの勉強開始以前に既に完成していたのだが、データがHTMLに手打ちだったため整理があまりにも面倒だった。そこでCSVにデータを作ってJavaScriptで読み込んで要素を構築できたらどんなにいいだろうと思ったのが、JavaScriptを勉強し始めた動機のひとつである。
　コードの長さは130行。ブラウザ上での編集機能は無し。

②Cards.html（ブラウザ上→Electron）

　CSVから要素を作れることがわかると、今度は他に整理がついていないものを同じ方法でどうにかしたくなった。その頃倉下忠憲さんのTextBoxの話を見聞きしていたこともあって、「すぐには使わないがいつか使えそうな気がするメモ」を溜めてピックアップするようなツールを作ろうと思ってこれができた。
　JavaScriptの勉強の最初の方で乱数を繰り返し使っていたので、乱数でメモをランダムピックアップするというのがその時点ではごく自然な発想の展開だった。
　作り始めた時点ではローカルのCSVからデータを構築してブラウザで見るという「メモビューワ」だったが、途中でlocalStorage（ブラウザへのデータの保存）の使い方を覚えたので「メモエディタ」にクラスチェンジした。それに伴いJSONの扱いにも慣れ、カードのメタデータを細かく設定したり編集履歴を保存できるようにしたり色々な機能を盛り込んだ。
　コードの長さは500行。

③Outline.html（ブラウザ上→Electron）

　普段アウトライナーを使っていて、項目そのものに種類がないことが不便に感じる瞬間があり、それをなんとかできたらいいのになと前々から思っていた。例えば引用をメモする時に、引用文と引用元の情報とは見た目が明らかに違っていた方が良いといったことだ。例えばDynalistではカラー機能とCSSを組み合わせて書式を作るというようなことも不可能ではなく、色々工夫してはいたのだが、なんとなく納得しきれないところがあった。欲を言うとバレットが項目の種類ごとに別のアイコンになったらいいな、というようなことを思っていた。項目にメタデータを設定したかったのである。
　Drummerというアウトライナーが少し前に登場したのだが（アウトライナーの父、デイブ・ワイナー氏が開発）、各項目に完全に自由にメタデータを付与できることに衝撃を受けた。その上Drummerではなんとツール上でJavaScriptを操作できるので、多分勉強すればDrummer内で自分好みのデザインを作り出せるのではないかとも思うのだが、ワイナー氏の感性に最適化されたツールゆえに色々難しく、具体的に何をどうしたらいいのか見当がつかなかった。
　なので、もういっそ自分でアウトライナーを作ってしまえと思ってやってみたのがこれである。
　出来はどうかというと正直に言って微妙なのだが、とりあえずこのくらいのものは自力でなんとかなるらしいということがわかったのはものすごく大きな一歩になった。ドラッグアンドドロップ操作やショートカットキー設定、複数箇所を同期してデータ更新するといった、一段複雑な処理ができるようになった。気分としてはメタルキングを倒した感じである。
　コードの長さは1100行。倍以上に増えた。

④Fusen.html（ブラウザ上→Electron）

　具体的なきっかけがあったかどうだったか忘れたが、ふと自由配置の付箋ツールを作りたくなって制作し始めたのがこれ。とにかく色々貼りたいと思った。
　アウトラインのブロックを動かせたら良いのにということはずっと前から思っていて、例えばExcel上にメモブロックとしてアウトライン機能付きのテキストボックスがあれば絶対便利だみたいなことをイメージしていた。Excel上に生み出すことはできないが、とりあえず画面上で自由に配置できたら色々使い勝手が良いだろうと思って付箋のひとつとしてアウトライン付箋を作ってみた。（なおデスクトップに貼っておけるタイプの付箋ツールとしてはsosuisenさんが開発していらっしゃるものが興味深い。）
　アウトライン付箋を作ったのは予想通り便利だったが、別にアウトライン付箋を貼りたいがためのツールではなく、他に画像、YouTube動画、mp4、mp3を付箋として貼れるようにした。お気に入りの絵画や音楽などを一度に視界に入れたかったからである。実際の画面は見せられない且つ適当なサンプルを用意するのがちょっと億劫なので見た目の紹介は省略。
　このツールを作ったときには「お気に入りのものを集める」以外の使い方はそんなに具体的にイメージできてはいなかったのだが、調べ物のメモに使ったところとても便利だった（上のスクリーンショットがその状態。なおメモの内容は誤りを含んでいる可能性がある）。「この情報をどのくらい視界に留めておきたいか」というようなことをコントロールできるのが良い。ページやカードで内容が分かれてしまうものだと、その点であまりうまくいかなかったのである。
　コードの長さは880行。

⑤のらてつの茶の間（ミニブログサイト）

　Twitter（ないしScrapbox）とブログの間の存在が欲しいと思って作った。
　ScrapboxやObsidianのリンクを参考に、「このノートでリンクにしているキーワード」「このノートに対してリンクしているノート」「他のノートではリンクにしているがこのノートではリンクにしていないキーワード」「このノートに対して言及しているがリンクはしていないノート」をガッと表示できるようにするなど色々工夫している。このサイトについては別途記事を書くと思う。
　サイトの挙動はいいのだが私の文章生産速度がそれに全く見合っていないのが目下の悩み。内容が遅々として増えていかない理由は明白で、プログラミングばっかりやっているからです。
　コードの長さは650行。エディタ機能がない割には長い。

⑥Plane Outliner（ブラウザ上）　

　これについては先日記事を書いたので挙動についての言及は省略（ツール製作日誌：「面のアウトライナー」）。
　デザインは茶の間を流用しているので、ツールの見た目としてそれまで恒例になっていた和柄からは離れたことになる。このブログや茶の間と同じ雰囲気なので特に違和感はない。3×3のマスにグレーを2段階使っているので背景はなくて正解という感じがする。
　「ここに来てやっと、初めに勉強した教材の意味がわかった」と感じる瞬間がしばしばあった。オブジェクトはこう使えばよかったんだとか、無名関数はこう使うのかとか、色々腑に落ちた。これまでのツールは馬鹿の一つ覚え的に同じやり方を繰り返していたところがあったが、ふっとそこから抜け出せるようになった感じがある。
　コードの長さは1900行。記述が圧倒的に多い。しかし多い割に随分クリアな感じがしている。

　このような感じで、プログラミング経験値ほぼゼロの状態から三ヶ月間であれこれやってきた。今回は作ったものの紹介までにして、次の記事でこの三ヶ月で起きた変化などについて書いていくことにする。
　

　ここのところ、HTML+CSS+JavaScriptでマンダラート的ツールの自作に取り組んでいた。
　現時点で搭載したい機能は全部搭載完了したので、この辺でブログに書いておきたいと思う。
　なお、後述するが今のところ公開は予定していない。いつかするかもしれないが、少なくとも今すぐにはできそうにない。

　さて画面はこんな感じ。メインの3x3とその下のノート欄で内容を編集できる。項目は右のアウトラインでも確認できる。

　マンダラートっぽい俯瞰モードもある。

　特定の項目以下の範囲で検索かけられたり（項目は複数指定可）。

　他にもノート欄に他の項目へのリンクを貼れたりバックリンクを確認できたりハッシュタグ機能があったり、自分が欲しいものは頑張って全部搭載した。一方で余計な機能をつけると、できることが増えただけにもかかわらず、何故かそれまでやれていたことが逆にやりにくくなってしまったりするので、例えば画像を貼るなどといった機能は付けていない。

　このツールを作り始めたのは、先日うちあわせCastでマンダラートの話をされていたのを聞いて、「そういえばやろうとしていたことがあったな」と思い出したからである。
　その当時はあっさり挫折したのだが、それはマンダラートというメソッドが合わなかったとかではなく、道具として継続的に使いたくなるものがなかったからである。紙に書くとなると綺麗に作るのが結構難しいし、個人的な好みの問題としてマスの中に手書きした時の見た目がなんだかあまり好きじゃなかった。一方Excelを使うとなると、それもそれでその当時は如何にもExcel感漂う見た目のものしか作れず、いまいち愛着が湧かなかった。
　そこで、プログラミングのスキルを少し得た今マンダラートというものを考えた時、自分で専用のツールを作れるのではないかと思ったのである。アウトラインと組み合わせること、上階層表示や任意の項目のプレビュー（マウスオーバーで表示）を用意することを思いついて、よし作ってみようと思い立った。

　そんな感じだったので作り始めた時点では「マンダラートのツール」を作るつもりでいたのだが（そしてつい一昨日まで「マンダラートツール」と呼んでいたのだが）、実のところ、自分の中ではそういうものではないなという感じがする。
　如何にもマンダラートな見た目であり、子項目を展開した81マスの俯瞰もできるわけで、もちろんマンダラートのメソッドを実践することは可能である。中心にテーマを置き、掘り下げるべきことを8項目設定し、それぞれについて発想を膨らませたり詳細に検討したりして全体像を作るということは、当然ながら普通にできる。
　ただ、自分がこれを使っていて思うのは、マスを埋める力によって前に進んでいけるということよりも、「上から下に並べなくて良い」ことが私の中で大きいということだ。つまり、アウトライナーの変形としてのこの形という認識がある。
　それを強く感じたのが、日記を書いてみた時である。
　具体的な中身は見せられないので空欄の状態だが、一週間の俯瞰モードのイメージはこうなる。

　各日に起きたことや注目すべきことが8個を超えることはあまりないので、基本的にはこれで全部を俯瞰できる。8個を超えたとしても、別に1項目に1つのことしか書いてはならないというルールはないし、粒度の小さなものについては「○○/××」みたいな形で詰め込んでしまえば俯瞰は可能だ。
　Kakauのような特別なものを除き、通常のアウトライナーだと一列に縦に並ぶので、81行を一画面で俯瞰することは難しい。何らかの手段で2列表示できるようにするか、表示サイズをかなり縮小するかという手はあるが、手段としてちょっと強引であまり現実的には思えない。しかしマスにしてタイル状に並べてしまえば可読性を保ったまま81項目（重複部分を除けば73項目）を一覧することができる。
　81マスを一度に確認できるとなると、それまで必要を感じていた「一週間の俯瞰のためのまとめ直し」が全く不要になるので、全体像の把握が随分楽になる。なお、まとめ直しではなく「一週間の振り返り」については、週の8マス目が空いているので、そこに書くことにする。
　また、空欄が多い日は「普通に特別なこともなく滞りなく進んだ」というのがわかるし（あるいは「忙しすぎて何ひとつ書けなかった」という可能性もある）、みっちり詰まっていれば「たまたま色々なことがあった」「てんてこ舞いだった」というようなことがわかる。この場合はひねり出して8マス埋めようとしない方がその後情報として意味を持つわけである。

　アウトライナーを使っていて、アウトライナーの持つ構造や操作性は情報（特に文章）を扱う上でとても良いものと感じているが、個人的には縦に全部並ぶ見た目に馴染めないところがあった。スクロールを繰り返してうろうろするのにはどこか「頑張って使っている」という感がある。それは眺めながら把握するためにやることなので、じゃあ検索でジャンプすればいいじゃんという話にはならない。
　おそらく根本的な問題（？）として、「文章を書くために使っているわけではない」ということがあるだろう。もしも文章ならば、完成形がリニアなので、そこに至るまでのアウトラインがリニアに表示されることには何も違和感がない。私も執筆作業にマンダラート風の見た目を取り入れたいとはあまり思わない。本を読んでメモするにあたってはマス目を埋めて俯瞰するとわかりやすいと感じているが、自分が書くという時は少し話が違ってくるのである。現にこの記事を書くためのメモはMarkdownで箇条書きして作った。
　ゆえに、「線のアウトライナー」と「面のアウトライナー」の二つが必要なのではないか、と思うのである。万人に必要かはわからないが、とりあえず私には必要だったように思う。そしてマンダラートというアウトライナーとは一応別物として存在しているメソッドの形態が、アウトライン表示の追加やドラッグアンドドロップ操作の実装などにより、結果として「面のアウトライナー」と呼べそうなものになった。なので、最初は自分が作っているものを「マンダラートツール」と呼んでいたが、最終的に「Plane Outliner（平面のアウトライナー）」と名付けることにした。
　「面」の形にすることで発生する制限としては、各項目に子項目が8項目までに限られるということが大きい。ただ、個人的な体感としては、十や二十の項目がずらっと並ぶ状態は構造の粒度がうまくないことが多い。あるいは、「ツリー状に列挙できる」ということによってのみアウトライナーを使っている状態で、アウトラインをプロセスする的な扱いの必要のない情報の場合である。それはそもそも「面」の形にする必要がなく、通常のアウトライナーやEvernoteやScrapboxなど他の数多の情報管理ツールから選択すれば良い。
　ただ、本を読んだメモをこのツール上で取りたいと思っており、その場合には何かしらの基準で8冊ずつに区切って格納することが必要になる。ジャンルや年月日で区切っていくことになるだろう。そうすると階層が形式的にどんどん深くなってしまう可能性があるが、「Plane Outliner」に於いては、リンクやピン機能ですぐアクセスできるようにすることは可能だし、検索機能もあるので辿り着くのに苦労するということを避ける手立ては一応ある。

　「面のアウトライナー」では、情報はツリー状かつ放射状に伸びていくので、マインドマップと似たような構造になる。マインドマップ的な使い方をすることも可能であろう。
　ただマインドマップとは異なり、紙面の制約に悩まされることはない。各項目が数十字の文章になっていても（それが適切な粒度かは別途検討が必要として）、場所を取りすぎてマップを作る邪魔になるということにはならない。
　もちろんマインドマップでしかできないこともあり、それは例えば二段階以上先まで含めた俯瞰である。とりあえず現時点での「Plane Outliner」では、マンダラートらしい81マスの俯瞰まではできるが、それより更に潜った先を含めて一望することはできない。もしその先の内容まで含めたいならば、各項目をその下位にある内容を含めた要約的な内容にすることによって、その先を一覧できなくても把握できるようにするというような工夫が多少必要になってくる。とはいえ、全ての項目についてその項目を中心として81マス俯瞰ができるので、無理して一度に全体を見ようと思わなければ支障はない。
　マインドマップにそれほど思いを巡らせたことがないのでマインドマップとの類似点と相違点を詳しく語ることはできないが、ある程度共通したことができるということは確かである。マインドマップで考えたことを「面のアウトライナー」でまとめ直しても良いかもしれないし、そうすると更に通常のアウトライナーにも取り込みやすいかもしれない。

　今までいくつかツールを作った時にはできなかったことで、今回から導入に成功したことが、「OPMLでの保存・出力」である。OPMLとはざっくり言うとアウトライン構造の共通規格だが（多分）、これを生成できるようにすればOPMLのインポートに対応しているアウトライナーにそのままデータを取り込める。例えばDynalistに取り込めることを確認した。
　取り込み先で使っていないメタデータは削除されてしまうと思われるので、（メタデータが全て保存されるDrummerを除いては）データを行ったり来たりさせるのは現実的でないが、いざとなれば他のものに移せるという互換性を持たせられたことは自分仕様のツールを製作する上で大きな一歩になったことは間違いない。
　また今回の場合には、「面のアウトライナー」の形式で文章について考え始めたものの、これ以上は通常の「線のアウトライナー」でやったほうがいいな、となった時に移すという使い方も考えられる。アウトライン表示は実装してあるが、操作の感覚が通常のアウトライナーとは違っているので、ビューより操作性の問題でツール自体を変えた方が良い場合もあるだろう。

　ということで、マンダラート用ツールを作ってみたら結果的に「面」のビューを持ったアウトライナーとして新しい道が拓けたという話をした。

　ここまで語っておいて公開はしないのかという話だが、以下の理由により現時点では難しい。

• 微妙に解消されていないバグがある（コピペ周りが地味に厄介）。
• まだ自分で使っている期間が短く検証が足りないので品質が保証できない。
• 動くコードは書けているがツール開発の勝手が全くわかっていないので、ツールの公開についての常識がわからない。

　諸々解決したらそのうち公開するかもしれない。
　

　今年に入ってからJavaScriptの勉強をしている。1月27日からなので、一ヶ月半近くになったようだ。

　少し長くなったので今回の内容を予め示しておくと、①JavaScriptを勉強し始めた理由四つ、②勉強して得たこと、③勉強を進められた理由二つ（教材と取り組み方）、という構成になっている。

　仕事に必要なわけでもなく、将来仕事にしたいわけでもなく、ただ趣味として勉強しているのだが、今更勉強しだしたのにはいくつか理由はある。
　まず、これまでにHTMLとCSSの勉強をしており、あとJavaScriptを覚えればWebページに必要な知識が揃うはずだというのがひとつ。CSSを覚えてよく使うツールやよく訪問するサイトの見た目を整えられるだけでデジタルライフは随分豊かになると感じているが、ここまで来たらもう一歩進みたい。
　次に、以前HTML日誌：自分のためだけにHTMLを書くで書いたが、ローカルのHTMLファイルにwebブックマーク置き場を作っていて、そのデータをスマートに管理したいという具体的な望みがあったことが理由として大きい。一応ブックマークレットを用意して、コピペすれば適切なHTMLタグがついた状態で簡単に貼り付けられるようにしてはいたが、並べ替えたりするとなると手作業になるので非常に大変だった。ごちゃごちゃHTMLタグがついた状態だと何がどこにあるのかも見づらい。VSCodeなどでは構造を踏まえてアウトラインを表示できるとはいえ、とても操作がしやすいとは言えない。なので、データ自体はCSVなど別の形式で作っておき、自動でHTMLタグを生成して表示できるようにしたかった。そのためにはJavaScriptを覚えればよいのだということは予め判っていた。
　また、Scrapboxを使っていると他の人が作ったUserScriptを目にすることがよくある。便利なものは借りていくつか導入している。しかし、一体どの文で何がなされているのかさっぱりわからないのでカスタマイズが全くできない。何をなし得て何が無理なのかも想像がつかない。別にScrapboxを使う上でUserScriptをマスターする必要などないが、わけがわからないという状態でいるとどうにも気になって、そのうち理解できるようになれたらいいなと思っていた。
　最後の理由として、プログラミングに対して抱いていたコンプレックスをどこかで粉砕したかったということがある。かなり前にVBScriptとVBAを少し勉強したのだが、全くわからない状態から雰囲気はわかるというところまで（要するにたった一歩）は進んだものの、結局コピペの組み合わせが辛うじてできる程度で挫折した。今にして思えば単に勉強の方法が悪かっただけのことと思うが、当時は「何を読んでも細かいところで何言っているかわからない、他の人はこれできっとわかるのに」というような気持ちになって、楽しさ補正が全くかからない状態のまま、折れてしまうまで辛抱するばかりだった。「結局よくわからなかったなあ」という失敗体験をずるずる引きずってここまで生きてきたので、できることならどうにかしてスッキリ解消してしまいたかった。

　自分自身の備忘録のために書いているものでもあるので長くなったが、そういうわけでJavaScriptを勉強してみようと思い立って始めた。今年一年の間になにか小さいアプリケーションみたいなものが作れたらいいなということは漠然と思い描いていた。
　結論から言うと一ヶ月経ったあたりで自作アウトライナーができあがったので、今年一年の間にというふんわりした目標は開始ひと月の二月中に達成した。
　知っているメソッドはまだほんの一部で、自由にプログラムを作れるようになったとはとても言えないが、それでもおおよその文法はわかるようになった。ScrapboxのUserScriptを見ても、何が変数名で何がメソッドで何が関数かくらいはひと目で判別できるようになったので、読解できそうな希望を感じられるようになった。ちんぷんかんぷんだという時のなんとも言えない疎外感からは解放されたようである。Pythonなど他のプログラミング言語のことはまだ何もわからないが、まあ頑張ればなんとかなるだろうと楽観的に考えられるようになった。
　実際にできるようになったことの多さよりも、「できない気がする」と感じていた領域が無闇に果てしなかったのがある程度狭められたことが、自分の中では大きな意義に感じられる。

　自分としては相当な速度で習得したのだが、波に乗れたのには要因がふたつあるように思う。
　まず第一に、良い教材との出会いがあった。
　以前CSSの勉強をした時にJavaScriptも載っている分厚い辞典のようなものを手にしたことがあったが、当時はそれを読んでも全く身につかなかった。というか、やってみようという気にならなかった。知識は美しく整理されているし、調べたいことがはっきりしているならばすぐにその情報にアクセスできるであろう本だったが、ゼロから勉強するには向いていなかった。一応初学者向けのパートはあったものの、「理解しやすい日本語で書いてある」ということと「理解が進む形式である」ということは全然違うらしいと悟って本を閉じた。教材の選択を誤ったのである。その時はCSSが解ればよかったのでそれ以上JavaScriptには挑まなかったが、またしても小さな失敗体験を積む羽目になったのだった。
　その後若干の（本当に若干の）調査をした結果、どうせならTypeScriptというものを知った方が良いのではないかと思い、TypeScriptを通じてJavaScriptを学べる何かがないかと簡単に検索をかけてみた。そしてさっと見つけたのがTypeScriptで学ぶJavaScript入門 - ＠ITというページだった。2014年の記事なので最新の情報ではないが（実行環境であるPlayGroundのバージョンが違うことによる影響があるような気がする）、書いてあるコードそのものはそのまま使えるし今のところ内容に不都合は感じていない。（後日追記：2015年にJavaScriptの大きな仕様変更があり（ES2015(ES6)）、そこで追加された機能が現在ごく当たり前に使われているため、より新しい情報を見た時に戸惑うことがしばしばある。考え方をインストールするものとしてはとても良い記事なので、コードそのものよりイメージを学習するものとしておすすめしたい。）
　たまたま見つけたこのページの書き方がズブの素人に丁寧に寄り添ってくれていたことで、至極滑らかにスタートを切ることができた。細かく説明してくれていることも重要なポイントだが、軽快かつ洞察力をひしひしと感じる語り口が初心者には大変ありがたかった。如何にわかりやすいと言えどさすがにさらっと一読しただけでたちどころに習得できるほど甘くはないが、何回か読み直してみようと思える文章と出会えたことにより、立ち止まったり前に戻ったりしてきちんと勉強することが苦行にならずに済んだ。他にも優れた教材は世の中に色々あると思うが、偶然苦労なく良いものと巡り合ったので基礎を学ぶにあたっては他の教材を探すことはしなかった。
　世の中には、その説明で解るならその説明がなくても解るのではと思ってしまう解説文がちらほらあるが、無理してそういったものと格闘する意味はあまりなさそうである。

　もうひとつの要因は、とにかく応用して反復したことである。
　急に当たり前感満載のうんざりする話になってしまうようだが、何も練習問題をひたすら解けという話をしたいのではない。例えば「alert("Hello World");」と書いて表示させてみようという話があった時に、じゃあ次は「alert("本日は晴天なり");」と書いて表示してみようと考える、というようなことだ。
　得られる結果は予想通りのものであって、それ以外の結果にはなりようがないのだが、それでも「（教科書の内容そのままではなく）自分で書いた通りになったぞ」という実感をその都度得るのは私にとって相当に大きな意味があった。変数を覚えたら今度は「var a = "のらてつ"; alert("私は"+a+"です");」と書いて、おおちゃんと表示されたぞと思う。掛け算を覚えたら掛け算の結果を表示する。console.logを覚えたら同じことをconsole.logでやる。わかりきっていても何回もやる。その度に「おお、本当にそうなった」と思う。そうなるのは当たり前だとしても「おお」と思う。絶対に、例をそのまま打って動かしただけで次に進んでしまわない。一歩進んだらその場で十回足踏みする。（気持ちの話であって、きっちり十パターンやるべしという話ではない。）
　用意された練習問題というのは「やれ」と言われているようで面倒になってくるが、「こうしたらこうなるのかな？」と自分で予想してやってみるのは何も苦にならなかった。なので今知っていることで何か他のことはできないかと考えてみる。足し算をやったら引き算をやる。掛け算をやったら割り算をやる。変数を覚えたらわざわざ変数の組み合わせで表現する。配列を覚えたら先にSwitch文の項で出たおみくじプログラムを配列を使って再現してみる。オブジェクトを覚えたら地方をキーとして値に都道府県を入れてみたりする。そんな感じで本返し縫いのようにその都度戻って補強していったことで、結果的に「既にやったことは大体定着している」という状態でじわじわ次に進むことができた。
　といっても、定着させるために反復していたというよりは、「もしかしてこうしたらこうなるのでは？」という予想が浮かんでしまい、それを実践して「ほら、やっぱり！」と思ってひとりで満足しているうちになんとなく定着したというのが真実である。なおfor文だけは苦手意識が強くあったので意識的に繰り返した。そしてコールバック関数は繰り返しが足りずにまだよくわかっていないのだが、応用例を自分で思いつくことがあまりできなかったためだ。
　プログラミングに才能のある人は一読しただけでスイスイ先に進めるのかもしれないが、どちらかというとただ楽しいからといった理由で「自然と反復した」というのが上達の鍵になった人が多いのかもしれない。学校の勉強のように義務として練習問題で反復させられるのは辛い。気がつけば反復していたという状態で勉強できたらそれが良いのだろうと思う。

　
　チャレンジしているもの→自作ツール - Noratetsu's Room（のらてつ研究所）