サマータイムの恐怖

日本が、サマータイムを導入しようとしているらしい。

これだけでも狂気の沙汰であるが、それも2時間もの幅で、それも2年間限定だという。

前代未聞の愚行だが、なんとそれを支持する人が過半数であるという。

都市機能が麻痺し、日本が国際的信用が損なわれ、人命が失われるまさにサイバーテロなのだが、 「日本は自国にサイバーテロを発生させよ!!」と考えているのだろうか。

これがどけほど愚かしいかは詳細に解説するには私には知識が足りないし、 外でも色々と解説されているので、部分的に切り取ってお話しようと思う。

これはほんとひとかけらにすぎないことを理解してほしい。

もっと理解したければ、Togetterに秀逸なまとめがある

サマータイムの難しさ

まつもとゆきひろ氏いわく

Rubyの生みの親であるまつもとゆきひろ氏が著書「コードの世界」の中で次のような話をしている

個人的な経験になりますが,2007年11月に米国,ノースカロライナ州で開催されたRUbyConfの最終日と、2008年3月にチェコのプラハで開催されたEuRuKoの2日目が,ちょうどサマータイム切り替えの日でした。 どちらも前日から主催者が繰り返し「明日からタイムゾーンが切り替わるから時間を間違えないように」と叫んでいましたが,それでも時計を合わせるのを忘れる人がそれなりにいたようです。 ホテルの部屋の時計も自動で調整されるわけではないので,かなり注意しないとうっかりミスをする人が続出しそうです。 電波時計なら自動調整されますが,国中すべての時計をいっせいに電波時計にするわけにもいきませんしね。

ずいぶん昔のことになりますが,Ruby 1.4.4のころ (2000年ころ) には,このサマータイムの扱いにバグがありました。 そのころようやく増え始めたヨーロッパのユーザーからのレポートで発覚したのですが,サマータイムの始まりと終わりの数時間だけ時刻がズレるという典型的な境界条件バグでした。 日本にはサマータイムがないので,私自身が問題を理解できず,このバグを直すのに大変苦労しました。 この経験から,安易なサマータイム導入は,ソフトウエアのトラブルを多発させることになり,最悪の場合,社会問題に,そうでなくても,人知れず数多くのプログラマが涙を飲むことになりそうなので,とても賛成できません。

巻き戻る時間、消失する時間

サマータイムが難しいのはなんといっても「時間が直線状に進まなくなる」ことである。

たとえば、2020年8月1日 00:00:00(JST)に夏時間(DST)が適用になるとする。 すると、2020年7月31日 23:59:59の次の1秒は2020年8月1日 2:00:00になる。 つまり2020年9月1日の0時から2時が消滅する。

一方、2020年9月1日にDSTが終了すると、が2020年8月31日 23:59:59の次は2020年8月31日 22:00:00である。 つまり、2020年8月31日の22時から24時までの間は2回繰り返される。

この場合、たとえば

  • 2020年8月31日23時放送予定の番組はJSTなのかJDTなのかによって2時間ズレる
  • 約束の時間を設定してしまうとすれ違いが発生しうる
  • 日中にやるとさらに問題は深刻に。就業時間も2時間伸びる
  • 0時更新とすると「日をまたぐ瞬間」がなくなってしまう。日次、月次でスケジュールされているジョブが発生しない可能性があり、重大事故が発生する可能性もある

ちなみに、サマータイムの想像はまつもとゆきひろ氏が苦戦していることからも明らかだと思うが、想像よりずっと難しい。 実際私もこれを書いている最中に、「サマータイムに入るときに時間が戻り、サマータイム終了時に時間が進む」と思って途中まで書いていた。 正解は逆である。

UTCから単純計算できない問題

日本は国内時差がないため、基本的にJSTは単純にUTCからオフセットした時間として扱えていた。 ここにJDTが加わるとJSTは計算可能な基準の値ではなくなってしまう。

たとえば日本から5時間戻る時差の場所(UTC+4)へサマータイムをまたいで7時間で移動すると、出発したときから日本の時計を見ていなければ時計上は2時間後に到着したように見えるが、日本の時計から見れば同時刻に到着したように見える。

まず、これが理解できない、特に自分が殊更に理解できないのではなく当たり前に理解できないものだと思うのであれば、サマータイムには断固として反対すべきである。 日本に関わる全ての人がこれを理解して新しい時間を取り扱うよりほかにないのだから。

解説すると、2020-07-31 22:30:00 JSTにアルメニアに向けて7時間で到着する直行便(存在しないが)で出発したとすると、 到着するのは2020-08-01 00:30:00 に到着するが、日本の時刻は2020-08-01 07:30:00 JDTになっている。 2020-08-01 00:30:00はJSTでもJDTでも実際に訪れることはないのだが、2020-07-31 22:30:00 JST = 2020-08-01 00:30:00 JDTである。なので、出発時刻をJDTで見れば同時刻に到着している。

さらにサマータイムをまたいで帰ると今度は16時間後に到着…するわけではなく、12時間後に到着する。

2時間

実はDSTは1時間と書かれていたりして、「サマータイムが2時間」なんていうのは想定外である。 そのため、DSTをフラグ管理していて、DSTが真である場合標準時に1時間を足す、という処理は結構一般的だったりする。

これを2時間のサマータイムなんて導入すると、世界中が大迷惑である。

しかもだ。 JDTはすでにある。

日本でも4年間ほどサマータイムが導入されたことがあり、そのために日本の時刻情報としてこの4年間JDTが運用された記録が残っている。

% date --date="70 years ago"
Thu Aug 19 18:54:05 JDT 1948

なのでJDTは使うことができず、新しい名前をつける必要があるのだが、 命名規則から外れた名前を、しかもサマータイム用に作る必要が生じる。

2年間のために世界中に恒久的に維持・管理しなければいけない複雑なデータをひとつ増やすわけだ。 迷惑も甚だしい。

単純に作業するだけでも経済損失は日本円換算で何十億、何百億では済まないだろうとは思う。

TZのないデータフォーマット

YAMLの場合

% date; ruby -r yaml -e 'puts YAML.dump Time.now'
Sun Aug 19 16:27:15 JST 2018
--- 2018-08-19 16:27:15.749864798 +09:00
...

日のみだとRubyはTimeZoneのないDateクラスを使用する。

% ruby -r yaml -e 'pp YAML.load(ARGV[0])' "ts: 2018-08-19"
{"ts"=>#<Date: 2018-08-19 ((2458350j,0s,0n),+0s,2299161j)>}

日時のみの場合はUTCとみなす

% ruby -r yaml -e 'pp YAML.load(ARGV[0])' "ts: 2018-08-19 05:00:00"
{"ts"=>2018-08-19 14:00:00 +0900}

TZをつけるとちゃんと認識してくれる。

% ruby -r yaml -e 'pp YAML.load(ARGV[0])' "ts: 2018-08-19 05:00:00 +9" 
{"ts"=>2018-08-19 05:00:00 +0900}

JSTだとは認識していない(タイムゾーンでなく時差で認識している)けれど、通常は問題ないはず。 リアルタイムでカウントする場合は問題だけれども、Rubyのレイヤーではそれはその瞬間に異なる時差が適用されるはずだから。

人間が書いたデータに必須でもないのにタイムゾーンが書いてあるなんてほとんど見たこと無いけれど。

日時情報はあるけれどタイムゾーンがないデータを持っているもので最も使われているのはExcelである

Excelマクロで提示処理、あるいは時刻に基づく集計処理をしている皆さん。 ご愁傷さまです。

AMD APU (A10-7870K Godavari) * Radeon VCE * AMDGPU * VA-API * ffmpeg

理屈としては解説してきたものの、実際にVA-APIでVCEを叩いたことがなかったのでやってみた。 ついでなので、qsvやnvenc、あるいはlibx264などでも応用できるウェブカメラとスクリーンキャスティングの話もしておく。

基本的な手順は単純で、AMDGPU(事実上現在唯一となったAMDビデオドライバ)を選択した上で、 VA-APIを有効にし、VA-API経由でエンコーディングを行う。

注意点としては古くなったプロプライエタリドライバ(Catalyst)ではなく、AMDGPUドライバーを使用することと、 MESA VAドライバを使用することである。

RadeonはVA-API/VDPAUの両方をサポートしており、NvidiaのようにVDPAUドライバをインストールし、VA VDPAUアダプタを使用するという方法(libva-dvpau-driver)も成立してしまう。 しかし、この場合は動作しなくなるので、必ずMESA VAドライバ(libva-mesa-driver)を使用する必要がある。

その上で基本はこんな感じ。 (Arch/ManjaroのffmpegはVA-APIを含んでいるのでffmpeg云々の話はない)

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 -c:a copy outfile.mp4

ffmpeg上でのVA-APIは公式にドキュメントがある

ソースファイルがビデオアクセラレーションが効くのであればUVDをVA-API経由で叩いてデコードすることもできる。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 -c:a copy outfile.mp4

ところがこれではうまくいかなかった。 一件成功しているように見えるのだが、フレームの全くないビデオファイルが出来上がってしまい再生できない。

多分、新しいRadeonだとそんなことはないのだろうと思うけれども、Godavari(2015年)のR7グラフィックスでは問題があったため、-profile 578を指定すると解決した。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -bf 0 -qp 24 -c:a copy outfile.mp4

ウェブカムからキャプチャする場合はエンコードのみ、入力はv4l2:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f v4l2 -i /dev/video0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 outfile.mp4

さらにマイクをPulseAudio経由で拾う場合。音声は192k AAC:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f v4l2 -i /dev/video0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

X11のスクリーンキャスティング 音声つき。 A10-7870Kだとh264_vaapiは34fpsくらいなので、60fpsはフレーム落ちばかりになる。30fpsも無理で24fpsがドロップしない限界。 ultrafastにした場合は30fpsは可能だけれど60fpsは無理。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 24 -video_size 1920x1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

ultrafastで30fps:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size 1920x1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

なお、-video_size-iよりも先に指定することが必須である。基本的にffmpegはオプションは順番に厳しい。

300×300のウィンドウを左上から200×200のオフセットで録画する場合

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size 300x300 -i $DISPLAY+200,200 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

-video_sizeの指定方法は色々あって、公式ドキュメントで解説されている。 なので、-video_size 1920x1080ならば-video_size hd1080とも書ける。

録画領域を表示するには-show_region 1

$ ffmpeg -show_region 1 -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size hd1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

NVENCだとmkvにもできるので音声はFLACやOpusで撮ることもできるのだけど、AMDGPU VA-APIはmp4だけ

使ってみた感想としては、QSVと違ってCPUがあくのは良いけれど、R7の速度自体がCPUと大差ない(libx264でやったのと同程度)であるため、ちょっと微妙かもしれない。 A10でもスクリーンキャスティングしながら配信みたいなことができるというメリットはあるけれども。

(Linuxにおける) シャットダウンとリブートの違い

Twitterで、「Linuxでもシャットダウンとリブートは違うよ」という話をしたら、若干の反響があったので、軽く解説。

なお、私はこのあたりのことはそこまで詳しくないので、詳しい解説をすると多分間違えることからほどほどにしておく。

Linux上の仕組み

実は私が行っているのはLinux上でどうこうということではなかったりするのだけど、けれど若干違いはある。

Systemdの場合はsystemd-reboot.service

After=shutdown.target umount.target final.target

となっており、reboot.target

After=systemd-reboot.service

となっている。 でもって、じゃあsystemd-reboot.serviceはなにをしているかというと…

ExecStart=/usr/bin/systemctl --force reboot

そう、再起動はSystemdの場合組み込みである。

shutdownのほうは割と単純で、Conflicts=shutdown.targetBefore=shutdown.targetがあるので色々終了処理を行う。 shutdown.targetはそれだけの存在で、shutdown.servicesystemd-shutdown.serviceはない。

シャットダウン自体はSystemdに組み込みで存在し、reboot同様systemctl shutdownで良い。

ただ少なくとも、rebootとshutdownが分けられている、というのはわかる。

ハードウェア的に

ここからが私が言っていた話になる。

実際に再起動してみるとわかると思うのだが、普通のパソコンでは再起動しても電源が切れることはない。 そして、電源を入れるのと比べて速く立ち上がる。

ワークステーションや、一部の業務用PC(法人向けのモデル)だと再起動時に電源を切ったりするのだが。

そもそもシャットダウンした時点でプロセスはほとんど残っていないのだから、OS側から「電源を切ったら起動する」のような制御をすることはできない。 当然ながらこれはファームウェア的な動作であり、ファームウェア的にシャットダウンの状態とリブートの状態を分けていることがわかる。

一般的には再起動時はPOSTが省略される。 そのため、デバイス認識がバグっている状態(例えば接続されているキーボードが認識されていないとか)では再起動では修復されなかったりする。

ただし、BIOS/UEFI設定に言ってsave changesした場合は(通常は変更があったかどうかにかかわらず)POSTからやり直すようになっている。

電源を切るかどうかについては、メモリ(DIMMに限らず)に影響を及ぼすことから、違いがでる、かもしれない。

英語で、ものすごーーーーく詳しい説明を見つけたのだけど、再度見つけることができず掲載できない。

「LinuxにはIntel*Nvidia」は終わり、時代はAMDに

安定してきたAMD Linux

LinuxにおいてはCPUもビデオカードもAMDは非常に安定性がなく、「LinuxではAMDはリスキー、IntelとNvidiaが鉄板」という時代が非常に長かった。

これはWindowsにおいてもそんなものだとは言えるが、どちらかといえば性能とか好みとか思想の問題であり、AMDだと困るという要素は少なかったのだが、Linuxにおいては動作安定性という意味でもAMDは避けたい、という状況があった。

大きな問題としてはCatalystドライバのデキの悪さがあった。プロプライエタリドライバーとしてもNvidiaよりも後にサポートされてきたCatalyst(flgrx)ドライバーだが、様々な問題が発生していた。私が利用している限りでもXサーバーのフリーズ、マウスカーソルの文字化け、ティアリング、画面化け、X再起動の失敗、などなど枚挙に暇がない。

AMDがLinuxに力を入れるという選言をしたのは、Linux 4.6の頃であったと思う。 そしてAMDGPUドライバーが誕生したわけだが、実際安定性は高いものの性能はいまひとつであった。

そこから3年ほどが経過している。 Linux 4.18ではAMDGPUの改善が進んだ。Vega 20や、Intel Kabylake-Gプロセッサ(IntelのプロセッサにAMDのビデオカードが内蔵されている!!)といったデバイスサポートが主だが、AMDGPUドライバーそのものの改善も結構手を入れていた印象だ。 その結果AMDGPUドライバーは4.18の初期には性能が従来よりも低下していた(!)

AMD APU(Godavari)マシンに4.18を導入してみて驚いた。 アップデートごとにどんどんよくなっていたAMD環境だが、4.18は明らかに描画がスムーズになった。 ビデオ性能に関していえばNvidiaのほうが(私の手持ちでは)良いのだが、結局のところLinux利用の上での快適性は画面のちらつきや、フリーズの有無、あるいはビデオ再生に支障があるか…といったことに左右される。

結果的に性能は圧倒的に低いのだが、そうしたエラーが少ないAMDGPU環境が非常に快適に感じられてしまうのだ。 実際、ビデオ再生に関してもLinux 3.17あたりの再生と比べて明らかに快適になった。

現状、ビデオドライバーから見れば「AMDGPU > Intel > nouveau > nvidia」という状況になっている。 本当に力を入れてきたAMDドライバーの成果が、「とりあえずIntel安牌」という状況を靴替えしている。Nouveauもそれなりに安定しているのだが、基本的にはメーカー協力のない、リバースエンジニアリングの成果物であること、またNvidiaはLinuxドライバーにあまり力を入れていないことからこの滋養今日が生まれているのだろう。

実際にPhoronixのベンチマークを見るとRX580がGTX1060よりも良い結果を出していたりする。 (まぁ、一方でVega56がGTX1070に全然勝てていなかったりするのでドライバーの優劣を反映しているようにも見えないが)

現状、Nvidiaドライバーでの問題と言えば

  • Google Chromeはウィンドウ移動時にマルチディスプレイでは座標がずれる
  • 画面が激しく点滅することがある
  • ffmpegでの録画時にちらつく。Allow Flippingを無効にしてもまだちらつく
  • Wineが条件によって問題を起こす (nouveauでも)

あたりである。このほか、Xサーバーのrespawnの失敗、Blink系ブラウザにおいてコンソールと行き来したり状況によってはフリーズする、デスクトップエフェクトの反応が悪い、などがある。

そしてCPUもしっかりとパフォーマンスを発揮するようになっていて、4.18においてはXeon Silver 4114のpowersave governorよりもA10-7870KのほうがChromiumで高速に描画できる(シングルスレッド性能の差だ)。

性能と選択肢の改善

Ryzenによって向上した選択価値

A10-7870Kシステムを組んだときには随分と後悔したものだが、Linux側の改善によって随分と快適なシステムに進化してきた。 従来のAMD APUは使い勝手は良いもののその性能は悲しいほどしょうもなかった。

A10はAMD APUでも上級グレードだが、その性能はIntel Core i3に及ばない。 PentiumやCeleronよりは良いのだが、現在はPentium Goldに抜かれてしまっているほどだ。

AMDはAシリーズの上はゲーム向けとしてビデオカードを内蔵しないFXシリーズをラインナップしていた。 だかいくらなんでも「Aシリーズの上はゲーム用」というのはちょっと乱暴である。一般用途で確実に十分であるほどにはA10は性能はよくない(ただし、恐らく十分である程度には高い)。

ところが、現在はRyzen Gシリーズがある。 これは従来のAPU (Aシリーズ)を置き換える新しいAPUである。

少し複雑なので説明すると、第二世代Ryzenには、第一世代Ryzenと同じくビデオカードを持たないモデル、 つまり従来のFXと同じ「ゲーマー向け高性能プロセッサ」という位置づけだった。

しかし、Ryzen3/5/7というネーミングの通り、Core i3/5/7の直接的なライバルとなるラインナップであり、 Core i3をゲーマー向けプロセッサとするのは無理がある通り、AMDも考えを改めた。 さらにいえば、Aシリーズの不評っぷり(性能がとても低く、そのくせ消費電力は大きい)とRyzenの好評っぷり(いままでのAMDが嘘のようだ)を踏まえてもAシリーズを継続させていくよりさっさと仕舞にしたほうが良いと考えたのだろう。 結果RyzenシリーズはAMDの主力プロセッサシリーズへと転身した。

しかし、それはそれでややこしいことになった。 AMDの場合、Ryzenにはビデオカードを内蔵するGシリーズと、そうでないSTD/Xシリーズの2系統がある。 さすがにゲーマーはRyzen3を使わないと悟ったのか、Ryzen3はGのみ、一方ゲーマーでもなければRyzen7は使わないだろうと考えているらしくRyzen7はSTD/Xのみ、一方Ryzen5は両方ある。1

単にビデオカードの有無かというとそんなことはなく、Passmarkで見てみると

CPU Score Intel rival Rival score
Ryzen 7 2700X 16882 Core i7-8700K 15975
Ryzen 7 2700 15087 Core i7-8700 15217
Ryzen 5 2600X 14448 Core i5-8600K 12805
Ryzen 5 2600 13523
Ryzen 5 2400G 9264 Core i5-8500 12060
Ryzen 5 2400GE 8513 Core i5-8400T 9672
Ryzen 3 2200G 7331 Core i3-8100 8086
Ryzen 3 2200GE 7229 Core i3-8100T 7532
Ryzen 3 2300U 7172

RyzenのGEやU、またIntelのH/T/Uについては後述する。

また、Ryzen Proというのはセキュリティの追加機能があるものである。

このようにRyzen5 2400GはRyzen5 2600よりも下位グレードという扱いになっていて、Core i5と勝負できるのはビデオカードなしモデル、ということになっている。お値段的にもちょこっと2400Gのほうが安い。

この中でRyzen5 2400G及びRyzen3 2200Gは非常に魅力的である。

そもそもAPUという発想は悪くなかった。「別にそんなにCPUパワーはいらないだろうけど、動画見たり、たまにはゲームもするだろうし、ビデオ性能はそれなりに高いほうがいいだろう?」という考え方にはとても同意できたのだ。だが、Aシリーズは「そんなにない」というか「あまりにもない」というのが現実であって机上の空論に終わっていたのだ。

ざっくり、RyzenになってAPUは「2倍のパワーになった」と考えれば良い。さすがに2倍も速いと話は変わってくる。 HEVCのエンコードにも対応した最新ビデオカード(後述するvegaである)を搭載しながら、2倍速くなったAPUは普通の人にとって本当にいいバランスになっている。

普通の作業にはRyzen5 2400Gのパワーは十分だし、軽作業ならRyzen3 2200Gは悪くない。そしてビデオ性能のほうはIntelはいささか不足気味だ。 大きなポイントとしては、IntelのQSVはCPUパワーをかなり使う。これは動画見ながら作業することは考えにくいラップトップではあまり気にならないが、デスクトップの場合、特にマルチディスプレイ環境では足かせになる。 また、コンシュマークラスのIntel CPUの場合依然として「動画エンコード中は他の作業が難しい」という状況が発生する。 人によっては些細な違いに思えるかもしれないが、実際は使い心地に影響を及ぼす可能性がある。

また、自作する場合はAMDのマザーボードは非常に高機能なものや安価なものが揃うという点も見逃せない。 実際、私のA10システムは豊富なUSBサポート、8つのSATA、S/SPIF端子を持つオーディオなど豊富な機能によってデスクトップユースで一線級ではなくなったとしても様々な使い途が残る。

強力なシステムも組めるようになった

Core iと比べたとき必ずしもRyzenは魅力的なわけではないが、AMDのプロセッサの性能が大幅に上がったために、高性能が求められる局面でもAMDという選択肢が加わった、という点が大きい。

さらにThreadripperに至っては文句なしに強力である。

だが、CPUに関してはあからさまにLinuxにおける利があるわけではない。 ビデオカードの話をしよう。

現在のAMDのビデオカードラインナップはちょっと複雑で、やや古いRX 400シリーズはPolaris10, メインストリームのRX500シリーズはPolaris20、ハイクラスのRX VegaはVegaと設計が異なる。 さらにメインストリームはVegaにならずPolaris30になり、ゲーム用はVega20になってからメインストリームがNaviに、ハイクラスはNavi20になる、と噂されている。 (つまり、Navi登場までの間をメインストリームはPolaris、ハイクラスはVegaのままプロセス微細化されたものでつなぐらしい)

ところがAPUに搭載されているのはVega。Vegaのほうが新しい。取り残されているRX500がすごくいまいちに思えてしまう。

しかしここには罠があって、Linuxでは(Windowsと比べても)性能的にVegaがいまいち振るわず、Polarisのほうが良い結果を残している。 AMDGPUドライバが新しいVegaの性能を発揮できていないのかもしれない。

ともかく、Ryzen 7 2700X + Radeon RX580, Ryzen Threadripper 2950X + Radeon RX Vega 56, Ryzen Threadripper 2990WX + Radeon Pro WX 8200のような強力なシステムを組めるようになったわけだ。

Radeonの重大な欠点だったHEVCエンコードも対応しており、NVENCほどではないもののVCE/VA-APIでかなり高速にエンコードができる。

APUによる省コストなシステムだけでなく、パワーを必要とするシステムにおいてRadeonを使う、ということが現実的になったのだ。 もちろん、これはIntelプロセッサと組み合わせても構わない。

省電力システム

AMDはいつの時代も電気を食うものだった。 さすがにそれが終わりを告げた、とまでは言わないが、Intelの高性能プロセッサがTDPを越える電気を使ってしまう中、 Threadripperは実質的なワットパフォーマンスでの逆転を見せた。

そんな新時代のAMDとして推したいのがRyzen 5 2400GEである。

Intelの場合H(省電力), T(超省電力), U(超低消費電力)とラインナップされていたりするのだけど、AMDの場合GEはT相当と考えてよさそうだ。

2400GもcTDPで35W/45W/65Wということらしいけれど、そんなややこしいことは置いといて、2400GEは35Wである。 35Wだけどベースクロックは3.2GHz。ここらへんのCPUは割と容赦なく電気を使うので、まったり処理してほしい低消費電力システム(特にホームサーバー)ではすごく便利だ。

それだったらIntelのTでも良さそうに思えるけれども、前述のようにビデオカードが強力である。 ホームサーバーとして使うなら動画処理性能は重要な項目となりえるし、デスクトップとして使うなら描画環境は重要であり、AMDのほうが快適である。

もちろん、これは「Linuxで使うラップトップでAMD優位」という状況でもあると言える。 (もっとも、絶対的な消費電力の問題があるから話はそう簡単ではなくなってしまうが)


  1. この考えはとても正しい。多くの人はCore i3で満足できるが、ゲーマーはCore i3では足りない。一方、多くの人はCore i7を必要としていない。

Mimir Yokohamaで続く改修、力を注ぐ

2018年8月5日、Mimir Yokohamaのソースリポジトリにはじめてのタグ、5.0が打たれた。

なぜはじめてのタグなのに5.0だったのか。

これは、Aki SI&Eのプロトタイプを1.0, Aki SIEのウェブサイトを2.0, Mimri YokohamaのWordPressを3.0, 現在のウェブサイトになったときを4.0とカウントしたものだ。

つまり、はじまって以来の、同一システムのままのバージョンアップとなった。

しかもこのタイミングである。 先日、大幅な編成変更と、いいね機能、コメント機能の追加を行った。 これで新しい船出だというタグではない。かといって同バージョン最終仕様としてのタグでもない。

これから次々とアップデートが予定されている。 その中での一区切りだった。

13年積み上げてきたものとは

PureBuiler Simplyの原型となっているのは2005年のACCS1である。

もうブログが流行り始めていた頃だったが、既に「事前生成戦略」に関するイメージはあった。 ブログを避けた理由は、一連の流れを持つ記事群を拾いにくくなること、そして時間とともに消えてしまうことだった。

「普遍的な内容を、きちんと分類して読みやすいように提供したい」と考えたわけだ。

様々な機能、様々なアイディアがあった。 実装されたものもあるし、実装されなかったものもある。 言語もPerl, PHP, Zsh, Rubyと変わってきた。 このような変遷をたどっているのはEQAIとこれだけで、まさに私のライフワークであり、また成長の軌跡でもあった。

この中でこだわってきたものもある。

例えば、デザイン性を保ったまま軽量・高速なウェブサイトを構築すること、可能な限り高いアクセシビリティを提供すること(環境や回線の違い、身体的ハンディキャップなどで差別しないこと)などもそうだ。 意味あるコンテンツを、読みやすい形で提供する、というのもある。

ACCSが追い求めてきた機能は次のようなものだった。

  • カテゴリで分類されて探しやすいインデックス
  • 検索機能
  • 意思表示機能 (コメント、と考えていることが多かった)
  • 連続した記事のページめくり
  • 要約の先読み
  • インライン用語集
  • prev, next, glossary, index, description情報を持たせる

PureBuilder Simplyは当初、Mimir YokohamaのWordPressページで提供されている全機能を提供する、ということを目標としていた。 これについては既に達成されている。そのために、従来のPureBuilderにはなかったタグ機能なども追加された。

「いいね機能」「コメント機能」はWordPressに完全な意味で標準であるものではないのだが、事実上付属するようなもの(特にコメント機能は)なので、これを追加したことで、事実上「WordPressを置き換える」というミッションは完遂した。

だが、同時に既にWordPressにはない機能の搭載もはじまっていた。 用語集機能はWordPressではなく、PureBuilderの伝統に由来する。そう、ACCSが目指していたものを達成する、という次のミッションに向かいはじめたのだ。

そこでつけられたのが5.0タグだった。

用語集機能

用語集機能という発想のスタート地点は、私が使っていたWindows 98SEマシンに搭載されていたインライン翻訳ソフトだった。

カーソルを載せるだけでその単語を翻訳してくれる、というソフトウェアは今持ってそれ以上のユーザービリティを提供するものはない。

「カーソルを載せたらわからない言葉を教えてくれる」というのは最高に便利だと思ったのだ。 現在はニコニコやはてなが似たような機能を提供しているが、あれはページが変遷してしまうため私からすれば理想的ではない。 どらちかといえばWikiに搭載されているインライン展開のほうがずっと理想的だ。

この機能は

  • 表示後にJavaScriptでtreatする
  • 生成時にHTMLを置き換える形で組み込む
  • ソースドキュメントを改変してから生成する

という3つのパターンを行ったり来たりしている。

PureBuilder SimplyではPost Plugins/Pre Pluginsの構造からこの3つとも選択肢として取ることができる。 Mimir YokohamaではPost PluginによるHTML置換え方式を取っている。

このあたりは試行錯誤の成果といえるだろう。 用語集ページも含めてYAMLの辞書ファイルから生成しており、文書に対して特別な処理は必要ない。

次の記事、前の記事

ACCSで最も苦戦したのがこの機能だ。

この解決については何度か言及しているが、今は前後関係をメタ情報として書く、という仕様になっている。

解決方法としては後退しているように見えるが、前後関係の自動解決はファイル名なり、もしくはなんらかのヒントなりを厳密に管理する必要があり、結構バグりやすいということを経験したのだ。

複雑な置換えやユーザーの管理によってバグを発生しうるようなものであるならばメタ情報をユーザー自身が書くべきだ、という割り切りは、これまでの歴史の中で手にしたバランス感覚である。

実のところ今の構成では前後を自動化することは難しくない。 だが、ユーザーがそれを守ってくれることを期待すべきではないだろう。

Post pluginsはページ生成が終わってから実行されるが、これは「他の記事の情報を取得できるようにする必要がある」からであり、 環境変数$pbsimply_indexesという形でデータベースのパスが渡っていることから

のようにして取得できるし、 連番に限るのであればもっと簡単に

とできる。 ちなみに、ディレクトリを認識させる方法は最新のコミットで環境変数$pbsimply_subdirに含まれるようになった。

このように「できるけれど、あえて手書き」だ。 これは、問題を簡単にするためと、この処理をPandocテンプレートを通じて行いたいためだ。 Pre Pluginsを使えばできるが、かなり複雑なことをすることになるため避けている。

意思表示機能

過去には「コメントを直接にHTMLファイル化し、objectで読ませる」ということをしていたこともある。

表示するかどうかを別として、コメント機能はそのときとあまり変わっていない。 表示させるために必要な部分を削ってシンプルになったくらいだ。

このような機能は本質的な部分は極めて簡単に書けることはこれまでの経験によって証明されている。 どの程度正当性を検証する必要があるかという点がwebアプリケーションの分量になる。

要約の先読み

まずは要約を入れる

いよいよ今回のハイライトだ。

descriptionへの対応自体は最初のリリース時点で

という記述があり、対応はちゃんとしていた。 だが、「書くのが面倒」「書いてもあまり意味がない」ということで放置していた。

「descriptionの先読み」は今まで実装計画には入っていたが、実装されたことはなかった。 そもそもdescriptionってSEOのために入れられているくらいで、「descriptionを読ませる」という発想はあまりない。

Firefoxだとこんなふうにブックマークのプロパティを表示するか、ブラウジングライブラリー上で詳細表示にするとdescriptionが表示されたりするのだが、これを見たことがある人という人は地球上に5桁いないのではないだろうか。

Firefoxのブックマークの詳細

だがdescriptionは入れたいと思っていたし、それを活用したいと思っていた。

そもそもの発端はトップページのレイアウト更新で、最新の更新記事と要約を(ニュースとは別に)表示したい、ということだった。 「どうせ記事の要約書くんだったらdescriptionに入れようよ」ということだ。

実はAtomフィードもスタンバイしている。

要約を見える形に

だが、これだけではおもしろくない。どうせ要約を表示するのならばぜひともユーザーに見える形にしたい。

私の文章は基本的に長いので(体系的でない短い文章に価値を感じていない)、読むのがしんどい人もいるだろう。 読むかどうか決めるために要約は重要だ。

要約を見たいタイミングとはいつだろう? やはり記事を読み始める前だろう。ならば本文前に

とかやってやればいいし、そのほうが効果的なのかもしれないが、既に「文書情報」という項目があることを考えるとちょっといただけない。

そこで文書情報に追加した上で「記事タイトルをクリックすると文書情報にジャンプする」という仕様にした。

これはヘルプページにも書いてあるけれども、誰も気づかなそうだ…

もうひとつ、利用者は多くなさそうだが、カテゴリインデックスがある。 ACCSとしてはこれが中心であり、ぜひとも使って欲しい機能だ。 世の中、情報を整頓するということに怠けすぎて、検索が全てになってしまっているので、使われていないような気もするけれど…

しかし私の意図としてはこのようなインデックスを活用してほしいというのがあるし、やはりタイトルだけではわかりにくい。 かといって変遷するとだるいので、変遷せずにインデックス上で要約を確認できると便利だ。

これはタイトルで関心をそそられた後の二次的な情報であり、通常は一覧性が高いほうがいい。 というわけで、ツールチップにしてみた。

PureBuilder Simply ACCS上でDescriptionを扱う

単純には記事タイトルにtitleで入れてあるため、ロールオーバーツールチップとして表示される。 だが、スマホだとこれが効かないので、補助的に“📖?”と表示して、これをタップすればツールチップが表示されるようにしてみた。 全く標準的でないインターフェイスなので、あまり気づいてもらえないような気もするけれど…

PBS ACCS用ツールチップ実装

何度見てもJavaScriptの複数代入が慣れない。 慣れればみやすそうだけども。

世の中的には割と珍しいDOM操作をしているが、これはelementに対してイベントリスナを設定するためで、innerHTMLだと二度手間になる。 基本的にやっていることは「記事部分 > リスト全体 > リンク」と絞り込んでいって要素を作成して追加する、という手順だ。 末っ子要素を追加するとき(今の要素の親要素の最後の子要素として追加する)はelement.parentNode.appendChildという手順は覚えておいてもいいかもしれない。

glosarryと共通のコードがライブラリとして読まれるようになっている。ライブラリはdeferだがasyncではない。

900pxを堺にしているのは、「サイドカラムがあるのであれば表示領域は少なくとも右側にサイドカラム幅はあるが、シングルカラムになるとそうではない」からだ。(このページのシングルカラム境界は800pxである)

機能チェックしているが、document.addEventListenerできないブラウザでJavaScriptに対応しているものはあまり残っていないだろうし、あっとしても単純にイベントリスナー設定時にエラーになるので放置してもいいかもしれない。 ただし、間違って複数回ライブラリが読まれたときのためにArt.tooltipはしておかないとイベントリスナが複数設定されてしまう。

PureBuilder Simplyはうまくいっている

PureBuilder Simplyがここまでうまくいっている理由としては、やはりPandocの強力さがなによりだろう。

PureBuilder SimplyはPandocが持っている機能をちょっと拡張する…という考え方をしている。 今までドキュメントジェネレーター自体を制作していた(PureDoc)ことと比べると問題はかなり簡単になっている。

Pandocの動作は必ずしも簡潔ではなく、自分で実装するのであればドキュメントジェネレーターにここまでの機能をもたせることはないだろう。 だが、Pandocがある以上はPandocを使いたい。

もしPandocがなければdocutilsを拡張することを考えただろうが、その場合はPureBuilder Simplyは今のように良いツールにはなっていなかっただろう。

PureBuilder Simplyが今ほど素晴らしいツールになったのは、Pandocがあったからこそだ。

Mimir Yokohamaに対して行われている様々な拡張は今の所PureBuilder Simplyに対して適用されていない。 これは、PureBuilder Simplyが生成するものに対する機能ではなく、Mimir Yokohama固有の、そしてテンプレートとCSSによるものだからだ。

だが、いくらかでも一般化してPureBuilder Simplyに還元していければと思っている。 PureBuilder Simplyのエコシステムの充実は普及には不可欠だろうから。

Mimir Yokohamaに「いいね機能」「コメント機能」を追加

概要

Weekly 10000PVを達成して機能強化に力の入っているMimir Yokohamaのウェブサイト。

連続の機能強化でついに「いいね機能」と「コメント機能」が追加された。

実は先日の「お問い合わせフォームの実装」は単にその機能を実装する最小限ではなく、簡単なアプリケーションを実装できるプラットフォームになっており、 アプリケーションを追加する条件が整っていたのだ。 また、そのためのテストもしてあった。

そのため、実は今回コード追加はわずかで、両方合わせても23行ほどにとどまる。 ごく簡単だが、確証が持てないためにテストと本番環境のための修正を行ったりして結構な時間がかかった。

これに関してはみるべきところはあまりない。 受け取ったパラメータをファイルに書き込めば良いだけだからだ。

ちなみに、連打しやすいアプリケーションを入れるために連打の対策もサーバーにしてあった。 実は先のパフォーマンスチューニングはこの対策によってパフォーマンスが低下してしまったため、これをカバーするついでに行ったものだった。

いいね機能の設計

いいね機能はごくシンプルだ。

Pandocテンプレートを使ってページタイトルを埋め込むことができるので、これだけ使うのであれば単にテンプレートの中にフォームを書けばいいだけ、ということになる。

実際はリファラ(Rack::Request#referer)及びユーザーエージェント(Rack::Request#user_agent), IPアドレス(Rack::Request#ip)も特定に使用している。

ポイントは「一度送信したら表示を変更、送信を無効化する」ということだ。

inputタグのdisabled属性を使うことで送信ボタンを無効化している。

そう、この機能はHTML上でインラインで書かれているのだ。 このような書き方はW3C的には推奨されないのだが、Googleは推奨している。 実際、これだけのためにJavaScriptファイルをロードさせることをしたくなかったので、インラインにした。

ポイントは

  • Legacy DOMにおいてフォーム部品は連想配列のようにアクセスできるようになっている
  • submitボタンのラベルはvalueである
  • disabledによってフォーム部品を無効化できる

である。

これらの処理は送信の「前に」行われる。 これは正しいことではないが、問題はない。 なぜならば

  • 送信できなかったからといってユーザーが修正するなどの手を入れる余地はない
  • 特に返信を必要とするものでもないので、送信失敗はクリティカルな問題でもない
  • サーバーエラーなどは表示されるようになっている

からだ。

また、画面変遷せずに送るだけ…というと、Ajaxで非同期に送るしかないように考えるかもしれないが、 実際は現代のブラウザは基本的に2XXステータスで空コンテンツを返すとページ変遷しないようになっている。

このような用途のために204(No Content)が用意されているため、204を返す仕様だ。 できるだけブラウザの標準機能に頼るようにしている。

このボタン、めっちゃgooglebotが押してくる…

コメント機能の設計

公開されるものではなく、sanitizeしなくても問題が発生しない設計になっている(単に文字列として扱う以上の取り扱いがなされる条件で使用しない)ため、非常に楽だ。

難しく考えるよりも、シンプルで挙動をちゃんと把握できていて、余計なことをしない方法をとるのが最も楽に、確実に、バグなく設計できる。

ただ、この機能に関しては「コメントフォームの表示」などが必要になり、JavaScriptが必要になった。 また、コメントするというあまりとらない行為のための部品であり、常にロードすることは非常に好ましくない。

そこでとった方法は「JavaScriptの遅延ロード」であり、「クリック時にelementを追加してJavaScriptを読み込む」という方法だ。

これでscript要素を追加している。

では呼び出されたあとどうしているのか…というと、こんな感じだ。

そう、コメントフォームは標準でHTMLに含まれていない。

パフォーマンス的にみても親切機能のためにもう重くなりつつあるドキュメントをこれ以上重くしたくないので、 「フォーム部分はJavaScriptがロードされたときにinnerHTMLで書く、という方法をとっている。

「クリックされたときにはじめて必要とされるのでドキュメントノードを追加してロードする」という手法は稀に使われるが、さすがにそれでHTMLドキュメントそのものを生成するというのはまず見ない手法になっている。

連打されたときのことを考えて、clickイベントを発生する値に特殊なプロパティを埋め込み、何度も実行されないようにしている。 なお、これは本当に連打したときだけ機能するもので、JavaScriptシングルスレッドなので一回このスクリプトに入っていまえばこのスクリプト中に割り込まれることはない。 だが、連打されるとイベントがキューに入ってしまうので何度も実行されてしまうことから、そうしたことがないようにしている。 シングルスレッドなので、このスクリプトが実行されているのにプロパティが設定されないうちにまた実行されるということはない。

元になるフォーム自体は存在していて、submitボタンを配置すればフォームの送信は可能だ。 そのため、submitイベントに対するイベントリスナーを設定するものはHTML上に静的に存在している。

その上で「フォームはやっぱり閉じられたほうがいいな」ということでボタンクリックに対するイベントの変更、及びボタンラベルの変更を行っている。

送信を行った場合はもうコメントフォームは使わないので、コメントフォームは非表示にして(削除はしていない)ラベルを変更している。

ラベル変更だが、input部品とは違ってbutton要素は子要素テキストノードがラベルになっているので、dataプロパティの書き換えによって変更している。

もともとHTML上でLevel0 DOMイベントを使っているので、スクリプト上でもLevel0 DOMによってイベントを変更している。 いつもaddEventListenerを使っていたので、珍しい。 イベントの削除はイベントにnullを代入するだけだ。

なお、HTMLで全て含めてしまえばJavaScriptは排除できるのだが、これ以上余計な要素を組み込むことはできれば避けたいためこのような仕様になっている。既にDOMコンパイルは割と重い。

また、デザインポリシーからいって、多くの場合余計なコメントフォームを常に表示させておくというのは美しくないとも思っている。 JavaScriptを使わずCSSでオンオフするようにもできるが、そうすると今度はボタンのテキストを変更するのが難しいし、連打や再送信を防ぐのも難しい。

このことから、なにがなんでもJavaScriptを使わないのが正義、ということでなければ、 このような付加コンテンツはユーザービリティの点からも素直に使うべきだと思う。

こちらもいいね機能同様、送信する前に状態を変更してしまい、成功すれば204を返す仕様。

Legacy DOM と DOM Level0 Eventに関して

Legacy DOMやDOM Level0 Eventについて意見をもとめられることがたまにあるのだが、私としてはあまり勧められないと考えている。

非常に簡単なので学習にはいいが、Legacy DOMはHTMLの構造に依存する。例えば

として、

とかやってしまうと、ドキュメントの構造が変わるたびに修正だ。

だが、「フォームにのみnameで使い」「フォームはW3C DOMで特定する」のであれば悪くない。

DOM Level0 Eventはイベントリスナーが1つしか登録できないためモジュール設計になっている場合や、なんらかのライブラリを使っている場合は使ってはいけない。 イベントを「追加」する場合はLevel2で、イベントを「設定」する場合はLevel0という使い分けも考えられる。 HTMLに直接書く場合はLevel0しか書けないので、その部品の基本的な動作と定義されているならLevel0でもいい。

ただし、その場合でもできればLevel2 Eventを「後から追加する」のが適切なので、DOM Level0 Eventの使いどころは今回のようなものが唯一だと思う。

Amazonのコンテンツ戦略とユーザーの問題

かつてのPrime

Amazonはいよいよ本格的にコンテンツ課金をはじめたようだ。

Amazonはプライムの価値を高めるため、Amazon Prime Music, Amazon Prime Photo, Amazon Prime Videoといったサービスをはじめた。 このサービス自体はアメリカ(.com)と同じものだが、.comと比べるとだいぶ安価な設定になっている。

そのためにプライムの価値は高かった。 当時プライムでなくても配送は無料だったし、お急ぎ便と変わらないスピードで届いていたのでプライムの価値は微妙だったけれど、こうしたコンテンツの充実によってプライムの価値を高めた。

Prime Musicはもとより微妙だった。 音楽大好きな私は大歓迎したのだけれど、とにかく収録曲数が少ない、というかラインナップが大変微妙。 しかもその微妙な音楽もどんどんPrimeから外されていくので実用性も微妙だった。

特殊なBGMをかけたいとき(ムードミュージックとか)でなければ使わなかった。

Prime Photoは現在も有効だけれど、写真をAmazonに渡すことを考えると…

そうしたことを踏まえてもAmazon PrimeのキラーコンテンツはAmazon Prime Videoだったと言っていい。

コンテンツ課金へ

付加コンテンツは微妙だが本国より圧倒的に安価なAmazon Primeはかなりの人気を集めた。

だが、Amazonはあまりユーザーのほうを向いていないようだ。

非Primeに対して送料有料にする、ということは無料自体が一時的なものだったからやむを得ないだろう。 また、梱包の質が落ちていることも、配送が遅れ気味であることも、Amazonのサービスの根幹的価値を落としている気がするが、かつての品質が非人道的労働によるものだとするならば、人はその品質低下は受け入れるべきだろう。

だが、問題は結局はPrimeに付加コンテンツを含めることをやめつつある、ということだ。

今後追加されると言っていたPrime Musicに関しては追加された楽曲にめぼしいものは少なく、主には(.comでライセンスされている)洋楽だった。むしろ追加より削除のほうが目立ったくらいで、人気アーティストの盤はライブや 結局、(私に限らず)Amazon Prime Musicは おまけのような存在を脱していなかったのだ1

そこへAmazon Music Unlimitedが追加された。Music Unlimitedサービスとしては標準的で、Primeサービスを拡張する感覚で使えるのがメリットだ。 だが、Amazonの付加コンテンツがただのお試し版であることが明らかになってしまったとも言える。 Primeの価値を高めるために追加されてきたコンテンツはあくまで他の有料サービスの体験版で、Primeの価値を高めるものではない(広告的存在である)と位置づけが変わってしまい、結果的にPrimeの価値はさらに下がった2

そしてPrime Videoもいまいちな状態となり3、早々にPrimeのみの表示だったトップページがPrimeをクリックしてもAmazonビデオのトップページとなり、さらに現在はPrimeのページにも購入の項目が並ぶようになっている。

そして有料チャンネルの追加だ。Prime VideoからJ-Sportが見られるようになった、というメリットはあるものの、これも本家で入ったほうが安く、オプションも豊富、見られる番組も多い。

とはいえこの時点では従来のPrime Videoが損なわれたわけではなく、「微妙な有料追加コンテンツが入った」というだけなのであまり見向きもされなかったのだが、一気に話題となったのがdアニメ for Amazon Primeの登場だろう。

Amazon Prime Videoはもとより比較的アニメに強かった。 だが、dアニメが圧倒的なラインナップを誇るためアニメ好きの選択肢というよりはアニメファンとしてはライト層の選択肢であったといっていいだろう。 ここにdアニメが加わったことは、単純に言えばAmazon Music Unlimitedのようなもので、コンテンツに幅が増えた、と言える。

だが、問題は、本家dアニメと比べて随分とラインナップが少ないこと、そして「Amazon Prime Videoを廃止してdアニメのみになった人気番組がある」ことだ。

ユーザーの絶望的リテラシー

もちろん、そのようなことは腹立たしいだろう。 私も「えー」と思った。

だが、大荒れのレビューは、ちょっとこんなにも愚かな人がこの世界にあふれているとはにわかには信じがたいものになっている。

まず、「元々お金をとっているのにさらに追加でお金をとるなんて詐欺だ」という主旨の発言。

Prime Video以外に選択肢がある、と理解しているのであればPrime経由でなくそちらでみればいい。 別に複数の課金コンテンツがあることはなんら問題ないだろう。 また、(その人はアニメのためにPrimeに加入しているのかもしれないが)Amazon PrimeはそもそもAmazonでの買い物のための優待であって、Prime Videoは付加コンテンツにすぎない。Amazon Primeが気に入らないのならPrimeを退会すれば良いし、なんならAmazonを使わなければ良い。 その自由はあるし、別にAmazon Primeをやめて他のところに加入するのも、Amazon Primeとは別に他のところに加入するのも自由だ。 Amazonにお金を払っているからといってすべてが手に入るわけではないのだから。

そして、「Primeのマークがあるのに途中からdアニメに課金させるなんて詐欺だ」という主旨の発言。

実際にそのような作品があった(それもかなり有名所であった)ため気持ちはわからないのではないのだが、元々Amazon Prime Videoの更新は不定期で、「毎週何曜日に更新」となっているものですら不定期だった。 対してdアニメのほうはきっちりやっているので時間差がある。

導入当初ならわかるのだが、既に大荒れコメントからの訂正というレビューが溢れているにもかかわらず放送回が更新されるたびにそんなレビューが追加されるのにはうんざりする。

多分、レビューが参考にならないといっている人はこのような人なのだと思う。 全く読まないか、もくしは読むとしても何かを読み取ろうとするのではなく自分の都合に合致するようにしか受け取らないのだ。 実際、このようなレビューは「他の人も言っている」とレビューしていたりするのだが、その人は訂正も入れているはずなのだが。

私はAmazonの対応よりも、自発的に何かを考えたり受け取ろうとしない愚かな人の多さによっぽど絶望している4


  1. AKBの楽曲があるので、AKBが好きな人なら満足したかもしれない。

  2. コンテンツ的にも削除が相次いで価値は少し下がったが、これは「PrimeはAmazonの特別なサービスを受けられる」から「PrimeはAmazonの他のサービスの体験版がついてくる」に位置づけとしてグレードダウンしたという話だ。

  3. これに関しては意見は様々だろうけれども、削除が目立ち、放送と連動したものも不定期にアップデートされ、みたいと思うような作品はなかなかPrime扱いにならないなど本屋の安売りワゴンのような様相を呈してきているように感じる。

  4. もちろんAmazonのやり方が適切だとも思わないが、それは「Primeの付加価値が低下し、存在価値が微妙になった」というだけのことで、サービスの質の低下についてとやかく言うことでもない。

Chromiumのインスペクタにいつの間にかモバイルデバイスインスペクションが入っていた

web分野の人にとっては当たり前の可能性もある知識だけれども、Chromiumのインスペクタにモバイルデバイス向けの検証機能がついていた。

Chromiumのモバイルインスペクタ

これをオンにすると、モバイル的な画面サイズとなり、同時にタッチエミュレーションが行われるようになる。 レンダリングが調整されるということはなく、あくまでこの2点が変更される。

モバイルインスペクタのガイド画面

Responsiveモードではサイズを柔軟に変更することができる。 実際に小さな画面ではどのように表示されるのかということをエミュレートできる。

また、デバイスごとの画面設定も可能。 候補は少ないがiPhoneは入っている。

機種や回線をエミュレートできる

ここで言う解像度は論理ピクセル数である。 例えばiPhone8の画面の実ピクセル数は1334×750だが、668×375と認識されている。

これはスケーリングによって1pxを実際の1ピクセルと対応させない、というもので、先日書いたので参考にしてほしい

拡大率は画面表示のサイズを変更するもので、リアルサイズに近づけることで物理的な大きさもチェックできる。

上部にあるガイドは各種デバイスに合わせた表示状態をエミュレートできるものになっている。 クリックするとResponsiveの状態で各プリセットにあったものになる。 Laptopが1024px, Laptop Lが1440pxとなっており、この上に4k2560pxもテストできるようになっている。

また、ネットワーク状態もエミュレートできる。 低速な回線ではどれくらいロードにかかるのかということもテスト可能だ。 offlineはページをロードしたあとにofflineにし、Ajaxが使えない状態をテストすることができる。

Low-endでMimir Yokohamaが4秒程度なのに対し、Chienomiは15秒ほどかかったので、その高速さにだいぶ満足している。

デバイスの論理ピクセル数なんて調べるのはとても大変なのでプリセットが入っているのはとても嬉しい。 サイトの設計にもよるが、私の設計だとアップロード前に十分なテストが行える。

HTML5でリンクタイプが変わっていた

正直SEO屋が好みそうな話題は触れたくないのだが。

link, area, a 要素の rel 属性で使用できるアドレスと文書の関係を示すリンクタイプ。

MDNを見ると色々書いてあるけど、あれ、glossaryとかcopyrightとかなかったっけ…

と思ってみると、HTML5HTML4で全然違う。appendexとかsubsectionとかもなくなっている。

copyrightlicenseに置き換わった模様。

ブラウザ側で実装されるべき機能が実装されずにいたためか、検索エンジン向けの情報になってしまっていて、ユーザーナビゲーション補助に使えるものがごっそり削除されている。

HTML4のリンクタイプをみんな知っているのかは分からないけれど、分かっているという前提でHTML5から重要そうなのをピックアップしてみよう。

stylesheet

おなじみのstylesheet。 これしか使わない人が圧倒的多数かもしれない。実はaareaにも使える。

next / prev

連続する文書の関係を示すもの。Netscape 6以降はナビゲーションで操作できたけれど、今はそんな効果はなくどちらかといえば検索エンジン向け。

比較的実用的で、モバイル版のOperaはこれをヒントに連続ページとして表示するようにしているっぽい。

index, last, firstは削除予定らしい…困った話だ。使われないからか。

noopener

Window.openerによる元文書へのアクセスを禁じる。

怪しい広告とかの挙動を抑制できるけれど、実際にそのような広告にリンクしている場合にわざわざ書くだろうか?

nofollow

これはリンクを否定的に表現するもの、らしい。外部サイトを示すexternalとの違いがよくわからない。

大きなポイントは、nofollowとついている場合、検索エンジンに対して「被リンクとしてカウントするな」と伝えるものらしい。 言及はしているけれども否定的に言及しているもののランク上げを手伝わないため、あるいは自作自演の被リンク(いわゆるBad SEO)とみなされないため、というものだと思われる。

そうなると意味的ではなくあくまでSEO要素ということになるけれど、それで良いのか。 というか、そもそもHTMLに文書の意味と関係ないSEO要素を盛り込むのは好ましくないのではないのか。

Arial/Helveticaを置換え 読みやすい欧文をウェブに

本当にArialが見やすいと思うのかい?

さて、突然だがあなたに質問だ。

次の画像を見てあなたが読みやすいと思うのはどれだろう。 「見やすい」ではない。ちゃんと英文を読んで、読むのが楽だ、このあと延々百何十ページとこの英文を読むのも苦にならないと思うのはどれか、ということである。

比較1

比較2

比較3

比較4

あなたの心は決まっただろうか?

webでなぜArialを指定したがるのか

Arialが指定されている現実の確認

まずはTwitterのフォント指定を見てみよう。

次にGoogle

Yahoo! Japan。Arialは指定するがHelveticaは指定しない。 MS PGothicが先に指定されているので、かなりArialを指定している意味は恐らく全くない。ヒラギノより先にしている理由もわからず、 これはさすがに技術力が疑わしい。

さらにいえば、フォントファミリーにクォートなしでスペースが入るのも無効なはずなので、技術力完全に駄目なやつでは…?

Mozilla。Zilla Slabはウェブフォントになっている。

Facebook。Helvetica優先でヒラギノ優先なあたり、Facebookはりんご党らしい。

Microsoftコミュニティは日本版でも欧文フォントのみの指定。 それもWindowsデフォルトフォント優先だが、MacデフォルトのHelvetica Neueを優先的に指定する謎のこだわり。

震源地となったMSNは現在は指定なし。私が指摘してから変えた…?

理由と経緯

ArialというフォントそのものはHelveticaの代替フォントである。

Helveticaは1950年代からあるフォントで、すごく使われてきた。PanasonicのコーポレートロゴもHelveticaだ。

Helveticaは現在はライノタイプのフォントで、Macに入っている。 MacはHelveticaを改変したGenevaもあって、割と重用しているようだ。しかもArialもある。

Arialのほうは1982年にRobin Nicholas, Particia Saundersがモノタイプに依頼して制作したもので、Hervetica互換フォントで形は少し異なるものの文字幅は同じ。

ArialはAlternativeを含めればWindowsに古くから収録されていて、Helvetiva互換フォントとして使われてきた。 WindowsのArialはフォント名にHelveticaを含んでいるので、Helveticaと指定してもArialが使われる。

そして代替フォントであったはずが、Arialのほうが美しいとか、WinとMac両方にインストールされているとか1いう理由でArialが主流になっていく。 Arialもポストスクリプトフォントとしてはかなり初期に誕生しているし、当時はあまりポストスクリプトフォントはなかった(し、高額だった)。 指定しなければビットマップフォントが使用される可能性が高く、すごく雑なビットマップフォントが多かったから、Arialの指定は高品位フォントの指定だったといっていい。今の日本の感覚で言うと、モリサワのフォントを指定するような感じだ。特にヒラギノ。

Arialが使える前提に立っていると、UIに使いやすかった。 ボタンはピクセル数を指定しなければならないけれど、その上に載せるフォントに合わせていい感じに調整する機能はなかったから、 「ボタンの上にこの文字を載せるか指定するためにはこの文字がどれだけの幅を取るか特定できなければならない」だったのだ。 当時はDPIも固定だったから、これは表示してしまえば確実に制御できたし、そこでArialが使える前提に立てば簡単に作ることができた。

あと、ワープロ文書でも文字数と改ページの関係でボックスサイズが変わると困ることがある。 ここでもArial前提にしとけばワープロ文書のままで受け渡しができる、というわけだ。 これは今MS Pゴシックの状態でワード文書を送りつける愚か者2と同じような心理である。

ところがだ。HelveticaにせよArialにせよフリーなフォントではない。 そこでサイズが同じ「メトリック互換フォント」がArial以外にも作られることとなる。 これはもう、Helvetica互換というよりはArial互換である。

  • Nimbus Sans (URW)
  • TeX Gyre Heros (Ghostscript)
  • FreeSans (GNU)
  • MS Sans Serif (Windows)
  • Arial (Microsoft)
  • Liberation Sans (Liberation Font Project)
  • Arimo (Chrome OS)
  • Albany (StarOffice)

これでArialに対する互換性をクリアしたわけだ。

和文フォントでも若干そういうものはある。 AAフォントと呼ばれるもの(IPAモナーフォントやMonapoなど)は5ちゃんねる(当時の2ちゃんねる)上でアスキーアートを表示するためのものだが、 梅フォントファミリーがMSフォントメトリック互換であるのは恐らくワープロ文書やメールにおけるレイアウトの都合だろう。

webでの指定の話

CSS登場以前はUI部品のサイズを柔軟かつ明瞭に指定する方法がそもそもなかった。

そのためUI部品にテキストを載せる場合(画像にすると当時は重かった)、レイアウト上「横にいくつボタンを並べる」という都合があり、 これをぴったりに載せる方法がWindowsでもMacでも使えるArialを使う、という方法だった。

これが「WindowsとMacにインストールされているフォントを考慮する」という誤った理解となり、思考停止したままWindowsとMacのフォントをそのまま指定するようになったのが「システムデフォルトの日本語フォントを指定する」問題だ。

挙げ句、MS Pゴシックはまだしもヒラギノとは全くデザインが合わない、単に美しくない状態となるだけの「欧文フォント指定があるから、それを消さずにその後ろに日本語フォントをWindowsとMacで並べればいいよね」という最高に頭の悪いアクションが生まれる、というわけだ。

だが、和文フォントをシステムデフォルトのものを指定するのが 全く意味がない のに対して、Arialを指定することは前述のように多少意味がある。 ただし、現在はCSSを使ってUIサイズを文字サイズ基準で指定できるため、まともなデザインセンスがあるのであれば問題にはならない。 そう、デザインについて数字でしか理解できないエンジニアが解決方法としてフォント指定に走るのはまだわからなくはないが、デザイナーがそれをやったら完全にデザインを投げ捨てているということになる。

基本的に「なり」のデザインになっていれば特に指定する必要はないのだが、UI上(好ましいことではないが)ボックスの中に入っていないテキストなどを書く必要がある場合はArialを指定するのは意味のあることである。 もちろん、その場合でもGoogleがしているように

とするのが適切。

ただし、google検索においてArialの指定が必要かどうかは疑わしい。 ただし、英語で検索するとGoogle検索の結果はArialの場合は2行であるため、2行に内容を詰め込むためには詰め詰めのフォントを使わせたい、というのがあるのかもしれない。そうでないフォントを使うと3行になったりするからだ。 その意味では「ゆるやかに意図を使える指定」ということで、ある意味妥当である。

Google検索の英語での結果 (Raleway)

このArialと汎用のサンセリフを指定する方法は日本語であっても有効である。 日本語はユーザーが設定したサンセリフ体が使われるだろうし、設定していなくても適切な日本語フォントが選択されるため、全く問題ない。

だが、そんなことを理解せず、思考停止してArial > Helvetica > MSPゴシ > ヒラギノにしているサイトが あんまりにもあんまりにもあんまりにも多い ので、3現実的に美しく読みやすく表示させようと思ったら、 「ArialとHelveticaとMS Pゴシックを置き換える」必要がある。

FontConfigに関してはウェブブラウザは当該フォントがFontConfigのエントリ上存在する(物理的にはなくてもいい)場合にその第一候補だけを取得するので、Arialに複数のフォントを設定しても駄目。 そのためArial+MS Pゴシックで合成されることを前提とした設定を行う、ということになりそうだ。

せめて日本語サイトで欧文フォントを指定していなければArialを英語専用で考えることができるのに、langも使わずまぜおって…

UI部品がArialでないと困るという場合でも、それはUI部品をクラス指定して、あるいはUI部品のタグで指定してフォントを指定すべきで、bodyに指定すべきではない。

デザイン的に指定したい (今の時代にデザイン的にデフォルトフォント、かつArialを指定したいとかセンスが死んでるけど4) 場合も「共通で入っている」とかじゃなくウェブフォントにすべき話だ。 和文フォントは大きすぎるため非常に迷惑になるが、欧文フォントは小さいので結構平気なもの。 Roboto, Open Sans, PT Sansあたりはキャッシュされている可能性が高いので、自前ではなくGoogle Fontsあたりを指定するのが良い。

なおWindows

Windowsでは標準でSerifやSans-serifを置換えることができないけれど、 Google ChromeもFirefoxもフォントの設定ができるし、している人は多い、少なくともユーザーにはその自由があるのでやはり強制はすべきでない。

Arialは本当に見やすいか?

冒頭の画像は

  1. Oxygen-Sans
  2. Arial
  3. Sen
  4. Input Sans Narrow

である。 私はInputが圧倒的に読みやすい。

見て気づくかと思うが、Arialはボックスに対して黒い「太めフォント」であり、極めて文字間を詰めた「詰め詰めフォント」である。 ある意味ではMS Pゴシックと類似の特性と言っていい。

Arialは「詰め詰めのフォント」であるため、代替は意外と難しい。 実際にArialは日本語フォントと比べpx数の決まったUI上に載せることが多く、サイズが違うフォントはUIからはみ出すケースが少なくないのだ。

そこでSans-Serifフォントから適当に見繕って表示させてみた。 Arialはとってもプロポーショナルなので文によって長さは大きく変わるが、おおよそこんな感じになった。 なお、試したフォントは200弱ほどあった。

サンセリフフォントの比較 (1)

サンセリフフォントの比較 (2)

サンセリフフォントの比較 (3)
サンセリフフォントの比較 (4)
サンセリフフォントの比較 (5)
サンセリフフォントの比較 (6)
サンセリフフォントの比較 (7)
サンセリフフォントの比較 (8)
サンセリフフォントの比較 (9)
サンセリフフォントの比較 (10)
サンセリフフォントの比較 (11)
サンセリフフォントの比較 (12)
サンセリフフォントの比較 (13)

この中からArialの代替になりそうなフォントを比較してみる。

Arialと代替フォントの比較

割と小さなところにも使われたりする(例えばTwitterのスクリーンネームとか)ので、グリフが小さいフォントは割とツライ。 UIフォントとして人気の高いUbuntuとOxygen-Sansは幅も似たようなもので優秀に見える。

私はlやtの字形がカーブしてくれているほうが見やすいように感じる。ここにはabilityみたいな縦棒いっぱいの単語がないが、 ぱっと見に字形を区別しやすいフォントが日本人には望ましいのではないか。日本語にはあまり「ぱっと見に字形を区別できない字が並ぶ」ということがないし、単語を字形で判断しようとするので、スペースで区切られた単語単位で識別して字は見ないという習慣があまりないためだ。

そう、日本人は日本語に慣れているが、日本語と英語では性質が違う。 日本語では一文字あたりの意味価値が高く、文字の識別が重視される。対して英語は単語感覚なので、どちらかといえば「単語の形」で見ていて一文字ずつはあまり見ていない。

Arialは詰め詰め黒々であり、単語の形で見るのであればなんとなく見やすいかもしれないが、ちゃんと文字がどう並んでいるかを識別しようとするとコストが高い。もうちょっと離すか、細くするかしてほしいし、字形も区別しやすいようにしてほしい、と感じるわけだ。 しかし字を離すと幅が増えてしまう。 TwitterのスクリーンネームなどでもArialが使われてしまうため、グリフ自体を小さくするとそれはそれで見づらい状況になる。

普通のCondenbcedでも厳しいくらい幅が狭く、代替を考えるのも難しい。

なお、字形の差については実はあまり問題がない。読みやすいフォントに代替するのであれば問題になるのは幅であり、例えばSans-serifではなくSerifを選択しても構わない。 ただし、それはデザイン的にArialが選択されている場合には違和感があるかもしれない。

Arialの代わりを探せ

もう少し長文で比較する。Arialがちょうど3行になっている。

Arialと代替フォントの比較 詳細(1)

Arialと代替フォントの比較 詳細(2)

デザイン的にも幅的にも差を小さくしたいのであればUbuntu、またはOxygen-Sansが有力候補だ。 Ubuntuは若干幅広、Oxygen-Sansは細字で詰めているため幅は逆に詰まる傾向がある。

また、リストに入れ忘れてしまったがSource Sans Proはかなり優秀な候補だ。 Source Han Sans Proの日本語部分でもあるため、かなり使いやすい。合成フォントとして人気の高いOpen Sansはやや幅が増えるが、こちらも優秀。

字形が違うものはどうだろうか。 Overlockは英文なら読みやすいのだが、日本語の中に混じっていると結構読みづらい。 Ralewayあたりだと変化が激しく若干の違和感があるが、不自由はない感じになる。

個人的に良いと思えたのはFira Sansだった。SenやAmikoもなかなか魅力的だが、幅の差がちょっと大きい。 今のところFira SansとRalewayとSenで迷っている感じだが、どうも私にはRalewayが良さそうである。

あとはもう好みの問題だ。だが少なくとも、Arialが他のなにより素晴らしいとは私には思えない。

設定例

メトリック互換

メトリック互換フォントに何を使うかはお好みではあるけども。

いい感じに表示する

和文はDPI100程度ならばさわらびゴシック、DPI150程度ならばMMCederがいい感じだった。


  1. もちろん、Helveticaで指定しても両方で使えるのだから、これを言う人は知恵が足りない。

  2. 相手がWindowsでない可能性、相手がMS Pゴシックを持っていない可能性についてわずかでも考えたのだろうか? 相手のことについて思索を巡らせず、自分に問題がないから構わないと考えるのはこの上なく愚かである。

  3. そんなこと言ってこのサイトも…と思っているみなさん。 あんまりCSSいじりたくなかったけど、直しました。アップデートでまた直すことになるのかなぁ。一応追加CSS側で上書きするようにしてはいる。

  4. 「英語のオーソドックスでキレイなフォントを指定したい」場合、RobotoあるいはOpen Sansが現代の主流。 現代は選択肢も豊富で、改良も続けられてきたので、Arialはさすがに古い。