断片の扱いについて考える
作業記録の共有 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) ＊ ＊ ＊
各種原稿を進める木曜日
作業記録の共有 ListLauncher+読み込み先のファイルが存在しないときの処理を書く メルマガ+Main稿（7000字の原稿） TH+outlineファイルを作る R-style+箇条書きとマークダウン TH+chapter14の書き下ろし（1500文字まで） TH+chapter14の書き下ろし トンネルChannel+expressという言葉 8:00 おはようございます。今日は原稿を進める予定です。うちあわせCastはお休みです。 ListLauncher: 最初は、存在するファイル名だけを対象にしていたのですが、そうではない入力が可能になったので、ファイルの存在を確認してから読み込むように変更です（はじめからそうしておけ）。 ＊ ＊ ＊ OKです。 アプリケーションの起動時にファイルリストを読み込むのですが、当然そのファイルは更新されます。しかし、このアプリは起動しっぱなしなので、更新された内容が反映されません。 アプリケーションがフォーカスを失ったタイミングで再読み込みするようにしましょう。 ＊ ＊ ＊ なんとかメインプロセスからレンダープロセスに通信することで、予定していた機能を実装できました。これもサブウィンドウを実装するなかで得た知識です。何かしら役立ちますね。 9:00 メルマガ: Mainの続きを書きましょう。 13:00 メルマガ: Main稿、結局7000字ほどになりました。もう十分すぎるボリュームですね。あと一つ短めに何かを書いておくくらいにしましょう。 TH; ListLaucherで閲覧できるように、アウトラインファイルを作っておきましょう。 publish:対象のファイルから見出しだけを抜き出して別ファイルに保存するPythonスクリプト - 倉下忠憲の発想工房 こういうpyファイルを新しいプロジェクト用フォルダを作るたびに作るか、それとも大本みたいな場所にコードを持っておき、フォルダ名を変数にして切り分けられるようにするか。 まあ、makeコマンドで動かすことを考えると、プロジェクトごとにスクリプトを置いておいた方が柔軟かもしれません。 ついでに、project-ptにも同じスクリプトを置いておきましょう。 14:00 R-style: 記事で使うようの表記。 なので、 こういう風に書いても、 表示では一つの段落としてまとめて表示されるわけです。 ＊ ＊ ＊ 書きました。 publish:マークダウンと箇条書き | R-style TH: chapter14を書き下ろします。 ＊ ＊ ＊ 1500文字まで書きました。もう少し続けましょう。 18:00 トンネルChannel: publish:outputからexpressへ - by 倉下忠憲@rashita2 - トンネルChannel
ListLauncherの改造
作業記録の共有 ListLauncher+の改造 8:00 おはようございます。昨日中でListLauncherを片付けるつもりでしたが、いろいろどたばたしたので今日に持ち越しです。 ListLauncher: 現状を整理しておきます。基本的な機能はできたものの、見た目をspotlight風にしたいと考えていました。 しかし、アプリを起動した後にウィンドウサイズを変更する方法がわかりませんでした。そこで、subウィンドウを新規で開いて、それを拡張したウィンドウ領域とする、というアイデアを思いつきました。 で、さんざん苦労してsubウィンドウを開き、二つのウィンドウで情報をやりとりできるようになりました。あとは、それに合わせてスクリプトを書き換えていくだけだ、というところまで到着したのですが、昨日の夜にふと思いつきました。 ウィンドウサイズ、変更できるんじゃね？ 二つのウィンドウで情報をやりとりするやりかたをためしているうちに、「ウィンドウ」を操作できるようになっていました。であれば、もう普通にウィンドウを操作できるかもしれません。 仮にそれができるなら、subウィンドウもろもろのコードはすべて不要になるわけですが、それでもそのシンプルな方法を一度試してみるべきでしょう。 ＊ ＊ ＊ フツーにできました。あの苦労は一体……という感じですがまあいいでしょう。 ＊ ＊ ＊ これでプロトタイプはできました。あとは、タスクバーに収納する操作と（でないとアプリを終了できない）、フォーカスが失われたらいったんウィンドウを消す操作ですね。
THを進める
作業記録の共有 ListLauncher+ウィンドウの見た目を整理 TH+chapter14の書き下ろし PT+chapter01の書き下ろし メルマガ+Main稿 9:00 おはようございます。本日はTHを進めましょう。あとListLaucherの見た目の整理です。 あとで読む:Cerebro App - Open Source productivity booster with a brain ListLauncher: 見た目を整えました。 現状は一つのウィンドウでやっていますた、最終的には中身の表示はサブウィンドウでやりたいところです。ほぼ同じことをやっているCerebroのソースコードがかなり参考になりました。 レンダラーからウインドウを開く | Electron 初心者向き！Electronで親ウィンドウ↔子ウィンドウのデータ送信 – console dot log Build a Todo App with Electron. In this tutorial, we will build a todo… | by CodeDraken | codeburst 【electron】ウィンドウを読み込んだらそのウィンドウにデータを送る｜yuuyu｜note Electron を試す 6 - 複数ウィンドウの管理 - アカベコマイリ たぶん下が一番やりたいことに近いと思う。 ElectronでToDoアプリを開発する - Qiita 親ウィンドウでのキー操作が子ウィンドウの操作に接続できるようになれば、ほぼspotlightっぽくできると思う。 11:00 断片:タスク管理の用語の図面化について: 掲示板でコメントをいただいたので、こちらで補足しておきます。
準備を進める月曜日
作業記録の共有 メルマガ+ファイルの準備 ListLauncher+UIの設定 ツイートの整理 過去原稿の整理 キーワードブックのアイデア出し ニュースレター+12月の活動報告 TH+chpater14の書き下ろし タスク管理の用語を図面化 PT+1-1の書き下ろし メルマガ+main稿 8:00 おはようございます。本日から一応通常営業の予定です。メルマガなどを進めましょう。 9:00 ListLauncher: さっそくTextboxからHTMLタグを持ってきて、見た目を整えましょう。 ＊ ＊ ＊ HTMLとJavascriptをほぼそのまま移植しました。めちゃくちゃ便利です。 ＊ ＊ ＊ デザインをもっとRaycast風にしてもいいかもしれません。 とりあえずどういう方向に寄せていくのかは使いながら考えていきましょう。 ＊ ＊ ＊ 段階的な絞り込み。まずリストを選び、その後リスト項目を絞り込む。前者は単一のものが選択され、後者は複数の候補があり得る。その場合のUIをどうデザインするか。 10:00 あとで読む:学歴にこだわり続ける敗北者たちの声を書きたい【京大卒・佐川恭一×慶應卒・麻布競馬場 学歴対談】 | 特集 | よみタイ ツイートの整理: 主題ノートへの転記。 過去原稿の整理 おそらく「物書きエッセイ」の連載をまとめた本作りをしようとしていたフォルダを発見したので、その中身をTextboxに移動させておきます。 これで何かかわるのかはわかりませんが、少なくとも今回のようにすっかりその存在を忘れてしまう、という状態は避けられると思います。 VS Codeの縦分割: この作業記録はVS Codeで書いています。 で、ご覧頂くとわかるように一番上にタスクリストがあって、そこから時系列に作業記録（的なもの）が書きつづられています。 時間が進めば進むほど、記述は下に延び、結果的にタスクリストから離れていきます。 もちろん、command + ↑のようなショートカットキー一発で一番上までスクロールできるのですが、少しだけ面倒さは感じます。 で、たとえば今作っているLinsLauncherで「今日のタスクリスト」を即座に表示して、その中身なんかをクリップボードに取りこめたら、ペースト一発で作業記録の見出し３の部分に書き込めるな、と思っていたのですが、ついさっき気がつきました。 エディタを縦に分割すればいいんじゃね？ と。 画面を分割し、同じファイルを表示しています。上はタスクリスト部分、下は作業記録の最先端部分です。これでリストを常に参照していられますし、コピペなどのスクロール距離も短くて済みます。 はじめからこうしておけば良かったレベルでラクチンです。 15:00 いろいろプライベートタスクがありましたが、片づいたので作業に戻ります。 キーワードブックのアイデア出し: ちょっと思いついた書籍案のアイデア出しをしてみます。 ＊ ＊ ＊