の作業記録
シゴタノ!な金曜日
- 作業記録の共有
- シゴタノ!
- ノート・エッセイ
- 読書メモリストを作る
- プレイリスト案
- ノートツールについての考察
10:00
おはようございます。今日は朝五時に目が覚めて、「ちょっと早起きしすぎた」ともう一眠りしたら9時まで寝てました。でもって、起きてかなり体が疲れていることを自覚しました。ちょっと最近作業を詰めすぎましたかね。
今日は、必要最低限のことだけやったら、あとはゆっくりすることにしましょう。
あとで読む:
シゴタノ!:
書きます。
* * *
1時間30分で、2800字くらいの原稿が書けました。これで今日の課題の半分はクリアです。
12:00
ノート・エッセイ:
書きます。
* * *
書きました。
publish:note:仕事もまたノートからはじまる / コンビニ店長時代のノート|倉下忠憲|note
13:00
book:buy:store:
『BRUTUS(ブルータス) 2021年 10月15日号 No.948[特集 村上春樹 上 「読む。」編]』
16:00
読書手帳システム:
| |
こういうのをボタンの数だけ書いているので、単一のサブルーチンにまとめます。
ファイル名を引き数にしたfunctionすればOK.これは簡単。
で、次。
| |
ボタン一つひとついついて。このように書いている。もうちょっと何とかならないか。
ボタンを作るためのJavaScriptを書く?
18:00
読書手帳システム:
わかっていたことだが、使っているうちにボタンが増えてくる。
でもって、そのボタンの機能の実装をどうするのか。
どこかにボタンのリストだけを持っておいて、最初の読み込みのjavascriptでそのデータからボタンオブジェクトを自動生成して配置する、というやり方がある。リストはたとえば、ローカルのファイルのリストを読み込むことで、こちらからは何も準備しなくてよい、ということができる。逆に言うと、こちらの「思惑」とは関係なく、存在するデータすべてのボタンができてしまう、ということはある。
一応、ボタンになるデータを収めたフォルダを作り、そのフォルダのファイルだけを対象にしたり、特定のファイル名にしておくことで、それを識別しにすることはできる。
が、どちらの場合でも、基本的にボタンは何かしらのソート順で「配列」されることになる。これはあまりアウトライナー的ではない。
何かしらでリストを作っておき、その順序でボタンを作る、というならば、そのリストに「意志」を込めることができる。個人的にはそちらの方が良さそう。
しかし、そうした方法を行っても、すべてのボタンが同じように配列されてしまうことは変わりない。自分で一つ一つボタンを置いていく場合は、特定のボタンを大きくしたり、あるいはちょっと離れた場所に置くことができる。そちらの方が具合がよいだろう。
よって、一応ボタンは自分でHTML的に配置する、ということにする。
しかしながら、今の書き方だと、HTMLでボタンを配置した後に、それに対応するonclickイベントを自分で書いて行かなければならない。これはさすがに面倒。
ということで、特定のclassを当てておき、初回読み込み時に、そのクラスのオブジェクトにonclickイベントを設定するコードを書くのは良さそう。まだ具体的なコードは見えないが、ロジックはだいたいイメージできているので、自分でも書けるだろう。
ボタンの配置と違って、このonclickイベントは基本的にすべて同じ処理になる。つまり「意志」の反映は必要ない。ボタンにする必要がないものは、ノートにするわけだから、その分け方で合っている。
で、buttonタグの属性(srcとかでもいい)にファイル名を書いておいて、それを参照するのもよいし、ファイル名+拡張子の「ファイル名」をbuttonの本文にしているなら、innerTextと拡張子でファイル名を自動生成することもできる。ただしその場合、txtとmdが混ざっていてはいけない、という問題はある。srcで、txtかmdを指定する。あるいは、何も指定がない場合は、mdにする、という分岐にすれば、もう少し応用範囲は広がるかもしれない。
まあ、mdでもtxtでも、拡張子が違うだけで中身は同じだから、そう大きな問題ではない。問題は、ファイル名とbuttonタグのテキストがかならず一致するかどうかだろう。あるいは、フォルダ分けをした場合などの問題もある。
フォルダをsrcで指定する、などをして補完してもいい。
すべてを同一のフォルダに入れておけば処理は楽だが、しかしそれはプログラマの理屈であって、ユーザーの理屈ではない。ユーザーの視点としては、フォルダが別々に入っていても、このビュアーでは何の問題もなく使える、という感じにしたい。なので、フォルダ分けの工夫も考えておきたい。
ここまでが次の一歩。
で、現状は単にマークダウンをHTMLに変換しているが、もう一歩進めたい。ダブルブラケット、ないしはシングルブラケットになっているごくのときは、それをbuttonにするのだ。
処理の考え方は上と同じでいい。innerText+.mdのonclickを添付する。で、そのボタンを押せば、表示されているテキストの内容が切り替わる。
この機能がつけば、一番大きなリンクはbuttonで配置して、それ以外はローカルのノートでリンクを作ることができる。ミニScrapboxのできあがり、というわけだ。ダブルブラケットにしておけば、Obsidianでも使えるメリットがあるが、しかし二つ付けるのは結構面倒ということはある。この辺は要検討。
とりあえず、その機能が付けばTopページはたまにいじるだけでよくなる。是非とも実装したい。
が、まずは、一括処理で、特定のclassのbuttonにonclickイベントを当てていく処理だ。
| |
一番シンプルに書いてみた。
繰り返しの処理。
【JavaScript】 getElementsByClassNameでforEachがエラーな理由と対処方法
ボタンのデザイン。
Buttons (ボタン) · Bootstrap v5.0
属性の取得。
JavaScript 属性値を取得/設定/削除する(Attribute) | ITSakura
たとえば、getAttribute(“type”)と書けばタグのtype属性を取得できる。だから、ここにフォルダを指定しておけばよい。拡張子も同じ考え方でいける。
21:00
読書手帳システム:
以前作ったシステムと組み合わせて、今表示しているファイルをVS Codeで開けられるようにした(日本語ファイルの処理が若干大変だった)。
ローカルサーバーをcgiで起動していないと使えないが、なかなかよろしい。
アイデアとして「このファイルをボタンとして追加する」みたいなこともできるか。まあ、HTMLを直接書き換えることになるのでややこしいか。そういうやり方をする場合は、むしろボタンのデータをリストで持っておくのが良さそう。
22:00
fragment:ノートツール考察:
倉下 忠憲さんはTwitterを使っています 「最近Googleカレンダーが「日記」になりつつある。後から「出来事」を書き込む、というような。」 / Twitter
いしたにまさきさん じゃあ、「これはToDoリストなのだろうか?と考えると違うわけで、あたらしい日報が必要なんじゃないかとも考えてはいますw」
新しい日報について。Googleカレンダーを日報的に使うこと。そのような用途、需要がある、ということ。
ToDoリストのように消化して終わってしまうものではない、日々の記録を残すためのツール。それもタスクシュートなどのようにリスト型でない形で。
本日の振り返り:
本日は疲労気味だったので、最低限の作業だけをしてゆっくりするつもりでしたが、たいはんの時間をコードを書いていました。が、かなりいい感じに整ってきました。少しずつ使いやすくしていきましょう。
というわけで本日はそろそろ閉店がらがらです。
お疲れさまでした。