月: 2020年5月

社長：YouTubeを活用しようと思うんですが。

基盤：具体的には？

社長：開発したソフトの広告とか無料でできるんじゃないかと。実際の画面上の操作例は製品を説明するのに有効だと思う。うまくすれば視聴料までもらえるとか？

基盤：利用規定とかどうなってるんでしょうね。まあ、とりあえず技術的にどうやるのかを調べてみます。

基盤：やってみました。コンテンツには Opera のウィンドウのリストアを使いまして、こんな感じです↓

社長：おお、できましたね。それで、どうでした。

基盤：投稿自体はめちゃめちゃ簡単ですね。タイトル書いて、動画ドラッグして、ポチッと押す。それだけです。ただ、YouTube側での動画の受入れ処理にはかなりかかりますね。でその待ち時間に説明文を書きはじめたんですが、これに30分くらいかかりまして（笑）

基盤：それよりもアカウント名を何にするか迷ったのですが、まあお試しだし、u-tube (Tube You）にしときました（笑）。あと、macOSのスクリーンの動画はどうやって作るんだろうって30分くらい時間を食いましたが、なんのことはなく、OSに備え付けのキャプチャ機能をポチッとするだけでできました。YouTube への投稿よりこれに感動しましたね。最近のmacOS になるまでは、このQuickTime Playerが公式な静止画のキャプチャ機能も兼ねてたようです。それと、この元の動画は47秒で38MBで、もちろん画質はピクセル単位で完璧です。YouTube が配信するのは圧縮してかなり劣化してますね。

社長：そうでしたか。やっぱりMacOS最高ですね。サイコーでーっす！

2020-0511 SatoxITS

こんなにステキなブラウザがいつもそこにあったのに。これからはもうずっとOperaですね。さようならChrome！

Opera というブラウザは昔から知っていて時々使ってもいました。楚々とした上品な赤いブラウザだと思っていました。品は良いが機能と馬力が足りない、そんな風に認識していたので、何か他のブラウザでうまく行かなかった時のリリーフとか、逆に「Opera でもできるなら大丈夫」的な試験用でした。

ところが、私が目を離していた10年の間に、実用機能的に macOS+アプリが Windows に追いついていたのと同様に、いつからなのか Opera が他のブラウザに機能的に劣る事もなくなっていたようです。

こうなるともう使いやすさ、気持ちよさの勝負です。今日初めてまともに使ってみたのですが、私が10年間 Chrome や Firefox で不便・不快に耐えてきたことが、Opera ではほとんど解決済みなのです。使い勝手がよく考えられていることに唸ります。根本的に設計思想が素晴らしい、というか、実にマトモ。形容はもう楚々ではなく凶暴を秘めた凛ですね。

Chrome のブックマークも Opera にインポートしたので、あと Chrome に残す思いはパスワードだけです。どうせ今でも生きているのは半分くらいしかないし、本当にヤバイのはさらにその半分くらいですから、この際に見直しながら Opera に移そうと思います。同期したがるパスワードのヤバさがクラス分けされてなくて、モバイルの Chrome からですら全てベタに見えてしまうのはどうなんだ？と思っていたところでもあります。バイバイ Chrome。

明日からは（というか既に今現在から） Opera です。きっといつまでも。

2020-0511 sato@izmoh

---

というわけでさっそくOperaに浸ってまして、デスクトップがこんな風になりました↓

4 x 4 でミニュチュアオペラをタイル状に並べて動かしておいて、開きたいウィンドウのタブを見つけたらそれを Fullscreen にすると別室（別の仮想デスクトップ）に移動、閉じると元の位置に収まる、という形です。いろいろ使い勝手状の問題はありますが気持ち良いです。自分の経験では、同時に開いていて混乱しないウィンドウの数は20くらいまでだし、負荷的にもこんなところかなと思われます。

Operaの実装はたぶん1タブ／1プロセスになってますが、一プロセスはとても小さいです。Chrome時代に比べてメモリプレッシャーが低い。CPUは見た目常時100％近く食ってます（ユーザ70％、システム25％）が、プルセスの優先度が低いのでしょうか、マルチコアだし、インタラクティブな作業を邪魔する感じはほとんどありません。他にCPUバウンドなプログラムを走らせても、time コマンドは、70%程度はCPUを使えた、と報告します。

ウィンドウがすごく多くなったら、各プロセスの優先度をすごく落とすとか、明示的に一時停止させるとか、最近アクセスした順に並べるとか、色々な工夫が必要そうです。ミニチュア化したときに自動的に表示の倍率を小さくするとか、全体を統括するOperaとか必要です。なにより「Fullscreen」じゃない、「Normal」サイズのウィンドウの段階が必要です。昔のウィンドウシステムはそうなってたと思うんですが…Xとか、CEとか…

なんにしても、デスクトップスクリーンが広大になった今日、しかも仮想デスクトップもできるわけなので、もうオーバラップじゃなくてタイルだよなー、と思います。

Operaは終了しても、再起動すると、終了前のウィンドウを完全に復元してくれるので、この設定は継続的・永続的に使えます。もうアップデートのための再起動は苦じゃない (^-^)/。ただ、その復元作業のため、起動時にロードアベレージ120超えとか普通にしますが、それで他の作業に大きな支障が出る感じはありません。変に自前のスレッドとかしないで、OSが管理できる単位であるプロセスにしているのが勝因なのでしょうか？

2020-0511 SatoxITS

開発しているプログラムを別のプラットフォーム上でコンパイルして実行してテストしたい。少し変えてはテストしたいので、コンパイル結果は10秒程度で得られると良い。手持ちのツールだけでやりたい。

そう考えたのでとりあえず、変更したらプログラムをリモートのマシンにscpして、sshでコンパイルやテストのコマンドを送るという安直な方法にしました。今日びのOSはデフォでsshを装備しているので、追加でインストールするものはありません。

この手順を行う簡単なシェルスクリプトを書いただけで実現。変更分だけの再コンパイルであれば、差分が小さければ、コマンド打って10秒程度で結果が得られるのでほぼ満足しています。

気になったのは、プログラムをリモートに送り込むための時間です。ソースコード類のサイズはナマだと約10MB、tar して gzip して 2.5MB。scp だと状況によっては転送に数秒かかります。それだけでなく、これを何百回もやってると、サーバ側の従量ネットワーク課金が気になってしまいます。

それで思い出すのが昔懐かしい rsync です。ググってみると最近は通信に ssh を使うようになっていて、すごく健在のようでした。やはり原理的に良いものは生き残るのだな。よし、これで行こう。手元のマシンでも、リモートでも rsync とコマンドを打つと何か動くので、インストールされているようです。

どう使うのか？rsync -h とかするとどどっと出てくるので読む気にならない（（実は man rsyncの先頭だけ見ればサクッとわかることに後で気づく））。scp と同じノリで使えるとラッキーと思い、

% rsync ファイル リモートホスト:

としたら、そのまま動きました。 素晴らしいです。

性能的にはどうなんでしょう？超簡単なベンチマークをやってみました。

% openssl rand 10000000 > 10MB
% time rsync 10MB remote:
rsync 10MB remote:  0.46s user 0.37s system 6% cpu 12.435 total
% time rsync 10MB remote:
rsync 10MB remote:  0.06s user 0.08s system 7% cpu 1.833 total
% time rsync 10MB remote:
rsync 10MB remote:  0.06s user 0.07s system 7% cpu 1.804 total

リモートのファイルの cksum を確認しましたが、もちろん同一です。そしてこの例では、2回目以降は何もデータ内容に変更が無いので、何も送られていないようです。macOSの（とてもステキな）アクティビティモニターには、一発目の転送しか出てきません。

一方 scp では毎回データを転送してますので、毎回ニョキニョキと送信データグラフが伸びます。

% openssl rand 10000000 > 10MB
% time scp 10MB remote:
10MB     100% 9766KB 796.4KB/s   00:12    
scp 10MB remote:  0.18s user 0.20s system 2% cpu 13.473 total
% time scp 10MB remote:
10MB    100% 9766KB 893.0KB/s   00:10    
scp 10MB remote:  0.19s user 0.20s system 3% cpu 12.118 total
% time scp 10MB remote:
10MB       100% 9766KB 497.7KB/s   00:19    
scp 10MB remote:  0.19s user 0.19s system 1% cpu 20.791 total
…

このホスト関係、ネット環境だと、ssh 接続の確立に1.2秒かかる（この遅延、ログインする時に結構気になるんですが）ようなので、それよりは短縮できないですね。常設のトンネルw開通させておくしか無い。rsync自体の空作業は0.1秒未満の模様。

% echo a > a
% time scp a remote:
a                   100%    2     0.0KB/s   00:00
scp a remote:  0.01s user 0.01s system 2% cpu 1.217 total

% echo b > b    
% time rsync b remote:
rsync b remote:  0.01s user 0.02s system 2% cpu 1.283 total

考え所は、クラウド上のサーバのデータ（主に差分はログだけ）のバックアップも rsync でやるかどうかです。ファイル数が70万くらいあるので、変更されたファイルを効率的に知る方法が無いと、それを探索し回るのに結構な負荷がかかりそうです。まあ、変更した本人のサーバかOSが教えてやれればよいのでしょうけど。

とりあえずは、サーバ仮想マシンのディスクのスナップショットをとるほうが簡単だし全面的ですし、スナップショット保管料金は1日4円程度です。なので、あれはあれで良いかなという感じ。

クラウド上のドライブサービスも、rsync的な仕組みが入っていると良いですね。入ってるのかな？

2020-0509 sato@izmoh

---

先月 data URI scheme について書きましたが、今日はひょんな事から file URI scheme のお世話になりました。きっかけはこんな事でした。

「場所がわかっているファイルを簡単に開きたいのだが？」

そこで思い出したのが file URL [RFC8089]です。さっそく、ブラウザにファイルの場所（パス名、つまり file URL）をコピペしたらパッと開きました。おっと！なんだこのサクサク感は！これこそ自分が求めていたものですよ。

ウェブブラウザで file URL を使えば、ローカルなフォルダやプレーンテキスト系のファイルを快適にブラウズできます。文字サイズの拡大縮小もブラウザ機能で簡単にできます。ウェブ系とシームレスに「ブックマーク」が管理できる点も素晴らしいです。

Mac の Finder にしろ Windows のエクスプローラにしろ、あのもっさり感にはうんざりしています。それに老眼のため「字が小さくて読めない！」「ポインターが合わせられない！」とか、「ダブルクリックができない！」とか（笑）。フォルダの中身をナマで見たいのに！とか。

ウェブブラウザは、HTTPをはじめとする上位レベルの、個別のアプリケーションプロトコルによる、明示的なリモートサーバへのアクセスを実現しています。一方で、昨今隆盛のネットワークドライブ（仮想ドライブ）に見られるように、下位レベルにおいて、リモートなファイルとローカルなファイルと区別せずにアクセスができる環境も整ってきました。

このように下位レイヤでリソースのビューが一元化が実現されていれば、お目当てのリソースに対して具体的にどのようなプロトコルでアクセスしているかを、エンドユーザが気にする必要ありません。それはまったくのところ、file:///path/name で十分なのです。

当社で開発中の技術の応用においては、リソースへのアクセスを、こちらのエンドポイント（ユーザアプリ）からあちらのエンドポイント（リソース）に至るどこかの地点で捕捉し介入する必要があります。その地点としては、個別アプシケーションプロトコルのどこかのノード、あるいはリモートファイルアクセスプロトコルだと思って来たのですが、いろんな意味でどうもイマイチです。

それで今日思ったのは「やっぱブラウザでいいんじゃね？」ということです。ブラウザでやる、というのは最初に考えることではありますが、ブラウザ以外のアプリからその恩恵にあずかれないというのが難点だと思っていました。ですが今思い出したのは「ブラウザをサーバにすればいいじゃん」ということです。ああ、昔はそんな事を考えていたなと。ブラウザはクライアントとしての機能は完備していますから、これを再び（いろんなプロコトルの）サーバとしてサービスすれば良いわけです。要するに結局、プロキシですね。

ここで考えを戻すと、たとえば sftp://xxx なんてのもブラウザで実装してあれば、プラットフォームでの実装を待つ必要もないわけです。

機能面以外で考えられる問題点はやはり、セキュリティ・プライバシーの問題です。なにしろ、今日のブラウザはプライバシーにアクセスするためのポータルです。これにサーバの口をつけて外部からアクセスされてしまうと、非常に危険だろうなとは感じます。だからそこはガッチリとガードするか、根本的に不能にするかですね。

逆に言えば、ファイル転送プロトコルのような下位のレベルでは、上位レイヤにおけるような意味構造に基づく細粒度のセキュリティ保護が難しいので、下のレイヤほどトンネルされると危険、制御不能とも言えます。

さてそれで、現状の主要ブラウザにおける file URL の実装はどうなっているかと見てみると、これがもう data URI よりもサブイ状況（笑）↓

20年前からまるで進歩していないですね。せめてフォルダ階層のパンクズリストぐらい出してよ、25年前のDeleGateですらやってたんですから、と思います。見た目は、まあしょうがないというか、いっそ清々しいです。Finderの代わりに使うには、アップロードの機能が無いのが困ります。

実装は、おそらく共通のライブラリをまんま使っているだけなのでしょう。見た目がほぼ全く同じです。FireFoxだけは、わずかな工夫をしています。またSafariは独自の丸投げ路線で、macOS上ではFinderを、Windows上ではエクスプローラを呼んで済ませています。

見た目がこれだけしょぼいので、実装にも手が入れ易いのではないかと期待してしまいます。

2020-0509 sato@izmoh

---