徐行運転な水曜日

作業記録の共有 メルマガ+原稿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+今更何を書くというのだ メルマガ+原稿1 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文字の原稿が書けました。いよいよ、あと一つです。 * * *

病院に行く金曜日

作業記録の共有 Textbox+絞り込み機能のフックだけを作る TH+chapter15のアイデアだし メルマガ+原稿 RSP+xmlファイルの解析 レシート入力 8:00 おはようございます。本日は市役所にいくタスクと午後からは心療内科です。たぶん、今回の通院で飲み薬は終わると思います。 断片:五月雨式執筆術: 昨日考えた、上にどんどん新しいものを追加していく方法を「五月雨式執筆術」と呼びましょう。英語だとweep writing。 この手法はもう少し検討したいところです。ツールの開発も一緒に。 あとで読む:ナラティブは終わらない あとで読む:窓辺の小石(91) ダイアン | マイナビニュース Textbox: 少しだけコードを書いておきます。 * * * できました。 すげーかんたんに書けました。 1 const result = json.filter(item => item.address == text); これはたぶん便利なはずです。 9:00 TH: ラストを飾るchapter15を検討します。 あとで読む:科学の中のゆらぎ|shinshinohara|note 16:00 病院に行ってきました。無事薬は今日でおしまいです。二週間後にあともう一回いけば、僕の通院は終わりっぽいです。 RSP: WordPressからダウンロードしたxmlファイルを開いてみましょう。VS Codeでひらくとさすがに重くなりそうなので、テキストエディットを使っておきます。 * * * WordPressのXMLにある記事のデータのサンプル - 倉下忠憲の発想工房 itemタグの中に、記事一つが入っている印象。 本当に必要なのは、タイトル、本文。で、投稿日時があるともうちょっと便利かな、というくらい。 あとは、Hugoのフォーマットを意識して、xmlからmdにすればOKというところ。

原稿を書く木曜日

作業記録の共有 TH+chapter14の書き下ろし Textbox+inputboxにデータピッカーを付ける トンネルChannel+心の物理学について 7:00 おはようございます。本日のうちあわせCastはお休みです。 原稿を書きます。 トンネルChannel: publish:心の物理学2 - by 倉下忠憲@rashita2 - トンネルChannel TH: chapter14を書きます。 9:00 Textbox: historyをクリックすると、そのidと中身が入力欄に自動的に入る。idはfromに入る。 もしそのidを消して保存すれば、まったく新しい保存になる。残してあれば、リファラーとして保存される。 リファラーがある場合は、history上で「スレッドを表示」みたいなリンクが表示され、それをクリックすると、つながっているリファラーがすべて表示される。あるいはそれが入力欄に挿入される。

原稿を進める水曜日

作業記録の共有 Textbox+書誌情報 Textbox+漫画情報 メルマガ+原稿 Textbox+絞り込み メルマガ+デジタルガレージ R-style+Workflowyのinbox機能 トンネルChannel+目標について TH+chapter14の書き下ろし 7:00 おはようございます。本日は本当に原稿を進めます。本当に、です。 Textbox: 本の情報をどう保存するか、ですが、JSONはすべてのデータが統一されている必要はないので、たとえばitem-infoみたいな属性を作り、そのサブ属性として書誌情報を入れるという方法が使えます。これなら統一的に処理しつつ、必要に応じて別の見せ方もできるようになります。 で、たとえば読んだ本の情報と、買った本の情報と、読みたい本の情報をどのように管理するのか。 * * * 読みたい本は、書誌情報は別に不要で、発売日と書名があればいい。それをLIne的に追加する。 買った本の情報も似ている。その時点では特にコメントはない。せいぜいどこで買ったのかや、なぜ買ったのか(誰が進めていたか、など)くらいだろう。 で、読んだ本の情報だと、書誌情報と自分の感想が出てきて、しかもその日付(読了日)が重要な意味を持ってくる。 これらをどう扱えばいいか。 * * * まず、本を登録する。そして、その本にリプライする形でコメントを書く? つまり、本の情報と、本についてのコメントを別のカード(単位)として扱う? 一般的な本については、これは優れた管理方法であると思う。 では、漫画やライトノベルについてはどうか。 これらはそれほど深い情報管理を必要とするだろうか。言い換えれば、一般的な書籍と同じフォーマットで情報を残しておく意義が高いだろうか。 * * * たとえば昨日は、ブリーチの48巻と49巻を読んだ。これを記録として取るのは、Log的な側面が強い。知的生産の素材として使おうという意欲は低い。写真アルバム的な役割。であれば、それは別の形にするか。 * * * 問題というかネックは、「読書日記」というものの中に、漫画も一般的な書籍も同時に入ってくるからだ。この構造を考え直す? 漫画はシリーズで読むことが基本なので、漫画に最適なフォーマットがあるかもしれない。 * * * とりあえず、あるノート(単位)についてリプライしていくことで情報をつなげていく、という発想は面白いように思う。 * * * 漫画の記録でいえば、せいぜいこれくらいが残っていればいい。 で、表紙の画像があればよりGood。シリーズを通して作者などの情報は共通している。巻数と発売日が異なるくらい。値段は違うだろうが、特に知りたい情報ではない。 とすれば、どうすればいいか。 まず「ブリーチ」という作品を登録し、それを参照する形で、読了日記を書く? 仮にそのやり方をするとして、画像はどうするか。書影画像をdragすると保存できるようにする? 仮にdragやコピペができたとして、その画像はどこに保存されるか。ブリーチシリーズのもとファイル? それとも読んだというそのノート? まあ、読んだというそのノートだろう。 なんとなく整合性がなくなる気がするが、まあ今は気にしないでおこう。 とりあえず、この方向でアイデアを整理してみよう。 リプライをつけられるようにする機能、漫画のシリーズを保存すること(作品.jsonのようなものを作る?)、画像をdragで保存できる機能、あたりがあれば満たせる。でもって、他の用途でも役立つだろう。

inputboxを作る

作業記録の共有 Textbox+inputbox(仮)の実装 でんでんコンバーターへのメッセージ R-style+記憶と記録 結城メルマガを読む メルマガ+原稿1 TH+chapter14の書き下ろし ツイートノートの整理 8:00 おはようございます。昨日は私事でバタバタしていて作業がほとんどできなかったので、今日はばりばりと進めたいところですが、今日は今日で朝から妻の病院の付き添いです。 Textbox: まずはinputbox(仮)の仮組みをしてみましょう。 中央に入力窓があり、左右にもウィンドウがある感じです。左右の窓は特定の動作で呼び出す、というのでもよいでしょう。 * * * まずGmailのような入力窓にしました。 で、addボタンを押したら、それがhistroy.jsonに記録されるようにします。それで最低限の「保存」機能にはなるでしょう。 * * * 保存先はjsonなので、前回作ったjsonに追記が使えるはずです。まず、空っぽのjsonを作っておきましょう。 11:00 Textbox: できました。入力して「add」ボタンを押せばhistory.jsonに記録されます。左にはそのjsonの中身が表示されています。 で、このhistoryをクリックしたら、その中身がモーダルの方に表示されればOKです。その際は、そのとき表示されている内容は自動的に保存されるのがよい? * * * historyから戻す機能もつけました。現状は戻すときは保存しない形で。 呼び出したファイルの中身が書き換えられている場合だけ新しく保存する、という形にしたいところ。 * * * とりあえず、最低限使える形にできたのでOKとしましょう。 でんでんコンバーターへのメッセージ: あとで読む:でんでん開発ブログ : 助けてください! 企画協力者募集のお願い メッセージを送っておきました。 Textbox: ヒストリーから呼び出されたアイテムは、保存されるときもともとのヒストリーのidも保持しておき、「すべてを削除」を選択したらそのすべてを削除できる、という機能はどうか。 14:00 Textbox: inputbox、現段階でもかなり便利です。シンプルで使いやすい。 情報を連続的にまとめていくために、「リプライ」のようなことができると面白いと思います。が、ヒストリー機能と若干競合しますね。 もう少し考えたいところ。 * * * ここの入力から、各種ページないしはそのページ用のjsonに入力すること。 R-style: 記事を書きます。 * * * publish:記憶と記録 | R-style

準備を進める月曜日

作業記録の共有 メルマガツイート メルマガ+ファイルの準備 Textbox+page.jsonの自動更新 Textbox+Quick insertについて検討 ブックカタリスト+記事配信予約 りっすんインタビュー記事チェック 7:00 おはようございます。今日は準備を進めつつ、Textboxへの入力を再検討します。 Textbox: 毎日、過去アイデアからランダムに5つ取り出していましたが、その手法はいったん停止します。HyperIndexに付箋(ライン)の一覧が表示されるので、そちらで対応するようにしましょう。 * * * 新規ページを作成したときの処理について。 これまでは新規ページを作成した際に「ページ呼出」にそのページ名を追記していた。この処理を変えたい。具体的にはpege.jsonに項目を追加する、という形にしたい。 で、そのようにしてページ呼出がくるくる編集されるからインクリメンタルサーチに呼び出していなかったが、それもやめていい。まず簡単なそちらから。 1 2 3 if(l.normalize("NFC") == "ページ呼出.md".normalize("NFC")){ return; } これを削除。 で、次にjsonの処理。すでに存在しているpage.jsonに、一番最初か最後にアイテムを追加する。 クライアントのJavaScriptでjsonを読み込み、項目の処理をしてcgiに「この内容で上書きして」と頼むか、対象ファイルと内容をcgiに渡して、jsonの処理はcgi側で行うか。 どちらにせよ、「jsonの操作」を扱うfunctionを作っておいた方がいい。 JavaScript側で処理するならば、すでに存在している「ファイルの上書き保存」cgiがそのまま流用できる。ただし、jsonの中身が大きくなると、処理に時間がかかる可能性がある。 JavaScript側で、追加したい項目のデータだけ作っておいて、それをcgiに丸投げするのでもよいかもしれない。 * * * 単純にjsonを追加する場合はどちらでもよいが、ページリストはそのページの中身をサルベージしてからjsonに加えるので、ここはcgiに任せたほうが言い。 * * * とりあえず、ページタイトルを受け取ったら、その名前で中身をサルベージして、page.jsonに追加するcgiを書きました。 これでTextboxで新規ページを追加したら、ページリストにそのページが自動的に表示されるようになります。 8:00 あとで読む:再び言葉を あとで読む:焦がれたものリスト - Word Piece あとで読む:さいごの宇宙船 - 田中空 | 少年ジャンプ+ Textbox: 新規作成について考えます。