視力の単位ではなくて、Windows標準の拡大鏡

数年前の記事に加筆したものですが、時間的な経緯は変更していませんので、5年くらい足してお読みください。

---

視力の単位は「メガメートル 」っていう話ではなく、Windows 7以降の拡大鏡の話です 。

Windowsには以前から「拡大鏡」という機能があって、視力の弱い人でも使いやすいような工夫が行われています。

ただし、以前の拡大鏡は拡大エリアがウィンドウの一部に固定されていて非常に使いにくい物でした。

Windowsを使っている方は [Windows]キーを押しながらUキーを押してみてください。それが[コンピュータの簡単操作]を起動するショートカットです。

そこに[拡大鏡]があるはずですので起動してください。
マウスカーソルの周辺が、画面上部に拡大されるでしょう。

ですが、古いWindowsの拡大鏡は、マウスカーソルと画面上部を交互に見る必要があります。

一方、Windows 7の拡大鏡は画面全体が拡大され、その一部をディスプレイが切り取っているようなイメージで表示されます。

視線移動がないので使いやすいと思います(従来のモードも用意されています)。

残念ながら、(コア部分はWindows 7と同じはずの)Windows Server 2008 R2には、標準構成では従来モードしか装備されていません。しかし、[デスクトップエクスペリエンス]の機能を追加し、Themesサービスを起動することでWindows Vista以降と同じ拡大鏡が使えます。ウィンドウの角が取れたり、全体がWindows 7っぽくなってしまいますが。

Windows Server 2012以降は、標準構成で新しい拡大鏡が使えます。Windows 7の派手な画面(Aero)と違い、Windows Server 2012やWindows 8はグラデーションや半透明色を使わないフラットな画面になっていますが、基本的な機能はしっかりしています。

Windows 8が登場したとき、マイクロソフトは「こう見えて、GPUの機能をフルに使っている」という説明をしていました。Windows 7のAeroはGPUの機能を使っていることはよく知られていますが、Windows 8やWindows Server 2012は標準構成でGPUの機能を使ってるようです。

新しい拡大鏡はGPUの機能を使うため、デスクトップエクスペリエンスを必要としたのですが、Windows Server 2012では標準でGPU機能を使うため、標準構成で使えるようになったみたいです。

さて、こんな風に使いやすい拡大鏡が登場した背景には2つの理由があると想像しています。

1つは画面操作のデモなどで、拡大鏡の利用者が増えたこと、もう1つは開発者の平均年齢が上がったことです。

私が高校生くらいの時は「プログラマ定年30歳」という説がありました。
後に定年延長が行われたせいか「プログラマ定年35歳」説になりましたがが、実は米国のプログラマの平均年齢は40歳を超えているという話です。

その話を聞いたのが10年ほど前ですから、今ではもう少し上がっているかも知れません。

米国で「プログラマ」というのはSEを含む場合が多いので単純な比較はできませんが、日本でも40歳代のプログラマは結構増えています。

そこで問題になるのが肉体の衰えです。個人差はあるもののだいたい40歳代後半から「老眼」が始まります。
Windowsのプログラマも老眼の人が増えているのではないでしょうか。

だから「拡大鏡」は使いやすくなり、Internet Explorerは簡単に画面拡大ができるようになり、そしてWindowsの文字を大きくしても表示が乱れないようになったのだと思います。

---

さて、私の話です。

昨年秋、健康診断で異常に低い視力が測定されたので眼鏡屋に検眼に行きました。
検眼の結果

近視も乱視も(2年前と比べて)同じくらいですが、えーと、その...、手元が少し見えにくいようでいらっしゃいます...

いいから素直に「老眼」と言ってください。 気にしませんから。

2年前に作った遠近両用メガネだと少し疲れると言ったら、遠近両用初心者向けに手元部分(老眼部分)の領域を少し狭くしてあるからだろうということです(実際には中心を少し下げてカットしているらしい)。

そんなわけで、年末に交換レンズを発注し、年始に新しいレンズと交換してきました。

肝心のかけ心地ですが、新聞を読んだりメモを取ったりするのは楽になりました。
でも大型ディスプレイは見にくいままです。
老眼はレンズの下半分だけなので、原理的にしょうがないようです。
まさかゲーム喫茶のテーブルみたいにするわけにもいきませんから、長時間の画面作業をするときは、近視の度を全体に落としたメガネを使おうと思います。

ところで、所力の単位は、もちろん「メガメートル=目が見(め)えとる」ではなく、円が作る視角の逆数なんだそうです。

「メガメートル」の話を最初に聞いたのは、KBS京都のラジオ番組「サンマルコからボンジョルノ」の投稿ハガキでした。35年くらい前の話です。

詳しくは別の記事に書いていますので、よろしければどうぞ。

Microsoft Azureのエンドポイントアクセスログ

講義中に質問されてそのまま保留してるんですが、さすがにまずいので途中経過を書きます。

【質問】エンドポイントのアクセスログは取れますか?

【背景】エンドポイントとは

Microfoft Azureのエンドポイントは、インターネットからのアクセスポートのことです。

たとえば、Webサーバーを立てた場合はTCP/80でアクセスします(暗号化しない場合)。

Microsoft Azureの仮想マシンは、Azureが持つファイアウォールで守られていますから、そのままでは正常なアクセスもできません。

そこで、エンドポイントとしてTCP/80を指定することで、実際にアクセスができるようになります。

では、WebサーバーでもないのにTCP/80のアクセスが頻繁に発生しているとします。原因はさまざまですが、可能性の1つとして「不正にアクセスできるWebサーバーを探している」ことがあります。

つまり、外部からエンドポイントへのアクセスを調べることで、不正アクセスの可能性を推測できます。

【暫定回答】できません

できません。「できない」という回答をするのは難しいのですが、「できる」という文書は見つかりませんでした。

許可されたアクセスに対しては、アプリケーションや仮想マシン側でログを取ってください。許可されていないアクセスは、仮想マシンまで到達しませんから、ログも取れません。

問題は、エンドポイントでアクセスできなかった場合です。どうも、これはログを取る機能がないようです。

インターネットの不正アクセスは、数が多すぎてログを取ってられないので、機能がないのかもしれません。万一エンドポイントを不正に通過してしまっても、仮想マシン側のログに残るので、それで十分だと判断しているのでしょうか。

明確なことが分かれば、追ってお伝えします。

オリンピックと情報処理

あけましておめでとうございます。そして、何の脈絡もなくオリンピックの話です。

社会基盤の維持にコンピュータは欠かせません。もちろんオリンピックも例外ではありません。

選手や観客を運ぶ交通機関の制御、会場での動線予測と制御、各種セキュリティ、競技判定、競技データの集計、試合結果の公開、あるいはトレーニングサポートなど、適用範囲は多岐に渡ります。

今回は、その中で、過去のオリンピックを振り返り、特に重要な技術を紹介します。

1932年ロサンゼルス大会

初の開催国外へのラジオ中継。日本では現地で行った実況中継を録音し、後日放送されたそうです。これを「実感放送」と呼びます。

1936年ベルリン大会

写真電送が実現し、国際電話によるインタビューが一部で行われました(とても高価です)。またラジオの実況中継が実現し、水泳競技では有名な「前畑がんばれ」もこの時です。

国内向けテレビ放送もこの年から始まったそうです。

1960年スコーバレー冬季大会

いわゆるITが活用されたのがこの年で、IBMが競技データの処理を行いました。オリンピック史上初めて競技中に途中経過が分かるようになったということです。

ただし、処理内容は限定的で、最終結果の集計には長い時間を要したと聞いています。手作業の時代は、なんと数か月だったそうです。

なお、当時は夏季大会と冬季大会は同じ年に開催されていました。

1964年東京大会

日本IBMが初めてオンラインシステムを構築し、閉会式直前にデータ集計を間に合わせたということです。この成功により、銀行がコンピュータの価値を認め、第一次オンラインシステムにつながります。

しかし、もちろんそんなにスムーズに進んだわけではありません。

当初、日本IBMはIBM米国本社に打診したところ「無理だからやめろ」と言われたそうです。そこで、日本IBMは米国の上層部に直談判、当時の米国本社社長のトーマス・ワトソン・ジュニアが「IBMは、いつからチャレンジを恐れる会社になったのか」と逆転受注につながります。

今思えば、単なるデータ集計ですし、データ量も多くないので簡単と思うかもしれませんが、何しろ昔の話です。

• コンピュータのデータ処理は不正確なので、たとえばお金を扱うことはできない
• 複数の競技場のデータを集中管理するシステムはあまり例がない
• データ通信にはデータ通信専用の回線が必要で、音声回線は使えない

という問題がありました。

最後の問題は、今の人には分かりにくいかもしれません。

当時は、音声回線にデータを流すと、電気特性の違いから交換機を破損するリスクがあったそうです。そのため、データ専用の回線を敷設するのですが、音声回線すら満足に敷設できなかった時代、優先的にデータ通信回線を敷設するのは時間と費用がかかるだけではなく、音声回線の敷設を後回しにすることにもなります。そもそもオリンピック用システムの企画当時、電電公社(現在のNTT)はデータ通信をサービスとして全く提供していなかったのです。

結局、モデムを使うのであれば大きな問題はないだろう、ということで法改正をして音声回線を使ったデータ通信を行ったそうです。

ネットワークを使ったデータ集計は、米軍がミサイル防衛網の情報管理に使っていた「SAGE」、それを応用したアメリカン航空の「SABRE」、そして国鉄(現在のJR)が日立製作所と共同開発したMARSくらいしかありませんでした。

ちなみにSAGEは全米のレーダー基地からの情報を集計する仕組みで、レーダー基地の代わりに旅行代理店にしたのがSABREだということです。

SAGEもSABREもIBMが開発したため、分散データ処理が不可能だったわけではありません。日本IBMは、このノウハウが利用できると期待していたのかもしれません。

システムは完全なウォーターフォール型で、開発に2年半かかったと言われています。案の定、プロジェクトは遅れ、人員の追加と、米国からプロジェクトの支援があったそうです。「遅れているプロジェクトに人員を投入するとさらに遅れる」という言葉もありますが、この時は完璧なドキュメントがあったため、大きな遅れはなく、プロジェクト進行を早めることが出来たとか。

伝わっている資料では、詳細設計書はバインダー5冊、英文、流れ図・表を含む千数百ぺージに及んだということです(東京オリンピック情報システム関連資料リスト)。

ちなみに、この時に使われたのがセイコーのクォーツ時計です。

1996年アトランタ大会

IBMが、自社のテクノロジーのショーケースとしてクライアントサーバーシステムを全面採用し、通信社向けのデータ配信サービスを開始します。また、初めて公式Webが出来たのもこの時です。

1998年長野冬季大会

インターネット普及期と重なり、IBMが構築した公式Webサイトは、3万ページに及ぶコンテンツとなり、期間中に6億アクセスがあったそうです。

これだけのアクセスをさばくのは1台ではもちろん無理で、負荷分散装置が導入されました。負荷分散装置の本格採用は珍しい時代だったため、情報処理学会の学会誌にも

複数のコンピュータに単一のIPアドレスを割り当てる特殊な方法

と紹介されていました。

2014年ソチ冬季大会

全面的にクラウド(Microsoft Azure)が導入され、動画配信などに力を発揮しました。

システム構築期間は明らかにされていませんが、おそらくかなり短期間でしょう。

2020年東京大会

さて、2020年の東京大会では、どのような技術が投入されるのでしょう。ソーシャルメディアとの連携や、入場券などに埋め込まれたICタグによる交通制御などがあるのでしょうか。