準備を進める月曜日
作業記録の共有 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.
徐行運転な水曜日
作業記録の共有 メルマガ+原稿1（タスクの整理） トンネルChannel+開きすぎてはいけない（執筆環境話） Textbox+tagボタンから関数をトリガーする R-style+バトルフィールドの選定 bct:issueの設定 Textbox+タグ確定のtabキーで絞り込み 9:00 おはようございます。今日は寒すぎるので徐行運転で進めていきましょう。 断片:開きすぎてはいけない: 普段、VS Codeの一つのワークスペース内でたくさんのタブを開き、最近ではそのワークスペースも複数開いていることが多いが、これはよくないのではないか。 しかし、こういうことをついついしてしまうのは、「閉じる」という行為の面倒さだけでなく、開いていることによる支配感が影響しているのではないか。 あとで読む:TauriがiOS/Androidに対応「Tauri Mobile」アルファ版登場。Electron代替を目指すRust製の軽量フレームワーク － Publickey Textbox: filterの使い方で困っていました。 1 2 3 4 function formatSearchHistoryJSON(json,text){ const result = json.filter(item => item.address == text); return formatHistoryJSON(result) } これは通るのに、複数行にしようと{}を入れると思うようにいきません。 1 2 3 4 5 6 function formatSearchHistoryJSON(json,text){ const result = json.filter(item => { item.address == text }); return formatHistoryJSON(result) } なぜかな〜と悩んでいたら、よくよく考えたら何も値を返していないことを理解しました。正解はこうです。
ブックカタリストな火曜日
作業記録の共有 Textbox+for欄に複数の項目を入力できるようにする 8:00 おはようございます。本日は午後からブックカタリストの収録です。それ以外は、原稿とinputboxの改造をすすめましょう。 Textbox: inputboxのfor欄をタグ的にしてみたいと思います。 各ツールでのタグの入力方法 - 倉下忠憲の発想工房 最終的に、このfor欄に入力したテキストがタグとなり、クリックできるボタンとしても機能すればGoodです。 「,」かリターンキーでテキストの区切りをしたいところ。日本語入力を考えると、リターンの方が簡単かもしれません。ただし、漢字の確定と競合しないような注意が必要でしょう。 ＊ ＊ ＊ history.jsで処理を書きたいのですが、その前にrequireについて調べておきたいところです。 ＊ ＊ ＊ サーバーサイドならrequire、ブラウザサイドならimportとのこと。index.htmlで使うのでブラウザサイドですね。 ＊ ＊ ＊ ぜんぜん理解ができていないので、実際に小さいサンプルでやってみます。 module-test.js 1 2 3 export function add(x,y){ return x+y } うまくいきません。 1 2 3 4 5 6 import { add } from "./module-test.js" const x = 1 const y = 2 console.log(add(1,2)) できました。なるほど。 これはかなり時間がかかりそうなので、いったん目的の処理を書いてみます。 ＊ ＊ ＊ まずはガワだけできました。
zoomミーティングをする月曜日
作業記録の共有 メルマガツイート メルマガ+ファイルの準備 PT+サンプル原稿 11:00~PTzoomミーティング PT+全体の構成を編集者さんに送信 R-style+今更何を書くというのだ メルマガ+原稿１ TH+chapter15のアウトライン検討 8:00 おはようございます。今日は11時からzoomで編集者さんとうちあわせです。 断片:ポメラみたいなエディタ: よく考えたらElectronを触れるようになったので、やろうと思えばMacで動くテキストエディタを作れるようになっています。 で、VS Codeなどはコードエディタとしては最適ですが、テキストエディタ（記事や原稿を書くエディタ）としてはやや過剰な気もします。 そこで文章を書くことを目的としたエディタを自分で作ってみるのかどうか、というアイデアが閃きます。 では、どんなエディタがよいか。たとえば、ポメラみたいなエディタはどうか。 なかなか良さそうですが、問題はポメラを触ったことがないので、何が「ポメラみたいな」と言えるのかがわからないところですね。 でも、プロトタイプからはじめてみてもいいかもしれません。 publish:アイデアは手広く構える / システム手帳日記 / 連載で読む、ゆっくり読む / RSP+xmlを読む / デジタルガレージとしてのTextbox｜倉下忠憲｜note メルマガ: ファイルの準備をまずやっておきましょう。 ＊ ＊ ＊ 一つ目の原稿に取り掛かりたいところですが、その前にうちあわせの準備をやっておきましょう。 PT: うちあわせで使えるように、サンプル用の原稿を少し書いておきます。 ＊ ＊ ＊ サンプルとかいいながら、そのまま使えそうな原稿を3000字弱書きました。やればできるじゃん。 9:00 Textbox: たとえば、inputboxに関するアイデアを書き留めたとする。これは「アイデア台帳」というあて先は持っていない気がする。 その代わり、#inputbox というハッシュタグがあっている気がする。この感覚の差異は何か。で、その感覚を活かすにはどういう機能にすればいいか。 これと、スケジュール問題を合わせて考える。 ＊ ＊ ＊ スケジュール問題。簡単にいえば、その予定が発生（確定）する日と、その予定そのものの日との距離にあまり関係がないこと。 Historyboxは現状、作成日順にメモが並ぶ。で、1月22日に2月10日の予定が発生して、1月23日に1月30日の予定が発生して、1月24日に、8月10日の予定が発生した場合、単なる作成日順ではスケジュールの並びがぐちゃぐちゃになる。ぐちゃぐちゃになるだけでなく、参照時に必要な「ちょっきんの予定」が表示されるかどうかがかなり不確定になる。 これをどうするか。 まず、jsonに「予定日」といった属性を増やすアイデア。scheduled-dateとかscheduledとかreminder-dateとか、そういう名前。 で、その項目があるならば、それがない項目よりも先に表示し、さらにその項目を時系列でソートする。で、今日を基準としてそれ以前のものは表示しないか薄く表示するか、下の方に送る、といった処理をする。 これはこれで悪くない。問題はその属性をどのように入力時に指定するのか、という点。また一つ欄を増やして入力できるようにするか、日付のピッカーを増やす手もある。日付のピッカーならばUI的にも占める幅は小さい。最初は空っぽにしておいて、クリックしたらカレンダーが表示されて日付を選ぶ、というもの。それで属性に設定できる。 あるいは、文中にテキストでそのまま書いてしまう手がある。「1月30日にhogehogeする」という感じで。ただ普通に書いたのでは識別できないので記法が必要。たとえばブラケット(ダブルブラケット)で囲むとか、あるいはハッシュタグにするとか。 ここでハッシュタグ問題と合流する。ハッシュタグにしておけば、先ほどのinputboxを拾う機能と合一に問題解決できる。ただし、それが好ましいことなのかは考える必要がある。 ＊ ＊ ＊ ハッシュタグなどの記法で拾いつつ、さらに特殊な記法はscheduled-dateとして設定する手もある。ハッシュタグにしているだけだと、その日付がどんな意味合いを持つのかが見えてこないので、処理に使えない。 11:00 zoomミーティング: うちあわせです。
ゆっくりしたい日曜日
作業記録の共有 週報の作成 9:00 おはようございます。本日はメルマガも終わっていることですし、ゆっくり過ごしたいと思います。 週報の作成: さて、一週間のまとめから。 と、その前にそのまとめをどう作るのかを少し検討します。 現状はpinboardに先週の週報ページへのリンクがおいてあるので、それでページを開き、その下部に新しい週報へのリンクを書きたし、それをクリックして白紙のページを作成して、そこに書く、という流れになっています。Scrapbox的な書き方ですね。 pinboardに置いておくことで、「自分は週報を書く習慣を持っているのだ」ということがリマインドされるのでGoodです。 で、今までこの方法で続けていたわけですが、別の方法は？ もっといえばinputboxを使った方法は？ ＊ ＊ ＊ あて先に「週報」あるいは「今週の振り返り」をつけるところまでは確定です。 で、内容を書く。ものすごく長くなったらhistoryboxで表示されるときにかなり占める面積が広くなってしまうので、max-widthを設定してもいいかもしれません。 で、そのhistoryをコンテキストクリックしたら、boardに貼りつけられる、という機能が考えられます。 さらにアレンジして、max-widthを設定する代わりに（あるいはそれと同時に）、inputboxにタイプしていが出来てもいいかもしれません。通常保存しているのは一行メモなのでLine、週報は文章が多くなるのでcard、あるいはnoteといった形で。で、そのtypeによってhistorybox上での表示が変われば、max-widthを設定したり、あるいは冒頭の数行だけ表示したりといったことが可能です。 ＊ ＊ ＊ というわけで三つの機能が出てきました。 max-widthを設定する コンテキストメニューを作成する entryにtypeを付ける どれも有用そうです。 ＊ ＊ ＊ ヘッダーをクリックしたらtypeを示す文字列がトグルするようにしました。まだ、保存には反映されません。 保存する巻数は 1 appendtext("history.json",arr,"list") となっているので、この文字列を上記のheaderから参照するようにすればよいでしょう。 ＊ ＊ ＊ header内の文字列からtype指定できるようになりました。ただし、現状はどのtypeでも処理は同じです。ここからが難しいところ。 LineとList、Card、note。それぞれをどう位置づけ、どう扱うか。 10:00 Textbox: すっかり脱線していますが、コンテキストメニューも軽く実装しておきましょう。細かいのは後からでOKで、とりあえず表示できるラインを目指します。 publish:JavaScriptでコンテキストメニューを作成する - 倉下忠憲の発想工房 いちおう表示ができました。 通常のコンテキストメニューはいったん消すとしましょう。 ＊ ＊ ＊ とりあえずOKです。ここからどんな動作をさせたいのかを考えます。 そもそも、listではなくnoteとして保存されたものは、history.jsonに記録されるだけでなくfile=pageを作ったほうがいいのか。3パラグラフくらいのものは別にそこまでする必要はないのでは？ だとしたら、Pinboardへの貼りつけはどうするか？ ここで分岐です。 全体の文字数を制限してpinboardに貼りつける（付箋のように） タイトルをリンクにして表示する。ただしそのリンクはpageへのリンクではなく、history.jsonのデータを呼び出す関数をトリガーするリンク Pinboard以外のリマインダーを考える 前者二つはこのままの路線を継続し、最後の一つは別の路線へとスイッチします。まずは最後の分岐から検討しましょう。
メルマガを書く
作業記録の共有 メルマガ+原稿1 メルマガ+原稿2 メルマガ+原稿3 メルマガ+原稿4 メルマガ+原稿5 ツイート振り返り ツイートノート作成 メルマガ+はじめに、おわりに メルマガ配信予約作業 8:00 おはようございます。本日はメルマガを書きます。 メルマガ: まずは一つ目の原稿を。 ＊ ＊ ＊ 3000文字の原稿が一つ書けました。 あとで読む:悠々として急げ - こまっちゃん、走ります！ 9:00 メルマガ: 二つ目の原稿を。 ＊ ＊ ＊ 1800文字の原稿が書けました。これで半分くらいです。 少し休憩: 5000字ほど書いたので、少し休みます。一週間のツイートの振り返りでもやっておきましょう。 あとで読む:今西錦司『生物の世界』をよむ : 発想法 - 情報処理と問題解決 - 12:00 メルマガ: 原稿を続けましょう。 ＊ ＊ ＊ 1800文字の原稿が書けました。あと一つくらいの予定です。 publish:2023年01月21日までのツイートノート - Addless Letter ＊ ＊ ＊ 短めの記事を書きます。 ＊ ＊ ＊ 1200文字の原稿が書けました。いよいよ、あと一つです。 ＊ ＊ ＊