ゆっくりしたい日曜日
作業記録の共有 Textbox+ハイパーインデックスの作成 今週の週報作成 来週のタスクの確認 8:00 おはようございます。本日はタスクの整理をして、残りはゆっくりします。 Textbox: 今Home画面にはPinBoardとページリストがあり、revノートには、シート、カード、付箋があります。 これを一つに統合したらどうなるでしょうか。 ＊ ＊ ＊ まず、一つのイメージとして、カードをボードに配置してみました。カードのpin。これはなかなか良さそうです。 ＊ ＊ ＊ 雑に一つのページにまとめてみました。 一応奇麗に動いています。 ＊ ＊ ＊ pinboard、ページリスト、シート、カード、付箋。これが一ヶ所に集まったページ。ハイパーインデックスと呼ぶとしましょう。 ＊ ＊ ＊ pinboardにカードを設置する（しても構わない）という着想を得たので、整理してみました。 よい感じです。 ＊ ＊ ＊ pinBoardに設置されるカード、たとえばevolvenoteのタスクカードなどは、card-listから生成されるというよりは、sheetから持ってくる感じが強い。あるいは、ページから。 結局ここが詰め切れていません。 textbox-evolvenote_task.mdなのか、jsonの１データとしてこれを保存するのか。これさえすっきりすれば、もろもろ進めていけるのですが。 ＊ ＊ ＊ 編集について考えます。 たとえばこのpinboardから消したときにどうなるか。あるいは、チェックマークを付けたときにどうなるか。そのときの「元データ」はどうなっていて欲しいか。 消したり、もう一度呼び出したりする。そういう操作において、ページかjsonかどちらがよいか。
メルマガを仕上げる土曜日
作業記録の共有 Textbox+新モードの検討 ツイート読み返し ツイートノート作成 メルマガ+「はじめに」「おわりに」 メルマガ+配信予約 ListLauncher+常時起動にしておく 8:00 おはようございます。今日はメルマガを仕上げます。あと、思いついた編集モードについて検討します。 Textbox: 作成したカードや付箋の編集をどうするのか、ということを考えていました。特に要素のクリックが次の媒体作成につながっているので、ダブルクリックなどが使いにくいのが問題です。 で、まずshift+clickを考えました。対象をshift+clickすることでそれを編集可能にする。たとえば、inputを表示して入力可能にするとか、contentEditableをtrueにするとかです。 これは良い手ですが、マウスだけで完結しない、という面倒さがやや気になります。それならば、コンテキストクリックの方がまだマシかもしれません。 ＊ ＊ ＊ もう一つ考えたのが、モードです。通常は編集できないですが、モードを変えることで編集を可能にする。たとえば、全体にcontentEditrableを付与する。そういうアプローチもありえるでしょう。ちょっとvim的ですね。 仮にそのアプローチを採用するとすると、そのモードの切り替え操作をどうするのか、という問題が出てきます。キー入力なのか、マウス操作なのか。前者は特定のキーの組み合わせ、後者はたとえばhtmlのbodyをダブルクリック、といったものです。 キー操作の方が自由度が高いですが、キーボードでモードを変える、マウスで対象をクリック、キーボードで入力、という流れが若干ひっかかります。ただ、MacbookAirを、つまりノートパソコンを使っている限りはそこまで気にならないかもしれません。 あるいは、編集モードに入ったら、tabキーで要素を選択していけるようにしてもいいでしょう。 マウスでモードを変えるのであれば、モードの変更→対象の選択→入力開始、とややスムーズにはなります。 ＊ ＊ ＊ モードで言うならば、現状Textboxは通常のプレビューモード（HTMLに変換して閲覧）と、ソースモード（mdファイルの中身をそのまま表示）の二種類がすでに存在しています。ここに新しいモードを加える、という感覚でもよいでしょう。そうであれば、キー操作での切り替えであったほうが統一的です。あと、他のページにおいても同様の操作が可能になることを意味します。 通常は閲覧だけで編集できないけども、ある操作をすればそれが可能になる、と。 現状は command + e でプレビューモードとソースモードをトグルします。たぶんeditの意味でしょう。 command + d （eの近く）、 command + i （inputの略）あたりがよいでしょうか。 ＊ ＊ ＊ そのモードに入ると、contentEdtitableがtrueになり、編集可能になっている状態を示すCSSが付与される、という感じでよいでしょうか。 個別の要素にcontentEdtitable属性とCSSを当てていくのか、それとも一番大きい要素（ページの要素を流し込んでいるdiv）に親的に指定するのか。後者の場合、CSSは個別ではなく、ページ全体に当てられることになりそう。 ＊ ＊ ＊ 一応、仮り組みができました。 モードをトルグし、グローバルな変数でページのモードを管理します。オブジェクト指向であれば、ページのオブジェクトを作り、そこにモードのプロパティを持たせるのがよいのでしょう。でもって、モードの切り替えも、そのオブジェクトに一任するのが良さそうです。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 var page = { state : "preview", setInputMode: function(){ this.
Web作業をする金曜日
作業記録の共有 RSP+ファイルのダウンロード RSP+プロジェクトファイルの生成 メルマガ+原稿1 メルマガ+原稿2 メルマガ+原稿3 メルマガ+原稿4 メルマガ+原稿5 Textbox+カード束の分解 8:00 おはようございます。シゴタノ！の締め切りがなくなったので、毎週金曜日はWeb周りの作業をする日と決めておきましょう。 基本的には新しいWebサイト作りに関する作業を進める予定ですが、その前にR-styleならびにHonkureの静的サイト化を進めたいと思います。 が、今週はまだメルマガが全然書けていないので、多少の作業だけして、残りはメルマガを書くことをします。 RSP: R-style Static-site化 Projectの略です。 長い期間進めていく必要があるので、プロジェクトノートを作りましょう。project-rsという名前にするか、rspないしはrs-pにするか。とりあえずrspとしておきましょう。 ＊ ＊ ＊ まずは、R-styleにアクセスして、Wordpressからアーカイブをダウンロードしておきます。 流れとしては、そのxmlか何かをmdファイルに分割し、hugoか何かに合わせて加工して、あとはそのhugoか何かでWebサイトにする、というもの。堀さんが記事をかかれていたので、それが参考になるでしょう。 ＊ ＊ ＊ ついでに、この話をメルマガでも書きましょう。 ＊ ＊ ＊ 情報源をまずScrapboxにまとめました。 WordpressからHugoに移行する - 倉下忠憲の発想工房 ＊ ＊ ＊ ファイルもダウンロードしました。まずはこれでOKです。 メルマガ: では、メルマガを。 ＊ ＊ ＊ 2000字の原稿を一つ。 ＊ ＊ ＊ 1800字の原稿を一つ。 11:00 メルマガ: 1500文字の原稿を一つ。 ＊ ＊ ＊ 1600文字の原稿を一つ。 16:00 メルマガ: 2000字の記事を一つ。 ＊ ＊ ＊ だいたい本編はこれでOKですね。 Textbox: 実験的に、一度カード束にしたものをカードに分解します。具体的には、 この束を下のカードの列に再配置します。
うちあわせCastな木曜日
作業記録の共有 Textbox+付箋の扱い うちあわせCast収録 Textbox+sheetの扱い 8:00 おはようございます。今日は午後からうちあわせCastの収録です。午前中は、昨日に引き続き付箋の扱い機能を実装します。 Textbox: 付箋を選択したときに、imaginaryCardを表示させるところまではできています。ここからの実装。 まず、そのimaginaryCardを編集可能にします。 ＊ ＊ ＊ contenteditableをtrueに。これは簡単です。 ＊ ＊ ＊ タイトル行を表示するように。 見た目は暫定で。 タイトル行はサイズを大きくしたいので、現状のコードでは厳しい。HTML的には見出しにすべきなので、現状のように単にテキストを連続して表示するのではなく、要素を追加したい。でもって、UL/liにして、アウトライン的な操作も可能にしたい。 ＊ ＊ ＊ 現状は、付箋がクリックされると、そのinnerTextが配列に保存されて、クリック操作のたびにその配列でカードの中身を生成している。操作がクリックだけならばこれで問題ない。しかし、カードの中身を編集できるようになると、この方式では難しいところが出てくる。 まず、追記されたテキストがあっても、付箋の操作があるたびにその内容が消えてしまう（追記されたテキストは配列に含まれていないから）。 次に、カード上で付箋のテキストが編集されとして、次に付箋操作をしたら、やっぱりその編集内容がリセットされる。つまり、カード上での編集を配列に戻すことが必要。 あるいは、配列を使わずに、付箋をクリックしたらその内容が単にHTML的にappendされるようにする？そのHTML要素に暫定的なIDを割り振って付箋とづけしておいて、付箋の操作と対応させる？ ふむ。だんだんややこしくなってきた。 ＊ ＊ ＊ カード上で操作をするたびに、その内容を配列に反映させるのが良さそうな気がする。 しかしそうすると、カード上で付箋の内容を書き換えたあとに、付箋を二回目のクリックをしても、それを消せなくなる（内容の一致で配列の要素を削除しているから）。それこそIDの割り当てが必要となる。 ＊ ＊ ＊ こういうときに、モードを区切れば話は簡単になる。まず付箋を選ぶモードがあり、その状態ではこれまで通りの動作ができる。で、編集ボタンを押すと編集がはじまり、そこでは並行して付箋の操作はできなくなる。その代わり自由にテキストを編集できる。編集モードに入ると、付箋とカードの接続は失われるので、お互いの編集は影響を与えない。 こういうモードの切り分けならば、上記のようなややこしい話は考えなくてもよくなる。が、あまり面白くはない。 ＊ ＊ ＊ ただ、現実的に考えたときに、カード上で編集した付箋内容をその後クリックして消したくなることがあるのかどうか。ほとんどないような気がする。 付箋の出し入れは、だいたいテキスト編集作業が始まる前までであろう。付箋を追加して、そのテキストを編集して、「やっぱり違う」と戻すなんてことはほぼ起きない気がする。 が、とりあえずID方式を少し考えよう。 ＊ ＊ ＊ 付箋をクリックしたときに、配列のlengthを見て、その長さ+1のidをattrで与えておく。カード上にliを作るときに同じidを割り当てておく。付箋がもう一度クリックされたらそのIDを見て対応するliを消せばいい。 では、カード上で行移動が起こったら？ その際、配列から要素を再描写してしまうと、IDの割り当ても変わってしまう。つまり、新しく付箋が追加でクリックされたら全体を再描写するのではなく、単にappendした方がいい。あるいは、配列にテキストだけでなくidも一緒に保存する（この場合は、ハッシュなどで適当な数字を当てておいてもいい）。で、カード上で行移動が起こったら、配列の順番も動かす。 ＊ ＊ ＊ 行移動の場合はともかく、keyupのたびに、それを配列に保存するのはあまりスマートではない気がする。まあ、気がするだけだけども。どうせそこまで大きい量にはならないし、複数開くこともないので可能ではある。 ＊ ＊ ＊ 整理しよう。 まず配列は「選択された付箋とそのID」を保存する装置だと捉える。で、追加と削除の場合だけ、それを使う。いや、というかそれならば別に配列は不要か。要素にIDを割り振って、あとは単にHTMLをappendしていけばいい。配列をまったく使わないパターンだ。 次に配列を、カードのもとデータだとする捉え方。すべての操作においてその配列を変更し、その配列をベースにカードを再描写する。 一見面倒そうだが、それぞれの操作で配列への処理を行い、あとはカード描写のfunctionを走らせればいいだけなのでコードの構造自体はシンプルになる。少なくとも、何をしているのかはわかりやすくなる。 とりあえず、付箋に加えて、追記される本文とタイトルの存在がある。配列を使わない場合は、描写されたカードがその保存場所となる。配列を使う場合は、そこにも本文とタイトルが保存される。 でもって、カードを書いた後には「保存」の作業が待っている。それは第一にページ上に他のカードと同じように配置することと、その内容をどこかのjsonに書き込むことの二つを意味する。その際に、どちらの方がやりやすいか。 まあ、あまり変わりないか。配列を使う場合でも、それはカードのもとデータであるわけで、結局カードそのものとほとんどかわりがない。つまり、どっちでもいい、ということだ。 ＊ ＊ ＊
断片の扱いについて考える
作業記録の共有 Textbox+付箋の扱い 8:00 おはようございます。原稿を進めたいところですが、もう少しでブレイクスルーしそうなので、昨日の続きを考えます。 Textbox: 一行だけの書き込みをjsonにまとめ、そのjsonを参照して以下のような表示を作りました。 で、問題はここからどうするか、です。これらをどのように操作して、どんな状態に持っていきたいのか。それがわかれば、フィードバックして、ここでの表示がどのようなものであれば嬉しいのかが見えてきます。 ＊ ＊ ＊ アイデア１．進化型。ここでの進化はダーウィンのそれではなく、ゲームなどでの進化です。 付箋が並んだUIにおいて、ある付箋を別の付箋に重ねるとそれが「進化」して、ステージが変わる。つまり一つ上の領域に移動する（β領域）。でもって、その領域でも付箋と付箋が重なると進化して、ステージが変わる。 そんな風にどんどん所属するdivが移り変わっていくイメージ。これはメタノートのメタファを拝借。 あるいは領域を移動せずに、単にその領域の先頭に移動する方式もある。これは押し出しファイリングの考え方。こちらは領域の管理が不要になる代わりに、重なった付箋とそうでない付箋の見た目をどう管理するのか、という問題がある。 ＊ ＊ ＊ で、もっと大きな問題。そうやって付箋をくっつけていくだけでいいのか、ということ。あと、ここでの付箋をくっつけるとは情報的にどんな意味があるのか、ということ。 たしかに付箋を並べていけば、そのなかでくっつけられるものは見つけられるだろう。それを繰り返していくことで、付箋に含まれたテキストは増えていくだろう。で、それだけでよいのだろうか。 ここでまた、「この操作において、自分は何を欲しているのか」という問題に突き当たることになる。 ＊ ＊ ＊ ここに並んでいるものは、一つの記事の種になることもあれば、暖めている企画案の要素になることもある。使われ方は結構異なる。その意味で、単純統一的な操作は考えないほうがいいだろう。いくつかのルートがあって欲しい。 ＊ ＊ ＊ 一番簡単なのは、上に並んでいるカード群(tracknoteのもともとのパーツ)にドラッグして、その一要素とすること。これが一番直感的な操作であり、たしかにそういう断片を求めている断片もあるだろう。でも、それだけではない。 まだどこに位置するのかはわからないけれども、断片同士で関連性を持つものもあるだろうし、それ単独で何かの媒体で記事にしたいと感じる核のようなものもある。これらはドラッグすべきカード先を持たない。 では、どうするか。 ＊ ＊ ＊ 実際的な話を先に考えてみる。同一領域で付箋を扱う場合（押し出しファイリング）、付箋を二つ重ねたとき、その表示をどうするのか、という問題がある。 単純にテキストを追加する場合、付箋のheightは固定されているので下の文字列は見えなくなる。でもって、追加が増えても同じ。つまり、付箋を追加しても変化が可視化されない。 tracknoteのようにリアルに（つまりliオブジェクトを）並べると厚みが出てくる。つまり、変化が可視化できる。その代わり、全体の内容を見るために特殊な操作が必要となる（前者ならスクロールすればいい）。 付箋を重ねることで、background-colorが変化する、というのはデジタル的なやり方だろう。だんだん色が濃くなっていく、的なこと。これはJavaScriptを使えばまったく問題なく実現できる。 なんにせよ、何かが変わったら、その変わった感じを可視化した方が良い気がする。その方が「操作している感覚」（広義のエージェンシー）を育むだろう。 ＊ ＊ ＊ 付箋の一つに「サイドバー恐怖症」というものがあり、これに関しては今週のメルマガ原稿で書こうと思っている。で、仮に書いたとしてその付箋をどのように扱うのか。そのままにするのか、削除するのか、それとも使用済みのマークを付けるのか。 でもって、先回りしていえば、「メルマガの原稿で書こう」と思っているその気持ちを、この付箋群においてどう反映させるのか。メルマガというcardsetを作り、そこにappendすればそれをなしたことになるのかどうか。 ＊ ＊ ＊ メタ・ノートはアナログ手法なので、あるノートに書いたものを別ノートに書き写す、という作業が発生する。 デジタルの場合、それこそドラッグでその操作が代替できる。 本当に代替できていると言えるのだろうか。 この「書き写す」をデジタル的にレストアできないだろうか。 ＊ ＊ ＊ 付箋を消して、新しく付箋を書き直す。という作業を補助するUI。 ＊ ＊ ＊ メタ・ノートは、少しずつ広い領域を割り当てているのがポイントとなる。 それを再現できないか。 ＊ ＊ ＊ 付箋に対してクリックかダブルクリックをすると、たとえば色が変わる。色は複数の色を移り変わっていくのがよい。 で、特定の色がついた付箋を「集める」という作業ができたり、それらの付箋を「使用済み」にできたりしたらどうか。 ＊ ＊ ＊
ブックカタリストな火曜日
作業記録の共有 Textbox+ページリスト ブックカタリスト+読書メモ トンネルChannel+目標について メルマガ+原稿1 13:30 ブックカタリスト収録 8:00 おはようございます。今日は午後からブックカタリストの収録です。 Textbox: 昨日ページリストを作ったのですが、Scrapboxのようにページの先頭部分をいくらか表示しても別段嬉しいものではありませんでした。むしろ、タイトルとそのページへのリンクだけで十分かもしれません。 ＊ ＊ ＊ たとえばこういう感じ。 これをMapの下に配置したらどうなるか。上の方にMap=boardがあり、下にこれまで作成したページがある。で、ドラッグで追加できる、的な。 それがページは別にしておいて（メンテナンスのため）、サイドバーなどにドラッグできる領域を設けて、その領域経由でMap=boardにも配置できるようにする？ ＊ ＊ ＊ 合体させてみました。これでボードの下の方があんまりチェックされない問題も解決できそうです。 機能がバッティングするので、下の方にスワイプしたら〈今日のノート〉に移動する機能はいったんオフにしておきます。横移動だけは残しておく方向で。 あとはdragイベントを作り、下から上にドラッグできる機能をつけるとさらに機能的になると思います。 ＊ ＊ ＊ で、上のmap=pinboardを触っていて思い出しました。これまでのノートツールではノートならノートという単位で情報を作ってしまうと、それしか閲覧できなくなり、違う粒度の情報が埋もれてしまう、という点が気になっていたのでした。なので、pinboardでは付箋を使い、ページへのリンクだけでなく、画像などもそのまま配置できるようにしたのでした。 その辺をこのページリストでうまく解決できないか考えてみます。 ＊ ＊ ＊ あと、新規ページを作成したときに、このjsonファイルを更新するようにしなければなりません。あと、ページを編集したときも更新日時をアップデートする必要があります。 あと、画像をどう表示するか。 ＊ ＊ ＊ サイズ調整などはあとで考えるとして、とりあえず画像の表示もできるようになりました。json便利。 ＊ ＊ ＊ pinboardの下に、ページリストを表示させたら嬉しいとして、たとえば、tracknoteの下に表示されたら嬉しいものは何か？ ぺージリストではないだろう。カードリストあるいはラインリストではないか。 期せずして、カード群の中央にスペースを置き、そこに一行のメモを書き残している。これがラインリスト（ただし今は単体）の萌芽だろう。あるいは必要性を自分が感じている証左とも言える。 カードはそれだけで存在しているのではなく、追記される運命を持つ。直接追記される場合もあれば、少し考えてから追記される場合もある。ラインリストは後者のプロセスを助ける。 異なる情報表示の形態を組み合わせることで、情報に流れ（動き）を与える。 これはこれまでのノートツールにはなかった機能だ。この点を深めていけばいい。 ＊ ＊ ＊ 話はもどって読書日記。 読書日記も、直接書くのではなく、Textbox上で入力を促して、それをjsonに変換して保存する、という方法がとれる。で、Textboxではそのjsonを解析してHTMLエレメントを作る。これで一応問題はない。 問題は、Textboxでない場所での入力がかなり難しくなること。が、現状はTextbox以外の場所で閲覧すらもほとんどしていないので問題は小さい。 json形式で保存すれば、たとえば、上で作ったようなビューに入れ込める。jsonの形式だけを揃えておけばよいだけだから。 複数のjsonがあり、それぞれが参照しあうようなリレーションなものは作れないか。たとえば、読んだ本のjsonの内部に、「買った本」jsonへのリンクがあり、それがTextbox上でリンクとして機能するような。 ＊ ＊ ＊ もう一つ。上のpinboardは、付箋を操作した後ボタンを押せばその配置が保存される。それは表示しているHTMLをそのまま保存している。で、下に表示されているページリストもそのまま表示される。 ページが読み込まれるたびにページリストのdiv.innerHTMLはリフレッシュするのだけども、それでもpinboard.mdにおいては常に「前回表示されたページリスト」がそのままのHTMLとして（つまりjsonではなく）保存されることになる。つまり、最新の状態でなければ、他のビュアーでも閲覧はできる、ということだ。これは大きい。 もちろん、ファイル的には冗長になっているのだが、Evernoteのローカルファイルとクラウドファイルのようなよい冗長性になっているのではないか。 ＊ ＊ ＊ というわけで、現状は深く考えずにこの考えを進めて行くとしよう。tracknoteで下に（あるいは中に）表示されたら嬉しいのはなにか。
準備を進める月曜日
作業記録の共有 メルマガツイート メルマガ+ファイルの準備 R-style+scrapboxについて メルマガ+原稿 8:00 おはようございます。本日は、いろいろ準備を進めます。 post: 新しいSNS、postにアカウントを作っておきました。たぶんあまり使わないと思います。 Your Profile / Post. push :clearなことを書く publish:執筆の指針を得る /閉じることの効能｜倉下忠憲｜note メルマガ: ファイルの準備と、今週号で何を書くのかをだいたい目論んでおきました。 断片:7つの: 1つのミッション 2つのモード 3つのプロジェクト 4つの領域 5つのルール 6つの 7つの 8つの 9つの 10のリスト 断片: 新規メモの作成時に何をやっているか。 10:00 R-style: publish:Scrapbox、光る言葉、〈弱いノートツール〉 | R-style ひさびさにR-styleっぽい記事を書いた気がします。 push :clearなことを書く メルマガ; 今週号は少し短めの記事を書いてみます。記事というよりもコラム的な。 15:00 Textbox: Textboxに含まれる要素を、Line、Card、Pageに分け、それらの生成データを一覧できたら面白いのではないか、というのが最近考えていることです。で、たとえば、そうした生成データのリストがあれば、それを原本として他の要素で利用できたりもするのではないか。 現状、ページの作成はすべてコード経由で行われますし、その際に「ページ呼出.md」に作成したページの名前を追記する処理をしています。これをアレンジすればページデータの生成をjsonで記録していくことはできるでしょう。 で、そのデータを元にホーム画面に「これまで作ったページのリスト」という歴史（ヒストリー）を表示させることができます。たぶん、私がTextboxに足りていないと感じているのはこのヒストリーの表現なのでしょう。Scrapboxにはサイドバーの全体像がない代わりに、このリストが最初から最後までスクロールで追いかけられるようになっています。 一応最近作ったMapでは、要素をそこに配置することで、Pin留めのようなことができますが、逆に言えばPin留めしなかったものはすべて流れてしまいます。その流れてしまっている具合がどうにも落ち着かないのでしょう。 json形式でデータを保存するのか、それともファイル名だけ保存して、そこからページデータを生成するようなScriptを書くのか。 たとえば、ファイル名がhoge.mdであっても、その中にjsonデータを保存することもできますし、Scriptタグを作ってその中に配列として保存することもできます。そこからページを描写することは容易です。
ゆっくりしたい日曜日
作業記録の共有 ブックカタリスト+原稿確認→ちゃんと書いていた 来週のタスクの整理 ブックカタリスト+読書メモ続き 9:00 おはようございます。本日はタスクの整理をして、あとはゆっくりすごします。 断片:フリーノート: 今、一行日記や読書日記について考えていますが、むしろ「フリーノート」を作ったほうが良いのではないか、という気がしました。 基本的に何でも書けるノート。で、何かしらで絞り込みを用意する。 Textbox: 現状のTextboxは、一気にページを読み込んでいますが、大きすぎるページだとかなり読み込みに時間がかかります（5000行のページなど）。そこで、Scrapboxのように、ある程度読んでおいて、スクロールしたら追加部分を表示する、という感じにしてもいいかもしれません。 あるいは、そういう要素に沿った別のアプリを作る、という手もあります。たとえば、読書日記はただひたすら長くなっていくので、そういうビュアーを別途作る、という感じです。 読書日記: ページのUIを作り直します。 ＊ ＊ ＊ とりあえず、読書日記はこれでよいとします。で、それ以外のノートについてどうするか。 ＊ ＊ ＊ 統一的ノートがあって、そこからカテゴリ別に転記される、という形もありうる。 17:00 book:read:end:『スマホ時代の哲学』: 読み終えました。過剰な接続によって孤独が失われ、寂しさを埋めるために「自己啓発」してしまう状況を分析し、それに対抗するために「趣味」を提唱する一冊です。 18:00 来週のタスクの整理: とりあえず、タスクの整理だけやっておきましょう。 ＊ ＊ ＊ まず週報を書きます。 ＊ ＊ ＊ で、タスクの設定。 こういうページを作ることにしました。 で、思ったのはたとえば、上のカードや、読書日記のカードを、カテゴリを超えて一覧したいのではないか、という視点です。いかにもScrapboxっぽくなりますが、そういうビューを自分が求めている気がしてきました。 で、これらのカードをすべてファイルで作っているならば簡単です。ファイルリストを表示すればよいわけですから。 しかし、ページ内のカードにしてしまうと、これがうまくいかない。やろうと思ったら、カードを直接生成するのをやめて、コード経由で作成し、その際にホームのページにも追記するか、あるいはjsonなどにそのデータを保存しておく、という方法でしょう。 ふむ。 ＊ ＊ ＊ ようするにこういうビューなわけだ。 ＊ ＊ ＊ ファイル単位に入力を変更すれば、これは簡単にできる。その代わり、読書日記のようなページはファイルを読み込んで、中身を表示させる、というスタイルに変更しなければならない。まさにデータベース。インテグレートページは複数のページで構成される（デザイン）されるページだったが、そのページは他のページをデータとして使うページになる。 そのやりかたをするならば、素直にデータベースを使った方がいいきがする。 たとえば、今年読んだ本の中から、hogeという本を探す、ということがファイルごとに分割すると、grepを使わざるを得ない。テキストファイルでの普通の検索では不可能になる。まあVS Codeではgrepも簡単なのでそこまで大きな問題ではないかもしれないが。 さて、どうするか。 ＊ ＊ ＊ ファイル単位にするならば、書いた記事もあとで読む記事もすべて一つのファイルとする必要がある。まあ、それはリストでも問題ないか。 この辺の統合性をどうバランスさせればいいのかがまだ見えてこない。あと、手間の問題もある。 書いた記事、書き留めたメモ、などはわざわざファイルを作らなくても並べておけばいい。そういうリスト処理をしたい対象と、カード処理をしたい対象があるのかもしれない。それによって二つの性質のものを一つのノートアプリに入れ込めるのかどうか。
メルマガを仕上げる土曜日
作業記録の共有 一週間のツイートの振り返り ツイートノート作成 メルマガ+「はじめに」「おわりに」 メルマガ+配信予約作業 ブックカタリスト+読書メモ作り 8:00 おはようございます。本日はメルマガを仕上げましょう。 断片:シーケンスノート: 最近「リスト」をよく触っています。で、それとは別に一行日記とか読書日記などもあります。これらは形状的にリストに似ていますが、実際は異なる存在です。 そこには連続性が前提としてあって、リストのように「順番はあるけれども」とは違った様子があります。そういう日記的なものをシーケンスノートと呼ぶことにしましょう。 カードの束も、やっぱりシーケンスノートとは違います。この辺がポイントなのでしょう。 一週間のツイートの振り返り: ツイートを読み返します。 publish:2023年01月07日までのツイートノート - Addless Letter メルマガ: 「はじめに」と「おわりに」を書きます。 ＊ ＊ ＊ 書けました。少し寝かせましょう。 10:00 メルマガ: 読み返しをはじめましょう。 14:00 メルマガ: 配信予約作業に移りましょう。 ＊ ＊ ＊ まぐまぐOKです。 ＊ ＊ ＊ noteOKです。 これで一段落しました。 断片:一枚一カード: たまたま見つけた、以下の文房具。 DAILY CALENDAR CARD 2023 | docketstore なかなか面白いです。一年間が365枚のカードになっていて、表面がカレンダーとして、裏面がノートとして使えるカードです。 なんとなくインスパイアを得られそうなのですが。 publish:一日一カードのカレンダー - 倉下忠憲の発想工房 あとで読む:(4ページ目)科学史家・村上陽一郎が考えるコロナ時代の教養「『知らない、何でもあり』の状態は恐ろしい」 | 文春オンライン あとで読む:Markdownは箇条書きプログラミングである push - Jazzと読書の日々
THとメルマガを進める金曜日
燃えるゴミ出し 作業記録の共有 メルマガ+sub TH+chapter14続き書き下ろし 8:00 おはようございます。今年から金曜日は締め切りがない曜日となりました。ちょっと変な感じがしますね。 とりあえず、本日は午後から心療内科なので、午前中にTHとメルマガ原稿を進めておきましょう。 ListLauncher: リストを呼び出せるようになったところで、次の不満が出てきました。たとえば、inbox相当のmemo.mdというファイルを呼び出すのはすごく便利なのですが、参照し終わったメモの「操作」ができません。 その行を消したり、チェックマークを付けたり、といった操作です。 同じことは、タスクを表示するリストでも言えるでしょう。 逆に、スケジュールや気になっている本リストなどは、項目を追加するという操作をしたいはずです。 そういう操作は、個別にScriptを設定できるTextboxではスムーズに処理できるのですが、現状ListLauncherではできません。もちろん、操作はTextboxに任せてLLでは呼び出すだけ、という姿勢に徹することもできますが、さてどうしましょうか。 ＊ ＊ ＊ 仮に機能を加えるとしたら、二つのルートが考えられます。 まず、普通にリストを呼び出して、そこに書き換えの機能を付与すること。しかるのちに保存する。これはTextboxと同じロジックが使えるはずです。 次にスラッシュコマンドを使う方法。普通はbooksのような文字列を入力してリストを呼び出すのですが、代わりに/ではじめるとスラッシュコマンドになる、というやり方です。ちょうど/はフォルダの区切りになるのでファイル名としては使いませんので衝突することがない点で安心です。 で、/addとしたら、下にaddできるリストが呼び出されて、それを選択したら、普段はリストから項目を絞り込むのに使っているフィールドに文字列を入力してリターンすれば、それが新規項目として追加される、みたいな感じ。 プログラムとしての整合性がかなり欠落しますが、動作としてはナチュラルでしょう。 ＊ ＊ ＊ とりあえず、項目を「消す」（あるいは処理済み表記にする）方法を考えましょう。 この場合、いちいちスラッシュコマンドを入力するのは面倒なので、リストの項目を直接操作できた方がいいでしょう。 該当行をダブルクリックで消す チェックボックスを表示して、それをクリックすると消す スライドで削除する 長押しで削除する まず行を削除するのか、それとも処理済み表記にするかを考える必要がありますね。 あとで読む:🖊知的生産のキラーアプリOrg-roamを１年使い倒し学ぶとはなにか考えたポエム(2022) | Futurismo あとで読む:音声認識モデル”Whisper”をストリーミング処理対応させる方法 | DevelopersIO あとで読む:Googleが「フェルミ推定」採用をなくした当たり前すぎる結論 | 幻冬舎ゴールドオンライン 16:00 なんやかんやで作業をしていて、そのまま心療内科に行ってきました。ようやく減薬です。順調に行けば、二週間後には薬が終わります。 17:00 メルマガ: sub1を書きましょう。 あとで読む:すでにアプリが起動しているときに関連付けファイルが開かれた場合 (app ‘open-file’ event) ＊ ＊ ＊