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 いろいろプライベートタスクがありましたが、片づいたので作業に戻ります。 キーワードブックのアイデア出し: ちょっと思いついた書籍案のアイデア出しをしてみます。 ＊ ＊ ＊
ゆっくりする日曜日
作業記録の共有 Keywordの整理 Electronの準備 PT+ファイル整理 7:00 あけましておめでとうございます。本年もよろしくお願いいたします。 ということで、おはようございます。今日はマジでゆっくりすごします。 サイドテーブルの片付け: 作業机のサイドテーブルが本山盛りになっていたので、片付けます。 ＊ ＊ ＊ 更地を確保できました。 なるべくこれくらいは維持したいものです。 11:00 Keywordの整理: 突然思い立ってやってみます。これからの執筆の方向性を考える上でも、自分の手持ちの「キーワード」を洗っておくのは有効でしょう。 ＊ ＊ ＊ publish:倉下の主要な関心事 - 倉下忠憲の発想工房 こういうページもありました。ここで統合的に考えていけばいいですね。 というわけで、WorkFlowyに列挙したものをこちらに移動します。 publish:Hubとなるサイトを構築する一年 - 倉下忠憲の発想工房 あと下のページは後から書きましょう。まず、ラジアルマップ的なものを書いてから、文章化ですね。 publish:2023年1月以降にやりたいこと - 倉下忠憲の発想工房 12:00 Electronの準備: 試しに環境を作ってみましたが、たいがい大げさですね。 Electron + Reactでリストコールアプリを作る - 倉下忠憲の発想工房 一度環境を作ったら簡単かもしれませんが、いちいちビルドするのもなかなか面倒です。この辺はサーバーを立ち上げなくても良いPythonのGUIの方がはるかに手軽ですね。 ふむ。 そういうアプリがどれくらい実用的かをまずPythonで確かめてみるのもいいかもしれません。あるいはこれを機会にReactなどを勉強するか。 ＊ ＊ ＊ ElectronでFileのOpenとSave - Qiita なんとなくわかりました。Reactを挟むから面倒なのであって、普通にindex.htmlを書き換えれば途中のbuildは省略できそうです。これならやりやすいかな。というか、React抜きで、単にElectronだけでよかったのでは？ クイック スタート | Electron 現状HTMLとそのロジックはTextboxのものを使えばよいので、Reactは無視しても良さそう。もう一度環境を作り直す？
メルマガを仕上げる土曜日
作業記録の共有 ツイートの振り返り メルマガ+はじめにおわりに メルマガ+配信予約作業 Googleフォームでアンケートを作る 今年の振り返り Honkure+人間の解剖は ニュースレター+活動報告 ListLuncherについて検討する [-] これからの執筆活動について検討する→来年でヨシとする 8:00 おはようございます。年末ですが、通常通り仕事です。とりあえず、メルマガを仕上げて、後は本棚の整理でもしたいところです。 ツイートの振り返り: まずは一週間分のツイートの振り返りから。 ＊ ＊ ＊ だいたいOKです。 publish:2022年12月31日までのツイートノート - Addless Letter 9:00 メルマガ: 「はじめに」と「おわりに」を書きましょう。 ＊ ＊ ＊ 書けました。少しおいてから、全体を読み返しましょう。 10:00 メルマガ: 全体の読み返しと、配信予約作業です。 ＊ ＊ ＊ 読み返し、OKです。 ＊ ＊ ＊ 配信予約作業もOKです。 15:00 ListLuncherについて検討する: スタートはPythonのスクリプト（しかもGUI）としてはじめましたが、最近の流行りと自分のコード資産を考えたときに、Node.jsベースでやった方がいいのかもしれません。ここは難しいところです。 今年の振り返り: メルマガでも書きましたが、改めて全体的な振り返りを。 ＊ ＊ ＊ 画面左にObsidianのCanvasを設置し、右にWorkFlowyを設置し、まず左側でざっとした項目を書き出し、その後右側で文章を書き下ろしました。わりとこの連携は良いです。 16:00 Honkure: 書きます。 ＊ ＊ ＊ publish:『人間の解剖はサルの解剖のための鍵である 増補新版』（吉川浩満） – Honkure 17:00 ListLuncherについて検討する: 考えがとっちらかってきているので、いったん整理します。
プロジェクトを整理する金曜日
作業記録の共有 プロジェクトタスクの整理 シゴタノ！+過去記事アーカイブのダウンロード 8:00 おはようございます。本日は、現在抱えている二つのプロジェクト、THとPTのタスクの整理をしておきます。 大掃除的にファイルの整理もできるとよいです。 シゴタノ！: 過去ファイルのアーカイブをWordpressからダウンロードしておきましょう。 ＊ ＊ ＊ 通常のダウンロードでは、特定のカテゴリの記事だけをダウンロードできない？ 全体のファイル(csv)が手に入りましたが、私以外の記事も入っているので扱いが難しいですね。Googleスプレッドシートにアップロードして処理してみましょう。 ＊ ＊ ＊ だいぶ面倒でしたが、なんとか望む形になりました。 publish:Googleスプレッドシートで、特定の文字列を含まない行をまるっと削除する - 倉下忠憲の発想工房 が、まだcsvファイルですので、これをなんとかしたいところ。 ＊ ＊ ＊ pythonは標準ライブラリでcsvが扱えるので、そのまま処理しました。 publish:PythonでCSVファイルを操作する - 倉下忠憲の発想工房 テキストファイルを作り、それをtextboxに投げ入れます。 ばっちりです。まず「シゴタノ！連載」というページを元本とし、それをコピーして「倉下マテリアル」ページに貼りつけます。ここは、シゴタノ！やメルマガなどの集合体であり、順番などを変えてもOKなページとします。 16:00 断片:オープンするものは一つ: 以前オープン・プロジェクト、という概念を考えた。たとえば書籍原稿の書き下ろしはオープン・プロジェクトである。 で、考えるに、オープンにできるものには上限がある。というか一つだけにする、という運用が良いのではないか。 何かを空けたら、何かを閉じる。まるで電流の回路のようなやり方。サーキット・システム。 問題は、「閉じる」というのが具体的に何を意味しているのか、という点。もうそれ以上拡張を考えない、ということだろうか。 断片:過去の記録: 上のようにシゴタノ！の連載を見返していて思うのは、これまでそういう活動をほとんどしてこなかったな、ということ。 わりとログを残すのは好きだが、あまりそういう振り返りに時間を割いてこなかった。 基本的には、過去や歴史に興味が薄く、むしろ今や未来に注意を向けがち、という点があるだろう。 加えて、シゴタノ！の連載は、ずっと続いていた、つまりオープンだった、という点もあるかもしれない。走り続けている間は、その注意は前にしか向かない。 これは結構大切な観点だと思う。「走り続けてはいけない」。そういう思想。 プロジェクトのタスク整理: とりあえず、TODOファイルを読み返すところから。 まずTH。 現状はchapter14。なんとなく書くことはイメージできている。それが他の章と整合するかどうかは、現時点では考えない。 ＊ ＊ ＊ プロジェクトのtodoはどこでどのように扱えばいいか。 それぞれのフォルダの中にtodo.mdなどを作り、そこで管理する Textboxのプロジェクトノートで管理する Textboxのtracknoteで管理する TodoIstで管理してそのAPIを叩けるようにする Todoistを使えば、タスク管理に特化した機能が使えて、しかもAPIを叩くことで、自分のシステムにそれを引き込むことができる。だったら、自分のシステムの中に「タスク管理に特化したモジュール」を作ったらどうなるか？ Textboxの一機能かあるいは独立した機能として、それを外部から叩けるようにデザインする。 ＊ ＊ ＊
うちあわせCastな木曜日
ビニールゴミ出し 作業記録の共有 メルマガ+main稿（3000字） Textbox+エラーの修正 『ライフハックの道具箱』+誤字の修正 うちあわせCast収録 R-style+Obsidian キャンバスとKJ法 メルマガ+main稿 Textbox+ホイール動作の実装 7:00 おはようございます。本日は今年最後のうちあわせCast収録の予定です。午前中はメルマガの原稿を書きましょう。 Textbox+エラー修正: 朝のファイル作成時にエラーを吐いていたので、それを修正します。 ＊ ＊ ＊ 存在しないファイルを開こうとしている、というエラーですが、それはifで切り分けていたはず。これについては時間がかかりそうなので、後回しにしましょう。 8:00 メルマガ: main稿を書きます。来年の指針について。 ＊ ＊ ＊ とりあえず3000字書きました。未完なので今日中に続きを書きます。 9:00 Textbox: エラーを追いかけます。 ＊ ＊ ＊ わかりました。forで一番最後に残っているものがあればappendする、という処理において中身が空っぽだった場合の例外処理がなされていませんでした。解決、と。 『ライフハックの道具箱』: メールで誤字の指摘を頂いたので、それを反映させます。 ＊ ＊ ＊ OKです。 Textbox: 昨日作ったtracknoteをhome.mdから横スクロールで移動できるようにします。 ＊ ＊ ＊ 縦スクロールの移動はもう作ってあったので、そのコードの流用ですぐに作れました。これでhomeと〈今日のノート〉だけでなく、homeとtrackも簡単に移動できるようになりました。 14:00 うちあわせCast: 収録です。 ＊ ＊ ＊ publish:第百十九回：Tak.さんと2022年の振り返り 作成者：うちあわせCast 16:00 メルマガ: 続きを書きましょう。
原稿の管理について試す水曜日
作業記録の共有 原稿管理のテスト 原稿の移動やグルーピングを検討 うちあわせCast確認→実施 レシート入力 メルマガ+main稿（来年の指針） 8:00 おはようございます。本日は昨日考えた原稿管理をちょっと試してみましょう。何事も実験です。 断片:語り: 物はオブジェクトで、出来事はオブジェクトではない。 物語は、物について語る。物語はオブジェクトではない。つまり、「語り」が物をものでないものに変換する。 「語り」が出来事を起こす。たぶん、動物の中で「語り」を行うのは人間だけだろう。 話と噺。そして咄。それぞれに意味の差異はあるか。道。途。路。径。それぞれに違う意味があるように。 原稿管理: まず、Textbox下に何かの原稿を保存してみる。 まずここで、Textbox/list直下に入れるのか、list/document/に入れるのか、/documentに入れるのか、という選択が生まれる。 どこに保存しても、Textboxでは扱える。/list直下に入れたら他のページと同じようなリンクで扱える。 list/document/に入れたらリンクで扱えるが、しかし少し文字列が長くなる（document/hoge.mdのようなリンク）。 /documentに入れると、リンクでは扱えなくなり、新しい操作を確立する必要が出てくる。 ここで考えるのはリンクの生成と検索だろう。list/系列にした場合はリンクが同じように作れるが、list/document/に入れた場合は検索のサジェストには出てこない（そのように仕様を決めている）（変えることもできる）。/documentに入れると両方が機能しなくなる（新しい機能を付与することもできる）。 もし、原稿ファイルの名前をidやハッシュ値にするのではなく、タイトルの文字列にする場合、検索のサジェストに出てきたらどうなるか。ありがたいのか、迷惑なのか。まずそれを考える必要がある。 たとえばLogseqについて書いた連載がある。10以上の原稿がある。そういうのがLogseqと入力したときに一気に表示されたら嬉しいかどうか。あるいは邪魔になりすぎないかどうか。 正直これは数が増えたときの話で、数個のレベルでは判断がつかないだろう。しかし、増えた後で──特にlist直下に入れた後で──邪魔だからと動かすのはなかなか大変である。少なくとも、それができるように保険をかけておく必要がある。 もう一つ、原稿の操作について。たとえばR-styleに書いたものだけを抽出したいとか、処理済みやカテゴリのタグを付けたいといった操作をしたいかどうか。それとも単に呼び出せて読めたらヨシとして、処理は別の系列で行うのか。 たとえば、一行に原稿タイトル、媒体名、タグというのをファイルに書いて行けば、それがデータベースになるわけで、記事そのものに対して操作する必要はなくなる。そちらの方がスマートだろう。そのファイルについてはlist/直下に置けばいいだろう（別でも構わないが）。仮にlist/直下に置くならば、そのときリンクや検索がどうなったら嬉しいのかを考えれば、一歩前に進める。 あるいは、ページとしてはTextboxだが、原稿を呼び出しリンクを作るための機能をまったく別に設けることもできる。/documentに入れる場合はそうなるだろう。画像やPDFについてはそのような別体系になっているし、それはそれで別に問題ない（Textbox上で直接生成するファイルではないから）。 ＊ ＊ ＊ 純粋に整理という観点で考えればdocument/r-style/2022とかdocument/2022/r-style、という形にした方がいいだろう。しかしだったら、Fidnerで別によくね？という感じがしてしまう。ターミナルでlsとかしている方がよっぽどはやい。だから、今回はあえて「別の仕方」を考えてみよう。 ＊ ＊ ＊ 今/listの中を除いていたら、mmというフォルダを見つけた。/list/mm。これは先ほど考えていた/list/documentに近いものだろう。でもって、まったく触っていない。当然だろう。検索でも出てこないし、そのためのページも特に作っていない（と思う）。 と思って、一応検索ボックスに「メルマガ」と入れたら「メルマガ連載.md」というページが見つかって、そこに原稿一覧があった。 おおむね、今自分がやろうとしている環境である。が、ほとんど触られていない（忙しかったのものあるが）。なぜほとんど触られていないのかを考えれば、これから造ろうとしているものの要点が見つかるだろう。 ＊ ＊ ＊ 理由の一つにはこうしたリストをどのように使うのかが、この時点では明確でなかった、というのはあるだろう。今はそこが違っている。 ＊ ＊ ＊ たとえば、Evernoteを使うとしたら、どのように分けるか。媒体ごとにノートブックを分けるか？ そうしないだろう。せいぜい「書いた原稿」的なノートブックを作り、そこにすべてを投げ込むはずだ。で、タグで媒体を明記する。とすれば？ 何らかの形で、あとからピックアップできるようにしつつ、list/直下にすべて入れてしまうか？ 先ほどEvernoteだったら「書いた原稿」というノートブックを作ると書いた。しかし、今なら「書いた原稿」すらもタグにしてすべてを一つにまとめる可能性もある。 ＊ ＊ ＊ とりあえず、/list/mm/に入っているmdファイルをすべて/list直下に移動させます。ついでに、609-○「苦労したHomeはうまく使えない」のようなファイル名も「苦労したHomeはうまく使えない」に変更しておきます。 Pythonを書こう。 ＊ ＊ ＊ 簡単なスクリプトを書いて処理しました。 でもって、フォルダの移動です。一つ上にレベルアップ。 ＊ ＊ ＊ できました。まずこの「メルマガ原稿」を起点に話を進めていきましょう。R-styleやシゴタノ！についても同様のページを作り、さらにそれらすべてのリンクを集めるページを作る、という手もありますし、懐かしのインテグレートページを作っても良いでしょう。 あるいははじめからすべてを分けずに、一つのページで管理することもできます。リンクベースなのでこの辺は自由です。 年表みたいな形で縦のラインに並べてもいいですね。インテグレートページでそういう形にしてもいいでしょう。問題は媒体を超えた移動を可能にするかどうか。 あるいは「移動」をどう考えるのか。リンクなので、別にどうだっていいのですが、並び替えや新しいグループ作りをどのように行うのかをさらに考えたいところです。 たとえば、「メルマガ連載」のページは単純に時系列に原稿リストを並べていき、そこから別の領域にリンクを移動させてグループを作る、というやり方はできるでしょう。ただし、「どこで使ったのか」という情報を残しておかないと混乱しそうではあります。 これらのページは、バックナンバーリストであり、インデックスであるのか、それとも「素材置き場」なのか。後者なら直接移動させても問題ありませんが、前者なら移動するとマズイことになります。 11:00 原稿管理: 一応二重の体制でいくとしましょう。動かさないインデックスとしてのリストと、自分が書いたことを素材として使うためのページの二段構えです。