Google スプレッドシートと比較して、Microsoft Excel が決定的に劣る点。
長年のウィークポイントであった同時編集については、Office 365 でほぼ挽回しているようだし、今回ツッコむのはその点ではない。
ズバリ、Microsoft Excel は「行列の削除ができない」。
なんのこっちゃ、という人もいらっしゃるやもしれないが、試しに Microsoft Excel で「空白のブック」（新規ワークブック）を開いてもらいたい。
そして、ワークシートで最大行列のセル（一番右下のセル）を選択する。[Ctrl]+[↓] と [Ctrl]+[→] でキー操作すると早い。行は「1048576」、列は「XFD」になっているはずだ。
その上で、適当な行や列を「削除」してみる。行や列を選択して、右クリックのプルダウンメニューから [削除] を選択する。しかし、表示されている最大行列のラベルは「1048576」と「XFD」のままだ。
言うなれば、選択した行列の削除はされているのだが、域外から削除されたのと同数の行列が追加されている。つまり、ワークシートの行列数は増減しない。
これが「行列の削除ができない」の意味。
Google スプレッドシートの場合は、削除すれば普通にその分行列は減る。
実に単純だ。
一見どうということもない違いではあるが、さに非ず。Microsoft Excel はワークシートの全体像を明示できないのだ。
見えている範囲の表や数値で全てかと思っていたら、極端な話 XFD1048576 のセルにデータが入っているかもしれない。それは実際に調べてみないと判らない。
確かに [Ctrl]+[End] で「最後のセル（右端の使用されている列の、最も下の使用されている行のセル）」へ移動できるので、それで確認はできるが、そうやって意図的に調べないと判らない。
削除できないのなら非表示にするという手もあるが、「見えていないだけで実体としては残っている」というのは混乱の種になるだけだ。
対して Google スプレッドシートの場合、不要な行列をバッサリ後腐れなく削除しておけば、シートの全体像は一目瞭然になる。
実に明瞭だ。
Microsoft Excel はバージョンを重ねても、この辺りの仕様が改善される気配はない。
おそらく高邁なる設計思想に基いているからなんだろうが、それだけにこれからも「決定的に劣る点」として残り続けるだろう。
ページ
▼
2018/02/26
2018/02/21
ソフトバンクのキャリアメール、運用ポリシー変更した？
ソフトバンクのキャリアメール（ @softbank.ne.jp ）、SMTP Server の運用ポリシー変更したのかな。
先週金曜日（2018/02/16）から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。
しっかし、キャリアメールは昔から頭痛の種なんだよな。
早く絶滅せんものか。
今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな（実際利用者は右肩下がりらしいので喜ばしいこと）。
先週金曜日（2018/02/16）から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。
しっかし、キャリアメールは昔から頭痛の種なんだよな。
早く絶滅せんものか。
今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな（実際利用者は右肩下がりらしいので喜ばしいこと）。
2018/02/20
e-Tax のインフラは Akamai
e-Tax って、Akamai（※）のネットワーク使って展開してるんだ。
今更ながら、「www.e-tax.nta.go.jp」を正引＆逆引して気が付いた。
さらにフロントエンドのみならず、バックエンド側も Akamai のネットワークでかためている模様。
※：
アカマイ・テクノロジーズ - Wikipedia
世界最大手の CDN業者。本社米国。
何だかなぁ。これは一納税者として納得いかん。
国家事業なんだから、安全保障上からも国内産業育成からも、国内の業者に任せるべきだろ。
余分に金を積んででも、IIJ 辺りにやらせて欲しい。
今更ながら、「www.e-tax.nta.go.jp」を正引＆逆引して気が付いた。
さらにフロントエンドのみならず、バックエンド側も Akamai のネットワークでかためている模様。
※：
アカマイ・テクノロジーズ - Wikipedia
世界最大手の CDN業者。本社米国。
何だかなぁ。これは一納税者として納得いかん。
国家事業なんだから、安全保障上からも国内産業育成からも、国内の業者に任せるべきだろ。
余分に金を積んででも、IIJ 辺りにやらせて欲しい。
2018/02/19
G Suite グループでは配信不能レポートは配送できない
G Suite（旧 Google Apps）のグループ（ML、メーリングリスト）では、SMTP Server からの配信不能レポート（エラーメール）は配送できない。
Google グループに関するよくある質問（管理者向け） - G Suite 管理者 ヘルプ
----------引用ココから
グループに送信できないメールの種類はありますか？
「返送メッセージ」とも呼ばれる配信不能レポート（NDR）をグループに送信または転送することはできません。NDR に似ているメッセージも、送信や転送はできません。
----------引用ココまで
この仕様、つい忘れて毎度「？？？」となってしまう。
単に「できません」としか書かれていないが、具体的な動きとしては配信不能レポートを dsn=2.0.0 で受取った上で、何処へ何も残すことなく（グループの管理画面にも痕跡を残さず）暗黙の内に破棄してしまう。
グループアドレスを代表にして、それを使ってチームで顧客対応をしたりする場合。つまり、各メンバはグループアドレスを From にして顧客へメール送信し、顧客にはグループアドレスへ返信してもらう（自動的にグループメンバでシェア）という運用の場合、問題が出てくる。
顧客のアドレスを間違って入力した場合（またはアドレスが既に存在しない場合）、普通は User Unknown で配信不能レポートが戻ってくるので直ちに気がつけるのだが、この場合 G Suite のグループは配信不能レポートを飲み込んでしまうので、それに気が付けない。これは困る。
回避方法としては、グループを使うのではなく G Suite の実アカウントを使って転送設定するか、「デフォルトの転送の設定」を使って転送設定するか…辺りか。
前者はユーザレベルでもメンテナンス可能（メンバの追加／削除が可能）だが、実アカウントを使う関係上コスト増になる。もちろん個別にアカウントを用意せずとも、個人アカウントで併用するという手もあるが…さらに管理が面倒になる。
後者はメンテナンスが管理者に限られる上、クリティカルな作業になってしまう（下手するとドメイン全体のメール配送に悪影響が及ぶ）。メンバの追加／削除ごときで、毎度々々そんなところをいじってられない。
どちらの方法にしても、非常に整備性が悪い。
G Suite というのは優秀なサービスなんだが、こういう割り切って使わなくてはいけない仕様が所々ある。
まぁ、何でもトレードオフということなんだろうが…。
Google グループに関するよくある質問（管理者向け） - G Suite 管理者 ヘルプ
----------引用ココから
グループに送信できないメールの種類はありますか？
「返送メッセージ」とも呼ばれる配信不能レポート（NDR）をグループに送信または転送することはできません。NDR に似ているメッセージも、送信や転送はできません。
----------引用ココまで
この仕様、つい忘れて毎度「？？？」となってしまう。
単に「できません」としか書かれていないが、具体的な動きとしては配信不能レポートを dsn=2.0.0 で受取った上で、何処へ何も残すことなく（グループの管理画面にも痕跡を残さず）暗黙の内に破棄してしまう。
グループアドレスを代表にして、それを使ってチームで顧客対応をしたりする場合。つまり、各メンバはグループアドレスを From にして顧客へメール送信し、顧客にはグループアドレスへ返信してもらう（自動的にグループメンバでシェア）という運用の場合、問題が出てくる。
顧客のアドレスを間違って入力した場合（またはアドレスが既に存在しない場合）、普通は User Unknown で配信不能レポートが戻ってくるので直ちに気がつけるのだが、この場合 G Suite のグループは配信不能レポートを飲み込んでしまうので、それに気が付けない。これは困る。
回避方法としては、グループを使うのではなく G Suite の実アカウントを使って転送設定するか、「デフォルトの転送の設定」を使って転送設定するか…辺りか。
前者はユーザレベルでもメンテナンス可能（メンバの追加／削除が可能）だが、実アカウントを使う関係上コスト増になる。もちろん個別にアカウントを用意せずとも、個人アカウントで併用するという手もあるが…さらに管理が面倒になる。
後者はメンテナンスが管理者に限られる上、クリティカルな作業になってしまう（下手するとドメイン全体のメール配送に悪影響が及ぶ）。メンバの追加／削除ごときで、毎度々々そんなところをいじってられない。
どちらの方法にしても、非常に整備性が悪い。
G Suite というのは優秀なサービスなんだが、こういう割り切って使わなくてはいけない仕様が所々ある。
まぁ、何でもトレードオフということなんだろうが…。
2018/02/15
RAIDストレージが壊れた & RAID1 の分散読込による高速化
自宅で使っていた RAIDストレージが、壊れてアクセスできなくなった。
とは言っても、RAID を構成している物理ドライブが壊れたのではなく、壊れたのは筐体側というあるあるパターン。つまり、RAIDストレージは一撃にして使用不能。
ドライブは多重化できても、筐体（RAIDコントローラ）はシングルポイントにならざるを得ない。あまつさえ使っていた筐体は NAS ではなく USB 接続の「HDDケース」で、オモチャみたいな RAID機能だった。こうなったのも、まぁ宜なるかな。
ただ、幸い RAID1（ミラーリング）で使っていたので、構成ドライブの片方を引抜いて USBアダプタで直結すれば、何の問題もなくそのまま使える（もちろん冗長性は失われているが）。
RAID5 や RAID6、それに RAID10 ではこうはいかないわけで、RAID1 の単純さ故の利点（※）。
※：もっとも、それ故にドライブの廃棄時や、修理交換時には（他の RAID 以上に）気を使うんだが…。
かくなる次第で現在、後釜にすべき製品を選定中。
どれを選んでも大差なかろうから適当に選んでいいかと思いつつも、できれば RAID1 の分散読込に対応している製品はないかと物色している…のだが、その辺りに言及している品が見つからない。
当今では RAID1 の分散読込ぐらい当たり前に対応しているだろうと思い、かつては今回壊れた製品を購入したのだが、読込では片一方のアクセスランプしか点灯せずにガッカリしたという事がある。
分散読込に対応しているような「気の利いた」製品は、昔同様やはり相応に本格的なもの（お高価い）である必要があるんだろうな。
追記：
軽く検索してみたのだが、世の中には「RAID1 の分散読込による高速化」というものを頑なに理解しない人がいるらしい。前世紀からの常識と言わずとも（実際 1990年代で普通に言及されていた）、2台のドライブへどの様にデータが保存されているのか考えたら、分散読込が可能なことは（技術的な手間や是非は置くとして）自明だと思うのだが。
例： 『RAID1構築での読み込みドライブは１つ？』 - 価格.com
とは言っても、RAID を構成している物理ドライブが壊れたのではなく、壊れたのは筐体側というあるあるパターン。つまり、RAIDストレージは一撃にして使用不能。
ドライブは多重化できても、筐体（RAIDコントローラ）はシングルポイントにならざるを得ない。あまつさえ使っていた筐体は NAS ではなく USB 接続の「HDDケース」で、オモチャみたいな RAID機能だった。こうなったのも、まぁ宜なるかな。
ただ、幸い RAID1（ミラーリング）で使っていたので、構成ドライブの片方を引抜いて USBアダプタで直結すれば、何の問題もなくそのまま使える（もちろん冗長性は失われているが）。
RAID5 や RAID6、それに RAID10 ではこうはいかないわけで、RAID1 の単純さ故の利点（※）。
※：もっとも、それ故にドライブの廃棄時や、修理交換時には（他の RAID 以上に）気を使うんだが…。
かくなる次第で現在、後釜にすべき製品を選定中。
どれを選んでも大差なかろうから適当に選んでいいかと思いつつも、できれば RAID1 の分散読込に対応している製品はないかと物色している…のだが、その辺りに言及している品が見つからない。
当今では RAID1 の分散読込ぐらい当たり前に対応しているだろうと思い、かつては今回壊れた製品を購入したのだが、読込では片一方のアクセスランプしか点灯せずにガッカリしたという事がある。
分散読込に対応しているような「気の利いた」製品は、昔同様やはり相応に本格的なもの（お高価い）である必要があるんだろうな。
追記：
軽く検索してみたのだが、世の中には「RAID1 の分散読込による高速化」というものを頑なに理解しない人がいるらしい。前世紀からの常識と言わずとも（実際 1990年代で普通に言及されていた）、2台のドライブへどの様にデータが保存されているのか考えたら、分散読込が可能なことは（技術的な手間や是非は置くとして）自明だと思うのだが。
例： 『RAID1構築での読み込みドライブは１つ？』 - 価格.com
2018/02/07
FireFox のプロキシ設定でハマリかけた
FireFox のプロキシ設定でハマリかけたので。
なお、これは Windows 10 Fall Creators Update + FireFox 58.0.1 の話。
さて、順を追って書いていくのも面倒なので、引掛けポイントを列挙する。
1. FireFox は DHCP による WPAD に未対応
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
3. Microsoft DNS Service には「DNS 禁止リスト」がある
プロキシ設定の配布方法には色々な方法があり、その中で一番自動化された方法が WPAD による配布。
さらに、WPAD による配布にも二通りあり、DHCP で配布する方法と、DNS で配布する方法がある。
WebブラウザのProxy設定を行うための4つの方法（WPADのススメ） - @IT
で、FireFox は DHCP による配布には対応していないというわけ。なので、WPAD を使おうとすると、勢い DNS で配布する必要がある。
以下のページで主要ブラウザについてまとめられているが、FireFox のそれは Windows に於いて例外的な挙動。
Browser Support - FindProxyForURL
まぁこういう仕様になっている理由は、概ね類推できるが…足並み揃えて欲しいよなぁ。
FireFox のプロキシ設定は、デフォルトで [システムのプロキシ設定を利用する] になっている。
そうなっているのは普通に考えるならベターな選択だとは思うが、残念ながらシステム設定を利用してくれない場合がある。
システム（IE）のプロキシ設定： [設定を自動的に検出する]
FireFox のプロキシ設定： [システムのプロキシ設定を利用する]
以上の場合（なお、これが OS & FireFox のデフォルト状態）、当然 IE 側は WPAD を検索して見つかればその設定を使ってくれる。FireFox も WPAD を検索してくれ…そうなものだが、してくれない。
どうも「[設定を自動的に検出する] というシステム設定」は、利用してくれないようだ。なので FireFox で WPAD を利用しようとすると、デフォルトから [このネットワークのプロキシ設定を自動検出する] へ変更しないといけない。
これが意味するところ、プロキシが必要な環境において、FireFox はどう頑張ってもデフォルトで動くようにできないということ。もちろん、FireFox の設定ファイルを自動配布するという手もあるが、本来はネットワーク側の設定だけで解決する話が、わざわざ別途そこまで手をかけてやる必要がある。
これは、心底ガックリ仕様。
なお、念のため確認したところ、macOS High Sierra + FireFox 58.0.1 では再現しない。つまり [システムのプロキシ設定を利用する] でちゃんとシステム設定に従って WPAD を検索してくれる。
…これ、Windows版 FireFox の不具合なんじゃねーの？
これは FireFox の問題ではないが、関連してハマリかけたので。
DNS 禁止リストからの WPAD の削除 - Microsoft
セキュリティ上の問題で、「wpad」は「DNS 禁止リスト」に入れられている。なので普通に設定しただけでは、問い合わせに答えてくれない。
これは「DNS 禁止リスト」を更新すれば解決。
動的更新で「wpad」レコードを登録されたら…と考えると当然の処置だが、それならそれで設定時に「禁止リストに入っとるで」と警告を出すとかして欲しいよなという気も。
----------
「2」の現象、Windows XP + FireFox 47.0.2 なんていう化石環境でも再現する。
どうも「不具合」というわけではなく、Windows版 FireFox の「仕様」である模様。
「不具合」であれば、新バージョンで改善するという希望も持てたんだが…。
なお、これは Windows 10 Fall Creators Update + FireFox 58.0.1 の話。
さて、順を追って書いていくのも面倒なので、引掛けポイントを列挙する。
1. FireFox は DHCP による WPAD に未対応
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
3. Microsoft DNS Service には「DNS 禁止リスト」がある
1. FireFox は DHCP による WPAD に未対応
プロキシ設定の配布方法には色々な方法があり、その中で一番自動化された方法が WPAD による配布。
さらに、WPAD による配布にも二通りあり、DHCP で配布する方法と、DNS で配布する方法がある。
WebブラウザのProxy設定を行うための4つの方法（WPADのススメ） - @IT
で、FireFox は DHCP による配布には対応していないというわけ。なので、WPAD を使おうとすると、勢い DNS で配布する必要がある。
以下のページで主要ブラウザについてまとめられているが、FireFox のそれは Windows に於いて例外的な挙動。
Browser Support - FindProxyForURL
まぁこういう仕様になっている理由は、概ね類推できるが…足並み揃えて欲しいよなぁ。
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
FireFox のプロキシ設定は、デフォルトで [システムのプロキシ設定を利用する] になっている。
そうなっているのは普通に考えるならベターな選択だとは思うが、残念ながらシステム設定を利用してくれない場合がある。
システム（IE）のプロキシ設定： [設定を自動的に検出する]
FireFox のプロキシ設定： [システムのプロキシ設定を利用する]
以上の場合（なお、これが OS & FireFox のデフォルト状態）、当然 IE 側は WPAD を検索して見つかればその設定を使ってくれる。FireFox も WPAD を検索してくれ…そうなものだが、してくれない。
どうも「[設定を自動的に検出する] というシステム設定」は、利用してくれないようだ。なので FireFox で WPAD を利用しようとすると、デフォルトから [このネットワークのプロキシ設定を自動検出する] へ変更しないといけない。
これが意味するところ、プロキシが必要な環境において、FireFox はどう頑張ってもデフォルトで動くようにできないということ。もちろん、FireFox の設定ファイルを自動配布するという手もあるが、本来はネットワーク側の設定だけで解決する話が、わざわざ別途そこまで手をかけてやる必要がある。
これは、心底ガックリ仕様。
なお、念のため確認したところ、macOS High Sierra + FireFox 58.0.1 では再現しない。つまり [システムのプロキシ設定を利用する] でちゃんとシステム設定に従って WPAD を検索してくれる。
…これ、Windows版 FireFox の不具合なんじゃねーの？
3. Microsoft DNS Service には「DNS 禁止リスト」がある
これは FireFox の問題ではないが、関連してハマリかけたので。
DNS 禁止リストからの WPAD の削除 - Microsoft
セキュリティ上の問題で、「wpad」は「DNS 禁止リスト」に入れられている。なので普通に設定しただけでは、問い合わせに答えてくれない。
これは「DNS 禁止リスト」を更新すれば解決。
----------
Afterfollow 2018/02/13
「2」の現象、Windows XP + FireFox 47.0.2 なんていう化石環境でも再現する。
どうも「不具合」というわけではなく、Windows版 FireFox の「仕様」である模様。
「不具合」であれば、新バージョンで改善するという希望も持てたんだが…。