Google マップで「マックカフェ店舗一覧（マイマップ）」を作った

　今まで非公開マイマップはいくつか作って利用していたんだが、このほど私的必要から「マックカフェ店舗一覧」を作った。

　そこで、"物好き" "同好の士" の役に立つかも知れないので、ついでに公開することにした。

マックカフェ店舗一覧 - Google マップ

　データの出典は公式サイトの店舗検索ページ。

　実は、このページからは JSONデータで店舗一覧が引っ張れる（Chrome 開発者ツールで探すと見つけやすい）。

　…のだが、今回はたかだか 114店舗なので、しこしこ手作業で抽出した。もっとも地図を見ながら一個づつ拾い出すのは流石に無駄なので、少し工夫して一覧形式でコピペの上加工した。

　で、なぜこのマイマップを作ったのかと言うと、バイクツーリング中にいつも「マックカフェ」を探すから。公式サイトの店舗検索ページを見れば済む話だが、Google マップアプリで見た方が当然に見やすい。

　コーヒーを飲める店は色々あるが、自分としては味とコストパフォーマンスで「マックカフェ」がトップなのだ。フード類（ケーキとかハンバーガー）の味はイマイツツだが、それにしたってコストパフォーマンスは悪くない。

　"物好き" "同好の士" 諸氏にはぜひ役立ててもらいたい。

TeraTerm の SSH SCP で「fopen: 3」エラー

　TeraTerm の SSH SCP（SSH を使ったファイル転送）で、いつも…というわけではないが、時々（現在二回目）嵌って抜け出せなくなるので、自戒を込めた備忘録ということで。

　SSH SCP のダアログで、以下のように受信しようとして嵌まる。

　結果、当然こうなる。

　答えは、「TO にファイル名の指定は不要（ディレクトリ名のみで可）」。
　TeraTerm は「TO」欄の指定をディレクトリ名と解釈するので、ファイル名を指定するとディレクトリ名として解釈してしまい（当然そんな名前のディレクトリはないので）「TTSSH: file open write error」「fopen: 3」となってしまう。

　我ながらバカ丸出しだが、これに嵌まると一頻り考えて抜け出せなくなる。
　まぁここにこうして書いておけば、三度と嵌まることはない（嵌ってもすぐ気がつく）だろう…多分。

本人へ確認のない「誕生日」開示について

　「誕生日」を、本人への確認なくカジュアルに開示する認識、なんとかならんものか。
　「面白みのない奴」と思われても、これは常々思う。

　世間一般では、「生年月日」は本人認証の一要素にされている。
　それの是非についても言いたいことはあるのだが、それはそれでそうなってしまっているのだからしようがない。であるのだから、「誕生日」の開示（あまつさえ本人への確認なく）には慎重であるべきだ。

　「生年月日」は個人情報だが、「誕生日」は単なる「月日」で自ずから個人情報ではない…という意見を開陳しているページも見かけるが、それは詭弁だろ。
　なんとなれば、「誕生日」…つまり「月日」が判明すれば「年」の類推はそれほど難しくない。例えば、外見等から「40歳前後」くらいが判れば、数年の幅を持たせば正解にヒットする。数年…つまり、たったの数パターンだ。
　対して「誕生日」のパターンは 365パターンだ。自ずから重要性は明らかだろう。

　念の為、誕生日を知人縁者へ教える（場合によっては SNS で公開する）ことを論難しているのではなく、「本人への確認なくカジュアルに開示する」ことについて述べている。
　会社で社員間の親睦のために開示するというのも良いだろうが（それはそれで大切で意義あることだが）、当然のように行うのではなく、先立って本人への確認はするべきではないか。

お名前.com の「ドメインプロテクション」機能を調べてズッコケた

　Google Domains へ引越してお名前.com とは手を切ったので、後は野となれ～なんだが、気になってちらっと調べてみた。

　今更ではあるが、レジストラ（ドメイン管理）サービスなんていうのは、基幹中の基幹であるのは言うまでもない。レジストラのアカウントが奪取されたら、whois 書換放題 ＝ ドメインハイジャックし放題な訳で、上のレイヤでセキュリティをいくら固めていても全部ひっくり返されてしまう。
　なので、レジストラのアカウントというのは、最重要アカウントとも言える。

　なのだが、お名前.com のアカウントは、未だ二要素認証に未対応。
　有り得ないなぁ…と思っていたが、お名前.com も流石にどうかと思ったのか「ドメインプロテクション」なる機能を考案していた。

ドメインプロテクション - お名前.com

　ふむふむ、ドメインに対してクリティカルな変更が加えられた場合、登録したメールアドレス宛に承認要求のメールが飛ぶという仕組みか。
　なんとも泥臭い方法だし、そもそもログイン認証がザルだというのは如何なものか。まぁ、とはいえ一歩前進か…と思って読んでいたら…

「1ドメイン980円（税抜）／年」

　はい？
　有料サービスなんかいっ！！

　ほんともうズッコケたよ。
　当然備えていて然るべき機能（しかも不完全な）で金取るのかね。
　しかも、ドメイン維持の本体費用に匹敵するような金額を。

　最近まで（不承不承とはいえ）利用していた身が何をか言わんやだが…お名前.com、今や「情弱向けレジストラ」の様相を呈しておりますな。

グループポリシーへ「Encryption Oracle Remediation（暗号化オラクルの修復）」の追加方法

2018 年 5 月の更新プログラム適用によるリモート デスクトップ接続への影響 - Microsoft Technet

　2018年 5月の Windows Update で、リモートデスクトップ（RDP）周りのセキュリティ強化があって、接続できないサーバーが続出。
　まぁ、サーバーも Windows Update を適用すれば問題ない話なんだが、現実問題そうそう簡単にできるものではない。

　というわけで、姑息（本来の意味）な解決方法を取ることにした。
　グループポリシーで以下の設定をクライアント側へ施せば（当然セキュリティレベルは「脆弱」になるものの）、取り敢えず接続できるようになる。

----------引用ココから
[コンピューターの構成]
-> [管理用テンプレート]
-> [システム]
-> [資格情報の委任]

ポリシー名 : Encryption Oracle Remediation (暗号化オラクルの修復)
設定 : Vulnerable (脆弱)
----------引用ココまで

　しかし、このポリシー項目、一覧に表示されないのだ。
　ローカルグループポリシーであれば、問題の Update を適用すれば追加される（そりゃ問題の Update が未適用なら不要な項目なんだから）。しかし、ActiveDirectory 側のグループポリシーにはどうやって追加すれば…？

　はい、以下のグループポリシーテンプレートを ActiveDirectory 側へ追加すれば OK だ。

Administrative Templates (.admx) for Windows 10 April 2018 Update (1803) - Microsoft ダウンロードセンター

　グループポリシーテンプレートの利用方法は以下。
　最初に書かれている方法より、後に書かれている「セントラルストア（中央ストア）」を使う方法のほうが楽かな。

Windows 10でグループポリシー設定を利用するには - @IT

　これで ActiveDirectory 側のグループポリシーにも追加されて、そちらで一括適用。
　メデタシ、メデタシ。

　………本当に「メデタシ」なのは、サーバー側へ最新の Update を適用してからなんだが。

Microsoft Excel が決定的に劣る点

　Google スプレッドシートと比較して、Microsoft Excel が決定的に劣る点。
　長年のウィークポイントであった同時編集については、Office 365 でほぼ挽回しているようだし、今回ツッコむのはその点ではない。

　ズバリ、Microsoft Excel は「行列の削除ができない」。

　なんのこっちゃ、という人もいらっしゃるやもしれないが、試しに Microsoft Excel で「空白のブック」（新規ワークブック）を開いてもらいたい。
　そして、ワークシートで最大行列のセル（一番右下のセル）を選択する。[Ctrl]+[↓] と [Ctrl]+[→] でキー操作すると早い。行は「1048576」、列は「XFD」になっているはずだ。
　その上で、適当な行や列を「削除」してみる。行や列を選択して、右クリックのプルダウンメニューから [削除] を選択する。しかし、表示されている最大行列のラベルは「1048576」と「XFD」のままだ。
　言うなれば、選択した行列の削除はされているのだが、域外から削除されたのと同数の行列が追加されている。つまり、ワークシートの行列数は増減しない。
　これが「行列の削除ができない」の意味。

　Google スプレッドシートの場合は、削除すれば普通にその分行列は減る。
　実に単純だ。

　一見どうということもない違いではあるが、さに非ず。Microsoft Excel はワークシートの全体像を明示できないのだ。
　見えている範囲の表や数値で全てかと思っていたら、極端な話 XFD1048576 のセルにデータが入っているかもしれない。それは実際に調べてみないと判らない。
　確かに [Ctrl]+[End] で「最後のセル（右端の使用されている列の、最も下の使用されている行のセル）」へ移動できるので、それで確認はできるが、そうやって意図的に調べないと判らない。
　削除できないのなら非表示にするという手もあるが、「見えていないだけで実体としては残っている」というのは混乱の種になるだけだ。

　対して Google スプレッドシートの場合、不要な行列をバッサリ後腐れなく削除しておけば、シートの全体像は一目瞭然になる。
　実に明瞭だ。

　Microsoft Excel はバージョンを重ねても、この辺りの仕様が改善される気配はない。
　おそらく高邁なる設計思想に基いているからなんだろうが、それだけにこれからも「決定的に劣る点」として残り続けるだろう。

ソフトバンクのキャリアメール、運用ポリシー変更した？

　ソフトバンクのキャリアメール（ @softbank.ne.jp ）、SMTP Server の運用ポリシー変更したのかな。
　先週金曜日（2018/02/16）から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。

　しっかし、キャリアメールは昔から頭痛の種なんだよな。
　早く絶滅せんものか。

　今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
　SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな（実際利用者は右肩下がりらしいので喜ばしいこと）。