Top  上へ  目次


 Ver.12の正式版リリースに至って思ったことをつらつらと

 ずっと先の話です。
 概念的な話であり、実装時期は未定かつ、どのような形態になるかも不明です。
 ぶっちゃけた話、規模的にメジャーバージョン番号が上がるタイミングじゃなきゃダメだろ!というネタが多いので「こんなのやりたいなー」というネタ帳的な妄想の備忘録であり、今後の方向性のひとつと考えていただければよろしいかと思います。


駄目なファイル名を作らせない工夫

 本稿執筆時点の作者のデスクトップに置いてあったテキストファイルの一覧です。(仕事に絡むものはは、趣旨を曲げない範囲で適当に加工してます)

1.txt
2.txt
2019_08_28メモ.txt
3.txt
aaaaa.txt
commandTimeout_120.txt
ClipboardText.txt
ClipboardText(2).txt
flexGrid.txt
sse.txt
todo.txt
wa.txt
work.txt
チェック112サーバー.txt
チェッククライアント.txt
チェックサーバー42.txt
めも.txt
めも3.txt
めも3.txt
めも0516.txt
概念.txt
概念1.txt
概念.txt(デスクトップcommonのディレクトリ)

 もうね、馬鹿かアホかと、クソみたいな名称をつけちゃってます。
 とはいえ、こういう駄目な状況を作ってしまっているのは私だけではないわけで、ファイル名の付け方というのは近年いろんな所で問題として認識されつつあります。

 最近では「公文書クライシス」という言葉でも表現されていますが、あるはずのファイルや記録が見つからないという問題があります。
 ちょっと前の話ですが、防衛省の日報があるとかないとか、なかなか結論が出てこなかったりしたのは、抽象化したファイル名を付ける様な運用をしていたからとかなんとか。
 だいぶ、悪意あるようにしか見えない報道や論調やらが見受けられましたが、抽象化っつーか、要するに厳密なルールが決められてなかっただけじゃね?と思ってます。(あくまでも個人の見解です)
 日報なんぞは普通、現場担当の人が各個人でまとめて、それをチームでまとめて、さらに上位の組織でまとめた上で清書するもので、どんどんまとめていく中間ファイルであるところのメモ書きに厳密な名称など、そんな細かいところまで決めておくべきなのか?とは疑問です。(あくまでも個人の見解です)
 とはいえ、情報が増えていくことに人間が追いつけなくなったという典型的な事例であり、人間の想像力だと事前の対策が難しいものですから致し方ないものと思います。
 ちゃんと反省して対策を考えられる社会ってすばらしい。(しつこいですが、あくまでも個人の見解です)

 さて、ファイルを後から見つけることができないというのは、まず「分類が適当だから」が一番大きなウェイトを締めると思いますが、次点で「名称が適当だから」も上位に来るんじゃないかと思います。
 というわけで、新規でファイルを作成する際の名称を、事前に、ある程度スタンダードな名称を、定型的に、決められるような仕組みを考えたいと思います。

 せっかく、内閣府あたりからもファイル名の付け方に関する標準例とか、公的な資料が出てきてるので、標準的なルールを初期値にして、そこから自分で肉付けできるようなカスタマイズができると幸せになれるかもしれません。

 あー、外国語圏は・・・ま、まぁ、この先に資料があったら考えましょう。
 いずれにせよ、シェルに丸投げ系の機能やら、OSが勝手に名前をつけているものを変更できるか否かの調査もこれからなので、まだまだネタの熟成が必要かと思います。
 (多分、ツリーの右クリックメニューの新規作成/貼り付けによる複製は対処不能)
 次点で、リネームの強化ですね。



よく使うファイル、アプリ、フォルダーは決して多くない

 これって忘れがちというか、最近まで意図して軽視していました。
 今までは「何でもかんでも取り込んでしまえ、情報の海から探し出すには管理を上手くすれば良いじゃないか」というのが基本スタンスです。
 今にして思えば、管理する人間のスペックが高いことを要求している話であり、そこまで気合を入れる必要がない場合、仕事でばっかり使うものじゃない場合、という観点がすっぽり抜け落ちています。
 階層のデザインとか、上記の命名規則とか、人力で何とかしなきゃいけないって、そりゃ不条理だよねぇと思うようになってきたのです。
 先般追加した「タグ」の管理もここに含まれるのですが、さらなる対策が必要に迫られているわけです。

 そもそもファイルシステム上には数十〜数百万個ものファイルが存在するわけですが、実際に起動するアプリや、編集・閲覧するファイルってぇのは数が少なくて、せいぜい数百に過ぎません。
 せいぜい数百なら、列挙しても良いでしょうし、それらを利用して新たな提案するというのも面白いかもしれません。

 実現例としては、アンケートの浪漫枠にありましたが、画面分割モードに切り替えたとき「お前さんが操作したいのは、このフォルダとこのフォルダか?ん?」と提案してくれるとか、上のファイル作成時にも新規作成するファイル名を履歴から提案してくれても良いでしょう。

 お気に入りやランチャは、検索窓を設けることで絞り込めて潜らないでも操作できると便利かもしれません。
 実行したコマンドやファイルを最近使った順に並べてくれても便利でしょうし、「最近使った順の監視を一時的に停止する」モードとか、「リストから選択して削除」とかあると、使い勝手がぐっと良くなる気がします。


 ぶっちゃけた話をすると私自身が年とって、フォルダ構成とか覚えてらんねー、名前付けるのだるー、アプリどこに配置したっけ・・・という、わりと致命的で切実な問題を抱えていることに気が付いたわけですよ。
 「お気に入り」を管理するユーザー定義バーの想定件数は1万件でしたが、オーバースペックで使いこなせねぇだろ?に、反論できません。
 いずれにせよ、履歴の収集、管理、利用法として検索、絞込み、応用として提案、再利用の仕組みが必要になるので、まだまだネタの熟成が必要かと思います。



ファイルの属性ってもっとあってもいいんじゃね?

 最近のWindows10のダウンロードフォルダなど、あいまいな日付のグループ分けが使用されています。
 ・今日
 ・今月に入って(先週を含めず)
 ・今年に入って(今月を含めず)
 といった、グループ分けですね。
 「含めず」のくだりは、もう少し工夫しろよと思わないでもないですが、以前よりぐっと人間寄りになり、分かりやすくなってきたと思います。

 これは日付に注目して、グループの見せ方を工夫している例だと思います。
 同様にビデオが格納されてるフォルダーだと、長さ、タイトル、アーティストとかでグループ分けというのも従来からあったかと思います。
 人間工学的な考え方を推し進めて、人間の認識を学問するようなアプローチがもっとあって良いと思うんですよね。

 ただこの手法、リストコントロールのグループ化という機能は、仮想リストでは使えません。
 (仮想リストって何ぞや?という方はぐぐって調べてください。高速で一覧表示する仕組みのひとつです)
 エクスプローラーが遅い理由のひとつはここに起因しているのだと考えていますので、速さ優先のソフトで同じような実装はありえません。
 ウチの実装だと、日付の色分けが類似の機能になるかなぁとも思いますが、もっと良い見せ方が無いかとも思うんですよね。
 いかんせん、地味過ぎです。

 あと、ファイルの属性って色々あると思うんですよ。
 ファイルシステム的に「誰が作ったか」といった情報を持っていないファイルの方が多いですし、「2020年7月まで保存」「1ヶ月使用しなければ削除」といった有効期限の情報もあっても良い気がします。

 また、現在実装しているのは、完全一致/部分一致の検索の仕組みですが、あいまい検索や近傍検索といった概念も人間にとっては必要なのではないか?とも思うわけです。
 例えば、漢数字とアラビア数字を同一視するとか、日本人的な発想があっても良さげだと思うんですよね。
 漢数字が良く使われる資料と言うものもあるわけですし。
 もちろん、これらをどうやって実現するか、全くの白紙なんですけど(ぉぃ)、こんなことをモヤモヤと考えています。

 属性と言えば、OneDrive配下のディレクトリにはMとかUとか、仕様を公開されてないような属性文字が付くことがあって困ったものだと思います。(多分どっちかが、FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS)
 この属性がファイルに付いてる場合は、ローカルにファイルが無いので開けないだけですが(それもひどい話だけど)、ディレクトリについてたら最悪で、実体のない仮想フォルダーになります。
 つまり、OneDrive配下の走査を行うのであれば、FindFirst系のAPIは使い物にならないわけで、多くの検索系のソフトが対処不能になるということです。
 うちはわりと新しいWindowsAPIに丸投げなのであまり問題になりにくいのですが、ファイルコピーツールの類ってどうしてるんでしょうか・・・



ビューア的な側面、もっと強化した方が良いんじゃね?

 プレビューバーって遅いんで使ってませんという意見がありました。
 激しく同意します。私もです。

 マウスホバーでプレビューとか、アンケートの浪漫枠で出てきたあたりから色々と試してはいるんですが、性能と邪魔にならないようにするバランスがどうにも取れません。
 静止画はそれなりに実現できるのですが、動画再生がねぇ・・・Visual StudioがActiveXを非対応にし、今後は(Windows10以降)メディアプレーヤーのエンジンすらが更新されないであろうと予想されるのも痛いです。
 しかも、現行のWindows10はあちこちバグってるしなぁ・・・というのもプレビューでの動画再生が色々トラブル起こしている原因と同じで、関連付けされているアプリとプレビューハンドラの紐付けがおかしいためエクスプローラーも変な動きをします。
 他の動画再生コンポーネントを本体に組み込むのは、ライセンス的に迷いますし。うーん。

 あと、ビューアのスクリプトの関連付けアプリのところに、「PreviewBar」とか書いておくとビューアーとして動作するとかですね。
 ぶっちゃけた話をすると、もう載せてるんですがリストの選択状態の連動が無効にできる設定がまだ非公開なので使い物にならないです。



スクリプト(デバッグ)

 ScriptTrace.exeで動いてる状況をトレースできると言うのはあるのですが、やっぱりブレイクポイントを仕掛けて、途中で止めたいですよね。
 というわけで、優先課題に格上げ。



「離れた位置のファイルをポイポイぶっこむ」バー(仮称)

 Ver.1.0どころかα版の頃から計画されていたモノなんですが、ぶっこんだ後どうするんだ?というのが課題のまま棚上げになっています。
 動きのイメージは、あらゆるフォルダからポイポイぶっこんで、コピーとか、別のアプリに渡すとか、削除するとか色んな操作を行えるようにするというものです。

 便利なのは間違いないですし、別に性能がダウンする要素もありませんし、操作のシナリオとして選択肢が増えるのは良さげにみえます。
 が、実装規模はとんでもなく大規模で、際限なく広がる可能性が高く、どこまでやるのかという線引きが必要なのですね。
 極端な話、リストと同じ規模でも良いわけですし。
 あとFinと同じように、複数のフォルダーにある同名ファイルをコピーし、それを貼り付けたらどうするんだ?という課題があります。
 まぁ、上書き確認のメッセージを出せばいいんでしょうけど、使い方が結構めんどくさいです。



更新(全件を再取得するタイプ)

 個人的な見解ですが、ファイラーを作るのが難しい部分って、この更新処理です。
 一覧で並べるごときは、大したことはありません。

 エクスプローラーでフォルダーをたくさん開いてると、やたらとPC全体の負荷が上がるのは1個のファイルが更新されても、そのフォルダ全体を全て更新しているからです。
 例えば、100万ファイルを列挙するのにエクスプローラーだと約90秒かかるとして、その中の1個でもファイルの更新を検出すると5〜7分くらい物理CPUコアが負荷100%に上がりっぱなしになります。
 このように一覧の初回表示よりも、更新の方が負荷が高いのに気がついてない人の方が多いのではないかと思います。
 要するにフォルダ開いていれば開いているほどPC全体の性能が劣化するわけですから、エクスプローラーを使いこなしている人ほど重いハンディキャップを抱えるという構造的なジレンマを抱える仕組みです。
 可哀想に、自分が非効率なことをしていることに気づいてないんだぜ・・・という酷い話です。
 また。おそらくこれもエクスプローラーがタブ化しにくい理由のひとつだと思います。

 As/Rの自動更新の特徴として、OSから発せられる更新通知の「差分」を処理することで、何タブ開いていても、ほとんどCPUやディスクの負荷が上がらないように作られています。
 100万ファイルあるフォルダの更新通知の処理がミリ秒単位で終了するのは、こういうカラクリを使って性能の差別化を行っています。

 ただAs/Rの方式にも弱点はあります。
 構成上、更新を100%キャッチして取りこぼしを防ぐことはできませんし、ネットワークでの差分の更新通知はSAMBAなどが対応していません。
 致命的なことに、正確性が万全ではありません。
 そのあたりはエクスプローラーと使い分けして欲しいところなんですが、もう少し歩み寄るべきじゃね?ということで全件を再取得するタイプの更新機能を追加して、正確性を優先するモードを検討しています。
 まぁ、「使い分け」と言う話なので「どうせ使われないであろう」というシナリオの可能性が大なんですが・・・。(遠い目)
 処理が重いし、負荷上げざるをえないしし、要らない機能になりかねませんし、やりたくないわー・・・で放置されていたものです。

 中身の話をすると、Windowsには3種類の更新通知をする仕組みがありまして、As/Rでは
 ReadDirectoryChanges()・・・「API通知」と呼んでいるもの、正確で差分のみ、ただしSAMBA等が未対応機器あり
 ShellChangeNotify()・・・「シェル通知」と呼んでいるもの、取りこぼし多い、10件くらい更新通知があると勝手にまとめる、嘘つきアプリにやたらと騙される
 この2つを設定で使い分けできるようにしています。

 これに、
 FindFirstChangeNotification()・・・「古典通知(仮名)」、指定フォルダ内で1個でも更新があると通知され、何が変更されたのかは不明、全件再走査して更新されたアイテム探す必要がある
 と言うものが、設定画面がないだけで実はVer.0から載ってます。
 ぶっちゃけた話をすると、旧作の更新検出エンジンが未だに残ってるともいえます。
 低性能が故に、どうやっても更新速度は劇遅いですし、ゴリゴリ自前で実装する必要がありますが、環境依存性は最強です。
 多分、エクスプローラーもこのAPIを使ってるか、非公開APIを直接使ってるものと思われます。

 あと、As/Rの弱点として、OSから発行される嘘の通知にだまされます。
 今はもう落ち着いていますが、ちょっと前までOS同梱のドライバが原因で、特定フォルダーのみガンガン更新通知が送られてきていました。
 「ごみ箱」と「コンピュータ」だけ、自動更新を止める設定が作られたのは、こういった背景です。

 あと、同じようにネットワークストレージのシェル拡張ソフトは、かなり酷かった記憶があります。
 G印やM印の、大手ベンダーがやらかしてた不具合だけに、影響が大きかったです。
 こいつら、OSに負荷をかけまくってたんですが、この不具合は数年放置されていましたように思います。
 今も発生するのかはめんどくさくて確認していませんが、OneDriveは落ち着きた気がします。


にゃんこ成分をもっと!

 動物系のファイラーといえば、個人的には某ハムスターの黒歴史が思い浮かぶわけですが、他には・・・トカゲと恐竜と亀は居たな。
 爬虫類の割合がたけーよ。
 というわけで、ファイラー界の哺乳類率を上げるべく立ち上がろうと思います。



絞込み/表示モードの組み合わせ/検索条件/一括リネーム条件を保存したい

 名前をつけて保存できれば幸せかもしれません。
 ・・・多分




 さて「ネタが尽きた!アンケートでネタ募集!」ってやってるわりには、チラホラやりたいことが生えてきてる気がしますが、これも浪漫枠の刺激を受けてのことだと思っています。
 またネタに困ってきたら、よろしくお願いします。
 気持ち的には、あと10年は戦える!というつもりですし、やることがあるというのは良いことなんでしょう。きっと。

 ・・・あ、1年で終わるフラグ立てた?