メモ帳はApple Notesに決めました

社長:わたしのメモ帳はApple の Notes にすることに決めました。もともとiPhoneでは使っていたのですが、デスクトップでもNotesにします。

社長:まず立ち上がりが1秒足らずと高速。テキスト入力がサクサク。画像がドラッグ&ドロップで扱える。それとMacとiPhoneで暮らしていますので固定とモバイルで共有が簡単。そして、月額130円50GBのiCloudのストレージがスカスカだからです。

基盤:どうせスカスカならスクリーンショットもiCloud の Notesに叩き込むと良いかもですね。

社長:いや、スクリーンショットの送り先にNotesは指定できないんですよ残念ながら。あと、iCloudに保存するのは遅いし、間違ってiPhoneに同期とかしたく無いですから。一方で、iPhoneで撮った写真をサクッとノートにして、それをすぐにデスクトップからも見えるというのは大変便利です。

社長:画像にメモをつけて保存したり、フォルダに整理したり、拡大縮小プレビューができるツールとして、Notesはとても使い易いことに気付きました。なので、ローカルディスク上(On My Mac)上のノートフォルダを作って、そこでスクリーンショットを管理することにしました。

社長:Notesへの画像ファイルの張り込みや取り出しはドラッグ&ドロップでサクサクだし、無段階で拡大縮小できるとか、動画の再生もその場でできるとか、とても気に入っています。取り出したファイルの日付が保持されているのもありがたい。まだ有効には使ってはいませんがPDFをインラインで表示してくれるツールというのは初めて見ました。

社長:残念な点も多々あります。たとえば印刷がノート単位でしかできないこと。これはMailにも言えることですが、せっかく複数を選択できるのに、それらをまとめて印刷(PDF化)できないのが残念。張り込んだ画像(アタッチメント)については、画像ファイルの属性をデスクトップやファインダーでやってくれるように表示できないことが残念です。そういうモードとか、コンテクストメニューがあると良いのですが。張り込み画像だけ一覧するビューがあって、これも便利なのですが、やはり属性情報が表示されない。それと、アタッチメントをクリックしたらそれを含んでいるノートに飛ぶとかして欲しいものです。

社長:おやおや?ノートを Small Images表示にすると、一部のファイル形式はサイズ情報付きになりますね。いまやってます中なんですかね。面白い過渡期を目撃してしまいました。パシャ。是非、デスクトップでのアイコン表示のように、日付情報もつけて欲しいものです。

社長:もう一つ残念なのが、ノートをギャラリー表示にした時の背景です。背景が真っ白でつまらないというか、各ノートに背景色が無いというか薄いから、メリハリが無いというか、どうも生気にかけます。

白装束的なNotesのギャラリー背景

社長:それで、ギャラリーの背景を変える方法を検索したのですが、以前の記事に背景はNotesアプリのフォルダにある画像ファイルだからそれを置き換えれば良い、とありました。でも現在の版ではそれは無いのです。

基盤:この、Notes.app のリソースの下にある CSS がそれっぽいですね。

MacMini% ls -l /System/Applications/Notes.app/Contents/Resources/pad.css
-rw-r--r--  1 root  wheel  2318 Nov 10  2019 /System/Applications/Notes.app/Contents/Resources/pad.css

基盤:背景を指定しているのはここでしょうか?

body {
    margin: var(--margin-top) 14px var(--margin-bottom) 19px;
    padding: 0;
    font: @[FONT_SIZE]px @[FONT_NAME];
    word-wrap: break-word;
    line-height:1.35;
    height: 100%;
    color: -apple-system-label;

    /* Notes from Mail can have a bgcolor set in the HTML, so override it to a clear color */
    background: rgba(0,0,0,0) !important;
}

開発:各ノートの背景の話のようにも見えますね。ただいずれにしても、これをいじれるといろいろ面白いことができるかもしれません。

基盤:ただ、/ って read-only で mount されてるから、rw でマウントしなおさないと。でもちょっと怖いなー。なんか壊したら当社の業務停止しますからね。

社長:来週くらいに新しい iMac が来ますから、それからにしますかね。この MacMini はいびられ役として余生を過ごすのかな。

--
2020-0614 SatoxITS

jQUEEN 計画

社長:帰りました。

経理:酒くさいですね。

基盤:今日は例のタイ料理ですか?

社長:いえ、あそこはお休みでした。日曜がかき入れ時というような店ではないのでしょう。で、斜め右50m位のところで白いのれんが揺れてたのでそちらへ。

社長:飲んでて気づいたのですが、いわゆるハッピーアワーでした。昼間はずっとハッピーなんですって。アルコール半額ですよ。これ、やばくないですか?わたしがかねてよりかくあるべしと思っていた世界が徒歩7分の場所にあったのです!

開発:その店の場所ってもしや?

社長:そう思って店長さんに聞いたら、昔つくば出身のお相撲さんがやってたちゃんこ屋さんのあった場所だったんです。

開発:就職したての頃は結構通いましたね。

社長:それで飲み食いしながらiPhoneでうちのサイトを眺めてて、思いましたね。いよいよその時が来たかなって。

営業:廃業ですか?

社長:いえ。JavaScriptだけでコンパクトなブラウザを作ったら自分の好きなようにいじれて面白いだろうなと思ったんです。で名前をどうしようかと考えていたるのですが「jQueen」 が良いかなと。

基盤:何か不遜な感じのネーミングですね。

社長:当社イメージカラーは Royal Blue ですし。陰ながら全英女王の応援もしています。毎日ひと缶、SUNTRY の Gokuriとか。

開発:Monzillo で行くと言う話ではなかったでしたっけ。

社長:昨日の UEE からピンと来てしまっていたのです。Quick URL/Unified/Universal Explorer Express みたいな。どんなブラウザにも寄生して共通のシンプルなUIを提供する、それと当社の独自機能のUIを制御する、そういう感じです。

開発:正直、Mozilla のコードを見たり、ちょっといじったりして、これはちょっと方向が違うかなとは思っています。少なくとも最初に飛び込む入り口では無い。開発作業のターンアラウンドも長い。JavaScript だとゼロ秒台ですからねぇ。

社長:ただ、全てのサイトにjQueenが居るように見せるには、ブラウザの援助は必要かなと思います。ひさしを借りて母屋のっとり計画(笑)

開発:そのあたり、client side CSS のサポートにしても、どのブラウザもイマイチサポートする気がなさそうな気配を感じます。どうやら最近は XMLHttpRequest とか WebSocket というものが普及しているようなので、これを使って独力でという可能性もありかなと思いますね。特に WebSocket は要するに Socket のようですから、HTTP以外でもなんでもできちゃうかなと。現行の技術を使い倒して多機能プロキシサーバを作るというのも面白いと思います。

基盤:jqueen という会社はありますね。まあでも、業種が全然かぶらないから良いのかな。

社長:なんとなれば GjQueen でも良いです。あ、そうしようかな。GJ。おや、.win なんていうTLDがあるんですね。面白いから取ってみよう。ぽちっと。でも、ドメイン取るのももう飽きたかな。

経費:会社の製品やサービスに繋がらない名前は経費と認められない可能性がありますね。

--
2020-0614 SatoxITS

UEE - URL Elevator Express

URL Elevator express


[ 上のURLの一部をパッと取り出せます ]

開発:例の file URL の中の上位のパスにジャンプする機能ですが。

社長:ブラウザの開発環境もできたし、そろそろまじめに作りますか。

開発:いえ、やめようと思います。

社長:あ、そうなの。なぜ?

開発:これは基本、file や ftp に限らず、URL全般に適用したほうが良いと思い直したんです。やることは同じなんですが、やる場所が変わります。といいますか、やる場所の選択肢が増えます。

基盤:でも、やる場所によって使える言語が変わりますよね。

開発:文字列の変換は同じ、表示の仕方だけの違いですから、本質的には単純ですよね。

基盤:多分本命は苦手の JavaScript ということになりますが。

開発:ゼロからのスタートです。で、まずモックアップから。やりたいことは、こういうのを自動生成することです。

開発:で、これを JavaScriptで書くとこうなる。これ、私が人生で初めて書いたJavaScript です(笑)

開発:で、一般化するために現在のページのURLを取ってくるわけですが、たぶん document.url とかじゃないかと思ったんですが、undefined になる。で、仕様を調べると document.URL なんですね。惜しかった。JavaScriptが case sensitive なんだということを初めて明確に理解しました。

開発:で、これを / を区切りに分解して、アンカーを挟み込みながら結合するわけです。そういうのは一般的に split / join というような名前の関数に違いありません。で、javascript split join でググるとたくさん例が出てきます。由緒もあるのでMDNにあるsplitのガイドから。

開発:余計なことが書いてないのでわかりやすいですね。それでちょっと変えてリロードしたら、何も出なくなりました。追加した部分で write() を wirte() と書き間違ってたんたんです。ステートメントの逐次実行即出力じゃないようです。また文字列の連結をとりあえずCと同様に並べて書いてしまったのですが、+ で連結することがわかりました。あと、JavaScriptのコメントがCと同じで /* */ だということがわかりました。

開発:for文のシンタックスがCと同じだということがわかり、少し驚きました。C風の言語は多いですが、for の構文は崩されてしまています。また、値を文字列にするのは toString() じゃないかと思ったら当たりました。

開発:ぬるぽは nil かなとおもったら null でした。

開発:ということで、文字列処理については雰囲気はつかめました。表示部分をちょっと整えて一旦休憩します。

基盤:前回、C++で同じ処理を実装する時には、もっと時間がかかってましたね。

開発:あれは、C++にsplit / join がなかったことと、自作の生文字列 split / join と Mozilla のストリングクラスとのやりとりがよくわからなかったからです。

開発:ここまでのところ、C言語に慣れている人間には、ごく普通の言語だなという印象です。ただ、タイポが多い自分としては、未定義名とか実行するまでわからないのは、ちょっと厳しい感じはしました。

社長:変更するたびに100%のカバレッジでのテストが必須なんでしょうかね。いや、昔少しだけ Google Apps Script (GAS)で遊んだことがあって、あれはその点が結構問題でした。GASとか、何時間も走らせるわけですが、えらく時間がたったあとに初めて実行するステートメントで、構文エラーですって。それまでの処理がパーになるわけです。実行前にそういう静的な検証をしてくれない処理系って、私には無理ですね。

開発:そういう意味では、ちゃんとユニットに分解してユニットテストしましょうね、っていう事かもしれませんけどね。

* * *

開発:それではなんかアクションを入れてみたいですね。その前にちょっと整理。

開発:マウスカーソルをそのパスに置いたら、その部分のURLがポップするっているのをやりたいですね。まあ、ステータスバーに出てるからいいじゃんていう話ではありますけど。マウスポインターに反応して応答するというのをやってみようかと。私が見覚えがあるのは、onMouseOver() というやつです。こんな感じ。

開発:反応しましたが、これじゃ使い物にならないですね。ただこれでわかったのは、HTMLは case insensitive だけど、JavaScriptはcase sensitive だということです。そりゃそうですね。大文字小文字を区別しない言語とかOSとかファイルシステムとか、ついでに検索エンジンも、アンビリーバブルです。

開発:じゃあ alert じゃなくて何が適切だろうかというと、ポップアップ系はユーザがなにかポチらないと消えないのでダメですね。

* * *

開発:いやはや、しばらく検索してましたが、ポップアップの仕方はすごい色々あるみたいですが、それはまあプログラム書けば何でもできますよね的な感じはします。納得感のあった一例は主にHTMLとCSSで見せ方を記述して、JavaScriptではその可視性だけを制御するという、w3scoolsの例です。

開発:それにしても感じるのは、JavaScriptで書いたページが環境依存だということです。少し昔の解説ページの例題が現在のブラウザで動かないとか。あるいは、以下には今作成中のスクリプトを貼り付けてありますが、WordPressでは動かない。編集モードやブロックのプレビューでは動くのですが・・・

Ancestors v.10


(Jump to the ancestor)

開発:と思ったもの、/* */でコメントアウトしつつ匍匐前進したら、JavaScriptの配列の使い方が間違っていたことがわかりました(笑)。splitした時に配列がnullで終端してるものと想定してしまったC言語育ちの悲しい佐賀でした。(実際、ゼロになっている場合が多いからタチが悪いわけですが)。

開発:ということで、どうやらWordPressのページには特に問題なくJavaScriptを貼り付けられる模様です。となると、何もプラグインとか使わなくてもかなりのことが出来そうな気がします。

開発:ただ、WordPressのHTML編集モードはきわめてしょぼい。まあ、これもHTML編集プラグインとかあるのかもしれませんが。デフォで提供されている「HTMLとして編集する」が寒すぎるんですよね。世の中には結構出来の良いHTMLエディタがあるのに、なんでWordPressのようなメジャーなフレームワークにそれがデフォルトで入ってないのか、理解に苦しみます。

開発:それはそうと、次に知りたいのは、JavaScriptで「現在ポイントされている部分が何であるか」をどう読み出すのか?です。ポイントされている部品は決まっているので、それぞれが「自分がポイントされている時のアクション」を記述することは簡単ですが、それはダサい。でも調べるのが面倒になってきました。指されるほうは onMouseOver とかで自分の上にマウスが出入りした事を知っていますから、onmouoverのイベントに引数を渡せれば、自分だよ、ということを知らせることができるわけです。ですが検索すると、ずばりそういうQ&Aがありました。

Determine which element the mouse pointer is on top of in Javascript

開発:この中で、後続のコメントでobsolete扱いされてますが、XY座標から何がさされているか知る方法として、document.elementFromPoint(x,y) というのが紹介されています。で私はこのQ&A本体よりもその例の中で使われている event.clientX, event.clientY というものにおーっと思ったわけです。ああ、Google の reCAPTCHA もこれ使ってるのかなって。

* * *

基盤:それはそうと、私はこの、今年に入ってからだと思いますがウエルシアで山積みイチオシの「辛辛魚」に非常み興味を持ってまして、ゲホッ、大変面白いコンセプトのカップ麺だなと。ズズッ。

社長:これは、スープを最後まで飲もうかどうか検討する価値のある品ですね。ただ残念なことに、この魚介粉がいかにも安物。ズズッ。もしちゃんとした花かつおでも使ったら、その味はいかばかりかと期待してしまいます。ゲホッ。

開発:辛さと旨味が不可分に存在しているという食材の例は多いですね。食われるほうは旨くありたいなんて意図は無いんでしょうけど。ズズー。

* * *

開発:それでは続きを進めたいと思います。で、上のv.10からコピーして来たわけですが、そのままでは動かなかったわけですよ。なぜかと言うと、CSSにもJavaScriptにも名前のスコープが無いからです。名前がぶつかったら最初の人に飛んじゃうんですね。なのでしょうがないから名前を全部11に書き変えました。

Ancestors v.11


(Jump to the ancestor)

基盤:プログラミングの分野で育った人間にはちょっと想像がつかないですね。マクロですか?BASICですか?って。

社長:それ、ずっと不思議だったんですけど、HTML5でも同じなんですかね?

開発:さあ。そもそもの出発点からそうだったっていう時点で、なんかもう価値観が違う人たちなのかなって思うじゃ無いですか。プログラム言語の世界では太古に完成してたやり方を無視して劣化版の再発明ですか。いや、スコープとかって確かに処理には邪魔臭いかもしれませんけど、それをいったらCSSの上書き上書きで一体何が最終的に採用されてんだかワカメっていうあれは何なんだと思いますね。だもんで、WordPressで指定したクラスのフォントサイズを変更するのって、今の私には無理ゲーですよ。

基盤:何かの雇用対策かもしれないですね。コロナだし。

開発:それはそうと、私のJavaScriptに関する疑問は、このElement.innterHTMLの例を見て氷解しました。シンブルで、全てを物語っているような例題です。それで、今日のお題はこのような解答になりました。

Ancestors v.12 -- Exp. Elevator


[ ↑ お望みの階層へ直行します ]

社長:なんだ、そういう事だったのですか。長年の疑問が解けました。とてもわかりやすいのですが、JavaScript って昔からこう言うものだったのでしょうかね?

社長:ところで、HTMLを書き換える方法はわかったのですが、CSSを動的に生成するってできるんでしょうか?

社長:あと、JavaScriptでマンデルブロー書いたら面白そうですね。ベンチマークにもなりそう。

社長:あと、なんちゃってreCAPTCHAも作ってみたいですね。あれ、特許に触れるのかな?

開発:今日できたものを少し整理しまました。はじめての JavaScript、記念写真をパシャ。

urlexp 2020-0613 コード

基盤:Creative Commons てプログラムコードとかにも使うもんですかね。

開発:さあ。単なるノリです。

社長:え?CCって当社クリエィティブコモデティの意味じゃないの?

営業:それなら CC BUY ですよね。

--
2020-0613 SatoxITS

Windowsからの生還

ブログに異常に長い文章を書くのは奇妙であり読みにくくもあるため、長い本文は固定ページにして、サマリーだけブログに書くことにしました。

今日は「Windowsからの生還」について書き始めました。あまりに長くMacを離れており、その間Windowsに洗脳もされてしまったので、ひどく基本的なところから戸惑いました。これまでの、またこれからも、復帰プログラムの過程をメモすることにします。

2020-0427 sato@izmoh


経費節減(仮想マシン)

問題提起

僭越ですが「入るを量りて出ずるを制す」です。会社の収入に見合う支出に抑えるのは経営の鉄則。当社の身の丈を考えれば、毎月のインフラ維持費は2〜3万円が妥当と考えます。会社設立時新規に購入した機材はもちろん、加入したネットワーク、各種サービス・サブスクリプションについても、100円/月単位で厳格にコストを評価して抑制の努力をして来たところです。

そんな中、大きな問題として、設立以前の活動から継承されるサービスの維持費があります。とりわけ、社長が個人として運営して来たサーバサイト(delegate.org)です。今後の当社の業務と深く関係するサイトであり、会社としてその運営を引き継ぐ由。それに掛かる運営費のうち、ドメイン名維持費としてN. Solutionsに支払っている年間$10.00は、他社の同様なサービスの料金と比較して妥当と言えます。一方、サーバの運用費用としてMS Win. Azureに支出されて来た月当たりおよそ1万円は昨今の一般的レンタルサーバ費用と比較して全く妥当性を欠き、そのままでは会社として引き継ぐ事を許容できません。

本件にかかる維持費としては半減目標としては3,000円/月以内とすることを求めます。費用削減の検討、実施計画をお願いします。

経理部 佐藤
2020-0426

p.s. 解約手続きもありますので、Azureの次回課金期間が始まる5月11日より前に、余裕を持って移行を決行してくださるようお願いします。


対応決定

どうも、社長です。経費の節減に関してご提案をありがとうございます。本件については、早急に対策を講じたいと思います。まず状況整理のため、これまでの経緯を説明します。

当該サーバためのAzureのサブスクリプションは仮想マシン(従量課金)となっています。利用目的が、WebサーバやFTPサーバをはじめ、独自開発したサーバ類の運用試験でもあること、またソフトウェア開発環境として利用することを考えていたため、Web専用のサーバでは足りず、仮想マシンとしてのレンタルしか選択肢がありませんでした。課金が従量ベースであるということも、無用な費用を抑えられるという期待から、望ましいと判断しました。

費用的にも、2014年に利用を開始した当時には全く妥当な選択でした。それまでは、サーバ運用のための回線と固定IPアドレス、サーバ機、UPS、バックアップ用ディスク等の機材、またそれらによる電力使用料金を合算すると、毎月およそ3万円を費やしていました。ですので、それらを全て代替して月1万円というのは劇的なコストダウンであったのです。しかも、それ以前には何度かサーバ機のクラッシュあるいは停電によるサービス途絶があり、復旧のための労力もかかっていましたから、サーバをクラウドに移行することで、単純に費用として見積もりがたいメリットもあったのです。

レンタルサービスとしては、Azureとともに、Amazon AWSを検討しました。試用してみたところ、当時のAzureはシンプルで非常にわかり易く、とても親切でほぼバカチョン、一方AWSは難解に感じました。それで、Azure にUbuntu の仮想マシンをサクッと立ててDeleGateの運用を開始、開発作業も主にこの仮想マシンで行っていました。当初は大変快適に使えていました。

ですが実のところ、Azureが行った何らかのアップデートに巻き込まれて発生したUbuntuの回復不能状態のために2度、仮想マシンをゼロから作り直す必要はありました。その際に10数年分のログ情報も消失してしまいました。リセット後に継続が保証されているのが30ギガバイトという信じがたい制約にも苦しめられて来ました。しかもその後、管理コンソールが次々に改悪され複雑化し重くなっていったAzureからは、いずれ撤収したいと思っていたのも事実です。

なのですが、2014年にAzureに移行後ほどなくして、前職での本業に追われるようになり、世情の変化にキャッチアップできず、コストの見直しを行うことができませんでした。それに、コストを削減できたとしてもおそらく半分程度、私人としての感覚でたとえれば1日の飲み代程度ですから、月に1日断酒すれば済む事、削減作業のためにかかる労力も考えると、総合的に考えて割に合わず、確かに言ってみれば放置していた、という経緯です。

会社としての経費の支出において、この状態が望ましくない事は承知しており、早急に対策を取りたいと思います。まずは基盤部に現状調査と対策案の検討を指示します。

社長
2020-0426

p.s. Azure の仮想マシンは、止めておけば課金は生じないので、解約を急ぐ必要はありませんよ。


現状調査

基盤部より報告(1)

基盤部の佐藤です。インフラのコスト効果の調査ですので、まずは現状、何にいくらかかっているのかざっと調べました。何年も前からのことですので、オンラインでの追跡調査が可能かな…と。実際 Azure のサイト(portal.azure.com)では、過去の注文履歴の検索が困難です(これには以前から私も困ってました)。それで、何やかやしているうちに acount.microsoft.comというサイト(最近できた?)に入っていて、全注文履歴を閲覧できました。(共通のアカウントでログインできているようなのに両者が連携していないという、あいからわず不思議な会社ですわ)

それによると、実際にはAzure(従量料金)のサブスクリプションは 2013年8月に開始されています。開始月に¥10,492、その後ほぼ横這いで推移しています。最大の月でも¥12,108でした。また、昨年(2019)6月に¥10,525だったものが突然、7月に¥8,451に低下し、それ以降横這いで推移していました。何か劇的な料金体系変更が起きたとも考えられますが、その後、先の3月分¥8,440だったものが4月分¥9,540になっていますので、そうとも言いい切れません。それに前後して、仮想マシンで動作させるサーバやアクセス状況に、大きな変化があった形跡はありません。(てか、ディスクフルになって3カ月分のログが飛んでましたよ 笑)

利用料金の分析

課金の内訳(根拠)は上記のアカウントサイトでは見られなかったので Azure のportal.azure.com に戻って調べました。請求書情報は過去12回(12ヶ月)ぶんしか見られませんが、月ごとに以下のような課金の遷移になってました。

MS用語はイマイチわからないのですが、水色が仮想マシン(主にCPU使用量?)、紺色が Storage(つまりディスク?アクセス量?)、小豆色がバンド幅(つまりネットワーク通信量かな)です。たしかに、最初から2本目が6月なので、次の7月にガクッと料金が低下しています。減少したのは紺色、つまりStorage料金です。まさか消費税を乗せ忘れたとしても、計算が合いません。やはり価格改訂かな?

一方、¥8,675 (税込み¥9,540)だった4月請求分(3/11 - 4/10)の使用料金の内訳は以下のようでした。小豆色がそそりたっているのは 3/30 なので、これは社長が身辺整理の一環でファイルのコピー等を行っていた際の使用であると思われます。当日、このサイトの来訪者向けHTTPやFTPサーバのアクセス数は通常通りでしたので、これはやはり、裏口からscpで行った全力ファイル転送のためと考えられます。

このように日別にみると「従量料金」とは言え、毎日ほぼ一定です。これはおそらく、使用量の最低量が決められていて、その基本料金ということと思われます。最終の2日間に突然変化していますが、これは課金のための整理作業かなんかのためではないかと。実際の運用状況は、この期間を通して平坦でしたから。

これから考えるに、この仮想マシンの固定費は¥8,000/月を下回ることができない、ということになります。これはいまどき、この30GBというバックアップ保証ディスク容量から考えても、あり得ない料金と言えます。またもう一つの問題は、従量通信料金の高さです。外部からガンガンにネットワークアクセスされると小豆色部分がのしかかり、従量料金総額として¥16,000/月にも達する恐れがある、ということです。これは当社にとって、許容しがたいリスクのレベルではないでしょうか?

これと同規模のしょぼいサービスであれば(もしあればですが)、¥3,000/月定額ですら割高、と考えます。[1]

基盤部 佐藤
2020-0426

[1] ご参考までに。当社が現在使用しているレンタルウェブサーバは、250GB SSD、転送量目安 3TB/月で、¥1,300/月ポッキリです(当社では12ヶ月まとめ払いで¥980/月ポッキリとなりました)。3TB/月は、概算で100GB/日、10Mbpsです。簡易測定したところ、表玄関のHTTPでは100Mbps、裏玄関のscpでは10Mbpsでした。TCPやSSHサーバでリミッターをかけていると思われます。それでもこれは、現状の当社のウェブサービスや、製品の配信にとって、十分な能力です。つけ加えますと、このサーバのOSは Linux、カーネルは 3.10で、SSHで入って作業ができ、C言語の開発環境やOpenSSLなどのライブラリも揃っています。ベンチマークによっては、Azure上の仮想マシンの3〜4倍の性能をたたき出します。super user にはなれず、システムのファイルにもアクセスできないので逆に安心ですし、当社の製品はまさに、通常ユーザとして使用するサーバですので、問題ありません。通常ユーザとしての自前サーバでは、標準のHTTPやFTPなどのポートで外部からのアクセスを受けることはできませんが、SSHの口が空いているわけですから、ここを通して自前サーバにアクセスするようにするのは技術的にはカンタンです。要するに、少なくとも予備もしくは拡張機能用のサーバ機として使用するのに十分なスペックであり、またLinux用ソフトウェアの開発マシンとしても耐えます。ただし、そのような利用に問題がないかは、当該サーバレンタル会社に問い合わせてはいますが、確認できていません。推測ですが、迷惑になるような理不尽な使い方をしなければ、怒られないんじゃないかなと…

佐藤メモ:
・Amazon AWS の無料枠を活用できないか
・Azure にも今はリーズナブルなプランがあるに違いない
・静的コンテンツ、ファイルサーバは別に置いても良い
 ー バックアップ機能付き、アクセスログ機能付きであること
 ー 通信量は固定・無料であること
・分散したとしても、全体を一体管理し易いことも重要
 ー 記憶域(ディスク)はクラウド上のドライブで統合するとか
・自社内にサーバを置くことも検討
 ー ギガビットインターネットが来ているので通信容量は十分
・手元のVMwareでラクラク運転・保守できるのと同じ感覚が良い
・サーバの階層化を考える
 ー クラウド上には基本的・固定コンテンツ・サービスのみ(安定運転)
 ー 拡張コンテンツとサーバは社内サーバに置く(長ダウンタイム許容)


技術提案準備:
・仮想マシンで行く
 ー クラウドに置くなら必然
 ー 手元に置くにも管理し易く、セキュリティ面でも有利
 ー 手元とクラウドの間でカンタンに移行・並行できる
・VMwareをVMホストとする
 ー 実績十分、ホストマシンはWinでもMacでも良し
 ー VirtualBox とかショボすぎる
 ー Hyper-v はMac版が無い
・Linux仮想マシンをウェブサーバホストとする
 ー Mac仮想マシンもありかも、Winではやりたくない
 ー AMPするにはやはりLinuxかな?
・クラウド仮想マシンをサーバ入り口とする
 ー ミニマム料金に収まるサーバを置く
 ー 微々たる通信量が従量料金を動かすのは問題外
 ー 残りは手元の拡張サーバに転送する
・WordPress/Apache + DeleGateを動かす
 ー どちらを根っこにしても良し
・全てのファイルはクラウドに置きたい
 ー 性能から言えばGoogleDriveだが
 ー Unixのシンボリックリンクが使えないのは問題
  ー 仮想マシンの仮想ディスク置き場と考えれば無問題
・RealVNCを活用できるか?
 ー たとえば汎用サーバとして
 ー そのための費用は生じる


クラウド仮想マシン・コスト評価

基盤部 佐藤メモ

まずは、うちが契約してるAzureが現状の水準の中で大損してないかが気になる。Azureの課金は複雑で人間には計算が無理だから、料金計算サイトに行こう。
https://azure.microsoft.com/ja-jp/pricing/calculator
よくわからないが、とりあえずLinux仮想マシンで従量料金デフォで$85/月と出る。てことは現状の費用がとんでもないということではないようだ。一安心。まあその辺は従量だから、現状に追随しているんだろう。

だが待てよ、ストレージも一応30GB ついてるし、IPアドレスも1ついてる。あと先月は通信量も結構かかった。もう一度内容を確認しよう。

「コスト分析」

なるほど、VMが¥4,992、ストレージが¥2,870、バンド幅が¥789、あとはゴミだな。つまり、この3点セットで料金計算すれば良いということか。料金計算サイトに戻ろう。

ストレージを30GBにすると、$1.66/月と出る。あれこれはうちの場合と全然違うじゃないか。デフォの読み書き回数が100,000回で計算してるからかな。ウェブサーバとしてそんなことはあり得ない。HTTPだけにしても、1日100,000回から200,000回程度のリクエストはあるんだから。10,000,000回ずつにしてみよう。お、$55/月と出た。まあこれなら桁的にはあってる。ログをかなり細かくとってるから、読み書きは拮抗してるんじゃなじゃないだろうか。でもコスト分析表によると¥789は data transfer out とあるから、やっぱサーバの応答分なのかな。Azureの中で閉じてるディスクI/Oは、たぶんこの、disk read/writeあたりなんだろうか。わからん。ま、足して100円未満だかどうでもいいか。では、読み書き5,000,000回ずつにしてみよう。$28と出た。これは先月の料金に近い。とりあえずこれで。

いずれにしても、容量よりもアクセス量で料金が支配されてる感じだ。なら、でかい容量をとっても時々バックアップするくらいなら問題ないか。では1TBでどうさ。おや、$48と来たな。うーむ、これは結構きつい。100GB/月で$2ということらしい。うちのサーバのアクティブなファイルとログを含めておそのくらいでおさまるだろうから、それが適当かな。とりあえず30GBに戻そう。

あとはバンド幅だ。デフォの見積もりが5GBで$0って、アタマがおかしいのか?デフォのVMと比べてバランスが悪すぎる。まあ、サーバとしての運用を想定してるわけじゃないのかな。100GBにしてみよう。ほほー、$826と出た。これは先月の料金にかなり近い。にしても、いま契約してる安かろうサーバは通信3TB込みでまるっと1000円なんだが…まあ、スループットが違うのかな。これじゃあ、遠隔でscpとかした分で料金が変動するわな。でも、scpでせいぜい20Mbps程度しか出てないから、速いっても2倍ってとこだと思うけど。てか、うちのサーバってそれくらいしか通信してないのか。1日3GB、ならすと300Kbpsってとこか。

あと、固定IPアドレスをひとつ持っているから、これはどうなんだろう?おっと、これは5つまで$0なのか。それを超えると、ひとつあたり$2.63とな。こりゃ利用しないと孫じゃないか。まあとりあえず1つで。

ストレージとバンド幅は現状に近くなったけど、VMだけで$85というのは、現状の¥5000と解離がでかい。これはなんだろう?うーむ、コスト分析の表を見ると、うちのはa1というものらしい。a1にしてみよう。おお、$43.80と出た。これでかなり現状に近い。総額で$80.24と出たな。んー、うちのマシンはデフォのUS西部じゃなくて東アジアだから…変えてみると…$83.47。まあ誤差範囲か。

$83.47/月。だいたいこれで、現状のモデルになったんじゃあるまいか。
それにしてもなんだAzureよ、現状の料金がどうやって発生してるのか、同じ料金計算にかけらないのはおかしいじゃないか?

まあいいか。それでは仕分けに入ろう。ざっくり切るぞー!

当該仮想マシン「概要(1日ぶん)」
当該仮想マシン「概要(7日ぶん)

うーむ、見事にスカスカじゃわ。CPUは5%も食ってない。もちろん、ネットやディスクで律速されてるわけじゃない。てことで、まずはVMのリストラだ。

最安VMは、A0というものらしい。これはいくらだ?…おおっと、$14.60とでたぞ。これなら、現状のA1の1/3の費用じゃないか。スペックはどうか?
A0: 0.75GB RAM, 20GB一時ストレージ, $0.02/時間
A1: 1.75GB RAM, 70GB一時ストレージ, $0.06/時間

このA0でも、軽いサーバを動かすLinuxとしちゃ、十分なスペックだろう。750MB RAM … 昔なんてVMのLinuxとかBSDを、128MB RAM程度で動かしてたような気がする。 VMwareだって、デスクトップUbuntuをインストールするのに2GBを推奨してくる。サーバマシンなら750MBでまったく問題ないはずだ。

テンポラリが20GBってのがちょっと気になるけど、そもそも総量30GBでこれまで来たんだから、問題ないだろう。

てことで、VMはA0に決定かな。$14.65

ストレージは30GBでは苦しいのはわかってるから、100GBにはしたい。30GBで$28.22のところ、100GBにすると、$29.90。まずは良し。足りなくなったら後でドライブを足そう。そもそもドライブを複数に分けるのは管理上望ましいことだ。

バンド幅は、実績から100GB/月。$11.40と見積もろう。

しめて$55.95となった。現状の$83.47から30%カットだ。コストカット後、ストレージ分の料金$29.90が過半になったのは気になるが、これは削るのが難しい。

ストレージ料金の中で支配的なのは、書き込み操作ぶんの$25.00だ。書き込みの単価が$0.05に対して読み出しの単価が$0.004で10倍以上違うから、これは…書き込むログの量(詳細度)を落とせば減らせば効果がありそうな気はする。うまく運用すれば半減できるかもしれない。いずれにしても、このサーバをバックアップ用にして書き込むをするのは、やってはいけないことだろう。

さて、それで次は「割引のオプション」だ。従量料金、1年間予約、3年予約、とある。年間予約は、従量料金ではないような名前だが、そんなことはあるまい。ただ、年間予約だと料金をVMでは72%とか、ストレージでは38%だか節約できるというフレーズが目に付く。バンド幅には割引はないようだ。これは、Azureの中で閉じてない料金だからだろうか?

では、3年予約にしてみよう。$1,665.53と出た(笑)。

意味がわからない。見ると、VMもストレージも、勝手にハイスペックに変えられている。それでも、VMはB1S=1GB RAM, 4GBストレージ, $0.0062/時間にアップグレードされた一方、$4.56/月と、57%の値引きになっている。問題は、ストレージが最小100TB($1,622/月)になることらしい。もちろん、あり得ない。

ということで、VMだけ3年予約にすると、$45.91/月となる。ここで気付いたのだが、画面の右下の隅っこに金額の単位として$以外が選べるのだった。日本円にして、¥5,141/月である。

現状の$83.47/月から45%カットであり、半減というノルマには近い。しかし、目標の¥3,000/月には、到底届かない。

他社の安かろうサーバの5倍の価格である。しかし、5倍の価値があるとは思えない。各種サブスクリプションはそれぞれ1000円/月程度だし。これなら、自宅でサーバを運営したほうが、コスト・費用・リスクがバランスするだろう。

ともかくストレージが高すぎる。他の要素とのバランスとしては、わからなくもない設定ではあるが。

他をあたって見よう… orz...

いや、ちょっと待て。わが社が欲しいものの中で優先度が高いのは固定IPアドレスだが、これは¥1,000/月はする。Azureは5つまでタダのようだ。単なるIPリダイレクションかフォワードサーバとして使うのはどうか?問題は「ストレージ無し」のVM、というのが意味をなすのかだ。リブートする度にインストールが必要なVMのサービスなんて有り得るだろうか?現状のストレージ代約¥3000/月というのは、あのなんとなく購入してからほとんど使っていない70GBの/mntにかかっていたりしないだろうか?だとすれば、明示的なストレージ契約無しで可能かも知れない。

なんにしても5月11日というデッドラインは近い。次の課金期に入ってしまう。継続するにしても、最低限、VMはA0にダウングレードするという作業はしなければならないだろう。

疲れたから一杯しよう。


クラウド仮想マシン・試作評価

基盤部 佐藤メモ

さて、そもそものAzureの仮想マシンの課金体系というのを見直そう。Azureが公表している「Liunx Virtual Machineの料金」というページがある。
https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/linux/

これによると課金方式は3種類。従量課金、定期予約(1年または3年(Azure Reserved VM Instances とか、日本語訳だけが仕事のMS Japanは仕事してるのか?))、それとスポットだな。スポットてのは、混んでたら遠慮してもらいます悪しからずサービスらしいからサーバ用としてはあり得ない。定期予約は「最大72%割引」とうたってるけど、どうやら最低で年1万円くらいらしい。無料使用12ヶ月とかいうのもあるようだけど、Microsoftの言うことだから眉唾だろう。タダほど高いものは無い。結局、従量課金だな。

従量課金は、めちゃ貧民向けの600円/月くらいのもあるけど、それを除けば最低限で1GB RAM+1TBディスクだと1000円/月くらいのようだ。途中でさようならしたくなった場合のために、従量課金で行くのが良いのではなかろうか?

てか、従量料金8,000円/月以上払ってる社長、やっぱおかしくね?

生命保険屋のメニューとか、携帯電話の料金体系とか、Azureのこれとか、アタマをおかしくして思考停止させる戦法には辟易する。で結局、面倒臭いからとりあえず作っちゃって考えよう。そもそも料金とサービス品質のトレードオフだからな。動かしてみないとわからないこともある。どうせ1000円くらい、失敗して自分がカブったってなんてことは無いし。

でもってサクサクっと設定。あいかわらず作るのだけはカンタンそうだなAzure。うまくいけばこのまま運用に入りたいので、あんまりケチるのもなんだし、1GB RAM, 1TB SSD にしとこう。¥1.6352/時間だから、¥1,190/月のはず。MSのひっかけがなければ。

仮想マシンの構成

まあこんなもんだろうよしよし。では、作成をポチッと。(待つことしばし)。おー、できたか。どれどれ、sshでログイン。問題なし。あれ、1TBあるはずなんだが…30GBしかないぞ…そういや特別にmountしないといけなかったような記憶がある。どうやらデフォは30GBというのはお変わり無いようだ。こいつが、ストレージ無しでついてくるやつなんだろうか?あとで別のマシンを作って試してみよう。sudo reboot ... 再度 ssh ... おお、ちゃんと生き残ってるな。あたりまえか。

開発環境はどうか。何?makeがないと。sudo apt install make。よしよし。お、ccも無いか。sudo apt install g++。あれ?エラーが出てインストールできねぇ。なんじゃこれは?Not Found?まあ、とりあえずUbuntuの64ビットでバイナリは共通だろうから良しとしよう。

64ビットLinux用のDeleGateのバイナリをscpで送り込んでと。 delegaed -P8080 -fv 、telnet localhost 8080 で繋いでみる。問題なし。では外から繋ぐとどうか… あ、ポートを開けないといかんな。どうするんだっけ?なんか Cloud serviceとかを入れるはず。これか。んんー。使い方側わからん。昔と違う。リソースグループってなんだっけ?ごちゃごちゃいじっているうちに…なんか壊れた。

(ここで苦闘することしばし)。これはもうだめかもね。なんかAzureでエラーがでるし。ゼロから作り直そう。そのほうが早い。(第2版を作って前のは捨てる)。この手軽さが仮想マシンのいいとこだよなー。できたできた。んー、やっぱり、Cloud services の使い方がわからん… そもそも昔作ったCloud serviceってやつは…おや?ポートの設定画面にならないのだが...

おや?新規仮想マシンの設定に「ネットワーク」とかいうのがある。なんかポートの接続を定義するもののようだ。SSHも定義されている… なんだ、ここで定義すればいいのかあ。つまり、新しい仮想マシンは、Cloud service とかいらなくなたのか。でもって 8080 を通してと、外からブラウザで繋ぐと、おお、つながったぞ。パチパチパチ。それでは、現行 delegate.org のサーバデータを送り込んでみよう。うーん、これはしばらく時間がかかるな。CPUもかなりいってる。

この時間パブリックIPでも追加してみよう。ぽちっ。お、できた。あれ?アドレスが割り当てられてない。どういうこと?まあいいか、とりあえず困らない。

面白すぎて疲れた。寝よう。
2020-0428


Ubuntu 18.0.4 仮想マシンで DeleGate を動かした


Mac Mission Incomplete

と、そういうわけで、Mac の Mission Control 機能を使うことで、Mac と Windows と、ついでに Linux を、サクサクっと切り替えられるようになりました。こんな感じ↓

Mission Control を呼び出したデスクトップスクリーン

上の画像のスクリーン(これはMacのデスクトップ画面です)の上部にある帯の部分(以下、リボンと呼びます)が Mission Control の制御画面です。拡大するとこんなふう↓

Mission Control のリボン(デスクトップサムネール一覧)

各デスクトップのアイコン(ライブなサムネール)のキャプションにあるように、左が実Macのデスクトップ、中央がVNC経由でのWindowsのリモートデスクトップ、右がVMwareの上に乗せたLinux仮想マシンのデスクトップです。

フルスクリーン状態にしたVNCやVMの画面を通常ウィンドウ状態に戻すのにも、このリボンの中で、サムネールの左上隅をクリックすればOKです(下記のようにドラッグ・アウトしてもOK)。もう「仮想デスクトップ全画面モードから抜けるホットキーを忘れた…」というような窮地はなくなります。ゲストマシン側に何かをインストールする必要もありません。

フルスクリーン状態のON/OFF

仮想デスクトップは普通フルスクリーンで使いますから、そのために、仮想デスクトップのウィンドウ状態⇔仮想デスクトップのフルスクリーン状態、という切り替えをします。これをMisson Controlでやるのは単純です。

[A] ウィンドウをフルスクリーン化するには
 ①Mission Controlのリボンを開く
 ②ウィンドウをリボンにドラッグ・イン

[B] フルスクリーンからウィンドウに戻すには
 ①Mission Controlのリボンを開く
 ②スクリーンのサムネールをリボンからドラッグ・アウト

あきれてしまうほどカンタンですね。やはりMacOS X最高!です。

上記 [A] についてのちょっとした注意事項は、ドラッグ・インしてしばらく、追加が可能な状態になる(+印が出てくる)までに、時間がかかる(0.5~1秒程度、たぶん時間設定は可能)ということです。誤操作防止のためのディレイなんでしょうけど、イラチの誤操作を誘発しそうですね(笑)

Mission Control を開くにはデフォルトで Shift+上矢印ですが、ホットコーナーにマウスカーソルを移動するなどの方法もあります。

なお、上記はVNC(アプリ)とVM(アプリ)のウィンドウを例に書きましたが、操作手順は通常のアプリのウィンドウでも同様です。ですのでこれは一般的にアプリの「ウィンドウを最大化」して使い、「最大化した複数のウィンドウ間を渡り歩く」方法の、とてもスマートな置き換えなのだと思います。これは、十年前のMacにはありませんでした(←事実誤認[3])。大きな進歩です。

フルスクリーン化するとDockが非表示状態になりますが(それが自然ですが)、マウスポインタをスクリーン最下部に置けば、ひょっこりDockが出てきます。ただし、通常のアプリではスクリーン最上部にマウスポインタを置くと、隠れていたMacの天井帯(なんて呼ぶんでしょう?ドロップダウンするやつ)がぬっと現れますが、VNCアプリやVMアプリではそうなりません。

てことは、通常のアプリは最果てのマウスポインタ位置情報(イベント?)をスルーする、VNCやVMはそれも捕まえる、ということでしょうか。VMゲストOSがプアだと天井帯は出るので、ゲストOSが掴んでいるということかと思います。VNCは「コントロールキーのフォワードをしない」なんていうドラスティックなオプションでなく、「スクリーンの天井状態を知らせない」とすれば弊害も少なく汎用生は高いんじゃないかと思うんですが。

あのMac天井帯は、あれがないとアプリを外界と交渉させられないですから、普通の(フルスクリーン制御を必要としない)アプリでは必須ですね。ですがあの、Macの画面が10数インチだった時代の、今の一つのウィンドウより小さかった時代のコンセプトを未だに引きずっているという大間違いから脱却できないのは、Macの最大の弱みですね。マジ不愉快というか、肉体的に苦痛。先代の遺訓でもあるのかしら?

Macには、実にスマートでない部分が、あの天井帯、Dock、Finderにあります(一方、システム環境設定での集中管理は悪くないし、個別アプリからもインフェースを踏襲してるのは良いと思いますが)。最近のデフォルトの壁紙とか、MacMiniのデザインとか、「macOS」とか言う表記も嫌いです。そんなネーミングにはOSXより前のゲロ吐きOS(OS?)に似た匂いを感じます。退化です。センスの悪い(というか私が好きになったMacOSXとセンスの違う)リーダーが中枢に居るのかもしれません。そういう劣化は、旧称「Office 365」にも「Azure」にも「Google Sites」にも見られました。

Dockがアプリによらず常にアクセス可能、というならば、Mission Control は独自のリボンを持つのではなく、Dockに入れるという手もあったのではないかと思います。たとえばDockの中に仮想デスクトップコーナーがあり、その中のデスクトップアイコンをクリックすると切り替えられる、というような。通常のウィンドウアイコンのエリアからデスクトップコーナにドラッグするとフルスクリーン・デスクトップに切り替わるとか。まあ、Mission Control はもっと便利なことができるみたいだから、Dockに束縛されるべきじゃなかったとは思いますが。

デスクトップの切り替え方

デスクトップの直接切り替え(Mission Control画面に遷移しないで直接遷移する)を「コントロール+矢印キー」でやるのはあきらめました。リモートのデスクトップ上でコントロールキーを使わなければならない場面が多すぎるからです。ですが、ControlではなくShiftでやれば良いことがわかりました。どちらかと言えば、そっちのほうが好みです。

加えて、片手で頬杖をついてマウスだけで切り替えるという、ありがちな場面を想定し、以下の安直かつ副作用の無い手順を、わが社での標準作法としようかと思います

[C] デスクトップをマウスで切り替えるには
 ①ホットコーナーにマウスポインタを移動する
 ⇒Mission Controlのリボンが開く(ように設定しておく)
 ②リボンの中の所望のデスクトップをクリックする
 ⇒そのデスクトップが開く

Mission Control で、デスクトップ直接切り替えのためのキーを定義する方法に気づくのに少し時間がかかりました。デフォルトである「コントロール+矢印」というホットキーは、(私の場合) WindowsやLinuxで使う事が無いので、これだけをホスト(大家)である Macの Mission Control がピンハネしてくれるように設定できると良いのですが…

ただ、今回の作業で、Windowsでの日本語/英語入力の切り替えに、(私の大嫌いな)専用キーを使わないで済ます方法を薄々理解したので、その点は収穫でした。でも、Windowsで日本語入力を必要とすることは、今後無いか、激減するでしょうけど。

なお、ここに書いたことについて、「Linuxなら簡単にできる」とか「Windowsでもほにゃららすればできる」というような話には、あまり興味がありません。なにか手や労力を加えて良いなら、それはWIndowsとかが生まれるはるか前、30年前のX Windowの各種「ウィンドウマネジャ」の時代に既に出来ていたことです。私は工場出荷時のスッピン状態で出来ない事は評価できません。そもそも結論として、私にとっては「Macが最高」でなければならないからです(笑)

2020-0425 sato@izmoh


参考
[1] 画面の切り替え :https://support.apple.com/ja-jp/guide/mac-help/mh14112/mac
[
2] 画面のキャプチャ:https://support.apple.com/en-us/HT201361


まずWikipediaを見よ

Wikiを見たら「バーチャルデスクトップ」について、X Window, Windows, MacOS の歴史がちゃんと書いてありました↓

[3] Virtual desktop:https://en.wikipedia.org/wiki/Virtual_desktop
[4] 仮想デスクトップ: https://ja.wikipedia.org/wiki/%E4%BB%AE%E6%83%B3%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97#Windows

英語版(Mac OS Xの節)には以下のようにあります。

Beginning with Mac OS X 10.5 Leopard in late 2007, Mac OS X has shipped with native virtual desktop support, called Spaces, which allows up to 16 virtual desktops. It allows the user to associate applications with a particular "Space". As of Mac OS X 10.7 Lion, this functionality has been moved into Mission Control.

ああ、確かにそうでした。Leopard のそれそれ、自分も使ってましたよ。「Mission Control 」は Lion 以降とありますが、Lion の発売は 2011年7月だったそうです。

それはちょうど自分がMacから離れた時期です。あれ、でもこの画面を目の前で見た記憶があるし、Lionという名前も覚えてるんだけど… たぶん、その後最後に購入した MacBook Airがこれだったのかも…

日本語版(macOSの節)には「デスクトップでの作業効率を挙げるためのOS標準のソフトウェアとしては、Mac OS X v10.3から採用されたExposéがあった」とあります。

確かに、エクスポーゼも使ってました。ただ、当時はVMware(とFusion)のVMのデスクトップや、RealVNCの画面をそのまま、Mac上でフルスクリーンで使ってた記憶は無いですね。出来なかったのか、自分では必要性を感じなかったのか…

なんにしてもイマドキ「Mission Control がー!」って言ってる自分は、世の中に8年ばかり遅れているということでした。うーん、その割には、カスタマイズ機能がいまひとつこなれていないというか、Mac流に絞り込んでいるのか、他の機種に対する思いやりが無いのか… まあ、コントロール+矢印問題の件は、Mac よりも RealVNC のほうにより非があるとは思いますが。


調達請求(VNC)

[物品調達請求-仕様書]
件名: MacとWindowsのカンタン両刀使いに用いるソフトウェア一式
請求日: 2020-04-25 
請求者: 開発部 佐藤

1.概要

業務効率改善・生産性向上のために、従事者が快適に作業を行えるコンピュータ利用環境を整備する。快適性は個々の従事者の「好み」と「慣れ親しみ」に大きく依存する。精神衛生および人間工学に鑑み、従事者の希望を最大限尊重すべきである。本調達物品の使用者は強くMacを希望している。ただし顧客対応の面で Windows の使用が避けられない状況もある。そのため、利用者のフロントエンド側はMac として快適性を確保する一方、バックエンドにWindowsを稼働させ臨機迅速な使用を可能とする環境を構築する。必要となるハードウェア機材は既存のものを利用し、最小限のソフトウェアを追加することで所期の環境を実現する事とする。使用者の要望と事前調査に基づき仕様を以下の通りとする。

2.要望
  • 使っているMac と Windows (以下Win)をサクサク切り替えながら両方使いたい
3.前提
  • 既にMacとWinのマシンを持っている
  • 両者は高速なネットワークで通信できる
  • Mac側をフロントエンドとする(快適性の実現)
  • Win側の使用感には完璧を求めない
  • 妥当な必要費用は支出できるものとする(有償ソフト検討)
4.背景
  • Macが好き(Winは極力使いたくない)
  • Winでしか動かないソフトを使う必要もある
  • Winにしか接続できないハードを使う可能性がある
  • 開発するソフトがWinでも動くことを確認する必要がある
  • 実機として保有しているWinを遊ばせて置きたく無い
5.要件
  • ホットキーでサクッとMac と Win を切り替えられること
  • ソフトウェアだけで実現できること(KVMスイッチは使わない)
  • 十分なセキュリティが確保されていること
  • 費用は1万円以内としたい
6.解法
  • WinでVNCサーバを、MacでVNCクライアントを動かす
  • Macの仮想デスクトップとしてWin(VNCサーバ)のデスクトップを表示する
  • Macのホットキーで Mac と Win の仮想デスクトップを切り替える [補足資料]
7.品名
  • VNCサーバ: RealVNC社製「VNC Connect」
  • VNCクライアント: RealVNC社製「VNC Viewer」
    *選定理由: 以前長く無償で使っていて快適だったから。感謝も込めて
8.費用
  • VNCサーバ: $4.59 / 月(1サーバあたり)[1]
    LAN上で直結して使用するため、これを許容する「Enterprise Edition」とする
  • VNCクライアント: $0 [5]
9.納期
  • 決済後1時間以内
10.納品
  • 使用者はRealVNC社サイトから上記7のソフトウェアをダウンロードする[2]
  • 使用者は同製品の無償試用期間(30日間 [3])の間に利用上の問題が無いことを確認する
  • 管理者はRealVNC社サイトでサブスクリプション契約を結びライセンスキーを得る[4]
  • 使用者はライセンスキーをプログラムに設定し、本格使用を開始する
11.特記事項(追記)
  • 短期的な解決の望めない不具合が発見された場合、また、より優れた他製品が見出された場合の移行を考慮し、月払いでのサブスクリプションとする。

以上


[補足資料](使用者作成)

本件請求に先立ち、RealVNC社サイトより当該ソフトウェアをダウンロードして試用し、実現性を検討しました結果、以下のように技術面の問題無し、と判断しました。

  • 導入:まず、インストールやユーザ登録は特に問題なく行えました。以前に使用していたこともあり、サーバとクライアント間の接続もカンタンでした。
  • 機能:次に、Macのマルチデスクトップ機能「Mission Control [6]」を使って、別の仮想デスクトップエリアにWinのデスクトップを表示することができました。ただ、そこまではスムーズに運んだのですが、ここで以下の1.に詳述する問題に遭遇しました。しかし、使い易さを損ねないで回避する方法も見つかったため、これに関しても問題ありません。
  • 性能:Mac / Win 両機が1Gbpsで直結している事もあり、使用していて違和感はありません。ウィンドウのドラッグ時にわずかにカクカク感がありますが(これは10年前も同じ環境で同じ様子でしたが)、プログラムや文書の作成用の仕事環境としては十分です。小画面であれば動画再生も滑らかで、Skypeテレビ会議程度には使える品質です。ネットワーク負荷としては、タスクマネージャによる簡易測定ではおおむね100Mbps以下で、ギガビットLANにとって問題ありません。同様にCPU負荷についても、4GHz動作において最大時20%程度であり、問題ありません。

なお、当該ソフトウェアの導入により以下の2. に挙げるようなメリット・発展性が、直接・間接的に生まれる事も考えられ、本調達は極めて有意義であり、コスト効果が高いと考えます。

*** 詳細 ***

1. 問題点と回避策

1)デスクトップの切り替え

[問題]
Mission Controlでは複数の仮想デスクトップを切り替えるホットキー(ショートカット)として「コントロール(^)+矢印キー」を使う。例えば「^→」で右にあるデスクトップに移動する、とか。ところがそうしてWinの(VNC経由のリモートの)デスクトップに切り替えると、コントロールキーもVNCを通じてWinに転送されてしまうため、Mission Control向けの「Control+矢印キー」が効かなくなり、Macの(ローカルの)デスクトップに戻れなくなってしまう。

[回避策]
ショートカット(ホットキー)を変更すれば良い。Mission Controlの呼び出しキーはデフォルトで「^↑」だが、これは「システム環境設定」により、コントロールキーを使わないように定義できる。たとえば「 Shift+矢印」にする。実のところ、コントロールよりShiftのほうが押し易く望ましい。設定は、実にMacらしいWISIWYGというか例示で行う[7]。
 また、Macでは画面の四隅(ホットコーナー)にポインターを置いた場合のアクションとして、Mission Controlを呼び出すようにもできる[8]。

2.導入のメリット

本製品の導入には同時に、今後においても、以下のメリットがあると考えられる。

  • バックエンド(リモート)のマシンを自由に増やせる(ただしサーバ費用は増える)
  • Linux にも使える(ただしLinuxが仮想マシンの場合には必要性は薄い)
  • テレビ会議にも有効利用できる可能性がある
  • モバイル端末でも使用でき、出先等からも利用できる
  • ウェブサーバ代わりに使用できる可能性がある(パラパラ漫画放送、ファイル配信、等)
  • Windows側も仮想デスクトップとして、個別ユーザ専用の画面を提供できる可能性
  • リモートに参加型の実機デモができる

[1] 価格:https://www.realvnc.com/en/connect/pricing/
[2] ダウンロード:https://www.realvnc.com/en/connect/download/vnc/
[3] 試用期間:https://www.realvnc.com/en/connect/trial/
[4] ライセンスキー:https://help.realvnc.com/hc/en-us/articles/360002249677-Licensing-VNC-Connect-
[5] VNC Viewer: https://www.realvnc.com/en/connect/download/viewer (is always free)
[
6] Macの仮想デスクトップ切り替え: https://support.apple.com/ja-jp/guide/mac-help/mh14112/mac
[7] Mission Control ショートカットキーの切り替え:システム環境設定 > 左ペインでMission Controlを選択 > 右ペインで変更したいショートカットの行を選択 > 行の右半分に表示されている現在のショートカットキー部分をクリックすると入力窓が開く > 新しいショートカットキーを実際に押す。
[8] ホットコーナーへの機能割り当て:各アプリの設定の中にある。この場合、システム環境設定 > Mission Control の中にホットコーナー設定の入り口がある。ここに一部のショートカットキーの設定があるため、[7] に気づかず往生した。



開発部 佐藤さま

いつもお世話になっております、経理の佐藤です。
先に提出されました調達申請につきまして、3点不明なところがありますので、補足をお願いします。
(1)費用の妥当性
仕様書の4項に「妥当な費用」とありますが、8項に示されている毎月$4.59が妥当であると判断される理由をお聞かせください。
(2)VNC選定理由
仕様書の7項にて特定の社の製品を指定されていますが、同様な機能(VNC)について他社製品と比較された結果をお聞かせください(書かれている理由が客観性に欠けます)
(3)KVMの排除
KVMスイッチと思しき機材をお持ちとお見受けしますが、それを利用しない理由をお聞かせください。

よろしくお願い申し上げます。
経理部 佐藤


経理部 佐藤さま

いつもお世話になります、佐藤です。
いただいたご質問にお答えします。
(1)費用の妥当性
費用はおおよそ月500円ですが、これは中ジョッキ一杯弱分に過ぎません。また、1日あたり20円弱ですが、これはうまい棒約2本分です。日常生活において大人から子供まで気軽に消費している金額であり、当社の基幹・開発業務のためにさく額として全く妥当あると判断しました。なお、例のSPAMドメイン押し売り会社レンタルサーバのクソソフト(ウェブ編集ツール)の月間使用料900円につきましては、先日解約手続きのお手数をおかけし、申し訳ありませんでした。
(2)選定理由
仕様書の第1項にも書かれていますが、この選定は第一に精神衛生上の理由に基づきます。精神衛生は創造性・生産性を支配しますが、それは好き嫌いに左右されます。好き嫌いにはかなずしも客観的理由は伴いません。Unixを産んだAT&Tのベル研究所へのリスペクト、MIMEのベルコア、RealVNCの源流もまたAT&Tの研究所、論理的ではありませんが、好きな理由はおそらくそのあたりにあります。第二に、使用者は過去にこのソフトウェアの旧版を長期にわたって利用しており、使い方に習熟しています。そして機能も性能も必要に十分としています。もし他社において何らかの面でより優れた製品があっても、おそらくそれは当社にとっては不要であり、それに習熟するために時間的コストを割くのは無駄です。以上をもって選定の理由とさせてください。
(3)KVMの排除
手元にあるスイッチはHDMI用ですが、実は手元のWin機(Lenovo)にはHDMIがなく、Display Portです。ですので、物理的に不可です。モニタ側はHDMIとDisplay Portを持っていますが、切り替えに数秒かかり、使用に絶えません。また、マシンとモニタを近くに置けない場合もありますが、その場合有線のKVMでは対応できません。無線のKVMはお高いので、当社の方針に合わないと思います。今回調達するソフトウェアは、安価なソフトウェアによる無線KVMであるとも言えます。

よろしくお願いいたします。
佐藤


経理部 佐藤さま

お疲れ様です、社長室の佐藤です。
本調達案件につきまして、社長の決済が降りましたので、進めてください。
よろしくお願いいたします。

社長室 佐藤


Mission Control で Control key を使わない(かといってファンクションキーも嫌)方法につまづいていましたが、システム環境設定の中のキーボード設定のほうに、Mission Control のショートカットを変更する機能がありました。デフォルトの Control+矢印を、Shift+矢印に変更して、今は幸せです。

各位

開発部、佐藤です。
先に提出しました RealVNC Viewer 調達申請の件ですが、一旦保留とさせてください。対象とする当社Lenovo機はWindows 10 Pro搭載であり、Windows の Remote Desktop サーバ機能を持つため、これにMacから接続して評価しました。そうしましたところ、使用感的にはRealVNCと同等以上、ネットワーク負荷的には数分の1であることがわかりました。Mac版のRemote Desktopクライアント(Microsoft Remote Desktop 10)は無償で提供されている点も有利です。もうしばらく使用してみて問題が無いようなら、こちらを使うこととし、RealVNCの調達は取り下げたいと思います。

よろしくお願いいたします。
佐藤
2020-0427


付記
試用・比較の結果、Remote Desktop が当面の使用目的に対してに機能・性能的に十分であることが確認されたため、本件(RealVNC調達)は取り下げられた。

法人口座

法人口座の開設完了通知が2つの銀行から届いた。これでようやく、会社設立の指南書にあるすべてのタスクが完了。

法人口座。なんかカッコいい! というか、無いとカッコがつかない。この開設手続きが今回の一連のタスクの唯一で最大のヤマだと思っていた。実際、資本金を1円にしなかったのも、このウェブサイトを作ったのも、法人口座を得るために最低限のカタチは整える必要があるという指南に従ったからだ。

定款の認証や法人登記も一応審査的なものだが、要は記載事項に誤りが無いこと。あとは反社で無いことを確認されるだけだ。私は非社会的な面があるが反社会的では無い。公証人さんの認証証明書には「審査の結果」とあるが、認証文は「…は、設立される法人の実質的支配者となるべきものが何の某である旨及び同人が暴力団員等でない旨を申告した。…。よって、この定款を認証する。」というだけのもので、実際のところ口頭で申告したわけでもなく、尋問のようなものをしてくれるわけではなかった。単に暖かくおもてなしされた感じだった。認証料5万円也。

一方、銀行での法人口座は審査の結果断られることがあると聞いていた。それで、法人口座開設の審査のために求められる書類には、事業内容の説明を(とても真剣に)数行で書いたが、これは会社名を考えるのに次いで、脳みそを使った作業だった。しかし、そこに嘘八百はったりを書いたとしても「審査」で峻別できるものだろうか?とても不思議。まあおおおらか銀行だからこそのユルさなのだろう。

うちは信用力を必要とするような会社ではないので、どんな銀行でも構わないのだが、ここつくば、茨城といえば個人的に長く口座を持ってきた常陽銀行が心のふるさとだ。地域に根差した活動をする予定はないけど、あそこに法人口座を作れれば何だかうれしい。

お役所は選べないが、銀行は選べる。2つの銀行に同時に申し込んで比べられたのは面白かった。法人口座の場合、申し込み時の記入事項や提出物が結構ある。しかもケースにより要・不要がわかれる。一方の銀行の申し込み書類はやや混乱しており、他方はとてもわかりやすく洗練されていた。洗練銀行のほうは、イマドキ当たり前だがメールにもちゃんと電子署名がされていて、メールのあて名も「当社の正式名称+さま」とあり好感を持った。他方の銀行は電子署名もされておらず、あて名は「カ)フリガナ様」と来た。まあある種、より実務的なのかも知れない。それぞれ個性があって面白い。

なんにしても当面、お金が出ていく口座でしかないけど。

2020-0424 sato@izmoh

data schemeは健在だった

Macに触れたのがきっかけで、つい昔の事を思い出してしまう。URLと言う表現形式の成長期に提案された dataと言うスキームもそのひとつ。

URLは http や ftp と言ったプロトコル名(つまりアクセス手段)と、//ホスト名/パス名、という「リソースのロケーション」つまりアクセス先のアドレスを表す表記法・手段(scheme)だ。その中のひとつとして、リソースのデータ自体をURLに表記する方法として提案されたのが「data」だった。似ていて対極にあるものに、抽象的にメールアドレスを表記する mailto (転送手段も規定していない)があり、現在広く使われている。

CPUの命令アドレスフィールドに即値(immediate value)を持たせられるのは当たり前だし、変数と定数とかポインタなど、その他の類想からも、コンピュータ分野で育てば当然考えられるべき事なのだが、当時はなるほど(膝をポン)と思った記憶がある。
一般的にも「名は体を表す」と言うが、体自体を名前にしてしまうジョークや商品名は昔からある。data scheme はまさにそれに相当する。

以下に具体例を示す。上がデータ(gifイメージ)のナマ表現で、下がそれをブラウザが解釈して表現した結果だ(画像は、data scheme 提案者のLarry Mainster 氏のポートレート)。

<IMG SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH hhx4dbgYKAAA7" ALT="Larry">

Larry

ここにはきっちりと、当時確立していたMIMEのデータ型名と、base64エンコーディングが、やはりWWWの初期に確立していたHTMLのタグIMG SRCの中に表現されている。だから、それら極めて基本的な標準仕様に準拠し、gifを表示できるブラウザなら、必ず表示できる表記だった(はずだったが、多くのブラウザの実装ではそうではなかった…)。

data scheme には実際、特に当時の未成熟なブラウザの状況もあり、色々な応用が期待された。data:表現が提案されたのは1997ねんで、翌1998年に正式にRFC2397となった。私はこれを使って、ブラウザによってサポートされていない文字や画像を埋め込む事を考えた。当時書いたデモ用のページが今も残っている(というか、動態保存している 笑)
URL: http://www.delegate.org/delegate/sample/data-url.shtml ↓

data scheme を代理で変換する試み(1997年)

これは、ブラウザローカルに解釈できる事がメリットのはずの data:表現を実装していないブラウザのために、リモートの http:サーバでそれを補ってやろうという、分かってはいたが本末転倒の試みであった(実際、ウケなかった)。そして、data がきちんと実装されるより前に、ブラウザの多言語対応や各種イメージ型の表示能力が成熟し、当時私が考えた応用の目的は失われた。

その後の2014年の追記にあるように、やがてほとんどのブラウザがこれを実装した。ただ、私の偏見から来る記憶違いかもしれないが、MSのIEの対応は遅かったように思う。

以下は2020年4月現在の、5大メジャーブラウザでの data scheme の表示。いずれもちゃんと表示できている。

各ブラウザでのdata:表現の実装状況(2014年)

右下は昨今流行りのQRコードでこの data を表現したもの。残念ながら、iPhoneのカメラアプリは、これを認識してくれなかった(笑)

ここまで長く、これを書いたのは、data scheme という歴史に埋もれ忘れ去られた表記を、今も全ての主要ブラウザが解釈できるという事実に基づく、新しい応用があると考えているからだ。応用するのは、良い人かも知れないし、悪い人かも知れないが…

たとえば、文字にしてもUnicodeでは足りないケースも多いはずだ。そういうニッチは今後も完全に無くなる事は無い。ニッチをグローバルなインフラからサポートするのはコストに合わない。

インターネットは100倍早くなったかも知れないが、一方でユーザは100倍短気になった。それに、いくらネットワークの片道スループットが上がったとしても、往復レスポンスは光の速さを超えられない。途中の停車駅だってそうは減らせないだろう。実際、ギガビット・インターネットのRTTは当時の10倍程も高速化していない、今もミリ秒の単位のようだ。

ウェブには1ページを表示するのに数十回のHTTPリクエストが発生するのはざらにある。細々としたイメージデータを多数取得するためである場合が多い。それらは、転送時にdata:にして埋め込んでやれば、一発転送で終わる。(いや、それをDeleGateにやらしてもらう必要は無いけど 笑)。同じデータを繰り返し送るとい無駄は発生するが、データの素性を知っていれば自動的・機械的なトレードオフはできる。長期的に保管するにしても、埋め込み型が有用なケースも多いだろう。

data scheme を IMG SRC 以外でも使えたとしたら、何が(何か)起こるか。応用は、全てをひとつのHTMLファイルに押し込む手段としてだけでは無い。MIME multipart 型と同様、古びた骨董の中に新しい可能性が埋もれている可能性はある。普通に普及しているアーカイブ形式をファイルシステムとして解釈する手法との優劣かなと思う。形式的には格好良くは無い。XMLが、ASN.1 があると言う人もいるかも知れない。しかし実現上の強みは、すでに data scheme は(長い時間をかけて)実装普及が完了していて準備OKであり、シームレスな移行かトランスペアレントな高速化が可能な事だ。

…と、つい昔のエキサイティングな時代を思い出してエキサイトしてしまった…

インターネットに破れて死んだOSIが電子証明書の中に残して行った形見のような X.509 を思いつつ。

2020-0423 sato@izmoh


2020-0423 追記
Wikipedia に比較的最近(2018年)に更新された data scheme のページがあった。さすが、素晴らしい(個人的にWikipediaには献金しているが、会社で寄付したら控除してくれないかな 笑)。それによると、インラインイメージの埋め込みによって転送効率を上げられる、一方キャッシュの有効性は落ちる、と言う認識は元々共通のもののようだ。また元のRFCから指摘されているように、各種セキュリティ上の問題ははらんでいる。MSでの対応に関しては「IEとEdgeでは未実装の部分がある」ともあるので、私の偏見ではなかったようだ。

data:表現の用途としてはインラインイメージ(IMG SRC)以外にも、各種スクリプトのデータのソースとして利用する例が挙げられている。メールに画像を表示する利用例が挙げられているが、現状、サムネールなどを送るのに利用されていたりするのだろうか?

このWikiページを斜めに読んだが、次の言及に目が止まった「他にサポートされないであろうと思われる要素に、電子メールクライアントのマルチパート形式やmessage/rfc822などがある」ピクピク!

え?今日、電子メール(MIME)で添付ファイルを送るのには実際、マルチパート形式が使われているし、メール読み書きツールはそれを理解するから成り立っている。なので、これはウェブ用の閲覧ツール(ブラウザ)における状況を指摘しているのだろう。data scheme に関する記事の中での言及なのだから、data:multipart/mixed,--xxx... と言った表現の事を指しているのだろう…

ひとつ前の文から読み直すと「ブラウザなど、多くの処理環境ではメタデータデータ圧縮コンテントネゴシエーションのような複雑な処理はサポートしないであろう。他にサポートされないであろうと思われる要素に、電子メールクライアントのマルチパート形式やmessage/rfc822などがある。」となっていた。

HTTPサーバとクライアントのやりとりが無い環境での使用も想定されるので、ネゴシエーションは無いだろう。と言うかそれは、ブラウザがローカルなHTMLファイルを開く場合でも同じ事だ。編者が言いたいのは、HTTPネゴシエーションでクライアントが受け取りを拒否したデータ型のdata:を、サーバが削除して返すことはないだろう、と言う意味だろうか。

また、URLの長さの制約からして、その他に言及されている機能がdata:表現においてサポートされないのも仕方が無い。ただ、複数のdata:と言うかリソースを連結してひとつのデータとしてみなす、分割パートのような一般的な表現方法が規定されていれば、そうとは限らない。

あるいは連結とは逆に、一つのデータの中の一部を切り出す、たとえばあるデータの中での開始オフセットとサイズとか、HTMLやXMLの中の名前のついたエレメントを参照するとか。これがあれば、何もdata:に詰め込む必要はない。DeleGateのマニュアルはそれを試行したものだ。一つのHTMLファイルの部分部分を、単独のHTMLのようにも表示する事ができる。

つまり、ひとつのファイルに複数の(URLで識別可能な)リソースを詰め込む事による利点は実現出来ている。また、複数に分割してHTMLを書くよりも、一枚で書いて、色なビューで切り分けて眺められる方が便利だった。だが、この方法は、ウェブサーバがDeleGateで無いと、サポートされない X-)

要するに、URLで識別されるデータの論理的な単位と、実際のデータの物理表現が1対1になっている事が根元にあるように思う。それは、ひとつのURLのデータをGETする毎に、ひとつのTCPコネクションを貼っていた、Keep-Aliveが出来る前のHTTPを思い出させる。

そもそも、MIMEフォーマットがHTTPのメッセージ形式として採用された時には、マルチパート型がそのような役割を果たすのでは無いかと期待したが、そうはならなかった。その後この分野をフォローしていなかったので、現在そのような役割を果たす標準形式、何か別のマークアップ言語なりコンテントタイプなりで、そう言う機能が存在するのかも知れない。

さて。それでは、昨今のウェブブラウザは、URLとしてのdata:multipart ではなく、HTTPのメッセージボディとしては、Content-Type: multipart を処理してくれるのだろうか?と一瞬期待して、試してみた(↓)。メール(左上)のソースをGmailのメッセージダウンロードで .eml に吐いて、ドラッグ&ドロップして各ブラウザに食わせた。結果は残念ながら、きちんと表示してくれるブラウザはなかった。無視または外部のブラウザ(メールツール)にまる投げするのが Firefox と Safari、一応マルチパートを解釈するがプレインテキストだけ表示するのがChrome, Opera, Edge だった。↓

ブラウザにマルチパートメールを食わせて見ると…

それにしても、メールツールとウェブブラウザが一体化しなかったのは不可解だ。ウェブブラウザたる Mozilla から派生し、おそらくエンジンを共有しているであろうThunderbird が、なぜウェブブラウザも兼ねないのだろうか?

もし両者が統合した形で発展していたら、当然マルチパート形式をウェブブラウザは理解するだろうし、それによって開けるデータ転送性能向上や新しい応用があったと思う。

ウェブサーバで提供される「ウェブメール」にしても、ブラウザでローカルに見た目が同じものを作ることはできる。逆に、ウェブ上の各種のフォーラムやらこう言ったブログのようなものを、メールツールからメールと見做して、つまりメールと同じ操作で読み書きすることも出来るはずだ。新着メール検出にRSSを使うことも出来るだろう。

そのためにはもちろん、データの識別子とデータ形式の標準化が必要だ。それがないから、有象無象のウェブメールや、ブログ形式が作られていて、わけがわからない。 HTMLにスクリプトやらが加わった表現能力が高過ぎるのだろう。まあ、いろんな創造性が発揮されていると言う見方は出来る。

とは言え、今ではHTTPサーバがバックエンドにMySQLなどのデータベースを備えるのが普通らしい。であれば、データベースの検索の結果出てきたデータを、ウェブとして読むか、メールとして読み書きするか、選べると言うことで良いのかも知れない。

電子メールにはURLでは無いが、MessageーIDと言うユニークIDがある(ユニークだと言う保証は無いが。電子ニュースではそうだった)。メールの引用関係はハイパーテキストを構成している。メールの特長の一つは、確実な日付順に情報を並べて見れることだ。もしそれができなかったら役に立たない。Message-IDの形式を標準化して、日付を内包する形式を定めれば、データベースを検索した結果をメール的なビューに食わせる事が出来るだろう。もちろん、メールヘッダ(MIMEヘッダ)全体をキーにするのでも良い。

プライバシーの問題があるから、ひとりにひとつのデータベースにするか、暗号化してデータベースに格納する必要はあるだろう。ただ、ヘッダの検索だけでなく、本文まで全文検索をするには暗号化はよろしくないとは思う。と言うか、全文検索エンジンはいわゆるデータベースでは違うか。

色々書き散らしたので、的外れな事が多いとは思うが、一言で言えば、現状のウェブとメールの関係、ウェブサーバとメールサーバ、ウェブブラウザとメールツールの関係は、どうも納得できない。あちらでは出来る事が、こちらでは出来ない。不便に感じる、と私は言いたいのだろう。

2020-0423 sato@izmoh