2018年9月29日(土) 12時06分41秒 [ソフトウェア]

データが先か、ソフト(アプリ)が先か

最初に意識するのはデータなのかソフトウェアなのか

WindowsやMacのような最近のPC向けOSでは、ユーザは「データファイル」をダブルクリックすることで何らかの操作をし始めるという手順が使えますよね。
もちろん、ソフトウェアを先に起動してからデータファイルを読み込む手順でも操作はできますが。
ブラウザやメーラやゲームのように「単独のデータファイル」というのが存在しない（orユーザに意識されない）ソフトウェアなら、ソフトウェアを先に起動するでしょうが、
Office系ソフトのデータのように、データ自体を作ることが目的のソフトウェアは、データファイルをダブルクリックして開かれる操作が多いのではないかと思います。

一方、iOSやAndroidなどのモバイルOSでは、まずユーザは最初にアプリを起動するのがほぼ唯一の操作手順ですよね。
そのアプリがどこにどんな風にデータファイルを作っているかをユーザ側が認識することは滅多にありません。

このような、何をするにしても「まずはアプリを起動して……」というのは、よく考えると昔々のPCの作法ですよね。
複数のソフトウェアを同時に起動しておけるほど潤沢なメモリ容量がなかった頃のWindowsもそうですし、それよりも前のMS-DOSみたいなシングルタスクなOSとかがそうでした。
そういうOSでは、「まずソフトを起動して」→「次にデータを読み込む」という手順でしか操作しようがありませんでしたから。

それが、WindowsやMacOSみたいなグラフィカルなOSの登場で、データを直接触れば適切なソフトが立ち上がって読み込まれる、というデータドブリンな仕組みになったわけですが。
iOSは、そんなデータファイルの存在を意識せずに使えるOSとして開発されたのでしょうが、それによって昔のPC流の起動手順に返ってしまっているのがちょっとおもしろいです。

わざわざユーザが考えなくても済むようにしよう、という思想は同じでも

そもそも、WindowsとかのPC用OSは「何のソフトを起動しないといけないのかをユーザが判断せずに済むようにしよう」という設計思想で、データファイルを選択するだけでソフトが起動される仕様にしたわけですよね。
ところが、その次に現れたモバイル端末向けOSは、「データファイルの存在をユーザが気にしなくて済むようにしよう」という設計思想で、データファイルの存在を見えなくした結果、ユーザがアプリを選択して起動するという最初に立ち戻ったわけで。
この堂々巡りみたいなものは今後も続くのかな、という気もします。(^_^;)

データファイルをダブルクリックしてソフトが起動する仕様は確かに便利ですが、「同じデータ形式を扱えるソフトが複数インストールされている」環境も多々あるわけで、関連付け設定が変わってしまった結果、意図したソフトが立ち上がらなくなるケースもありますからね。(^_^;;;
もちろん関連付け設定を好きなように変更すれば済む話ではあるんですが。そういう手間が発生する時点で、「その仕様が万人向けだ」とは言えないのかも知れません。

初心者ユーザが分かりやすいのはどちらなのかな？

実際のところ、何の予備知識もないユーザは、

• 使いたいソフトウェアを先に起動してから、必要なデータファイルを読み込む手順
• 編集したいデータファイルをダブルクリックすることで、ソフトウェアを起動する手順

のどちらを使いやすいと感じるんでしょうかね？

よく考えると、編集したいデータファイルがある場合には「データファイルのダブルクリック」でも良いですが、新規にデータを作成したい場合には、ソフトウェアを直接起動する方が分かりやすそうですね……。(^_^;)
私の場合は、プレーンテキストなtxtファイルを作るときだけは、Windowsのエクスプローラにある新規作成機能を使って空のファイルを先に作成してからテキストエディタを立ち上げることもありますが、それ以外の場合ではソフトウェアを先に起動すると思います。

※プレーンテキストなデータを作るときでも、テキストエディタの方を先に起動することもあります。（作成先のフォルダが決まっている場合で、そのフォルダを表示しているエクスプローラのウインドウが今ある状況でなら、エクスプローラ側から新規作成するかな……。^^;）

仕様の堂々巡りといえば

そういえば、そういう堂々巡りみたいなのは、Windowsのレジストリにも言える気がします。
初期の頃のWindowsは、ソフトウェアの設定ファイルは各ソフトウェアが勝手に作成して好きなところに保存されていました。
でも、それではどこに何の設定があるのか一括して把握できないので、「今、どんなソフトウェアがインストールされているのか」すら把握は困難でした。
そこで登場したのは、ソフトウェアの設定を一括管理できるデータベースである「レジストリ」です。
ところ、その仕様になってから、レジストリの肥大化による速度低下が問題になってきました。
その結果、「このソフトウェアはレジストリを使いませんよ」というのが1つの売り文句になってしまった、というような。(^_^;)

なかなか「これなら万人がハッピーになれる！」という仕様はできあがらない、ということなんでしょうねえ。

2018年9月27日(木) 13時38分59秒 [学習・資格]

受験番号を書き忘れたら失格になるかどうか

ふと思い出した昔々の話。

入学試験では、名前を書き忘れたら失格とか、受験番号を書き忘れたら失格、とかよく言われますよね。
実際にそうなのか、という話です。

入学試験のお手伝い生徒

私が昔々に通った高校は、中学もある私立高校でした。(私自身は、高校受験で入学して高校の3年間だけを通ったんですが。)
で、私立なので高校入試だけでなく中学入試も実施されます。
その中学入試には、受験生誘導用のお手伝い役が在校生の中から募集されました。
んで、報酬として図書券3,000円をくれるというので、私は手を挙げたのでした。報酬目的というのもありますが、単純に入試の手伝いをしてみたかったというのもあります。^^;（単純に拘束時間で割れば時給400円くらいですかね。^^;）

そのお手伝い生徒の主な仕事は、体育館に集められた受験生（＝小学6年生）の集団を試験教室まで誘導したり、面接の際に1人ずつ入室するよう案内したりすることなどなんですが、試験監督のまねごともありました。
試験監督はもちろん教員(各教室に1人)なんですが、1教室につき2人ずつお手伝い生徒が配置されていました。

受験生が鉛筆を落としたり消しゴムを落としたりしたときに本人が直接拾うことは禁止されていたので、それらを代わりに拾ってあげることと、試験終了後に答案を回収して回るのが役割です。(なので、試験中はほとんど突っ立っているだけです。鉛筆や消しゴムは2～3回くらいは拾ったような気がしますが。)

で、今回の本題はそのペーパーテストに書く受験番号です。

答案回収時には受験番号が書かれていることを確認せよ、との指示

試験時間終了後に受験生の答案を回収する仕事では、事前に「受験番号がちゃんと書かれているかどうかを確認してから回収せよ」という指示がありました。
……あったんですけども、
私は「とにかく早く回収しないと！」と思って、何も確認しないまま回収しちゃったんですよね。

すると、1人だけ居たんです！
受験番号を書いていなかった受験生が！

生徒（＝私）が回収してきた答案は、最後にざっと教員が教卓で確認するわけですが、その中に1枚だけあったんです。受験番号の書かれていない答案が。

しまった！ 確認してなかった！

と後悔しましたね。
うちの学校の答案には、受験番号欄だけがあって氏名を書く欄はなかったので、誰の答案なのかを特定する要素は受験番号ただ1つしかありません。（冗長性が足りないと思います！）

これで、あの受験生が失格になってしまうのだとしたら申し訳なさ過ぎる、と思ったんですが、

さらっと救済

我々が回収してきた答案をざっとチェックしていた先生は、ほんの1秒間くらい迷う表情を見せた後、手元の鉛筆でさらっと空欄に受験番号を書き加えました。

受験番号は完全に連番な上、答案は座席順に回収しているわけですから、前後の答案に書かれた受験番号を見れば、その書き忘れ答案の受験番号も当然分かります。

というわけで、その子は受験番号を書き忘れたわけですが、失格にはならなかったのでした。
（もちろん、入試に合格できたかどうかは別の話ですが。）

※今ふと思ったんですけども、受験番号を書き忘れたのではなく、書き間違えていた場合はどうだったんでしょうね？(^_^;) 存在しない番号を書かれただけなら本人が困るだけですが、存在する他人の番号が書かれた場合、その他人の方にも被害が及ぶような。そういうミスを防ぐためにも、受験番号欄の他に氏名記入欄も設けて冗長性を確保しておいた方が望ましいんじゃないでしょうかね？(^_^;) そもそも受験番号にも、チェックディジットみたいな1桁を付加しておく方がより安全だと思うんですが。（受験番号ただ1つしか書かせない仕様なら、なおさら。）

2度目はちゃんと指摘できたんだけど

で、その中学入試では、たしか午前に1科目、午後に1科目のペーパーテストがあって、最後に面接があったんだったような気がします。（すさまじく昔の話なので記憶がおぼろげですが。）

午後の試験でも私は同じ教室のお手伝いを担当しまして、さすがに2度目の回収時にはちゃんと1枚ずつ受験番号が書かれているかどうかを確認しました。
すると、やはりその子は受験番号を書いていませんでした。
「忘れていた」というよりも、受験番号を書く必要があるという事実自体を認識していなかったのかも知れません。(^_^;)

なので今度は回収するときに指摘して、その子自身に受験番号を書かせることができたわけですが、
よく考えると、彼は落ち込んだだろうな、と思います。
だって、午前の試験では自分は受験番号を書かなかったわけですから、当然、午前の試験の段階で自分は失格になったのだと思ったことでしょう。

※いや、もしかしたら、「あれ？午後の試験だけは受験番号を書く必要があるの？」と思うような天然の子であった可能性もないとは言えませんが。(笑)

これでもし3つ目のペーパーテストが続いてあったとしたら、もう3つ目はやる気をなくしていたかも知れません。
幸いペーパーテストは2つだけで、残りは面接だけでしたから、面接でよほど気力を失っていなければ大丈夫だとは思いますが。

こっそり教えてあげれば良かったが

今思い返すと、1つ目の試験が終わった後に、こっそり救済措置の事実を教えてあげておけば良かったかな、と思うんですが、当時はそこまで気が回りませんでした。^^;
なんせ、ただの高校生ですし。
彼が面接を諦めていなければ良いんですけどもね。
（彼が合格したのかどうかは知りませんし、そもそも合格できる学力があったのかどうかも知りませんが。）

※名前を書く欄がなかったので名前も知りません。（そういえば、受験票とかあったのかな？ ないわけないからあったんだろうけど、記憶にない。^^;）

余談

ただまあ、卒業生が言うのもなんですが、別にそこまで入試を頑張ってあの学校に6年間も居てもあんまり良いことはないと思うんですけどもね。(笑)
私は高校から入ったので3年間しか居ませんでしたけども。
進学校ですから、高校卒業後には「名の知れた大学に入りたい」という目的があって選んだんでしょうけども、たぶん公立中高に行きつつ塾や予備校に通う方が良いと思うなあ。^^; 精神的にも、コスト的にも。
だって、午前4時間・午後4時間の1日8時間授業を、毎日毎日同じ連中と一緒に受けるって、相当控えめに表現しても苦痛しかないので。

※ちなみに現在では共学になっていますが、当時は男子校でした。(なので、なおさら監獄みたい。：爆)

本題とは何も関係ないんですが、男子校に通った身で言いますけども、野郎ばっかり集めても何一つ良いことはありませんよ。(笑)
デメリットしかないと断言してもまったく過言ではない。

さらに余談

さらに関係ないんですが、手にした報酬3,000円(分の図書券)で買ったのは、結城浩さんの「C言語プログラミングレッスン〈文法編〉」だったと思います。
当時、MS-DOS環境のLSI C-86とかでプログラミングしていた私にとって、とても役立った本でした。駸々堂書店で立ち読みしていてとても欲しかったんですよね。これが。
ああ買いたいなあと思っていたところに入試お手伝いの話が来たので渡りに船でした。

というわけで、受験番号を書き忘れても失格にならないこともある、という話でした。

2018年9月14日(金) 14時50分54秒 [Web関連]

SSL証明書を RapidSSLから Let's Encryptに変更した

有料のSSL証明書を削除して、無料のSSL証明書に変更

うちのウェブサイトで使っているSSL証明書を、DigiCert（GeoTrustのRapidSSL）発行のものからLet's Encrypt発行のものに変更しました。

9月13日にβ版がリリースされるChrome70から適用される「SymantecのSSL証明書失効問題」が、うちの証明書にも該当していましたので。再発行は無料でできるんですが、どうせ手続きをするなら継続するよりも無料の証明書に変更しようかと思いまして。

私が管理しているサイトのうち、メインの個人サイト(www.nishishi.com)以外では既に Let's Encrypt を使っていたのですが。メインサイトだけは（レンタルサーバ側でLet's Encryptを超簡単に導入できる仕様が用意されるよりも）ちょっとだけ早めにSSL化をしたので、GeoTrustのRapidSSLを使っていたのでした。

RapidSSLの証明書はまだ2019年まで使う権利はあるので、ここで捨てると1年半くらいの料金が無駄になってしまいますが、まあ、そこはサンクコストですからね。
別にLet's Encryptと比較してRapidSSLの方がセキュリティ的に望ましいということもないですし、どうせ元々RapidSSLの権利消費後にはLet's Encryptに移行するつもりでしたから。移行作業が早いか遅いかの違いしかありません。

RapidSSLのまま放置していれば良いだけなら放置していたと思いますが、「SymantecのSSL証明書失効問題」が出てきて、RapidSSLに関しても証明書の再発行手続きと設定のし直しが必要になりましたので、どうせ設定変更の作業が必要になるなら、今Let's Encryptに変更して手間を1段階節約しよう、という考えです。

SSLチェッカーで証明書失効対象であることを確認

既にChrome70のβ版はリリースされていますので、それを導入すればチェックも可能ですが。
特定のウェブサイトで使われているSSL証明書が「SymantecのSSL証明書失効問題」に該当するのかどうかは、シマンテックの下記チェックサイトで調べられます。
→『Google Chromeにより警告がでるウェブサイトかチェックする』

うちのドメインで調べると、下記のように「証明書を入れ直すように」と表示されます。(※今はもちろん表示されません)

アクセス数の最も少ない時間帯に作業することに

SSL証明書を変更すると、しばらくの間はSSL通信ができなくなります。
うちのサイトで使っているレンタルサーバ側の案内によると、数十分～数時間くらいは不通時間ができるかもよ、とのことでした。(結果的には不通時間は約30分間でした)
したがって、1日のうちでアクセス数の最も少ない時間帯に作業することにしました。

先月1ヶ月間の時間帯別アクセス数をログで調べたところ、うちの個人サイトでは午前4時台のアクセスが最も少ないようでした。
と言うわけで、昨夜は早めに寝て、わざわざ4時に一旦起きて作業しました。(^_^;)

夜間よりも昼間の方が多いですね。
うちのサイトは、主にCSSやJavaScriptの書き方など、仕事関連情報を求めて職場からアクセスしてくる方々が多いのだろうと思います。たぶん。

サーバのコントロールパネルから、SSL証明書を削除して、新たにLet's Encryptからの証明書発行を申請する

以下は、私が利用しているさくらインターネットのウェブサーバで、RapidSSLのSSL証明書を削除して、Let's Encryptの証明書を入れ直した作業記録です。
作業記録と言っても、特に難しいことはありません。
単にコントロールパネルから作業するだけです。

1. レンタルサーバのコントロールパネルからSSL証明書を全削除
2. レンタルサーバのコントロールパネルからLet's Encryptを申し込み
3. 完了：だいたい30分後にSSL通信が復活

Step.1■レンタルサーバのコントロールパネルからSSL証明書を全削除

まずは、ドメイン設定からSSL証明書を削除します。
「SSL設定の全削除」ボタンを押すと、秘密鍵をバックアップしておきなさいよと案内されます。
まあ再度使うことはないだろうと思いつつ、何らかの問題が発生したときにロールバックできたほうが良いかと思って念のためにバックアップしておきました。

SSL証明書を削除すると、もう次の瞬間にはSSLでの通信はできなくなります。
HTTPSで自サイトにアクセスしようとすると、下図のようなエラーが常時表示されるようになりました。(当たり前ですが)

もしウェブサイトで、強制的にHTTP→HTTPSにリダイレクトしている場合は、常時エラーが表示されるようになります。
一時的にリダイレクトを解除する手もありますが、

1. 301リダイレクトはブラウザ側がキャッシュしているので、リピーターに対しては意味が薄い。
2. 検索サイトには既にHTTPSページが拾われているので、リダイレクトを解除したところで検索経由で来る人々にはエラーが見えてしまう。
3. Let's EncryptのSSL証明書のインストールが完了すればすぐにSSL通信が復活する。

……というわけで、何もせずにそのままエラー状態を放置することにしました。
1時間も経てばSSL通信を復活させられる予定でしたし、なによりもそのためにアクセス数の最も少ない午前4時台を選択したわけですからね。^^;

Step.2■レンタルサーバのコントロールパネルからLet's Encryptを申し込み

すぐさま、コントロールパネルからLet's Encryptの無料SSL証明書を申し込みました。
これも単に申し込みボタンを押すだけなのでとても簡単です。

すぐには反映されないので、しばらく待ち時間があります。
特にすることはなく、ただ待つしかありません。^^;

さくらインターネットでは、Let's Encryptの無料SSL証明書が発行されてサーバへの設定が完了した時点でメールで知らせてくれます。
今回、たまーにリロードしつつ待ってみたところ、サーバへのSSL証明書導入が完了する方がメールよりもかなり早くて、メールはSSL通信ができるようになってから数十分後くらいに届きました。

Complete■完了：だいたい30分後にSSL通信が復活

私の場合は、だいたい30分程度待てば、SSLでのアクセスが可能になりました。
一応、HTTPSではなくHTTPでアクセスを試みた人々向けに、トップページで下記のような案内も掲載してはいたんですが、掲載時間は30分程度だけでした。(^_^;)

というわけで、無事にRapidSSLからLet's EncryptのSSL証明書へと差し替え作業が完了しました。
めでたし、めでたし。

しかしまあ、約30分間のSSL通信不能期間ができるのは避けようがなさそうなので、SSL証明書の差し替え作業はやはりアクセス数の少ない時間帯に作業するのが正解っぽいですね。