メルマガを書く土曜日
作業記録の共有 メルマガ+原稿1 メルマガ+原稿2 メルマガ+原稿3 メルマガ+原稿4 iPadのiCloudバックアップの中身を調べる メールの返信 ツイート振り返り メルマガ+はじめに・おわりに メルマガ+全体の読み返し 7:00 おはようございます。いろいろ他の原稿にあけくれていたので、メルマガがぜんぜん書けておりません。今日はまずそれを書きあげましょう。 メルマガ: まずは一つ目。 ＊ ＊ ＊ 2000字の記事を書きました。 8:00 メルマガ: 二つ目へ。 ＊ ＊ ＊ 3000文字の原稿が書けました。 9:00 メルマガ： 三つ目を書きます。 ＊ ＊ ＊ 1300文字の原稿を書きました。あと一つくらいの予定。 11:00: メルマガ: 四つ目を書きます。 ＊ ＊ ＊ 1800文字くらいが書けました。今回はこれくらいにしておきましょう。 14:00 トンネルChannel: publish:イマジナリーなボードにイマジナリーなタスク - by 倉下忠憲@rashita2 - トンネルChannel 今週の振り返り: メルマガ作業を続けましょう。まずは一週間のツイートの振り返りから publish:BC056 『運動の神話（上）』 - by goryugo and 倉下忠憲@rashita2 - ブックカタリスト 15:00 メルマガ: 「はじめに」と「おわりに」を書きます。
PTヲカク金曜日
作業記録の共有 PT+chapter02-2を書き下ろす PT+chapter02-2をメールで送信する 15:30~ 心療内科 メルマガ+原稿一つ トンネルChannel+今日のタスク管理 Scrapbox+情報の整理学のノート作成→倉下の関心事 8:00 おはようございます。本日は午後から心療内科です。予定では最後の通院日。午前中はPTの原稿を書いて送信しておきましょう。 Textbox: タスクの見え方を変えます。 ＊ ＊ ＊ まず、stateのdoneがnull以外なら、done用のスタイルを当てることにしました。 あとは、順番も変えたい気持ちがあります。doneを先に並べるか、それとも未doneを先に並べるか。どちらにせよ、アルゴリズムを結構変える必要があります。 ＊ ＊ ＊ 現状のfuncitonは、jsonのデータを受け取り、書き込み（append）先のdivを特定して、あとはjsonのデータからdivを生成して、先ほどのdivに順番にappendしていく、という流れです。 順番を変える場合は、doneと未doneで別の配列にappendしていき、その後二つをappendする、というやり方があるでしょう。この場合、順番を逆にしたくなっても簡単です（最後のappendの順番を反対にすればいい）。 あるいは、一つの処理の流れの中で、doneなものはprependし、未doneなものはappendするとどうなるでしょうか。片方は前に前に追加され、もう片方は後ろに後ろに追加されるので、結果的に未doneなものが前に、doneなものは後ろに集まるのではないかと予想。 ＊ ＊ ＊ 後者はif分でpreppendとappendを分岐させればいいだけなので、ちょっとやってみました。 この場合、未doneの並びが、json上の並びとは逆になってしまいます（そりゃそうだ）。この点がひっかかるなら、やはりdoneと未doneに振り分けておいて、後からそれを追加の方がよいでしょう。 PT: chapter02-2を書き下ろしましょう。 ＊ ＊ ＊ その前に少し考えておきます。 こうして「さあ、原稿を書きはじめよう」というとき、どのようなムーブメントが起こせればよいのか。 以前まではVS Codeのワークスペースを開いていた。が、イマイチテンションが上がるものでなかったことは確かだ。では、どうすればいいか。 （とりあえず、今日は 用紙の種類 について書くこと）。 まず、上記を調べた。つまり先に立てておいたアウトラインを参照し、今日書くべきテーマを引っ張り出した。 次に、その原稿用のテキストファイルを開くことが必要。今回は続きではなく書き起こしなので、真っ白なテキストエディタファイルを開くことになる。これはチョー簡単。CotEditorから直接開いてもいいし、たとえばTextboxに「CotEditorを開く」というボタンを設置してもいい。裏側でコマンドを走らせて、touch hoge.txt しておき、それを開いてもいい。 この辺は通常の運行だからこのままで特に問題ないだろう。検討したいのは最初のところ。今日書くことにいかにして焦点を合わせるのか。 これは、毎日作業記録を作る際に昨日の一行日記を入力が促されるのだが、そのときに数日前までの過去の一行日記が表示される、というのが参考になりそうな気がしている。つまり、前後のアウトラインが表示されて、今日書くことをそこで「宣言」するのである。 「アウトライン」用の情報は、ファイルとして開く必要がない。ちらっと見られればいい。その点が、VS Codeだとちょっと違うと感じる点なのだろう。 ＊ ＊ ＊ これはEmacsのミニバッファあたりも参考になるかもしれない。 Textbox: Textboxでは現状、shift+contorl+Mで、inputboxモーダルが表示され、メモが入力できる。 が、最近Textboxページ以外でもメモを入力するときにそのショートカットに指が伸びるようになった。当然だ。メモは汎神的なのだ。メモ入力は遍在する。 だとすれば、リスト参照用のListLuncherとしてサイドバーの機能を切り出したように、メモ入力の機能も独立させた方がいいかもしれない。扱うデータ群はどれも同じ。でも、個別の機能によって分化されている。ちょっとUNIX文化に通じるものがある。 13:00 断片:4D: Drop、Draft、Document、DataBase、の四段階を考えてみる。 ＊ ＊ ＊ ListLauncherとInputboxは統合できないか。理想的なメモ入力環境とはどのようなものか。 ＊ ＊ ＊
THを書く木曜日
作業記録の共有 『人新世の人間の条件』 の在庫を調べる hont,未来屋,くまざわ→くまわざにあり TH+chapter15の原稿 TH+chapter15の共有 トンネルChannel+今日のタスク管理 8:00 おはようございます。今日はTHの進捗共有の日なので、昨日作ったアウトラインをGuidに書き下ろしを仕上げてしまいましょう。あと、本屋にも行きたいですね。 断片:ショートカットとJSON: iOSのショートカットアプリでJSONデータを扱いたいのですが、うまくいきません。それができたら最近作っているTextbox内のJSONをiPhoneからも操作できるようになるのですが。 追加の調査が必要ですね。 あとで読む:ゼロからはじめるJavaScript(14) ブラウザからインストールできるアプリPWAを作ってみよう | TECH+（テックプラス） あとで読む:ゼロからはじめるJavaScript(11) JavaScriptで手軽に文章校正textlintを使おう | TECH+（テックプラス） TH: chapter15を書き下ろします。 ＊ ＊ ＊ まずは2700文字まで。 ＊ ＊ ＊ 最後のchapterなわけですが、なんというかこのchapterに向けてここまでのchapterの内容を再構成する、という気概が高まっています。 つまり、chapter01~chpater14までの内容を受けて、まとめとして書かれるChapter15なわけですが、むしろChatpter15を先に固めて、逆算する形で、chapter01~chpater14を再構成する、ということです。 こういう書き方はこれまでやったことがなかったので、なかなか楽しそうだなと感じています。 11:00 TH: chapter15を続けます。 ＊ ＊ ＊ 4800文字まできました。これで半分くらいかな、の感触です。 12:00 TH: 8600文字。後半だいぶ小難しい議論を展開してしまいました。あとでばさっと切り落とすかもしれませんが、そのときはどこかにアップしておきましょう。 17:00 TH: chapter15の原稿（粗稿）ができたので、編集者さんに送信しておきます。 トンネルChannel: 書きます。 publish:今日のタスク管理 - by 倉下忠憲@rashita2 - トンネルChannel 断片:ターミナル+cotEditor: CotEditorでファイルを保存するときに、いちいちフォルダを選ばなければならないので、いっそターミナルから起動しようかしら。
原稿を進める水曜日
作業記録の共有 TH+chapter15のアウトライン整理 メルマガ+原稿１ メルマガ+原稿2 トンネルChannel+「今日のタスク管理」 R-style+2 hop search 8:00 おはようございます。本日は３つ原稿を進めましょう。 そういえば、今日から2月ですね。頑張ってまいりましょう。 Textbox: dais-board用のTask.jsonを作りたい。Tasksか。あるいはLibrayと同じように、「それを集める場所」の名前にしてもいい。 で、そもそもとしてjsonを操作するためのPythonスクリプトを整備しておいた方がいいかもしれない。 空っぽのjsonを作成するinit、特定の項目を追加するinsert（あるいはpush）、削除や順番の入れ替え、といったことをいちいちゼロから書かなくても良くする。 ＊ ＊ ＊ とりあえず手書きでjsonを作ろうと思ったわけだが、属性を埋めなければならない。で、この下に並んでいるカードの属性はどうすればいいか。 タイトルと内容。すべてを一つにまとめることもできるし、タイトルと本文をわけることもできる。本文はUlを構成してもいいし、ベタに並べてもいい。 そもそも、タイトルには何を書くべきか。「Chapter15」はどう考えてもタスクの名前ではない。 ＊ ＊ ＊ booksページでは、kinde版だったらそれっぽい表示を追加するとよいかもしれない。 AmazonのAPIはその情報を返してくれるかどうか。 Items.BrowseNodeInfo.BrowseNodes.Ancestor.Ancestor.ContextFreeName に「本」が、 Items.BrowseNodeInfo.Ancestor.Ancestor.Ancestor.Ancestor.ContextFreeNameに「KIndleストア」がある。 これも確保しておくとしよう。 ＊ ＊ ＊ 見た目ではわかりませんが、直にHTML要素を書くのをやめて、do.jsonからページの要素を生成しました。 まずはOKです。 9:00 TH: いよいよ原稿執筆直前のまとめを行います。WorkFlowyで考えましょう。 ＊ ＊ ＊ WorkFlowyのβの機能であるDashboardはなかなかよいのですが（CSSは上書きしてある）、このビューだとカードのドラッグができなくなります。それが改善されたらすげーよいのですが。 12:00 断片:読書ノート作り: 『人を賢くする道具』を読み込んでみたいと思った。読書ノートの出番だ。 まず思いついたのが、100ページのコクヨノートに引用と自分のコメントを書き連ねていく方法。非常に原始的なアナログ手法。 あるいはごく普通にScrapboxで同じことをやってもいい。本のタイトルのページか、タイトル＋読書ノートという名前のページを作り、そこに同じように書いて行く。 あるいはその両方でもいい。 ＊ ＊ ＊ まず一回目はパット読む。ドッグイヤーくらい。 次にノートを持ちながら二回目を読む。ポイントとなる要素を拾い上げていく。 それが終わったら、そこからページを切り出していく。Scrapboxで、という運用。 あるいはまとめてきな文章を書き下ろし、それをPDFにしておいてもいい。 あとで読む:講談社が“イッキ読みできる教養新書”を創刊した理由──現代新書・編集長と副部長に聞く、多忙で不透明な時代の「教養」のかたち - CX（顧客体験）のメディア「XD:クロスディー」 あとで読む:Scrapbox 3年間 1400回のリリースを振り返る - Scrapbox Drinkup
フィード処理を仕上げる火曜日
作業記録の共有 Textbox+ブクログのフィード処理 メルマガ+原稿1メータ TH+chapter15のアウトライン トンネルChannel+リアルタイムマガジン 7:00 おはようございます。今日はブクログのフィードを処理して、jsonに追記するコードを仕上げます。 Textbox: 深い辞書型への値の操作がだいぶ面倒ですね。まあ、よしとしましょう。 ＊ ＊ ＊ だいぶ強引に切り抜けた部分もありましたが、なんとかコードが書けました。 ブクログのフィードを見に行って、そのRSSからISBNを取得し、それを使ってAmazonのAPIをたたき、得られた書誌情報をJSONに追加して、そのJSONを表示するページです。 とりあえず、当面の運用は問題ないでしょう。 いや、フィードのアイテムがすでに存在している場合にスキップする処理が必要ですね。一応それだけ考えておきましょう。 9:00 Textbox feedは買った本が新しい順に流れてくる。 一番最近買った本 次に最近買った本 さらに次に買った本 JSONもその順番で登録されることになる。 さらに新しい本を買ったとき。 もっと最近買った本 一番最近買った本 次に最近買った本 さらに次に買った本 フィードのトップの項目をJSONのトップと比較する→違っているなら追加する。 この場合、このツールを経由せずにJSONに項目が増えているとうまくいかない場合が出てくる。すべての項目の中に存在しないなら追加するなら安全。 と、いうことは？ ＊ ＊ ＊ とりあえずできました。新しいものだけが追加されます。
準備を進める月曜日
作業記録の共有 Textbox>inputbox>library+ブクログのフィード処理に噛ませる処理を作る Textbox>TaskGround+簡単なページを作る メルマガ+ツイート メルマガ+ファイルの準備 メルマガ+原稿1 8:00 おはようございます。今日はメルマガの準備を進めて、Textbox周りの作業もやっておきましょう。 あとで読む:常に老若男女で“ざわついている”書店 ポイントは「探しやすさ」を考慮しない店内設計(1/3)〈AERA〉 | AERA dot. (アエラドット) 読む:かんばんについて: かんばん (ソフトウェア開発) - Wikipedia かんばんはソフトウェア製品を開発するための方法である。さらに、かんばんは、ソフトウェア開発者に過剰な負荷をかけずに、ジャスト・イン・タイムでのソフトウェアリリースを強調したプロセスでもある。このアプローチでは、顧客へのデリバリーに必要なタスクの定義を行い、そのタスクをソフトウェア開発プロジェクトの関係者が理解するために、プロセスを視覚化する。そして、タスクの作業者は、作業をキューから引っ張って（プル）していく。 方法論としての「かんばん」は、デイヴィッド・アンダーソン（David J. Anderson）によってまとめられた。物理学者のカール・デイヴィッド・アンダーソンとは別人。 著作。 Amazon | Kanban: Successful Evolutionary Change for Your Technology Business | Anderson, David J., Reinertsen, Donald G | Methodology Amazon | Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results | Anderson, David J. | Software Development
ゆっくりコードを書く日曜日
作業記録の共有 やることの整理 ツール開発 スケジュールの確認 各種プロジェクトの確認 週報作成 9:00 おはようございます。本日はやることを整理して、あとはゆっくりコーディングを進めます。 やることの整理: まずは、ツール開発について、やりたいことを整理しましょう。 ＊ ＊ ＊ 現状はこんな感じ。要素は単にfloatで回り込ませているだけのdiv。 看板風に。 色味などを変更。 「済」のハンコをafter要素で生成。 「output」欄に移動したら、「〜〜する」を「〜〜した」に変更したい。英語なら動詞を見つけて、それを過去形にすればいい。日本語でも、まあ在る程度は似たようにいける。自分の手を動かして書き換えるのが一番だろうけども。 あるいは、そういう書き方の変更が必要なタスクの記述がおかしい？名詞的に書くべき？ ＊ ＊ ＊ jsonからHTML要素を生成するのと同じで、あるオブジェクトのstateが"done"になっていたら、そこで生成される文が「〜〜する」ではなく「〜〜した」に変わるようにすればいい。これまでのタスク管理ツールでは、新規作成時に入力したタスク名がそのタスクの「本体」だったわけだが、そうではなく、入力時のテキストとして保存した上で、状態が変わるごとに、カードやらなんやらで表示させる文面を動かしていく。タスクを破棄した状態だったら「〜〜したかった」として表示する、など。 10:00 断片: タスクの状態について。 まず、inbox（アイデア）に思いつきが入る。このときこれはまだタスクではない。で、タスクとなったとき、inbox（タスク）に入る。 次にそのinboxからオーガナイザーの中に入る。実行中などの状態を扱うもの。でもって、その後log/historyに移る。実行が破棄されたものはtrashboxにはいる。 二段階のinbox inboxとオーガナイザー log/historyとtrashbox これらすべてが同じUIでよいのかどうか。 11:00 Textbox: アプリアイデア帳.mdにそのページのアイデアをまとめながら、いくらかサンプルを実装しました。 12:00 やることの整理: 日付が関係する出来事をチェックしました。具体的には、締め切り・予定・本の発売日などです。 これをまずinputboxに普通にメモしました。 このデータをpinboardにペーストできればいいですね。そのアイデアはメモしておいて、次に進みます。 15:00 Textbox: AmazonのAPIを叩いて、書誌情報を含めたJSONを生成できるようにしました。 OKです。 やることの整理: 最後にプロジェクトの整理。これはどのように進めましょうか。 ＊ ＊ ＊ とりあえず、スケジュールと同じように簡単にメモとして書き留めておきました。 この辺の処理が今後の課題ですね。lineよりももう少し大きい情報。しかし固定的ではなく、使い捨てられる情報 16:00 Textbox: library.jsonからページを生成しましょう。 17:00 週報作成 そういえば週報を作成することにしていたのでした。週報作成ボタンを見て思い出しました。
メルマガを仕上げる土曜日
作業記録の共有 一週間の振り返り ツイートノート作成 Textbox+画像のドラッグをテスト実装してみる メルマガ+「はじめに」「おわりに」 メルマガ+読み返しと配信予約 Tak.さんに振り込み add:ブックカタリスト056アフターの下書き ブックカタリスト読書会のページ更新 8:00 おはようございます。本日はメルマガを仕上げます。 一週間の振り返り: まずはツイートの読み返しから。 あとで読む:Noratetsu Lab: ツール製作日誌：HyperDatabase あとで読む:哲学が好きです - by Go Fujita - トンネルChannel ＊ ＊ ＊ publish:2023年01月28日までのツイートノート - Addless Letter 9:00 Textbox: ChatGPTさんに質問しながら画像ファイルのdrogイベントを実装してみましょう。 ＊ ＊ ＊ 画像を置けるようにはなりました。 15:00 メルマガ: 「はじめに」と「おわりに」を書きます。 ＊ ＊ ＊ だいたい1時間で3000文字相当が書けました。 16:00 メルマガ: 読み返しを行い、その後配信予約を行います。 ＊ ＊ ＊ 読み返しが終わりました。結構時間がかかりました。 17:00 メルマガ: 配信予約です。 ＊ ＊ ＊
メルマガを書く金曜日
作業記録の共有 買った本の登録 トンネルChannel+リアルタイムマガジン メルマガ+原稿2 メルマガ+原稿3 21:00~ブックカタリスト読書会 8:00 おはようございます。本日はメルマガの原稿を書きましょう。あと、inputboxに画像をドラッグしたら保存できるようにしたいところです。 とりあえず、今日もVS Codeではなく、CotEditorで作業を進めましょう。毎日作業記録を作成するコマンドをうったらVS Codeでその日の作業記録が開く設定になっていますが、それをCotEditorに変えたいところ。 wakeup.pyの書き換え 普段はVS Codeなので、作業記録ファイルを開いたまま、その他のスクリプトも編集できるのですが、ターミナル+CotEditorだとそうはいきません。 ターミナルで対象のpythonファイルを開く必要があります。でなんとなくvimにしました。やはり起動が速いですね。が、modeの移行で少し戸惑いました。でも、:wとか:qは覚えていましたね。 こういう風にツールを切り替えるのも悪くないです。 作業記録用のエディタ: CotEditorは全般的に悪くないのですが、ある程度書くとカーソルが一番下にいっぱなしになるのを避けたいところです。タイプライターモードが欲しい。 ＊ ＊ ＊ 検索してみるといくつかマークダウンエディタでタイプライターモードを持っているものがある。が、それはそれとして自分で作ってみるのもよいだろう。 Textbox: たとえば以下のようなメモを入力するとして、 このメモの「送り先」はどこになるだろうか。アイデア台帳？ やること帳？ Textbox？ Textbox開発記録？ アプリアイデア？ まず、「アイデア台帳」は違う気がする。同じように「やること帳」でもない。強いていえば「やりたいこと帳」だろう。 で、「Textbox」は違う。これはタグであって「送り先」ではない。逆に「Textbox開発記録」はそれっぽい。ようするにプロジェクト名ということだ。 「アプリアイデア」（アプリアイデア帳とすべき）は一つ上の階層で、ツール開発に関するアイデアを書き留める。 この「送り先」は、そのメモを入力しようと思ったときに一緒に表示されると嬉しいのは何か？という視点から考えることができる。 ＊ ＊ ＊ 本文中にブラケットでinputboxが囲まれているが、これはタグであろう。送り先ではないが、これで絞り込めれば嬉しい的なもの。まずこの二つを区別する。送り先とタグ。 で、このinputboxは、Textboxの関連要素・子要素である。タグの階層構造。だからといって、二つのタグをつけたり、inputboxをつけたら、Textboxと直接関連付けられるのは嬉しいか？ それは2hop先のリンクと言えるか？ 微妙にぴんとこない。 ＊ ＊ ＊ 先ほどの一緒に表示されると嬉しい問題について考える。 まず、Textbox開発記録（日誌でもいいな）だと、Textboxの他の機能などの実装の記録などが一緒に表示されることになる。一方で、アプリアイデア帳だと、Textbox以外のツール、あるいはこれから造ろうと考えているツールのアイデアと一緒に表示される。その代わり、こちらは実績や実装の記録は表示されない。 つまり、プロジェクトとして単位を見て、その「記録と展望」を一緒のものとして表示させるか、あるいはプロジェクトを横断して（ないしはそういう境界線を考えずに）「ツール作り」い関する包括的な「展望」を一緒のものとして表示させるか。 で、たとえば、タグによる絞り込みをandではなくorにするならば、「Textbox開発記録」と「アプリアイデア帳」の二つをタグにすれば、上にあげた要素のすべてが一望できる。実装としては難しくない。が、それははたして嬉しいのだろうか。 たとえば、inputboxという本文中のタグで絞り込めるとして、そういう状況で「送り先」を考えるとしたら何が嬉しいか。単語＝概念の共有以外のもの。 inputboxはtextboxという概念に含まれている。つまり、本文中にinputboxというタグがあるならば、「送り先」にTextbox開発記録は不要ではないか。つまり、開発の記録を残す場合もinputboxにかかわるものはそれをタグにしておくことで、そちらで一緒に並べることができる。 ただし、Textboxの他の機能の記録といったものは一緒には並ばない。それが並ぶことによる「偶発的融合」みたいなものは期待できなくなる。 「Textbox開発記録」という送り先があるのはよい。それはログを溜めていくための場所として機能するだろう。一方で、アイデアはどうか。それを一緒に混ぜ込んでしまうのはよいことか。 ＊ ＊ ＊ “[inputbox]に画像ファイルをドラッグできるようにしたい。“は、開発の記録ではないだろう。開発の途中で思いついたアイデアの記録ではある。このこうもり性をどう片付けるか。 二つのタグを付けるのは安直ではあるが、それは何か大切なことを考えていないだけな気がしないでもない。 が、現状考えていてもラチがあかないので、とりあえず二つ付ける方向でいってみる。 9:00 買った本の登録: 昨日、『標本作家』という本を買ったので、それをinputboxに登録してみます。（ブクログには登録済み）。 ＊ ＊ ＊ この場合「あて先」はどうなるか。本を読んでいるわけではないので「読書日記」はおかしいだろう。「書誌情報」「ライブラリ」あたりか。「送り先」でいうならば、まず「ライブラリ」が適切だろう。「書誌情報」は送り先ではなく、「分類」にすぎない。「書誌情報帳」であれば適切だ。 「ライブラリ」「書庫」「ブックシェルフ」「シェルフ」あたり。 「ライブラリ」は間違いではないが、微妙に違和感がある。「マイライブラリ」だとその違和感は小さい。「買った本リスト」は一番直感的。
コードを書く木曜日
作業記録の共有 Textbox+inputboxのカーソル移動 7:00 おはようございます。本日のうちあわせCastはお休みです。代わりといってはなんですが、コードを書きましょう。 Textbox: body欄の一番上の行で上カーソルを押したらfor蘭に移動できるようにします。 ただし、body欄はtextboxで、contenteditableなdivではないので、最上行の取得は少し工夫が必要です。 publish:Textareaのキャレットがある行の行数を取得するJavaScript - 倉下忠憲の発想工房 間違えてカーソル移動してしまったときに、自然に戻れるようにfor欄の下カーソルにもイベントを設定しておきましょう。 ＊ ＊ ＊ これは簡単でした。 次に。 ＊ ＊ ＊ あとはタグ入力のサジェストだけです。 まず、そもそも何をサジェストするのか。 一つ目はTextboxに存在する、pagelistをサジェストすること。これは当初イメージしていた機能。 ＊ ＊ ＊ ここから作業記録を書いているエディタをVS CodeからCotEditorに変えました。ターミナルがなくなるので、GitHubへのプッシュが一手間かかりますが、よく考えればターミナルを立ち上げればいいとも言えます。 そもそもmakeコマンドを使っているので、logtextフォルダでmakeを実行できればいいのですから、CotEditorのスクリプトで対応できるかもしれません。 ただその場合エラーが読めない可能性がありますね。ふむ。 まあ、いろいろ試していきましょう。 ともかく、Textboxについて。 ページリストのサジェストをするならば、すでにページリストのjsonがあるうえに、そのサジェストをmainpageで実装しているので超簡単です。ほぼコピペで済むでしょう。 ただし、500以上のページの大半は、addressとして使われることは無さそうです。もちろん、アイデア台帳、schedule、project-ptなどは、Textboxにおけるページの概念であり、まさにそこへの追記の代わりとしてこの機能を実装しているので、おおむね王道的な進み方ではありそうです。 もう一つの道行きは、空っぽのデータベース(json）から初めて、実際に入力したものだけをそこに保存し、次回以降のサジェストに役立てる、というもの。これだと、不要なデータを抱える必要はなくなります。 ページリストを参照する場合は、ページを作っておけば、次からいきなりサジェストとして出てくるのに対して、自前のリストを作る場合は、最低一度以上は自分でfor欄に入力する必要があります。 あと、ほとんど似たようなデータを扱うのに（巨大なAと、その部分集合であるBを別ファイルにするイメージ）、わざわざファイルを分けている、という点が若干気になります。もちろん逆に、ほとんど使用しない巨大なAをいちいちサジェストのたびに読み込む必要があるわけですが、それはTextboxを立ち上げたときに済ませているので、スペック的には問題ないでしょう。 あとはサジェストの「精度」でしょうか。 ページ方式の場合、自分が作ったことを忘れていたページがタグのサジェストとして出てきます。これはこれで便利そうな気がします。しかし、よくある単語が含まれている場合、ごく普通のページと、原稿のテキストファイルとが渾然一体となったサジェストになるので、結構面倒かもしれません。 たとえば、Textboxで「アイデア」と入力した状態のサジェストです。 この中で使われるのはおそらく「アイデア台帳」だけです。 ようするにここで問われているのは、inputboxで書き込まれるものと、ページとの関係性なのでしょう。こうしたmemoはページに対してどういう位置づけになるのか。もし、ここで入力したものが何かしらのjsonになり、それがページを描写するためのデータになるならば、ページタイトルのサジェストは自然だと言えます。たとえば「アイデア台帳」をfor欄に入力したら、アイデア台帳.jsonにappendされ、そのjsonを元に、「アイデア台帳」ページの要素が生成される、といった形。 原稿を書いたファイルなどはそのままテキストを保存しておくわけですが、アイデア台帳.mdは、そのスクリプトでアイデア台帳.jsonをfetchして中身を描写する、ということがありえます。でもって、そうしたページリストだけがfor欄の入力時にサジェストされたら嬉しいです。 ということは、ページリスト全体よりも「一度入力したもの」というか、タグとしてfor欄に入力されたもの、という限定がよいでしょう。 ただし、タイプミスがありえるので、入力したものというよりは、送信されたものという形が良さそう。そのデータでtaghistory.jsonを作り、そこからサジェストを生成する、という流れでまず考えましょう。 8:00 Textbox: ダミーのjsonを作って、それをベースにサジェストを起こすことからはじめる方向と、保存時にjsonを生成・上書きすることからはじめる方向があります。 まずは、保存から行きましょう。 ＊ ＊ ＊ 保存に関与している関数を探します。 ＊ ＊ ＊ addボタンが押されたときの処理に、とりあえず空っぽの関数を呼んで起きます。history.jsonに含まれる予定の関数です。saveTagHistyory()としました。 その関数は、タグボタンの状況をチェックし、オンになっているボタンのinnterTextを取得し、その配列を一つずつ要素にして、jsonに保存する、という形になるでしょう。ほぼ、これまで作ってきた関数の流用でいけそうです。 ＊ ＊ ＊ json生成用のpythonコードをアレンジ。 1 2 3 4 5 6 7 elif(flag == "pages"): with open(filePath)as f: json_load = json.