メルマガを書く
作業記録の共有 メルマガ+原稿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: 毎日、過去アイデアからランダムに５つ取り出していましたが、その手法はいったん停止します。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: 新規作成について考えます。
ゆっくりしたい日曜日
作業記録の共有 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に書き込むことの二つを意味する。その際に、どちらの方がやりやすいか。 まあ、あまり変わりないか。配列を使う場合でも、それはカードのもとデータであるわけで、結局カードそのものとほとんどかわりがない。つまり、どっちでもいい、ということだ。 ＊ ＊ ＊